GigaWiper: Anatomy of a destructive backdoor assembled from multiple malware

1. A wiper inside a backdoor
2. Backdoor capabilities
3. How GigaWiper was assembled
4. Conclusion: Multiple destructive capabilities consolidated into a single implant
5. Defending against destructive threats
6. Microsoft Defender detections
7. Indicators of compromise

In October 2025, Microsoft Threat Intelligence identified destructive wiping activity and uncovered a sophisticated Go programming language (Golang)-based backdoor we now track as GigaWiper, a versatile implant that combines robust command-and-control (C2) capabilities with multiple destructive payloads, including disk wiping, fake ransomware, and system-level sabotage.

GigaWiper is particularly notable for its makeup. It’s not a single, purpose-built tool, but an amalgamation of separate malware families that were folded into GigaWiper as on-demand backdoor commands, giving threat actors the flexibility to choose their mode of destruction:

• A standalone wiper that operates at the physical disk level, overwriting raw disk content and removing partition metadata.
• A destructive command that derives from Crucio ransomware and encrypts files with randomly generated keys that are never saved, making decryption impossible.
• A wiping command that reimplements the logic of FlockWiper, a C-based malware reimplemented in Golang with additional multi-pass secure wiping.

The consolidation of multiple destructive capabilities into a modular backdoor reflects a notable shift in wiper malware, which are typically designed purely to destroy rather than to extort and carry real-world consequences. GigaWiper exemplifies threat actors investing in operational efficiency, merging standalone tools into unified platforms that reduce their deployment footprint while expanding their destructive capabilities.

In this blog, we provide a code-level analysis of GigaWiper’s architecture. We’re sharing these findings, along with Microsoft Defender detections and mitigation recommendations, to enable organizations and the security community to investigate and defend against GigaWiper and similar destructive threats.

A wiper inside a backdoor

Beginning in October 2025, Microsoft Threat Intelligence started observing compromised environments being wiped with destructive tooling. Looking closely at the intrusions, we observed two types of GigaWiper samples:

• Standalone wiper binaries
• Larger binaries with robust backdoor functionality

Both sample types are unstripped portable executable (PE) files written in Golang. Comparing the two samples showed that the standalone wiper’s code is fully embedded inside the backdoor as one of the commands.

The standalone wiper binary

The standalone wiper is an unstripped PE written in Golang. Instead of deleting individual files, it wipes at the physical disk level. It identifies physical drives, determines which drive contains the Windows installation, removes partition references from other drives, overwrites raw disk content, and then reboots the system.

The wiper starts by enumerating physical disks through Windows Management Instrumentation (WMI) using the following query, giving it the device identifiers and disk metadata it needs before deciding how to handle each drive:

Figure 1. Query for enumerating physical disks through WMI

The malware then calls main.FindWindowsDrive to determine which physical disk contains the Windows installation (for example, \\.\PHYSICALDRIVE0). With that drive identified, it iterates the remaining disk list and calls main.unallocateDrive on each non-Windows drive to remove their partition references. This is achieved with DeviceIoControl and IOCTL_DISK_CREATE_DISK, which reinitializes the disk’s partitioning metadata and effectively wipes the existing partition table entries. If successful, the malware prints to the console “Partitions removed successfully.”

Next, it proceeds to wipe each drive. It calls main.writeRandToDrive to overwrite each drive in chunks of size 0xA00000. The first byte of each buffer is randomized with crypto/rand.Read, while the rest is filled with zeros. If random generation fails, it uses the byte value “1” instead. This pattern might be intended to avoid detections or mitigations that look for conspicuous full-disk zeroing behavior.

After it finishes wiping the drives, the malware forces an immediate reboot by invoking Windows shutdown functionality with restart and zero-delay options.

The wiper binary as a backdoor command

Next, we analyzed the larger backdoor. The same wiper functionality is also present as one component of the backdoor. The code flow and function names in the larger backdoor are identical to those of the standalone wiper, with the wiper’s main.main routine implemented in the backdoor as the rabbit_tools_tool_wipe_main.WipeMain function.

Figure 2. Left: Standalone wiper functions. Right: The same wiper functions replicated in the backdoor

Backdoor capabilities

With the wiper routine overlap established, this section focuses on the backdoor’s additional capabilities. Beyond destructive functionality, the backdoor sets persistence and implements C2 communication over RabbitMQ and Redis. In analyzing these backdoor capabilities, we discovered that some backdoor commands contain code from additional malware families.

Persistence

The backdoor creates and uses the registry key HKCU\SOFTWARE\OneDrive\Environment to track its execution count. If the key is absent on the system, the malware determines that it’s running on the system for the first time and proceeds to create the key, setting it to “0”. It then creates a new scheduled task named OneDrive Update by running the following command before printing “Task created. Original process exiting.” and exiting the process. The scheduled task is configured to essentially run every minute in addition to running once on system startup.

Figure 3. Command that creates scheduled task for persistence

In subsequent executions, when the registry key exists and is greater than “0”, the malware increments it,  determines that it is running as a scheduled task (prints “Running from Task Scheduler…”), and continues execution normally.

Communication

GigaWiper uses two modes of communication:

• RabbitMQ over AMQP for receiving commands from the C2 server
• Redis server for updating command status and output

The malware decrypts a hard-coded configuration using AES with a hard-coded key. For example, one observed sample uses 185.182.193[.]21:5544 as a RabbitMQ C2 server, and 185.182.193[.]21:7542 for a Redis server, where it uploads results. The configuration also specifies the credentials to use to connect to the RabbitMQ and Redis servers.

To receive commands from the RabbitMQ C2 server, the malware declares a queue and binds it to a fanout exchange named “All”. Because “All” is a fanout exchange, any command published to it is broadcast to every bound queue across infected clients. To enable targeted commands, the malware also declares a topic exchange named “Topic”.  The backdoor binds the queue to “Topic” when the actor issues command 8 (See Commands section) and provides a routing key.

Each command sent by the C2 server is a cmd.Task structure with the following fields:

• task_id
• command_code
• args

To update the Redis server with command status and output, the malware sends it a cmd.Result struct with the following fields:

• error
• target_ip
• task_id
• target_computer_name
• output
• pwd
• time
• status
• work_status

Commands

GigaWiper logs several types of commands using specific categories:

• “always run command” – Commands that are meant to run continuously (like screen recording)
• “manage command” – Commands used to manage things on the system like services or the Registry
• “special command” / “shell command” – Modes of command 7

Each command is represented by a numeric command code from 1 to 20:

---

Command 1: Calls WipeMain, which is identical to the standalone wiper described in the last section

---

Command 2: Triggers a Blue screen error (BSOD) and prevents the device from booting

This is achieved by running a sequence of hard-coded destructive commands that disable Windows recovery, take ownership, and grant permissions to critical boot and kernel files before deleting them.

Figure 4. Series of commands that lead to BSOD

Command 3: Calls RanMain and BigBangExtortMain to trigger a file encryption process that imitates ransomware

