Welcome to this week’s edition of the Threat Source newsletter. 

Howdy friends, and hello from Cisco Live U.S., here in sunny (and very hot) Las Vegas!  

An interesting quirk of being sent to one of these events is you learn to understand your limits as a person. Cisco Live is a three-day event, and it encompasses so many people, partners, workshops, CTFs (!!), and symposiums. I can confidently say that here on day three, I’ve had rarely a moment’s rest and, as they say, my dogs are barking.  

Speaking of dogs, did you know that at Cisco Live we have therapy dogs? Healing Hounds is a local Las Vegas therapy dog volunteer group, and Splunk sponsored them this year. Every two hours, the goodest boys and girls rotate in and you can stop what you are doing to immediately go give them pets. Look at these cute faces. LOOK AT THEM.

Back to limits. One thing I’ve discovered is that conferences like this can be loud. I don’t mind loud. Loud is fine. But eight hours of noise at high levels is stressful. So, I use my Apple AirPods in noise cancelling mode, and it keeps even a massive conference like CLUS to a very manageable dull roar. If you own a pair, or any earplugs, trust me. Use them. It’s not going to shut out the world, but it will give you more stamina in an environment with bright lights and loud noises.

With that much stimuli for an extended period, you must create some space for yourself. Conferences that have quiet or chill spaces, shout out to you! A place for humans to find a moment of rest in the endurance contest that is a technology convention is a wonderful thing.

So what is the vibe at CLUS? AI. All the AI. Not from a product perspective, but from an infrastructure and security perspective. How do folks plan to move and manage that much data, especially in an agentic world? It’s a hot debate, given what I’ve listened to so far. Every business is struggling with it in their own ways, and conferences like CLUS are good opportunities to put those companies in the same room and ideate on ways to process and defend in an AI world. We’re talking many hundreds of zettabytes of data daily, the kind of data pipelines the entire world runs on. At that scale, the challenge is just wild and almost incomprehensible. I’m glad I could help and be a part of those discussions.

As the summer starts, the great patchening is coming as vendors start issuing rapid patches and CVE advisories. This is the quiet before the storm, so enjoy these cute dog photos! Black Hat and DEF CON are around the corner, as well! And always find time during these fire drills to take care of yourself, and if you can, pet some dogs.

The one big thing 

Cisco Talos is expanding our Threat Hunting program to proactively track down advanced adversaries who deliberately slip past traditional detection thresholds. By combining AI-driven telemetry analysis with human expert validation, we continuously hunt for hidden threats across endpoint, network, and identity data. This hypothesis-driven approach allows us to identify complex intrusions — like a recent KongTuke command-and-control (C2) discovery — before a formal detection signature even exists. 

Why do I care? 

Most security tools operate on a simple principle: If a known-bad pattern appears, fire an alert. But as threat actors increasingly leverage AI to move faster and intentionally stay under the radar, relying solely on automated alerts leaves massive blind spots. Hypothesis-driven hunting addresses this gap by correlating weak signals across an environment, allowing defenders to piece together ambiguous anomalies and uncover sophisticated intrusions that would otherwise go unnoticed. 

So now what? 

If your team lacks the dedicated headcount for continuous hunting, Cisco Talos Threat Hunting can bridge the gap. Reach out to your Cisco account team, explore our new dedicated portal in Cisco Security Cloud Control, and read the full blog for a detailed breakdown of our recent KongTuke C2 investigation. 

Top security headlines of the week 

Global stock exchange hit by monthslong email campaign 
A threat actor got a near-continuous view into an influential finance executive's email inbox, thanks to clever use of legitimate, native Windows tools. (Dark Reading) 

One-click GitHub dev attack lets attackers steal full GitHub OAuth tokens 
The vulnerability allows attackers to install malicious VS Code extensions that steal GitHub OAuth tokens when they are passed to GitHub.dev by exploiting a message-passing mechanism between the main VS Code window and webviews. (The Hacker News) 

FBI-flagged phishing kit “Kali365” expands its reach 
Once targeting just Microsoft 365, the phishing-as-a-service platform now aims at AWS, Okta, and Russian platforms, while relying on device code phishing. (Dark Reading) 

Dozens of Red Hat packages backdoored through its official NPM channel 
Official Red Hat NPM accounts have been compromised and used to push a malicious worm that spreads from machine to machine, where it pilfers sensitive credentials in hopes of stealing yet more confidential data, researchers said. (Ars Technica) 

“HTTP/2 Bomb” exploit knocks web servers offline in seconds 
The attack potentially affects over 880,000 websites that support HTTP/2 and run default NGINX, Apache HTTPD, Microsoft IIS, Envoy, or Cloudflare Pingora configurations. (SecurityWeek) 

Can’t get enough Talos? 

Winning the cyber marathon with Tony Giandomenico 
In the high-speed world of cybersecurity, the difference between a breach and a breakthrough often comes down to endurance. Tony Giandomenico, Senior Director of Product Management with Cisco Talos, joins me to discuss Talos Threat Hunting, the challenges of leading major product launches, and the grueling discipline of Ironman triathlons. 

When synthetic logs don’t lie: Generating coherent attack stories for better detection 
Are your detection rules failing because your test data lacks the nuance of a real-world network?  In this episode of Talos Takes, Amy sits down with David Bianco to discuss why traditional synthetic data often falls short and how his new open-source project, EvidenceForge, is changing the game. 

Upcoming events where you can find Talos 

• Cisco Live U.S. (May 31 – June 4) Las Vegas, Nevada 
• Black Hat USA (Aug. 1 – 6) Las Vegas, Nevada 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: sample.exe 
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: c0ad494457dcd9e964378760fb6aca86a23622045bca851d8f3ab49ec33978fe 
MD5: bf9672ec85283fdf002d83662f0b08b7  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c0ad494457dcd9e964378760fb6aca86a23622045bca851d8f3ab49ec33978fe 
Example Filename: f_000b97.html  
Detection Name: W32.C0AD494457-95.SBX.TG 

SHA256: afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
MD5: cc4d231df34e57f59eb970353c7d9de2  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638  
Example Filename: AutoPico.exe  
Detection Name: PUA.Win.Tool.Kmsactivator:: 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe  
Detection Name: Win.Dropper.Miner::95.sbx.tg**

In the high-speed world of cybersecurity, the difference between a breach and a breakthrough often comes down to endurance. Tony Giandomenico, Senior Director of Product Management with Cisco Talos, joins me to discuss how he balances the intensity of leading major product launches with the grueling discipline of Ironman triathlons.

Beyond the technical specs and new threat hunting features, this conversation dives deep into the human side of leadership. Tony shares his hard-won lessons on the power of communication, the importance of knowing your "why," and how to navigate the complexities of a 30-year career without losing your focus.

Amy Ciminnisi: You have been in the thick of the cyber security world for a while now, and a lot of things have shifted in this field. So what has been the biggest surprise for you, and what keeps you excited about leading the charge on the product side?

Tony Giandomenico: Well, I would probably say that the biggest shift over the last six months has been the increase rate of the capabilities of these frontier models. I'm the first one not to jump on the bandwagon of this stuff, because I've been doing this for about 30 plus years or so, but I think this feels a little different. The capabilities are increasing, and I think what that means to cybersecurity is a big shift. How do we deal with all that? From the adversary side, they're actually breaking in the networks like they typically do. They're moving laterally within the environment. They're evading different types of security controls. Finding vulnerabilities, exploiting those vulnerabilities, all of that stuff.

It's also going to be supercharged on the defensive side. Of course, you don't bring a knife to a gun fight, right? You're going to use the same AI technology — you know, the same frontier models — to speed things up there as well. From the product management side, I think we're going to see the things that we would have previously seen five years down the road a lot sooner. And that's kind of that's what kind of excites me about everything — that opportunity to explore the art of possibility is a lot more at your fingertips where it wasn't necessarily before.

AC: We specifically lined this episode up with the Cisco Talos Threat Hunting launch, which you played a major role in. For people who aren't familiar, can you explain what it is?

TG: Threat hunting is where we're looking for different types of threats that are circumventing our existing security control alerts, detection mechanisms, and so on. When defenders invest in these different types of technologies that are automatically detecting alerts or threats in your environment, the challenge that they have is the sensitivity meter. If they set it to be too high, the team might get inundated with false positives, and then that particular product isn't really worth that investment because you're constantly have to investigate those. So the sensitivity meter has to find some place in the middle. That's where it gives these stealthy threat actors a place to live. So you have a combination of AI and human-in-the-loop services, where we build hypotheses to identify actors that may have actually already circumvented your security controls.

Currently, we're hunting in the endpoint telemetry side (e.g., Secure Endpoint) that we offer our customers today. With this expansion, we're expanding it out to our flagship firewall product. So we'll be hunting within Secure Firewall as well as identity, which actually includes Duo and CII, which is Cisco Identity Intelligence.

AC: How do you keep your cool and stay focused on the why behind the work when you're dealing with the intensity of a major launch?

TG: Before coming to Cisco, I had a small cybersecurity consulting company for about 10 years or so out in the Hawaiian Islands. I had the domain expertise, but I had to learn financial aspects, sales, and marketing. I also had to understand what makes people tick. I wasn't able to talk to every individual the same way to get them on board with things. So the biggest thing that I took away when I went from running my business to working in a larger organization was that when folks are in different departments, there are competing priorities and I have to influence them. I have to get them to understand and believe in the vision. So if you go in there with that mindset, knowing that it's not going to flow exactly how you envisioned, things just work out.

Want to see more? Watch the full interview, and don’t forget to subscribe to our YouTube channel for future episodes of Humans of Talos.

By Ron Scott-Adams

Most security tools operate on a simple principle: If a known-bad pattern appears, fire an alert. This works well enough for many threats, but it fails against adversaries who closely study detection thresholds and deliberately stay under them. 

Cisco Talos Threat Hunting operates on a different principle. Instead of waiting until we’re sure we can cross an alerting threshold, we start with a hypothesis about what specific adversary behavior would look like in the telemetry, and then search for it. Using both AI and human-driven processes, including pioneering hunts built from Talos’ latest threat research, we continuously search for threats that traditional detection misses.

These hunts operate at the leading edge of our intelligence, where patterns are compelling but require expert judgment to distinguish from benign activity. Talos threat analysts provide this judgement to ensure maximum fidelity for your threat landscape. 

This post covers how that works in practice.

Hypothesis-driven hunting vs. alert-driven detection 

A detection rule says, "If X happens, alert." A hunt hypothesis says, "Given this specific threat actor uses these specific techniques, what would those techniques look like in this specific telemetry source?" 

The distinction matters because it inverts the workflow. Detection requires prior knowledge encoded into a rule. Hunting requires only a plausible theory about adversary behavior and the telemetry to test it against. 

Our hypotheses come from multiple sources: active threat intelligence on adversary tradecraft, findings from Cisco Talos Incident Response engagements, and patterns observed across global telemetry from nearly 50 million sensors. When Talos sees a new technique in the wild, we can build a hunt for it before a detection signature exists.

Here are a few examples of these threat hunts:

• Python User-Agent connections to malicious ASN infrastructure. Legitimate Python HTTP requests exist in most environments, but Python calling out to hosting providers with poor reputation scores is a different signal entirely. 
• MSIEXEC User-Agent making connections to suspicious or malicious ASNs. MSIEXEC fetching remote packages is a known living-off-the-land (LOTL) technique. The user-agent string persists in firewall connection logs even when the payload itself is encrypted. 
• Domain generation algorithm (DGA) detection via AI/ML. Algorithmically generated domains have statistical properties (character distribution, entropy, n-gram frequency) that distinguish them from human-registered domains. Our models flag DNS queries that match these patterns. 
• Connections to EVILEMPIRE ASN ranges. Certain autonomous systems have a long, documented history of hosting command-and-control (C2) infrastructure. Outbound connections to these ranges warrant investigation regardless of the specific destination IP. 
• User-Agent and application outliers. Baseline what's normal for an environment, then surface what deviates. A curl binary running on a finance team's workstation at 2am is not the same signal as curl running in a CI/CD pipeline. 
• Endpoint detection and response (EDR) research findings correlated with network indicators of compromise (IOCs). When endpoint telemetry reveals a new threat, the associated network indicators become hunt targets across firewall data for all customers.

Each of these hunts runs continuously. The AI engine executes them at scale, 24 hours a day, across all enrolled customer environments. It surfaces candidates. Then a human analyst investigates.

Case study: KongTuke C2 discovery through multi-domain correlation 

The value of correlating telemetry across security domains is easiest to explain with a real example. During a recent engagement with a customer, Talos analysts identified active KongTuke C2 activity by combining firewall and endpoint data in a way that neither source could have accomplished alone. This is the kind of continual awareness we are seeking to bring to customers everywhere with Talos Threat Hunting.

What the firewall showed 

Cisco Secure Firewall telemetry recorded outbound ConnectionEvents to “144.31.221.82” on port 6060, with a URL path of /capcha9856. This pattern is consistent with a Traffic Direction System (TDS) infection, where a compromised website redirects visitors through a chain of intermediate servers before landing on a malicious payload host. 

The firewall gave us the "what" and "when" — a specific device was reaching out to known-bad infrastructure at a known time. But the firewall alone could not tell us how the connection was initiated or what happened next on the host.

What EDR added 

