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

We all knew, to some degree or another, that this summer was going to a hot mess. I don’t mean FIFA drama or record setting heat waves. I mean the slow but steady momentum that AI frontier models were accruing for vulnerability research. If you were like me, and guesstimating exactly when that shoe would drop, my money was on the middle of summer. And... well, friends, I hate to say it, but I was right.  

This July’s Patch Tuesday is an absolute whopper. There are 622 vulnerabilities being patched, with 62 being a critical severity. To put this context, this month alone has more vulnerabilities listed than all of 2018 combined. Three are zero days, two of which are being actively exploited. July is usually a quiet month historically – two years ago, it was just five patches issued in total! These are wild times, friends.  

Microsoft has said this is due their AI frontier-accelerated research. We knew that this was coming, but what I am less sure about are companies that can meet the demand of this patch flood and getting these patches out to their infrastructures. The pessimist in me knows how most IT enterprises operate: You test, review stability, and then deploy. There’s a lag there – always has been, always will be. But that system worked under a sane patching load. As surely as much as Microsoft is using frontier models to research and announce vulnerabilities, so every is every other vendor.  

Either through bug bounty programs or their own internal research, vendors are eating these bugs from a fire hose. Some are straight-up slop and just noise, but some have absolute value and need to be fixed. A giant like Microsoft has the money and resources to address this – as well they should. But for every Microsoft, there are five other companies who don’t have those resources. They’ll get bugs analyzed and patches issued, surely, but it will be on a much longer timeline.  

The trick, I think, will be identifying what is a “surge” vs. our new normal. If everything is a fire drill to patch, then nothing is a fire drill. What might just be a hot summer for patching, might turn into a 12-month fusillade of KEV and EPSS notifications, with companies already under the gun taxed even more. 

I truly don’t know how this ends, but… Find your change management and IT administrators and give then a hug. There are going to be some long days and hard questions to answer, and they’ll need all the help they can get. 

The one big thing 

Cisco Talos is disclosing a new campaign by UAT-11795, a sophisticated, financially motivated Russian-speaking adversary targeting users in the U.S. and Europe since at least June 2025. UAT-11795 uses trojanized software installers — including popular tools like Webex, Zoom, and MobaXterm — to deliver a custom Python-based remote access tool we track as "Starland RAT." This RAT acts as a gateway to deploy further malicious payloads, most notably a bespoke, in-memory PowerShell command-and-control (C2) implant known as the "WLDR agent." 

Why do I care? 

This opportunistic campaign casts a wide net across multiple victim profiles, turning a simple software download into a full-blown compromise. UAT-11795 employs highly evasive techniques, including AMSI and ETW bypasses, and uses a clever blockchain-anchored fallback mechanism to maintain persistent command and control. Once inside, attackers rapidly deploy secondary payloads like CastleStealer and Remcos RAT to siphon high-value credentials and cryptocurrency assets. 

So now what? 

Educate your users on ClickFix social engineering tactics and the dangers of unofficial software downloads. Monitor for suspicious execution of mshta.exe and unusual PowerShell activity, particularly scripts executing from memory or creating unexpected scheduled tasks. Ensure endpoint detection solutions are tuned to catch in-memory execution and AMSI tampering. Read the full blog for coverage and indicators of compromise (IOCs). 

Top security headlines of the week 

Microsoft patches record 622 flaws, including two zero-days under active attack 
Microsoft shipped its largest Patch Tuesday on record, more than triple June's previous high of around 200. (The Hacker News) 

RabbitMQ vulnerability threatens enterprise systems 
RabbitMQ is a popular open-source message broker that routes, buffers, and distributes messages, enabling asynchronous communication between applications. The security defect impacts an open management endpoint that returns the OAuth secret to anyone, without authentication. (SecurityWeek) 

Nigeria deepens cybersecurity efforts as cybercriminals see more profits 
The West African country advanced rules to force organizations to disclose cyberattacks, joining other nations in a shift to mandated transparency. (DarkReading) 

Two-click cursor exploit enables dev environment takeover 
Cursor AI, a popular AI coding tool used by more than 50,000 enterprises and 64% of the Fortune 500, can be exploited in just two clicks, allowing attackers to install permission-rich model context protocol (MCP) servers on privileged developers' machines. (DarkReading) 

Can’t get enough Talos? 

[Video] Where protection starts: Cisco Talos Intelligence Integrations 
Every day, defenders make high-consequence decisions with incomplete information. Learn how Cisco Talos Intelligence Integrations help reduce uncertainty by turning the latest threat intelligence into proactive protections across Cisco technologies. 

The Hunter's Paradox: Is it time to embrace automated threat hunting?
Humans can no longer keep up with the volume and velocity of security data on their own, but AI can't be fully trusted. David discusses the merits of both and what the future might look like.

The serpent’s tongue: Luring the Python out of its den 
Protect your development environment from rising Python supply-chain threats by understanding the package installation lifecycle and implementing these essential defensive strategies. 

ARToken: How attackers are bypassing MFA and maintaining access 
In this episode of Talos Takes, we dive deep into ARToken, a sophisticated phishing-as-a-service platform that steals credentials, bypasses MFA entirely, and leverages primary refresh tokens (PRTs) to maintain persistence in your environment long after a password reset. 

Upcoming events where you can find Talos 

• Black Hat USA (Aug. 1 – 6) Las Vegas, NV 
• DEF CON 34 (Aug. 6 – 9) Las Vegas, NV 

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: SECOH-QAD.exe 
Detection Name: Win.Tool.Procpatcher::1201 

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

SHA256: b8be9a5e0a191050f9099c11c155b436863e9bc43bc904cdb842e249679aa35a 
MD5: 0398df5a18f71efcfeef4571a2cef577 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=b8be9a5e0a191050f9099c11c155b436863e9bc43bc904cdb842e249679aa35a 
Example Filename: b8be9a5e0a191050f9099c11c155b436863e9bc43bc904cdb842e249679aa35a.js 
Detection Name: W32.B8BE9A5E0A-95.SBX.TG 

Should we let AI run our threat hunts? The debate usually splits into two camps. One says, "Yes, obviously! The sheer scale of our security telemetry is impossible for humans to deal with." The other says, "Absolutely not!  You can't trust an AI with something this important."  

The thing is, I think both are wrong, or at least incomplete.  

I've spent a long time as one of the louder voices saying that hunting is specifically a human-driven process. I created the first widely recognized definition of threat hunting back in 2015, and the version I'd have given you until very recently put a human firmly at the center of it.  

But lately I've been reconsidering the role of AI in threat hunting. So this post is, in part, me arguing with my past self.  

We're facing what I call the Hunter's Paradox: Humans can no longer keep up with the volume and velocity of security data on their own, so we need to lean on automation. But the most capable automation available, AI, is exactly the kind we can't fully trust. Both are true at once, and that tension is what I've been wrestling with for a while. We can’t resolve it cleanly by picking either side, so let's take them in turn, starting with the human element. 

Humans have a numbers problem 

So why not just keep humans in the driver's seat and call it a day? Because that math stopped working a long time ago. 

When I started in this field about 30 years ago, the conventional advice was that system administrators should read all their logs every day. It probably wasn't realistic even then, and it has been thoroughly impossible for most of my career. That's the volume problem, and it only ever compounds. There's more data than anyone can read, and there's more of it every year. 

Then there's velocity. Automated attacks already move at close to machine speed, and even human-driven intrusions routinely outpace human defenders. AI on the offensive side is making that gap wider, not narrower. 

And finally, there's capacity. This isn't the usual complaint about being under-resourced. That may still be true, but the problem is deeper than that. Volume and velocity together have pushed us to a place where it is simply not possible for humans to keep up no matter how many of us there are. If your team can still manage today, the trend line says it won't be able to for long. Even a perfectly staffed, perfectly funded team can’t beat that math forever. 

Put those three pressures together and opting out of AI isn't really an option. We can't hunt at scale without it, which lands us right back in the paradox: we need a tool we can't fully trust. 

AI doesn’t deal well with lies 

When most people think about AI and attackers, they think about prompt injection. An attacker slips instructions into something the AI will read, the AI dutifully follows them, and now your defensive tooling is working for the other team. It's real, it's a problem, and you should design with it in mind. It's also the less interesting part of the trust problem, so I'm going to acknowledge it and move on. 

The deeper issue is that attackers lie and cheat constantly, whether or not they think an AI might be watching. Deception isn't a tactic they reach for occasionally; it's the medium they operate in. Every phish, every exploit, every defense evaded is a lie that has to be believed in order to work. That has always been true, long before AI showed up. 

Pervasive deception is a real issue for AI. It’s baked into how we create LLMs: They have no concept that their training data might be deceiving them, and so when they come into the real world and deal with our dirty data, they tend to take it at face value. Not every time, maybe, but enough that their judgment is noticeably skewed even when we explicitly tell them to detect shenanigans.  Even the most accurate telemetry isn't trustworthy if it's faithfully recording a lie, and AI tends to process what it's given and believe it. 

Solving the paradox starts with a definition 

Now that we understand how deep of a hole we’re in, we can start thinking about how we might get out of it. Let’s start with the very definition of threat hunting itself. 

Back in 2015, I was the architect behind the Sqrrl threat hunting framework. I defined hunting as "any manual or machine-assisted process for identifying security incidents your automated detection systems missed." That same definition carried forward into our PEAK framework in 2023, of which I was the lead author. This has been the working definition for much of the field for a decade, though often in different words. 

That phrase right at the front, "manual or machine-assisted," is the entire reason I’ve been thinking about this so hard. What that phrase actually meant was that humans drive the hunt. Machines can assist, through analytics or machine learning or whatever tooling you had, but a person was always the one doing the hunting.  

And honestly, that was the right call at the time. But if I look back at what I was really trying to capture with that definition, the essential ingredient was never the human. It was reasoning. Humans were just the only place to get it in 2015.  

But that’s no longer the case. AI can reason now — maybe not as well as a good human analyst, but it really can reason in a way that the tools of 2015 could not. So maybe the definition should change to match what I really meant. Threat hunting might be better described as "any reasoning-driven process for identifying security incidents your automated detection systems missed."  

Reframing hunting around reasoning rather than around who's doing it feels more accurate to the original intent, and it's a lot more useful for working through the paradox. If reasoning is the point, then the question isn't whether the hunter is human or machine. It's whether there's real reasoning involved. 

If it’s really about reasoning, what does that mean? 

If we accept that AI can reason and hunting is a reasoning-driven process, then letting AI drive starts to seem… well, reasonable. 

The next big question, then, is what should that actually look like? Just saying, "AI, go find the evil!" is not a real plan. I wouldn't hand most human hunters that assignment either. Letting AI hunt responsibly takes careful planning, and more importantly it takes guardrails. At least three things matter. 

The first is tight focus. Decide deliberately which hunts you're willing to let AI drive. The procedure should be reasonably clear, but the hunt should still contain some real ambiguity. It’s the ambiguity that requires reasoning, and if there’s no reasoning at all you don't have a hunt, you have a SIEM rule. A good place to start is the pile of hunts you've run before but never quite managed to fully automate. Most teams have at least one of those sitting in a backlog. 

The second is strict guidelines. An AI agent operating in your environment is a non-human principal with credentials, and it should be treated with at least as much care as a service account: scoped access, audit trails, the ability to revoke and rotate, and never more privilege than your most junior hunter would get. You also have to decide ahead of time which actions the AI can take on its own and which it cannot. Maybe you let it quarantine a user endpoint when it's confident something is wrong. Quarantining a production server? Probably not. 

The third is graduated autonomy. Don't jump straight to full hunting independence. Let the AI act as an advisor first, then an assistant, then an operator on narrowly defined tasks, earning a little more trust at each step. Remember: Your threat actors don’t have to care about collateral damage, but you do. We’ve all heard the horror stories about AIs that deleted the production database. If your AI oversteps its boundaries, you’re more likely to actually cause incidents than to detect them. 

What stays human 

Even with all of that working well, there are still things that humans will be markedly better at for the foreseeable future, but they mostly trace back to one aspect: creativity. 

One important creative area is your hunt strategy — that is, deciding what's worth hunting for in the first place, what to prioritize, and in what order. That's running the hunt program, and it shouldn't be delegated to the AI. It can execute hunts, but it shouldn't be allowed to decide which hunts matter. 

Another important creative area is analytic novelty. Attackers are creative, so we have to be creative too, both in what we choose to look for and in how we analyze our data. The biggest payoff in hunting comes from finding the thing nobody thought to look for, and an AI's training data by definition doesn't include the attacker behavior nobody has seen yet. Lean too hard on AI to generate your hunting procedures and you'll quietly converge on well-trodden ground, leaving the truly new stuff as your blind spot.  

Put together, we almost have another guideline: Humans pick what's worth hunting and how. AI executes within those bounds. 

Where we go from here 

So, should we let AI start driving some hunts? Probably, yes, but that was never really the hard question. The hard question is how, and that's the part we have to work out together. 

I don't have all the answers, and I'm not pretending this is a finished playbook. What I'm sure of is that reframing hunting around reasoning, applying narrow focus and strict guidelines and graduated autonomy, and keeping humans firmly in charge of strategy and novelty are good things to keep in mind as we figure it out. You hunters reading this are the ones who are actually going to shape what AI hunting becomes. It’s going to be on all of us to experiment, to try things, and then to share what we’ve built — whether that's code on GitHub, a blog post, or a conference talk. The whole field gets better when we share what worked and what didn't. I'm eagerly looking forward to seeing what we come up with. 

Victimology 

According to the telemetry data, the infection is predominantly observed in the United States. There are also fewer potential impacts observed in Germany, Romania, and Venezuela, based on the assessment of the passive DNS resolution data of the C2 domains associated with this campaign. 

Talos has observed that the threat actor in this campaign has utilized trojanized installer lures from software categories including: 

The breadth of trojanized software across developer tooling, IT administration utilities, enterprise collaboration platforms, and a consumer gaming application suggests the actor is operating an opportunistic, volume-driven distribution model targeting multiple victim profiles simultaneously, rather than a single vertical. 

Threat actor infrastructure 

The threat actor in this campaign operates a distributed infrastructure across two functional categories, payload staging and persistent C2, with domain naming conventions chosen to blend into legitimate traffic categories. The staging domains, including “eorthopaedics[.]com” (likely a hijacked domain), “web-devtools[.]com” (resembles a developer tooling portal), and “zynaris[.]io” (resembles a technology start-up), with each domain serving a narrow functional role:  

• “eorthopaedics[.]com” and “sastoro[.]com” hosts the PowerShell stage chain under “/feed/” and “/alpha/” paths indicating that the actor has added the malicious routing alongside the legitimate contents. 
• “web-devtools[.]com” serves raw shellcode payloads under the paths (“/starlandfox”, “/x32remka”, “/dopfile”) and a compressed archive. 
• “zynaris[.]io” hosts the potential ClickFix-delivered HTML application (HTA) stager and trojanised installer lures. 

The C2 infrastructure is similarly distributed, with “eorthopaedics[.]com” and “sastoro[.]com” both serving hardware-bound unique identifier (HWID) encrypted envelopes over HWID parameterized URL paths with “eorthopaedics[.]com” under “/feed/” and “sastoro[.]com” under “/alpha/”. This suggests that the two domains represent parallel C2 infrastructure used for the same campaign. 

The domains “windowscreenrepairnearme[.]com” (which is also likely to be a hijacked domain) and “aipythondevs[.]com” serve as the primary C2 for the Starland Python RAT. All C2 URLs incorporate a victim hardware identifier derived from the C: drive volume serial number of the victim machine as the final URL path component, enabling the distinct C2 communication for each of the compromised victims. The actor in this campaign has also implemented C2 infrastructure resilience by using a Polygon smart contract (“0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba”), which stores an XOR-encrypted fallback C2 domain that is retrievable via a public JSON-RPC call.  

Talos discovered that the actor controls two Telegram bots, “8384531459” (“skuefq_bot”) and “7993597060” (“komandastuk_bot”), used for receiving the implant’s execution notification beacons, including messages with victim’s machine fingerprints and cryptocurrency wallet inventories. 

Talos’ research uncovered a private live Telegram channel called “stuk komanda”, controlled by the same threat actor. The stuk komanda channel was created on June 5, 2025, and has three unknown subscribers. It does not contain any chat groups and appears to be structured like a C2. The channel lists messages in the name of file names that appear to be Windows-based binaries, highlighting that the threat actor has been active since at least June 2025. 

Multi-stage attack summary 

The threat actor executed a multistage campaign that involves deploying a weaponized HTA downloader via Microsoft HTML Application Host (“mshta.exe”) on the victim's machine, likely utilizing a ClickFix technique. The execution of the HTA file results in the downloading and execution of trojanized installers bundled with a malicious Python package, which sends the implant status of the installer to an attacker-controlled Telegram bot. The NSIS script associated with the trojanized installer is designed to execute the malicious byte-compiled Python code encapsulated within the installer file. 