The key and initialization vector (IV) that the malware uses to encrypt files are random and are not saved anywhere. The malware reads and encrypts each file, excluding files with extensions like .exe and .dll that are critical for the system to load. Each file is read and AES-CBC encrypted in chunks before being deleted with os.Remove. The file is renamed with the .candy extension.

It drops the following hard-coded image to ./image_danger.jpg and sets it as the wallpaper:

Figure 5. Image dropped by backdoor and set as the wallpaper

Command 4: Uses MinIO Client (mc) to upload a file to a remote storage

The path to the MinIO client to use is supplied in the command arguments alongside additional settings:

• IPandPort
• AliasName
• Username
• Password
• BucketName
• SourcePath
• MCPath – The path to MinIO Client (mc.exe) to use

---

Command 5: File encryption utility

This command bulk encrypts or decrypts files with AES-256 in Cipher Block Chaining (CBC) mode. The following are the command arguments:

• key
• iv
• path – The path to encrypt/decrypt (either a directory or a file)
• key_file
• enc – A mode that specifies whether to perform encryption or decryption

The server can specify a key and IV in the arguments. If in encryption mode but no key or IV were provided, the malware generates a random key and IV and stores them in key.txt.

If in decryption mode, the malware first tries to read the key and IV from the provided key file. If it was not provided, the malware attempts to use the key and IV sent as arguments.

Interestingly, the error message shows a glimpse of what running this command might look like from the actor side:

Key/IV required. Use -k/-i or –keyfile

---

Command 6: Runs the PE from the map RTYPE_map_string_cmd_appInfoStc[“6”]

We have not seen this structure populated in the binary. The logging message “Exec cmd wipe-file” suggests that this is meant to contain wiper functionality.

---

Command 7: This command has two types:

Type: shell command – Command for running PowerShell commands. The malware appends ;”|?????|$pwd” to the command. This causes the output of each command to include |?????|, followed by the current working directory. Then, the malware calls os.Chdir to change the working directory to the path output by $pwd, so the next command runs in that same folder.

Type: special command – When command 7 is run with one of the following arguments, it is considered a “special command” and handled as follows:

• purge_cmd_queue: Empties the queue of shell commands, then stops the process run by command 7 “shell command” if it exists
• purge_queue: Empties the queue of normal commands, then stops the process run by commands 6 or 13 if it exists (those are two of the “always run” commands)
• pwd: Sets a global flag to indicate the working status, which is sent to the server in shell command 7, and then proceeds to run pwd using shell command 7.

---

Command 8: RabbitMQ route manager; allows binding the queue to the “Topic” exchange to receive targeted, non-broadcast commands (Type: manage command)

This command receives a mode of operation (1/2/3), followed by a list of routing keys as arguments:

• Mode 1 – Binds each provided routing key
• Mode 2 – Unbinds each provided routing key
• Mode 3 – Pairs update mode: for each old,new pair, unbinds the old key then binds the new one

---

Command 9: Takes one screenshot per active monitor/display

The malware saves each screenshot to a PNG file in .\<timestamp\<monitor_index>.png (for example .\2026-06-10_12-30-00\0.png).

---

Command 10: Records the screen when the user is not idle (10s) and the system is unlocked(Type: always run command)

Recordings are saved in the folder C:\ProgramData\output.

---

Command 11: Runs the PE from the map RTYPE_map_string_cmd_appInfoStc[“11”] (Type: always run) command

We have not seen this structure populated in the binary. The logging message “Exec cmd keylog” suggests that this is meant to be a keylogger functionality.

---

Command 12: Calls WipeCMain to wipe the system

This command is like command 1 (WipeMain), but with a few important differences:

• It only wipes the drive with the Windows installation. Usually it is the C drive, hence the name WipeCMain.
• It performs secure wiping: It wipes the drive with multiple passes, each time overwriting it with different bytes (0s, 0xFF, random bytes…), and prints status messages between passes:
  • Pass 1 Time took: %s\n
  • Pass 2 Time took: %s\n
  • Pass 3 Time took: %s\n
  • …

---

Command 13: Runs the PE from the map RTYPE_map_string_cmd_appInfoStc[“13”]

The logging message “Exec cmd wipe32” suggests that this is meant to be another wiper binary. It is run as admin using the command:

---

Command 14: (not implemented)

---

Command 15: Collects system info by calling the function GRATClientInfo (Type: manage command)

The command arguments control the amount of info collected:

• long
• short

Collected system info includes:

• IP address
• Machine GUID
• CPU information
• OS information
• Network configuration
• Firmware
• User information
• Antivirus software information, collected by running the following command:

---

Command 16: Process manager (Type: manage command)

Arguments specify the process and operation to perform:

• process_name
• process_path
• process_id
• process_operation – Performs one of the operations below:
  • createProcess
  • resumeProcess
  • suspendProcess
  • exit (does nothing, returns empty response)
  • list
  • killProcess
  • processInfo – Returns the info below:
    • process_name
    • process_user_name
    • process_id
    • process_thread_count
    • process_memory_info
    • process_exe_path
    • process_status
    • process_error

---

Command 17: Service manager (Type: manage command)

This command is similar to the other manage commands, but for services. It has the following arguments:

• service_name
• service_display_name
• service_exe_path
• service_operation
  • create
  • delete
  • restart
  • query
  • start
  • list
  • stop

---

Command 18: Registry manager (Type: manage command)

On first execution, the malware runs rabbit_bin.RunOnceRegistryMain.gowrap1 in the background as a goroutine. On subsequent executions, the routine receives and returns input and output through Go channels. From there, it operates almost like an interactive session, persisting its position in the Registry between requests, and allowing the following operations (arguments):

• registry_root_key
• registry_key_path
• registry_key_name
• registry_value_entities
• registry_operation
  • show – Enumerates current key, subkeys, and values
  • navigate – Change current position to a new key and send its contents
  • back – Go up one level from current key
  • exit – Exits the current session
  • createKey
  • deleteKey
  • deleteValue
  • setValue

---

Command 19: Clears Windows event logs

First, the malware ensures that it’s running with Administrator privileges. Next, it deletes the System, Setup, Application, and ForwardedEvents event logs by running the following command for each:

Then, for unknown reasons, it prints the hard-coded string “kharbvnmhkjbkjb”.

Finally, it attempts to delete the Security event logs using wevutil.exe. If it fails, it prints the message “Failed to clear Security with wevtutil. Attempting manual removal…” and attempts to directly delete the log file C:\Windows\System32\winevt\Logs\Security.evtx.

---

Command 20: Starts a server so the attackers can remotely control the system in a VNC-like manner; allows keyboard and mouse control and streams the screen to the attackers (Type: always run command)

This occurs over TCP with the port provided as a command argument. The malware first deletes the existing firewall rule if it exists. The rule name impersonates legitimate Windows firewall rule names:

