Storm-3168: Agentic-driven cloud attacks using compromised service principals

1. Attack overview
2. Technical analysis
3. Mitigation and protection guidance
4. References
5. Learn More

Microsoft Security Research has identified malicious cloud activity associated with JADEPUFFER, a threat actor discovered by Sysdig in July 2026 and reported to be the first documented agentic ransomware operation. Our investigation found an extensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration.

These findings expand the publicly documented activity associated with JADEPUFFER, tracked by Microsoft as Storm-3168, demonstrating an evolution in the threat actor’s cloud operations and providing the first detailed view into its Azure activity. We identified bulk destructive operations in a compromised Azure environment. The destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

Organizations can reduce exposure by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections. Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.

This activity highlights a broader shift toward AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale. As these capabilities evolve, defenders must similarly use AI to investigate and respond across large environments. Rather than requiring analysts to manually follow each individual action, efforts such as Project Perception and MDASH are intended to support a model in which defenders can investigate and respond across increasingly large and complex environments using AI.

Attack overview

Microsoft observed two compromised service principals belonging to the same tenant. One performed reconnaissance and resource discovery. The other performed discovery, destructive operations, and credential collection.

Discovery before destruction

For the impacted tenant, in early June 2026, one of the compromised service principals enumerated Azure Virtual Machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes with 300+ successful read operations. This breadth of activity would give the threat actor visibility across the organization’s Azure environment.

About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.

16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.

70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.

A seven-minute destructive sequence

Less than one second after the unsuccessful ListKey operation against a non-existent storage account, the second compromised service principal began with its destructive activities. This compromised service principal then attempted 150+ destructive or credential collection related operations in 35 minutes.

The destructive sequence lasted for about 7 minutes. This involved 100+ storage account deletion attempts. Most Azure Storage accounts targeted by the threat actor were successfully deleted. However, Azure resource locks and storage account-level deletion protection blocked deletion attempts for few of the storage accounts, demonstrating the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions. An Azure Key Vault, Function App, App service plan were also deleted, all of which belonged to the same resource group and appeared to support the Function app.

The same service principal also attempted to delete multiple Azure SQL databases in parallel with the storage account deletions mentioned earlier, but every deletion attempt failed because it used an unsupported API version for the Azure SQL database resource type.

Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.

Credential collection

About 30 minutes after the final destructive activity, the same service principal made an inventory request for Azure Storage Accounts and sent 30+ successful ListKeys requests, asking ARM to return each storage account’s access keys. These storage accounts included Azure Site Recovery related storage accounts.

Technical analysis

Possible initial access

• Credential exposure: While it is unclear how the service principal was initially compromised, its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was later edited to remove the secret, but the secret remained accessible through the issue’s public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated. We could not confirm whether this secret was used for the activity described here.
• Application Probing: Since the beginning of this year, we also observed repeated probing from Storm-3168 linked infrastructure against multiple Azure App services for different customers, against sensitive paths related to WordPress administration, PHP-CGI, LangFlow’s code validation endpoint (/api/v1/validate/code) and other web-shell like paths. However, the App Service targets did not overlap with the affected Azure subscriptions, and we found no App Service to ARM (Azure Resource Manager) credential path for the impacted tenant.

Coordinated automation

The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.

We observed five unique tokens issued for the service principal used for destruction and credential collection – four tokens supported deletion, while the fifth token handled storage inventory and key retrieval. Two of the tokens used for deletion were active during the same 70 second period. While one of these tokens focused on Storage account deletion, the other focused on a mixture of Storage and SQL deletion.

While the Key Vault, Function App, and App Service plan associated with the same application were deleted, a similarly named storage account in the same resource group was spared and later targeted by the compromised service principal through a successful ListKeys operation.

The operations followed the identity’s existing Azure role assignments. A group-granted Storage Account Contributor role authorized the destructive storage operations. Direct Contributor access authorized the three application-resource deletions and the one additional successful key retrieval. Direct SQL DB Contributor access authorized the multiple SQL deletion attempts, which were ultimately unsuccessful because of the unsupported API version used for the Azure SQL Database resource type.

Destructive activity indicative of a ransomware-aligned objective

The threat actor deleted numerous Azure resources, while also targeting backup and recovery related resources such as Azure Site Recovery locks or Azure Storage Accounts which had terraform and backup themed names, potentially intending to impair the victim’s ability to recover from the destructive activity.

The parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type. Although the database deletions were unsuccessful, their inclusion in the same destructive sequence provides additional insight into the intended scope of the activity.

The compromised service principal also made multiple attempts to retrieve storage account keys, which could provide access to sensitive data.

Taken together, the resource destruction, attempts to interfere with recovery mechanisms, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations.

However, we did not observe a ransom note or confirm successful data exfiltration in the activity described here.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the risk and impact of activity similar to that observed in this campaign:

• Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads. Consider enabling workload protections relevant to the resources in your environment, including Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service and Defender for Databases. Learn more in the Microsoft Defender for Cloud overview.
• Protect and continuously assess application credentials and secrets. Avoid storing service principal credentials, storage keys, connection strings, and other secrets in source code, configuration files, public repositories, issues, or other locations where they might be inadvertently exposed. Learn more in the Microsoft Entra Workload ID documentation.
• Rotate compromised or exposed credentials immediately and establish credential lifecycle practices. Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential or eliminate copies retained in edit history, caches, archives, logs, or other systems. Immediately revoke or rotate the affected credentials and investigate their historical use. Where supported, organizations should favor mechanisms that reduce reliance on long-lived credentials. Learn more about protecting secrets with Defender for Cloud.
• Apply least privilege to service principals and other workload identities. Review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required by their applications. Learn more about best practices for Azure RBAC.
• Protect backup and recovery infrastructure as part of ransomware resilience. Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls. Learn more about Azure Backup security best practices.
• Scale investigation and response with agentic defenses. Use Project Perception to help defenders deploy AI agents that investigate and respond across large, complex environments at machine speed.
• Strengthen security posture for AI applications and agentic systems. Use Microsoft Defender for AI Security (codename MDASH) to discover AI assets, identify vulnerabilities and misconfigurations, and reduce exposure to AI-related attack paths.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below.

Tactic	Alert name	Defender for Cloud Coverage
Collection, Exfiltration	Possible data exfiltration detected	Defender for App Services
Exfiltration	– An abnormally large number of rows were extracted from an SQL server – Unusual volume of data extracted (Azure Cosmos DB) – Access from an unusual location	Defender for Databases
Persistence, Execution, Command and Control	Communication with suspicious domain identified by threat intelligence	Defender for DNS
Exfiltration	– Unusual amount of data extracted from a storage blob container – Unusual number of blobs extracted from a storage blob container – Unusual amount of data extracted from a sensitive blob container – Unusual amount of data extracted from a storage file share – Unusual number of files extracted from a storage file share	Defender for Storage
Initial Access	– Access from a known suspicious IP address to a sensitive blob container – Access from a suspicious IP address – Access from a known suspicious IP address to a sensitive storage file share	Defender for Storage
Defense Evasion	Azure Resource Manager operation from suspicious proxy IP address	Defender for Resource Manager
Credential Access	– Unusual operation pattern in a key vault – High volume of operations in a key vault – Unusual application accessed a key vault	Defender for Key Vaults

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across cloud 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.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, 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 Defender XDR Threat analytics

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 activity 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 Defender XDR Threat Analytics report on Storm-3168

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 threat.

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

