Reading · The Monday Brief

Every attack in this issue got past a control that was working correctly at the time.

ChainDrop’s packages carry real Sigstore provenance, because a real workflow in a real repository really did build them. The travelers Midnight Blizzard is after complete a legitimate strong authentication and hand over a session that was never theirs. Malware exercises a Windows Hello key that never leaves the TPM, clearing your phishing-resistant Conditional Access policy on the way through. The Snowflake logins were just correct.

So this isn’t a story about controls failing. It’s a scope problem. Each of these mechanisms makes a narrow technical assertion, we read it as a broad assurance, and the gap between the two is where the week’s attacks live. Provenance tells you where a build ran. It has nothing to say about whether that build should have happened.

Worth asking which of your controls you’ve quietly promoted from evidence to guarantee.

Get The Monday Brief in your inbox every Monday. Subscribe for free, and share it with someone who’d find it useful.

Thanks for supporting us.

A valid signature stopped being evidence this week. ChainDrop publishes through npm trusted publishing, so its attestation is authentic: that tarball genuinely was built by that workflow in that repository. Verification passes. If you’re investigating, the useful fields are the Rekor log index and the workflow identity inside the certificate, not whether the signature checks out.
Strong MFA doesn’t help when your user authenticates the attacker’s session. Storm-2945 is manipulating DNS and HTTP traffic on hospitality networks served by captive portals, and some of those landing pages push victims into a device code flow. The authentication is real and the user performs it correctly. Block device code where you can.
Phishing-resistant isn’t theft-resistant once the host is gone. Malware in a signed-in session can use a Windows Hello for Business key, satisfy your authentication strength policy, register a device, then enroll passkeys of its own. Nobody designed that authenticator to survive a compromised endpoint, and nobody claimed they did.
What not to over-index on: treating a guilty plea as the end of the risk. Moucka’s Snowflake spree worked because the targeted accounts had no MFA, not because of anything exotic. One actor is off the board. The thousands of data warehouse accounts still reachable with a bought password are not.

Why it matters: ChainDrop doesn’t poison one package and wait. It steals GitHub Actions runner secrets and uses them to publish itself into other packages, so every compromised build becomes a launch point for the next one. The C2 domain isn’t hardcoded either. The worm asks an Ethereum smart contract where to send stolen data, which lets the operator move infrastructure with one transaction and no update to anything already deployed.

What is being misread: Teams hear “npm supply chain attack” and reach for the dependency-pinning playbook, picturing a malicious package sitting in the registry waiting for someone to install it. That model has the pipeline consuming trust. ChainDrop has it producing trust. Once the worm is running on a runner that holds valid publish credentials, your build system is the distribution channel, and there’s no upstream maintainer to notify because the last victim creates the next one.

Think Red (Douglas McKee): The interesting part here is not the worm code but the fact that the build runner already holds everything I need to keep going. Secrets, publish rights, a trusted identity in the registry. I do not have to convince anyone to install my package a second time, because the pipeline does that work for me every time it runs. Putting the command channel on an Ethereum contract just means you cannot seize or block a domain and make me disappear. The offensive lesson is that self-propagation plus inherited pipeline trust removes the two things defenders count on most, a single patient zero and a takedown target.

Act Blue (Ismael Valenzuela): Your CI/CD runner became an external dependency the moment it could publish to a registry. Most orgs still have it filed under “internal.”

Start with one of my favorites: egress, an explicit allowlist out of build environments. Rotate the Actions secrets on a schedule too, but temper your expectations there, because ChainDrop pulls them straight out of Runner.Worker process memory through /proc/pid/mem while the job is still live. Secrets that were supposed to evaporate when the job ended never get the chance. Ephemeral single-use runners buy you more here than any amount of secret hygiene will. Then look at what you’re trusting on the way out. Since the worm publishes through trusted publishing, its Sigstore attestation is genuine and your signature verification will pass, so pivot on the Rekor log index and the workflow identity in the certificate instead. Alert on publishes with no human-approved release behind them, and on anything reaching for stored secrets outside a known build step. Keep your SBOMs and your pinning, they’re still doing real work on what you consume. They just have nothing to say about what your pipeline ships once somebody else is driving it. If a runner can publish, threat model it like a domain admin.