Finally, the malware creates rules with that name to allow inbound and outbound traffic to its own program over a port provided in the command arguments. The following command is run once with Inbound then with Outbound:

How GigaWiper was assembled

The standalone wiper, implemented as command 1, is only one part of the interesting anatomy of GigaWiper.

The backdoor contains code for two additional wiping commands: command 3, implemented as rabbit_tools_tool_ran_main_cmd_extort.RanMain, and command 12, implemented as rabbit_tools_tool_wipec_main.WipeCMain. Further analysis showed that, like the standalone wiper, these originated from two separate, older malware families previously used by the same threat actor.

In other words, the GigaWiper backdoor is an amalgamation of at least three standalone malware families, stitched together as commands within a single implant, and combined with new backdoor functionality.

RanMain and BigBangExtortMain

As mentioned, command 3 is handled by rabbit_tools_tool_ran_main_cmd_extort.RanMain, which calls rabbit_tools_tool_ran_main_bin.BigBangExtortMain to encrypt the files on the victim system and rename them with the .candy extension. This is a wiper disguised as ransomware. The key and IV are randomly generated but not saved anywhere, and no ransom note is dropped. As a result, the actor has neither the ability nor, apparently, the intent to ever decrypt the files.

The function BigBangExtortMain is notable. A function with the same name was used in the Crucio ransomware, which was documented in a Cybersecurity and Infrastructure Security Agency (CISA) advisory published in December 2023. GigaWiper backdoor command 3 is heavily based on Crucio’s code, leading to the assessment that the same threat actor developed both malware families.

Figure 6. Left: Crucio functions. Right: GigaWiper’s ran_main functions.

WipeCMain

Command 12 represents the third wiper family that was incorporated into the GigaWiper backdoor. This command is handled by rabbit_tools_tool_wipec_main.WipeCMain. It is very similar to command 1, WipeMain, except that it wipes only the Windows installation drive, and performs more secure wiping with multiple passes.

Our research revealed that WipeCMain is essentially identical to the standalone wiper that Microsoft tracks as FlockWiper. While FlockWiper was written in C, its logic appears to have been reimplemented in Golang within GigaWiper. In essence, the two variants follow the same core execution flow, and many of the strings are identical, though the GigaWiper implementation appears to be a more updated version. FlockWiper was first uploaded to VirusTotal in June 2025, months before GigaWiper was first observed in the wild.

Another notable detail is that the observed FlockWiper samples contain program database (PDB) paths referencing “GRAT”:

• A:\GRAT\CWipeNew\Release\CWipeNew.pdb
• E:\files\new\GRAT\CWipe\Release\CWipe.pdb

The name “GRAT” is also prevalent in several function names within the GigaWiper backdoor. Although the FlockWiper binaries do not include “GRAT” functionality, the PDB paths provide another link between the two malware families.

Figure 7. References to “GRAT” in function names

Conclusion: Multiple destructive capabilities consolidated into a single implant

GigaWiper is a backdoor with extensive operational capabilities that allow a threat actor to maintain control over infected systems, execute commands, deploy additional tooling, and ultimately trigger one of multiple destructive commands on demand. It allows the threat actor to operate with flexibility, enabling both quiet espionage activity and destructive wiping operations.

Our research reveals that GigaWiper was created by combining and reimplementing components from at least three previously separate malware families. This includes the wiping functionality, and the file-encrypting ransomware that leaves no way to decrypt the files.

We tied GigaWiper to both Crucio and FlockWiper based on code analysis, shared execution flow, function naming, and unique strings. Crucio’s code was the base for GigaWiper command 3, and FlockWiper was recoded in Golang and updated for GigaWiper command 12. In addition, the references of “GRAT” in both the FlockWiper PDB paths and GigaWiper function names provide an additional link between these tools, and suggests the possible existence of another related component or framework that has not yet been recovered.

Overall, these findings show the evolution of the actor’s tooling over time. Functionality was merged into a single robust backdoor, granting the actor more ways to control and destroy infected systems.

Defending against destructive threats

To harden networks against GigaWiper, defenders can implement the following mitigation steps:

• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in troubleshooting mode to turn off tamper protection temporarily without impacting the wider organizational security policy.
• Block direct access to known C2 infrastructure where possible, informed by your organization’s threat intelligence sources.

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Allow investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Microsoft Defender XDR customers can also implement the following attack surface reduction rules to harden an environment against techniques used by threat actors:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Tactic	Observed activity	Microsoft Defender coverage
Execution	Execution of malware components	Microsoft Defender Antivirus – Giga – Wiper – FlockWiper – CutBrooch Microsoft Defender for Endpoint – ‘WprFlock’ malware was detected – ‘WprCree’ malware was detected – ‘FlockWiper’ malware was detected – ‘GigaWiper’ malware was detected – Possible ransomware activity – Ransomware behavior detected in the file system

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Tool profile: GigaWiper

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Indicators of compromise

Indicator	Type	Description
633d4cbd496b1094495da89a64f5e6c31a0f6d4d1488411db5b0cba1cfe42001	SHA-256	GigaWiper backdoor
ce9ad5f6c12019f4aae5b189bd8ddf5bb09e75b06a0a587b25a855c65948c913	SHA-256	GigaWiper backdoor
f622ed85ef31ad4ab973f4e74524866fe1bb44f0965ad2b2ad796cd657a05bfd	SHA-256	GigaWiper backdoor
9706a192e2c1a1faaf0a521daf31c2af60ff4590e3f47bbb4abc227f42af0683	SHA-256	GigaWiper backdoor
3c30deb6556a94cfb84ae51798f4aecfae8c7358e55fdb321c5f2376579631cd	SHA-256	GigaWiper standalone wiper
440b5385d3838e3f6bc21220caa83b65cd5f3618daea676f271c3671650ce9a3	SHA-256	Crucio
12c39f052f030a77c0cd531df86ad3477f46d1287b8b98b625d1dcf89385d721	SHA-256	FlockWiper
db41e0da7ab3305be8d9720769c6950b4dc1c1984ef857d3310eb873a0fc7674	SHA-256	FlockWiper
185.182.193[.]21	IP address	GigaWiper C2
212.8.248[.]104	IP address	GigaWiper C2

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post GigaWiper: Anatomy of a destructive backdoor assembled from multiple malware appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/TmnfO1d
via IFTTT

Fake 7-Zip Installers Turn Devices Into Residential Proxy Nodes

Cybersecurity researchers have disclosed details of a new threat actor dubbed Lurking Lizard that has been operating an end-to-end malicious residential proxy business using an infrastructure comprising more than 230 lookalike domains.

The activity dates back to at least August 2022, according to DNS threat intelligence firm Infoblox. Once such campaign, observed earlier this year, involved the actor luring victims with a trojanized 7-Zip installer hosted on a domain named "7zip[.]com," covertly recruiting compromised devices as proxy nodes.

