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:

• Android Trojan posing as government services and Starlink apps
• What happens if you download a cracked program?
• Miner inconvenience: how cybercriminals blackmail YouTubers into promoting malware
• Mario Forever, malware too: a free game with a miner and Trojans inside

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:

• The Winter Games in Italy: how to avoid the scams
• Summer scams in Paris
• Meme coins and NFTs: how not to lose your shirt
• How to watch soccer safely
• Neither flowers nor gifts: how women get scammed

Two kinds of work you want AI to do in a SOC

1. 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.
2. 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

1. If you’re already an Intezer customer, an Intezer admin creates an MCP OAuth application under Account Settings → MCP OAuth Applications.
2. 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.
3. 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.

The post The other half of the AI SOC: Intezer, now inside your AI workspace appeared first on Intezer.

Israel-based Entro specializes in non-human identity and credential security solutions, and it will enable SailPoint to enhance its products.

The post SailPoint to Acquire Entro in Reported $200 Million Deal appeared first on SecurityWeek.

Kodak told SecurityWeek it believes there is no threat to its systems or operations as a result of the cybersecurity incident.

The post Kodak Admits Data Breach After ShinyHunters Hack Claims appeared first on SecurityWeek.

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

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.

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:

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:

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:

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:

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:

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:

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:

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:

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

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

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

Indicators of compromise (IOC)

Network indicators

File indicators

Host indicators

Package indicators

References

Security: mastra@1.13.1 is compromised — malicious postinstall payload via `easy-day-js` dependency · Issue #18046 · mastra-ai/mastra

Microsoft has identified a supply chain attack on the Mastra-AI npm ecosystem, with 80+ packages compromised through npm account takeover. The attacker introduced a phantom dependency into the… | Microsoft Threat Intelligence

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.

Learn more

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

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

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

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

• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post From package to postinstall payload: Inside the Mastra npm supply chain compromise appeared first on Microsoft Security Blog.

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.

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.

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.

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:

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)
  • Method: curl with POST requests
  • Authentication: GUID + GEIP (geolocation)
• Actions Sent to C2:
  • GUID : Heartbeat beacon
  • SEED : Exfiltrated seed phrase
  • PKEY : Exfiltrated private key
  • REPL : Address replacement notification
  • GOOD : (legacy/fallback action)
• Commands from C2:
  • GUID : Acknowledge/refresh victim GUID
  • EVAL : Execute arbitrary JScript code (remote code execution)

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.

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:

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.

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
• T1113 Screen Capture | PowerShell screenshot capture supports operational visibility

Command and Control

• T1090 Proxy | Traffic routed through Tor via local SOCKS5 proxying

Exfiltration

• T1048.002 Exfiltration Over Alternative Protocol

Indicators of compromise (IOC)

References 

• https://www.microsoft.com/en-us/security/blog/2022/05/17/in-hot-pursuit-of-cryware-defending-hot-wallets-from-attacks/#clipping-and-switching. Microsoft (published 2022-05-17)
• https://gbhackers.com/ssh-over-tor-tunnel/. Ghbhackers(published 2026-04-28)

Learn more

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

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

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

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

• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Crypto Clipper uses Tor and worm-like propagation for persistence and control appeared first on Microsoft Security Blog.

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.

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.

Codename MDASH 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. 

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. 
• Validate stage: 10 cases (19.2%), incorrectly flagged intended findings as false positives.
• 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

• Configuration: Prepare / Scan / Validate: Bug discovery outputs from Experiment 1. Prove: GPT-5.5 / GPT-5.5-cyber. 

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

Sign up to follow codename MDASH and join the private preview. To go deeper on the engineering behind codename MDASH, explore our technical blog series.

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

The post Beyond the benchmark: Advancing security at AI speed  appeared first on Microsoft Security Blog.