Pivoting to Cisco Secure Endpoint data for the same DeviceIP, we pulled the full process history around the time of the connection. The endpoint telemetry revealed:

1. A cmd.exe process spawning powershell.exe with an -EncodedCommand parameter containing a Base64-encoded payload 
2. The decoded payload executing Invoke-WebRequest to fetch a file named script.ps1, dropping it into the user's ApplicationData directory 
3. A separate curl.exe process making requests to the same C2 infrastructure the firewall had flagged 
4. Post-execution cleanup via Remove-Item, attempting to delete traces of the downloaded script

Why neither source alone was sufficient 

The firewall saw an outbound connection to a suspicious IP. That's useful, but not conclusive on its own. Hundreds of legitimate services might generate similar connection patterns. The EDR saw obfuscated PowerShell execution. That's suspicious, but without the network context confirming the destination was a known C2 server, it could be a false positive from an overzealous admin script. 

Together, they told a complete story: initial compromise via TDS redirect, payload delivery through encoded PowerShell, C2 communication confirmed by both endpoint process tree and network connection logs, and active evidence of anti-forensics (file cleanup). This is a confirmed intrusion with clear remediation steps, not an ambiguous alert requiring hours of analyst triage. 

Broader sweep 

Once we had the process hashes and file paths from EDR, we searched across the full customer environment for other hosts exhibiting the same behavior. This turned a single finding into a scoped understanding of how far the compromise had spread.

How AI and human analysts divide the work 

Talos Threat Hunting runs on a hybrid model where each component does what it's best at. 

The AI engine handles volume and persistence. It executes hundreds of hunt hypotheses continuously across all customer environments. It applies statistical models (DGA detection, behavioral baselining, anomaly scoring) to telemetry streams at a scale no analyst team could match. Its job is to reduce the search space by taking the full volume of telemetry and surfacing the subset that warrants human attention. 

Human analysts handle context and judgment. A statistical anomaly is not the same as a confirmed threat. Analysts validate findings by correlating across data sources, applying knowledge of the customer's environment, and making determinations that require understanding adversary intent. When an analyst confirms a finding, the customer receives a written notification explaining what was observed, why it matters, how it maps to known techniques (MITRE ATT&CK or equivalent), and specific remediation guidance. 

This is not "AI finds threats and humans approve them." The AI surfaces candidates from a space too large for humans to search manually. Humans then do investigative work that AI cannot always reliably perform: understanding whether a particular behavior is malicious or benign given the full operational context of that specific environment.

The feedback loop: Hunting improves detection 

Every confirmed finding is first reported to the customer, then evaluated for a second question: “Should this have been caught by automated detection?” 

If the answer is yes, that means a detection gap exists. Maybe a rule needs tuning, a sensor configuration needs adjustment, or the customer's policy allows something that creates unnecessary exposure. In each case, the finding feeds back into product improvement or customer-specific configuration recommendations.

This creates a cycle: Intelligence drives hypotheses, hypotheses drive hunts, hunts produce findings, findings improve detection, and better detection raises the bar for what qualifies as "between the alerts." The space we hunt in gets harder to exploit over time. 

What this means for your security team 

If you have a mature SOC, this covers the ground your team is not currently reaching. These hypotheses are built from global threat intelligence, executed continuously, across telemetry your analysts may not have time to proactively search. The findings are validated before they reach you, so they add signal without adding noise. 

If you are running a lean security operation, this provides a hunting capability that would otherwise require dedicated headcount, specialized tooling, and the institutional knowledge to know what "normal" looks like well enough to spot deviations. 

Either way, the output is not more alerts. It's written findings with context, mapped to adversary techniques, with clear next steps that you can act on directly. To learn more, contact your Cisco account team and explore what’s possible with Cisco Talos.  

Some products or features described may be in various stages of development and offered on a when-and-if available basis. Cisco reserves the right to change delivery timelines and will have no liability for any delays or failures to deliver.  

Welcome to this week's edition of the Threat Source newsletter. 

Recently, Martin closed his introduction with a warning: Ready or not, the time of much patching is coming. I've been chewing on that one for a while because I'm rethinking my own enrichment pipelines along these lines, and the questions Martin raised are the ones I keep running into — with one or two ideas on what practitioners can actually do about it. 

Honestly speaking, most of us are still prioritising the wrong way. CVSS has been the default for over a decade — but it only answers one question: How bad could this be in theory? It's a severity score, not a risk score. A CVSS 9.8 on something nobody is exploiting (and nobody ever will) is a very different problem from a CVSS 7.2 that's being weaponised in the wild this morning. If your patch queue is sorted purely by CVSS, you'respending finite operations capacity on hypotheticals. 

This is where EPSS (Exploit Prediction Scoring System) earns its place next to CVSS. EPSS is a probability — between 0 and 1 — that a given CVE will be exploited in the next 30 days, based on real-world signals. The two answer different questions:

CVSS tells you how bad it would be if exploited. EPSS tells you how likely it is to actually happen to you soon. Used together, a high CVSS and a high EPSS is your "drop everything" pile, while a high CVSS and a very lowEPSS can probably wait behind a medium with an EPSS of 0.7. That single change in triage logic can meaningfully shrink the patch backlog without weakening your posture. 

The second ingredient is knowing what is actually being exploited — and here, many teams default to CISA's KEV catalog. KEV is excellent, and I've quoted KEV numbers in this newsletter more times than I can count. CISA contributes as an Authorized Data Publisher (ADP) in the CVE Program, enriching records alongside the original CNA's data. That model works well, but it's also why KEV is structurally centralized, conservative in what it admits, and naturally scoped to what U.S. federal visibility surfaces. For a global practitioner — and writing this from Germany, I notice — "Is this being exploited?" deserves a broader lens. 

That broader lens is starting to take shape with GCVE (Global CVE), a decentralized approach to vulnerability identification and enrichment. Two properties matter for the surge that's coming: 

1. Speed of enrichment. Because GCVE is decentralized, enrichment data — references, affected products, exploit indicators — doesn't have to wait in a single queue. In practice, actionable context arrives meaningfully faster than the traditional NVD pipeline, which has visibly struggled with backlog over the past two years. 
2. Broader exploitation signal. Rather than a single authoritative list of what is being exploited, GCVE makes room for multiple sources of exploitation evidence to surface against the same identifier. That gives defenders outside the U.S. (and frankly, inside it too) a more complete picture than KEV alone. 

Pair that with EPSS on top of CVSS, and you end up with a triage stack that is faster, broader, and probability-informed rather than only severity. 

None of this removes the patching workload that is coming, but it does change which patches you sprint on at 2:00 a.m. and which ones can ride the normal cycle. Before the surge arrives, that's a worthwhile thing to get right.

The one big thing 

Cisco Talos released EvidenceForge, a new open-source tool designed to generate highly realistic, correlated synthetic security logs. This tool solves the chronic shortage of high-quality, labeled datasets needed to train threat hunters and validate detection logic. By using a single canonical event model and AI-assisted scenario authoring, EvidenceForge ensures causal and temporal consistency across more than 20 log formats. 

Why do I care? 

Relying on heavily scrubbed public datasets or red team engagements often leaves security teams with incomplete telemetry. While most synthetic generators spit out independent events that fail to tell a coherent story, EvidenceForge injects realistic background noise, red herrings, and proper causal sequencing into the mix. This allows your team to work with synchronized datasets that (more) accurately mimic real-world network visibility without the compliance headaches of using production data. 

So now what? 

Security teams can head over to GitHub to clone the EvidenceForge repository and use its guided conversation feature to build custom attack scenarios. Defenders can then use these newly generated datasets to build robust SOC analyst training programs, stress-test a new SIEM, and validate detection pipelines before they touch a production environment. You can find the full details and the link to the open-source repository in the blog post. 

Top security headlines of the week 

Lawmakers demand answers as CISA tries to contain data leak 
Lawmakers are demanding answers from the U.S. Cybersecurity & Infrastructure Security Agency (CISA) after a contractor intentionally published AWS GovCloud keys and a vast trove of other agency secrets on a public GitHub account. (KrebsOnSecurity) 

Over 5,500 GitHub repositories infected in “Megalodon” supply chain attack 
The campaign relies on GitHub Actions workflows containing a payload designed to steal credentials, keys, tokens, and other secrets. The workflows were injected through over 5,700 malicious commits pushed to the impacted repositories on May 18. (SecurityWeek) 

Authorities seized 800 servers of hosting company used to launch cyber attacks 
The investigation centers on a web hosting company established on Feb. 10, 2022, weeks before Russia invaded Ukraine. The infrastructure was allegedly used to support cyber attacks, disinformation campaigns, and sanctions evasion linked to Russia. (CyberSecurityNews) 

Content delivery exploit opens websites to brand hijacking 
The Underminr domain-fronting attack allows threat actors to modify web requests and leverage trusted websites to cloak malicious activity. (Dark Reading) 

Cisco’s risk-based vulnerability disclosure in the age of AI 
Cisco is adapting its vulnerability disclosure practices, focusing on increasing the visibility of detailed technical information for vulnerabilities that are critical, actively exploited, or have a higher likelihood of exploitation. (Cisco blog) 

Can’t get enough Talos? 

DICOM, Pydicom, GDCM, and Orthanc: A technical tour of what really happens in the heap 
Hospitals rely on DICOM-based PACS systems, and those systems often automatically ingest files received over the network. Our latest white paper presents a concrete case study demonstrating the creation of a heap overflow vulnerability through the exploitation of the DICOM file format. 

MediaArea heap-based buffer overflow vulnerabilities 
MediaArea produces digital media analysis open-source software, as well as support tools for file investigation. Talos discovered four vulnerabilities in MediaInfoLib, which provides a UI for technical and tag data for video and audio media files.

Breaking things to keep them safe with Philippe Laulheret 
From his memorable experiment using a green onion to bypass a biometric fingerprint reader to his experience on the frontlines of cybersecurity, Philippe shares the journey that led him to vulnerability research. 

Upcoming events where you can find Talos 

• Cisco Live U.S. (May 31 – June 4) Las Vegas, Nevada 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201** 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: sample.exe  
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: 5e6060df7e8114cb7b412260870efd1dc05979454bd907d8750c669ae6fcbcfe 
MD5: a2cf85d22a54e26794cbc7be16840bb1 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=5e6060df7e8114cb7b412260870efd1dc05979454bd907d8750c669ae6fcbcfe 
Example Filename: a2cf85d22a54e26794cbc7be16840bb1.exe  
Detection Name: W32.5E6060DF7E-100.SBX.TG 

SHA256: afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
MD5: cc4d231df34e57f59eb970353c7d9de2 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
Example Filename: AutoPico.exe 
Detection Name: PUA.Win.Tool.Kmsactivator::1201 

Over the last decade, DICOM parsing has become an active research topic. The reason is simple: DICOM is both critical and complicated. Hospitals rely on DICOM-based PACS systems, and those systems often automatically ingest files received over the network. That means malformed data could directly trigger vulnerable decoders — the holy grail of attack surfaces for those studying robustness.

This white paper presents a concrete case study demonstrating the creation of a heap overflow vulnerability through the exploitation of the DICOM file format. The objective is to show how an Orthanc server can be targeted during the image upload process, resulting in an out-of-bounds write.

DICOM, Pydicom, GDCM,
and Orthanc

A technical tour of what really happens
in the heap

Download now

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed four vulnerabilities in MediaArea MediaInfoLib library.

The vulnerabilities mentioned in this blog post have been patched by their respective vendor, in adherence to Cisco’s third-party vulnerability disclosure policy.

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.

MediaArea vulnerabilities

Discovered by Dimitrios Tatsis of Cisco Talos.

MediaArea produces digital media analysis open-source software, as well as support tools for file investigation. MediaInfoLib provides a UI for technical and tag data for video and audio media files. Talos discovered four vulnerabilities in MediaInfoLib.

TALOS-2026-2367 (CVE-2026-25104), TALOS-2026-2368 (CVE-2026-25713), TALOS-2026-2371 (CVE-2026-28764), and TALOS-2026-2374 (CVE-2026-22554) are heap-based buffer overflow vulnerabilities in various functionalities of MediaInfoLib (version(s): 26.01). All can lead to arbitrary code execution. An attacker can provide a malicious file to trigger these vulnerabilities.

Good data is hard to find... and to create

A lot of important work in security depends on having realistic log data to work with, and a lot of that work gets blocked, watered down, or quietly skipped because the data just isn’t available. The use cases come up constantly: teaching threat hunters, incident responders, and detection engineers with datasets that have known ground truth; validating that a detection fires on the right activity without drowning in false positives; and training ML models that need labeled, balanced, multi-source telemetry at scale.

These are different problems with the same root cause. You need realistic, labeled security logs and you can’t get them easily. The options are limited:

• Real production telemetry is a compliance problem. Public datasets are often so heavily anonymized they no longer resemble the original log sources. The LANL dataset and OpTC are well-known examples of data scrubbed to the point of being generic event representations rather than actual telemetry. What isn’t anonymized is stale, narrow, and over-recycled.
• You can generate data yourself using attack simulation frameworks like Atomic Red Team or MITRE Caldera, but that requires real infrastructure, is time-consuming to operate, and scales poorly when you need variety. 
• You can hire a red team, which trades complexity for money but still takes weeks and produces only the specific scenario they ran. 