Supporting sources:

Why it matters: A Midnight Blizzard subgroup tracked as Storm-2945 has been manipulating DNS and HTTP traffic on hospitality networks served by captive portals since May 2026, steering travelers through infrastructure it controls for credential theft and malware delivery. That puts a Russian state actor in front of your executives and your staff at exactly the moment when normal corporate connectivity and monitoring aren't up yet.

What is being misread: "Public Wi-Fi is risky" has been the takeaway for fifteen years, and it's the wrong one here. Nobody is passively sniffing an open network. Microsoft hasn't pinned down the initial vector yet, and what it says is that the equipment and management systems involved have enough in common to suggest access to shared services somewhere in the captive portal ecosystem, rather than someone breaking into hotels one at a time. The VPN answer treats the travel network as a transport problem. This attack lives in the authentication surface your traveler touches before the VPN is even up.

Think Red (Douglas McKee): What is interesting here is that we have been teaching how attackers manipulate and abuse and bypass captive portals in SANS SEC660 for years. I pick the hotel portal because it is the one screen every traveler is trained to trust and click through without thinking, and browsers automatically look for it when they join a new network. It appears before the VPN connects, it looks legitimate, and almost nobody questions it. From my perspective, that makes it a perfect delivery point. I am not trying to overcome user suspicion; I am taking advantage of a behavior the user and the browser already expect. Better yet, it all happens on a network your security team cannot see. By the time the laptop connects back to the corporate VPN, the credential theft or payload delivery may already be done.

Act Blue (Ismael Valenzuela): You can’t monitor a hotel’s captive portal, and you never will, so the defense has to start from the assumption that the travel network is hostile before anyone connects to it.

Phishing-resistant MFA plus Conditional Access tied to device compliance means a harvested password on its own gets the attacker nowhere. Good. Now here’s the problem: some of these landing pages redirect into device code authentication, and in that flow the victim performs a completely legitimate strong authentication and approves the attacker’s session rather than their own. Authentication strength does nothing against it, because nothing went wrong with the authentication. Kill device code flow wherever your applications can live without it, and fence it in with Conditional Access where they can’t. Against the credential-theft arm, no other control buys you more. The malware arm needs a different answer, because the payloads arrive as fake browser and OS updates pushed through the portal itself. No portal has any business updating your software, so make that a rule travelers can recite, and run endpoint detection that assumes the machine lives on networks you don’t own. These implants lift session tokens and cookies too, so back it all with risk-based Conditional Access that revokes a session the moment sign-in risk spikes. Prefer cellular over guest Wi-Fi where practical, and put a posture check between a returning traveler and anything sensitive. For the people whose calendars are public and whose travel is predictable, clean minimally provisioned devices on an always-on tunnel that comes up before any portal can interpose. Identity is the thing that follows your people into every hotel lobby, so it had better be the thing that refuses to work from a posture you don’t recognize.

Supporting sources:

Why it matters: Dirk-jan Mollema showed that malware already running inside a signed-in Windows session can use the victim’s Windows Hello for Business key to authenticate to Entra ID, register a device the attacker controls, and settle in for long-term cloud access. There’s no CVE and no patch coming, because this falls out of how the technology works rather than from a bug in it. Anyone who deployed Hello specifically to kill credential phishing now has to think about what it does for an attacker who’s already on the box.

What is being misread: Phishing-resistant authentication gets sold as the answer to credential theft, and teams come away treating a Hello-enrolled device as safe by construction. What that skips over is the difference between possessing the authenticator and being the user. Windows Hello proves a key is present on the device. It has no opinion about whether a human or a piece of malware in the same session is the one using it.