• T1190 Exploit Public-Facing Application | Storm-3168 linked infrastructure repeatedly probed sensitive application paths on applications hosted in Azure App Service for potential exploitation.
• T1078.004 Valid Accounts: Cloud Accounts | Compromised service principals were used for Azure resource discovery and destruction.
• T1526 Cloud Service Discovery | The identities enumerated subscriptions, virtual machines, resource groups, Azure Storage, Web Apps, App Service plans, locks, and Recovery Services.
• T1485 Data Destruction | Azure Storage, Key Vault, Function App, and App Service plan resources were deleted. Azure SQL deletion was also attempted, extending the destructive objective toward databases.
• T1490 Inhibit System Recovery | Site Recovery disk locks and an Azure Backup protection lock were targeted for deletion

Indicators of compromise (IOC)

Indicator	Type	Description
45.131.66[.]106	IPv4	App Service probing and malicious ARM requests
34.153.223[.]102	IPv4	App Service probing
64.20.53[.]230	IPv4	App Service probing

References

• JADEPUFFER: Agentic ransomware for automated database extortion by Sysdig

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.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Storm-3168: Agentic-driven cloud attacks using compromised service principals appeared first on Microsoft Security Blog.

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

PamStealer macOS Malware Adds Live C2 Payload Decryption and Multi-Layer Persistence

Cybersecurity researchers have flagged a new version of PamStealer that ensures that the main payload can only be recovered using a server-side decryption chain.

The latest artifacts, per Jamf Threat Labs, continue to rely on the same JavaScript for Automation (JXA) dropper mechanism, but modify the lure and the delivery method.

"Where earlier variants embedded their payload key material directly in the JXA source, it now fetches a purpose-built decryption utility and completes a key exchange with the server before the payload can be unwrapped," security researcher Thijs Xhaflaire said in an analysis. "Without the server's cooperation, the payload cannot be recovered statically."

A second major change is the choice of the decoy itself. While previous versions observed in July and August 2026 were observed using fake websites masquerading as Maccy, Scoppr, and Nancy Clipboard, victims are now lured through a bogus website ("wavel[.]app") advertising a non-existent cryptocurrency wallet service named Wavel.

Clicking the "Download for macOS" button on the fake site leads to the retrieval of a disk image file ("Wavel.dmg") that contains a compiled AppleScript file. Opening the file launches Apple's built-in Script Editor with instructions to trigger the execution of a JXA dropper.

"In Maccy, Scoppr and Nancy, the JXA source performed RC4 decryption of an embedded payload, made Objective-C framework calls through JXA's bridge to Foundation and NSData, and managed the entire download and staging process," Xhaflaire explained.

"In Wavel, the JXA source contains none of that. The entire JXA layer is now a carrier. When Script Editor executes the file, it decodes the base64 string and pipes the result into /bin/zsh -s, where zsh reads and executes the decoded bytes from standard input. The JXA process exits immediately; the zsh dropper continues in the background."

The decoded zsh script is takes the infection forward by carrying out the following actions -

• Downloading and invoking the "pkgunpack" decryption utility from "wavel.apple03cloudstore[.]com"
• Performing the X25519 key exchange
• Decrypting and staging the payload bundle
• Suppressing macOS notifications that alert users when a new background login item is added
• Installing four redundant persistence methods via LaunchAgent, a repair zsh script that restores both the payload bundle and the LaunchAgent if not present, and a shell hook appended to ~/.zshrc that triggers the execution of the repair script on every new interactive zsh session
• Polling for and uploading the staging directory in the form of a ZIP archive

Because the server holds the private key that completes the key exchange process, the Data Encryption Key (DEK) cannot be recovered without it, thereby preventing the payload from being decrypted. Furthermore, given that a new ephemeral keypair is generated during every execution, a captured DEK value cannot be replayed to extract the contents of the payload.

This, in turn, renders the encrypted payload effectively useless for static analysis without access to a live command-and-control (C2) session.

Ephemeral key generation and a live DEK exchange

What's more, the repair script is copied to "post-checkout" and "pre-commit" folders within "~/Library/Application Support/System/.githooks/," with the Git configuration option "git config --global core.hooksPath" set to the directory. As a result, any git checkout or git commit action in any repository on the compromised system will silently activate the repair script.

The final stage is the stealer component written in Swift, marking a departure from the predecessor, which was implemented in Rust. Despite the change in the programming language used, the end goal is the same -

• Capture system password by serving a fake crash dialog and cross-checks the entered information using a PAM-based validation approach
• Enumerate and retrieve keychain items
• Steal credentials from Chromium- and Firefox-based browsers, including Google Chrome, Microsoft Edge, Mozilla Firefox, Brave, Vivaldi, Opera, Opera GX, Arc, Zen, Waterfox, LibreWolf, Yandex Browser, and Cốc Cốc
• Fingerprint the system and gather extensive metadata and user's profile photo
• Collect user-centric files like .zsh_history, .zshrc, .bash_history and .gitconfig
• List running processes and installed applications

"The inclusion of Arc, Zen and the less common regional and privacy-focused browsers extends the target list noticeably beyond what is typical in commodity macOS stealers," Xhaflaire said.

"This variant of PamStealer reflects a deliberate investment in delivery infrastructure. The pkgunpack utility introduces a live key exchange that ties payload decryption to server availability: without C2 cooperation, the second stage cannot be decrypted. That design makes static recovery of the payload significantly harder and shifts part of the operational control to the server operator."

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

The SOC Doesn't Need to Start Over with Every Alert

Security leaders keep debating whether AI will produce an entirely new class of cyberattack. The nearer change is quieter and already visible: AI has made a failed attack cheap to retry.

The routine version looks like this. An attacker lands on a low-privilege cloud account, and the first try at privilege escalation goes nowhere. That dead end used to cost hours of documentation reading, permission checks, and script debugging, and plenty of operators simply got stuck. With a model in the loop, the error gets explained, the script gets fixed, and a fresh enumeration path is under test within minutes.

No step in that sequence is a new capability. Together they strip time, skill, and cost out of the unglamorous middle of an intrusion, the research and troubleshooting that sit between intent and outcome.

What the threat reporting shows

The public record traces the arc. In early 2025, Google's Threat Intelligence Group found state-backed actors treating generative AI as a productivity tool: translation, scripting help, troubleshooting, research. By late 2025, the same team was writing about malware samples that phoned a model mid-execution and about a maturing underground market for illicit AI tools, while Anthropic disclosed shutting down an extortion operation that leaned on AI at nearly every stage, from reconnaissance and credential harvesting through to setting ransom demands. In May 2026, GTIG reported that cyber crime actors found a two-factor bypass in an open-source administration tool and built working exploits for it, and that based on the structure and content of those exploits it assessed with high confidence that an AI model supported both the discovery and the exploit development. GTIG worked with the affected vendor on disclosure and disrupted the activity, and its own assessment is that the counter-discovery may have prevented the exploit from being used.

That last distinction matters. Assessed AI assistance and a planned operation are not the same claim as confirmed deployment in the wild, and the difference tends to get lost once a finding like this starts circulating. Attribution is hard, prevalence is unclear, and none of these reports is a census of global activity. The direction is what counts, and the direction is toward AI sitting inside attacker workflows rather than beside them.