Synthetic generators seem like an obvious solution and many existing ones are genuinely useful tools, but they share a common architectural limitation: They generate events independently, one format at a time, with no shared state across log sources. The result is datasets where events don’t tell a coherent story. For example, a process in Sysmon doesn’t connect to the same process in standard Windows logs, or a network logon doesn’t leave a consistent connection trace. More capable tools support attack chains and MITRE ATT&CK mapping, but even then, they generate individual events rather than simulating something that happened, with all the prerequisite and consequent evidence that real activity would produce. Realistic background noise is largely absent.

What analysts detect when they call data synthetic is the absence of a coherent causal story. The logs don’t line up because they emit each log entry independently from the others, and they are not modeling a series of connected events.

The answer: A new kind of synthetic data

EvidenceForge is a new open-source project from Cisco Talos that approaches the problem differently. It features a single canonical event model, causal ordering, realistic background noise, and AI-assisted scenario authoring. The result is a synchronized dataset across 20+ log formats (Windows, Linux, network, and endpoint detection and response [EDR] telemetry), complete with ground truth documentation and an analyst briefing.

One honest note: No purely synthetic dataset will fool a seasoned analyst in every case, but that’s okay. The goal is fidelity that’s good enough to be useful, not something that’s indistinguishable from production.

The core idea: One event, many formats 

Most synthetic log generators are a collection of independent emitters. Each one knows how to produce its own format but doesn’t share state with the others. You can see the seams the moment you cross-reference across sources. 

EvidenceForge inverts that. Every piece of evidence flows from a single canonical SecurityEvent object. That object carries a timestamp and event type, plus over 30 composable context objects populated as needed: ProcessContext (PID, parent PID, image, command line), NetworkContext (src/dst IP and port, Zeek UID, shared across Zeek, EDR, and SNORT®), AuthContext (username, LogonID, logon type, result), DnsContext and HttpContext (protocol-layer detail that fans out into the corresponding Zeek log types), and many more. Emitters read only the fields relevant to their format.

The consequence of shared contexts is that emitters cannot disagree. There is one PID, one LogonID, one timestamp, and one Zeek UID. The engine is also OS-aware: Windows hosts produce Security Events and Sysmon while Linux hosts produce syslog and bash history, each according to the OS assigned to each host in the scenario. 

All of this is driven by a scenario configuration file: a YAML document describing the environment (hosts, users, network topology) and an optional attack storyline. The engine reads that file and produces the correlated dataset. 

What the engine produces 

From a single scenario, EvidenceForge generates several correlated log formats:  

• Windows Security Events (30 event IDs covering authentication, process lifecycle, Kerberos, persistence, account management, and more) 
• Sysmon (10 event IDs) 
• EDR/XDR telemetry 
• Linux syslog 
• bash history 
• Zeek logs in JSON format 
• Snort IDS alerts 
• Firewall logs 
• Web server access logs 
• Forward HTTP proxy logs 

The exact output logs depend on a combination of the components in the simulated environment, and which log sources you may have opted to disable. 

Every attack scenario also produces two companion documents.  

• “ENVIRONMENT.md” is an analyst briefing consisting of organizational context, network layout, user roles, naming conventions — everything an analyst would need before diving into the logs, with zero information about the attack itself.  
• “GROUND_TRUTH.md” documents exactly what happened including a narrative, a timeline, and key IOCs. 

Causality, not just sequence 

Real logs are both temporally and causally ordered. Before a domain logon, there’s a Kerberos TGT, then a TGS. Before a TCP connection to a hostname, there’s a DNS query. This is the physics of how the protocols work.

EvidenceForge ships with a composable rule engine that auto-generates prerequisite events with realistic timing offsets so that each event sits exactly where an analyst would expect to pivot to it: 

• A logon in the scenario expands to the Kerberos exchange that made it possible. 
• A connection to a named host gets the DNS resolution inserted beforehand. 
• A privileged admin command generates downstream audit events. 

Network visibility is a first-class concept 

Most synthetic generators are too visible, meaning that every connection gets a log, regardless of whether a sensor would have seen it. Real networks don’t work that way. Traffic between hosts on the same VLAN may never cross a SPAN port. East-west traffic in a segmented network may be invisible to perimeter sensors. A TAP at the internet edge sees outbound traffic but nothing internal. 

EvidenceForge lets you declare sensor placement in the scenario: SPAN or TAP, monitored segments, and direction. The engine determines which connections each sensor could realistically observe and only emits network logs where they’d actually appear. If your environment has a monitoring gap, the generated data has that same gap, which is exactly the kind of thing analysts need to learn to reason about.

AI co-develops the story; a script generates the evidence 

The hard part of realistic synthetic data is scenario design, not generation. Describing a coherent attack lifecycle with the right tactics, techniques, and procedures (TTPs); realistic sequencing; and plausible actor behavior requires research and protocol knowledge most people don’t carry in their heads.

EvidenceForge addresses this with Claude/Codex skills. You bring intent (an attack type, an environment, a training objective), the AI brings research and technical scaffolding (a guided interview, MITRE ATT&CK TTP research), and together you collaboratively develop the attack narrative, resulting in a validated YAML scenario file.

The YAML is version-controllable, shareable, and editable. Once it exists, generation is entirely deterministic: a Python script reads the config and produces all the correlated log evidence.

This separation is the optimal balance of what each technology is good at. AI excels in narrative coherence, TTP research, and protocol knowledge. A deterministic script excels at the thousands of cross-referenced field values, causal prerequisite chains, and inter-format consistency checks that make up a realistic dataset. This would overwhelm even a capable LLM at scale, and hallucinated field values or subtle inconsistencies would undermine the whole point.

A typical scenario costs pennies in API calls to co-develop, and the data generates in seconds or minutes rather than the hours or days an LLM-based approach would require. EvidenceForge also produces identical output every run because randomness is seeded. Built-in validation checks the scenario for schema correctness and cross-reference integrity before generation runs, and the AI can automatically fix most errors it finds.

Making the background convincing 

Attack events are only useful if analysts have to work to find them. Noise quality matters as much as signal quality. 

EvidenceForge’s baseline engine generates several types of realistic background noise, including: 

• Legitimate lateral movement patterns (backup agents, monitoring tools, AD replication, application-to-database traffic) 
• User and application-driven network activity (web browsing, SMB file share access, RDP sessions, scheduled service polling) 
• Per-user diversified command pools, depending on user role 
• Red herrings (suspicious-looking events or patterns that are benign) 

Timing is just as important as content. Volume-level realism without burst-level texture still looks synthetic. EvidenceForge uses three complementary timing models:

• A Hawkes process for user activity, a self-exciting model where each event makes the next more likely for a short window, then decays, matching how people actually work in bursts
• A periodic envelope for large-scale structure (Monday login storms, Friday drop-off, and near-zero weekends)
• Periodic intervals plus jitter for modelling recurring automated events like scheduled tasks, background updates, and other system and service traffic 

Most timing details are exposed in the scenario or engine config files, so you can tweak them to make them as realistic as you like for your simulated environment. 

Getting started 

EvidenceForge is available on GitHub. Clone the repo and follow the install instructions in the README. 

The core experience is a guided conversation. Start the /eforge:scenario command and describe what you want. You can be as specific or as vague as you like. Bring a fully formed scenario and the AI helps translate it into a valid configuration; bring a rough idea and it asks the right questions, fills in the gaps, and makes suggestions until you have something technically coherent and satisfyingly realistic. From there, the skill leads you through validation, generation, and a brief automated data quality evaluation. You come out the other end with a complete, correlated dataset and companion documents. A full CLI is also available for scripted workflows.

What will you build? 

EvidenceForge removes the data bottleneck. The question becomes what you do with that. The following are just a few examples: 

• Build a SOC analyst training program with scenarios tailored to your environment. 
• Test detections against controlled, labeled datasets before they go near production. See whether they fire on the attack and how they behave against realistic noise.
• Generate the labeled training data your ML model needs.  
• Stress-test a new SIEM or detection pipeline against volume and variety you control. 
• Create repeatable practice exercises that can be regenerated on demand after tuning.

The scenarios themselves are shareable artifacts. A scenario developed for one team can be shared, adapted, or built on by others. The right mental model is high-fidelity training and testing data — not a production telemetry substitute — but within that framing, the use cases are broad.

Welcome to this week’s edition of the Threat Source newsletter.  

“It takes very little to govern good people. Very little. And bad people can’t be governed at all. Or if they could, I never heard of it.” ― Cormac McCarthy, No Country for Old Men 

Most of my career has been built on dichotomy: striving to be a supportive teammate while also pushing every boundary in front of me. I've often been told to “never do X, only do Y,” but I’ve invariably chosen to do X anyway (even when fraught with peril) to get to the deeper answer. For years, I was told that I should perform in certain ways — instead of in ways that made sense for my brain and way of learning. 

I wasn’t governable, but I wasn’t bad. Just ... challenging. While Sheriff Ed Tom Bell’s view of good vs. bad is compelling, maybe our careers should be defined as “acquiescent” vs. “challenging.” It’s less of an existential crisis that way. 

Over the past few years, I’ve been enjoying the mentoring aspect of my career. One of the things that I love to share with people is that being ungovernable is very challenging early in career; it’snot a favorite of middle management, but it can take you to places that you really want to be (i.e., Talos). The road is going to be longer and much bumpier than your governable cohort, but this is the long con. 

The path to Talos was long and arduous, but I've learned to make my career choices through the lens of the axiom, “If you’re the smartest person in the room, you’re in the wrong room.” It's been the only guidepost I’ve needed. I don’t know that it applies to everyone, because everyone is unique, but it absolutely helps me decide what I want to learn, what I want to dive into, who I want to surround myself with. 

The secret lies in the last comment — it's the people. If you continue to search for the smartest people in the room, you’ll find it and when you do, you’ll find that you aren’t ungovernable — rather, you’re understood. Be ungovernable (but kind) in the short term, find new ways to solve problems, think around solutions in new ways, program in different languages, and be the person in the meeting that says, “I think we should do Y instead, and here’s why.” 

I suspect that this is the same approach many of you already take in your daily roles when identifying threats vs. benign activity, choosing your pivots in hunting, or deciding the priorities in device replacement. It’s a natural direction for the intellectually curious, so be kind, but ungovernable. 

“The future of intelligence must be about search, while the future of ignorance must be about the inability to evaluate information.” ― Patricia Lockwood, No One Is Talking About This 

The one big thing 

Cisco Talos has recently discovered a commodity BadIIS malware variant fueling a thriving malware-as-a-service (MaaS) ecosystem for Chinese-speaking cybercrime groups. Identifiable by its embedded "demo.pdb" strings, this toolset boasts a multi-year development cycle complete with builder tools and persistence mechanisms. Threat actors are leveraging this robust framework to easily execute malicious search engine optimization (SEO) fraud, hijack server content, and redirect traffic to illicit sites. 

Why do I care? 

This is a highly active, commercially driven malware ecosystem. The author constantly pushes rapid updates to introduce new features and actively evade specific security vendors, making it a persistent headache for defenders. Because this BadIISvariant is sold as a commodity tool, it lowers the barrier to entry for cybercriminals, leading to widespread attacks that silently hijack server traffic without triggering obvious alarms. 

So now what? 

Defenders should actively monitor IIS environments for unauthorized traffic redirection, unexpected reverse proxying, or sudden spikes in "503 Service Unavailable" errors. Threat hunting efforts should also target the distinct "demo.pdb" strings and associated Chinese-language folder paths within IIS binaries. Ensure your endpoint detection solutions are updated to catch these reactive evasion tactics, and read the full blog for complete coverage and indicators of compromise (IOCs). 

Top security headlines of the week 

CISA exposes secrets, credentials in “private” repo 
A researcher discovered a public GitHub repository belonging to CISA that contained 844MB of sensitive data, including plain-text passwords, authentication tokens, and other secrets. (Dark Reading) 

NYC Health + Hospitals says hackers stole medical data and fingerprints, affecting at least 1.8 million people 
The breach is particularly sensitive because hackers stole biometric information, including fingerprints and palm prints, which affected individuals have for life and cannot replace. (TechCrunch) 

Bug bounty businesses bombarded with AI slop 
Companies that pay hackers to find flaws in their software are being inundated with low-quality (often false) reports generated by AI, forcing some to suspend the programs altogether. (Ars Technica) 

Four OpenClaw flaws enable data theft, privilege escalation, and persistence 
The vulnerabilities, collectively dubbed Claw Chain, can permit an attacker to establish a foothold, expose sensitive data, and plant backdoors. (The Hacker News) 

New NGINX vulnerability allows remote attackers to trigger malicious code 
A new vulnerability in NGINX JavaScript (njs) allows unauthenticated remote attackers to trigger a heap‑based buffer overflow that can lead to denial‑of‑service and, in some conditions, remote code execution in the NGINX worker process. (Cyber Security News) 

Can’t get enough Talos? 

TP-Link, Photoshop, OpenVPN, Norton VPN vulnerabilities 
Talos’ Vulnerability Discovery & Research team recently disclosed eight vulnerabilities in TP-Link, and one each in Adobe Photoshop, OpenVPN, and Gen Digital's Norton VPN. The vulnerabilities have been patched by their respective vendors. 

Webinar: AI found the problem. Now what? 
Experts from Talos and Cisco Security will examine how AI is changing the game for both defenders and well-resourced adversaries, and why the most persistent risks often remain rooted in unpatched legacy systems. 