This initial byte-compiled Python code acts as a loader that decodes and executes an embedded Python RAT, which we are calling Starland RAT, in the victim's machine memory. Starland RAT offers a wide range of functionalities and has been specifically engineered to operate within the Windows environment. Its capabilities include defense evasion techniques, system reconnaissance, stealing browser data and cryptocurrency wallets, and a fallback C2 connection mechanism that includes a hardcoded C2 URL, as well as a Polygon Ethereum smart contract that serves as a backup. This connection allows it to interact with the smart contract through Eth_call, dynamically resolving the C2 domains. The RAT sends the reconnaissance information to the C2 to register the victim's machine and is proficient in receiving and executing intermediate payloads in several formats, including shellcode for 64-bit and 32-bit Windows environments, directly executing Windows shell commands, and downloading and executing malicious EXE, MSI, and DLL files. 

Talos has observed that the threat actor has distinct infection chains for each type of intermediate payload that Starland RAT receives from the C2. In the case of an x64 shellcode intermediate payload, it implants CastleStealer as the final payload. CastleStealer is a .NET stealer that targets credentials, cryptocurrency wallets, Telegram data, and other browser data from the victim's machine. Similarly, the x32 shellcode implants a variant of the Remcos RAT. 

Furthermore, Talos has observed that the threat actor executed a Windows shell command through Starland RAT as an intermediate payload to download and execute a PowerShell stager. This stager is associated with an undocumented PowerShell C2 framework, which we track as “WLDR C2” in alignment with the internal project designation used by the threat actor in the PowerShell scripts. The PowerShell stager is heavily obfuscated and is designed to decrypt an embedded next-stage PowerShell loader. The second-stage PowerShell loader script has capabilities for defense evasion, connects to the C2, downloads a JSON response, and processes this response to execute another embedded PowerShell payload, the WLDR agent, in the victim's machine memory. The WLDR agent is a bespoke PowerShell script that receives its C2 address through the PowerShell loader injected global variable at the time of execution. The WLDR agent employs capabilities including encrypted HTTP beaconing, comprehensive host reconnaissance, a robust reconnection protocol, and a modular task execution engine to further execute the malicious PowerShell scripts as directed by the threat actor from the WLDR C2 server. 

Initial vector 

The threat actor gains initial access to the victim machine potentially through a ClickFix social engineering technique that entices the user to execute a command, which then stealthily downloads and executes a remotely hosted weaponized HTA file. The HTA file runs an embedded VBScript that drops a Windows batch file into the user profile’s application temporary folder, which contains instructions to first download and implant a trojanized installer from the attacker-controlled staging domain onto the victim machine. 

Once the trojanized installer is executed, the batch file sends a notification beacon to an attacker-controlled Telegram bot, “8384531459”, to confirm successful execution to the threat actor. At the same time, the VBScript establishes persistence under “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the generic value “MyApp”, pointing back to “mshta.exe” to execute the remotely hosted weaponized HTA file every time the victim logs in to the machine. Talos identified a Russian-language developer comment left in the VBScript (“Добавление команды в автозапуск для текущего пользователя”), indicating that a Russian-speaking actor is conducting this campaign. 

Python loader packaged into trojanized installers 

Talos has observed that the threat actor in this campaign has weaponized software installers by utilizing the Nullsoft Scriptable Install System (NSIS). They have packaged the Python runtime executable “pythonw.exe” along with a compiled Python loader, which is disguised as a license file named “LICENSE.txt”. The threat actor has modified the NSI script file of the installer to include instructions for executing the compiled Python loader using the Python runtime executable.  

The compiled Python loader is a relatively large file obfuscated with numerous junk functions that perform random arithmetic operations and print randomly generated strings to the standard output. The actual execution logic is confined to six lines in the loader program, implementing XOR decryption using the XOR key 198 (0xC6) to decrypt the encrypted embedded payload of Starland RAT and execute it in the victim machine's memory.

Starland RAT, a Python-based RAT 

Starland is a Python-based remote access tool (RAT) with the capability to steal cryptocurrency. During its initial execution phase, the RAT resolves and declares all required Windows API function signatures through Python’s ctypes interfaces. It directly loads “kernel32.dll” using WinDLL and explicitly defines the argument types and return types for every Win32 call used later in execution, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, VirtualProtectEx, CreateProcessA, QueueUserAPC, and ResumeThread. Custom ctypes Structure subclasses are declared for SECURITY_ATTRIBUTES, STARTUPINFO, and PROCESS_INFORMATION, mirroring the definitions in the Windows SDK. This API mapping mechanism ensures that all injection and process manipulation calls later in execution are ready without further need for Windows API imports or dynamic resolution. 

Before any malicious logic executes, the RAT conducts check for anti-analysis environments. First, it compares the logged-on username of the victim machine against a hardcoded list of usernames, which includes known sandbox service accounts and aliases, including WDAGUtilityAccount. Next, the RAT verifies the victim's computer name against a list of hostnames from recognized sandbox environments, such as Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. If either check matches, the RAT's execution terminates immediately. Additionally, the RAT examines the Downloads folder for a Zone.Identifier alternate data stream on the trojanized installer file, confirming that the file was obtained via a browser download rather than being uploaded or copied directly. 

The RAT establishes persistence before any network communication with the C2 takes place. The primary mechanism involves creating a scheduled task using the PowerShell New-ScheduledTask command, with a randomized name following the pattern PythonLauncher-{3 random characters}. When executed with administrator privileges, the trigger is set to AtLogOn with RunLevel Highest, ensuring the elevated re-execution of the RAT at every user logon. Additionally, a secondary Startup folder LNK shortcut is created via the WScript.Shell COM object, placed in the user's Startup directory, targeting “pythonw.exe” with LICENSE.txt as its argument. If the RAT is not already running with elevated privileges, it also attempts UAC elevation via ShellExecuteW with the runasverb, aiming to upgrade the scheduled task to the higher-privilege logon before proceeding. 

It performs system reconnaissance, assembling the victim profile that includes the system hardware-bound unique identifier (HWID), total RAM size of the victim machine, and installed antivirus by executing the following commands: 

Get-CimInstance -Class Win32_ComputerSystemProduct.UUID  
wmic memorychip get Capacity   
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct

The RAT also conducts Active Directory reconnaissance via the PowerShell command Get-WmiObject Win32_ComputerSystem.Domain. If the victim is identified as a member of Active Directory, the RAT executes the following commands to collect information about domain structure, domain controllers, and the victim’s domain privileges: 

whoami && systeminfo && net user {USERNAME} /dom && nltest /dclist

For workgroup-only hosts, it executes the whoami /all command. The reconnaissance data collected are staged by the RAT for inclusion during the victim machine registration to the primary C2 domain hardcoded in the RAT program. It also captures a screenshot of the victim machine's desktop, saves it as a PNG in the RAT’s working directory, generates a Base64-encoded string for the PNG file in memory, stages it alongside the reconnaissance data, and deletes the PNG file from the disk. 

Additionally, it gathers the victim’s cryptocurrency assets information by enumerating the desktop cryptocurrency wallets and browser extension wallets, checking for the presence of over 40 cryptocurrency wallets. The collected data is also staged alongside the reconnaissance data and the Base64-encoded screenshot (PNG) data. The RAT consolidates all collected data into a single JSON file, XOR encrypts it with the 5-byte key “helo1”, Base64-encodes it, and sends it to the primary C2 through an HTTP POST request using the HTTP user-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36.  

If the primary C2 registration fails, the RAT enables a blockchain-anchored fallback mechanism. An eth_call is triggered via JSON-RPC to the public Polygon RPC endpoint “polygon-rpc[.]com”, targeting the smart contract “0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba” and function selector “0xc659f3b8” for the latest block. The encrypted hexadecimal string that the RAT receives from the smart contract is XOR-decrypted with the key “$m7*rYpry3” to recover a fallback domain to which the RAT sends the victim machine registration request along with the reconnaissance and screenshot data. 

Before transmitting the reconnaissance information to the C2 for the victim's machine registration, the RAT sends a notification message to the attacker-controlled Telegram bot using hardcoded credentials. The message includes the victim's public IP address sourced from “api64.ipify[.]org”, the build name, region locale, computer name presented as a “Crew ID” field, OS platform and release, processor string, and the hardcoded label  
"Windows Defender” as the protection application indicator. If any Chrome cryptocurrency wallet extensions or desktop cold wallet applications were detected during the reconnaissance phase, they were also appended to the message of the Telegram bot, providing the threat actor with visibility into the victim profile and cryptocurrency assets before the actual registration of the victim machine to the C2. 

After the RAT registers the compromised machine with the C2, it sends a GET request to the C2 server every 50 – 60 seconds. It contains minimal JSON content with two randomly named junk fields and the bot's unique identifier, encoded using the same XOR key “helo1” and then Base64 encoded. The C2 server responds with one of the four commands supported by the RAT: 

Windows shell command deploys bespoke WLDR agent C2 implant 

In the current campaign investigation, Talos discovered that the threat actor executed a curl command to download and execute additional PowerShell script payloads of the WLDR C2 framework from another C2.  

WLDR stager 

The WLDR stager PowerShell script represents the initial stage, where it establishes a loop counter and two boolean flags for execution states. Each state creates a runtime alias for PowerShell command execution, resolving .NET Base64 and byte conversion types through an obfuscated string construction mechanism. It also defines an inline decryption routine that XOR decrypts the next stage, which is the embedded encrypted WLDR downloader PowerShell script, using a dynamically computed XOR key. 

WLDR downloader  

WLDR downloader is a compact HWID-bound loader script. Upon execution, it derives a hardware identifier from the victim’s C: drive volume serial number, converts it from hexadecimal to a decimal number, and appends it to two hardcoded C2 URLs for victim-specific payload delivery and a persistent agent task channel. It then issues an HTTP GET request to the C2, and the C2 server only responds to requests whose HWID matches a pre-registered value. The C2 server response is an encrypted JSON envelope containing fields with a Base64-encoded salt, initialization vector, encrypted data, and authentication tag. 

The WLDR loader processes the JSON response by decrypting the envelope through an inline decryption routine using a derived 64-byte key from a hardcoded plaintext password “odg5t8mvssvh” and the salt received from the C2 server in the JSON response. This is followed by the decryption of the encrypted data, which is the next stage of the WLDR agent PowerShell C2 memory implant. Before executing the WLDR agent, it writes the C2 URL and the plaintext password into the global PowerShell scope, making both available for the WLDR agent as its C2 address and session encryption key for all subsequent communication with the C2. 

Bespoke WLDR C2 agent implant 

The WLDR agent is a fully featured PowerShell remote access client that operates entirely in memory. It implements encrypted C2 communications, concurrent task execution through a managed Runspace engine, and a module delivery framework that provides the threat actor with interactive remote PowerShell execution capabilities on the victim's machine. 

Upon execution, the agent initializes the server's URL to a development placeholder and immediately checks for a globally scoped URL and session encryption password that were set by the WLDR loader script. If found, it overwrites the placeholder with the C2 URL and inherits the session encryption password, while also configuring other operational parameters, including polling interval, HTTP timeout, retry counts for the C2 reconnect cycle, and the number of threads for the Runspace pool. 

Before initiating the C2 connectivity, it implements a mutex “f2j398fj239d8j23dkkskskkkkkkkkk” to prevent duplicate instances and performs a dependency check on the inherited session encryption password. If the password is not found, the agent exits its execution. The network communication is encrypted using AES-256-CBC with HMAC-SHA256 in an encryption, then Message Authentication Code (MAC) construction, with session keys derived through PBKDF2-SHA256 over a randomly generated salt at 5,000 iterations. The protocol version tag WSv1 is bound to every MAC computation, with a new random initialization vector (IV) generated for each message. 

The agent performs reconnaissance via WMI queries, gathering information on antivirus products, network adapter configurations, OS version and build, domain membership, CPU, RAM, administrative privilege status, and UAC policy. A hardware identifier is primarily derived from the C: drive volume serial number; if that fails, it queries the machine's registry for the GUID or generates a checksum of the host name, which is appended to all C2 URLs. The initial connection to the C2 is established through an HTTP POST that includes the victim machine profile, the infection identifier, protocol version 2.0.0, and the cryptographic session parameters, with a connection retry timing set to 30 seconds. All subsequent traffic is sent to C2 over HTTPS, with headers designed to mimic a Chrome browser session in version 124. 

After establishing the initial connection with the C2, the agent polls the C2 server every 10 seconds. The response from the C2 server can include either commands or tasks, with the only hardcoded command in the agent being a kill instruction that triggers instance termination, while tasks are queued for execution. 

During our research, we observed that the initial response from the C2 was the idle polling interval response, which included empty fields in both the “commands” and “tasks” arrays. 

Further analysis of the agent program disclosed that the C2 responses to the polling will contain encrypted PowerShell commands or scripts, which are decrypted using the same hardcoded password and executed through one of the two runtime engines defined in the backdoor program.  

The primary agent execution engine is a PowerShell RunspacePool supporting up to 10 concurrent threads. Each PowerShell script payload delivered by the C2 is wrapped with details of execution context and parameters as in scope variables along with event handlers on the script’s execution result of output, error,and warnings. These event handlers registered on the output, error, and warning streams are triggered synchronously as the script execution output is produced, packaging results into stream messages and forwards them to the C2 in real time without waiting for the script execution completion.  

This message streaming capability makes the WLDR agent’s Runspace engine favorable for the interactive operations such as continuous monitoring where the command output reaches the threat actor incrementally, rather than after the completion of the script execution.  

If the Runspace engine fails to initialize the payload, PowerShell script execution defaults to standard PowerShell background jobs. It injects parameters and launches the script as a background job; however, unlike the Runspace path, it collects output only after the job completes, making it suitable only for short-lived batch tasks. 

Other payloads of Starland RAT campaign 

Talos has discovered that the threat actor possesses additional malware, including CastleStealer and Remcos RAT, which can be deployed as payloads to the victim's machine via the Starland RAT. To deliver these payloads, the threat actor utilizes a custom shellcode loader for both x64 and x32 machines, encapsulating the embedded encrypted binaries of the payloads. 

The shellcode loader resolves all required Windows APIs entirely at runtime by enumerating the list of loaded modules in the OS memory, iterating through each module's export directory, and comparing a hash of each function name against stored target values. The shellcode neutralizes both the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) through two sequential bypass mechanisms. The primary technique resolves the target functions AmsiScanBuffer in “amsi.dll” and EtwEventWrite in “ntdll.dll” using runtime hash-based API resolution, then overwrites their first bytes in memory with a patch that forces AMSI to always return a clean scan result and the ETW write function to return immediately without writing the output, effectively neutralizing both interfaces. If the primary patching technique fails, the shellcode executes a fallback mechanism where it calls VirtualProtect to temporarily change the target function's memory page protection value to read-write-execute and writes the same patch bytes directly, then restores the original page protection. 

Then, it decrypts the embedded encrypted payload blob and decompresses the decrypted data using LZX decompression into a newly allocated memory region. The payload is subsequently dispatched either by the reflective PE injection technique or by .NET CLR loading through the ICorRuntimeHost COM interface for .NET binaries, or through the PowerShell Runspace for PowerShell scripts. 

Talos discovered that the threat actor can deliver CastleStealer implant through the x64 shellcode and the Remcos RAT through the x32 shellcode variant.  

CastleStealer is a .NET-based infostealer and credential harvesting implant designed to systematically extract sensitive data from compromised Windows hosts. It incorporates several anti-analysis measures, including a Russian locale exclusion check and a hardcoded build expiry timestamp, ensuring it executes only against genuine targets within a defined operational window. Its credential theft surface is broad, targeting the full Chromium browser family and Firefox through direct SQLite database access, with decryption support for both legacy DPAPI-protected credentials and the AES-GCM application bound encryption scheme. Beyond browser data, it enumerates crypto wallet browser extensions, Discord and Telegram session files, Steam account credentials, and targeted filesystem paths, transmitting all collected material over a TCP socket to the attacker-controlled infrastructure. CastleStealer’s secondary payload delivery capability allows the actor to implant further payloads through process injection technique or PowerShell script execution.  

Remcos RAT (Remote Control and Surveillance) is a commercial remote access tool originally sold as a legitimate remote administration tool. However, it has been extensively abused by a wide range of threat actors since its emergence in 2016. It provides operators with comprehensive post-exploitation capabilitiesincluding real-time keylogging, screen and webcam capture, audio recording, file management, shell command execution, and clipboard monitoring all communicated over an encrypted channel to a configurable C2 server.  

Coverage 

The following ClamAV signature detects and blocks this threat: 