Provider guardrails deserve credit here. Safety classifiers and abuse disruption push the cost of misuse up, and the disruption cases above show the work paying off. A guardrail still lives outside the enterprise. An operator can poke at it until a reframed request slides through, move the job to an open-weight model, split one malicious task into a dozen innocent-looking ones, or wrap tooling around the model and route around the policy layer entirely. Friction of that kind slows misuse without ever becoming a security boundary, and an organization that treats provider policy as a boundary has substituted reassurance for defense.

Attacks run as loops

Textbooks draw the attack lifecycle as a line: reconnaissance, access, escalation, impact. A working attacker runs a loop instead. Watch the environment, form a guess, try something, read what came back, adjust the guess. AI compresses the time between those steps. A novice stays in the game longer. An expert runs more experiments per day.

Defense is supposed to loop the same way. A signal fires, context gets gathered, a hypothesis forms, scope gets validated, an action lands, and the outcome feeds back into detection. In practice, queues and handoffs interrupt that loop at every joint. The alert idles unassigned. The identity picture lives in a different console. A telemetry gap turns into a backlog item, and the explanation behind a closed false positive dies in the ticket instead of reaching whoever owns the rule.

The environment answers the attacker's experiment in seconds. The defender's answer arrives whenever the ticket gets picked up.

Mean time to acknowledge and mean time to remediate hide this. An alert can be acknowledged in minutes and then spend hours being reconstructed: finding the right identity, confirming whether the endpoint was managed, restating the incident to each new owner along the approval path. That reconstruction interval is decision latency, and few SOCs measure it at all.

Five things every handoff drops

The work is commonly described in five functions: threat intelligence, threat hunting, detection engineering, investigation, and remediation. That is a useful lens rather than a universal org chart. In a small team, one person wears several of those hats. In a large enterprise they spread across the SOC, identity, endpoint, cloud, and business teams, and an MDR provider may own the investigation without owning the authority to contain.

The functions are rarely the problem. The transfer between them is. Threat intelligence understands why a technique matters. Threat hunting can say where it would surface. Detection engineering carries the rule's unstated assumptions. The investigator holds the evidence trail that settled the verdict. The team that acts can name the actions that would break the business. Each transfer squeezes that knowledge into an indicator, an alert, or a ticket, and the squeeze is lossy.

This is the lossy handshake, laid out in a recent three-part series, and the inventory of what a handoff has to carry is worth keeping whole:

• Entity identity: the actual user, device, workload, or business process at the center of the case
• Evidence and provenance: the observations behind the conclusion, their origin, and their timestamps
• Hypothesis and confidence: the leading explanation, the alternatives still standing, and the certainty behind the choice
• Telemetry sufficiency: which claims the available data can support, which it cannot, and which absent source caps the confidence
• Decision ownership and constraints: who holds authority to act, which approvals stand in the way, and what the action might break

Lose the first and two teams end up investigating the same user under different names. Lose the last and a correct recommendation sits in a queue while the intrusion ages. Evidence without provenance is decoration.

One incident, five vantage points

A worked example from that series makes the loss visible in motion.

A finance employee signs in from a hosting provider the account has never used. MFA is satisfied. Inside 10 minutes, a new mailbox rule starts forwarding to an external address, and the account begins pulling files from a finance SharePoint site in a pattern it has never shown. No single event proves compromise. The sequence deserves attention.

Threat intelligence has been tracking a wave of adversary-in-the-middle phishing built to steal authenticated sessions, which is why an MFA success cannot clear the account on its own. That context ships onward as a short advisory with indicators and technique IDs. The behavioral sequence, and the local conditions under which it matters, stay behind.

The hunter translates the advisory into queries and learns two things the advisory never asked about: device-compliance data covers only part of the environment, and SharePoint audit records show up hours late. The hunt forwards a list of suspicious accounts. The coverage caveats stay behind.

Detection engineering builds logic that fires only when the unfamiliar network, the MFA success, and the new forwarding rule cluster inside a short window, knowing full well the rule has no device-state visibility for a slice of the user base. What goes out the door is a severity level and a description field. The assumptions and the expected false-positive patterns stay behind.

The alert reaches an analyst mid-shift, showing a sign-in and a mailbox rule with none of the reasoning that connected them. The analyst rebuilds the picture across four consoles: identity, email security, the SIEM, the asset inventory. Two explanations stay live. The user could be traveling or trying a legitimate new service, which accounts for the unfamiliar network but not for an external forwarding rule and an access pattern the account has never shown. Or an authenticated session was stolen, which accounts for the whole sequence. The second fits the evidence, and endpoint scope stays unknown, because the device is unmanaged and there is no process or network telemetry to check. The case closes with a recommendation to disable the account. The competing explanation, the confidence level, and the endpoint nobody could examine stay behind.

A ticket lands with the identity team: disable this account. The team knows something the SOC never saw: the account is mid-payroll-run, and a blunt disable interrupts a time-sensitive business process. That does not give finance a veto over containment. It means the containment decision and the continuity decision have to be made by people who can see both. Revoking the live sessions and stripping the forwarding rule are the low-risk moves. Suspending the account sits under incident policy and belongs to whoever holds that authority. Moving the payroll run depends on whether a backup operator exists and is free to take it. Reopening access waits on credential reset, MFA re-enrollment, and a managed device, and somebody still has to confirm the actions took effect.

Every function did its job. The system still forced each one to rebuild the incident from scratch, and it handed the one team holding business context a one-line task instead of a decision.

The unicorn analyst is a symptom

When organizations feel this loss, the reflex is a job posting: someone fluent in identity, endpoint, cloud, email, malware analysis, detection logic, and executive communication, assigned to the alert queue. The mythical unicorn analyst is not a talent strategy. It is a workaround for missing system state.

The senior analyst succeeds by knowing things no dashboard shows. Which log source lies. Which service account must never be touched. Which application owner picks up at 2 a.m. The company's real runbook lives in that one head, and it resigns when the person does. A meaningful share of analyst burnout is exactly this, re-deriving what the organization already knew and failed to keep.

The most expensive loss lands after the incident closes. Say the truth turns out benign: the employee was traveling, and the forwarding rule had been approved. The rule's owner needs the evidence that flipped the verdict. The telemetry owner needs to hear that device coverage came up partial. What the system keeps is a closure reason. The verdict survives; the lesson evaporates. That is why a noisy rule stays noisy for years, and why each new analyst rediscovers the same blind spot on their own shift.

What a stateful SOC remembers

The fix is architectural. The series lands on a specific prescription: the SOC has to become stateful. SOCs are not amnesiac. They retain evidence and case histories, often for years. What tends not to survive a handoff is the reasoning around that evidence, the uncertainty that qualified it, and the constraints on who could act. Those stay buried in whichever system produced them instead of informing the next decision. The alternative is shared operational memory, five kinds of state that every workflow reads and writes:

• Environmental state: the identities, devices, workloads, and business services that exist, their relationships, their owners, and which of them are privileged, exposed, or unmanaged
• Evidence state: each observation, its source, its timing, and a path back to the original event
• Decision state: the current hypothesis, the alternatives weighed, the evidence for and against, and what new evidence would change the answer
• Control state: the actions on the table, the approvals they require, the owner of the affected system, and anything that has to be preserved before containment
• Learning state: the corrections analysts made, the assumptions that failed, whether the fix held, and what should change in a threat hunt, rule, or playbook as a result

A shared model on those lines lets the SIEM, the EDR, the identity platform, and the case system contribute to one decision. None of those tools gets replaced by it.