Breaking things to keep them safe with Philippe Laulheret 
From his memorable experiment using a green onion to bypass a biometric fingerprint reader to his experience on the frontlines of cybersecurity, Philippe shares the journey that led him to vulnerability research. 

Upcoming events where you can find Talos 

• Cisco Live U.S. (May 31 – June 4) Las Vegas, Nevada 

Most prevalent malware files from Talos telemetry over the past week 

 SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201** 

SHA256: d87e8d9d43758ce67a8052cb2334b99cc24f9b0437ee44815f360be0b22d835a  
MD5: 362498c3e71eeaa066a67e4a3f981d1c  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=d87e8d9d43758ce67a8052cb2334b99cc24f9b0437ee44815f360be0b22d835a  
Example Filename: TunMirror.exe  
Detection Name: PUA.Win.Tool.Tunmirror::1201 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f  
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f  
Example Filename: SECOH-QAD.exe  
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: acd55c44b8b0d66d66defed85ca18082c092f048d3621da827fce593305c11fd  
MD5: 0f03f72a92aef6d63eb74e73f8ac201d  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=acd55c44b8b0d66d66defed85ca18082c092f048d3621da827fce593305c11fd  
Example Filename: KMSSS.exe  
Detection Name: PUA.Win.Tool.Hackkms::1201 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
MD5: aac3165ece2959f39ff98334618d10d9  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe  
Detection Name: W32.Injector:Gen.21ie.1201

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed eight vulnerabilities in TP-Link, and one each in Adobe Photoshop, OpenVPN, and Gen Digital's Norton VPN.

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, in adherence to Cisco’s third-party vulnerability disclosure policy, except the Norton VPN vulnerability, which was discovered in-use before a patch was available. 

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.

TP-Link vulnerabilities

Discovered by Lilith >_> of Cisco Talos.

The TP-Link Archer AX53 is a dual band gigabit Wi-Fi router. Talos has disclosed eight vulnerabilities, as follows:

TALOS-2025-2302 (CVE-2026-30814) is a stack-based buffer overflow vulnerability in the tmpServer opcode 0x436 functionality of Tp-Link AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted set of network packets can lead to arbitrary code execution. An attacker can send packets to trigger this vulnerability.

TALOS-2025-2303 (CVE-2026-30815) is an OS command injection vulnerability in the OpenVPN configuration restore script_security functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary command execution. An attacker can upload a malicious file to trigger this vulnerability.

TALOS-2025-2304 (CVE-2026-30816) is an external config control vulnerability in the OpenVPN configuration restore crt.sed functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary file reading. An attacker can upload a malicious file to trigger this vulnerability.

TALOS-2025-2305 (CVE-2026-30817) is an external config control vulnerability in the OpenVPN configuration restore route_up functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary file reading. An attacker can upload a malicious file to trigger this vulnerability.

TALOS-2025-2306 (CVE-2026-30818) is an OS command injection vulnerability exists in the dnsmasq configuration restore dhcpscript functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary command execution. An attacker can upload a malicious file to trigger this vulnerability.

TALOS-2025-2307, TALOS-2025-2308, and TALOS-2025-2309 are OS command injection vulnerabilities in the OpenVPN configuration restore client_disconnect, client_connect, and route_up functionalities of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary command execution. An attacker can upload a malicious file to trigger this vulnerability.

Photoshop vulnerabilities

Discovered by KPC of Cisco Talos.

Adobe Photoshop is a popular digital photo manipulation and illustration program with a wide array of features for personal and business use cases.

TALOS-2025-2274 (CVE-2026-34632) is a privilege escalation vulnerability in the installation process of Adobe Photoshop via the Microsoft Store. The vulnerable version of the installer is Photoshop_Set-Up.exe 2.11.0.30. A low-privilege user can replace files during the installation process, which may result in elevation of privileges.

OpenVPN vulnerabilities

Discovered by Emma Reuter of Cisco ASIG.

OpenVPN is an open source SSL VPN with remote access, site-to-site VPNs, WiFi security, enterprise load balancing, failover, and granular access control features available.

TALOS-2026-2381 (CVE-2026-35058) is a reachable assertion vulnerability in the TLS Crypt v2 Client Key Extraction functionality of OpenVPN 2.6.x and 2.8_git. A specially crafted network packet can lead to a denial of service. An attacker can send a sequence of malicious packets to trigger this vulnerability.

Gen Digital Norton VPN vulnerabilities

Discovered by KPC of Cisco Talos.

Gen Digital's Norton VPN client is a proprietary tool for private proxy network information exchange. 

TALOS-2025-2276 (CVE-2025-58074) is a privilege escalation vulnerability in the installation process of Norton VPN via the Microsoft Store. A low-privilege user can replace files during the installation process, which may result in deletion of arbitrary files, possibly leading to elevation of privileges.

Mystery BadIIS containing “demo.pdb” 

Since 2024, Talos has investigated numerous attacks across the Asia-Pacific region (along with a few in South Africa, Europe and North America) that utilize a specific variant of BadIIS characterized by "demo.pdb" strings. While multiple security vendors are tracking the global spread of these variants, Talos' observed tactics, techniques, and procedures (TTPs) show notable divergences from those documented by other vendors like Trend Micro, Ahnlab, VNPT, and Elastic. Consequently, it is difficult to attribute these attacks to a single threat actor. However, we assess with moderate confidence that the "demo.pdb" BadIIS variant is a commodity tool utilized by multiple Chinese-speaking cybercrime groups. 

Insights from embedded PDB strings 

Although the core functionality of this BadIIS variant is largely limited to SEO fraud, content injection, and proxy‑based traffic manipulation, our investigation pivoted toward the malware’s embedded PDB strings. The consistent PDB path pattern offers much more intelligence value than the generic “demo.pdb” filename. The combination of a stable “Administrator\Desktop” build environment, Chinese-language folder names, and date-based versioning creates a highly reliable fingerprint for tracking and clustering this BadIIS version toolset. Beyond reinforcing our assessment that this is a commodity IIS malware family, the PDB paths enabled attribution to a possible customer name alias “x神” (“xshen”). Furthermore, the PDB artifacts reveal the existence of customized builds, some explicitly tailored to:

• Bypass specific antivirus products, such as Norton 
• Perform site‑wide hijacking 
• Redirect users conditionally based on browser language or environment

Prompted by these initial discoveries, Talos expanded our threat hunting efforts to identify similar PDB strings associated with this author with high confidence. The PDB paths extracted from these BadIIS variants reveal a sustained, multi-year development effort spanning from at least September 2021 to January 2026. By analyzing the developer's folder naming conventions, we can accurately map the malware's evolutionary trajectory, feature branching, and commercialization model.

Timeline and iterative maintenance 

Talos observed that the earliest explicit timestamp in the PDB paths is Sept. 30, 2021, indicating that the development of this specific toolset began on or before this date. The naming conventions observed in folders such as “dll0217”, “dll0301”, and “dll0315” (likely representing February 17, March 1, and March 15) demonstrate periods of rapid, sprint-like updates. Additionally, the “dll-no503” directory is particularly notable; it likely represents a troubleshooting build designed to resolve an issue where the malware caused IIS to throw "503 Service Unavailable" errors, which would otherwise alert server administrators to the infection. Finally, the latest observed compilation date, “dll20260106” (Jan. 6, 2026), confirms that this toolset remains actively maintained and deployed in the wild as of early 2026.

Feature branching and evasion tactics 

Talos also observed that the folder “兼容百度浏览器+劫持robots.txt” (“Compatible with Baidu browser + hijacking robots.txt”) explicitly confirms the malware's role in malicious SEO campaigns, specifically targeting the Chinese search engine ecosystem. Furthermore, the “2024-05-05-tcp" branch indicates a shift or enhancement in how the malware handles network traffic, potentially introducing custom proxying or SEO fraud communication protocols over raw TCP. Additionally, the inclusion of “过诺顿” (”bypass Norton”) in the build paths highlights a reactive development cycle, demonstrating that the author actively modifies the code to evade specific security vendor detections.

Below are the PDB strings Talos collected:

• C:\Users\Administrator\Desktop\2021-09-30\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\iis\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0217\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0217\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0301\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0301\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0315\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll0315\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll-no503\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll-no503\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\兼容百度浏览器+劫持robots.txt\x64\Release\demo.pdb  
  (translation: “compatible with Baidu browser + hijacking robots.txt”) 
• C:\Users\Administrator\Desktop\2023-10-10\dll\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2023-10-10\dll\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2023-11-02\dll\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2023-11-02\dll\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2024-05-05-tcp\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2024-05-05-tcp\Release\demo.pdb 
• C:\Users\Administrator\Desktop\J3\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll(cur)\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll(cur)\x64\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2024-05-05-tcp(过诺顿)xshen\Release\demo.pdb  
  (translation: “bypass Norton”) 
• C:\Users\Administrator\Desktop\2024-05-05-tcp(过诺顿)xshen\x64\Release\demo.pdb  
  (translation: “bypass Norton”) 
• C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\Release\demo.pdb  
  (translation: “xshen custom site hijacking: redirect based on browser language)” 
• C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\x64\Release\demo.pdb  
  (translation: “xshen custom site hijacking: redirect based on browser language”) 
• C:\Users\Administrator\Desktop\dll20260106\Release\demo.pdb 
• C:\Users\Administrator\Desktop\dll20260106\x64\Release\demo.pdb

Builder architecture and BadIIS generation 

During our research into these BadIIS campaigns, Talos discovered a builder tool specifically designed for this malware variant. The threat actor utilizes this utility to generate configuration files, JavaScript redirectors, and PHP backlink scripts, as well as to inject custom parameters directly into the BadIIS malware. Figure 3 shows a screenshot of the builder's interface.

The observed builder is labeled as “version 1.0,” with an estimated original release year of 2021. However, the application header and compilation timestamp indicate that this specific artifact is an updated build compiled on August 22, 2022. The interface fields and configurable settings perfectly align with known BadIIS capabilities, which can be categorized into four primary functions: 

• Traffic redirection: The builder allows threat actors to input target URLs, typically JavaScript-based redirectors, designed to be injected into the victim's browser. This feature forcibly redirects legitimate user traffic to spam infrastructure, such as illegal gambling, adult content, or other malicious websites. 
• Reverse proxy: This feature manipulates how the compromised server interacts with search engine crawlers. When a crawler visits specific hidden URLs, the BadIIS malware acts as a reverse proxy, silently fetching illicit content from the threat actor's command-and-control (C2) backend and serving it to the crawler for indexing. Furthermore, the builder includes a toggle to enable this reverse proxy behavior globally, intercepting crawlers even if they do not visit the designated hidden URLs.
• Content hijacking: The builder includes a site hijacking function capable of replacing the compromised website's original content for both normal users and search engine crawlers. Threat actors can configure the hijacking rate (percentage of traffic affected), toggle whether the homepage is explicitly targeted, and supply a remote URL to dynamically fetch malicious title, description, and keyword (TDK) metadata. 
• Internal and backlinks setting: The final component configures the injection of internal links and external backlinks. Internal links force search engines to discover and index the spam pages hosted directly on the compromised server. Meanwhile, external backlinks siphon the compromised server's Domain Authority, passing that high reputation onto external illicit websites to artificially inflate their search engine rankings.

Furthermore, operating this builder is not a simple, single-click process. Prior to generating the final payloads, the threat actor must stage unconfigured 32-bit and 64-bit BadIIS binaries within the same directory as the builder. Upon initiating the build process, the builder generates a “config.txt” file based on the threat actor’s configured parameters.

It then attempts to authenticate with the C2 server by checking for the specific response string "lwxat". Although the builder does not enforce this validation step — continuing the payload generation process regardless of whether the authentication succeeds or fails — this specific network behavior is highly valuable. Notably, this unique authentication mechanism serves as a critical pivot point, enabling us to identify and attribute other tools developed by the same author.

The final step of the build process involves obfuscating the C2 server address using a single-byte XOR operation with the key 0x3. Once encoded, the builder embeds these addresses, along with all other configured parameters, directly into the final BadIIS malware under the output folder. This configured and output files are illustrated in Figure 7.

Advancement of the builder architecture 

Talos has been tracking multiple cybercrime groups, including those detailed in our previous reports on DragonRank and UAT-8099, that utilize various BadIIS variants to turn global web servers into compromised assets for search engine manipulation. The BadIIS variants deployed by those two groups primarily relied on hardcoded C2 infrastructure and statically compiled payloads to spread. However, the variant characterized by the "demo.pdb" strings represents a significant departure from these previous iterations.

Based on the recovered builder and PDB strings, Talos assesses with moderate confidence that this "demo.pdb" variant is commodity malware, likely sold privately or shared within underground markets. The architecture of this toolset suggests a modular, MaaS business model designed for continuous monetization. The malware developer can initially sell a basic version of BadIIS alongside the builder tool. If a threat actor later requiresan advanced, updated, or customized version (such as the “Norton bypass” or “custom site hijacking: redirect based on browser language” modules), they can request a bespoke payload from the developer and use their existing builder to inject the necessary configurations. Figure 9 shows the workflow Talos assessed.

Additional tools developed by same author 

By pivoting on the previously identified PDB strings and the authentication mechanism, Talos discovered that this author has developed a suite of additional tools designed to facilitate the installation of BadIIS on target machines. The observed PDB strings are listed below, followed by a detailed analysis of the differences between these tools and their respective capabilities.