Txt.Downloader.Agent-10060312-0
Html.Downloader.Agent-10060313-0
Html.Downloader.Agent-10060314-0
Py.Loader.Agent-10060315-0
Py.Loader.Agent-10060316-0
Ps1.Trojan.Agent-10060317-0
Ps1.Trojan.Agent-10060318-0
Ps1.Trojan.WLDRAgent-10060319-0
Ps1.Downloader.Agent-10060320-0
Win.Trojan.CastleStealer-10060341-0
Win.Trojan.Starland_Installer-10060342-0
Win.Malware.Starland-10060343-0
Win.Malware.Remka-10060344-0

The following Snort Rules Snort 2 and Snort 3 (SIDs) to detect and block this threat: 66787 – 66790 and 301580  

IOCs

The IOCs for this threat are also available at our GitHub repository here. 

Microsoft has released its monthly security update for July 2026, which includes 622 vulnerabilities affecting a range of products, including 57 that Microsoft marked as "critical."

Microsoft notes that two of the vulnerabilities disclosed this month have been exploited in the wild.

CVE-2026-56155 is an important-severity elevation of privilege vulnerability in Active Directory Federation Services (AD FS) caused by insufficient granularity of access control. An authorized attacker could use it to elevate privileges locally.

CVE-2026-56164 is a moderate-severity vulnerability in Microsoft SharePoint Server caused by missing authentication for a critical function. An unauthorized attacker could exploit it to perform spoofing over a network.

The 57 "critical" entries break down by vulnerability type as follows: 48 remote code execution (RCE), seven elevation of privilege (EoP), 1 spoofing and 1 security feature bypass vulnerability.

The 48 critical RCE vulnerabilities affect a range of Microsoft Windows services and applications, including Windows Media and Media Foundation, the Windows DHCP client and DHCP Server service, Microsoft Office, Word, Excel and PowerPoint, Windows GDI and GDI+, the DirectX Graphics Kernel, Microsoft SharePoint, Microsoft SQL Server, the Windows Reliable Multicast Transport Driver (RMCAST), Windows TCP/IP, the Windows Server Network driver, the Windows Print Spooler, the Windows Secure Socket Tunneling Protocol (SSTP), Windows Active Directory Domain Services, Microsoft Defender, Microsoft Copilot, Microsoft Message Queuing (MSMQ), the Remote Desktop Client, Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central (on-premises), and the Minecraft Bedrock Dedicated Server.

Eleven of the critical RCE vulnerabilities are rated "more likely" to be exploited. CVE-2026-50370 and CVE-2026-50518 are heap-based buffer overflows in the Windows DHCP Server service, exploitable by an unauthorized attacker over an adjacent network and over a network, respectively. CVE-2026-54128 is a use-after-free in the Windows DHCP client that allows an unauthorized attacker to execute code locally. CVE-2026-50327 and CVE-2026-50655 are heap-based buffer overflows in Windows Media and Windows Media Foundation. CVE-2026-54992 is a heap-based buffer overflow in the Microsoft Message Queuing Queue Manager. CVE-2026-56188 is a race condition in the Windows Server Network driver, and CVE-2026-55010 is a heap-based buffer overflow in the Minecraft Bedrock Dedicated Server that an unauthorized attacker could exploit over a network. CVE-2026-50522 and CVE-2026-58644 are deserialization vulnerabilities in Microsoft SharePoint that allow an unauthorized attacker to execute code over a network. CVE-2026-55944 is a deserialization vulnerability in Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central (on-premises) that allows an unauthorized attacker to execute code over a network.

The remaining critical RCE vulnerabilities are rated "less likely" or "unlikely" to be exploited, or were not assigned an exploitation-likelihood rating by Microsoft. Microsoft Office and its applications account for a large share: CVE-2026-50314, CVE-2026-50467, CVE-2026-55018, CVE-2026-55022, CVE-2026-55045, CVE-2026-55049, CVE-2026-55056, CVE-2026-55129 and CVE-2026-55140 are in Microsoft Office; CVE-2026-55033, CVE-2026-55127 and CVE-2026-55132 are in Microsoft Word; and CVE-2026-55043, CVE-2026-55120 and CVE-2026-55123 are in Microsoft PowerPoint. These are typically triggered by opening a specially crafted document.

The remaining critical RCE vulnerabilities affect Windows Media and Media Foundation (CVE-2026-56189, CVE-2026-57087, CVE-2026-57090, CVE-2026-57094 and CVE-2026-58542), the Windows DHCP Server service (CVE-2026-48564 and CVE-2026-56159), Windows GDI+ and GDI (CVE-2026-49796, CVE-2026-50380 and CVE-2026-54122), the DirectX Graphics Kernel (CVE-2026-50382), the Remote Desktop Client (CVE-2026-50474), Microsoft SQL Server (CVE-2026-54117 and CVE-2026-54118), the Windows Reliable Multicast Transport Driver (CVE-2026-54982 and CVE-2026-54995), Windows TCP/IP (CVE-2026-54999), the Windows Print Spooler (CVE-2026-58608), the Windows SSTP (CVE-2026-50694), Windows Active Directory Domain Services (CVE-2026-49164), Microsoft Defender (CVE-2026-55011 and CVE-2026-55012) and Microsoft Copilot (CVE-2026-48561).

The seven critical elevation of privilege vulnerabilities are CVE-2026-42982 and CVE-2026-50392 in Windows Secure Kernel Mode; CVE-2026-50444 in the Windows Server Update Service (WSUS); CVE-2026-50680 and CVE-2026-54127 in Windows Hyper-V; CVE-2026-54121 in Active Directory Certificate Services; and CVE-2026-57092 in Microsoft Windows VMSwitch.

The single critical spoofing vulnerability is CVE-2026-55008 in Microsoft Exchange Server, caused by a cross-site scripting condition. The single critical security feature bypass is CVE-2026-55040 in Microsoft SharePoint Server, caused by weak authentication. Both are rated "more likely" to be exploited.

Several of the critical entries above — including the Copilot, Azure Synapse, Azure OpenAI, Exchange Online and Entra items — affect Microsoft cloud services, for which Microsoft has not assigned an exploitation-likelihood rating.

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

·       CVE-2026-49170: Windows StateRepository API Server file Elevation of Privilege Vulnerability

·       CVE-2026-49795: Windows Kernel Elevation of Privilege Vulnerability

·       CVE-2026-49798: Windows Kernel Elevation of Privilege Vulnerability

·       CVE-2026-49805: Win32k Elevation of Privilege Vulnerability

·       CVE-2026-50297: Win32k Elevation of Privilege Vulnerability

·       CVE-2026-50325: Win32k Elevation of Privilege Vulnerability

·       CVE-2026-50329: Microsoft DWM Core Library Elevation of Privilege Vulnerability

·       CVE-2026-50332: Windows Kernel Elevation of Privilege Vulnerability

·       CVE-2026-50343: Microsoft Install Service Elevation of Privilege Vulnerability

·       CVE-2026-50351: Windows Audio Compression Manager (ACM) Elevation of Privilege Vulnerability

·       CVE-2026-50375: DirectX Graphics Kernel Elevation of Privilege Vulnerability

·       CVE-2026-50387: Windows GDI Elevation of Privilege Vulnerability

·       CVE-2026-50390: Windows Kernel Elevation of Privilege Vulnerability

·       CVE-2026-50423: Windows Kernel Elevation of Privilege Vulnerability

·       CVE-2026-50433: Windows Media Elevation of Privilege Vulnerability

·       CVE-2026-50436: Windows Kernel Elevation of Privilege Vulnerability

·       CVE-2026-50454: Windows User Interface Core Elevation of Privilege Vulnerability

·       CVE-2026-50475: Windows Kernel Information Disclosure Vulnerability

·       CVE-2026-50476: Windows Network Connections Service Elevation of Privilege Vulnerability

·       CVE-2026-50489: Win32k Elevation of Privilege Vulnerability

·       CVE-2026-50509: Wireless Wide Area Network Service (WwanSvc) Elevation of Privilege Vulnerability

·       CVE-2026-50667: Windows Common Log File System Driver Elevation of Privilege Vulnerability

·       CVE-2026-50688: Windows Win32k Elevation of Privilege Vulnerability

·       CVE-2026-54114: Windows Win32k Elevation of Privilege Vulnerability

·       CVE-2026-54986: Windows Win32k Elevation of Privilege Vulnerability

·       CVE-2026-57091: Windows File History Service Elevation of Privilege Vulnerability

·       CVE-2026-58531: Windows SMB Elevation of Privilege Vulnerability

·       CVE-2026-58536: Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability

·       CVE-2026-58596: Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability

·       CVE-2026-58631: Windows Admin Center (WAC) Remote Code Execution Vulnerability

·       CVE-2026-58633: Desktop Window Manager Elevation of Privilege Vulnerability

·       CVE-2026-58638: Windows Boot Loader Security Feature Bypass 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:66733 - 1:66743, 1:66745 - 1:66785, 1:66791 - 1:66793, 1:66800 - 1:66807

The following Snort 3 rules are also available: 1:301555 - 1:301579, 1:301581 - 1:301583

Cybersecurity has always involved elements of uncertainty. Every day, security teams are asked to make decisions with incomplete information, while attackers rely on defenders not being able to see the full picture.

What defenders haven't always had to deal with is attackers using AI to rewrite malicious commands on the fly, malware that adapts its code upon every installation, and models that can search through decades of vulnerable code and exposed interfaces to uncover new opportunities for exploitation.

While none of that changes the fundamental purpose of cybersecurity — to understand and act on what's happening in your environment — it does make that picture harder and harder to build. Is a newly registered domain part of an attack? Is that outbound connection normal? Is that user behavior unusual? 

Cisco Talos Intelligence Integrations helps answer those questions.

Across Cisco’s security and enterprise technologies, Talos’ reputation and detection integrations continuously apply the latest threat intelligence to identify and block malicious activity.

Our latest video introduces some of the Talosians behind the integrations and explains how they work.

If you'd like to learn more about the technologies behind Talos Intelligence Integrations, you'll find a more detailed overview on the Cisco Security website.

Due to the friendly nature of its syntax, extensive capabilities, and wide range of libraries, Python’s adoption by the developer community has been steadily increasing. Both the StackOverflow Developer Survey and the first party package repository PyPi’s download stats indicate rapidly growing usage, especially for data science, AI, and backend projects. Python has a very vibrant community of modules that can be easily installed using various package indexes. Unfortunately, this convenience comes with an additional burden. Malicious packages and supply chain infection are also increasingly common, as threat actors attempt to utilize these modules to infect as many victim devices as possible, abusing the very trust that the community is built upon. GitHub’s 2025 security data highlights the accelerating threat to the software supply chain, noting a 69% year-over-year increase in published malware advisories. Notably for Python developers, 17% of all reviewed advisories in the GitHub Advisory Database are now related to the Pip ecosystem, reflecting a significant targeting of Python-based environments. The threat actor group TeamPCP has also utilized software supply chain attacks, including misuse of Python modules, to compromise Microsoft’s GitHub subsidiary and carry out 20 “waves” of supply chain attacks according to Wired. 

Users often believe that for a malicious payload to be executed they need to directly interact with the infected piece of code (e.g., providing it with a sensitive input, executing its entry point, or importing it to a working project). In reality, Python packages can establish a foothold simply through installation. While analyzing these techniques in detail, we will take a deeper look at the background process of package installation for Python. This will help understand the threat landscape for Python packages, including legitimate components adversaries try to alter for their benefit.

Journey of a Python package 

The process of moving a Python package from a remote repository to a local machine involves three distinct layers. While these layers are interconnected, they provide a useful abstraction for understanding the installation process: 

• Hosting layer: Defines the location where the package is published 
• Distribution layer: Specifies the file formats supported by the package 
• Installation layer: Dictates the method of deployment for the package

Hosting packages 

Python packages can be installed from various remote repositories.  

PyPI (Python Package Index): PyPI is the official repository for Python packages. The native package manager, pip, uses PyPI by default. Package details are accessible via a JSON API at “https://pypi.org/pypi/<package-name>/json”. During installation, the PyPI frontend redirects users to “files.pythonhosted.org”, where the actual files are stored. Download URLs are derived from the distribution file name and its blake2b_256 hash. For example:

Version control systems (VCS): Projects hosted on platforms like GitHub or GitLab can be installed directly. This supports open source development through transparent issue tracking. A project can be installed using the following command:

Custom web servers: Any web server with a suitable directory structure can serve as a repository. Packages must be hosted in folders using their normalized names, with all versions grouped together:

To use a custom repository, pip must be instructed to use a different index URL:

Alternatively, users can provide an extra index URL to search multiple repositories:

Configuration and environment variables: Index URLs can be specified in pip configuration files at three levels, global (system-wide), user (specific to a user), or site (specific to an environment). The PIP_CONFIG_FILE environment variable can also point to a custom configuration. Additionally, any pip command line argument can be converted into an environment variable using the PIP_<UPPER_LONG_NAME> format, such as PIP_FIND_LINKS.

Distributing Packages 

Independent of the hosting layer, Python packages are published in two primary formats: 

• Source Distributions (sdist): These come in a packed .tar.gz format. They contain the full source code and build instructions, requiring the package to be built on the user's workstation before installation. 
• Wheel Distributions: These come in a pre-built .whl format. They are ready to be deployed immediately, providing a faster and more robust installation process. Despite having .whl extension, these distributions use same format as the .zip files. 

Source distributions rely on build instructions, typically written as either a “setup.py” or “pyproject.toml” file. While “pyproject.toml” is the modern, preferred format due to its transparency and support for various backends, “setup.py” is a standalone script that uses Setuptools. A critical security concern is that “setup.py” executes automatically during installation or download, allowing for the execution of arbitrary code.

Installing packages 

Distribution format and target environment are the main parameters of the installation layer. Distribution format determines if the build process will take place on the user computer. Depending on the target environment used, accessibility of the package will differ after installation. 

Besides system-wide deployments, use of virtual environments are very common. Virtualization of Python environment isolates packages and their versions per deployment. It prevents version conflicts between different software, which are relying on the same set of dependencies with varying versions. Isolation occurs mainly on the package and binary level. Once activated, a virtual environment is treated as a separate Python site, sharing the same file system and network interfaces, but with its own binary and package library. Therefore, we cannot consider this type of virtualization containerized. 

Use of virtual environments provides convenient management for package dependencies. Direct dependencies of a Python package is handled in various locations. Within source distributions, direct dependencies can be found on: 

• “setup.py”, the setup function contains an install_requires parameter, where dependencies can be listed
• “pyproject.toml”, under “projects” section, dependencies parameter lists required packages 
• “requirements.txt” file contains a list of dependencies 
• “Pipfile”, under packages section 

After package is built, dependencies are listed in the “METADATA” file under “.dist-info” folder within wheel distribution file.  

Tools like poetry, uv, and hatch are replacing native solutions by providing end-to-end management for environments, packages, and projects. These tools extend “pyproject.toml” capabilities by adding tool-specific sections to handle complex build-time tasks.

Entry points for malicious payloads 

The delivery medium for a malicious payload often defines its victim base. While phishing campaigns might target broad demographics based on geography or language, package manager attacks specifically target individuals with software development skills. In a modern enterprise, these individuals often hold administrative rights across sensitive assets, including endpoints, source code repositories, Continuous Integration and Continuous Delivery (CI/CD) pipelines, and cloud infrastructure. This makes them high-interest targets for adversarial campaigns. Furthermore, the rise of AI-based tooling has expanded this target group, increasing the potential impact of a single breach.  

In this landscape, Python offers a feature-rich and popular environment favored by both developers and adversaries. Despite malicious packages being identified and removed from public repositories within hours, this is still a valid opportunity window for adversaries. Payload execution can occur within minutes of installing the malicious package, and exfiltration can be achieved within an hour, depending on adversarial goals. Later, operationalization of stolen assets by different actors can occur within just a few days. Recent trends indicated dwell time of nine days once compromised. This might vary based-on detection and response capabilities of an organization. Therefore, having a structured understanding of malicious Python packages can help us estimate the impact of the infection and avoid being compromised all together. 

With this in mind, let's delve deeper into Python packages and highlight native features abused by the adversaries within a structured format. We group adversarial techniques into two main categories (build hook abuses and package content abuses) and list some additional characteristics, that convey the potential impact that can be inflicted upon the victim system: 

• OS: Operating System support for this technique 
• Category: Category of the technique, based on the Python feature it abuses 
• Persistence: Indicates if the payload can persist between executions 
• Build: Shows the supported build methods for the technique 
• Distributions: Indicates if technique requires package to be build on victim endpoint 

Build hook abuses 

Command class utilization on setup files 

“setup.py” helps with building the source distribution into a package on clients. It can execute arbitrary code during build process and mainly uses setuptools library’s setup function, to run pre/post-installation actions. setup function uses command classes through distutils library to build the package. The initial payload is executed once during package installation. In the wild examples of install command class abuse were previously reported. 

