September Cyber Threat Download™

Each month, the Pondurance team of experts in threat intelligence, incident response, security operations, vulnerability management, and compliance share insights with our clients and partners to help them stay on top of recent trends in cybersecurity and take action to prevent harm to their organizations. Please feel free to share this information with colleagues and other interested parties on social media. 

DFIR insights

The digital forensics and incident response (DFIR) team is seeing an uptick in attacks that target compromised remote monitoring and management (RMM) tools. Many organizations use RMM tools to remotely monitor their IT systems for vulnerabilities and manage updates. However, a compromised RMM tool can be readily exploited by threat actors. A compromise can come from stolen credentials, weak multifactor authentication (MFA) enforced from the tool, compromised administrative accounts, and vulnerable or outdated RMM software. 

Once the threat actors find a vulnerability in an RMM tool, they move quickly to execute ransomware at scale. Threat actors can execute commands, deploy backdoors or software and scripts, and immediately move laterally. Typically, the team doesn't see much dwell time or many actual indicators of compromise because the threat actors are moving so fast — they infiltrate, execute ransomware, and exit. 

The team stressed the importance of knowing who uses the RMM tools, where the tools originated, and how to minimize problems associated with installation of these tools on the system. The team recommends limiting who has access to RMM credentials, segmenting critical systems and restricting lateral administrative protocols, and maintaining protected backups that can't be accessed or administered through an RMM tool. In addition, the DFIR team suggests that organizations should have RMM compromise emergency procedures in place to assure that the IT team knows precisely what to do in the event of an attack.

Notable vulnerabilities

Nearly 10,000 newly disclosed vulnerabilities — 9,909 to be exact — were reported in July. That's the highest number of vulnerabilities ever reported and is three times the number reported in July 2025. Of those 9,909 vulnerabilities, there was known exploitation of 85 of them, impacting 61 vendors, including Microsoft, Cisco, SonicWall, and WordPress. Online proof-of-concept codes were made available for 60 of the vulnerabilities, increasing the likelihood that threat actors will exploit the products. The large number of proof-of-concept codes stems from an increased use of artificial intelligence (AI) to assist researchers in finding new vulnerabilities and writing codes that explain how to exploit the vulnerabilities. Of note, 14 of the 85 vulnerabilities were at least 5 years old, with the oldest being a 2008 vulnerability that impacts the Cisco operating system.

During Microsoft Patch Tuesday in July, 622 reported vulnerabilities were disclosed, including 62 critical vulnerabilities and two zero days, both of which were privilege elevation vulnerabilities. During Microsoft Patch Tuesday in August, 415 reported vulnerabilities were addressed, which was a dip from July. Of those 415 reported vulnerabilities, there were 62 critical vulnerabilities and one zero day. The zero day was a privilege elevation vulnerability carried out by Lazarus, a North Korea-backed threat actor group. The vulnerability did not provide Lazarus with initial access. For access, the threat actor group needed to successfully chain together vulnerabilities or gain stolen credentials from a phishing attack. 

AI-enabled campaigns are on the rise, and the team provided details about a recent AI-enabled attack. For the attack, the threat actor used the Hermes agent framework, which is an open-source AI agent, and integrated it with Chinese AI company DeepSeek to select the targets, assess vulnerabilities, generate code, and make decisions. The threat actor used encrypted messaging product Telegram to allow the threat actor to communicate via texts with the automated AI workflow, integrated it with the Chinese cyberspace search engine FOFA, and directed the AI workflow to search for and retrieve any publicly available exploit code. 

The threat actor also used a manual workflow. In particular, the threat actor interacted with FOFA as the AI workflow was ongoing and used custom Python scanners to look for vulnerabilities, specifically authentication cookies. The threat actor exfiltrated memory data, made attempts to remotely execute arbitrary code, and established reverse shells on compromised systems. 

In addition, the Hermes agent identified a vulnerability on LangFlow, a platform used to develop AI workflows, and identified 84 potential targets. The agent downloaded the proof-of-concept code from GitHub and continued to make exploitation attempts until all attempts failed and the workflow exhausted all possible LangFlow exploits. From there, it pivoted to an n8n development platform, identified vulnerable instances, downloaded a different exploit from GitHub, and attempted the exploit until all attempts failed due to a configuration that the targets placed on their systems.

Overall, the exploit attempts involved "errors" made, such as reaching out to the agent via Telegram and requesting that an HTTP file server be established, and exposed some components that the threat actor used. The example shows that AI is not foolproof, but it does allow exploits to happen much faster — and without getting tired or discouraged by failure. 

Penetration testing collaboration