Lurking Lizard is also known to impersonate major proxy providers, including IPIDEA, SmartProxy (now Decodo), IP Royal, and 911Proxy, not to mention going to the extent of running fake "independent" review sites to drive traffic to its own scam storefronts. Interestingly, IPIDEA's infrastructure was dismantled by Google in an operation earlier this January.

Subsequent findings from Proxyway have uncovered that 773,087 unique IP addresses linked to SmartProxy were also present in a publicly available IPIDEA IP dataset comprising 16,192,293 unique IPs, indicating SmartProxy either "resells IPIDEA's infrastructure directly or uses it as a significant IP source."

WHOIS analysis and infrastructure fingerprinting suggest that Lurking Lizard is a China-based actor, with the illicit scheme also using popular VPNs and services like HeroSMS as decoys to distribute the proxy malware.

One of the notable aspects of the adversary's modus operandi revolves around acquiring domains when they expire to inherit their accumulated history and legitimacy, a technique known as drop-catching. In some cases, the attacker has taken advantage of the perceived legitimacy surrounding incorrectly referenced domain names (e.g., "7zip[.]com" instead of "7-zip[.]org") to use them to their advantage.

Further analysis of the IPLogger URL ("iplogger[.]com/mnWD") embedded within the samples tied to the 7-Zip campaign has uncovered that the same underlying infrastructure has been used to serve fake installers for 7-Zip, WhatsApp, tools falsely claiming TikTok and YouTube downloaders, and WireVPN.

The use of WireVPN branding represents the latest evolution of the campaign, using a multi-pronged approach to target users across operating systems, including Android, macOS, and Windows. One such Android app, called "wirevpn - Fast Unlimited Proxy" and developed by a U.K.-based firm named WEILAI NETWORK TECHNOLOGY CO., LIMITED, has amassed more than 1 million downloads, although it's unclear if these downloads are organic.

"In the original 7-Zip campaign, victims were directed to malicious installers through tutorial content, search-driven discovery, and lookalike domains," Infoblox said. "Whether similar techniques are driving users to the current desktop variants is unclear, but the mobile applications may serve as an additional acquisition channel."

It's also unclear if the same proxy functionality -- i.e., an exit node funneling third-party traffic through victims' devices -- is present in the mobile applications, and if it's just limited to the desktop applications. Regardless, they paint a picture of what appears to be an unlawful proxy business that fuels a coordinated ecosystem spanning victim acquisition, proxy infrastructure, marketing, and monetization.

The result is an end-to-end operation that goes through two distinct stages:

• Trojanized installers, mobile applications, and other lures recruit victim devices into an actor-controlled proxy botnet.
• The pool is then monetized through lookalike proxy service brands, while fake review sites help drive traffic to the actor’s storefronts.

"We are struck by the parallels between the recently exposed criminal activity in the residential proxy space and malvertising that plagues affiliate advertising," Infoblox said. "There's an obvious story: Your TV may be part of a giant botnet conducting attacks across the internet. But the real story is far more complex, and solutions are still elusive."

"Rather than operating a single malware campaign, Lurking Lizard manages multiple stages of the residential proxy lifecycle for several years, from acquiring victim devices through to marketing and selling access to the resulting network."

The development comes days after Google announced that it had significantly degraded the NetNut (aka Popa) residential proxy network that turned at least 2 million devices, such as smart TVs and streaming boxes, into conduits for unauthorized network traffic through malware-laced SDKs that either come pre-installed before purchase or through apps containing hidden proxy code.

"This creates serious risks for unsuspecting device owners, as their home IP addresses can be used by attackers as a launchpad for hacking and other unauthorized activities," Google said. "Consequently, users can have their legitimate traffic flagged as suspicious, or blocked by their service providers."

from The Hacker News https://ift.tt/Vo2O9GX
via IFTTT

AI Coding Agents Found Triggering Endpoint Security Rules Built to Catch Attackers

Sophos looked at a week of its own endpoint data and found that AI coding agents such as Claude Code, Cursor, and OpenAI Codex are setting off detection rules written to catch human intruders.

The agents are not malicious. They just do a lot of things that, to a behavioral engine, look exactly like an attack.

Decrypting browser credentials, listing what sits in Windows' credential store, pulling files down with built-in system tools, writing to the startup folder: these have long been high-signal to defenders.

What has changed is who is generating it. On the machines Sophos watched, it was often a developer's AI assistant going about ordinary work.

What set the alarms off

The analysis draws on seven days of telemetry from June 2026, taken from Sophos's behavioral engine on Windows and counted by unique machines, not raw event volume. It is a narrow window on one vendor's fleet, not an industry census.

Sophos's charts put credential access at 56.2 percent of the blocked activity and execution at 28.8 percent: agents reaching for stored secrets, or running code the way attackers do.

The biggest credential-access rule, at 42.6 percent of that group, fires when a process uses Windows' built-in Data Protection API, or DPAPI, to decrypt the browser's stored credential data. Sophos calls GStack a widely adopted skill pack for coding agents.

Its /browse skill does exactly that, running PowerShell that calls DPAPI to unlock saved browser data. Sophos caught it running under Claude Code. In context, it is almost certainly browser automation on the user's behalf. To the detection engine, it is credential theft, and the rule is right to fire.

Some Python examples looked worse on paper. In one instance, Claude Code shut down the running browser and ran a script that pulled data from its credential store.

Separately, it ran cmdkey /list to enumerate the credentials Windows Credential Manager was holding. Sophos notes that Claude Code here ran with its --dangerously-skip-permissions flag set, a mode Anthropic's own documentation warns against and tells administrators how to block.

When one approach fails, an agent tries another. OpenAI Codex did just that, fetching a Python installer from the real python.org, starting with certutil. That was blocked, so it switched to bitsadmin. Both are legitimate Windows utilities that attackers routinely abuse to pull payloads, living off the land.

The target was harmless, but Sophos's point is that this pivot-when-blocked behavior is what separates a live attacker from a static script, and benign agents now do it too.

Cursor tripped a persistence rule by using PowerShell to drop a startup-folder script that would run every time the machine booted. Sophos could not confirm what the script did, but writing to startup outside a trusted installer is the kind of thing defenders flag on sight.

AI agents on both sides of the line

The flip side is already visible. A month earlier, Sophos documented an attacker who used AI agents to build and test malware against EDR products, one of them running Claude Opus 4.5 to coordinate the work.

That was development-time: agents helping an attacker write better tooling. Agents get turned on their own users at runtime, too. In a separate case, researchers showed a coding agent could be tricked into running attacker code through poisoned inputs, a chain that can slip past EDR because the agent is acting inside the user's trusted session.

These are separate events with different rules firing, but they share a surface: browser credential calls, LOLBin downloads, and startup writes now come from benign agents, attacker-run agents, and hijacked agents.

That is why the raw action tells you less than it once did. And it sits inside a bigger change in how intrusions look. CrowdStrike's 2026 Global Threat Report found 82 percent of 2025 detections were malware-free, with attackers moving through valid credentials and trusted tools instead of dropping files.