In Figure 2, the setup function uses a malicious mock-object called BeaconOnInstall to override installation behavior of the package.

After installing the Python package, the pyproject hooking script beacons third-party domains, as instructed with the BeaconOnInstall object.

Use of Path Configuration Files 

Path configuration files (.pth) are used to extend system path coverage for Python environments. They are expected to contain file paths in order to point out additional directories for runtime usage. Yet, they are capable of executing Python one-liners. Once a .pth file was added directly under package folders, such as “site-packages” or “dist-packages”, they are executed with every invocation of Python, therefore exhibiting a persistent behavior on the victim endpoint. This technique can be achieved regardless of the build method and distribution type. One of the high profile campaigns using this technique was initiated by the TeamPCP during supply chain compromise of the litellm package. 

In order to leverage .pth files through “setup.py”, we can again use the help of distutils command classes. Our hidden payload located in a .md file, will be converted to a .pth file and will be added to the root of the package directory, once the build process is completed.

Alternatively, same can be achieved through “pyproject.toml” file. If the Hatchling backend is used, you can use the tool.hatch.build.targets.wheel.force-include capability in order to drop a “.pth” file under the packages folder. 

After installing this package, every invocation of Python (whether failed or succeeded) will be infected with the payload located within the .pth file. For testing purposes, this payload executed “calc.exe” after each invocation of Python.

Use of Site Hook Modules 

Python’s site module provides sitecustomize and usercustomize hooks in order to help customize Python deployments per site. Originally, it is aimed to help customize the environment before Python is executed. These hooks runs the contents of “usercustomize.py” and “sitecustomize.py” files, which are located within the directories listed in sys.path Python variable. Package folders are one of the directories Python looks for these modules. If an adversary manages to manipulate existing scripts or drop their own into one of these directories, they can hijack the given environment and execute their payload with every Python invocation, therefore achieving persistence on the victim endpoint. The VIPERTUNNEL backdoor was reported to abuse site hooks in order to import and trigger DLL execution. 

Similarly to the previous technique, we can use both “setup.py” and “pyproject.toml” in order to drop “sitecustomize.py” directly under the packages folder. After installing the package, we’ve executed pip freeze, to test the execution of our payload. Since the pip command uses Python environment in the background, it triggered our payload, and we observed curl command making connection attempts against “www.google.com”.

Manipulation of PYTHONPATH Environment Variable 

As previously described, Python looks up the sys.path variable in order to determine which directories to use for importing modules. The value of the sys.path is generated through site module of Python. It collects user and site folders, and combines them together with “.pth” files and the value of the PYTHONPATH environment variable. If the adversary is able to control the value of PYTHONPATH environment variable, they can point it to anywhere they would like and manipulate imported packages. Every Python invocation of corresponding users would be infected, achieving a user level persistence on the targeted Python environment. This technique is suitable only through source distributions that are leverage “setup.py” based builds. Although its abuse is well-known by the community, vulnerabilities arising from the misuse of the PYTHONPATH variable were also previously reported. 

If used in conjunction with Python site hooks, the malicious payload within “sitecustomize.py” can be invoked without requiring it to be placed under the packages directory. We can extend module search towards the malicious package folder to achieve code execution. In Figure 5, the “setup.py” file leverages distutils command classes and alters the user profile to manipulate the value of PYTHONPATH.

Once the user profile is altered, future Python invocations from new shell sessions will lead to infected executions. User profile updates will impact the current shell session, since its preferences are already imported ahead of its creation.

Package content abuses 

Import time loading of malicious payload 

Init files define their parent folder as a Python package. They also enable users to customize import process of a module within the same folder. They are executed each time a module within the same folder is imported. Adversaries abuse this feature by hiding their malicious payload within often overlooked “__init__.py” files. This technique does not lead to compromising of the entire Python environment. The malicious payload only gets invoked once a module is imported from its directory, therefore leading to a conditional persistence on the target environment. This technique has been utilized in the wild as part of the lightning supply chain compromise.

Importing the module on Python interpreter or executing a script that imports functions from this module leads to victim endpoint’s compromise.

Payload execution through module scripts 

Python packages can be executed as a script using the -m flag. In this case, a package is imported and its “__main__.py” is used as an entry point. Python package manager pip is one of the common examples of this usage. Besides having its standalone binary “pip.exe”, it also can be executed as python -m pip <args>. Similarly, Python site module can be executed as a script, in order to list site configuration of the given Python environment.  

Adversaries can leverage main files to hide their payloads. Malicious code gets executed each time module is executed as a script, therefore achieving a conditional persistence on the victim endpoint. In Figure 7, “__main__.py”, belonging to redpy_demo package, executes the netstat command through using the subprocess module.

After installation, executing the redpy_demo package as a module leads to execution of arbitrary code.

Search order hijacking through entry points 

Python packages can declare entry points for their execution, which leads to the creation of a specific binary in the binary/scripts folder of the given environment. Whenever its alias is invoked, the corresponding binary is executed. In a naming conflict, the binary which has a higher ranking on the search path gets executed. The impact and scope of this technique depend on the target Python deployment. Virtual environments are vulnerable only when activated in a shell session, while system-wide environments may invoke the infected binary at any time. The operating system version and Python installation path can also affect search-order behavior. 

Adversaries can leverage this feature to hijack legitimate binaries. For instance, entry point declaration using a netstat alias can replace the execution of the legitimate netstat binary, due to being in a higher rank in search order. If adversaries manage to declare such an entry point in their package, they can re-route the execution of netstat to a binary they have control over. While executing the legitimate binary in the background, they can also include their malicious payload in between. Different research has reported on this technique previously. 

In Figure 8, “setup.py” creates an entry point named netstat, executing the main function of the cli module within the package. 

The same technique can be achieved through the “pyproject.toml” file as shown in Figure 9. Under the project.scripts section, the netstat entry point is declared to use the main function of cli module.

After installing the malicious package, each netstat execution from the given Python environment will execute the malicious payload, creating conditional persistence on the victim endpoint.

Overriding the content of a legitimate package 

While building Python projects for distribution, the directories that will be packaged are specified, meaning that a single distribution file can contain multiple packaging directories. It is not mandatory for the project and package names to be identical — when a project, and therefore its distribution file, is named package1, its package directory can be named packet. If you expect to upload it to PyPi, the distribution should have a unique name, but the same is not true for the package directories. This can lead to naming collisions, when different distributions use the same name for their packaging directories. When this occurs, the content of both distributions are extracted into same folder. For overlapping files and directories, directories replace the files.  

This feature can be useful when trying to extend the capabilities of an existing library by adding new pipelines, backends, functions, etc. However, attackers can also leverage it to hide their payload amongst benign distributions. This makes it harder for defenders to spot and eradicate the malicious payload. Similar to other package content techniques, the use of compromised modules would trigger the execution of malicious payload, therefore leading to a conditional persistence. 

In Figure 10, we override the legitimate read_json function of pandas library with a malicious one. We can now create a new project using a fraudulent name, that only contains “pandas” folder and “__init__.py” within.

For testing purposes, we can create a script that imports and calls the read_json function from the pandas library.

Once executed, our altered function will be executed besides the original one:

Defensive measures 

Securing a Python environment against malicious packages requires a layered defense strategy that combines automated auditing, strict dependency management, and proactive behavioral analysis. While effective individually, no single technique is resilient against breaches and compromises alone. The stages of a package lifecycle demand a complete approach. The following measures are all applicable for the techniques discussed previously. 

1. Threat intelligence and scanning 

Intelligence generation and consumption is one of the fundamental elements of cybersecurity, and Python packages are no different in that regard. Regularly auditing installed packages is the first line of defense against known security flaws. It begets additional indicators, which can be contributed back to community as a fresh threat intelligence. 

• pip-audit: This is the official tool for scanning Python environments for packages with known vulnerabilities. It uses the Python Packaging Advisory Database to identify risks and can be integrated into CI/CD pipelines to break builds if a vulnerability is detected. 
• Automated Patching: Tools like pip-audit --fix can automatically upgrade vulnerable dependencies to the minimum safe version, reducing the manual effort required for remediation. 
• Yara rule scanning can be utilized to identify known malicious packages. 
• Abstract-Syntax Tree (AST) scanning turns code strings into a tree object that can be utilized to analyze function names, variables and imports for malicious behaviors. 

2. Dependency pinning and integrity 

To prevent "dependency drift" or tampering, developers should ensure that every installation is reproducible and verified. Besides providing deployment stability, it prevents further spreading of the malicious packages by keeping users in stable versions. 

• Lock Files: Use lock files such as “uv.lock”, “poetry.lock”, or “Pipfile.lock” to pin the exact versions of all transitive dependencies. 
• Cryptographic Hashes: Always include hashes in requirement files or lock files. This ensures that the package content downloaded from a repository matches the version originally vetted by the developer, preventing attackers from swapping files on the server. 

3. Environment and installation controls 

Controlling where, when, and how packages are installed can prevent the immediate execution of zero-day malicious payloads. They minimize the impact of malicious packages by slowing down the gains of the adversary. 

• Dependency Cooldowns: The uv tool offers an exclude-newer feature that ignores any package version published after a specific date or within a recent window, such as the last seven days. This "cooldown" period allows the security community time to identify and remove malicious uploads before they reach your environment. 
• Isolated Build Environments: Never build or install untrusted packages on a local workstation with sensitive access. Use ephemeral containers, virtual environments or isolated runners for all installation and build tasks to minimize the risk of a persistent foothold. 

4. Visibility and advanced tooling 

Over time, cybersecurity is proven to become a communal effort. Individual initiatives such as vulnerability scanning may not be enough to catch sophisticated techniques. Providing and maintaining visibility across development helps engaging more responders in case of a compromise. 

• Software Bill of Materials (SBOM): Generating an SBOM using standards like CycloneDX provides a comprehensive inventory of every component in your software. This allows security teams to respond within minutes when a new compromise is announced in a popular library. 
• Trusted Publishing: Maintainers should adopt OpenID Connect (OIDC) for "Trusted Publishing" on PyPI. This eliminates the need for long-lived API tokens and reduces the risk of account takeovers through credential theft. 

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed three vulnerabilities in WolfSSF, fourteen in GeoVision, and one vulnerability in VTK-DICOM.

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, 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.

WolfSSL vulnerabilities

Discovered by Ankur Tyagi of Cisco Talos.

WolfSSL aims to provide "lightweight and embedded security solutions" for both individual and business needs. WolfSSL is an open-source product to provide secure data transfer.

Talos discovered two improper input validation vulnerabilities (TALOS-2026-2409 (CVE-2026-28739) and TALOS-2026-2410 (CVE-2026-25106)) and one integer underflow vulnerability (TALOS-2026-2408 (CVE-2026-33091)) in WolfSSL.

GeoVision vulnerabilities

Discovered by Philippe Laulheret of Cisco Talos.

GeoVision specializes in security technologies, including cameras and monitoring solutions, access control, and machine-identification.

Talos released 14 advisories for GeoVision vulnerabilities, covering 37 CVEs:

• TALOS-2026-2411 (CVE-2026-12488) memory corruption vulnerabilities
• TALOS-2026-2379 (CVE-2026-12486, CVE-2026-12849, CVE-2026-12850, CVE-2026-12851) OS command injection vulnerabilities
• TALOS-2026-2377 (CVE-2026-12485, CVE-2026-12846, CVE-2026-12847, CVE-2026-12848) buffer overflow vulnerabilities
• TALOS-2026-2369 (CVE-2026-42370) stack overflow vulnerability
• TALOS-2026-2333 (CVE-2026-7372, CVE-2026-42369) stack overflow vulnerabilities
• TALOS-2026-2329 (CVE-2026-42368) privilege escalation vulnerability
• TALOS-2026-2328 (CVE-2026-42367) privilege escalation vulnerability
• TALOS-2026-2327 (CVE-2026-7371, CVE-2026-42366) reflected cross-site scripting (XSS) vulnerabilities
• TALOS-2025-2326 (CVE-2026-42364) OS command injection vulnerability
• TALOS-2025-2332 (CVE-2026-42365) guessable session cookie vulnerability
• TALOS-2025-2322 (CVE-2026-7161) insufficient encryption vulnerability
• TALOS-2026-2375 (CVE-2026-57273, CVE-2026-57274, CVE-2026-57275, CVE-2026-57276, CVE-2026-57277, CVE-2026-57278) stack-based buffer overflow vulnerabilities
• TALOS-2026-2373 (CVE-2026-13131, CVE-2026-13132, CVE-2026-57264, CVE-2026-57265, CVE-2026-57266, CVE-2026-57267, CVE-2026-57268, CVE-2026-57269, CVE-2026-57270, CVE-2026-57271, CVE-2026-57272) out-of-bounds read vulnerabilities
• TALOS-2026-2370 (CVE-2026-13125) lack of authentication vulnerability

VTK-DICOM vulnerability

Discovered by Emmanuel Tacheau of Cisco Talos.

The Virtualization Toolkit (VTK) is an open source software solution for handling scientific data, for use in tools for 3D rendering. The VTK-DICOM API is specifically to allow VTK users to parse Digital Imaging and Communications in Medicine (DICOM) medical data.

Talos found one vulnerability in VTK-DICOM, TALOS-2026-2366 (CVE-2026-22879), which is a heap-based buffer overflow vulnerability.

Welcome to this week’s Threat Source newsletter. 

There’s a fairly cliché phrase in cybersecurity that I’m sure our audience is familiar with: Attackers only need to be right once, whereas defenders need to be right 100% of the time.  

I guess it captures the asymmetry of this industry, but I’ve never been entirely comfortable with the phrase because it assumes cybersecurity is a game of perfection. One mistake and it's over.  

I’ve been watching a lot of Wimbledon this week, as I have done since childhood. In fact, I believe my first words were, “C’mon Tim!” (For our non-U.K. audience, I’m referring to tennis player Tim Henman, who made four Wimbledon semi-finals in the late 90s and early 2000s and has a hill in the Wimbledon grounds named after him).  

Of the “big three” (or the “big four” if you’re Scottish), my favourite was always Rafa Nadal, but I have to admit there’s no one who could deliver a one-handed backhand quite like Roger Federer. I bet that when he swats at a fly, the fly apologises and claps its wings. 

As I saw him sitting in the Royal Box entirely on his own this week, watching tennis out of pure love of the game while everyone else scoffed their strawberries and cream in the comfort of hospitality, I remembered the commencement speech he gave at Dartmouth a couple of years ago. He told the students that, across his entire career, he won 80% of his matches.  

But of all the total points he played, he won 54% of them.  

Tennis is a long game (no one can tell you that more than Novak Djokovic and Felix Auger Aliassime who just played the longest quarter final in Wimbledon’s history last night). And, mathematically in tennis, you can lose more points and overall games than your opponent and still win the match. Which point you win matters more than the total amount of points you win.  

If you go to the IBM SlamTracker right now, you’ll see all sorts of stats around when players choose to attack, how often they successfully convert those attacking positions into points, and how often they win points they looked destined to lose (the “steal” score). 

Tennis is hundreds of small decisions: When to attack, when to defend, when to be patient, when to let the point develop. Not all of those decisions pan out because, well, you’re playing against an opponent who’s also making decisions within the point… and not a brick wall. 

In the SOC, it’s also about making thousands of judgement calls, using whatever hand you’re dealt. And with more context, you’re able to know your environment better and make better decisions. You can test more assumptions and follow a hypothesis that might lead somewhere, or nowhere at all. 

Because that’s the job, and perfection is a myth. 

The one big thing 

Cisco Talos’ latest findings on the China-nexus threat actor UAT-7810 shows they are expanding their Operational Relay Box (ORB) networks with a fresh suite of custom malware. The group exploits known vulnerabilities in unpatched Ruckus and ASUS routers to deploy new tools, including the upgraded "LONGLEASH" and "DOGLEASH" backdoors. UAT-7810 builds these covert networks to provide infrastructure for other APT groups to launch attacks against high-value targets. 

Why do I care? 

ORB networks create a massive blind spot. They allow secondary threat actors to mask their origins and route malicious traffic through seemingly innocuous nodes. By compromising edge devices like wireless routers, UAT-7810 builds a highly evasive, decentralized proxy network that easily bypasses traditional perimeter defenses. The active development of sophisticated, multi-platform tools like LONGLEASH shows this group is heavily investing in making their infrastructure incredibly resilient and hard to dismantle. 

So now what? 

Because UAT-7810 relies on exploiting n-day vulnerabilities, defenders must ensure all edge devices, particularly Ruckus and ASUS routers, are fully patched. Monitor network traffic for unusual proxying behavior or unauthorized connections on devices that typically lack complex services. The blog post has a complete list of IOCs to help detect and block this malware suite. 