• D:\vc\dll封装进exe\x64\Release\moduleinit.pdb  
  (translation: “DLL packaged into EXE”) 
• C:\Users\Administrator\Desktop\2024-05-28\install\x64\Release\install.pdb 
• C:\Users\Administrator\Desktop\install\x64\Release\install.pdb 
• C:\vc\service\Release\service.pdb 
• C:\vc\service\x64\Release\service.pdb 
• C:\Users\Administrator\Desktop\service\Release\service.pdb 
• C:\Users\Administrator\Desktop\bao\svchost\x64\Release\service.pdb 
• C:\Users\Administrator\Desktop\2024-05-26\svchost\x64\Release\service.pdb 
• C:\Users\Administrator\Desktop\x神的自安装服务\svchost\x64\Release\service.pdb
  (translation: “xshen self-installation service”)

Early service‑based installer 

Talos identified an additional tool that we assess with high confidence is linked to the same author. Upon execution, the tool verifies that it is running as a Windows service named “Winlogin.” If this condition is met, it initiates a two-stage C2 communication process. First, it connects to a primary C2 server for authentication. During this phase, the malware validates the connection by checking if the server's response matches the specific string "lwxat".

Once authenticated, it connects to a secondary C2 server to download and execute additional malicious payloads on the target machine. Furthermore, the malware uses double Base64 encoding to obfuscate the addresses of both C2 servers.

Configuration‑driven service installer 

Talos observed another service-based tool that dynamically locates and reads an external configuration file to deploy BadIIS onto target machines. This component serves the same operational purpose as the installation batch scripts traditionally observed in earlier BadIIS campaigns. Upon execution, the malware identifies its own absolute path and searches its current directory for a file named “config.txt”. This configuration file uses an XML-like syntax, employing custom tags such as “<globalModules>”, “<name>”, “<path>”, and “<cmd>”. The tool employs a custom parsing routine to segment the file based on these tags, extracting string arrays that dictate its subsequent actions. Using this extracted data, the malware dynamically assembles command-line instructions by iterating through the parsed modules and replacing placeholders like “{name}” and “{path}” with randomized DLL paths and command snippets.

During this assembly phase, the tool specifically prepares commands for both 32-bit and 64-bit BadIIS (e.g., appending “32.dll” /y and “64.dll” /y). These fully-formed commands are then executed, likely via cmd.exe /c, using a function designed to capture the command output.

Authentication and configuration‑driven unified tool 

The threat actor continues to update this tool, recently merging two distinct capabilities into a single binary. The malware still impersonates the Winlogin system service for registration and persistence, but it now utilizes a higher volume of command-line executions to successfully install the BadIIS payload. Notably, these command lines closely resemble the syntax used in earlier BadIIS batch scripts. To evade detection by security products, the tool obfuscates its command lines and parameters using a custom Base64 encoding algorithm. A list of the encoded strings and their decoded counterparts is provided below.

Based on the decoded strings and the tool's code structure, we can categorize the functionality of this upgraded tool into three primary areas. The first group of strings focuses on file discovery, searching for “module.txt”, “.dll”, and “.config” files. The “.config” and “.dll” searches serve the same purpose as in previous versions, targeting IIS configuration files and the BadIIS malware, respectively. The “module.txt” file likely acts as a staging file to temporarily store the IIS modules list before committing changes to the active configuration. Furthermore, this phase targets the “<globalModules>” and “<modules>” sections to register the malicious DLL at the server level. The second group handles payload registration; the tool utilizes specific XML nodes to inject its payloads into the IIS configuration, dynamically replacing placeholders (e.g., “{name32}” and “{path64}”) with actual values. Finally, the third group is responsible for locating the primary BadIIS DLL and establishing its backup location to ensure persistence. However, prior to executing its primary functions, the tool sends a request to the C2 server for authentication. The validation process remains identical to previous versions; the tool verifies the connection by checking if the server's response matches the specific string "lwxat".

Latest two‑stage installation toolset 

Talos observed that the latest version of the service installation tool is now separated into two distinct files. The workflow is shown in Figure 15.

The first file acts as the primary installer and begins by authenticating with the C2 server. Following successful authentication, it searches for the BadIIS malware, copies the payloads to specific primary and backup directories, and registers them within the IIS server module list to ensure persistence. Subsequently, it drops a secondary malware component, installing it as a Windows service. During our research, Talos observed this secondary malware impersonating legitimate services such as FaxService or AudiosService. Additionally, we recovered customization parameters and execution logs associated with this installer, which provided deeper insights into its overall capabilities.

The commands and parameters embedded in the install are also encoded. Below is a list of the encoded strings and their decoded counterparts.

The secondary malware component functions similarly to the previously described service tool. However, recognizing that security operations centers (SOCs) or antivirus products can easily quarantine or delete the primary BadIIS malware, the author has implemented a robust persistence mechanism. The installer now copies the BadIIS malware not only to the active directory used for hooking IIS requests and responses but also to a hidden backup location. This ensures that the malicious BadIIS is automatically restored and launched every time the compromised IIS server is restarted. The table below provides a list of the encoded strings and their decoded counterparts.

Module initialization dropper 

Alongside the service-based tools, Talos identified another utility that shares the same C2 authentication mechanism, custom Base64 encoding algorithm, and similar code structure. However, rather than operating as a persistent service, this tool functions primarily as a dropper designed to install the BadIIS malware onto the target IIS server. The embedded PDB string (“D:\vc\dll封装进exe\x64\Release\moduleinit.pdb”, which translates to "DLL packaged into EXE") explicitly confirms its purpose: packaging malicious DLL payloads within a standalone executable. The BadIIS are found in the resource and named as “IIS32” and “IIS64” (see Figure 17).

The drop location for this BadIIS malware is identical to the one used by the installation script previously documented by Trend Micro.

"lwxat": BadIIS author identification 

Through detailed analysis of numerous BadIIS samples, associated tools, and builder artifacts, Talos assesses with moderate-to-high confidence that the string "lwxat" is the author's alias or handle. This assessment is based on the following converging evidence: 

• Builder authentication mechanism: The BadIIS builder and service tool uses the string "lwxat" as a hardcoded match string within its authentication routine, suggesting the author embedded their identity into the tool's access control logic. 
• Configuration parameter: The string "lwxat" is used as the enable function parameter within the builder's “config.txt” file, further indicating authorship attribution embedded in the tool's operational configuration. 
• User-agent signature: Most notably, several BadIIS malware samples were observed using "lwxatisme" as a custom user-agent string during HTTP communications — a strong behavioral indicator that directly ties the malware to the "lwxat" persona.

Additionally, corroborating evidence was identified through PDB path strings found within certain samples. One PDB path contained the Chinese-language string:

This suggests that the author created a dedicated development folder for a user or client named "xshen" (x神), indicating that this particular BadIIS variant was a customized build tailored specifically for “xshen's”requirements that a full-site traffic hijacking with redirection logic based on the victim's browser language settings.

Collectively, these findings presence of "lwxat" across the builder's authentication, configuration, and in-the-wild user-agent strings, combined with the PDB path referencing a customized build for “xshen” and provide converging evidence indicating that "lwxat" is the primary developer or operator behind the BadIIS malware family, potentially offering customization services to other threat actors. 

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Malware.BadIIS-10059971-0 
• Win.Malware.BadIIS-10059977-0 
• Win.Malware.BadIIS-10059984-0 
• Win.Malware.BadIIS-10059985-0

The following SNORT® rules (SIDs) detect and block this threat:  

• Snort2: 1:66400, 1:66399, 1:66398 
• Snort3: 1:66400, 1:301491 

Indicators of compromise (IOCs) 

The IOCs can also be found in our GitHub repository here.

Welcome to this week’s edition of the Threat Source newsletter. 

Many solutions have been proposed to reduce software bugs: zero-defect mandates, pair programming, formal methods, and mathematical software proofs. The reality is that software engineering is hard. Identifying and fixing bugs before they make it into production code is hard. Source code peer review and extensive unit testing have improved code quality, but bugs still get through. 

Not every bug is a vulnerability, and not every fault that appears to be a vulnerability can be usefully exploited. Nevertheless, through extensive testing and review, a skilled vulnerability researcher can still uncover faults in software that has already undergone rigorous quality assurance. However, skilled vulnerability researchers are a scarce resource and can only review so much software. 

AI is the great hope for improving software quality. Iterative improvements in AI's ability to find bugs mean that each new version of these systems is better than the last. We’re now at the point where AI, although still not as good as a skilled vulnerability researcher, can scan code to find errors at a scale and speed that human analysis cannot match. Used well, it can identify potential vulnerabilities before they reach production. 

In the long term, this is very good news. Better automated review and analysis of software is how we will improve code quality. However, in the short term, decades of technical debt and latent errors will be uncovered and will need to be addressed. To make things more complex, threat actors will have access to these same tools to search for exploitable vulnerabilities for their own ends. 

The result is likely to be a surge in patches. More vulnerabilities discovered means more fixes released, placing additional pressure on already stretched operations teams. Many of these patches will be urgent; some will address vulnerabilities that are being actively exploited. Without proper planning, the volume of fixes may outpace an organization's capacity to deploy them.

The surge of patches has yet to happen, but the first signs may already be visible. Now is an excellent time to consider how you prioritise patching, apply patches at scale, and manage systems that cannot be patched quickly — or at all. We can reflect on these questions now, and improve our processes, or we can flounder when the surge of patches arrives. Either way, ready or not, the time of much patching is coming. 

The one big thing 

In Cisco Talos’ latest blog, we outline the differences between responding to state-sponsored threat actors and handling commodity ransomware. These advanced adversaries log in using valid credentials and leverage your own trusted tools to remain invisible for months. Because their primary objectives are long-term espionage and pre-positioning rather than immediate financial gain, standard incident response playbooks are entirely inadequate.  

Why do I care? 

State-sponsored actors operate inside your trust boundary and aim to remain completely undetected. They have the patience and resources to map your infrastructure, exploit supply chain vulnerabilities, and blend their lateral movement into routine administrative tasks. If your security architecture assumes internal traffic is inherently trustworthy, these adversaries will exploit that gap to establish deep, persistent access across both IT and operational technology environments. Prematurely containing these threats can even tip off the attacker, causing you to lose critical intelligence and the chance to fully eradicate their foothold.

So now what? 

Shift to a zero trust architecture that continuously verifies access and plans for inevitable failures, starting with maximizing your visibility through centralized log aggregation and enabling Windows command-line and PowerShell script block logging. Prioritize identity management by enforcing multi-factor authentication on all administrative accounts and implementing a tiered access model. Update your incident response playbooks to specifically address living-off-the-land techniques, supply chain compromises, and the complex operational timing required for state-sponsored containment. Read the blog here for more information. 

Top security headlines of the week 

Linux bitten by second severe vulnerability in as many weeks 
The leaked exploit is deterministic, meaning it works precisely the same way each time it’s run and across different Linux distributions. It causes no crashes, making it stealthy to run. Install patches immediately. (Ars Technica) 

A DOD contractor’s API flaw exposed military course data and service member records 
The issue affected Schemata, an AI-powered virtual training platform used in military and defense settings. According to Strix, an ordinary low-privilege account was able to access data across multiple tenants. (CyberScoop) 

Fake OpenAI Privacy Filter repo hits No. 1 on Hugging Face, draws 244K downloads 
A malicious repository managed to take a spot in the platform's trending list by impersonating OpenAI's Privacy Filter open-weight model to deliver a Rust-based information stealer to Windows users. (The Hacker News) 

TanStack, Mistral AI, UiPath hit in fresh supply chain attack 
The same as in previous campaigns, the worm targets sensitive information, including developer credentials, API keys, tokens, cloud credentials and secrets, cryptocurrency wallets, and more. (SecurityWeek) 

Official CheckMarx Jenkins package compromised with infostealer 
Checkmarx warned over the weekend that a rogue version of its Jenkins Application Security Testing (AST) plugin had been published on the Jenkins Marketplace. (BleepingComputer) 

Can’t get enough Talos? 

Breaking things to keep them safe with Philippe Laulheret 
From his memorable experiment using a green onion to bypass a biometric fingerprint reader to his experience on the frontlines of cybersecurity, Philippe shares the journey that led him to vulnerability research. 

Inside the SOC: AI-powered DNS defense against ransomware 
Learn how Cisco Talos' advanced AI-driven detection, including domain generation algorithm (DGA) analysis, integrates within Cisco Secure access to proactively identify and predict malicious domains. 

Clustering and reuse of phone numbers in scam emails 
Cisco Talos has recently started to collect and gather intelligence around phone numbers within emails as an additional indicator of compromise (IOC). In this blog, we discuss new insights into in-the-wild phone number reuse in scam emails.   

Upcoming events where you can find Talos 

• OffensiveCon (May 15 – 16) Berlin, Germany 
• Cisco Live U.S. (May 31 – June 4) Las Vegas, Nevada 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201** 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
MD5: aac3165ece2959f39ff98334618d10d9  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe  
Detection Name: W32.Injector:Gen.21ie.1201 

SHA256: e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba  
MD5: dbd8dbecaa80795c135137d69921fdba  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba  
Example Filename: u112417.dat  
Detection Name: W32.Variant:MalwareXgenMisc.29d4.1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
Example Filename: APQ9305.dll  
Detection Name: Auto.90B145.282358.in02