The hardest discipline in that list is treating "unknown" as a legitimate answer. When endpoint telemetry is missing because a device is unmanaged, a weak system files the finding as "No malicious process activity was observed." The sentence is technically true and operationally misleading. A stateful system records that the endpoint could not be checked at all, cuts its stated confidence in endpoint scope, and routes the coverage gap to whoever owns device management. The gap becomes part of the case rather than vanishing into a reassuring sentence.

Agents need jobs and boundaries

Agentic AI enters this picture last, and deliberately so, because bolting agents onto a stateless SOC gives a broken operating model more speed. Bounded workflows working from shared memory are a different proposition. Threat intelligence decides whether an outside threat matters locally and shows its reasons. Threat hunting reports the populations it covered next to the ones it could not see. Detection checks that the environment can feed a rule the data it needs before that rule goes live. Investigation packages timeline, competing explanations, evidence, and confidence as a single object. Remediation maps the decision onto available actions, owners, and approvals.

Authority stays separate from confidence. The framework distinguishes four modes for any action: observe and gather further evidence; put a recommended action and its reasoning in front of a human who holds the authority; execute only after explicit approval; or execute automatically, and only where policy, confidence, entity type, and potential-impact conditions are all satisfied. The mode lives in control state, versioned and auditable. A confident-sounding narrative earns an agent exactly nothing in execution rights.

The same caution governs learning. A single false-positive verdict from a single analyst is thin evidence for changing production detection logic. Analysts make mistakes, and some cases are simply exceptions. A stateful system captures the evidence behind the correction, gathers similar cases, drafts a proposed change, and routes the proposal to the owner of the rule. That review step is what separates learning from self-corruption.

The analyst's job moves up the stack

The evidence-assembly half of the investigation is already done when the analyst arrives. The analyst's first move is to challenge the structured case: whether the hypothesis holds together, whether a competing explanation got missed, whether the proposed action is proportionate to the evidence, and what the business context changes.

Measurement moves the same direction. Counting completed agent tasks flatters the software. Four questions do the job better: does the analyst open a case that already contains the context, does the case record what could not be seen, does a corrected verdict reach the rule's owner while the correction still matters, and did every automated action stay inside policy with an audit trail behind it. Revised federal guidance points the same way: NIST's updated incident response recommendations in SP 800-61r3 treat response as part of an organization's wider risk management rather than a self-contained SOC activity.

The attack loop is tightening on a curve, and waiting for full autonomy to arrive is a slow way to concede it. The starting points are unglamorous: measure where the same context keeps getting reassembled by hand, record what an investigation could not see next to what it concluded, decide who owns each action and who approves it while things are calm, and route what the investigation learned back into threat hunting and detection.

The finance employee's account gets suspended either way. In one SOC, the lesson evaporates with the closure reason and the payroll problem surfaces after the fact. In the stateful one, the people who act can see what the investigation could not, the coverage gap has an owner, and the next analyst inherits a memory instead of a queue.

Note: This article is based on a three-part series by Jonathan Waknin, Director of Solution Architects/CISO at Conifers.ai.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

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

Bitget Says Suspected North Korean Hackers Stole $351.6M After Backend Compromise

Cryptocurrency exchange Bitget said suspected North Korean threat actors have stolen $351.6 million from its hot and warm wallets.

"At 18:31 UTC on September 24, 2026, Bitget's security systems identified unauthorized transfers involving a limited number of hot wallets," BitGet said in a post shared on X. "Bitget's cold wallets and the overwhelming majority of platform assets remain secure and unaffected."

The company emphasized that customer account balances remain accurate, and deposits and trading continue to operate normally. However, withdrawals have been temporarily suspended out of an abundance of caution while a "comprehensive security review" is underway.

Bitget did not disclose any details on how the attack took place, but said it has enlisted the help of Google-owned Mandiant and SlowMist for a third-party investigation.

"Bitget Wallet operates as a self-custodial wallet on a completely separate and independent infrastructure from Bitget Exchange and was not affected by this incident," it noted.

According to Bitget CEO Gracy Chen, assets impacted by the hack include ETH, XRP, BNB, AVAX, USDT, and USDC, with the chains involving Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, and Base.

"We have contacted the foundations of all affected chains, and some foundations have confirmed the freezing of hacker wallet addresses," Chen said. "Based on IP behavior patterns and on-chain analysis, the attack method in this incident is highly consistent with known patterns of North Korean hacker organizations."

"The attacker compromised a critical backend system within our wallet infrastructure, used it to spoof transaction data, and triggered our authorization process to move funds out. No further unauthorized transfers are possible. The specific method of system intrusion remains under active investigation."

The development comes about a week after SentinelOne attributed the North Korea-linked TraderTraitor group to an attack targeting an India-based information technology (IT) services company. TraderTraitor is best known for the theft of $1.5 billion from Bybit and $292 million from KelpDAO's LayerZero bridge.

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

Roundcube Pre-Auth SQL Injection Flaw Actively Exploited in the Wild

The Canadian Centre for Cyber Security has warned that a now-patched Roundcube Webmail vulnerability is being actively exploited in the wild.

The vulnerability in question is CVE-2026-48842 (CVSS score: 8.1), a pre-authentication SQL injection in the virtuser_query plugin of Roundcube Webmail versions 1.6.x before 1.6.16 and 1.7.x before 1.7.1.

The issue stems from a preg_replace() backslash escape bypass that allows attackers to inject arbitrary SQL statements without authentication.

"Unauthenticated attackers can inject SQL into Roundcube's database backend through the virtuser_query plugin, potentially exposing mail account credentials and stored messages," SentinelOne said.

Patches for the vulnerability were released by Roundcube in May 2026 as part of 1.6.16 and 1.7.1.

In an update shared this week, the Cyber Centre said the security flaw is being actively exploited in the wild, citing open-source reporting. No additional details of the exploitation activity have been disclosed.

Data from the Shadowserver Foundation shows that there are more than 523,000 Roundcube instances exposed to the internet, with 10 of them flagged as vulnerable hosts as of September 23, 2026.

Vulnerabilities in Roundcube have been an attractive target for threat actors looking to harvest sensitive email communications. In July 2026, Proofpoint said it identified a suspected China-aligned adversary dubbed UNK_MassTraction exploiting known security flaws in Roundcube to deliver web shells or a post-exploitation tool called VShell.

Way back in February 2026, two other vulnerabilities in the same product (CVE-2025-49113 and CVE-2025-68461) were tagged as actively exploited by the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

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

Placeholder third-party[.]com Referenced Across 1,700+ Repositories Now Serves Malicious Content

The "third-party[.]com" domain, commonly used as a documentation placeholder, has been observed serving a ClickFix lure to Windows browsers while displaying a harmless decoy to other users.

"third-party[.]com has been a generic documentation placeholder for years, the same role example.com plays," Manifold Security's Head of Research, Ax Sharma, said. "Unlike 'example[.]com,' third-party[.]com is not IANA-reserved. Anyone could register it, and someone did. Every doc, test, and skill that hard-coded it now points readers at attacker infrastructure."

As of writing, the domain has been marked as malicious and unsafe on both VirusTotal and Google's Safe Browsing list.

ClickFix is a social engineering attack technique in which either malicious or legitimate-but-compromised websites display error messages, browser alerts, or CAPTCHA verification prompts, tricking users into copying and executing hidden commands via the Windows Run dialog or Terminal to "fix" the issue.