Top security headlines of the week 

The “first” AI-run ransomware attack still needed a human 
Researchers at cloud security firm Sysdig said they’d documented the first known case of “agentic ransomware.” (The encryption was non-reversible — essentially a wiper, not ransomware.) A human provided compromised credentials, provisioned the command-and-control server, the staging server used for the stolen data, chose a victim, and more. (TechCrunch) 

AirDrop and Quick Share flaws let nearby attackers trigger crashes and bypass checks  
Two researchers have found six security flaws in AirDrop and Quick Share. An attacker within wireless range, with just a laptop and no prior connection, can crash the sharing service on a Mac or iPhone set to receive from anyone, with no tap or prompt. (The Hacker News) 

Hidden backdoor in Tenda router firmware grants admin access 
A hidden authentication backdoor has been found in multiple Tenda router firmware versions, potentially allowing an attacker to gain administrative access to the device's web management panel. According to the CERT Coordination Center, the issue remains unfixed because the maker couldn't be reached. (BleepingComputer) 

State IDs for AI agents: Will Estonia set a precedent? 
Estonia's government will soon assign official government ID numbers to AI agents. The point is to enable organizations and individuals to use AI when engaging government systems, but in a way that's limited and auditable. (Dark Reading) 

Can’t get enough Talos? 

Space pirates, Living Off Trusted Services, and Bill declares food war  
The team discusses how Living Off Trusted Services (LOTS) differs from Living Off the Land (LOTL) (and Lord of the Rings (LOTR]), why trusted services create new detection challenges, and what defenders should be monitoring. 

ARToken: Inside an EvilTokens affiliate panel targeting Microsoft 365 
Talos has identified "ARToken," a phishing-as-a-service platform that targets Microsoft 365. The ARToken panel exposes 80+ API endpoints for device code phishing, Primary Refresh Token persistence, email access, BEC operations, and SharePoint exfiltration. 

Martin Lee: Running through the Arctic (and the threat landscape) 
Ever wonder how someone goes from studying human viruses to leading cybersecurity teams? How about running through the Arctic for fun?  In this Humans of Talos you get to hear from Martin and that’s ALWAYS worth pulling up a seat. 

Upcoming events where you can find Talos 

• Black Hat USA (Aug. 1 – 6) Las Vegas, NV 
• DEF CON 34 (Aug. 6 – 9) Las Vegas, NV 

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: 621c6d42409e8aa423684827b4375a35684c71c600f2dd9101f235e8ec633488 
MD5: 9b512ba139304c247ddd3d2c4b9179fd 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=621c6d42409e8aa423684827b4375a35684c71c600f2dd9101f235e8ec633488 
Example Filename: 9b512ba139304c247ddd3d2c4b9179fd.exe 
Detection Name: W32.HEUR:Attribute.28iy.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: afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
MD5: cc4d231df34e57f59eb970353c7d9de2 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
Example Filename: sample.exe 
Detection Name: PUA.Win.Tool.Kmsactivator::1201 

Talos assesses with high confidence that UAT-7810 is a China-nexus threat actor based on the infrastructure that it provides to secondary China-nexus APTs such as UAT-5918. Open-source reporting has also illustrated overlapping tooling between UAT-5918 and UAT-7810. However, at this time, Talos considers UAT-5918 and UAT-7810 separate APT actors tasked with their own set of objectives and targets.

Talos’ latest findings on UAT-7810 indicate that the threat actor continues to develop their custom-made malware dubbed “SHORTLEASH” with a newer version already being developed and hosted on attacker-controlled infrastructure. We track this new version of SHORTLEASH as “LONGLEASH.”

Talos has also discovered two more previously unknown tools in UAT-7810's arsenal:

• DOGLEASH: A malicious backdoor that can execute arbitrary shellcode on the compromised Linux device
• LEASHTEST: A Linux binary (ELF) that is used for testing rudimentary functionality on MIPS-based embedded devices

Talos’ findings also illustrate that UAT-7810 used at least four new servers to host a variety of minor variations of DOGLEASH to deploy against compromised targets. An additional JAVA-based (JAR package) backdoor that we track as “JARLEASH” was also deployed by UAT-7810 on at least one of the three servers for administration purposes, including file management, FTP, SFTP, and Netcat.

UAT-7810 exploits n-day vulnerabilities

Talos has observed UAT-7810 primarily exploit known vulnerabilities in unpatched Ruckus wireless routers, a tactic UAT-7810 has used since 2025. CVEs exploited include:

• CVE-2020-22653
• CVE-2020-22658
• CVE-2023-25717

UAT-7810 infrastructure

Talos discovered four new servers being used by UAT-7810 to host malicious payloads for a variety of hardware platforms including MIPS, ARM, and x64. The malware hosted predominantly consists of DOGLEASH, and accompanying shell scripts are executed on compromised systems to download and execute DOGLEASH.

All three of the following IP addresses were associated with VPS instances that indicated UAT-7810 acquired and used these servers as download locations:

• 194.233.92[.]26
• 217.15.160[.]247
• 217.15.164[.]147

 One of the IPs, “217.15.164[.]147”, was also used as infrastructure to conduct exploitation of ASUS’ AiCloud Routers in early 2026 — specifically CVE-2025-2492 — indicating that UAT-7810 or an associated threat actor likely attempted to expand their ORB network to AiCloud Routers.

Additionally, “217.15.160[.]247” and “217.15.164[.]147”,  hosted a TLS server on port 99 with the certificate fingerprint:

c2ab9adaba93ff094b8f3fc37d906014d870582039d276b7bd03e6fd583d8a15
and
subject_dn = "C=exploit, ST=exploit, L=exploit, O=exploit, OU=exploit, CN=exploit"

Forensic analysis of compromised networking devices led to the discovery of a fourth IP address UAT-7810 used to host their malicious payloads: “95.182.100[.]231”, residing in Hong Kong.

UAT-7810's malware suite

LONGLEASH: A new version of SHORTLEASH

LONGLEASH is a new version of UAT-7810's previously disclosed backdoor SHORTLEASH. SHORTLEASH consisted of a backdoor capable of contacting its command and control (C2), hosting a web server, managing tunnels, and acting as both a C2 server and client. LONGLEASH, however, contains a variety of additional capabilities, indicating that UAT-7810 is actively developing it for use against their targets.

LONGLEASH is built off the same codebase as SHORTLEASH, with both tools being internally named “ff-agent”. The LONGLEASH variant compiled for MIPS processors is built on the asynchronous version of the Boost library (Boost.Asio) to minimize the blocking time and maximize the performance of the network.

The internal name for the LONGLEASH project is “nz1.0” and it has the following major components:

• Base: Contains the implant’s logging and utilities, such as routines for Base58 and Base64 encoding and decoding.
• Executor: Supports several capabilities, including the main proxying functions, for setting up the following channels:
  • Reverse shell to C2
  • Proxy servers for HTTP, DNS, SOCKS, TCP, ICMP, and UDP
  • Packet redirection for traffic based on TCP, UDP, and HTTP
  • SMTP server and client

The other major executor modules support managing of network connections to other servers, including TLS and public key infrastructure, managing clients connected to the implant, sockets and URIs.

 The executor is also tasked with authorization of clients, routing of the messages through the proxy network, and setting and management of basic network tunnels.

 Finally, the executor contains functionality to remove the implant and all traces from the server if a suspicious connection or tampering is detected.

• Core: Provides basic authorization and node identification services, HTTP encoding and utilities, processing of protocol buffer (protobuf) encoded messages, basic SHA checksum functions, task management, and basic security.

The implant contains the User-Agent string "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.95 Safari/537.36" which may allow it to hide within legitimate traffic purporting to be an instance of the Windows Chrome version 122.

 Apart from the Boost.Asio, the implant contains code from at least two open-source libraries: Nanopb, used for processing protobuf messages, and MbedTLS, for establishing TLS, proxying TLS encrypted communications, and managing x509 certificates for the network. The implant does not use a standard libc library but a small musl library libc that implements C functions on top of Linux syscalls.

LONGLEASH also has the capability to act as an intermediate C2 server. It can obtain commands and data from the original C2 and forward to its peers.

DOGLEASH: The passive backdoor

Talos also discovered a previously unknown backdoor, developed and operated by UAT-7810, that we track as DOGLEASH. After compromising a networking device, UAT-7810 deploys a shell script that:

1. Downloads DOGLEASH.
2. Adds iptables rules to allow TCP traffic to a specific port, on which DOGLEASH binds and listens.
3. Executes DOGLEASH on the device.

DOGLEASH will bind and listen for an incoming request on a local hardcoded port. Any TCP data received is then decoded using a hardcoded password string. Based on the command code and accompanying data received, it creates a new thread in the process and carries out a specific action:

JARLEASH: The JAVA-based administrator

JARLEASH is a JAR-based backdoor that UAT-7810 deploys on their own infrastructure, as well as on compromised systems with JAVA available, to enable easy access to the system. JARLEASH is accompanied by a startup script that first kills any active instances of JARLEASH on the system, and then spawns the JAVA container to deploy JARLEASH.

JARLEASH can either use an external configuration file or default to an embedded configuration. The configuration file contains comments in Simplified Chinese, indicating that the operators were Chinese-speaking individuals.

The backdoor has the following capabilities:

• Host a web-based file management interface
• FTP and SFTP servers
• Run a netcat server on a specified IP and port number

LEASHTEST: Testing the waters

Talos also discovered a test binary UAT-7810 developed that we track as “LEASHTEST.” This binary is not malicious as-is, but its presence on a device likely indicates a compromise. It is used to test rudimentary functionality on the MIPS platform. Internally named "iot-test", it checks to see if it can take the following actions on an Internet-of-Things (IOT) device:

• Create a thread and join it
• Bind and listen to a port to open up a TCP acceptor
• Create a child process (sub program)
• Create an async timer
• Print "Hello World!"
• Test exception handling routine

 The development and use of LEASHTEST signifies that even though they have developed LONGLEASH, a full-fledged backdoor framework, UAT-7810 is still actively testing functionality on MIPS platforms and may not be completely confident of its behavior on MIPS devices.

Coverage

SNORT® SIDs for the threats detailed here are: 66433, 66432, 66430, 66431, 301493.

ClamAV signatures for the malicious tooling associated with this cluster are:

• Unix.Backdoor.Agent-10059997-1
• Unix.Backdoor.Agent-10059998-0
• Unix.Backdoor.Agent-10059999-0
• Java.Backdoor.Agent-10060000-0
• Unix.Backdoor.Agent_mips32-10060001-0
• Unix.Backdoor.Agent_mips32r2-10060002-0
• Unix.Backdoor.Agent_armv7-10060003-0
• Unix.Backdoor.Agent_mips1-10060004-0
• Unix.Backdoor.Agent_mips32r2el-10060005-0
• Unix.Backdoor.Agent_mips32el-10060006-0

IOCs

Network indicators

194.233.92[.]26
217.15.160[.]247
217.15.164[.]147
95.182.100[.]231

http[:]//217.15.160[.]247:8088/
http[:]//217.15.160[.]247:2222/
http[:]//217.15.160[.]247:99/
http[:]//194.233.92[.]26:8088/
http[:]//194.233.92[.]26:2222/
http[:]//217.15.164[.]147:99/
http[:]//217.15.164[.]147:8088/
http[:]//217.15.164[.]147:2222/
http[:]//95.182.100[.]231:2222/

Malware indicators

LEASHTEST

1b5649b479fd625de5c8120873644b5eb669cc89cd504582c18e0ae350fd8823

LONGLEASH

755fcee1337a252203002ecfdf673a08cfadeda8d738bef2d518a08e0626aa4f

Startup script for JARLEASH

e799d72929d7ccc7f6b6109742b8cc482838303207efc989543b6e1ca6d16e9c

Configuration file for JARLEASH

3b89d183eb014e29d9d0d4e45fc2b784a7fcfcf31dd48fd3bde30f8d956383d1

JARLEASH

324d95024fc8da5c92b5a1f4825aed5a2a91c9ca8fb6aa52abb332a4c9cf4257 
bafba443170e54ef7fd431ce7f1b5e202719f3fd022e4ef70788904f574d2cdf

DOGLEASH

604b53f87d6c070bf387e80c70a6df8d272fa3fc143148d41f13e59d52ab1f13 
c92541f273eeb576d39235d0a5c6f18f2574b132a1022598edfa38065783ab98 
29c7fccc6ef8cbfe4da9a169c7c74bacaea1fb515a1fddef91ab1b1522f76e4c 
425bf771c8c9f740b1ae9803dcb4fd45af4d6a6f171fcc72fc7d511095ca82ce 
ac8eae94d27122f4751bc96d9ea52d30000b7ca37569a2291b2710824ca3396f 
dc4f25b2247cfdd6fc96848db30a178baa4419a4c854e86e315b465836102d14 
3878dd5c8eba1e5b53ab2e07e7b5482e95a3fd3e98268bcd7861318bc9902376 
9b9e0e5a1eb469b8d20dc23351e08ff5d5731e1cedce0ddee9bbd00a76217f13 
57bdab2ba4b05ec0338c06632599393d5b14227f31a43fe950ea8fdd47428715 
b8d247fd1fb85d24a17afeec3815906dfbcdc5359647910b4a153900ec999a0f 
5e225ea2648a8cba0fd94ec7fd8ce5315f5d0cc2922bafc9db3c8c41280e917c 
d5cf7315186a78ab6a7475c338bdf101bc6461930aaa7a012a02cf93f347c207 
dd0fc1a88180fde8367bec7086f99294f36b8332f12994293139ed532d2ebbac 
5c3f190571645c4641dcff2c07a4c3ab9acad06aa9607350a385729d8d6139f1 
323c3a91be60ebc3e06e942bad04899a15911cea23269e43d07829164b2ce5d4 
880425fee707e9f42e0b8d60119ed639b1ad506ea29877d126bdebce379cd229 
e5d2de8ae98579bfb940290f60e59a502b3065345aaf765456387989c0488b20 
2e0e43776e2e1a37d882a1b2ebb7d337ee88950177e43831dae645a367824feb 
b5969636eec376ad6c3ece2202b1722219955638e09b6f96d4cfc0598d3b1890 
1660536f448b8b9f086ce9ea3ce4e9deefc59a76711ea53ee6d8f08fc8c1bb99 
65feba2c971c214e71303ad2e0fbf62b45ebcaa784cbf3d0dab62786cb4c0469 
53ac2b231c23d41234e55b1f7ed89f86234f785adbbe820959655d7b019d7df9 
33c10b77e1da9f0679023d55fb3057879d15609db9c1d46ee5c3ff1240a3d052 
5faea1650cac0f3ffd2dc1fb220182095a46e34158967d37c2a942e85e2ca97b 
62d4ec87ed21f0d15cb769b0b2a5577cab41fc2cdb1e7e796c5bdff09264dd9a 
534a4a5bff2609a2d6e088cb87465c08c2d69c6aaa7d2ffcbcd491274b8505f1 
5eab4c61baa67ae2838a36c2e6ff0476a8f2117b96a7027b830c8cb46ce78efc 
0af4c52a1d13e4132a1843ce7727abcf0ddd4d1ca6a4b17cdf599ec3f355c241 
d4861088161fc72b9922abf933b4ea664a807105ec1eab4a173253aa60bfe6d7 
3d296af7f29c0425655bd1cc0be48fe4aba52ee6760a89e805ca2589f4ef4d77 
f235d2e044c2f7814e6bbcd835b9fd9f10f227dacfb9396185ec2013e7df4db4 
4130f49fa81a699a667cafdbd6d1f6e781edd686c947eb8ae27134f6dc2c43d7 
0a8555a71868749be8c905ed53296ce335af50a9262772b5e154ad3f9c35c2e4 
5dbfa033676b5caacfae902734ce462cd871181eefbe299250ca8ac7e139719e 
20fcba222f74dd68aaeb1f0ad30cdf702a828ee164a182b30d05d600c35b72d9 
912adea5339c73cb4a777a3e9f98bf3cb08da6622c9dd3b4cc9b083cb03d10a2 
03926e3da998f32ad898b640bd15cf145768f9e849e6f18d81350234254c424e 
16971f9706d70ac4925651c7c8719b9d77aff63e4c0a618129efc32c2c46b989 
6917c0f9eafefe42e33e791b75a7e503ff8b081bc10a98449e4076787dfc6c16 
c7c9bfa9ffcd8fb6a2afe656f510c406ddc58ebff48ce1d0fd3fad951b46a36e 
b9fe48bda9a6c8787981a24f8bbc723a6f6aa80cab5fa53481937382f3c6ce85 
f3fbf4481f30fd840f35568746f54be49eb92b2c9ac95597a7760abb171cb54b 
6366d59b573d50fd23ff650923c4a8c1c918518a02d0a56f12c23533c45f439d 
3fcaa3038e365b6ab0b121e2cd319c56b74e37381943a0da0e8dce407087cdb8 
bf70c6f3a8e913f526ec57eeec50e1306f7b34b037915b7a1cf2968cc46acc58 
0352f3e338261d98895df4c7b7a76b296485b2290c72bce56603351d167d0601 
52b871429833e1dee348263844efb531f6a3fcd321f88dc8a876caaee912cedd 
5db2ce9acd50f96d566e8d139f6490abf2bbf7a9293b876eeb4598fd2c37c515 
3169a6dbcce684e2c5a2f166996b58ffa673df6e58b8edf2bdf3e66271c8c69e 
d871d76171504597bbda387689e12e7a5e354c360ff135f4df231cec68c761af 
d1f963b88672f3676a7da1580262ba0d4f367cc57a94b551754c20f77a670c43 
76d9e2a2ff313f5b91cc67aab1127122baee1c3efbae1087e58a25bc5f1eb065 
8c104da0e66ef6384663309aaf8fb49f549f2785d835eec620b265f8aa11d9f0 
c494c878e28284539419612616d964ab9224cbe27e57f42293d91d02d684e3db 
08701ed7975bf4f5688c2724d27ab497764200ad6f4dc53d3cc03b170378ced0 
604b53f87d6c070bf387e80c70a6df8d272fa3fc143148d41f13e59d52ab1f13 
0a8cae96e25e85c612b0736fe886f9b124ad70ec425bc2ec1a8a4135b25436ba 
8459ff264a2c81c68a34c4ee6bc109d141ad28b96037d34ff112322a4c853739 
68445a37a9943a267a8b2100fba2678353d6ec88844505ccbba659e586c7a105 
29686c933cec1e274467e2dae264625ae6f754824bb7f550bc9c3131f625562c 
d973ad5a80c3d7468a9c392db4166857ed32b5d61cd6755766ba8922156dada3 
f5a57dfae488d9dfe260b32460a1d947fb5af58ceaf2fb0139bc08b4bb79a966 
2ebc1b6cf543e2cb3f22d9a5b54b6676bb71dde98df7532f8791297734e44fdd 
6dbd507ca7cecea861f9cf704b3c5c37f5bd5392886a8c2562088892b7703fa5 
89f0a67bc595ab8bce02c2f95f9292ad06e1868207e809c76bd16f0cab800c06 
d81201d0fc19977e51104438a5b9cba861f4da20cea3ae9183edf16ab11d98f8 
9d52cb4febf3342c34dcc8198dcaf453458be3699ab47dc08616aa7f18daa7fa 
9a927c37a31b80975c5c5467f112b61478c9493c046281046443525358a5acb0 
6cda1e81667f869940401f05a55c8dea94dbdf3ceffb93b5f320a6462cfea44d 
745538dea8ed9aec4466e67a9d0aecf9e7026ff16a792d1d6f306e8b67d3f34c 
13acadb3541e75af50e02d5be56c2238b93d8f154ce5514be1558e6ee59a1432

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