That shift is what pushed detection toward behavior in the first place. AI agents now generate the same behavior for ordinary reasons, crowding the exact signal defenders came to rely on.

What it means for defenders

If developers run these agents under their own accounts, expect endpoint rules to fire on their machines. Sophos's answer is to split the rules by what they catch. Execution noise from an agent retrying a download or emitting oddly formatted PowerShell can usually be scoped.

Key the rule to the agent's parent process (claude.exe, cursor.exe, and their child processes), its workspace or temp path, or the reputation of the download target. That stops a known agent doing ordinary work from generating alerts.

Credential-touching behavior is where you hold the line. Decrypting browser credentials or enumerating Credential Manager does not become safe because an agent did it instead of a person, and an agent should not inherit blanket access to credential stores just because it runs under a trusted user. If the noise comes from Claude Code's --dangerously-skip-permissions mode, disable that mode through managed settings.

Sophos calls this an early read, not a verdict, and notes the shift is still small even if the direction is clear. The open policy question is what a coding agent should be allowed to touch on an endpoint at all, and credential stores are a sensible place to draw the first line.

from The Hacker News https://ift.tt/c3TDgrZ
via IFTTT

Protecting Microsoft at AI speed: How SFI proactively hardens our cloud

AI models have reached a threshold where they exhibit expert-level capabilities in vulnerability discovery, exploit chaining, and proof-of-concept generation. As AI-powered vulnerability discovery matures, every organization that builds or runs software at scale needs continuous proactive evaluation to ensure security controls are correctly implemented, layered effectively, and working as intended in production.

At Microsoft we encompass these security requirements, along with threat knowledge and operational frameworks in our Secure Future Initiative (SFI), to guide what a well-defended cloud service looks like. But defining the requirements is only the start. Meeting them means continuously evaluating our live services against them, at AI speed.  

That is why Microsoft built a multi-agent AI system that proactively evaluates and hardens our cloud infrastructure—matching the speed, scale, depth, and quality needed for our unique hyper-scale production environments. This system is purpose-built to evaluate Microsoft’s own cloud services against our stringent security requirements and make our infrastructure harder to compromise. While this is an internal capability and not available as a customer-facing product or service, the insights and patterns we develop through this work will inform how we improve our products over time. This system complements existing tools in Microsoft’s security ecosystem. For example, this system incorporates code-level vulnerabilities, including from systems like codename MDASH and adds configuration, identity, network, and runtime context, to assess overall service security posture. 

A modern AI architecture for proactive defense 

Vulnerabilities don’t just live in code. They emerge from the interplay between how a service is built, configured, deployed, and connected. Consider a cloud service where the application code passes every security review, the identity configuration follows least-privilege policy, and the network rules restrict inbound traffic as designed. Individually, each component is compliant. The system evaluates the service as a whole and may find that a combination of a permissive service-to-service trust relationship, a token scope that grants broader access than the service requires, and a deployment configuration that exposes an internal API to an adjacent network tier creates a composite vulnerability that no single-component review would surface.

At its core, the system employs a multi-tier agent hierarchy: orchestration agents for workflow management, analysis agents that specialize in security reasoning and are grounded in Microsoft’s threat intelligence—including emerging patterns and threat actor activity—and evidence-gathering agents that investigate across code repositories, infrastructure definitions, identity configurations, runtime settings, network topologies, and live resource states.  

The result of this multi-stage analysis is a comprehensive security understanding of each service that goes beyond what any single analysis method can provide on its own. Compared to traditional human-led security reviews that take weeks, the system compresses the same depth of analysis into hours. 

How it works: The system follows a multi-stage analysis pipeline, where each stage builds on the one before it:

1. Profiles each service architecture to understand components, data flows, trust boundaries, risk exposure, and more. 
2. Enumerates applicable security controls based on SFI requirements across identity, network, tenant isolation, engineering systems, and detection domains. 
3. Verifies control implementations against real-world code, configurations, and cloud resources. 
4. Evaluates defense-in-depth coverage to help ensure layered protections exist across all control domains. 
5. Identifies where controls are missing, misconfigured, or brittle, and maps the compensating controls that determine whether a gap is exploitable in practice. 
6. Produces compensating controls and durable fix recommendations for immediate-risk reduction while driving lasting remediation. 
7. Continuously learns and improves by incorporating feedback from security reviewers and service teams, and by tapping into Microsoft’s evolving threat intelligence to adapt to new patterns. 

Core design principles  

The analysis pipeline is shaped by four principles that determine how the system reasons about security: 

1. Frontier-ready architecture

The system is built with modular model interfaces that can take advantage of new frontier capabilities as they emerge. New models, enhanced planning, and execution capabilities can be integrated behind stable agent interfaces—preserving existing tooling, orchestration, knowledge, pipelines, reporting, and governance.  

2. Compositional risk reasoning

The system uses “what-if” agentic ideation to reason compositionally about risk. It explicitly explores how individual security gaps can chain together into multi-step attack paths. For example, a minor misconfiguration in identity, combined with a seemingly unrelated network exposure, and a missing data encryption control, might together enable a serious breach. Modern attacks are often complex sequences rather than single bugs, and the system is designed to help identify and analyze them. By running diverse models and large-scale reasoning trials in parallel, the system explores an expansive space of scenarios that traditional static analysis or single-scan tools would miss. 

3. Service-specific adaptation

Cloud services aren’t one-size-fits-all, so security analysis shouldn’t be either. Rather than applying a fixed checklist, the system builds a service-specific understanding of each service it analyzes. It profiles the service in depth—identifying its components, mapping data flows, locating trust boundaries, and determining which security controls should apply given that service’s unique architecture and risk profile. If a service uses a novel pattern, a microservices architecture spanning multiple codebases, or an agent-to-agent communication model, the system adapts its analysis to account for those patterns. This adaptive approach, guided by current SFI requirements, means that the system can tackle emerging cloud paradigms that don’t fit traditional security checklists.

4. Defense-in-depth evaluation

A key focus area for SFI is layered defense. The system asks two questions: “What vulnerabilities exist?” and “Where does this service lack multiple lines of defense?”. It evaluates whether critical security domains have overlapping, robust controls, and it flags any missing or brittle layers—even if no immediate exploit is identified.

For example, the system will highlight a scenario where a service might have a weak network segmentation or an overly permissive admin role—even in the absence of a known attack—because those gaps mean a single failure could lead to a compromise.

This forward-looking, “assume breach” analysis embodies the Zero Trust and defense-in-depth principles reinforced by SFI. In an era when AI-assisted attackers can enumerate systems faster and chain together weaknesses more systematically, ensuring redundant safeguards is increasingly critical.  

The assurance tree: SFI in action 

At the core of the system are the SFI engineering and security principles: a structured body of security requirements shaped by years of hardening the Microsoft infrastructure. These requirements guide what the system evaluates, how it reasons about risk, and the recommendations generated. When security expectations evolve—whether to address a new class of threats or incorporate lessons from remediation—the system’s reasoning evolves with them. The assurance tree is how we express these requirements: a structured, hierarchical map of security controls that the system expects a service to have in place, tailored to that service’s usage and design.