Think Red (Douglas McKee): The phishing-resistant part happened before I got here, and it does not help you now. Once I am running inside a signed-in context, that Windows Hello key is just another local capability I can drive. I do not need to steal a password or beat MFA, because the authenticator is sitting right there and it will happily prove who you are to Entra ID for me. Then I register my own device and I have durable cloud access that outlives your session. The point worth sitting with is that a strong authenticator on a compromised host becomes a persistence tool, not a barrier.

Act Blue (Ismael Valenzuela): Identity and endpoint aren't separate problems, and this is a good example of why a defensible security architecture based on layered controls is key. Hello for Business raised the cost of phishing and I’d deploy it again tomorrow. But it was never built to survive malware sharing the logged-in session, and we shouldn’t act surprised that it doesn’t.

What the attacker walks away with in this case, is worse than a borrowed session. That WebAuthn sign-in satisfies Conditional Access policies demanding phishing-resistant authentication strength and it counts as fresh MFA, which is exactly what’s needed to enroll new passkeys or Hello keys on the device they just registered, wherever your policy permits it. They now hold credentials of their own that outlive whatever you do to clean the original host. No admin rights required anywhere in that chain, and the private key never leaves the TPM, so there’s nothing to detect being stolen. Treat the endpoint compromise as the event and instrument everything downstream of it. Hunt Entra ID for device registrations and token requests that don’t fit the user’s pattern, and alert when a device join lands shortly after suspicious local activity. Tune your endpoint detection toward the process injection and session access that come first. Then put a ceiling on what a brand-new registered device can actually reach, which means Conditional Access requiring a compliant known device for anything that matters. The authenticator determines how hard you are to phish. Whether it’s still protecting you an hour after someone lands on the endpoint is a question about device and session integrity, and it’s a different question. As I often say, defensible security architecture in 2026 means effectively combining defense in depth, detection in depth, and response in depth.

Supporting sources:

Why it matters: Connor Riley Moucka pleaded guilty over a campaign that reached more than 165 Snowflake customer tenants, earned him somewhere around $495,000, and now carries up to 32 years. There was nothing novel in the technique. He used stolen credentials against customer accounts that weren’t enforcing MFA. The development that actually changes anything is that Snowflake’s strong-authentication rollout has reached the phase requiring MFA for human password users and removing password authentication for service users altogether.

What is being misread: It’s tempting to read the plea as the closing chapter on a 2024 campaign. The more useful question is how a gap this basic stayed this profitable for this long. Nobody in 2026 needs to relearn that MFA matters. What’s worth checking is whether any identity you own, human or service, can still reach high-value cloud data with a password somebody could buy.

Think Red (Douglas McKee): I am not attacking Snowflake, that would be hard! I am shopping infostealer logs for tenants that still accept reusable credentials. The platform can be perfectly patched and it does not matter if a valid password gets me to the data. What changes my economics is not one operator going to prison. It is the platform removing password-only paths so the credentials I buy stop working. The win condition for me has always been the cheapest (and easiest to obtain) valid login.

Act Blue (Ismael Valenzuela): Don’t let a sentencing headline convince you this exposure went anywhere. What happened to Snowflake customers was single-factor authentication failing at scale, and that condition could be alive and well across many of the SaaS and cloud data platforms your organization runs on. Enforce MFA on every account that touches a warehouse or an analytics platform, with no self-service opt-out and no service accounts quietly exempted because someone’s ETL job broke once. That closes the door Moucka walked through, and it isn’t enough on its own, because infostealers lift session tokens that sidestep MFA completely. Hunt anomalous login geography and impossible travel, and cut session lifetimes on your high-value data platforms so a stolen token has a short shelf life. Then work from the assumption that some credentials are already gone and watch for bulk extraction with no business reason behind it. Moucka was arrested within months of starting. The plea took two years. Neither timeline is yours, because yours is however long it takes the next infostealer log to reach a buyer, and that’s measured in days.