“I do not know everything; still many things I understand.”
― Madeleine L'Engle, A Wrinkle in Time 

“Don't try to comprehend with your mind. Your minds are very limited. Use your intuition.”
― Madeleine L'Engle, A Wind in the Door 

The World Cup. The 4^th of July as the US turns 250. Dungeon Crawler Carl. LeBron moving on. Wimbledon. AI. There are so many things that I could draw a parallel to farm for this week’s newsletter content. So let’s talk about board games.  
 
A lot of skills come and go, and your journey with cybersecurity will be full of tools that you learn and then are gone. It’s a never-ending journey of learning. And it’s honestly the best thing about this career path for the kind of minds that are drawn to it. Innate curiosity is the currency of our cyber family.  

Learning new and interesting board games (and I use the term broadly to circle in RPGs, card games, etc) is an incredible way to hone your mind and keep it focused on some of the most important tools that you will have.  

Games will harness your ability to highlight anomalous activity, by players, by rulesets, by structure. They will also highlight your personal brand of brain activity and allow you to leverage your singular style and intuition into a weapon.  

There are countless ways to win Ticket to Ride and your play style may be completely counter to someone you play with. That then creates patterns that you must learn to break. Nothing is more important to your defensive strategies than knowing yourself (know your environment!) and then breaking your tendencies to force your opponent to change their comfortable tactics (maybe, you’ve created some honeypot fake accounts to trigger identity alerts to track threat actors, to track their tooling and methodologies quietly).  

This is nothing compared to the chaotic variance of a game like Go with its simplistic ruleset yet cascading complexity of each stone’s placement.  
 
Learning a new game is a challenge and a great practice in and of itself, but learning how YOU and your strategies evolve as you learn the game will give you a microcosmic view into taking on new technologies, new coding languages, and new skill sets.  

You will have peaks and valleys. So often in the work world we let the complexities and our imposter syndrome keep us from taking a risk or next step in our learning evolutions – next steps that we boldly take in our gaming lives.  

So take what you learn from a Machi Koro, or Pathfinder, or Catan, or Wingspan, or ADnD 2e, or ... you get the idea, take that same aggressive inquisitive mindset to your current work, turn it on its head and find a new way to do something you are already good at. And then look at something you struggle with and treat it like the next level. In the end, the worst that can happen is you fail. Because that’s where we learn.  

"If the rule you followed brought you to this, of what use was the rule?"
– Cormac McCarthy, No Country for Old Men  

The one big thing 

Cisco Talos is highlighting research into ARToken a fully-featured phishing-as-a-service (PhaaS) operator panel, branded "ARToken," that shares infrastructure, API contracts, and operational patterns with the EvilTokens platform documented by Sekoia and Microsoft in early 2026, and features capabilites previously not documented. 

Why do I care? 

The ARToken panel exposes 80+ API endpoints for device code phishing, Primary Refresh Token (PRT) persistence, email access, business email compromise (BEC) operations, and SharePoint exfiltration — all accessible to operators through a React-based dashboard. These features indicate the platform is more mature than a simple device code phishing kit — it is a complete BEC operations environment. 

So now what? 

Defenders should be aware of the kind of capabilities that this panel gives and use the IOCs provided by Talos to block malicious activity and use them as pivots for their internal hunts if they are present.

Top security headlines of the week 

An aggressive password-spraying campaign targeting Microsoft 365 environments generated more than 81 million login attempts over a two-week period
The threat actor tried to authenticate via Microsoft's Azure command-line interface (CLI) using still valid username and password combinations that had been exposed in past breaches. (BleepingComputer)

Threat actors are trying to leverage organization-owned AI agents to power complex threat activity
By exploiting misconfigured or exposed AI endpoints, adversaries are increasingly turning enterprise-grade automation tools against their owners to facilitate more sophisticated and evasive cyberattacks. (DarkReading)

A recent authentication bypass vulnerability in the SimpleHelp remote monitoring and management (RMM) software has been exploited for malware delivery
Tracked as CVE-2026-48558, the bug impacts SimpleHelp’s OpenID Connect authentication flow and allows a remote attacker to obtain a fully authenticated technician session. (Security Week)

Can’t get enough Talos? 

Martin Lee: Running through the Arctic (and the threat landscape)
Ever wonder how someone goes from studying human viruses to leading cybersecurity teams? How about running through the Arctic for fun?  In this Humans of Talos you get to hear from Martin and that’s ALWAYS worth pulling up a seat. 
 
Beers with Talos has an updated format, which includes making Hazel a hacker and “Reasons not to Quit”, listener questions (yes, that means YOU) - as well as a guest appearance from Nick Biasini who is always worth the price of admission. 

Upcoming events where you can find Talos 

• Black Hat USA (Aug. 1 – 6) Las Vegas, NV 
• DEF CON 34 (Aug. 6 – 9) Las Vegas, NV 

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: afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638
MD5: cc4d231df34e57f59eb970353c7d9de2 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=afc8a00883a4ea07df2dc1d4ed02f8a23b35c9456413b438a2d9ce3ae5076638 
Example Filename: AutoPico.exe 
Detection Name: PUA.Win.Tool.Kmsactivator::1201  

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

SHA256: 853baab97b1f3b03c1ffa55797e87867f5fb7ce33457411f56afd270cb395453
MD5: 41acb30b9d662d48b7b4fc0ac3d4b79f Talos Rep: https://talosintelligence.com/talos_file_reputation?s=853baab97b1f3b03c1ffa55797e87867f5fb7ce33457411f56afd270cb395453 
Example Filename: SignInfoConsole.exe
Detection Name: W32.853BAAB97B.in12.Talos 

Ever wonder how someone goes from studying human viruses to leading cybersecurity teams? In this Humans of Talos, we’re joined by Martin Lee, EMEA Lead, to talk about his journey into the industry. Martin takes us back to the early days of the internet, explaining how he made the leap from academia to the front lines of threat research. He also gives us a fascinating look at his current work, where he’s applying a sociological lens to cybersecurity to better understand what makes certain organizations more resilient than others.

Whether you’re just starting your career in security or looking for a fresh perspective, you won't want to miss Martin’s advice on staying visible, being curious, and "flavoring your life with many spices."

Amy Ciminnisi: Martin, welcome! Can you describe what you do here at Talos for people who might not know you?

Martin Lee: My job is really ambassadorial. I still research the threat landscape, although I spend less time doing that now. Certainly understanding what are the changes that are happening in the threat landscape. But mostly my job is to externalize that — both to write about the threat landscape, but also discuss what we're seeing, what's important, and what's different with our customers and partners.

AC: I had no idea that you started your career in researching the genetics of human viruses. That’s one hell of a career change. Can you tell us about how you ended up where you are today?

ML: Yeah, "I discovered the internet," is basically the short answer. I discovered the internet very, very early on and just thought this is going to be the biggest invention in my life. I thought if I didn't jump there and then because I could see it was going to explode and go everywhere, and if I didn't jump then, I wouldn't be able to keep up with it. So, I left behind a career in academia to jump on board in the early internet and start building it and building websites.

AC: I actually wrote about this in my most recent newsletter — I'm one of the younger members of Talos, so I was born well after all of this started. It is so fascinating to me to hear about people who were out of college when the internet really started booming.

ML: Yeah, it was growing massively through the mid to late 90s, which was awesome. And then there was the .com crash, which was pretty rubbish. So, I found myself with a young family and less work than I wanted. This job came up, writing spam filters. This was before spam filters and certainly before spam was a big problem. So I thought, "Okay, that sounds fun, let's do that." And then we started detecting all of these weird and wonderful attacks. What we didn't know is we were detecting the first APT attacks. In trying to work out what was happening and what we were seeing, that kind of launched the career. So here we are over 23 years later, and cybersecurity has just grown massively. But it was entirely by accident that I ended up here.

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.

• Cisco Talos identified a fully-featured phishing-as-a-service (PhaaS) operator panel, branded "ARToken," that shares infrastructure, API contracts, and operational patterns with the EvilTokens platform documented by Sekoia and Microsoft in early 2026.
• The ARToken panel exposes 80+ API endpoints for device code phishing, Primary Refresh Token (PRT) persistence, email access, business email compromise (BEC) operations, and SharePoint exfiltration — all accessible to operators through a React-based dashboard.
• Analysis of the platform's publicly served JavaScript bundle reveals the complete post-compromise toolkit available to affiliates, including capabilities not previously detailed in public reporting on EvilTokens.
• The phishing kit deploys a seven-layer anti-analysis system combining client-side behavioral verification with XOR-encrypted payloads, a more sophisticated evasion approach than the server-side X-Antibot-Token mechanism documented in prior EvilTokens research.

Background: EvilTokens and device code phishing-as-a-service

In March 2026, Sekoia published a two-part analysis of EvilTokens, a PhaaS platform that abuses Microsoft's OAuth 2.0 Device Authorization Grant (RFC 8628) to capture victim tokens while bypassing multi-factor authentication (MFA) entirely. Microsoft confirmed the campaign's scale in April 2026, noting significantly higher success rates than previous device code attacks, AI-powered personalized lures, and a post-compromise pipeline that included automated device registration for persistent access.

By the time of Microsoft's publication, Sekoia had documented approximately 500 Cloudflare Workers domains and over 1,000 total phishing pages operating under the EvilTokens umbrella, with affiliates targeting finance professionals, HR staff, and logistics personnel across global regions.

EvilTokens' second-stage capabilities, revealed in Sekoia's Part 2 research, include an AI-augmented BEC pipeline chaining Groq-hosted Llama models for financial exposure scoring and GPT-4o-mini for email translation, producing three tailored BEC scenarios per compromised mailbox. The platform sells access at $1,500 one-time plus $500/month, with a standalone "Portal Browser" for $500 lifetime.

The lure in the wild: Vendor-impersonation invoice fraud

Most public reporting on EvilTokens covers the panel and the kit. What it has not shown is how an ARToken lure actually reaches an inbox. Talos recovered two near-identical messages, sent roughly four minutes apart on April 20, 2026, that initiate the chain. The tradecraft is targeted, not spray-and-pray.

The messages spoof an accounts-payable contact at a legitimate Wisconsin contractor, addressed to an accounts-payable recipient at a U.S. life-sciences company — abusing a real vendor relationship rather than inventing a sender. The lure theme is an outstanding-invoice query ("the following invoices appear to still be outstanding… advise when this will be processed"), the kind of message accounts-payable staff are conditioned to act on. Other features of note in this email include:

• The From header presents the vendor's real domain, but Reply-To quietly redirects replies to an unrelated domain — a classic reply-pivot that keeps any victim response away from the spoofed organization.
• All three checks fail: SPF, DKIM (body-hash mismatch), and DMARC (compauth=none reason=405). The display identity is not authenticated from the sending path.
• Each message carries short random hex strings and an inline signature image (pumber.png), consistent with light per-message mutation to frustrate exact-match content rules.
• The visible anchor text reads as the vendor's genuine SharePoint tenant: “https[:]//mononapfp.sharepoint[.]com/:f:/document/INV-IgCx1X50pgUjR7iAjZL2fuQaAW4GfKVs6wHT3BYv9sgwW7g”

However, the actual href points to a near-identical look-alike tenant — the vendor's name with the .com folded directly into the tenant label — under a different, attacker-controlled Microsoft 365 workspace. Because the destination is still a genuine sharepoint.com host, it inherits SharePoint's clean reputation: “https[:]//mononapfpcom.sharepoint[.]com/:f:/g/IgAdH_aaBPMcQbtINZzC1TsLARj3dHj63MnKjvnY-QJrKEc"

Discovery: The ARToken Panel

During investigation of phishing infrastructure targeting a Talos IR engagement, we identified a management panel at “dashboard-bl.pamconj[.]com” serving a React single-page application (SPA) with a 1.7MB compiled JavaScript bundle. The page title reads "ARToken Panel."

SPA architecture exposes all client-side code including routes, UI labels, component logic, and API endpoint paths in the JavaScript bundle regardless of authentication state. No credentials were required or bypassed.

The associated command-and-control (C2) API operates at “spx.pamconj[.]com”, and phishing lures deploy through Cloudflare Workers accounts including “clear90489058903-document.workers[.]dev”.

Linking ARToken to EvilTokens

The connection between ARToken and EvilTokens rests on multiple overlapping technical indicators:

• Identical API contract: ARToken's phishing kit issues POST /api/device/start with a JSON body containing userId, clientMode: "broker", login_hint, and redirect_url. The C2 responds with device_code, user_code, verification_uri, and expires_in matching the EvilTokens API contract documented by Sekoia exactly.

• Shared clientMode: "broker" semantics: This parameter instructs the backend to use Microsoft's Authentication Broker (WAM) flow for PRT acquisition. It is not a standard OAuth parameter it is specific to EvilTokens' implementation of persistent token capture.
• Matching deployment model: Both platforms deploy phishing lures to Cloudflare Workers using UUID-prefixed subdomain patterns. ARToken uses {uuid}-docviewer.workers.dev, {uuid}-onedrive.workers.dev, and {uuid}-adobe2.workers.dev. EvilTokens uses [service]-[random].[target]-s-account.workers.dev. The naming convention and lure themes (Adobe, OneDrive, document viewers) overlap directly.
• Identical PRT lifecycle:ARToken's API surface includes /prt/setup, /prt/refresh, /prt/renew, /prt/reacquire, and /prt/cookie, the same Primary Refresh Token persistence chain Sekoia documented as EvilTokens' core differentiator over traditional AitM phishing platforms.
• Shared operational model: Both platforms operate as multi-tenant PhaaS with isolated operator workspaces, Telegram bot notifications on token capture, subscription-based access, and template editors for lure customization.

Technical analysis: The phishing kit 