A cyberattack has two distinct perspectives: offensively, what the threat actors are doing within an organization's network and, defensively, what the organization is doing to protect itself. A penetration test with security operations center (SOC) collaboration during and after the penetration test, known as penetration testing collaboration, brings those two perspectives together to help an organization improve its security posture.

A penetration test shows what an attacker can do. It allows the SOC analysts to observe the cyber landscape from the attacker's perspective, identifying the exploitable paths, demonstrating the potential business impact, and helping prioritize remediations. SOC collaboration shows what defenders can see, how they can respond, and ways to improve. It allows the team to validate telemetry and alerting, assess triage and escalation, and create durable detection improvements. Penetration testing collaboration can prove if an attack technique works and if the team can detect and respond to that technique in a real incident.

The team discussed that SOC involvement in a penetration test is a choice, not a prerequisite, and explained how collaboration between the penetration test team and the SOC team can happen in three ways.

• Blind test. The SOC team is not informed about the penetration test. This test provides the most realistic assessment of detection and response. 

• Limited disclosure test. Only designated leaders know about the penetration test. This test balances realism with safety guardrails. 

• Fully coordinated test. The SOC team receives the scope and timing well in advance of the penetration test. This test works best to validate a specific process alert capability or response procedure. 

During the penetration test, the SOC team still needs to carefully manage repeated alert noise and always follow the rule to never suppress an unrelated alert. After all, a real attacker could be operating during the penetration test. The team uses four main points for alerts: validation to confirm that the alert matches the approved test scope and evidence; association to link repeated alerts to the initial case and preserve telemetry; monitoring to watch for new, unique alerts involving different assets, techniques, identities, or impacts; and escalation to treat deviations as potentially malicious until the team receives further guidance from the client.

The most valuable learning often happens after the penetration test when the team compares the penetration test timeline and the SOC timeline. The team needs to understand the observations, the alerts, how the test was handled, and what improvements can be made. The team asks questions such as: Was required telemetry available and retained? Was there enough evidence to escalate? Did logic surface activity with useful context? Was triage accurate, timely, and proportionate? And should the team tune existing logic or create a new detection? The answers to these questions help the team understand the strengths of the organization and the SOC, recognize the gaps in operation and detection, and prioritize the actions needed to reduce risk.

Not blocked by default

The detection engineering team discussed how clients can block some actions taking place in their networks or systems. The team focused on Microsoft Azure Entra products, noting that many clients do not know that certain actions are not enabled by default so a few configurations are required to block undesirable activities.

• Microsoft Teams. By default, Teams is open to allow external groups to initiate chats or join an organization's meetings, but that's not something that all organizations want. Fortunately, Teams has a few settings that allow organizations to block external chats or, at least, allow only invited contacts. External bots and assistants are allowed by default, so your organization must decide whether to allow those entities to attend or change the settings to exclude them. In addition, organizations need to know that blocking a domain does not necessarily mean the entire domain is blocked. But there is a setting in Teams where organizations can block all subdomains. Organizations need to determine whether to allow only specific domains or block all of them. The team encourages clients to reach out to Microsoft with questions.

• Device code phishing. A phishing tactic is currently trending where the threat actor sends a code to a victim, and the victim enters that code, the MFA code, and the password, unwittingly allowing the threat actor into the system as the user of the device. For most organizations, this tactic is enabled by default and cannot be turned off. However, organizations can create a conditional access policy to block device code flow and allow only documented exceptions. The team shared a link that shows organizations how to audit their devices and block devices. 

• Open authorization (OAuth) consents. This situation typically happens when using Salesforce, where a user can accept an app and, basically, be the user. The team warns that administrators joining apps to their organizations may be overly permissioning those apps, and the apps are typically open by default. The team recommends that clients disable user consent or allow it only for verified publishers and approved low-impact permissions. The team provided a link to a site that can help organizations configure OAuth consents and restrict them.

As a reminder, the team provided a list of phishing do's and don'ts often used in training. In particular, the team wanted to encourage organizations to have a phishing amnesty program in place. After all, humans make mistakes, and the top priority should be to bring any phishing incident to the attention of the IT team as quickly as possible.

About the Pondurance threat intelligence team

The Pondurance threat intelligence team consists of cybersecurity experts across our organization dedicated to providing exceptional threat intelligence research and insights to optimize the efficacy of proactive threat prevention efforts, as well as threat detection and response. By monitoring emerging cybersecurity trends and collaborating with our SOC, we provide real-time insights and actionable intelligence. Through knowledge sharing and advisory posts, we empower organizations to strengthen their cybersecurity posture and foster a more secure digital landscape.