As the system profiles a cloud service, it generates an assurance tree tailored to that service. At the top level of the tree are the fundamental security domains, that map to the SFI pillars. Each of these domains is recursively decomposed into more granular controls and sub-controls tailored to the service. For instance, Identity security decomposes into controls for password policies, OAuth token handling, and MFA enforcement—down to verifying that the service’s code correctly validates a JSON Web Token’s issuer and expiration. The assurance tree guides the system’s evidence-gathering agents to verify that thousands of expected controls are in place and effective—or to identify where something is missing. 

This approach turns security from an open-ended hunt into a systematic verification of the SFI requirements: the system is essentially asking, “Have all the security measures that should protect this service been properly implemented?”. Crucially, it goes further—considering how individual gaps might combine, helping to ensure that even combinations of missing controls are identified and addressed. 

Proven results: From theory to practice 

Within a few months, the system has enabled Microsoft security engineering teams to proactively harden our cloud services. It generates findings and recommendations which our security engineering teams then validate and implement. Because the system evaluates the whole service in context and reasons about the severity and exploitability of each issue before surfacing it, its findings have proven high quality and actionable: more than 90% have been confirmed as genuine security issues by our security engineers, enabling proactive action to improve security posture. Just as important as the volume and precision of findings is their nature. Many issues the system discovers are nuanced, cross-domain vulnerabilities that wouldn’t have been caught by traditional methods. For example, the system has uncovered security gaps that only become apparent when considering code, configuration, and cloud resources together—the kind of issue that isolated scans or compliance checklists could overlook.  

This capability allows us to enhance how we do security reviews. Traditionally, a deep security review of a complex service might span weeks of effort by multiple domain experts. The system can achieve a thorough review in a matter of hours—allowing teams to assess more services, more frequently.

The path forward: Applying these principles in your environment

If you are responsible for security at your organization, the key question is whether your defenses are keeping pace. AI models will continue to evolve. The organizations that are hardest to compromise will be the ones that have layered, verified controls already in place—not the ones that react fastest after something is found.

Based on what we have learned from building and operating this system, here are three principles any organization can apply now:

1. Go beyond code scanning to system-level discovery. The most consequential issues emerge not from a single bug, but from how factors including code, configuration, identity, and network interact in production. Collect rich signals across these domains and evaluate your services as composed systems, not isolated components. Prioritize composite attack paths over individual findings. 
2. Move beyond known vulnerability patterns to proactive defensive controls. Traditional scanning asks, “Is there a known bug here?” Proactive hardening asks, “Does this service have comprehensive controls and layered defenses?” Reason about not just vulnerabilities, but controls, and how defense-in-depth coverage can improve protection before a specific exploit is discovered. 
3. Integrate AI to drive proactive prevention at machine speed. The same AI capabilities that accelerate vulnerability discovery can be applied to continuously evaluate whether security controls are correctly implemented, layered effectively, and working as intended. Organizations that adopt AI-powered proactive evaluation will identify and close gaps faster than those relying solely on periodic manual review. 

For deeper guidance on implementing AI-powered defense for an AI-accelerated threat landscape, customers can review Secure Now guidance for AI‑powered security and proactive defense. Any customer with a Microsoft Entra ID can access it. Microsoft Security customers will also have access to capabilities that enable them to assess their exposure and take action. 

Moving forward, we will share more about how we are scaling our response operations to match machine speed and how SFI’s engineering practices are evolving for this new reality.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity. 

The post Protecting Microsoft at AI speed: How SFI proactively hardens our cloud   appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/7C4LDaS
via IFTTT

HPC AI Workloads Need Runtime Security. The Architecture Already Exists.

The US Federal Government is committing $600 million to build one of the world’s most advanced AI infrastructure systems. Executive Order 14363, the Genesis Mission, connects national laboratory supercomputers across nuclear simulation, biodefense, energy grid modeling, and every major scientific domain. Fifty-one organizations signed on, including NVIDIA, OpenAI, IBM, Microsoft, AWS, Google, and Oracle.

The security framework governing these workloads was not written for this scale of use.

NIST SP 800-234, the High-Performance Computing Security Overlay, is well-constructed, tailoring 60 controls across four security zones, building on the SP 800-53B moderate baseline. It was designed for deterministic HPC workloads such as climate simulations, finite element analysis, and computational fluid dynamics. These workloads share a common attribute: code that runs the same way, every time, and behaves predictably under well-understood inputs. The security controls governing those workloads assume you can scan at the perimeter, clear memory between jobs, and attest to integrity at load time.

AI workloads break every one of those assumptions.

SentinelOne has submitted a formal proposal to the NIST HPC Security Working Group regarding this gap, and NIST has acknowledged it. We have a post on LinkedIn to share our proposal, and welcome commentary from across the industry.

The supply chain problem just got a lot more dangerous

This spring, in just three weeks, three AI-driven supply chain attacks targeted widely deployed software: LiteLLM, the most-used AI infrastructure package in Python development environments, Axios, the most-downloaded HTTP client in the JavaScript ecosystem, and CPU-Z, a trusted system diagnostic tool with a legitimate signed binary from the official vendor domain.

SentinelOne stopped all three on the same day each attack launched, with no prior knowledge of any payload.

The most important aspect of this outcome is how these attacks were stopped, and why signature-based detection couldn’t work. Each attack arrived through a trusted delivery channel. LiteLLM was compromised after credentials were stolen via Trivy, a security scanner. The attacker published two malicious versions to the PyPI repository. In at least one confirmed case, an AI coding agent with unrestricted permissions auto-updated to the infected version, meaning there was no human review or approval step before the payload ran. The Axios attacker exploited a legacy access token that the project maintainers had forgotten to revoke, bypassing every npm security control. CPU-Z attackers targeted the vendor’s distribution infrastructure directly; anyone who downloaded from the official website received a properly signed binary containing a payload. In all three cases, while the authorization chain was legitimate, the intent was not.

This is the defining characteristic of modern supply chain attacks: the workflow is verified, but the intent has been subverted. Every perimeter control, signature library, and reputation lookup checks authorization and passes. These attacks were designed to exploit that gap, and they ran at machine speed through automated pipelines with no human checkpoint.

To put this into the context of HPC and AI workloads running at scale, a compromised Python package in a developer’s environment is a serious incident; a poisoned training pipeline on classified biodefense data on a national laboratory supercomputer is on a different order of magnitude. The model it produces may be correct 99.9 percent of the time and adversarially wrong under precisely targeted conditions. No perimeter scan, signature check, or load-time integrity verification will catch it after training completes.

Where the current framework falls short

Of the 60 controls SP 800-234 tailors, three bear directly on AI workload protection, and each carries a documented gap. In a fourth area, supply chain, the overlay does not tailor at all.