This client-side behavioral verification is notably more sophisticated than the server-side X-Antibot-Token mechanism (SHA-256 of secret + timestamp + "antibot" with 5-minute validity window) documented in Sekoia's EvilTokensresearch. The divergence is consistent with EvilTokens' known practice of selling anti-bot pages as a separate product through a dedicated Telegram bot. Affiliates may deploy upgraded or custom anti-analysis modules independently of the core platform.

The phishing payload itself fires on DOMContentLoaded and:

1. Attempts to steal any existing JWT from localStorage (key: artoken_jwt) for victim session correlation
2. Extracts the victim's email from the URL ?hint= parameter
3. Calls the C2 at /device/start with the hardcoded operator UUID 84eb384d-cd3e-4c90-a283-c960ce557913
4. Displays the returned device code with a countdown timer (default: 900 seconds)
5. Directs the victim to “microsoft.com/devicelogin”

The kit includes persistAfterPassChange: false, an explicit signal that the operator understands refresh tokens are revoked on password reset and must exfiltrate data or escalate to PRT before the victim responds.

XOR payload encryption

The JavaScript payload is delivered encrypted with a 16-byte XOR key ([233,69,224,219,53,48,213,165,119,243,77,151,101,148,15,227]), decrypted at runtime. This differs from EvilTokens' documented AES-GCM Web Crypto API encryption. The decoded sample analyzed here represents the inner payload after decryption consistent with EvilTokens' delivery model of encrypting phishing content and decrypting client-side to evade static analysis by URL scanners.

The full operator toolkit

The ARToken panel's API surface reveals the complete post-compromise workflow available to operators:

Token management and persistence

Once a victim completes device code authentication, their captured token appears in the ARToken dashboard. Operators can:

• Refresh tokens to maintain access
• Escalate to PRT via the /prt/setup → /prt/refresh → /prt/cookie chain, achieving persistence that survives password resets
• Export and backup tokens in bulk
• Import tokens from external sources (enabling cross-platform token trading)
• Share tokens with other operators via generated links with granular permissions

The UI advertises, "PRT-enabled - Persists across password changes."

Email operations (ARTSender)

The built-in BEC tool provides:

• Full Outlook inbox read access per compromised account
• Email sending as the victim with BCC batch support and configurable inter-send delays
• Inbox rule creation for forwarding and auto-deletion (evidence suppression)
• Keyword-based monitoring across all compromised accounts simultaneously
• Email attachment access and download

SharePoint and OneDrive access

Operators can browse, upload, download, and manage permissions on victim SharePoint sites and OneDrive files, enabling document theft and malicious file placement for lateral phishing.

Infrastructure automation

The panel integrates directly with Cloudflare's API for:

• Authenticating via API token or Global API key
• Listing deployed Workers
• Deploying phishing templates directly to Workers from the panel
• Managing allowed origins and worker name prefixes
• Configuring device code proxy servers

Desktop session browser (ARTBrowser)

A standalone Windows application, functionally equivalent to EvilTokens' "Portal Browser," enables operators to browse victim Microsoft 365 sessions using captured tokens outside the web panel. The admin configures a download URL through the settings panel.

Capabilities not previously documented

Several ARToken features extend beyond what Sekoia's research covered:

These features indicate the platform is more mature than a simple device code phishing kit — it is a complete BEC operations environment.

MITRE ATT&CK techniques 

Indicators of compromise

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

Welcome to this week’s Threat Source newsletter. 

The issue of AI in cybersecurity is often portrayed as a binary choice: either a force multiplier for our adversaries, or a tool bringing professional obsolescence. The reality is more nuanced. While AI certainly brings some advantage to attackers, it also offers advantages to the defender, notably in how we manage, index, and derive value from threat intelligence. 

Currently, our industry excels in the use and dissemination of indicators of compromise (IOCs). These atomic indicators fit neatly into key-value data stores and their value can be enhanced with added context, neatly structured in STIX/MISP format. However, this is only the tactical layer. 

Ultimately, we want the consumers of threat intelligence reports to develop their knowledge and to build a picture of the relevance of the threat to their own situation, along with understanding of how they can respond given their resources and constraints. This capability is conferred by the natural language found within strategic and operational intelligence briefings. 

These reports provide the context required for meaningful response, yet they remain notoriously difficult to index. We are often left with disparate incident reports, darknet monitoring, and malware analysis that fail to cross-reference effectively, further complicated by inconsistent naming conventions for threat actors. 

This is a problem that large language models (LLMs) may be able to solve. Although AI models have no real understanding of an issue, they can identify synonyms and relate entities across vast, unstructured datasets. This can only make the retrieval of relevant threat intelligence reports easier, and facilitate the generation of relevant advice to protect against threats. 

There are still issues to resolve. We need to be vigilant regarding the veracity of the data that LLMs ingest, and of the confidentiality of the queries made of such a system. However, the development of personal, domain-specific LLMs offers the possibility of a world of integrated threat intelligence where relevant reports from disparate sources can be easily retrieved, and specific advice returned to even the vaguest of queries. 

Rather than fearing AI’s potential negative effects on our employment, we can consider AI’s development as a powerful tool that enables access to threat intelligence reports and allows us to provide tailored actionable advice faster to those who need to know it. Ultimately, AI can help us do what we do best: making a difference and making the bad guy’s lives harder. 

The one big thing 

Cisco Talos is highlighting how Windows threats increasingly abuse the Component Object Model (COM) to execute malicious activities. While COM is a fundamental Windows technology for legitimate inter-process communication, malware families like Qakbot and WarmCookie hijack it for lateral movement, persistence, and evasion. Because COM functionality relies on opaque GUIDs and indirect vtable calls, it obscures the attacker's intent and makes manual analysis incredibly labor-intensive. 

Why do I care? 

Threat actors love COM because it provides convenient access to built-in Windows functionality while making static analysis a nightmare. By hiding malicious behavior behind indirect function calls, attackers easily bypass basic scrutiny and blend in with legitimate system processes. Adversaries are effectively turning Windows' own architecture against itself. If analysts aren't prioritizing COM during triage, they are likely missing critical pieces of the infection chain. 

So now what? 

Defenders must sharpen their skills in recognizing COM usage and translating evidence like ProgIDs and vtable offsets into human-readable actions. Leverage specialized tools like OleView.NET, IDA’s COM Helper, and DispatchLogger to map anonymous indirect calls to clear behaviors. Security teams should also build static hunting logic to track these threats. You can find a simplified YARA hunting rule for binaries referencing the Task Scheduler COM class in the full blog post. 

Top security headlines of the week 

FortiBleed campaign used custom FortiGate sniffer to steal credentials 
Security firm SOCRadar says the large-scale FortiBleed campaign targeting Fortinet FortiGate devices used custom sniffers to harvest authentication secrets from compromised firewalls and steal credentials. (BleepingComputer) 

Scattered Spider hackers plead guilty on Day 1 of trial 
Two men pleaded guilty in the United Kingdom this week to criminal charges stemming from an August 2024 cyber attack affecting Transport for London, the entity responsible for the public transport network in the Greater London area. (Krebs on Security) 

Klue says hackers stole credential from 2022 that led to customer data breaches 
Market research company Klue has confirmed that a credential dating back to 2022, which was part of a limited pilot, was used by hackers earlier this month to steal data from its corporate customers, including several cybersecurity companies. (TechCunch) 

New exploit bypasses Apple’s boot defenses, affects millions of iPhones 
Baked permanently into the device’s SoC, SecureROM is the first code an iPhone runs on startup and the foundation of Apple’s entire secure boot chain. The exploit chains a USB controller bug and a device firmware configuration weakness. (SecurityWeek) 

Windows 11 KB5095093 update rolls out new Point-in-Time restore feature 
This update introduces numerous new features, including a standout Point-in-Time Restore feature that allows Windows users to easily roll back their operating system, applications, and files to a previous point in time. (BleepingComputer) 

Can’t get enough Talos? 

AI is finding bugs faster. Now what? 
In this episode of Beers with Talos, the team is joined by Nick Biasini to unpack what attackers are doing with AI-assisted vulnerability discovery, review FIFA World Cup threat trends, and phish the Pope. 

Patching in the dark: Managing unknown threats in complex environments 
If you're tired of being told to "just patch," we understand. Amy and Pierre explore the logistical, technical, and business realities that make patching a complex, high-stakes operation rather than a simple button click — and break down the things defenders often miss that build true resilience in organizations. 

Hypotheses, telemetry, and human judgment: Inside Cisco Talos Threat Hunting 
Learn how Cisco Talos Threat Hunting uses hypothesis-driven methods and multi-domain telemetry correlation to find stealthy threats operating below automated detection thresholds. 

Upcoming events where you can find Talos 

• Black Hat USA (Aug. 1 – 6) Las Vegas, NV 
• DEF CON 34 (Aug. 6 – 9) Las Vegas, NV 

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: SECOH-QAD.exe 
Detection Name: Win.Tool.Procpatcher::1201 

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 

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

SHA256: 853baab97b1f3b03c1ffa55797e87867f5fb7ce33457411f56afd270cb395453 
MD5: 41acb30b9d662d48b7b4fc0ac3d4b79f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=853baab97b1f3b03c1ffa55797e87867f5fb7ce33457411f56afd270cb395453 
Example Filename: SignInfoConsole.exe 
Detection Name: W32.853BAAB97B.in12.Talos

Component Object Model (COM) is one of the Windows technologies that analysts regularly encounter but may not always prioritize during triage, as the manual analysis of COM functionality in binary executable files can be labor-intensive.

The post starts with a brief introduction into COM, following how binaries utilizing COM can be analyzed, and some examples of malware families and their usage of COM. The post concludes with a list of further resources.  

COM as Windows glue 

COM is an application binary interface (ABI) model for reusing software components. COM objects expose interfaces to client applications, and those interfaces can be consumed by multiple programming languages because the contract exists at the binary interface level rather than at a single language runtime level. COM is a fundamental, principal way for components written in different languages to communicate.  

Microsoft describes COM as a distributed, object-oriented system for creating binary software components that can interact with each other. COM is also the foundation for technologies such as OLE and ActiveX.

This language independence is visible in common scripting and automation patterns. The same COM object may be created from VBScript, PowerShell, Python, or C/C++. For example, a script can instantiate the WScript.Shell COM object and use it to read or write registry values, execute a command, create shortcuts, or access environment variables — and it can do it in a very similar way using different scripting languages supporting COM automation. 

DCOM extends the same model across the network 

Distributed COM (DCOM) extends COM so a client can activate and use COM objects on another system. At a high level, the local client talks to a proxy, the remote server exposes a stub, and the COM runtime transports the method invocation over Microsoft RPC.  

The existence of CoCreateInstanceEx API in a binary, with the appropriate parameters, can be used to distinguish between local COM and DCOM. DCOM extends local COM activation by allowing an object to be associated with a specified remote computer. DCOM is also explicitly represented in MITRE ATT&CK as one of the techniques and is described in Remote Services: Distributed Component Object Model, T1021.003. 

Classes, interfaces, and the registry 

Classes and interfaces are two foundational COM concepts. 

COM classes are templates for creating COM objects. A class is identified by a class identifier (CLSID), a GUID that uniquely identifies the component.

GUID is a 128-bit identifier used to uniquely identify COM-related objects and interfaces. The string representation of a GUID is common in the Windows registry, scripts, and configuration text. It is typically formatted as: 

{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} 

A GUID can also appear as a binary structure in a compiled executable. In a binary, the first three fields are typically stored in little-endian byte order, which is why byte-pattern searches for GUIDs differ from the familiar string form. Readers should be aware that many malware families assemble GUID structure dynamically on the stack before attempting to create a new object in order to make the analysis process harder. 

Interfaces are also represented by interface identifiers (IIDs), which also have the GUID's data type. Interfaces define methods an object exposes to clients. The foundational COM interface is IUnknown, which exposes functions QueryInterface, AddRef, and Release. Every COM interface ultimately derives from it. 

COM registration data is stored in the Windows registry. Classes can be inspected under HKEY_CLASSES_ROOT\CLSID, while interface registrations can be found under HKEY_CLASSES_ROOT\Interface. On a typical Windows installation, the number of registered classes can easily reach into the thousands and changes based on Windows version, optional components, and installed software. 

 A common example used in malware is the Windows Task Scheduler service. The newer Task Scheduler 2.0 COM class is commonly referenced by the CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}. The ITaskService interface has IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85} and provides access to the Task Scheduler service for managing registered tasks. ITaskService::Connect should be called before using other ITaskService methods. Older Task Scheduler 1.0 samples may instead use the ITaskScheduler interface, which appears in the WarmCookie case study below. 

A program usually loads a COM class by specifying its CLSID, requests a specific interface by specifying its IID, and receives an interface pointer which points in memory at the beginning of the virtual function table (vtable) for the object. The interface methods are called indirectly through a vtable.  

Without type information, the analyst may only see something like: 

call qword ptr [rax+38h] 

With the correct interface recognized and renamed, the same call can become meaningful, which is our main goal when analyzing malware utilizing COM: 

call qword ptr [pTaskServiceVtbl.Connect] 

Basic COM concepts for reverse engineers 

COM clients, servers, and ProgIDs 

A COM client is any code that obtains a pointer to a COM interface and calls methods through that pointer. A COM server is the component that implements the object behind the interface. The two sides may be in the same process, in different processes on the same host, or on different hosts through DCOM. Malware is most commonly just a COM client. Malicious COM servers are encountered less frequently and are outside of the scope of this blog. 

The client asks the COM runtime, implemented in ole32.dll or combase.dll, to instantiate a class (identified by a CLSID) and to return a specific interface (identified by an IID). The dwClsContext argument supplied to activation APIs such as CoCreateInstance tells COM which server locations are acceptable. For reverse engineers, the CLSCTX flags provide a useful context, as they indicate whether the sample is trying to load a DLL into its own process, talk to a local EXE or service, or reach a remote DCOM server.

 A ProgID, or programmatic identifier, is a human-readable registry entry that can be associated with a COM class. Examples include WScript.Shell, Shell.Application, Excel.Application, MSXML2.XMLHTTP and WinHttp.WinHttpRequest.5.1. The registry maps a ProgID to a CLSID, and higher-level languages often use the ProgID directly through functions such as CreateObject or PowerShell’s New-Object -ComObject. Native code can call CLSIDFromProgID to resolve the string to a CLSID before activation. In binaries, the analyst may therefore see either a readable ProgID string, a string-form GUID, or the little-endian binary representation of the CLSID. 

What CoCreateInstance does for an in-process server 

A typical native COM client starts by initializing the COM runtime for the current thread with CoInitializeEx or CoInitialize. In code that will communicate across process or machine boundaries, the client may also configure process-wide COM security with CoInitializeSecurity. After that, the client activates a class, receives an interface pointer, calls methods through the interface, and releases the pointer when finished. 

For an in-process server, CoCreateInstance is a convenience wrapper around the class-factory path. COM resolves the CLSID registration, locates the in-process server DLL for the current bitness, loads the DLL if necessary, and asks the DLL for a class object. That class object usually implements the interface IClassFactory. COM then asks the class factory to create the object and return the requested interface pointer. 

DllGetClassObject is the main activation export and COM calls it to retrieve a class object for the requested CLSID. DllRegisterServer and DllUnregisterServer are self-registration exports used by installers or regsvr32-style workflows to create or remove registry entries; they are not part of the CoCreateInstance call path. 

 A local-server COM EXE follows the same class-factory idea, but the registration points to an executable or service rather than an in-process DLL. The server process typically registers its class object with the COM runtime, and clients receive an interface proxy when the object lives outside the client process. DCOM extends this model to another machine and adds remote activation, RPC transport, authentication, and impersonation state. 

IUnknown, object identity, and vtable layout 

Every COM interface derives from IUnknown. The first three entries in a COM vtable are QueryInterface, AddRef, and Release, regardless of the higher-level interface being used. QueryInterface lets a client ask whether the object supports another interface identified by an IID. AddRef and Release implement reference counting so that objects can manage their lifetime across language boundaries, DLL boundaries and proxy/stub boundaries without relying on a language-specific garbage collector or destructor model. 

COM activation and call security 

COM has its own security model on top of normal Windows process, token, registry, and file-system checks. Security is most visible for local-server and DCOM objects as activation and method calls cross a COM process or RPC boundary.

Activation security controls whether a client can launch or connect to a COM server. The COM Service Control Manager checks launch and activation permissions when a client requests an out-of-process or DCOM object. These permissions may come from machine defaults or from application-specific AppID configuration such as LaunchPermission. A class can be registered and still fail activation if the caller’s token is not permitted, if remote activation is disabled, if the server is not configured for remote use, or if required marshaling information is unavailable. 

Malware samples that call CoInitializeSecurity or CoSetProxyBlanket are often setting up the identity and authentication context needed for WMI, DCOM, or another out-of-process COM interface. For static analysis, the constants passed to these APIs help identify whether the sample expects local-only access, remote access, impersonation, or delegation. 