Often, web pages using ClickFix rely on clipboard hijacking to automatically inject malicious script or commands into the victim's clipboard for subsequent pasting on Windows Run dialog or macOS Terminal. This approach is also sometimes referred to as pastejacking.

According to Manifold Security, the domain has been serving the ClickFix lure since at least June 2026. Windows users visiting the page are shown a Cloudflare check that poisons the victim's clipboard and instructs them to paste and run the command via the Windows Run dialog. The pasted command is designed to extract and run a remote PowerShell payload.

When a macOS user visits the same page, the fake security verification prompt shows an error: "macOS is not supported. This website requires a Windows PC to access. Please try again from a Windows device."

A search on GitHub shows that the domain is referenced in over 1,700 public repositories, including those related to AI agent skills and MCP-server docs that cite "third-party[.]com" as an example endpoint.

"In every one of those places it is exactly what it looks like: a placeholder, an example, a stand-in, and entirely reasonable use by the teams involved," Sharma noted. "It is also, now, a live pointer to a ClickFix server."

This weaponization of a blindly trusted domain, in turn, can open up avenues for prompt injection and other unintended behaviors.

To counter the threat, it's advised to audit their documentation and treat non-reserved placeholder domains (e.g., yourcompany[.]com, mycompany[.]com, your-api[.]com, and their lookalikes) as squattable and open to abuse by threat actors, who can register them and serve malicious content.

Developers working on skills, documentation, or test cases are recommended to use reserved placeholders like "example[.]com" (or "example[.]org," "example[.]net") only and avoid using plausible-sounding domains that are not under their control.

"You can scan the skill, read the file, resolve the domain from your analysis box, and conclude it is fine, and be completely wrong about what a Windows user's agent receives when it follows the same link," Manifold Security pointed out. "A file scan cannot see what a website decides to send. The tell only appears at request time, from the caller that matters."

The disclosure comes as Manifold said it has since identified 13 more placeholder domains that are not IANA-reserved, with two of them – yoursite[.]com and your-domain[.]com – serving scams and scareware to macOS visitors and an ordinary parking page to other users.

"On a macOS browser, your-domain[.]com showed a fake 'MacOS Security Center' claiming four viruses and selling a counterfeit McAfee renewal at 55% off," security researcher Cody Nash said. "On another macOS render, yoursite[.]com showed a counterfeit ZDF news article advertising an investment scheme."

The complete list of domains, each of them are pass static checks, is as follows -

• your-domain[.]com
• yourdomain[.]com
• your-site[.]com
• yoursite[.]com
• your-app[.]com
• yourapp[.]com
• myapp[.]com
• mysite[.]com
• acme[.]com
• company[.]com
• mycompany[.]com
• vendor[.]com
• foo[.]com

To make matters worse, the two scam-scarware-serving sites are present in hundreds of thousands of GitHub files and hundreds of agent skills. "Scareware and investment fraud are a lower threat than clipboard malware, the exposure they ride on is far larger, and none of it showed up in any static check we ran," Nash said.

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

Hacked Ukrainian Sites Serve Fake Cloudflare ClickFix Lures for Psychedelic Stealer

An active ClickFix campaign has been observed compromising legitimate Ukrainian business websites to inject bogus Cloudflare verification pages and trick victims into downloading a previously undocumented information stealer called Psychedelic.

"When a visitor interacts with the page, the lure copies a Windows Installer command to the clipboard and instructs the visitor to paste it into the Windows Run dialog," Arctic Wolf Labs said in a technical report shared with The Hacker News.

The ClickFix chain uses an "msiexec.exe" command to fetch a Windows MSI installer that's used to deliver the stealer malware. The malicious tool is designed to harvest browser passwords, account tokens, and cryptocurrency-wallet data, set up scheduled-task persistence, and contact a command-and-control (C2) server for additional tasking.

Some of the compromised websites include a hair-treatment clinic, a scale-model manufacturer, a specialist bookseller and publisher, a psychological facility, a tool retailer, and an automotive retailer. These affected sites include an injected iframe element that's responsible for executing attacker-controlled JavaScript ("fsputnik[.]com/tds/tracker[.]js").

The ClickFix command, for its part, retrieves an MSI installer ("elita.msi") hosted on "uasputnik[.]com," a domain that was registered on September 9, 2026. Other MSI payloads identified include "miks.msi," "astra.msi," "harbor.msi

," "neon.msi," "sova.msi," and "vyse.msi."

"The attacker-controlled page imitates a Cloudflare verification screen and presents Ukrainian-language instructions," Arctic Wolf said. "The clipboard operation occurs before the lure displays its Windows Run instructions. After a three-second spinner, the page presents an instruction dialog and keeps the 'Done' button disabled for approximately 35 additional seconds."

"This delay controls progression through the lure interface; it does not verify that the visitor opened Windows Run, pasted the command, or installed the payload."

The MSI installer, for its part, is responsible for retrieving the next-stage payload ("psychedeliclove.exe") from the URL "107.175.82[.]242:9000." The 64-bit Windows executable is Psychedelic Stealer, which performs the following functions -

• Collect credentials from Chromium-based browsers, including Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, and Yandex, and exfiltrate them through the "/api/v1/ext/passwords" endpoint
• Collect browser-associated account tokens and exfiltrate them through the "/api/v1/ext/tokens" endpoint
• Scan for known cryptocurrency wallet browser extensions (MetaMask, Trust Wallet, OKX Wallet, and SafePal) and desktop apps (Exodus, Atomic Wallet, Electrum, Bitcoin Core, and Litecoin Core) and exfiltrate data through the "/api/v1/ext/wallets" endpoint
• Capture extensive host information and exfiltrate it through the "/api/v1/checkin" endpoint
• Terminate selected browser processes, extract an embedded extension archive into web browser profiles, and set a native-messaging bridge

"These components extend the operation beyond one-time data collection," Arctic Wolf said. "Browser-profile modification and native messaging provide a mechanism for deployed browser content to communicate with a local host component."

"A recurring background routine revisits extension-related operations before polling the C2 server for tasks, indicating that browser-component handling is integrated into the implant's ongoing execution cycle rather than limited to initial installation."

Psychedelic Stealer also features the ability to retrieve further tasks using the "/api/v1/agent/tasks?hwid=%s" endpoint, where "hwid" refers to a unique victim identifier. It can allow the malware to run EXE, COM, BAT, CMD, MSI, and PowerShell payloads, offering the operator a way to introduce additional malware.

Arctic Wolf said it identified an exposed lure management panel linked to the campaign called РУБЛЁВКА TDS (Rublevka TDS) on the "uasputnik[.]com" domain. The panel, which is distinct from the implant's C2 ("193.178.159[.]128:8080"), is used to configure web-lure commands and records interactions.

"The dashboard polls visitor records every two seconds, providing near-real-time visibility into progression through the lure interface, not endpoint execution," it added.

At the time of analysis, the panel recorded 557 views, 426 clicks, and 79 complete events across 32 countries, with Ukraine accounting for 446 views, 351 clicks, and 71 complete events. Other targets include the U.S., Poland, Germany, Canada, and the Netherlands.

"Russian-language branding and implementation artifacts suggest likely Russian operators, and the intended audience is clear: Ukrainian-language instructions, affected Ukrainian business websites, and the panel's concentration of recorded views in Ukraine support an assessment that the campaign focused heavily on Ukrainian users," the cybersecurity company concluded.