• SI-3 (Malware scanning): The control acknowledges that real-time scanning is most effective but explicitly permits tailoring for performance on HPC systems, deferring to perimeter scanning before data reaches the compute zone. For traditional HPC workloads, that tradeoff may be defensible, but for AI workloads, it leaves behavioral analysis of the execution process completely unaddressed. A poisoned training run that executes within the expected statistical range of a training job looks like legitimate compute to a perimeter scanner.
• SI-4 (System monitoring): The control notes that high-speed data flows in HPC environments can overwhelm standard monitoring tools, and lacks AI-specific monitoring requirements or telemetry collection requirements from execution pipelines. The practical interpretation of this is: monitor what you can, accept the gap for what you can’t. On infrastructure running AI at scale, that gap creates a primary attack surface.
• SC-4 (Information in shared resources): Requires GPU memory clearing between user reassignments. It addresses data residency at the transition but does not address runtime behavioral monitoring of workloads during execution, side-channel attack detection, or anomalous compute-pattern identification while training is active.
• SR family (Supply chain risk management): The overlay carries all 12 moderate-baseline SR controls forward from SP 800-53B, with no HPC or AI-specific guidance, and supply chain is not among the 14 categories it tailors to. The SR controls still address only the conventional software and hardware supply chain; they say nothing about training-data provenance, model-weight integrity, or pre-trained-model validation, and the framework defines no AI equivalent of a software bill of materials. LiteLLM, Axios, and CPU-Z all arrived through legitimate software supply chain channels. AI workloads carry that same exposure one layer deeper, in the data and model artifacts that software trains on, which is exactly where the overlay is silent

AI Runtime Threats

The attacks against AI workloads on HPC are not theoretical, and they are not detectable at the perimeter.

• Training data poisoning scales at rates most security teams are not equipped to respond to. Research¹ across 41 studies documents attack success rates exceeding 60 percent from manipulation of 100 to 500 training samples, a fraction of a percent of a typical dataset. Poisoning as little as 3 percent² of training data achieved 41 percent attack success rates in code-generating models. OWASP’s LLM Top 10³ documents the consequence. Backdoors leave model behavior intact until a specific trigger activates adversarial outputs. The model ships, it gets deployed, and operates correctly, until it doesn’t. No post-training audit reliably catches a well-designed poisoning attack.
• GPU side-channel attacks are executed remotely by a co-tenant workload on shared GPU infrastructure; no physical access is required. The NVBleed research demonstrated covert channel attacks on NVIDIA NVLink, achieving over 91 percent accuracy in recovering data-dependent information from co-tenant GPU workloads on a shared fabric. The BarraCUDA research demonstrated the extraction of neural network weights via electromagnetic side channels from NVIDIA hardware. Both attack classes execute during active training, not at job transition. If your HPC environment runs multiple projects or security classifications on shared accelerators, the co-tenancy model is an active attack surface today.
• Inference pipeline compromise survives load-time integrity checks. A model with clean weights at deployment faces attacks through three vectors: hot-swap modification of serving configurations while inference runs; preprocessing and postprocessing layer injection that alters inputs before they reach the model or modifies outputs before delivery; and adversarial input manipulation that triggers targeted misbehavior in a model that appears fully operational. For AI serving safety-critical inference, each is a security risk, not just a research concern.

The characteristic that makes AI workloads uniquely difficult is persistence. A compromised simulation may produce visibly wrong results, but a compromised model can produce correct results the overwhelming majority of the time and adversarially wrong results under precisely targeted conditions. By the time anyone has reason to investigate, the window for recovery has often closed.

Securing HPC AI Workloads

We know the technology required to address these gaps exists and has been proven at scale in environments with performance constraints far tighter than those in HPC. What is needed is a well-defined architecture that enables the secure execution of large-scale AI workloads.

Dedicated security compute. Runtime security that shares CPU resources with the workload it monitors can be starved of CPU time under heavy load and interfered with by a workload that achieves kernel-level access. The SPiCa research demonstrated that eBPF monitoring pipelines can be manipulated from within the kernel by rootkits filtering events before they reach the analysis engine, meaning that a co-scheduled monitor is not a reliable monitor.

Every other infrastructure function on an HPC node has dedicated resources. The job scheduler, the filesystem client, and the out-of-band management plane. Security monitoring is infrastructure and should be afforded the same dedicated resources.

Modern HPC nodes have 128 to 256 CPU cores. One reserved for security monitoring is less than one percent of the available compute. Linux kernel CPU isolation via isolcpus, nohz_full, and rcu_nocbs is production-proven in high-frequency trading and real-time systems, with bounded, predictable overhead.

eBPF-based behavioral telemetry at the training layer. Effective monitoring of an AI training pipeline means continuous observation of compute behavior profiles, memory access patterns, GPU utilization, and inter-node communication, with behavioral baselines established for approved training configurations. A poisoning attack that executes within expected statistical ranges is not visible to a perimeter scanner, but it is visible to a behavioral baseline that knows what the training job should look like.

This is the same principle that SentinelOne’s on-device Behavioral AI detected for LiteLLM, Axios, and CPU-Z. The LiteLLM detection flagged a Python interpreter executing Base64-decoded code in a spawned subprocess. The CPU-Z detection flagged an anomalous process chain: cpuz_x64.exe spawning PowerShell, which spawned csc.exe, which spawned cvtres.exe. CPU-Z doesn’t do that. The behavioral baseline knew what legitimate execution looked like, and in these cases, that behavior was the decisive signal.

Cloudflare uses an eBPF-based architecture to mitigate DDoS attacks exceeding 7 Tbps. SentinelOne uses it to detect and stop threats in under one second across enterprise fleets. A training job that begins writing to unexpected locations, establishing anomalous inter-node communication, or deviating from its expected compute profile is detectable at runtime, before the model completes training. The performance argument against runtime monitoring on HPC was never about the technology; it requires a shift in architecture.

Inference-time output monitoring. Deployed models require continuous observation of output distributions, latency patterns, confidence score distributions, and input-output statistical properties. A model under adversarial input attack, or serving modified weights, exhibits detectable output patterns before any human analyst notices the outputs are wrong. Circuit-breaker logic needs to be designed into the serving architecture, not added after the first incident.

Model integrity verification that runs during inference. Load-time attestation is a necessary and important requirement; it is not sufficient. Long-running inference deployments are vulnerable to hot-swap attacks that replace weights after the initial integrity check passes. Continuous cryptographic hash verification of loaded model weights, running on the dedicated security core with automated circuit-breaker logic on failure, closes that vector. For a model serving safety-critical calculations, the re-verification frequency should match the workload’s risk profile with predictable overhead.

An SR-family extension for the AI supply chain. The existing SR controls address software supply chain risk. They do not address training data provenance, model weight integrity at ingestion, or pre-trained model validation. An AI bill of materials, including cryptographic documentation from the training data source through intermediate checkpoints to the deployed model, is the model-layer equivalent of software supply chain controls. Without it, every pre-trained model loaded into an HPC environment is an unverified artifact from an unverified chain.