UAT-8616 in-the-wild (ITW) exploitation of CVE-2026-20182

Talos is aware of the active, in-the-wild (ITW) exploitation of CVE-2026-20182 in Cisco Catalyst SD-WAN Controller and Manager, that allows log in to the affected system as an internal, high-privileged, non-root user account. Talos clusters the exploitation of this vulnerability and subsequent post-compromise activity under UAT-8616, whom we assess is a highly sophisticated cyber threat actor. UAT-8616 previously exploited a similar vulnerability in Cisco Catalyst SD-WAN Controller, CVE-2026-20127 to gain unauthorized access to SD-WAN systems.

UAT-8616 performed similar post-compromise actions after successfully exploiting CVE-2026-20182, as was observed in the exploitation of CVE-2026-20127 by the same threat actor. UAT-8616 attempted to add SSH keys, modify NETCONF configurations, and escalate to root privileges. Our findings indicate that the infrastructure used by UAT-8616 to carry out exploitation and post-compromise activities also overlaps with the Operational Relay Box (ORB) networks that Talos monitors closely.

Customers are strongly advised to follow the guidance and recommendations published in Cisco's Security Advisory on CVE-2026-20182. Customer support is also available by initiating a TAC request.  Please refer to the Recommendations and Detection Guidance section for additional coverage information. We also recommend referring to Rapid7’s disclosure on CVE-2026-20182 for additional details.

In-the-wild (ITW) exploitation of CVE-2026-20133, CVE-2026-20122, and CVE-2026-20128

Talos is also aware of the widespread in-the-wild active exploitation of three vulnerabilities in unpatched Cisco Catalyst SD-WAN Manager infrastructure (CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122) that, when chained together, can allow a remote unauthenticated attacker to gain access to the device. Cisco released software updates and a security advisory addressing these vulnerabilities in February 2026. Following the public release of proof-of-concept code exploiting these vulnerabilities by ZeroZenX Labs in March, we observed the exploitation of the unpatched systems from March to April 2026.

Talos has observed several other threat clusters, separate from UAT-8616, leveraging publicly available proof-of-concept exploit code to deploy webshells to affected systems. Following successful exploitation, the webshells would allow the attacker to execute bash commands on the affected system.

The vast majority of observed exploitation attempts involved the use of the ZeroZenX Labs proof-of-concept code and accompanying JavaServer Pages (JSP) shell, which we are calling “XenShell.” However, we observed several other JSP-based webshell variants, which are outlined below.

Note: The CVE referenced in the ZeroZenX Labs proof-of-concept is incorrectly attributed to CVE-2026-20127. Talos’ analysis indicates that the targeted CVEs in the proof-of-concept are in-fact CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122.

So far, Talos has observed the following clusters of malicious activity being conducted post successful exploitation of CVE-2026-20133, CVE-2026-20122, and CVE-2026-20128: Cluster #1 to Cluster #10.

Cluster 1

This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 since at least March 6, 2026. Following the exploitation of these CVEs, the threat actor deployed a variant of the Godzilla web shell under the filename “20251117022131.jsp”. This variant is associated with a publicly available GitHub project.

The following IPs were used to carry out the exploit and subsequently interact with the shell:

• 38.181.52[.]89
• 89.125.244[.]33
• 89.125.244[.]51

Cluster 2

This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122 since at least March 10, 2026. Following their exploitation, the threat actor deployed a variant of the Behinder webshell under the filename “conf.jsp”. This variant has been modified to only use Base64 for encoding, as opposed to AES encryption commonly observed in other variants.

The IP “71.80.85[.]135” was used to carry out the exploit and interact with the shell.

Cluster 3

This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122 since at least March 4, 2026. Following successful exploitation, the threat actor deployed XenShell under the name “sysv.jsp”, before returning hours later to deploy a variant of the Behinder webshell under the filename “sysinit.jsp”.

The IP “212.83.162[.]37” was used to carry out the exploit and interact with the shell.

Cluster 4

This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 since at least March 3, 2026. Following successful exploitation, the threat actor deployed a variant of the Godzilla webshell under the filename “vmurnp_ikp.jsp”.

The following IPs are attributed to this cluster:

• 38.60.214[.]92
• 65.20.67[.]134
• 104.233.156[.]1
• 194.233.100[.]40

Cluster 5

Talos observed the deployment, beginning March 13, 2026, of a malware agent compiled off the publicly available AdaptixC2 red team framework. The filename was “systemd-resolved” and the agent’s command and control (C2) is “194[.]163[.]175[.]135:4445”.

The authors have changed the default TCP banner for the sample from “AdapticC2 server” to “shadowcore”. Hosted on Contabo GmbH, this is likely a VPS. As of March 28, 2026, this C2 IP, “194[.]163[.]175[.]135” hosted:

• A Mythic C2 server on port 7443, along with a Mythic C2 server certificate with serial number: fece5b954e69b2c6a8d0a1029631a0d7
• Another AdaptixC2 server on port 31337
• An open SSH service on port 22, likely for administration of server

Cluster 6

In another cluster of activity, since at least March 5, 2026, Sliver, an open-source adversarial emulation framework (aka red-teaming implant), was deployed with the filename “CWan”. The Sliver sample’s C2 is “mtls://23.27.143[.]170:443”.

Cluster 7

In this cluster of activity, since at least March 25, 2026, an XMRig sample and its accompanying configuration file were downloaded and deployed via a shell script from the remote location “83.229.126[.]195”.

This IP, residing in Hong Kong, is also a known C2 server for Cobalt Strike.

Cluster 8

Activity observed in Cluster 8 began as early as March 10, 2026. This cluster consisted of a few key malicious tools. The first tool is KScan, an asset mapping tool, that can port scan, TCP fingerprint, capture banners for specified assets, and obtain as much port information as possible without sending more packets. It can perform automatic brute-force cracking and brute-force RDP. The tool’s filename and Go packages have been renamed to “QScan” by the authors, but it is essentially the same implementation as the open-source GitHub version.

The second tool, named “agent1”, is a Nim-based implant. It is most likely based on the open-source tools, Nimplant, but is further modified to include:

• Additional commands/capabilities, such as cd to directories; cat files; download and upload files; execute files using bash; and collect system information such as username, hostname, hwid, process listings, etc.
• C2 endpoints for communication, registration/check-ins, obtain tasks, provide results, and more:
  • /api/v1/handshake
  • /api/v1/results
  • /api/v1/payloads
  • /api/v1/exfiltrate
  • /api/v1/tasks
  • /api/v1/init
• An RSA public key to be used by the agent to communicate with the C2 hosted on “hxxp://13[.]62[.]52[.]206:5004”.

This tool was downloaded and executed post-compromise from the remote location “replit[.]dev”:

The attackers executed this command on the compromised system while connected from the source IP “79[.]135[.]105[.]208”. This is likely a ProtonVPN node.

Replit is an AI platform that facilitates building applications using AI. It is therefore likely that the backdoor was created with the help of AI to resemble Nimplant’s functionality with the additional capabilities and deviations listed above.

Cluster 9

In this cluster, since at least March 17, 2026, Talos observed the deployment of an XMRig miner and a peer-based proxying and tunneling tool.

This tool, gsocket, is a peer-based proxying and tunneling tool that allows peers to connect to each other within the Global Socket Relay Network (GSRN). GSRN allows peers to connect to each other using node IDs, which are unique 16-byte identifiers for nodes with the network.

This sample obtains the peer or C2 node to connect to by reading and Base58 decoding the accompanying “defunct[.]dat” file. The C2 peer ID is:

78 c4 a2 37 56 27 7b b7 de 20 06 76 34 d2 63 c9  

The tool is activated by placing a malicious command in the .profile file:

This decodes to:

XMRig Miner

Accompanying gsocket was a Monero miner and its scripts and configuration files. The miner is also activated via the user profile (.profile):

/tmp/moneroocean/miner.sh --config=/tmp/moneroocean/config_background.json >/dev/null 2>&1

The “miner.sh” will find all processes named XMRig, kill them, and then start its own copy of XMRig:

Cluster 10

This cluster of activity, since at least Mar 13, 2026, consisted of a credential stealer deployed along with accompanying scripts. The main script, named “loot_run.sh”, attempted to obtain:

• The admin user’s hashdump
• JSON Web Tokens (JWT) key chunks that are used for REST API authentication
• AWS credentials for vManage: AccesKeyId, SecretAccessKey and Token

Two other helper scripts were also deployed in this cluster to check if the current user could escalate to root. The scripts contained a hardcoded password and used it to execute the command su root –c id. The output is checked for the string “uid=0(root)” to verify successful escalation.

Recommendations and detection guidance

Customers are strongly advised to follow the guidance and recommendations published in Cisco's Security Advisory on CVE-2026-20182. Customer support is also available by initiating a TAC request. Talos strongly recommends that customers and partners using Cisco Catalyst SD-WAN technology follow the steps outlined in this advisory to help protect their environments. We also recommend referring to Rapid7’s disclosure on CVE-2026-20182 for additional details.

Snorts SIDs for CVE-2026-20182 are: 66482 - 66483

Please refer to the official Cisco Security Advisory on CVE-2026-20133, CVE-2026-20122, and CVE-202128 for the latest information regarding affected products, Indicators Of Compromise (IOCs), and mitigation steps.

Snort SIDs for CVE-2026-20133: 66468 - 66469

Snort SIDs for CVE-2026-20122: 66461 - 66462

Snort SIDs for CVE-2026-20128: 66468 - 66469

Snort SIDs for the threats detailed in Clusters #1 through 10 are:

• Snort2: 66200, 66201, 66202
• Snort3: 301461, 301462, 66252

ClamAV signatures for the malicious tooling associated with these clusters:

• Unix.Tool.QScanCrack-10059958
• Unix.Backdoor.NimPlant-10059957
• Unix.Tool.GSocket-10059956
• Unix.Backdoor.JSPZapLoot-10059955
• Unix.Backdoor.GopherRAT-10059941
• Unix.Backdoor.JSPZap-10059944
• Unix.Backdoor.JSPZapExcEnc-10059945
• Unix.Backdoor.GopherRAT-10059941

IOCs

IOCs for the Clusters detailed above are also available in our GitHub repository here.

Cluster 1

• 38.181.52[.]89
• 89.125.244[.]33
• 89.125.244[.]51

Cluster 2

• 71.80.85[.]135 

Cluster 3

• 212.83.162[.]37

Cluster 4

• 38.60.214[.]92
• 65.20.67[.]134
• 104.233.156[.]1
• 194.233.100[.]40

Cluster 5 - AdaptixC2

• f6f8e0d790645395188fc521039385b7c4f42fa8b426fd035f489f6cda9b5da1

Cluster 5 - AdaptixC2 C2 server

• 194[.]163[.]175[.]135:4445

Cluster 5 - AdaptixC2 C2 IP

• 194[.]163[.]175[.]135

Cluster 6 - Sliver

• 02654acfb21f83485393ba8b14bd8862b919b9ec966fc6768f6aac1338a45ee8

Cluster 6 - Sliver C2 over mTLS