ClickFix Delivers RemotePanel and BoundSiphon

The development comes as Blackpoint Cyber said it identified two undocumented .NET malware components delivered together via a ClickFix chain: RemotePanel, a persistent remote access platform, and BoundSiphon, a .NET credential and cryptocurrency stealer that targets both Chromium and Firefox browsers.

"RemotePanel establishes persistence by masquerading as the Windows Time service and gives operators broad control over infected systems, including PowerShell, file and process management, screen access, modular HVNC, and fleet management," researchers Nevan Beal, Sam Decker, and Andi Ursry said.

"BoundSiphon runs primarily from memory and targets browser credentials and sessions, cryptocurrency wallets, password manager data, and selected documents, including secrets protected by Chromium App-Bound Encryption."

RemotePanel makes use of a BNB Smart Chain contract to resolve its C2 server, thereby allowing the threat actors to rotate infrastructure without rebuilding or redeploying the malware on infected hosts. BoundSiphon, on the other hand, is assessed to share overlaps with a stealer that was flagged as being distributed via five malicious NuGet packages back in May 2026.

The attack sequence begins with a ClickFix command that uses PowerShell to initiate a multi-stage chain, with one of the intermediate components abusing the CMSTPLUA COM object to bypass User Account Control (UAC) and gain elevated administrative privileges without prompting the user and run a privileged hidden PowerShell process.

The process then proceeds to configure broad Microsoft Defender exclusions and fetch and execute two additional payloads using different methods -

• RemotePanel, which is written to disk, installed as a service, and is used for persistent remote access and operator control through interactive PowerShell sessions, file and process management, screen streaming, and modular hidden virtual network computing (hVNC)
• BoundSiphon, which is loaded directly into memory through PowerShell, and is used for credential, session, wallet, and document collection

The campaign has not been attributed to any known threat actor or group, although Blackpoint said it recovered artifacts that suggest a possible Russian-speaking development environment. This includes source code checks to avoid executing on systems with a Russian keyboard layout.

"RemotePanel and BoundSiphon reflect a broader shift toward modular malware ecosystems that separate persistent access from data theft, allowing operators to replace infrastructure and individual components while retaining the underlying capabilities needed to continue an operation," Blackpoint said.

"RemotePanel can move its backend through an owner-controlled BNB Smart Chain resolver without rebuilding the implant, while BoundSiphon moves its App Bound Encryption recovery into legitimate Chromium processes to reach newer browser secrets."

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

Proactive Defense: Hardening Code Pipelines and CI/CD Infrastructure

Introduction

The landscape of software supply chain security has undergone a significant shift. Recent campaigns demonstrate that sophisticated threat actors are systematically targeting the engineering lifecycle by compromising trusted security and programming tools.

These intrusions reveal three key tactics:

• Attackers target trusted security scanners, utility libraries, and AI developer tools to exploit the elevated privileges granted to these systems within build pipelines.

• Adversaries target developer workstations and Integrated Development Environments (IDEs) via highly tailored social engineering, malicious extensions, or typosquatted local dependencies to exfiltrate private cryptographic keys, API tokens, and active session credentials directly from local engineering environments.

• Rather than relying solely on compromised static credentials, attackers have escalated to advanced pipeline manipulation techniques, including GitHub Actions cache poisoning, OpenID Connect (OIDC) token extraction, and the subversion of mutable action tags to publish compromised packages that still carry legitimate cryptographic provenance.

Building upon prior guidance (here, and here), this blog provides an actionable blueprint for software and platform architects designed to safeguard the software supply chain against threat vectors that are actively being exploited, third-party risks, and architectural vulnerabilities throughout the entire Software Development Lifecycle (SDLC).  

Read on for more on how to establish continuous integration and continuous delivery/deployment (CI/CD) safeguards, strengthen developer workflows, and build robust, end-to-end defense-in-depth. 

The Multi-Layered Approach

Treating each stage of the pipeline as independent security domains is no longer sufficient because these multi-layered attacks target vulnerabilities across the entire build pipeline. Defending against these persistent threats requires a thorough, defense-in-depth approach spanning the five key pillars of the software development lifecycle outlined in Figure 1:

Figure 1: The five core pillars for securing the software development lifecycle

Endpoint 

Developer workstations are high-value targets because they hold direct, privileged access to repositories, pipelines, and cloud environments. Threat actors frequently target IDEs, exploiting unmonitored local access to collect personal access tokens (PATs), SSH keys, and proprietary code. Organizations should establish a unified security layer that enforces a consistent security posture across all local host machines and cloud-based development environments.

Local Secret Scanning 

Organizations should deploy pre-commit hooks and IDE-integrated scanning tools to detect and block secrets prior to repository commit. Standardizing local pre-commit templates ensures git trees are fully verified before changes are pushed to central servers. To minimize the impact of a potential leak, organizations should migrate from legacy classic PATs to fine-grained PATs constrained by tight time-to-live (TTL) limits and minimal, environment-specific permissions.

Endpoint Security Management

Organizations should configure Endpoint Detection and Response (EDR) solutions to monitor developer software integrations and enforce continuous device posture checks. EDR agents should monitor trusted IDE process trees for anomalous file access, unexpected process spawning, and unauthorized outbound network connections. 

To ensure complete alignment, these EDR compliance signals should be integrated directly with Unified Endpoint Management (UEM) systems to automatically restrict or revoke a user's ability to access Source Code Management (SCM) systems, execute pipeline tasks, or publish code if their device falls out of compliance. Necessary command-line interface (CLI) process exclusions should be strictly restricted to designated, isolated developer environments rather than applied broadly across corporate endpoints.

IDE Standardization

Organizations should vet and approve specific versions of IDEs, browser integrations, and third-party extensions. IDE and browser marketplaces should be restricted to allow only vetted applications, explicitly blocking unverified extensions. All integrations require a formal third-party risk management review before allowlisting. Organizations should maintain an active software asset inventory paired with strict version-pinning and centralized emergency-block capabilities to stop newly discovered threats.

AI-Assisted Security

Engineering teams should leverage only approved large language models (LLMs) and AI agents for pre-merge vulnerability analysis and application security testing. This boundary is critical, as threat actors have begun actively inserting malicious code into open-source Model Context Protocol (MCP) packages and tricking AI coding agents (as detailed in our accompanying blog).

To mitigate risks like context poisoning and data exfiltration, security teams should deploy context-protection tools to validate inputs before runtime execution. Developers should, wherever possible, exclude local environment (.env) files from the workspace using platform-specific ignore configurations to prevent sensitive credentials from entering the model's context window. Organizations should maintain a human-in-the-loop control model to verify all AI-generated code before it is written to a  repository.

Isolated Developer Sandboxes

To prevent host-level compromises, organizations should, wherever possible, require the use of containerized development environments or dedicated virtual machines (VMs). Sandboxing ensures malicious post-install scripts or dependency-poisoning attacks cannot traverse the local filesystem.

Mounting sensitive host paths into workspace containers should be restricted to prevent compromised dependencies from executing with host privileges. Developer guest VMs should be instantiated from centralized, hardened golden images and network isolated from live production environments. All sandbox execution and network activity should integrate into centralized corporate logging.

Code Repositories  

Source code repositories serve as the definitive source of truth for an organization's proprietary software and intellectual property. Hardening this layer requires control over user identities, strict branch governance, and continuous verification of the code history to prevent unauthorized changes from entering the lifecycle.