Defending AI at Every Layer

The supply chain attacks this spring demonstrated what happens when defense architecture falls behind the delivery mechanisms attackers use. LiteLLM, Axios, and CPU-Z all arrived through trusted channels, carrying payloads no signature database contained. They were stopped because behavioral detection does not require prior knowledge of the payload. It requires knowing what legitimate execution looks like and acting when execution deviates.

Defenders protecting AI workloads face that same problem across every layer they own. HPC is the hardest version of it. But identities, endpoints, applications, and infrastructure all carry the same exposure at different scales. SentinelOne gives defenders coverage across all four, with behavioral AI running at each layer to catch what signatures miss. The specifics of how that works across your AI environment are in our AI security overview.

Citations

¹ “Data Poisoning 2018–2025: A Systematic Review. IACIS (2025)”, and “Data Poisoning Vulnerabilities Across Health Care AI Architectures. JMIR (2026)

² “Poisoning Attacks on LLMs Require a Near-Constant Number of Poison Samples” (2025). arXiv:2510.07192 and Huang et al., 2020.

³ OWASP (2025) LLM04:2025 Data and Model Poisoning. OWASP Gen AI Security Project.

from SentinelOne https://ift.tt/neQRVmH
via IFTTT

New HalluSquatting Attack Could Trick AI Coding Assistants Into Installing Botnet Malware

AI coding assistants have a habit of making things up. Ask one to fetch a popular tool, and it will sometimes hand back a real-sounding name for a project that does not exist.

New research, which its authors call HalluSquatting, turns that habit into an attack: work out the fake names an AI reliably invents, register them first, and wait for the assistant to fetch your trap on a user's behalf.

Anyone whose AI assistant can fetch an outside resource and then run commands with little human review is exposed. In tests, that path led the assistant to run attacker-supplied code on the machine.

Repeat it with a popular enough resource, and one planted name can reach many machines, which is why the researchers frame it as a way to assemble a botnet.

How it works

The attack chains two AI quirks. The first is a hallucination: an AI making something up and presenting it as real. The second is a prompt injection: a booby-trapped instruction that hijacks the AI, so it follows an attacker instead of the user.

Here, the injection is the indirect kind, riding in on content the assistant fetches rather than anything the user types.

1. Pick a target. The attacker finds a repository or plugin that is trending, so lots of people are asking their AI to fetch it. Trending matters, because a brand-new resource is not in the AI's training data, which is exactly when the model starts guessing at names.
2. Learn the mistake. The attacker asks an AI to fetch that resource over and over and records the fake name it invents most often.
3. Claim the fake name. The attacker registers that name on GitHub or a plugin store and hides adversarial instructions inside it.
4. Wait. A real user asks their assistant to grab the popular resource. The assistant invents the same fake name and pulls in the attacker's version instead. Its hidden instructions fold into what the assistant thinks it was told to do, and the hijacked assistant uses its own command-running tool to carry them out.

The trap is not code that runs by itself. It works because these assistants keep a terminal among their built-in tools, so once the planted instructions take over, "install a bot" is simply something the assistant can do.

What makes it practical is that the fake names are not random. In the researchers' experiments, the mistake was consistent: across different phrasings and across models from different companies, the assistant reached for the same wrong name in up to 85% of repository requests and 100% of skill installs. Those are the peak rates the authors report; the paper carries the full breakdown.

They ran it against tools including Cursor, Windsurf, GitHub Copilot, Cline, Google's Gemini CLI, and the OpenClaw family of assistants, getting each to run attacker code. The test payloads were harmless placeholders, not real malware; a live one would take the same path.

The research comes from Aya Spira and colleagues in Ben Nassi's group at Tel Aviv University, with Stav Cohen at Technion and Ron Bitton at Intuit. Nassi's group has done this before, building a self-spreading AI email worm and a calendar invite that hijacked Google's Gemini.

The team says it told the affected vendors, model makers, and marketplace operators before going public, and held back the exact steps needed to copy the attack.

Why is it a new kind of botnet

Traditional botnets take work to build. They lean on weak passwords, or malware that worms from machine to machine, and they usually herd one kind of device, the way Mirai herded cameras and routers.

This needs none of that. No passwords, no worming, and because the payload arrives as text the AI reads rather than a network exploit, it is not the kind of thing a firewall is watching for. The machines it lands on can run any operating system, not one uniform fleet.

The AI is the delivery van here, not the cargo. The planted instructions trick it into installing an ordinary bot, and once that bot is running, the machine belongs to a botnet like any other. What is new is the combination that gets it there: a name an AI predictably invents, a marketplace where anyone can register that name, and an agent with permission to fetch and run.

The pieces are not new, even if the combination is. Attackers first learned to register fake software package names that AIs invent, a trick called "slopsquatting."

In January 2026, Aikido Security's Charlie Eriksen found one such made-up npm package, react-codeshift, that AI-written instructions had already spread to 237 code projects, with agents still trying to install it daily; he registered it himself before any attacker could, so it caused no harm.

The idea then jumped from packages to web addresses. Palo Alto Networks' Unit 42 recently described "phantom squatting," roughly 250,000 hallucinated domains sitting unregistered and free for the taking (THN's write-up is here).

HalluSquatting is the version that reaches all the way to running code by hijacking the agent doing the fetching. And the marketplaces meant to screen bad uploads are not much of a backstop: in June, Trail of Bits slipped malicious "skills" past several store scanners in under an hour.

What to do

It all turns on one condition: an agent that fetches an outside resource and runs it with no one checking. Close that, and the attack stops. The most effective fix is also the simplest: make the assistant search before it fetches.

A real lookup grounds the agent in what actually exists and sharply cuts the guessing. That is a job for the people building these tools, who can also train the planner (the part that maps a request to steps) to look a resource up first and to treat words like clone, install, and fetch as flags.

Users and security teams have nearer-term levers. By default, these agents ask before running a command. The exposure is the auto-run modes (Claude Code's skip-permissions flag, Gemini CLI's yolo mode) that switch that off, so the first rule is not to let an agent run unattended on anything it fetched.

Some tools now add a safety layer that inspects what the agent reads or is about to do before it acts, like Claude Code's auto mode and Gemini CLI's Conseca check, but that lowers the risk rather than removing it. No single switch closes this, so also verify that a repository or package name resolves to the real, expected source before an agent pulls it in, and treat any name an AI hands you as a guess, not a fact.

Platforms have their own lever. They can stop letting people reuse well-known repository names under new accounts, and pre-register the fake names AIs are likely to invent (the same defense already used against typosquatting), so those names point back to the real project.

The researchers call their results a lower bound: "Attacks always get better; they never get worse." There is no single CVE to patch here. They frame it not as one product's bug but as a weakness in how AI agents trust names they were never actually given.

from The Hacker News https://ift.tt/v6iDHtM
via IFTTT