• mtls[://]23.27.143[.]170:443

Cluster 6 - Sliver C2 IP

• 23.27.143[.]170

Cluster 7 - XMRig downloader script

• 0ed72d52347bfe4a78afff8a6982a64050c8fc86d8957a20eeb3e0f3f5342ed0

Cluster 7 - XMRig sample

• 96fc528ca5e7d1c2b3add5e31b8797cb126f704976c8fbeaecdbf0aa4309ad46

Cluster 7 - XMRig configuration

• 7aa88a64a527ade7d93c20faf23b54f2ee33ad9b1246cdc2f8ded2ab639affb1

Cluster 7 - XMRig remote location IP

• 83[.]229[.]126[.]195

Cluster 7 - XMRig remote URL

• hxxp://83[.]229[.]126[.]195:8081/xmrig

Cluster 7 - XMRig configuration file remote location

• hxxp://83[.]229[.]126[.]195:8081/config[.]json

Cluster 8 - Nim-based backdoor

• 0c87871642f84e09e8d3fb23ec36bf55601323e31151a7017a85dbec929cf15d

Cluster 8 - Download URL for the Nim-based backdoor

• hxxps://1a820b09-95ba-44eb-b350-417e8241b725-00-1lgwuuen9b77p[.]worf[.]replit.dev/download

Cluster 8 - Attacker controlled sub-domain hosting the Nim-based backdoor

• a820b09-95ba-44eb-b350-417e8241b725-00-1lgwuuen9b77p[.]worf[.]replit.dev

Cluster 8 - Attacker IP that downloaded the Nim-based backdoor

• 79[.]135[.]105[.]208

Cluster 8 - C2 for Nim-based backdoor

• hxxp://13[.]62[.]52[.]206:5004 

Cluster 8 - C2 IP for Nim-based backdoor

• 13[.]62[.]52[.]206

Cluster 8 - KScan – scanning tool

• 18d77c9c5bbb5b9d5bdfd366fdfcf26bad9e64c63ca865fad711bcce8e3d5a80

Cluster 8 - IP related to Nim-based backdoor and KScan

• 176[.]65[.]139[.]31

Cluster 9 - gsocket

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa

Cluster 9 - gsocket secret file

• 5bc5998161056b7c8f70c9724d8a63abc7ff8c3843b91c30cffab0899e39b7f8

Cluster 9 - IP related to Miner activity

• 47[.]104[.]248[.]7

Cluster 10 - VManage credential extractor script

• b0f51b098842cd630097b462aab0ec357e2c7824af37cca6d08165265da2c2d3

Cluster 10 - Check for root escalation

• 72f570ce97de3eaaffef33d90b0c337a153fc9690cc34ee207b557d868360060
• 17302d903baf182f94dc3be40ab1e0874dd0eb2ec5255bf9131fd53591efe925

In the latest Humans of Talos, Amy sits down with Senior Vulnerability Researcher Philippe Laulheret to demystify the world of ethical hacking. Philippe shares his unique journey from French engineering school to the front lines of cybersecurity, explaining how his lifelong love for solving puzzles helps him uncover critical security flaws before they can be exploited.

From his memorable experiment using a green onion to bypass a biometric fingerprint reader to his perspective on the reality of cybersecurity versus what we see in the movies, Philippe provides a fascinating look at the work that keeps our digital world safe.

Amy Ciminnisi: So, can you talk to me a little bit about what you do in vulnerability research?

Philippe Laulheret: I work in vulnerability research. Basically, my job is to find vulnerabilities in software, hardware, or things physically. It’s an interesting position because I usually get to choose which target I want to look at, which confuses people usually, because usually it’s a consulting role, or someone asks you to do that. But for us, we find vulnerabilities in things that we think are important. And then this way, people in different teams can write detection rules, and our customers are protected.

AC: I love that you get to kind of pick a niche and explore. How did you get into this?

PL: My deepest interest was more in reverse engineering, which is understanding how things work, software in particular. Throughout my whole life, I was really curious and really wanted to understand stuff. I guess research is an extension of that where you need to understand how the system works, and then it’s a puzzle where you need to find a way to break it. In my teenage years, I was really interested in that. I started playing Capture The Flag, which are challenges where people design exercises where there is a bug to find and exploit. It was really fun. I was doing that to stay sharp with my skills, and eventually, I was able to transition from regular development work to actual research. All those years of playing CTF really helped, even if it wasn't professional.

AC: Did you go to school initially for development work? What kind of career path led you here?

PL: Originally, as you can hear, I have a French accent. In France, we have engineering schools, which are fancy grad schools. The process is first you study very hard in math and physics, and then you go to grad school. At that time, I was convinced I wanted to do security, and I joined an electrical and computer engineering school. Somehow, in that school, I discovered an interest for different aspects of software development. I was getting interested in computer vision and other things. When I moved to the U.S. for development work instead of security work, I worked in a design studio for four years, which was really fun. I was making interactive installations. But as I said, I was playing CTF on the side to keep security pretty high in my head. Eventually, I moved to New York and joined a cybersecurity startup, and finally, I moved back to the Pacific Northwest, where I’m currently living, and I was finally able to do vulnerability research the way I wanted to.

Want to see more? Watch the full interview, and don’t forget to subscribe to our YouTube channel for future episodes of Humans of Talos.

By Jaeson Schultz 

Microsoft has released its monthly security update for May 2026, which includes 137 vulnerabilities affecting a range of products, including 31 that Microsoft marked as “critical”. 

In this month's release, Microsoft has not observed any of the included vulnerabilities being actively exploited in the wild. Out of 31 "critical" entries, 16 are remote code execution (RCE) vulnerabilities in Microsoft Windows services and applications including Microsoft Office, Microsoft Word, Windows Native WiFi Miniport Driver, Azure, Office for Android, Microsoft Dynamics 365, Windows GDI, Microsoft SharePoint, Windows Graphics Component, Windows Netlogon, and Windows DNS Client. 

CVE-2026-32161 is a critical use after free vulnerability. Concurrent execution using a shared resource with improper synchronization ('race condition') in Windows Native WiFi Miniport Driver allows an unauthorized attacker to execute code over an adjacent network. 

CVE-2026-33109 is a critical access control vulnerability in Azure Managed Instance for Apache Cassandra. Improper access control allows an authorized attacker to execute code over a network.

CVE-2026-33844 is a critical input validation vulnerability in Azure Managed Instance for Apache Cassandra. Improper input validation allows an authorized attacker to execute code over a network.

CVE-2026-35421 is a critical heap-based buffer overflow vulnerability in Windows GDI that allows an unauthorized attacker to execute code locally. For this vulnerability to be exploited, a user would need to open or otherwise process a specially crafted Enhanced Metafile (EMF) file using Microsoft Paint. This action is necessary to trigger the affected graphics functionality in the Windows component. 

CVE-2026-40358 is a critical use after free vulnerability in Microsoft Office which allows an unauthorized attacker to execute code locally. 

CVE-2026-40361 is a critical use after free vulnerability in Microsoft Word that allows an unauthorized attacker to execute code locally. 

CVE-2026-40363 is a critical heap-based buffer overflow in Microsoft Office which allows an unauthorized attacker to execute code locally. 

CVE-2026-40364 is a critical heap-based buffer overflow vulnerability. Access of resource using incompatible type ('type confusion') in Microsoft Office Word allows an unauthorized attacker to execute code locally. 

CVE-2026-40365 is a critical vulnerability affecting Microsoft SharePoint. Insufficient granularity of access control allows an authorized attacker to execute code over a network. In a network-based attack, an authenticated attacker, as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server. 

CVE-2026-40366 is a critical use after free vulnerability in Microsoft Word which allows an unauthorized attacker to execute code locally. 

CVE-2026-40367 is a critical vulnerability affecting Microsoft Word. An untrusted pointer dereference may allow an unauthorized attacker to execute code locally. 

CVE-2026-40403 is a critical heap-based buffer overflow vulnerability in Windows Win32K – GRFX that allows an authorized attacker to execute code locally. This vulnerability could lead to a contained execution environment escape. In the case of a Remote Desktop connection, an attacker with control of a Remote Desktop Server could trigger a remote code execution (RCE) on the machine when a victim connects to the attacking server with a vulnerable Remote Desktop Client. 

CVE-2026-41089 is a critical stack-based buffer overflow in Windows Netlogon that allows an unauthorized attacker to execute code over a network. An attacker could send a specially crafted network request to a Windows server that is acting as a domain controller. If successful, this could cause the Netlogon service to improperly handle the request, potentially allowing the attacker to run code on the affected system without needing to sign in or have prior access. 

CVE-2026-41096 is a critical heap-based overflow vulnerability in Windows DNS Client. An attacker could exploit this vulnerability by sending a specially crafted DNS response to a vulnerable Windows system, causing the DNS Client to incorrectly process the response and corrupt memory. In certain configurations, this could allow the attacker to run code remotely on the affected system without authentication. 

CVE-2026-42831 is a critical heap-based buffer overflow vulnerability in Office for Android that allows an unauthorized attacker to execute code locally. An attacker must send a user a malicious Office file and convince them to open it. 

CVE-2026-42898 is a critical code injection vulnerability in Microsoft Dynamics 365 (on-premises). Improper control of generation of code ('code injection') allows an authorized attacker to execute code over a network. An attacker with the required permissions could modify the saved state of a process session in Dynamics CRM and trigger the system to process that data, which could result in the server unintentionally executing malicious code.

Talos would also like to highlight the following "important" vulnerabilities as Microsoft has determined that their exploitation is "more likely:"   

• CVE-2026-33835: Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability 
• CVE-2026-33837: Windows TCP/IP Local Elevation of Privilege Vulnerability 
• CVE-2026-33840: Win32k Elevation of Privilege Vulnerability 
• CVE-2026-33841: Windows Kernel Elevation of Privilege Vulnerability 
• CVE-2026-35416: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability 
• CVE-2026-35417: Windows Win32k Elevation of Privilege Vulnerability 
• CVE-2026-40369: Windows Kernel Elevation of Privilege Vulnerability 
• CVE-2026-40397: Windows Common Log File System Driver Elevation of Privilege Vulnerability 
• CVE-2026-40398: Windows Remote Desktop Services Elevation of Privilege Vulnerability 

A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.    

In response to these vulnerability disclosures, Talos is releasing a new Snort ruleset that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Ruleset customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.    

Snort 2 rules included in this release that protect against the exploitation of many of these vulnerabilities are: 1:66438-1:66445, 1:66451-1:66460, and 1:66470-1:66476.  

The following Snort 3 rules are also available: 1:301494-1:301497, 1:301500-1:301506, 1:66472-1:66473, and 1:66476. 

Most organizations operate under the assumption that anything residing within their trust boundary is trustworthy. Software arrives from vetted vendors, employees pass background checks, cloud providers hold compliance certifications, and build pipelines produce signed artifacts. 

In practice, these assumptions are rarely scrutinized, and state-sponsored actors have constructed their operational methodology around exploiting precisely this gap. They operate inside the trust boundary, using trusted tools, holding valid credentials, and performing actions that appear entirely authorized. Conventional security architecture is not designed to identify this, and that limitation warrants acknowledgment before turning to what incident response looks like when the adversary is a state-sponsored.

Responding to a state-sponsored intrusion is fundamentally different from responding to a criminal one. The adversary is better resourced, more patient, operationally disciplined, and often in pursuit of objectives that do not trigger any alarms, such as espionage or long-term data extraction. Standard incident response playbooks, typically built around malware containment and ransomware recovery, are not adequate for this category of threat. The tooling, decision-making, legal coordination, and even the definition of what constitutes a successful response all need to be reconsidered.  

This is also the context in which zero trust architecture becomes essential. This is a fundamental reorientation from a model in which trust is assumed to one in which it is continuously verified, and in which systems are architected to handle the case where verification fails. The operative principle is not "trust nothing," which no organization can realistically operationalize, but rather "verify continuously and plan for failure." 

The following sections cover how state-sponsored actors operate across the Cyber Kill Chain, why their techniques demand different detection and response approaches, and what organizations need to have in place before, during, and after an intrusion to mount an effective response.

Same Kill Chain, different objective 

Every cyber attack, from commodity ransomware to state-sponsored espionage, follows the same fundamental sequence as the Cyber Kill Chain developed by Lockheed Martin: reconnaissance, weaponization, delivery, exploitation, installation, command and control (C2), and action on objectives. State-sponsored actors do not deviate from this sequence. They execute each phase with greater patience, greater precision, and a fundamentally different objective. 

A financially motivated attacker requires the target to know it has been compromised. The ransomware note, the leak site, and the negotiation channel are all components of the business model. A state-sponsored actor requires the opposite. Whether the objective is espionage, intellectual property theft, or pre-positioning for future disruption, success depends on the target remaining unaware. That requirement for covertness shapes every technical decision the actor makes and determines what defenders need to look for at each phase. The following are common trends that change the dimensions of defense:

• Reconnaissance: This stage tends to be deeper and more prolonged. Where a financially motivated actor might scan for exposed Remote Desktop Protocol (RDP) and move on, a state-sponsored adversary may spend weeks or months mapping an organization's personnel, technology stack, vendor relationships, and communication patterns, often entirely outside the target's perimeter through open-source intelligence (OSINT) and social engineering of adjacent organizations. This phase frequently leaves no artifacts in defender logs. State-sponsored actors also have lawful access laws in their respective countries that allow them to obtain some of this data without the target being aware that any reconnaissance is taking place.
• Initial access: State-sponsored adversaries can afford to expend significant capabilities against a single target, including zero-days or supply chain vectors that signature-based detection will not identify. More commonly, however, they use legitimate credentials obtained through spear phishing or supply chain compromise, which produce no exploit signature at all. 
• Lateral movement: This is where the covert imperative becomes most technically consequential. Rather than deploying custom malware, state-sponsored actors increasingly operate using tools already present on the target's systems, such as PowerShell, WMI, and PsExec, or they take time to observe what tools are used in the environment. If the environment uses SCCM or Puppet to manage infrastructure, the state-sponsored actor will aim to gain access to these systems and use legitimate deployment methods to compromise additional hosts. When Active Directory is queried through PowerShell, the security stack registers a routine administrative task, because it is indistinguishable from one. Extended dwell times result not from slow operational tempo, but from deliberate use of trusted tools to minimize the detection surface. 
• Persistence: State-sponsored actors operate on the assumption that any single access method may be discovered and therefore establish multiple mechanisms across different parts of the infrastructure. Think aboutscheduled tasks, modified service configurations, dormant accounts, and firmware-level implants. These footholds may remain inactive for extended periods, activating only when an intelligence requirement or geopolitical trigger demands it. 
• Action on objectives: This stage may not resemble what most teams would identify as an incident. If the objective is long-term data collection, exfiltration is structured to blend into normal traffic patterns. If the objective is pre-positioned disruption, as CISA assessed with Volt Typhoon in U.S. critical infrastructure, the actor may take no visible action during peacetime. Salt Typhoon's access to lawful intercept systems required no disruptive action to deliver intelligence value. The access itself was the operation. When that access gets used is a separate question. 
• Anti-forensics: Advanced actors clear event logs, manipulate file timestamps, operate in memory where possible, and use encrypted channels that leave minimal artifacts. Attribution may be further complicated by the deliberate planting of indicators associated with a different threat actor. 

Detection methodology does not require reinvention. The Kill Chain remains the same. It does, however, need to be calibrated for an adversary that treats every phase as an exercise in remaining invisible, that can operate using the target's own tooling, and that measures success in months of undetected access.

Attribution 

Attribution in the context of incident response deserves a straightforward treatment, because it is frequently misunderstood and its operational relevance is often overstated at the tactical level. Technical attribution, associating an intrusion with a known threat actor based on tactics, techniques, and procedures (TTPs); infrastructure; and malware characteristics is possible with varying degrees of confidence and is useful primarily for informing the threat model and anticipating likely next steps. An organization that can assess with reasonable confidence that Volt Typhoon is responsible for an intrusion can make better-informed decisions about what systems to prioritize, what persistence mechanisms to hunt for, and what the likely objectives are. Political attribution, the public or legal assignment of responsibility to a state-sponsored actor, is a government function -not a security team function - and attempting it without the intelligence resources to support it creates more risk than it resolves. 

The practical implication for incident response teams is that TTPs and infrastructure indicators should be shared with national authorities and relevant Information Sharing and Analysis Centers (ISACs), who are better positioned to place them in a broader intelligence context. Internal response should focus on containment, scope determination, and recovery regardless of whether attribution is ever formally established. 

Preparing for the long game 

Encountering a state-sponsored actor during incident response is not the time to discover logging gaps, missing baselines, or that the legal team has never discussed intelligence sharing with government agencies. The following sections cover the areas where preparation most directly determines whether detection and response are feasible. 

Logging and visibility 

Default logging configurations are not sufficient for detecting the techniques described above. 

• Windows process creation (Event ID 4688): Enable full command-line argument logging to track exact parameters used during process execution. 
• PowerShell script block logging (Event ID 4104): Capture the actual code being executed, not just the fact that PowerShell was launched. 
• Sysmon: Deploy with a configuration tuned to detect suspicious parent-child process relationships, flagging legitimate binaries used as proxies for malicious activity, both on Windows and Linux environments. 
• Strategic prioritization: If a full Sysmon rollout is impractical, prioritize critical servers, externally facing web applications, and cloud environments. Deploying Sysmon everywhere is sometimes not feasible due to very extensive and noisy logging. Prioritization is important here. 
• Centralized log aggregation: Forward all logs to a write-once, centralized location, as sophisticated actors routinely clear local event logs, permanently destroying evidence left on compromised hosts 

More broadly, visibility needs to extend across identity systems, endpoints, network infrastructure, and cloud environments. 

Endpoint telemetry alone is insufficient. State-sponsored actors operating through legitimate tools will generate process events that are difficult to distinguish from normal administrative activity, and network-layer visibility provides an independent detection plane that host-based logging cannot replace. 

• NetFlow analysis: Connection metadata without payload content is sufficient to identify unusual communication patterns, including beaconing behavior characteristic of C2 channels and lateral movement between systems that have no operational reason to communicate. 
• DNS logging: Many C2 frameworks rely on DNS for command delivery and exfiltration. A host suddenly querying domains it has never previously resolved, or generating abnormal DNS query volumes, warrantsinvestigation. 
• Encrypted traffic analysis: Machine learning models can identify C2 communication patterns in TLS sessions without breaking encryption, based on session timing, packet size distributions, and connection frequency. These capabilities do not require deep packet inspection and remain viable where privacy or compliance constraints limit payload visibility. 

Behavioral baselines 

CISA's joint advisory on living-off-the-land techniques recommends maintaining continuous baselines across network traffic, user behavior, administrative tool usage, and application activity. The emphasis on "continuously" is not incidental. A baseline established once and left unattended can generate more problems than it resolves, creating false confidence that normal has been adequately defined, when in reality theorganization has moved on. Baselines need to reflect seasonal patterns, organizational changes, infrastructure updates, and role transitions. When an administrator changes teams, their access patterns shift. When a new application is deployed, new NetFlow patterns emerge. If the baseline fails to keep pace, genuine threats blend into an outdated picture of normal, and anomaly detection becomes a source of noise rather than signal.

Statistical anomaly detection can surface the low-and-slow deviations characteristic of state-sponsored lateral movement, but tuning is an ongoing commitment, and false positive management carries a real operational cost that should not be underestimated. 

State-sponsored actors do not typically maintain access through malware alone. Once inside, they move through identity infrastructure. Privileged access management deserves explicit treatment: administrative accounts should operate on a tiered model that prevents domain administrator credentials from being exposed on workstations, and service accounts should be scoped to the minimum access their function requires. Detection logic needs to account for credential abuse patterns that do not involve any malicious tooling. Pass-the-hash and pass-the-ticket attacks use legitimate authentication protocols and will not trigger antivirus. Kerberoasting, where an attacker requests service tickets for offline cracking, is visible in Kerberos event logs but only if those logs are collected and someone is looking. Anomalous authentication patterns, such as accounts authenticating at unusual hours, from unusual sources, or against systems they have never previously accessed, are among the more reliable behavioral signals available, provided the baseline exists to contextualize them. 

Operational security (OPSEC) 

If a state-sponsored breach is confirmed, the response needs to assume the adversary can see internal communications. If they have domain admin access, they can likely read email. If they have compromised a collaboration platform, they may be able to see the incident response channel. Here are some of the common aspects that should be considered:  

• Out-of-band communications: Use encrypted channels on separate, unconnected devices to ensure investigative communications remain outside the compromised infrastructure. 
• Compartmentalization: Limit knowledge of the investigation to essential personnel only, as each additional person aware of the response is a potential vector for the adversary to detect the investigation. 
• Pre-established authority contacts: Maintain established relationships with national authorities, CERTs, and intelligence agencies before a crisis occurs, rather than identifying the right contacts during an active incident. 

Organizations should also have a pre-established relationship with national authorities, including the relevant contacts at national CERTs or intelligence agencies, rather than trying to find the right person during a crisis. 

OT and Industrial Control System (ICS) readiness 

For organizations with OT environments, the threat model extends beyond what most IT-centric IR plans address. 

The IT-OT boundary that appears on network diagrams is a logical construct, and state-sponsored actors treat it as a lateral movement path rather than a barrier. Volt Typhoon demonstrated this in concrete terms by moving from compromised IT infrastructure toward OT-adjacent systems, including those controlling water treatment plants and electrical substations. Through 2025, the group progressed from IT reconnaissance to directly interacting with OT network-connected devices and extracting sensor and operational data, representing a transition from passive espionage to what amounts to a sabotage-ready foothold, maintained quietly and positioned for activation when circumstances require it. Important aspects are:  

• Availability as a safety constraint: OT systems often cannot be taken offline for forensic imaging, as production shutdowns in energy, water, or manufacturing carry significant safety and economic consequences.Investigations must work around live systems. 
• Patching constraints: Many OT systems run legacy software that cannot be updated without vendor involvement, making virtual patching through IDS/IPS rules the only viable near-term remediation option. 
• Insufficient software-defined segmentation: IT/OT boundaries relying solely on software-defined controls are inadequate, as a compromised account with sufficient privileges can reconfigure them. 
• Hardware-enforced unidirectional gateways: Data diodes provide a physical, deterministic guarantee of network separation that cannot be overridden by a compromised account or software misconfiguration. 
• Regulatory alignment: Both CISA and the UK's NCSC recommend engineering-based, deterministic protections for OT boundaries as the baseline standard. 

Supply chain readiness 

Vendors, software dependencies, and network infrastructure are all extensions of the trust boundary, and preparing for supply chain compromise means understanding those dependencies and having response procedures ready before one of them is exploited. Some critical measures are as follows: 

• Software Bill of Materials (SBOM): Maintain an SBOM for all applications and monitor it against vulnerability databases using automated tooling, connected directly to infrastructure. 
• Vendor access inventory: Map which systems each third party can access, through what mechanisms, and at what privilege level. 
• Contractual incident notification: Enforce 24-hour disclosure clauses in vendor contracts to ensure timely notification of compromise, preventing containment windows from closing before the organization is aware. 
• Pre-authorized IR procedures: Define in advance what gets revoked, what gets isolated, and who makes the call for each vendor integration, eliminating delays while an adversary continues to operate. 
• Firmware inventory: Maintain a firmware inventory with patch status for every network device, including firewalls, routers, switches, and VPN concentrators. 
• Legacy and end-of-life (EOL) devices: Apply compensating controls such as network isolation, enhanced monitoring, and virtual patching to devices that can no longer receive patches, as they represent supply chain risk sitting inside the perimeter. 

Insider threat readiness 

In the state-sponsored context, the insider threat is not about a disgruntled employee stealing files. It is a structured intelligence operation that uses the hiring process itself as an attack vector, and preparation requires a cross-functional program spanning security, HR, legal, and finance because the indicators span all four domains. 

For planted insiders, the DPRK IT worker scheme being the most documented example, hiring verification needs to go beyond standard background checks. This includes live, multi-stage video interviews with liveness verification that current deepfake technology cannot reliably defeat (for now), digital footprint validation across independent data sources, detection of VoIP phone numbers and shared credentials across applications, and cross-referencing candidate information for the kinds of inconsistencies a fabricated identity cannot fully conceal. 

For all insider categories, behavioral baselines and data loss prevention policies should be in place before an incident occurs. Legal pre-authorization for employee monitoring is also important to establish ahead of time. Trying to build that legal framework during an active investigation will either delay the response or create legal exposure. 

Why your IR plan needs revisiting 

If your current IR plan covers malware and ransomware but typically it does not address supply chain compromise, insider threats, or living-off-the-land techniques. Most IR plans simply reflect a threat landscape that has already shifted. These gaps should be addressed through distinct playbooks, each with its own containment decision trees, evidence collection procedures, legal coordination requirements, and recovery verification steps. Each playbook should be tested through tabletop exercises built around realistic scenarios. 

One aspect of state-sponsored incident response sets it apart from criminal incident response is that the adversary may be observing the response in real time, will likely attempt to regain access after eviction, and the diplomatic, legal, and intelligence dimensions of the incident extend well beyond the security operations center. 

The containment decision in a state-sponsored incident is rarely straightforward. Treating it as a binary choice between immediate isolation and inaction understates the complexity involved. In a criminal incident, early containment is almost always the correct approach. In a state-sponsored incident, premature containment can eliminate the opportunity to understand the full scope of the adversary's access, forfeit the ability to collect intelligence on their infrastructure, and signal to the adversary that they have been detected. That signal may trigger accelerated action on their objectives before defenses are fully in place. 

The deliberate choice to monitor silently while the adversary operates introduces its own legal, ethical, and operational risks. That decision should never be made unilaterally by the SOC. It requires input from legal counsel and senior leadership, and in many cases a conversation with national authorities before it is exercised. 

The incident response plan should define in advance who holds decision authority over containment timing, what criteria govern the transition from silent monitoring to active containment, and what evidence collection must be completed before containment begins. Tabletop exercises that do not incorporate this decision point are not adequately preparing teams for the reality of state-sponsored incident response. 

Post-incident 

After containment and recovery, the work is not finished. The intelligence collected during the incident has value beyond the organization that was targeted, and sharing it through ISACs and government channels contributes to a broader defensive picture that benefits the entire sector. Internally, the after-action review should map findings to MITRE ATT&CK, not as a compliance exercise but as a structured way to identify where detection failed, where response was too slow, and where controls need to be strengthened. That review should feed directly into updated detection logic, revised access controls, and adjusted monitoring priorities. 

Threat hunting should not stop when the incident is closed. A state-sponsored actor that has been evicted will often attempt to regain access using different infrastructure or modified techniques, and sustained hunting focused on the specific actor's TTPs is the most reliable way to catch that early. Tabletop exercises should also be updated to reflect what was learned, so the next time a similar scenario plays out, the team is not relearning the same lessons under pressure. 

None of this is new guidance, but in the context of state-sponsored threats, where the adversary is persistent, well-resourced, and likely to return, these activities stop being procedural housekeeping and become direct preparation for the next intrusion. 

Where to start when you have low budget, minimal staff, and competing priorities 

Everything covered above assumes an organization can invest in logging, baselines, segmentation, supply chain controls, and dedicated IR planning in parallel. In reality, most security teams are operating under hiring freezes, flat budgets, and competing priorities, and the guidance to "do all of this" is not actionable without a sense of sequencing. The following is a pragmatic order of operations for teams that need to make meaningful progress without a step-change in resourcing. 

Start with visibility, because you cannot defend what you cannot see. Before buying new tooling, turn on what you already own. Enabling Windows command-line logging (Event ID 4688), PowerShell script block logging (Event ID 4104), and centralized log forwarding costs nothing in licensing and addresses the single largest gap most organizations have. If logs are not being collected and retained centrally, no amount of downstream investment will compensate. 

After this, prioritize identity over endpoints. State-sponsored actors move through credentials, not malware that can be easily fingerprinted, blocked, and made public through sandboxes. Enforcing multi-factor authentication (MFA) on all administrative accounts, implementing tiered admin models, and reviewing service account privileges typically delivers more risk reduction per hour invested than any endpoint initiative. These are configuration changes, not procurement cycles. 

Next, focus monitoring where the adversary has to go. If Sysmon everywhere is not feasible, then deploy it on domain controllers, identity infrastructure, externally facing systems, and critical servers. An adversary pursuing meaningful objectives will eventually touch these systems, and concentrated visibility on them is more valuable than thin visibility everywhere. 

The underlying principle is that state-sponsored readiness is not a single large investment. It is a sequence of smaller decisions where the early ones disproportionately determine whether the later ones are ever useful. Visibility and identity come first. Everything else builds on them.