Universal Identity

Securing repositories requires strict control over user identities. Implementing a Company Managed User (CMU) model allows organizations to retain full ownership of all accounts, including outside collaborators, and enables the enforcement of phishing-resistant multi-factor authentication (MFA), such as FIDO2 compliant physical security keys or digital passkeys.

However, CMU accounts may be inhibited from contributing to external, open-source repositories. Because of this limitation, a standard user model with MFA enforced Single sign-on (SSO) integration remains the recommended approach for teams engaged in public or open-source publishing and private collaboration.

Regardless of the chosen account model, identity verification should be continuous. Organizations should deploy conditional access policies to verify device posture before granting access, while monitoring user API activity to quickly detect compromised sessions.

Branch Protection

Organizations should implement a zero direct-to-main policy, ensuring all changes flow through isolated feature branches that require peer reviews and pass automated CI checks before merging. Administrative bypass policies should be disabled. At the filesystem level, force-push activity should be restricted and monitored. Security teams should continuously analyze audit histories for chronological discrepancies to identify timeline tampering and detect unauthorized dead-drop repositories used for code exfiltration.

Credential Lifecycle

To prevent long-term persistence, organizations should automate credential rotation, implement just-in-time retrieval mechanisms, and establish a strict token TTL. For developer access, organizations should deprecate PATs which function essentially as static, host-stored passwords vulnerable to local infostealer malware and transition to cryptographically verified SSH-based authentication backed by hardware security keys (such as FIDO2/YubiKey or macOS Secure Enclave).

For automated CI/CD pipelines and third-party integrations, organizations should mandate the use of GitHub Apps in place of service account PATs to leverage short-lived, highly scoped access tokens that automatically expire after one hour. Secrets should not be stored in environment variables; local environment files (.env) should be excluded via .gitignore while utilizing native platform secret features for runtime injection.

Dependency Security

For application manifests utilizing Semantic Versioning (SemVer), organizations should prohibit dynamic version ranges (such as carets ^, tildes ~, or wildcard * operators) that introduce dependency drift during resolution. Instead, configurations should mandate exact SemVer pinning (e.g., 1.4.2) supported by strictly enforced, cryptographically verified lockfiles

Unverified execution vectors, such as blind "curl to bash" scripts, should be blocked in favor of direct vendor containers invoked via explicit SHA-256 digests. Organizations should implement Software Composition Analysis (SCA) paired with reachability analysis to prioritize patching vulnerabilities that are actually executed within the application path. Builds should generate a software bill of materials (SBOM) and enforce Supply-chain Levels for Software Artifacts (SLSA) Level 2+ provenance checks.

Artifact Management 

Defending the artifact layer requires controlling what crosses the boundary into the trusted build environment. Point-in-time scanning is no longer sufficient; organizations should continuously inspect and verify upstream components before they propagate downstream.

Dependency Cooldowns

Organizations should mandate a minimum release-age cooldown of seven days before any newly published public package version becomes installable. Community detection often identifies and removes malicious open-source packages shortly after they are published.