Supporting sources:

Krebs on Security: Canadian man pleads guilty in Snowflake extortions involving 165 organizations
CyberScoop: Snowflake hacker pleads guilty, faces up to 32 years in prison
CSO Online: Snowflake attacker pleads guilty to hack of 165 companies’ data
Snowflake Documentation: Strong-authentication rollout requiring MFA for human password users and eliminating passwords for service users

The captive portal has a browser update ready for you.

One operator reached 165+ organizations by logging into accounts that had no MFA on them. The plea is a reminder, not a resolution. Confirm MFA enforcement across every cloud data and analytics platform we run, exceptions included, and bring the coverage number to the board this quarter.
Storm-2945 is manipulating traffic on hospitality networks and walking travelers into flows where they approve the attacker’s session themselves, which means state-sponsored credential theft is now aimed at our people on networks we have no control over. Executive protection needs to cover travel: hardened devices and always-on connectivity for the roles that travel most.
A valid signature no longer proves a package is safe, and our build pipeline is now a live attack surface rather than a support function. ChainDrop turns compromised runners into distribution points while producing authentic provenance for everything it ships. Pipeline security belongs at the same tier as privileged administrative access.

Design Principle Impact: The trust boundary around CI/CD has to invert. ChainDrop demonstrates the pipeline producing trust rather than consuming it, so any runner holding publish rights is a privileged identity and needs explicit egress control plus ephemeral credentials. Signature verification alone won’t distinguish a legitimate release from a worm’s, which pushes provenance evaluation onto workflow identity and the Rekor log entry.
New Constraint/Dependency: Phishing-resistant authentication doesn’t guarantee session integrity. After the Hello for Business finding, access policy has to account for device and session posture at request time rather than resting on the strength of whatever authenticator got enrolled months ago.

Implementation Watch Item: Watch outbound connections from CI/CD runners this week. ChainDrop routes command traffic through an Ethereum smart contract, so any runner hitting blockchain RPC endpoints or unfamiliar external hosts is worth a look, as is any process touching Runner.Worker memory.
Common Failure Mode: Assuming pinning, SBOMs, and signature verification cover you here. They guard what you consume, and the worm’s attestations are legitimate anyway. Propagation happens build to build on stolen secrets. Remember, prevention is ideal, detection is a must.
Monitoring Patterns: Hunt Entra ID for Hello for Business authentications carrying an empty device ID, then correlate against unexpected device registration, new passkey enrollment, or odd token activity. Pull device code authentication events, especially from traveling users or unfamiliar egress, and hunt for executables created within two minutes of an NCSI captive-portal check on a traveling device. On the pipeline side, look for publish and release actions with no human approval attached. On the data side, bulk extraction with no business activity behind it.
Signal vs Noise Guidance: A publish tied to an approved release with a matching commit and a human sign-off is routine, and its attestation validates exactly the same way the worm’s does, so anchor on workflow identity rather than signature status. A publish triggered by a runner process that reached for stored secrets outside a known build step is worth waking someone up for. Empty device ID on a Hello authentication happens legitimately in incognito and non-SSO sessions, so treat it as a hunting lead rather than an alert. It gets interesting when an unexpected device registration or credential enrollment follows it.
Adversarial edge item: Pre-authorize containment for the pipeline. Where a runner triggers an unapproved publish, or combines unexpected secret access with Ethereum RPC queries or connections to freshly resolved infrastructure, automation should revoke that runner’s registry credentials and quarantine the build node without waiting on a human. ChainDrop moves faster than a ticket gets opened.

See you next Monday!

The Monday Brief is produced by Douglas McKee and Ismael Valenzuela. The opinions expressed are our own and do not reflect those of our employers.

No posts

A Self-Propagating npm Worm That Rotates C2 Through Ethereum, and a Hotel Portal That Borrows Your MFA

Comments