Tooling for COM exploration 

The first step in COM analysis is usually identification of classes and interfaces used by malware and understanding interfaces together with functions present in their vtables. Tools such as ComView and OleView.NET allow researchers to inspect classes, interfaces, type libraries, proxy/stub information, and method layouts registered on a system. 

OleView.NET, developed by James Forshaw, is particularly useful since it combines a graphical interface with a PowerShell interface, making it suitable for both manual exploration and repeatable research workflows. 

ComView is an older tool still available through internet archive. ComView contains offsets (in decimal) of a function address from the beginning of the vtable, which allows us to identify which functions are being called in the indirect calls observed in compiled executables. In the ComView screenshot below that displays the details of the ITaskService interface, we see that the connect method has offset 40 (28h) from the start of the vtable so any indirect call to a register + offset 28h after a client obtains a pointer to the interface can be transcribed as ITaskService.Connect to improve our understanding of the code functionality.  

 A manual reversing process would contain the following steps: 

1. Find calls to CoCreateInstance, CoCreateInstanceEx, CLSIDFromProgID, CoGetObject, GetActiveObject, IDispatch::Invoke, or related APIs. 
2. Identify the CLSID and IID values passed into those calls. 
3. Look up the class and interface definitions in the registry, Microsoft documentation, OleView.NET, ComView, or a COM database. 
4. Map indirect vtable calls to interface methods based on architecture and interface layout. 
5. Rename types, variables, and calls in the disassembler so the COM workflow becomes readable. 

For this research, we created a simple task scheduler sample written in C, which uses COM to create a Windows scheduled task that runs notepad.exe two minutes after it is created. To simplify the development, the sample was generated by a large language model (LLM).  

We used our Task Scheduler sample to show how compiled binary code differs from its source code. We then reverse engineered the binary to show that once the ITaskService vtable is reconstructed, calls that initially look like generic indirect calls can be renamed to Connect, NewTask, GetFolder, RegisterTaskDefinition, and related methods.  

A faster way to reach the same analysis stage is to use a plugin for your reverse-engineering tool that maps GUIDs to human-readable code. For example, in IDA Pro, the standard COM Helper can identify relevant class and interface IDs and rename locations in the database.  

The remaining task for the analyst is to add the required interface’s vtable structure to the list of code structures currently in use. For example, for ITaskService, we can add ITaskServiceVtbl to IDA Pro and apply the type wherever an indirect call is related to the instantiated interface pointer.

Still, having a thorough understanding is recommended, so that analysts can recognize calls to COM related functions and identify related indirect calls in a binary.  

Applying the workflow to a Qakbot DLL 

Qakbot, also known as Qbot or Pinkslipbot, is a long-running modular banking trojan that has been active since at least 2007 and evolved into a general-purpose malware delivery platform used by financially motivated actors. Early versions focused on credential theft and online banking fraud, but later campaigns added functionality for system reconnaissance, persistence, browser and credential harvesting, email collection, command execution, command and control (C2) communication, payload delivery, and movement inside enterprise environments. Qakbot was frequently distributed through phishing emails, including hijacked email threads, and was used as an initial access and loader component for follow-on malware and ransomware operations. 

In the Qakbot DLL shown below, CoInitializeSecurity is called before the sample references IID_IWbemLocator, and CoCreateInstance creates an instance of the WMI locator class. The GUID is visible in binary form and can be used for type recovery inside the disassembler.

After the class and interface are identified, the next step is to apply the correct interface type to the returned pointer. In this case, the relevant structure is IWbemLocatorVtbl, and the method of interest is ConnectServer.

 The call through a register and offset maps to IWbemLocator::ConnectServer once the vtable type is applied. 

 Several plugins and scripts can accelerate this process. IDA includes a default COM Helper plugin, and Airbus CERT’s COMIDA and Frank Boldewin’s COM Code Helper scripts are also useful options. Binary Ninja users can apply similar type reconstruction workflows to make interface pointers and vtable calls easier to read. Recent Binary Ninja releases include COMpanion-related data rendering support. 

 For dynamic analysis, tracing can help by observing COM activation and dispatch calls at runtime. DispatchLogger, written by Talos’ David Zimmer, is one example of a DLL that can be injected into a process to proxy and log COM-related calls, including IDispatch usage. Researchers can hook or place breakpoints on COM-related calls to identify which interface is being instantiated. For IDA Pro users, the file “<IDAROOT>\cfg\clsid.cfg“ can be used as a reference to map a GUID. OleView.NET can also be run inside the analysis environment to help with the mapping. Dynamic binary instrumentation frameworks such as DynamoRIO can also be used for runtime tracing of COM behaviors. 

How threat actors use COM and DCOM 

Malicious actors use COM as it provides convenient access to existing Windows functionality and can make static analysis efforts more difficult with the functionality of the sample hidden behind indirect register-based function calls.

The following COM classes and interfaces are useful when triaging samples and building hunting logic.

Hunting for COM interfaces 

Static hunting for COM usage starts with known ProgIDs or GUIDs targeted in a hunt. Some binaries contain ProgID strings such as WScript.Shell, Shell.Application, MSXML2.XMLHTTP or WinHttp.WinHttpRequest.5.1. Others contain binary GUIDs without helpful strings. For hunting, we need to be careful about the on-disk byte order for GUIDs because the first three fields are usually stored little-endian in memory and in binaries. 

For the Task Scheduler CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}, the corresponding byte pattern is: 

9F 36 87 0F E5 A4 FC 4C BD 3E 73 E6 15 45 72 DD 

For the ITaskService IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85}, the byte pattern is:

C7 A4 AB 2F A9 4D 13 40 96 97 20 CC 3F D4 0F 85

 A simplified YARA hunting rule for binaries that reference the Task Scheduler COM class and interface might look like: 

 This kind of rule will also find legitimate software, so it typically needs to be tightened with detection names, submission dates, file types, family names, and other context to narrow the output. 

Notable malware families and COM 

Although there are many malware families utilizing COM, the following case studies demonstrate only a few notable malware families and their interaction with COM interfaces. 

Case study 1: Gh0stRAT/SimpleRemoter and Task Scheduler 

Gh0stRAT is a long-lived remote access trojan (RAT) whose source code has been publicly available for years, which has made it a convenient base for modified RAT families and actor-specific forks. MITRE ATT&CK describes Gh0stRAT as a remote access tool with public source code that has been used by multiple groups.  

The COM-relevant part of this example is the scheduled task creation logic in the RAT. The code uses Task Scheduler COM interfaces rather than simply invoking schtasks.exe. In process creation telemetry, the task creation may not appear as a direct schtasks.exe launch visible in EDR telemetry as COM calls run inside the malware process.  

Case study 2: Attor and BITS 

Attor is a Windows-based cyberespionage platform first publicly documented by ESET in 2019, with observed activity dating back to at least 2013. It is a modular implant built around a dispatcher component that manages loadable plugins, allowing operators to tailor functionality per victim. Reported capabilities include screen capture, audio recording, keylogging, clipboard capture, file collection and upload, process/window monitoring, persistence, Tor-based C2 communications, and GSM/GPRS device fingerprinting through AT commands. 

Background Intelligent Transfer Service (BITS) is another COM-exposed Windows service that attackers use, as it provides reliable file transfer functionality and an alternative service for C2 communications that may evade the scrutiny of EDR software.  

The IBackgroundCopyJob interface is used to add files to a job, set priority, determine state, and start or stop transfers. Malware using this interface may perform payload download, staging, or exfiltration through the same background transfer service used by legitimate applications. 

In the example used here, the Attor plugin uses IBackgroundCopyJob to communicate with a C2 server. The same plugin also contains COM exposed functionality for launching VBScript and PowerShell through COM client code, and through use of IWbemClassObject to enumerate installed endpoint security software. 

Case study 3: WarmCookie and Task Scheduler 

WarmCookie, also known as BadSpace, is a malware family that Talos reported as emerging in April 2024 and being distributed through malspam and malvertising. 

The COM-specific part of the workflow is visible in the decompiled function responsible for persistence. WarmCookie initializes COM, creates the older Task Scheduler 1.0 object using CLSID_CTaskScheduler, and requests IID_ITaskScheduler. It then creates a work item, configures flags and creates a trigger. In the screenshot below, the class and interface identifiers appear before the follow-on task and trigger creation calls. 

Conclusion  

COM is an integral part of the Windows programming model. As such, it will remain useful to malware authors wishing to utilize existing cross-platform functionality in Windows. COM is often used to hide malicious functionality behind the vtable based indirect function calls but equally for achieving persistence or moving laterally within victim environments.  

For threat researchers, the important skill is recognizing when a sample is using COM and then translating the evidence like ProgIDs, CLSIDs, IIDs, and vtable offsets into the human-readable name of the Windows component, interface, and method that are being used. 

Analysts in most malware cases do not need to fully master COM to analyze COM-based binary malware. They need enough practical knowledge to identify the client-side workflow, recover interface types, and understand whether the malware is using COM for task creation, WMI access, BITS transfers, shell automation, Office automation, local execution, remote activation, or persistence. 

Tools such as OleView.NET, ComView, IDA’s COM Helper, COMIDA, COM Code Helper, COMpanion plugin, and DispatchLogger can shorten the path from an anonymous indirect call to a meaningful API-level action. 

Further reading and tools 

• Microsoft Learn: Component Object Model (COM) and DCOM Remote Protocol overview 
• Microsoft Learn: COM technical overview and COM clients and servers 
• Microsoft Learn: CoCreateInstance, CoCreateInstanceEx, and CLSIDFromProgID 
• Microsoft Learn: IUnknown, IDispatch, and COM reference counting 
• Microsoft Learn: COM security with CoInitializeSecurity, CoSetProxyBlanket, LaunchPermission, and AccessPermission 
• Microsoft Learn: Task Scheduler ITaskService, legacy ITaskScheduler, and BITS IBackgroundCopyJob 
• Google Project Zero: OleView.NET tooling updates 
• James Forshaw: DCOM Research for Everyone! 
• James Forshaw: COM in Sixty Seconds! (well minutes more likely) 
• Mandiant/Google Cloud: Hunting COM Objects 
• Mandiant/Google Cloud: Hunting COM Objects, Part Two  
• Hex-Rays: COM reverse engineering and COM Helper  
• Malwarebytes Labs: Observing COM within Malicious Code  
• Tools: COM Code Helper, DispatchLogger, COMIDA, ComView 

Welcome to this week’s Threat Source newsletter. 

I love a Spielberg summer. His ability to imbue a sense of wonder, awe, curiosity, and connection means he’s in a league of his own. Granted, I haven’t felt that from him in a while, but when he hits? Oof. I feel like I need somebody to reach across and take off my sunglasses. 

So, Disclosure Day then. A group of friends and I visited a thankfully packed-out cinema at the weekend to bear witness to Spielberg’s latest dalliance with extra-terrestrial beings. 

Thar be no spoilers here, but I do want to touch on one of the film’s central themes: the idea that a group of people (let’s call them “the government”) believes they can predict how humanity will react to world-changing information based on historical data patterns. 

We often assume that information influences behaviour. Surely, if people have the right information, they'll make the right decision? If people understand the risk, they'll act. 

However, the older I get, the less convinced I am that human beings are rational creatures. 

Organisations know they should patch. People know they should use MFA. Leaders know they should practice an incident before it happens for real. 

And yet. 

Life is messy. Life, uh, finds a way. 

Most people aren't making decisions in a vacuum. They need to contend with limited budgets, workloads, competing business priorities, and a hundred other things demanding their attention. "Knowing" what they should do is the easy part. The hard part is finding the time, resources, urgency, and collective will to actually do it. 

As one of my colleagues recently wrote, even in a post-Mythos world, many of the controls most likely to protect organisations are the same ones we've been talking about for years. Segmentation. Backups. MFA everywhere. Understanding if your controls are doing what they’re supposed to be doing.  

And people can react to the exact same situation in very different ways. 

Take the film itself. One of my friends remarked on the way out, "What a load of twaddle." (Do you use "twaddle" much in the U.S.? If not, I recommend introducing it into more sentences.) Another friend thought it was entertaining, exciting, and thought-provoking. 

As Colin Firth’s character finds out in Disclosure Day, humans don’t always react the way you expect them to. I think that’s so important to acknowledge and work with, rather than against, in the cybersecurity field. Information is only one piece of the puzzle. Experience, priorities, personality, context, and a hundred other factors shape how people interpret and respond to that information. 

So, this message probably won’t land with 99% of you. But for the 1% that it might, go ahead and do that MFA install you’ve been putting off.  

Also, you’re running low on milk. Best pick some up on your way home.

The one big thing 

Cisco Talos detailed a new approach to reverse engineering that pairs local AI agents with traditional analysis tools like the VB6 disassembler vbdec. Instead of awkwardly bolting AI onto the software, vbdec exposes its parsed data through a live Component Object Model (COM) interface. Analysts can simply use natural language prompts to automate complex tasks like decompiling functions or building call graphs. This transforms the disassembler from a static viewer into a highly interactive, queryable data server. 

Why do I care? 

This methodology empowers analysts to generate custom workflows on the fly, completely bypassing the wait for new vendor features. It also solves a massive privacy hurdle: because the AI agent and disassembler share a local machine, sensitive binaries never leave your workstation. This architectural shift proves that any analysis tool holding structured data behind a GUI can become a powerhouse for agentic automation, saving defenders countless hours of tedious reverse engineering. 

So now what? 

Tool developers should start exposing their application data through external scripting interfaces like COM or other inter-process communication (IPC) protocols. If you are analyzing VB6 binaries, enable remote scripting in vbdec and point your preferred local AI agent at the provided operator briefing to start automating your tasks. Security teams need to lean into this paradigm shift, letting agents handle the exhaustive, repeatable grunt work while analysts focus on the actual analysis. Read the blog for more.

Top security headlines of the week 

ShinyHunters claims Council of Europe hack 
On Sunday, ShinyHunters added the Council of Europe to its Tor-based leak site, threatening to release more than 297GB of data allegedly stolen from the organization’s network. (SecurityWeek) 

Sweeping credential-harvesting heist compromises +30K Fortinet devices 
A large-scale cyber espionage and credential-harvesting operation is actively targeting Fortinet firewalls and VPN gateways, and has already compromised more than 30,000 Internet-facing devices across nearly 200 countries. (Dark Reading) 

Fileless Phantom Stealer targets browser credentials 
In addition to executing entirely in memory, the malware's infection chain incorporates other anti-analysis techniques designed to evade detection. (Dark Reading) 

Bug in FIFA World Cup internal system gave anyone ability to modify TV stream 
A security researcher said she was able to access several internal FIFA platforms due to a simple security flaw, which allowed her to watch and have full control of the TV stream of every World Cup game. (TechCrunch) 

The FBI built its own replica small town to simulate real-world cyber attacks 
Dubbed the Kinetic Cyber Range, the FBI’s small purpose-built town opened in February 2025 and features fully furnished houses, a hotel, a gas station and grocery mart, a courthouse, a hospital, roads, traffic lights, and a power company designed to mimic a real U.S. community. (TechCrunch)

Can’t get enough Talos? 

Patching in the dark: Managing unknown threats in complex environments 
If you're tired of being told to "just patch," we understand. In this episode of Talos Takes, Amy and Pierre explore the logistical, technical, and business realities that make patching a complex, high-stakes operation rather than a simple button click. Here are the things defenders often miss that build true resilience in organizations. 

Hypotheses, telemetry, and human judgment: Inside Cisco Talos Threat Hunting 
Learn how Cisco Talos Threat Hunting uses hypothesis-driven methods and multi-domain telemetry correlation to find stealthy threats operating below automated detection thresholds. 

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 Amy to discuss Talos Threat Hunting, the challenges of leading major product launches, and the grueling discipline of Ironman triathlons.

Upcoming events where you can find Talos 

• Black Hat USA (Aug. 1 – 6) Las Vegas, NV 
• DEF CON 34 (Aug. 6 – 9) Las Vegas, NV 

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: c0ad494457dcd9e964378760fb6aca86a23622045bca851d8f3ab49ec33978fe 
MD5: bf9672ec85283fdf002d83662f0b08b7  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c0ad494457dcd9e964378760fb6aca86a23622045bca851d8f3ab49ec33978fe 
Example Filename: f_000cd7.html 
Detection Name: W32.C0AD494457-95.SBX.TG 

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: e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba  
MD5: dbd8dbecaa80795c135137d69921fdba  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=e60ab99da105ee27ee09ea64ed8eb46d8edc92ee37f039dbc3e2bb9f587a33ba
Example Filename: u992574.dll  
Detection Name: W32.Variant:MalwareXgenMisc.29d4.1201