Establishing a strict seven-day buffer provides the open-source ecosystem time to detect and pull poisoned releases before they reach internal builds. This delay should be enforced at centralized registries or local configurations; for specific configuration parameters (such as configuring npm's minimumReleaseAge cooldown or secure Python pip indexing), see the technical implementation steps detailed in our accompanying blog.

Proxies & Quarantines

All external packages and container images should, wherever possible, route through a centralized internal proxy that caches, inspects, and gates each component. Organizations can manage this secure boundary using Google Artifact Registry to host private repositories, configure virtual upstream repositories, and restrict direct build-runner access to public registries. New components arriving through the proxy should be held in a quarantine state and screened, blocking builds automatically on a failed security verdict. Internal repositories should be kept distinct from public registries to prevent dependency confusion attacks, and promotion to the trusted registry should follow a deliberate, policy-driven approval path.

Vulnerability Scanning

Container images and third-party dependencies should undergo automated scanning at the registry layer and at runtime. Stored artifacts should be continuously re-evaluated as new vulnerabilities emerge. To manage alert volume, results should be prioritized using reachability analysis and real-world exploitation signals, such as the CISA Known Exploited Vulnerabilities (KEV) catalog. Vulnerability Exploitability eXchange (VEX) statements should be used to suppress inapplicable findings and reduce noise.

Image Provenance

Verifying that an artifact came from a trusted source is as critical as confirming it is free of known vulnerabilities. Provenance establishes this trust by cryptographically signing every internally produced container image and package, then binding each one to the specific build workflow and source commit that created it. Modern signing tooling makes this practical without the burden of managing long-lived signing keys, instead tying each signing event to a build identity and recording it in a public transparency log. A signature is only meaningful when checked, so verification should be enforced at admission, restricted to the exact build identity expected, and performed against an artifact's immutable digest rather than a mutable tag.

The same principle extends to the credentials that publish artifacts. Long-lived registry published tokens are a recurring root cause in supply chain incidents, since a stolen token lets an attacker publish poisoned versions under a trusted name. Where possible, these static tokens should be replaced with short-lived, identity-bound publishing tokens issued to a specific build workflow at the moment of release. For first-party builds, adopting a recognized provenance standard provides a consistent benchmark for how and where software was built.

SHA Referencing

Container image tags and action references are mutable by default, which means an upstream actor can silently replace the content behind a trusted name at any time. Pinning to an immutable cryptographic digest closes this gap, because a digest is a content hash and any change to the underlying artifact produces a different identifier, breaking the reference rather than substituting malicious content under a name the pipeline already trusts.

Images should be pinned by digest, and third-party actions should be pinned to a full commit hash rather than a version that can be repointed. This discipline should extend across every image a build touches, not just the primary application image, since base images, sidecars, and init containers are equally viable injection points if left on mutable tags. Teams should also avoid configurations that re-resolve a mutable tag on every restart in production.

CI/CD

Hardening the automated pipelines within CI/CD infrastructure is a critical requirement for securing the broader software development lifecycle. Because these environments rely on an extensive web of privileged integrations to access source repositories, third-party registries, and cloud infrastructure, they function as high-value targets for adversaries. Securing these build and delivery systems requires the rigorous application of least-privilege principles, the enforcement of strict network boundaries, and the continuous verification of every trusted software component.

Runner & Build Servers

Hardening CI/CD infrastructure is a critical task because these pipelines require access to code repositories, dependency registries, and cloud environments. To secure these integrations, the primary defensive objective is to eliminate runner persistence. Organizations should use ephemeral, single-use runners, ensuring that every job executes in a fresh, isolated environment that is automatically destroyed upon completion. This clean-slate approach prevents cross-job contamination and denies attackers a permanent foothold. For self-hosted environments, this isolation should extend to the network layer, restricting outbound runner traffic exclusively to pre-approved registries and repository APIs to prevent data exfiltration. Furthermore, to mitigate Poisoned Pipeline Execution (PPE), the execution engine should block unvetted code from pull requests from accessing secrets or triggering deployment-grade runners until an administrator grants manual approval.

Additionally, pipelines should protect shared build caches from tampering. Because build caches are frequently shared across branches to speed up builds, a malicious pull request can inject corrupted dependencies directly into the shared cache. If left unrestricted, a subsequent production build will retrieve this poisoned cache and run the malicious code in a trusted environment. Pipeline setups should isolate cache access strictly by branch privilege and reject cache writes from unauthenticated forks.

Least Privilege CI/CD

• Federated Ephemeral Identities: Prohibit persistent automation secrets within workflows, leveraging OIDC to exchange pipeline identities for short-lived tokens.

• Zero-Trust Execution Scopes: Issue read-only or null-permission runner identities by default, requiring components to explicitly request minimum viable permissions.

• Shared State Parameterization: Prohibit the automatic inheritance of credentials across downstream templates or nested workflows to isolate sensitive variables.

• Runtime Governance: Restrict unsanctioned third-party plugins and marketplace actions. Security teams should also sandbox or disable package installation lifecycle scripts (using configurations like ignore-scripts=true detailed in our accompanying blog) to prevent compromised dependencies from executing arbitrary commands in build environments.

• Environment Isolation: Segment network and IAM boundaries so that early-stage validation or linting tasks operate completely decoupled from systems possessing release authority.

• Immutable Branch History: Disable history-rewriting functions and force-pushing on canonical branches to maintain an append-only audit trail.

• IaC Validation: Scan Infrastructure-as-Code (IaC) prior to deployment to block over-privileged keys, unquoted user-parameter injections, unencrypted webhooks, and runner RBAC misconfigurations.

Scanning Gates & Attestation

CI/CD scanning gates act as automated quality control within the deployment process, evaluating code against set security standards and automatically halting deployments if the defined criteria are not met. Placing scanning gates as early in the process as possible alerts developers of potential vulnerabilities before they reach production:

Secret Scanning (At the Developer Commit / PR Gate): Configure pre-commit hooks and SCM-level scanners to block developer pushes if they contain hardcoded API keys, passwords, or SSH keys. This stops secrets from ever entering your repository's permanent history.

SAST - Static Application Security Testing (At the Pull Request / Peer Review Gate): Integrate SAST into your continuous integration (CI) tests to analyze draft code before it is merged into the main branch. This automatically flags structural flaws, logic vulnerabilities, or dangerous functions (like unescaped user inputs) during active development.

SCA - Software Composition Analysis (During the Build Phase): Trigger SCA scans when your build environment resolves dependencies. By scanning your package lockfiles (e.g., package-lock.json or requirements.txt) against databases like Google OSV, you can automatically fail builds that attempt to import libraries with active, known CVEs.

Container/Image Scanning (At the Registry / Push Gate): Build automated scanners directly into your container registry pipeline. Before a newly built container image is allowlisted for production, the registry scanner should inspect its base OS packages and reject any image containing critical OS-level vulnerabilities or default root access.

DAST - Dynamic Application Security Testing (In Staging / Pre-Deployment): Create a temporary, isolated staging instance of your running application as a deployment step. Run automated DAST tests to simulate real-world attacks (like SQL injection or cross-site scripting) against your endpoints, validating that your active runtime defense configurations are working.

CSPM - Cloud Security Posture Management (Pre-Deployment IaC Scan & Post-Deploy): Use Policy-as-Code tools to scan your Infrastructure-as-Code (IaC) templates (like Terraform or Kubernetes manifests) before applying changes. This automatically blocks the provisioning of misconfigured cloud environments, such as overprivileged IAM roles or security groups with SSH (port 22) open to the internet.

SBOM Generation and Attestation

An SBOM is a complete, verifiable inventory of every component that went into a build. Generating and signing the SBOM as part of the build produces this inventory as a tamper-evident attestation rather than an after-the-fact reconstruction.

In practice, this means generating the SBOM as a build step in a recognized format such as CycloneDX or SPDX. The resulting SBOM should be signed as an attestation tied to the artifact’s digest, preventing modifications. Signed SBOMs should then be mapped back to affected artifacts without re-scanning every image in the fleet. To keep monitoring useful, VEX statements should be used to flag findings that do not apply to the code, ensuring the inventory remains an actionable triage tool.

Deployment

Securing the runtime phase ensures that workloads remain protected even if an attacker manages to bypass early pipeline defenses. This operational layer acts as the final quality gate as code transitions from the build pipeline to active production.

Workload Protection & Runtime Hardening

Workload protection should be enforced directly on running applications and container instances to limit their execution footprint and block active exploits.

• Deployment Guardrails: Establish an automated security check at the entrance of your production environment to block any container that lacks a valid cryptographic signature, requests unneeded root privileges, or originates from an untrusted public registry.

• Workload Posture: Build workloads from hardened base images and run them on immutable infrastructure with read-only root filesystems and removed SSH capabilities to prevent post-exploit file creation or lateral directory traversal.

• Active Application Protection: Deploy Runtime Application Self-Protection (RASP) to block execution-level exploitation attempts like SQL injection. Protect AI workloads from prompt injection and jailbreaks using runtime guardrails such as Google Model Armor.

• Just-In-Time Access: Eliminate standing administrative privileges in favor of time-bound, task-scoped access credentials that expire automatically, injecting privileged credentials at runtime only when required.

Protecting Live Infrastructure

Securing the surrounding network and cloud control plane shields your deployed applications from external threats, blocks lateral movement, and maintains the absolute integrity of your cloud configuration.

• Web Application Firewalls (WAF): Deploy edge firewalls to inspect incoming application-layer traffic, filtering out malicious payloads and blocking common web exploits, such as cross-site scripting or OWASP Top 10 vulnerabilities, before they reach your backend services.

• API Gateways and Load Balancers: Centralize edge authentication, enforce rate limits, and validate request signatures to prevent direct public exposure of application backends.

• Microsegmentation: Enforce granular, identity-aware network policies to isolate workloads and restrict traffic exclusively to pre-authorized service-to-service communication paths, blocking lateral network movement by default.

• Configuration Integrity: Deploy Policy-as-Code tooling to continuously validate the live environment against the version-controlled IaC source of truth, automatically reverting out-of-band modifications to prevent unauthorized changes.

• Active Posture Scanning: Run Cloud Security Posture Management (CSPM) and Cloud Native Application Protection Platforms (CNAPP) to continuously scan for cloud misconfigurations, overly permissive IAM, and exposed storage.

• Continuous Monitoring: Maintain complete visibility across all systems by collecting logs, system metrics, and audit events to quickly detect, trace, and respond to live security events.

Conclusion 

Recent software supply chain campaigns demonstrate that development infrastructure, build pipelines, and developer utilities represent critical threat vectors and key points of compromise. Legacy access controls and point-in-time security scanning are insufficient to defend these environments against sophisticated intrusions. Hardening the development lifecycle requires implementing continuous, automated verification at every stage, unifying security postures across developer endpoints, code repositories, package registries, build runners, and deployment guardrails into a cohesive defensive framework.

Ultimately, the objective of pipeline security is to build a resilient architecture capable of isolating and containing an intrusion. By automating cryptographic validation and policy enforcement from the initial code commit to the final production deployment, organizations can significantly reduce their overall attack surface, safeguard downstream consumers, and ensure that any individual compromise is rapidly isolated and resolved before it can spread.

Acknowledgements

This guidance would not have been possible without the assistance of Bhavesh Dhake, Brentyn Muir, Brian Meyer, Emilio Oropeza, Eyad Mahmoud, Franklin Ramos, Gursev Singh, Omar ElAhdan, Sara Takhim, Stuart Carrera, Stuart Munro, Will Silverstone, and the Mandiant Security Transformation Services team.

from Threat Intelligence https://ift.tt/d2TnmlQ
via IFTTT