nolimit

Machine-speed SOC. We replace tier 1, 2, and 3 SOC functions — only decisions are left for humans. Threat intel via The Signal

[nolimit @n0limitSOC]

🔴 PRACTICAL DEFENSE

One VM in. Every VM gone.
Jun 18, 2026 · 6 min read
────────────────────────────────────────

A ransomware crew doesn't dream about your laptops. Encrypting endpoints one at a time is slow, loud, and survivable. What they want is the layer underneath all of it — the hypervisor — because everything you run lives there as a guest: production, the databases, the domain controllers, and very often the backups meant to save you. Reach the hypervisor and you don't encrypt a machine. You encrypt the estate, all at once, and everyone watches their screen go dark in the same minute.

That's why ransomware has been climbing the stack toward VMware ESXi. And CISA has now confirmed what defenders feared: an ESXi flaw is being actively used in ransomware campaigns.

## The escape: from one guest to the whole host

The vulnerability CISA flags for ransomware use is CVE-2025-22225, an arbitrary-write flaw in ESXi (CVSS 8.2), one of a trio Broadcom disclosed alongside CVE-2025-22224 (CVSS 9.3) and CVE-2025-22226. Researchers at Huntress observed an exploit toolkit chaining all three, and the mechanics are exactly the nightmare scenario: an attacker who has gained privileges inside a guest's VMX process can trigger an arbitrary kernel write and escape the virtual machine sandbox onto the host itself.

Read that as an attacker would. Compromising one ordinary virtual machine is a normal Tuesday — phishing, a web shell, a stolen credential. Most of the time that's a contained problem on one box. The escape is what turns it catastrophic: it converts "I'm on a guest VM" into "I own the hypervisor every other VM runs on." One foothold, promoted to the whole data center.

Ransomware's evolution isn't louder malware. It's higher targets. The crews stopped fighting your endpoints and went after the one box that runs all of them.

## The crown jewel with the thinnest visibility

Here's the part that makes ESXi the worst-case target. It is simultaneously the most consolidated system you own and the least watched. You can't install an endpoint agent on the hypervisor — it isn't a place your EDR runs. Its logging is limited, it runs headless, and most security programs treat it as infrastructure plumbing rather than an attack surface. So the highest-blast-radius box on the network is also the one with the dimmest lights.

That combination is why these attacks succeed. The intrusion rides straight through the coverage gap: a guest VM gets compromised (maybe noticed, maybe not), the VMX escape generates almost nothing anyone is watching, and the first unambiguous signal — mass encryption across every VM — arrives only when it's already over. By the time the alert is undeniable, recovery is measured in weeks, assuming the backups weren't virtualized on the same hosts.

## The signals were quiet, not absent

An ESXi ransomware run isn't actually silent. It's quiet — which is different. The signals exist; they just don't look like "ransomware" until they're assembled:

• SSH suddenly enabled on an ESXi host that normally has it off.

• A guest process reaching toward hypervisor interfaces it has no reason to touch.

• New administrative sessions on vCenter, outside any change window.

• A burst of VMs powered off in sequence — the standard prelude to encrypting their disk files.

Each one, on its own, has an innocent explanation. An admin enabling SSH to troubleshoot. A maintenance task powering down VMs. Pulled apart and routed to whoever happens to own "virtualization," none of them trips an alarm. Held together, in order, they are a ransomware operation staging on your hypervisor — and the window to stop it is the span between the escape and the first encrypted datastore.

## Reaching the box you can't put an agent on

The defense for a system you can't install...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/OZYMwq8JoE

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 INDUSTRY ANALYSIS

208 CVEs in a day. Patching was never the plan.
Jun 13, 2026 · 6 min read
────────────────────────────────────────

On June 10, 2026, one vendor shipped fixes for a record 208 vulnerabilities in a single day. Around 33 of them critical. A wormable kernel flaw in the pile. Multiple zero-days already being exploited before the patch existed.

That's one vendor. One Tuesday. Now add the rest of the month — NGINX, Cisco, Check Point, Oracle PeopleSoft, Chrome, Android — each with its own actively-exploited critical bug, each with its own emergency clock. Then ask the question every security leader is quietly avoiding: what, exactly, is the plan to patch all of this in time?

There isn't one. There was never going to be one.

## The math doesn't close

Patching 208 vulnerabilities across a real fleet is not a one-day job, or a one-week job. Each fix has to be prioritized, tested for regressions, scheduled into a change window, and rolled out without breaking the business that depends on those systems. A disciplined team might clear the critical ones in days and the rest over weeks. That is competence, not failure — and it still loses the race.

Because the other clock is faster. We've watched a disclosed bug get weaponized in five days (the-six-hour-bug.html). We've watched extortion crews sit inside a network for two weeks (clop-just-takes.html) through a zero-day nobody had a patch for. The window between "a fix exists" and "the fix is applied everywhere" is not administrative downtime. It's the exact interval attackers live in — and on a 208-CVE month, that window is open somewhere on your estate, all the time.

• A Defender race condition that hands an attacker SYSTEM.

• An HTTP/2 request that exhausts 64 GB of server memory in 45 seconds.

• A BitLocker bypass. A spoofing flaw in Exchange, exploited in the wild.

Pick which three you patch first. The honest answer is that while you're deciding, the others are exposed.

## Patching is a backlog, not a control

None of this is an argument against patching. Patch — quickly, relentlessly, on the criticals first. But be clear-eyed about what patching is: a backlog you administer, not a line you hold. It reduces how many doors are open. It does nothing about the attacker already walking through one of them while the change ticket is still in review.

For twenty years the industry has treated "patch faster" as the answer to vulnerability volume. Volume won. The number isn't going down — it's setting records. Any strategy whose success depends on out-running the patch backlog is a strategy that has already conceded the gap.

You don't get graded on how many vulnerabilities you patched. You get graded on the blast radius of the ones you didn't reach in time.

## The number that actually decides the outcome

Here's the metric that bounds the damage: the time between an exploit landing and that exploit being contained. Patching doesn't touch it. Whether a bug is patched, unpatched, or a zero-day nobody has a fix for, the question on the day of the attack is the same — how fast did you detect it, investigate it, reach a verdict, and shut it down?

That interval is the one variable a defender fully controls, and it's the one that sets the blast radius. A foothold contained in seconds is an incident report. The same foothold contained in days is a breach notification. The vulnerability count is upstream noise; the response window is the outcome.

## Out-pace what gets through

n0limit is built on the assumption that things will get through — that on any given week some exploitable door is open and you haven't reached it yet. So instead of betting the program on a patch race it can't win, it collapses the response window: every alert from every system, including the ones still waiting on a fi...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/EvhiQ5JOJj

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 THREAT RESEARCH

Open the email. The attacker is now you.
Jun 13, 2026 · 6 min read
─────���──────────────────────────────────

An employee opens an email in Outlook Web Access. They don't click a link. They don't open an attachment. They read it — that's the whole attack.

By the time they reach the signature, JavaScript embedded in the message is already running inside their authenticated session: reading their mailbox, lifting their credentials, sending messages as them. There is no malware on the endpoint. There is no exploit chain to a domain controller. There is only the user's own session, doing things the user never did. And in every log you have, the user did all of it.

## The flaw: a weaponized email

On June 9, 2026, Microsoft shipped an emergency fix for CVE-2026-42897, a zero-day in on-premises Exchange Server already under active exploitation. Technically it's a spoofing flaw — improper neutralization of input during web-page generation, which is the formal way of saying cross-site scripting in Outlook Web Access. Rated critical at CVSS 8.1.

The mechanics are brutally simple. An attacker sends a crafted email. The victim opens it in OWA. Arbitrary JavaScript executes in their browser session, and from there the attacker can spoof email, steal credentials, hijack the session, and perform actions on behalf of the compromised user. It affects every update level of Exchange Server 2016, 2019, and Subscription Edition. No privileged access required on the attacker's side, and the only "user interaction" needed is the one thing email is designed to make people do: open the message.

The crown jewel of most enterprises isn't a database. It's the mail server — because it's where identity, communication, and trust all converge. Compromise it and you don't break in. You become the company's voice.

## Why the mail server is the worst place for this

Exchange isn't just where email lives. It's an identity system. It holds the conversations attackers use to pivot, the password-reset flows they hijack, the org chart they impersonate. An attack that runs inside a trusted OWA session inherits all of that — and wears the user's identity while it does.

That's what makes CVE-2026-42897 nastier than its modest score suggests. There's no second-stage payload to flag, no anomalous process tree, no beacon to a command server. The malicious actions are HTTP requests issued by a legitimate, authenticated browser session — indistinguishable, on their face, from the user simply working in their inbox. The attacker isn't hiding from your detection. They're wearing your user as a disguise.

## What the SOC actually sees

Pulled apart into individual events, the attack is invisible. "User opened an email" — happens ten thousand times a day. "User accessed mailbox items" — that's the job. "User sent messages" — normal. "Credential used from the session" — the session is authenticated, so of course it is. Not one of those lines, on its own, is worth chasing.

The breach exists only in the contradictions between them: script execution inside OWA, followed within seconds by a burst of mailbox actions and a credential touch that don't match how this human actually works. Each signal is benign alone. Correlated, in order, they are a session being driven by someone who isn't the user. The tell was always there — it just required holding every event at once and asking a question most stacks never ask: is this really them?

## How n0limit catches the session that isn't the user

n0limit treats every action inside a session as something to investigate, not something to wave through because the session authenticated. When script executes in an OWA context and is followed by mailbox and credential activity that contradicts the user's established pattern, those events aren't filed se...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/wobtfO07Qo

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 THREAT INTELLIGENCE

Cl0p doesn't encrypt anymore. It just takes.
Jun 12, 2026 · 6 min read
────────────────────────────────────────

A university finds out it's been breached the way most victims do this season: not from an alarm, but from an email. No drives are encrypted. Nothing is locked. Nothing on the network looks broken. The only evidence that anything happened is that roughly 40 gigabytes of student records — financial aid, health files, immigration documents — are now sitting on a leak site, with a deadline attached.

There was no ransomware, in the sense everyone still pictures it. There was just theft. And it had been happening, quietly, for two weeks.

## The door: one unauthenticated request

On June 10, 2026, Oracle published an emergency advisory for CVE-2026-35273, a critical (CVSS 9.8) unauthenticated remote code execution flaw in the Environment Management Hub of PeopleSoft PeopleTools 8.61 and 8.62. The vector tells the whole story: AV:N/AC:L/PR:N/UI:N — remotely over HTTP, low complexity, no privileges, no user interaction. Send the right request to the right enterprise HR system and you are running code on it.

The advisory came late. Attackers had been exploiting the bug as a zero-day since at least May 27. By the time Oracle confirmed it, Google's Threat Intelligence Group was notifying more than 100 organizations whose exposed endpoints matched the attack — and 68% of the victims were in higher education, an entire sector running the same internet-facing payroll-and-records platform.

•

May 27, 2026 — staging
The intruders settle in. They install MeshCentral, a legitimate remote-management tool, and the acme-client package to auto-provision Let's Encrypt certificates — so their access looks like sanctioned IT, not an attack.

•

May 27 – June 9 — quiet work
Reconnaissance maps the PeopleSoft configuration. A custom propagation script moves laterally, host to host. Records are read and staged for exfiltration. Two weeks of it, with no encryption event to trip a single alarm.

•

June 10, 2026 — disclosure
Oracle ships the emergency fix. Cl0p and ShinyHunters are named; the extortion emails go out. For the victims, the patch is months too late to matter — the data already left.

The ransom note isn't the start of the incident. It's the receipt. By the time it arrives, the only decision left is whether to pay.

## Cl0p doesn't need to encrypt you

Cl0p has run this exact play before — MOVEit, Accellion, SolarWinds. The pattern never changes: find one internet-facing enterprise application that an entire industry depends on, weaponize a zero-day before anyone's patched, exfiltrate at scale, and extort. The encryption step — the loud, theatrical, drive-locking part everyone built their defenses around — is now optional. The leverage is the data itself.

That shift quietly breaks a lot of security programs. We spent a decade learning to detect encryption: the mass file rewrites, the ransom note dropped on the desktop, the shadow copies deleted. A pure data-theft extortion produces none of that. It produces a remote-management tool that "looks like IT," a certificate that "looks routine," an account reading more records than usual, and a script touching hosts it has no business touching. Every one of those is a shrug in isolation. None of them is the thing your tooling was trained to catch.

## The two weeks nobody was watching

Here is the uncomfortable part. For most of the 100-plus victims, the breach didn't hide. It was sitting in the telemetry the whole time — fourteen days of it. The MeshCentral install was logged. The new certificate was logged. The lateral movement generated events. The unusual reads against the records database were right there.

What was missing wasn't data. It was ...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/gUbDKB24hA

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 BREACH LESSONS

Ransomware didn't hack in. It logged in.
Jun 10, 2026 · 6 min read
────────────────────────────────────────

At 3 a.m., a remote-access VPN session opens. It is fully authenticated. It belongs to an account whose owner is asleep, two time zones away, and who did not touch a keyboard that night.

No exploit alert fires. No malware signature trips. The firewall doesn't flag it, because the firewall is the thing that just vouched for the session. By every log your SOC reads, this is a normal login — the most boring line in the file. Days later, it's Qilin ransomware.

This is the part of the breach nobody screenshots: the attacker didn't break in. They logged in.

## The flaw that forges a session

On June 8, 2026, Check Point shipped an emergency hotfix for CVE-2026-50751, a critical authentication bypass (CVSS 9.3) in Remote Access VPN and Mobile Access deployments that still use the deprecated IKEv1 key-exchange protocol. The root cause is a logic flaw in certificate validation. The effect is blunt: an unauthenticated, remote attacker can establish a remote-access VPN connection without a valid user password.

Read that again. Not "crash the gateway." Not "run code." Become a trusted, authenticated user of your network — on purpose, through the front door, with the gateway's blessing.

•

May 7, 2026 — quietly live
The earliest observed exploitation. No disclosure, no patch, no headlines — just authenticated sessions that shouldn't exist.

•

Early June 2026 — escalation
Exploitation attempts climb. In at least one confirmed case, the access is followed by post-compromise activity tied to a Qilin ransomware affiliate, across a few dozen targeted organizations.

•

June 8, 2026 — disclosure + patch
Check Point publishes the hotfix; CISA adds CVE-2026-50751 to its Known Exploited Vulnerabilities catalog the same day.

•

June 11, 2026 — three days to fix
CISA's remediation deadline for federal agencies — one of the shortest it has ever issued. The clock length is the threat assessment.

The hard breaches of this era don't trip an alarm. They authenticate. The attacker's goal isn't to look like an exploit — it's to look like you.

## Why "logged in" is so much worse than "hacked in"

Twenty years of security tooling is tuned to catch the act of breaking: the overflow, the dropped payload, the command that shouldn't run. That tooling is genuinely good now. So attackers stopped breaking.

An authentication bypass produces no exploit to detect. It produces a session — a legitimate-looking, fully-credentialed session that your VPN, your identity provider, and your access logs all agree is real. The only artifact is "successful login," and successful logins are the one thing a SOC is trained never to chase. The signal is indistinguishable from the millions of benign logins around it, because on the wire it is one.

This is why identity is the real perimeter, and why the perimeter device vouching for an intruder is the worst-case version of the problem. The trust decision already happened. By the time anyone asks "should we have trusted that session?", Qilin has been inside for days.

## The black-box problem

Here's the uncomfortable question CVE-2026-50751 forces: when a session shows up authenticated, can your stack tell you why it was trusted?

For most teams the honest answer is no. The tools can tell you a session happened — timestamp, account, source IP. They cannot show you the reasoning behind the trust, because there was no reasoning recorded, just a boolean: the gateway said yes. When the basis for trust is opaque, you have no way to separate a real login from a forged one. You're not investigating; you're taking the gateway's word for it. And the gateway was the thing th...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/rcoA2cb9cv

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 SOC OPERATIONS

The breach was three alerts. Nobody connected them.
Jun 8, 2026 · 6 min read
────────────────────────────────────────

Picture three tickets in your queue, opened over three different weeks, closed by three different analysts who never spoke to each other.

The first: an authentication anomaly on an SD-WAN controller. Odd, but it resolved, and the controller kept running. Closed. The second: a new SSH key showed up in an admin account's authorized-keys file. Probably the network team during a maintenance window. Closed. The third: a configuration change pushed out to the edge devices. That's literally what the platform is for. Closed.

Each one, on its own, was a shrug. Together, they were a threat actor walking from the open internet to root on your network's management plane — and then pushing their will to every device downstream.

## The chain Cisco documented this month

This isn't hypothetical. On June 5, 2026, Cisco disclosed its seventh SD-WAN zero-day of the year. Read the advisories together and they describe an end-to-end path, link by link:

•

CVE-2026-20127 — get in
A maximum-severity authentication bypass on the Catalyst SD-WAN Controller. An unauthenticated, remote attacker sends crafted requests and gains high-privileged internal access. Cisco Talos has tracked a sophisticated actor, UAT-8616, abusing this since at least 2023.

•

CVE-2026-20182 — get privileged
A second authentication bypass lets the attacker become an authenticated peer of the appliance and inject their own public key into the vmanage-admin account's authorized SSH keys. That's the quiet alert in the middle: a key that shouldn't be there. They now hold netadmin.

•

CVE-2026-20245 — get root
With netadmin in hand, a crafted file upload to the SD-WAN Manager CLI runs arbitrary commands as root. Cisco observed exploitation in the wild — discovered by Mandiant — and, in limited cases, a configuration change pushed to edge devices. There is no patch yet and no workaround.

Cisco's advisory for that last bug explicitly names the first two as the way to obtain the netadmin precondition. The vendor itself drew the line connecting the dots. The question is whether your SOC would have.

A breach is almost never one alert. It's a sequence — across systems, across privilege levels, across time. Attackers think in chains. Most defenses still triage in singletons.

## Why three real alerts read as three non-events

None of these links trips a five-alarm fire on its own. The first is an "authentication anomaly" �� a category your team sees hundreds of times a week, almost all benign. The second is a configuration-file change on an admin account — indistinguishable, at a glance, from legitimate operations. The third, the root-level one, scores a moderate 7.8 and surfaces as a routine config push, which is the platform's entire job.

So they land in different queues. The controller alert goes to whoever owns network infrastructure. The SSH-key change goes to whoever watches identity. The config push may not alert at all. Three people, three contexts, three independent "looks fine to me" decisions. The correlation that turns three shrugs into one breach never happens, because no single human is holding all three at once.

This is the coverage gap that volume created. It isn't that analysts are careless — it's that the breach only exists in the relationships between alerts, and human triage is structurally built to look at one alert at a time.

## Totality is the answer to chains

You don't close this gap by tuning any single detection to be louder. The controller bypass should be a low-confidence alert in isolation. So should an SSH-key change. Crank them all to critical and you've simply moved alert fatigue, not fixed i...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/RweyIYXAfG

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 THREAT ANALYSIS

Six hours to find it. Five days to weaponize it.
Jun 8, 2026 · 6 min read
────────────────────────────────────────

On May 13, 2026, F5 disclosed a critical heap buffer overflow in NGINX — the web server that sits in front of roughly a third of the internet. The bug, branded NGINX Rift and tracked as CVE-2026-42945, scored 9.2 on the CVSS v4.0 scale. Patches shipped the same day.

Five days later, VulnCheck reported it was being exploited in the wild.

That sentence is the whole story of modern cybersecurity, compressed. Not because NGINX is unusually fragile — it isn't — but because of how fast every clock in the sequence is now running.

## The timeline that should worry you

Walk through the dates, because the pace is the point.

•

April 2026 — discovery
An autonomous vulnerability-analysis system run by the research outfit depthfirst flags the flaw during a routine scan. Time to find a previously unknown bug in code that has shipped since 2007: roughly six hours.

•

April 24, 2026 — confirmation
F5 confirms the finding and begins a coordinated disclosure process.

•

May 13, 2026 — disclosure + patch
F5 and depthfirst publish the advisory. Fixes land in NGINX 1.30.1 (stable) and 1.31.0 (mainline). The clock for every defender on earth starts now.

•

By May 18, 2026 — exploitation
VulnCheck observes real-world attacks against unpatched servers. Five days from public advisory to active exploitation.

A machine found the bug in six hours. Threat actors weaponized the fix in five days. Somewhere in the middle sits the defender, who is still expected to read the advisory, inventory their estate, schedule a maintenance window, and push a patch — on a human calendar.

The discovery-to-exploitation window used to be measured in months. For NGINX Rift it was measured in days. The next one will be measured in hours.

## Why the patch is the starting gun, not the finish line

There's a comfortable myth in security that a patch closes a risk. It doesn't. A patch publishes a risk. The moment a fix ships, the diff between the old code and the new code is a roadmap — it tells anyone watching exactly where the flaw lives and how to reach it. Weaponizing a disclosed-and-patched bug is far easier than finding one from scratch.

So the disclosure that protects the patched also arms the attacker against the unpatched. And the unpatched population is enormous. Roughly 5.7 million internet-facing NGINX servers were running potentially vulnerable versions when Rift dropped. Patching that many systems is not a six-hour job. It is a multi-week, multi-team, change-control-approved job — and the attackers know it.

This is the asymmetry that defines the era. Finding bugs is being automated. Weaponizing them is being automated. The one part still moving at human speed is the part defenders own: noticing, deciding, and responding.

## What the bug actually was — and why it barely matters

For the record: NGINX Rift is a two-pass contract violation in the server's script engine. An is_args state flag set during the length-calculation pass leaks into the copy pass, so ngx_escape_uri writes past its allocated buffer when a rewrite rule combines an unnamed PCRE capture with a question mark in the replacement string. The reliable outcome is a crashed worker process — a denial of service. Remote code execution is possible only in narrower conditions, which is the small mercy here.

But notice how little the mechanism matters to the strategic problem. Whether the next Rift is a heap overflow, a deserialization flaw, or an auth bypass, the shape of the event is identical: machine-speed discovery, same-day disclosure, days-to-exploitation, and a defender population that cannot move at the speed of the threa...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/eXYeWqqXSW

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 INDUSTRY ANALYSIS

The AI Paradox: Will AI Automate Cybersecurity Jobs or Just the Arms Race?
Jun 5, 2026 · 7 min read
────────────────────────────────────────

## The AI Paradox: Will AI Automate Cybersecurity Jobs or Just the Arms Race?

It’s 3 AM. The pager goes off. Again. This time, it’s a flurry of alerts from the SIEM – anomalous activity detected across a swath of developer workstations, all pointing to outbound connections to suspicious domains. You’re still half-asleep, but the adrenaline kicks in. Log into the EDR, start pulling process trees. What you find is a blur of npm CLI commands, followed by a rapid-fire sequence of file writes and network connections. Thirty-two packages, compromised in 72 seconds flat. Seventy-two seconds. That’s not a human attacker. That’s automation, pure and simple, likely leveraging compromised CI/CD pipelines to inject a credential-stealing worm. You’ve just walked into the Red Hat supply chain compromise, a variant of the Shai-Hulud infostealer, and it’s already hit nearly 10 million collective downloads. Your first thought? How the hell do we keep up?

This isn't some hypothetical threat model from a conference whiteboard. This is what we’re seeing right now. The speed, the scale, the multi-stage payload delivery focused on developer credentials and cloud material—it screams automation at every step. And it begs a fundamental question that's been rattling around the community: Is AI going to solve our "limited resources" problem as defenders, or is it just pouring gasoline on the offensive capabilities of our adversaries, escalating the arms race faster than ever?

## The Problem

For years, we’ve been talking about the cybersecurity talent gap. Not enough skilled people, too many alerts, too much noise. The promise of AI has always been to close that gap, to automate the mundane, to surface the critical, and to let our analysts focus on the high-value, strategic work. But what we’re seeing on the ground tells a different story.

Take that Red Hat incident. Thirty-two malicious NPM packages published in 72 seconds. That’s about 2.25 seconds per package. No human operator, no matter how skilled, is doing that manually. This is a highly sophisticated, likely AI-driven or at least heavily automated, attack chain. The attackers aren’t just looking for low-hanging fruit; they’re targeting the very heart of development—CI/CD pipelines, GitHub Actions secrets, npm tokens, cloud credentials, Kubernetes and Vault material. These are the crown jewels, and the speed of compromise means our traditional detection-and-response timelines are already obsolete.

Then there’s the Google Gemini voice assistant vulnerability. A single poisoned notification from WhatsApp or Slack could have allowed attackers to hijack devices, control smart home devices, initiate Zoom calls, or even subtly corrupt the AI’s long-term memory. This isn't just a fun parlor trick; it's a terrifying attack surface at the intersection of AI assistants and everyday communication channels. We’re integrating AI into everything, often without fully understanding the blast radius of these integrations. Are we auditing notification permissions and AI assistant capabilities in our enterprise environments with the rigor needed?

And let's not forget the immediate weaponization of vulnerabilities. Cisco patched a critical SSRF flaw in Unified CM (CVE-2026-20230) that could lead to root access, and proof-of-concept exploit code was *immediately* available publicly. This isn't a theoretical risk; it's an imminent threat. Attackers are watching disclosures, and they're leveraging public PoCs faster than many organizations can patch. This speed of weaponization is a direct reflection of automated threat intelligence gathering and exploit development.

#...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/YjHr4QuNjJ

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 VISION

AI-Generated Zero-Day Exploits: The Dawn of Autonomous Attackers and How to Build Proactive AI Defenses
May 29, 2026 · 7 min read
────────────────────────────────────────

## AI-Generated Zero-Day Exploits: The Dawn of Autonomous Attackers and How to Build Proactive AI Defenses

It was 2 AM, and the SOC lead’s phone rang – an urgent ping from a tier-one analyst. They were looking at something… strange. Not just a new variant, not just a clever obfuscation, but a vulnerability being exploited in the wild that had absolutely no public record. No CVE, no vendor advisory, nothing. Just a very specific, deeply technical exploit chain hitting a popular, well-maintained enterprise application. We’d seen nation-state actors pull this off before, of course, with their limitless resources and highly specialized teams. But this felt different. The attack signature was too clean, too precise, almost… elegant. It was then that the analyst, a veteran of countless late-night hunts, muttered, “This looks like something an AI built.”

That gut feeling, that chilling intuition, is becoming our new reality. Just recently, Google publicly confirmed what many of us in the trenches have been dreading: an AI-generated zero-day exploit identified in the wild. This isn’t a theoretical future anymore; it’s here. We’ve crossed a threshold, moving from AI as a tool for threat actors to AI as an autonomous, vulnerability-finding, exploit-generating entity. The implications are profound, fundamentally shifting the ground beneath our feet.

## The Problem

For years, our defensive strategies have largely been reactive. We wait for a CVE to drop, for a vendor patch to be released, or for an attack to hit our perimeter before we scramble to respond. This model, while imperfect, worked because the pace of vulnerability discovery and exploitation was, to some extent, human-constrained. Skilled reverse engineers and exploit developers are rare, and their work takes time. Even with advanced tooling, the cycle from vulnerability discovery to weaponized exploit could take weeks, sometimes months, giving defenders a crucial window to prepare.

But that window is slamming shut. We’re already contending with an overwhelming volume of threats. The "Megalodon" supply chain attack, compromising over 5,000 GitHub repositories in just six hours, shows the speed at which automated attacks can propagate. And when vulnerabilities like the actively exploited Trend Micro Apex One flaw or the Exchange OWA zero-day (CVE-2026-42897) emerge, our SOC teams are immediately overwhelmed. They're already grappling with alert fatigue and tool sprawl, leading to burnout and missed threats. Adding AI-generated zero-days to this mix isn't just an increase in volume; it's a fundamental change in the nature of the threat.

Think about the traditional kill chain. Reconnaissance, weaponization, delivery, exploitation, installation, command and control, actions on objective. Each stage historically required human expertise and intervention. AI changes this. An AI could theoretically automate the entire process: scanning vast codebases for subtle logical flaws, generating multiple exploit payloads tailored to specific environments, testing them against various configurations, and then launching them with precision. The speed, scale, and sophistication of such an attack would be unlike anything we've encountered.

## Why It's Getting Worse

The acceleration isn't slowing down. We're seeing a convergence of factors that amplify the threat of AI-generated exploits. First, the proliferation of large language models (LLMs) and other advanced AI techniques is democratizing offensive capabilities. What once required a deep understanding of assembly language and kernel internal...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/ChVf27cSeq

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 THREAT INTELLIGENCE

"TrapDoor" Weaponizes AI Assistants: How Malicious Packages Are Poisoning Claude & Cursor to Steal Your Credentials
May 29, 2026 · 7 min read
─────────────────────��──────────────────

## "TrapDoor" Weaponizes AI Assistants: How Malicious Packages Are Poisoning Claude & Cursor to Steal Your Credentials

The call came in at 2 AM, the kind that makes your stomach drop. A developer, mid-deploy, noticed something off. Their GitHub token, just used, had been revoked. Then another. And another. Within minutes, we were staring down a cascade of compromised credentials—AWS, SSH keys, even some crypto wallet keystores. The initial forensics pointed to a dependency, something benign-looking, a utility package pulled from npm just hours before. But this wasn't just another malicious package. This was different. This was "TrapDoor," and it was weaponizing something we’d all started to rely on: our AI coding assistants.

We’ve been living and breathing incident response for years, and we thought we’d seen every flavor of supply chain attack. But watching an attacker not only exfiltrate sensitive data but also subtly corrupt the very tools meant to make developers more efficient—their AI assistants—that was a new kind of gut punch. It wasn't just about cleaning up the immediate compromise; it was about understanding how deeply this could embed itself into future development cycles.

## The Problem

The "TrapDoor" campaign didn't reinvent the wheel for initial access—it leveraged malicious packages, a well-worn tactic. The critical difference, however, was its sophisticated post-exploitation phase. We observed attackers distributing seemingly innocuous packages, such as eth-security-auditor, across popular ecosystems like npm, PyPI, and https://t.co/ol58tX5MX9. Once executed, these packages didn't just grab credentials and run; they performed a targeted sweep for developer AI assistant configurations.

Specifically, the malware sought out and modified instruction files for AI coding assistants like Claude and Cursor. Think about that for a second. Your AI assistant, designed to help you write code, debug, and suggest improvements, was subtly being re-educated by an adversary. We saw instances where the attackers injected "invisible instructions" into these AI tools. These instructions might tell the AI to subtly introduce vulnerabilities into new code, prioritize specific, less secure libraries, or even redact critical security warnings from its output. It’s a silent, insidious form of poisoning that, left undetected, could lead to a systemic weakening of an organization's codebase over time.

The scope of credential theft was equally alarming. Beyond the AI manipulation, "TrapDoor" was designed to harvest a comprehensive range of sensitive data. We found evidence of SSH keys, AWS credentials, GitHub tokens, browser login databases, and even crypto wallet keystores being exfiltrated. This wasn't a smash-and-grab; it was a methodical, surgical extraction of everything a developer needs to build, deploy, and manage code across multiple environments. The impact wasn't limited to a single developer's machine but had the potential to unravel an entire organization's security posture by compromising access to critical infrastructure and intellectual property.

Traditional dependency scanning tools, while crucial, often fall short here. They're excellent at identifying known vulnerabilities in package manifests or identifying malicious code patterns within the package itself. But what happens *after* the package executes? How do you detect subtle modifications to an AI's instruction set, especially when those modifications are designed to be stealthy and context-aware? We're talking about a threat that operates in the grey areas of trust, lever...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/wZQBsGqeeE

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 SOC OPERATIONS

The Silent Ransom Group's Physical Infiltration: When Ransomware Goes Analog and Your SOC Needs Bouncers
May 28, 2026 · 9 min read
───────────────���────────────────────────

## The Silent Ransom Group's Physical Infiltration: When Ransomware Goes Analog and Your SOC Needs Bouncers

The call came in just after 10 AM on a Tuesday. Our client, a mid-sized law firm specializing in intellectual property, was in full panic mode. Not because of a phishing email or a zero-day exploit, but because two individuals, dressed in sharp business casual and carrying official-looking IT badges, had walked into their office, sweet-talked their way past reception, and spent an hour in their server room. They claimed to be "third-party auditors" for a routine network integrity check. They even had a convincing story about a last-minute schedule change. By the time the firm's actual IT manager, working remotely that day, saw the security camera footage and realized he knew neither of these "auditors" nor of any scheduled work, it was too late. The individuals were long gone, and with them, several network-attached storage (NAS) devices containing highly sensitive client data. This wasn't just a data breach; it was a physical smash-and-grab facilitated by social engineering so slick it bypassed every digital defense the firm had. This was The Silent Ransom Group, and they weren't just encrypting data anymore—they were walking out the door with it.

We've dealt with ransomware groups for years. We’ve seen the evolution from spray-and-pray emails to sophisticated, multi-stage attacks leveraging Cobalt Strike and living-off-the-land binaries. But this—this was different. This wasn't about exploiting a vulnerability in a firewall or an unpatched server. This was about exploiting human trust and the often-overlooked chasm between cyber and physical security. It’s a wake-up call, not just for law firms, but for every organization that holds valuable data: the attack surface isn't just digital anymore. It's the front door, the reception desk, and every employee who might hold that door open for a seemingly legitimate visitor.

## The Problem

For too long, our industry has drawn a thick line between cyber and physical security. SOCs focus on logs, network traffic, endpoint telemetry, and cloud configurations. Physical security teams worry about badges, cameras, and door access. Rarely do these two worlds truly converge in a coordinated defense strategy. This siloed approach is precisely what groups like The Silent Ransom Group (SRG), also known as Luna Moth or Chatty Spider, are exploiting with devastating effectiveness.

The FBI recently issued a stark warning about SRG's tactics, specifically highlighting their in-person data theft operations. These aren't just one-off incidents; they represent a calculated shift in adversary tradecraft. Why bother with the complexities of exfiltrating terabytes of data over a compromised network—risking detection by network intrusion detection systems, data loss prevention (DLP) solutions, and egress filtering—when you can simply walk in and carry it out on physical media? The ROI for the attacker is clear: reduced technical risk, potentially faster exfiltration, and a high likelihood of success against targets unprepared for such an analog approach.

Think about the typical incident response playbook. It’s heavy on digital forensics: analyzing disk images, reviewing firewall logs, hunting for indicators of compromise (IOCs) in SIEMs. But what happens when the primary "IOC" is a grainy security camera photo of an unknown person walking out with a server? Our standard tools and processes are often blind to this type of threat. We’re left scrambling, trying to piece together a timeline...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/Rooyab9YQO

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 PRACTICAL DEFENSE

TrapDoor's AI Assistant Hijack: How Malicious Packages Are Turning Claude and Cursor Against Developers
May 28, 2026 · 9 min read
────────────────────────────────────────

## TrapDoor's AI Assistant Hijack: How Malicious Packages Are Turning Claude and Cursor Against Developers

Picture this: it’s 3 AM, and the on-call pager just screamed. A critical alert from your EDR – suspicious outbound connections from a developer’s workstation. You jump on, heart pounding, and find yourself staring at a terminal session that looks… normal. But it’s not. Not really. The developer, bleary-eyed and confused, swears they didn’t execute anything unusual. Their AI coding assistant, Claude, was just helping them refactor some legacy code, and then… this. The machine is now exfiltrating SSH keys, AWS credentials, and GitHub tokens, all while the developer was interacting with their trusted AI copilot. This isn't a hypothetical scenario anymore. This is the grim reality of "TrapDoor."

We’ve been in the trenches, seen the nastiest stuff. But this new breed of supply chain attack, specifically the TrapDoor campaign, hits different. It's not just about poisoning a package anymore; it’s about weaponizing the very tools developers rely on for their daily work. It’s a betrayal of trust on a fundamental level, turning an AI assistant meant to boost productivity into an unwitting accomplice for credential theft. And it’s insidious because it leverages the invisible parts of our tools – the memory files, the configurations – to plant its seeds.

## The Problem

The TrapDoor campaign, as recently detailed by researchers, has been a wake-up call for the entire developer ecosystem. We’re talking about 34 malicious packages, across hundreds of versions, spanning npm, PyPI, and https://t.co/ol58tX5MX9 – the lifeblood of modern software development. These aren't just your garden-variety typosquatting attacks; these are sophisticated operations designed to blend in, to look legitimate, and to execute their payload with surgical precision. The sheer scale is staggering: over 5,500 GitHub repositories were recently compromised in a similar "Megalodon" attack, injecting malicious GitHub Actions workflows to steal credentials and plant backdoors. This isn't just a few bad actors; this is an organized, persistent threat targeting the very foundation of our software supply chain.

What makes TrapDoor particularly nasty is its novel approach to credential harvesting. Traditional supply chain attacks often focus on direct execution of malicious code within a package, aiming to steal files or establish persistence. TrapDoor does that too, but it adds another layer: it actively targets AI coding assistants like Claude and Cursor. How? By manipulating their project memory files. These memory files, often overlooked by security tools, are where AI assistants store context, preferences, and even snippets of code they’ve processed. By injecting invisible instructions or malicious prompts into these files, the attackers can subtly coerce the AI to perform actions that benefit them – like exfiltrating sensitive data that the developer might not even realize is being handled by the AI.

Think about the data points: your SSH keys, AWS credentials, GitHub tokens – the keys to the kingdom for any developer. These aren't just floating around; they're often secured, sometimes even hardware-backed. But if your AI assistant, a tool you implicitly trust, starts subtly feeding these to an attacker through manipulated prompts or background processes, you're in deep trouble. The average time to detect a breach is still far too long – often months. In that time, an attacker with your credentials can pivot, escalate privileges, and cause catastrophic damage. And the worst part? The developer...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/rN0agfUA0J

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 PRACTICAL DEFENSE

Aur0ra Ransomware's Silent Kill: How to Detect Fileless Encryption When Renames Are Gone
May 26, 2026 · 9 min read
────────────────────────────────────────

## Aur0ra Ransomware's Silent Kill: How to Detect Fileless Encryption When Renames Are Gone

The call came in at 2 AM – a familiar pattern, unfortunately. Our client, a mid-sized engineering firm, had users reporting strange behavior: files were inaccessible, but their names looked… normal. No “.encrypted” or “.[random_string]” extensions. No frantic pop-ups yet, just a growing dread that something was very wrong. We jumped on it, expecting the usual ransomware signature—file renames, high CPU on encryption processes, the works. But as we dug deeper, the picture that emerged was far more insidious. This wasn't your run-of-the-mill LockBit or BlackCat variant. This was Aur0ra, and it was deliberately designed to fly under the radar, specifically by omitting the file rename events that so many of our EDR rules rely on. It was a silent kill, and it was already spreading.

Imagine a critical incident unfolding, and your primary indicators, the ones you’ve tuned and trusted for years, simply aren't firing. That's the scenario Aur0ra is creating. We were looking at a growing wave of inaccessible data, but our EDR wasn't screaming "ransomware." It was a stark reminder that attackers are constantly innovating, and if we're not adapting our detection strategies just as quickly, we're already behind.

## The Problem

For years, a cornerstone of ransomware detection has been the observation of file system events, particularly file renames. When a ransomware strain encrypts a file, it typically renames it, often adding a new extension to signify its encrypted state and to provide instructions for decryption. This behavioral pattern is so prevalent that many EDR rules are explicitly written to flag processes that rapidly rename a large number of files, especially with suspicious extensions. It’s a low-hanging fruit for defenders, and it has served us well.

The problem is, attackers know this. Aur0ra ransomware, recently identified and actively targeting Windows systems, completely sidesteps this common detection mechanism. Instead of renaming files, it encrypts them in place. The file name remains the same, the extension remains the same, but the contents are irrevocably scrambled. This simple change has profound implications for detection. Our carefully crafted rules, looking for patterns like *.doc -> *.doc.encrypted or *.xls -> *.xls.hacked, are suddenly blind. The EDR logs show file modifications, yes, but without the rename component, that activity looks far less suspicious in isolation. A legitimate application might modify many files; it’s the rename coupled with modification that often triggers the alarm.

This isn't just an academic exercise. In the incident with the engineering firm, we saw hundreds of thousands of files being "modified" by a seemingly innocuous process. Without the rename event, the alert fatigue from every legitimate application touching files would be astronomical. The sheer volume of benign file modification events makes it incredibly difficult to spot malicious activity when the most distinctive indicator is stripped away. We found ourselves sifting through an ocean of data, looking for subtle changes in behavior rather than explicit, neon-sign indicators. This ransomware also engages in double-extortion, meaning data exfiltration often precedes or accompanies the encryption, adding another layer of complexity and potential damage.

## Why It's Getting Worse

The move by ransomware groups like Aur0ra to omit file renames is part of a broader trend towards increased stealth and evasion. Attackers are increasingly sophisticated, leveraging aut...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/no3axrjNcG

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 PRACTICAL DEFENSE

Mini Shai-Hulud's npm Onslaught: Beyond CVEs – How to Defend Against Pre-Install Supply Chain Attacks
May 22, 2026 · 7 min read
────────────────────────────────────────

## Mini Shai-Hulud's npm Onslaught: Beyond CVEs – How to Defend Against Pre-Install Supply Chain Attacks

The Slack channel explodes. It’s 3 AM, and the dev team is seeing weird behavior in their local environments. A new dependency, pulled in just hours ago, seems to be making outbound connections it shouldn’t. Then, the pings start: our internal credential management system is reporting suspicious login attempts from developer workstations. Panic sets in. We’re looking at a live supply chain compromise, and the malicious code didn’t wait for a vulnerability scan to find it—it was there from the moment the package hit the local cache.

This isn't a hypothetical. This is the reality many teams face when a well-crafted supply chain attack hits. The latest wave of the "Mini Shai-Hulud" worm, compromising over 600 npm packages, particularly within the @antv ecosystem, is a stark reminder of this brutal truth. This isn’t about a CVE in an already installed library; it’s about malicious code running before the package is even fully integrated, stealing developer credentials and exfiltrating secrets. The attacker, TeamPCP, is using compromised maintainer accounts to publish these booby-trapped versions, making them appear legitimate. We’ve seen this movie before, and frankly, it’s getting harder to watch.

## The Problem

The traditional security playbook for dependencies is broken when it comes to these types of pre-install attacks. We've spent years building robust pipelines that scan for known vulnerabilities (CVEs) in deployed code, manage licenses, and perhaps even check for some common misconfigurations. But what happens when the malicious payload executes as part of the package installation process itself, before any of those post-install checks even have a chance to run? That's the gaping hole Mini Shai-Hulud exploits.

Consider the npm install process. When a developer runs npm install, a series of scripts can execute: preinstall, install, and postinstall. A sophisticated attacker doesn't need a CVE in the core library functionality. They just need to inject malicious code into one of these lifecycle scripts. By the time your vulnerability scanner looks at the installed package, the damage—credential theft, backdoor implantation, or even data exfiltration—might already be done. The malicious code might even clean up after itself, leaving a seemingly benign package behind. This is why the Mini Shai-Hulud worm is so effective; it’s designed to hit hard and fast at the very beginning of the supply chain.

The data reinforces this. Supply chain attacks have steadily climbed, and the focus is shifting. While we’re busy patching critical zero-days in Defender like CVE-2026-41091 and CVE-2026-45498, attackers are focusing on the weakest link: the trust we place in open-source ecosystems. The sheer volume of packages—millions on npm alone—makes manual vetting impossible. And when you factor in transitive dependencies, the problem scales exponentially. A single compromised maintainer account can poison hundreds of downstream projects, as we’ve seen with the @antv ecosystem compromise.

The problem isn't that developers are negligent; it's that the system doesn't provide them with adequate guardrails. They're trying to deliver features quickly, and pulling in a dependency is often the fastest path. Expecting every developer to become a supply chain security expert, meticulously auditing every line of code in every dependency and its sub-dependencies, is simply unrealistic and unsustainable.

## Why It's Getting Worse

The landscape is only getting mo...

─────────────────────────────��──────────

📰 Full analysis on The Signal:
https://t.co/qvcGM50Os3

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 PRACTICAL DEFENSE

Fox Tempest's 1,000 Revoked Certs: Why Your EDR Needs Behavioral Analysis More Than Ever
May 21, 2026 · 7 min read
────────────────────────────────────────

## Fox Tempest's 1,000 Revoked Certs: Why Your EDR Needs Behavioral Analysis More Than Ever

Picture this: it’s 3 AM, and your pager goes off. A critical alert from your EDR – something about a new process spawning from a digitally signed executable, behaving erratically. You roll over, rub the sleep from your eyes, and think, “Signed? How bad can it be?” You log in, eyes scanning the console, and that knot in your stomach tightens. The process is making outbound connections to known C2 infrastructure, attempting to inject into explorer.exe, and enumerating sensitive directories. The signature on the binary looks legitimate, issued by a reputable certificate authority. But the behavior? That’s screaming “breach.”

This isn't a hypothetical. This is the reality we’ve been living lately, and the recent takedown of the Fox Tempest operation by Microsoft just amplified it a thousand times over. For too long, we’ve leaned on the crutch of code signing as a primary trust indicator. It’s been a cornerstone of our defense-in-depth strategies, a quick filter for "good" versus "bad." But with over 1,000 fraudulent certificates revoked from Fox Tempest, that crutch just snapped. We need to talk about what that means for your EDR and, more importantly, for your incident response.

## The Problem

Let’s be blunt: if your security strategy relies heavily on the assumption that a digitally signed executable is inherently trustworthy, you have a problem. Fox Tempest wasn't some fly-by-night operation; they were running a full-blown "malware-signing-as-a-service" (MSaaS), providing cybercriminals with the means to sign their malicious payloads with seemingly legitimate certificates. This allowed malware families like Rhysida ransomware, Lumma Stealer, and Vidar infostealer to masquerade as trusted software, bypassing initial detection layers that prioritize signature validation.

The numbers are staggering. Over 1,000 revoked certificates. Think about that for a second. That's a thousand instances where a piece of malware could have walked right into an organization, unchallenged by traditional defenses that check for valid signatures. We’ve seen this play out in countless incidents. An analyst sees a signed binary, the EDR gives it a green light because the signature checks out, and the malicious activity proceeds unimpeded until it's too late. The initial alert might be for a suspicious network connection or an anomalous process injection, long after the initial execution.

This isn't just about Fox Tempest. We've seen threat actors exploit legitimate signing certificates stolen from compromised companies, like the ones used by the Lapsus$ group. We've seen certificates issued through shady CAs or via supply chain compromises. The point is, the digital signature, once a robust indicator of trust, has been severely eroded. It’s no longer a definitive "clean" signal; it's just one data point among many, and increasingly, a misleading one.

The time lag between initial compromise and detection in these scenarios can be catastrophic. If your EDR is primarily focused on static analysis and signature validation for initial ingress, you’re missing the forest for the trees. By the time behavioral analysis kicks in – if it’s even configured to do so effectively – the adversary might have already established persistence, exfiltrated data, or deployed ransomware. The cost of incident response skyrockets with every minute of undetected dwell time.

## Why It's Getting Worse

The landscape isn't getting any easier. We're facing an increasingly automated and AI-driven adversary. The fir...

────────────────────────────��───────────

📰 Full analysis on The Signal:
https://t.co/bXaNw7d9n9

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 PRACTICAL DEFENSE

AI-Powered Zero-Day Exploitation: A New Era of Offensive AI and How to Prepare Your Defenses
May 20, 2026 · 7 min read
────────────────────────────────────────

## AI-Powered Zero-Day Exploitation: A New Era of Offensive AI and How to Prepare Your Defenses

The call came in at 2 AM. Our client, a mid-sized financial institution, was seeing anomalous outbound traffic from their Exchange servers—traffic that looked like it was trying to exfiltrate mailboxes. We’d just gotten off a bridge call about the new Microsoft Exchange zero-day, CVE-2026-42897 (https://t.co/WSFq46kvpw), a nasty spoofing and XSS issue that Microsoft warned was already being actively exploited. The team was still scrambling to apply mitigations, and now it looked like we were too late. The attackers weren't just probing; they were in. This wasn't a case of some script kiddie getting lucky. The precision, the speed, the way they leveraged a freshly disclosed vulnerability—it had the hallmarks of something far more sophisticated, something… automated.

We’ve been bracing for this, and frankly, it’s here. The news broke just yesterday: for the first time, an AI successfully discovered and exploited a zero-day vulnerability. This isn't theoretical anymore. This is a seismic shift, and it means the rules of engagement for defenders have fundamentally changed.

## The Problem

For years, the discovery and exploitation of zero-days were the domain of highly skilled, often state-sponsored, teams or well-funded exploit brokers. It was expensive, time-consuming, and required deep expertise. That barrier to entry has just been obliterated. Imagine a system that can continuously scan codebases, identify subtle logical flaws, and then, without human intervention, generate working exploits. That’s not science fiction anymore; it’s our current reality. The time from vulnerability disclosure to active exploitation—already shrinking—is about to collapse even further. When Microsoft warns us about a new Exchange zero-day like CVE-2026-42897 and says it's already being exploited, it’s a race against the clock, and now that clock is running on AI speed.

We’re seeing this play out in other areas too. Take the "Shai-Hulud" supply chain attacks, for instance. TeamPCP is compromising hundreds of npm and PyPI packages, injecting credential-stealing malware. While not explicitly AI-driven, the sheer scale and speed of these attacks highlight how quickly adversaries can weaponize new vectors. If a human-driven operation can compromise hundreds of packages, what happens when an AI can identify vulnerable components across the entire open-source ecosystem and craft bespoke attacks at machine speed?

The traditional defensive playbook—patching, vulnerability management, threat intelligence feeds—is struggling to keep up. CISA's move to retire emergency directives and rely more heavily on the KEV catalog is a step toward standardization, but it's still reactive. It tells us what's already being exploited. We need to get ahead of the curve, not just chase it.

## Why It's Getting Worse

The acceleration of offensive AI isn't just about finding more zero-days; it's about changing the entire attack lifecycle. Think about it:

• Automated Reconnaissance: AI can sift through vast amounts of public and dark web data, identifying potential targets, misconfigurations, and vulnerable assets with unprecedented efficiency.

• Exploit Generation: As we've just witnessed, AI can move from vulnerability identification to exploit development without human intervention, drastically reducing the time to weaponization.

• Adaptive Attacks: Offensive AI can learn from defensive responses, automatically modifying its attack vectors to bypass...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/Dhef3fGn7M

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 PRACTICAL DEFENSE

Mini Shai-Hulud's npm Onslaught: How to Defend Your CI/CD Pipelines from Credential-Stealing Supply Chain Attacks
May 19, 2026 · 8 min read
────────────────────────────────────────

## Mini Shai-Hulud's npm Onslaught: How to Defend Your CI/CD Pipelines from Credential-Stealing Supply Chain Attacks

Picture this: It's 2 AM, and the on-call pager just screamed. A build failed, not with a syntax error, but with something far more sinister. Logs are spewing cryptic messages about unauthorized API calls, and then the unthinkable happens—your cloud provider just notified you of a massive egress of data from a storage bucket that should only ever be accessed by a deployment pipeline. You scramble, pulling the pipeline, freezing repos, but the damage is done. Your developer credentials, your cloud API keys, your SSH keys—they’re gone. This isn't a hypothetical nightmare; it’s the cold reality of a supply chain attack like the one the Mini Shai-Hulud campaign is unleashing right now, compromising packages and turning CI/CD environments into launchpads for credential theft and backdoor implantation. We’ve seen this movie before, and it never ends well for the unprepared.

This isn't just about some random npm package getting popped. We’re talking about a sophisticated operation that has infiltrated major ecosystems, including Alibaba’s @antv suite, echarts-for-react, and timeago.js. The payload isn't just dropping malware; it's surgically extracting the crown jewels: plaintext secrets from CI/CD runner memory, local cloud provider credentials (think AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY), SSH keys, and even planting backdoors in developer tools like VS Code and Claude Code configurations. And the kicker? They’re using those stolen tokens to spin up thousands of rogue GitHub repositories. This isn’t a smash-and-grab; it’s a full-spectrum takeover designed for persistence and lateral movement.

## The Problem

The core of the problem lies in the inherent trust we place in our CI/CD pipelines and the vast, interconnected web of third-party dependencies they consume. Every npm install, every pip install, every go get is a potential ingress point. Defenders are already drowning in alerts—the recent Microsoft Exchange zero-day (CVE-2026-42897) and the NGINX vulnerability (CVE-2026-42945) are just the latest fires we’re fighting. But those are known vulnerabilities in established software. Supply chain attacks, especially those targeting open-source packages, are a different beast entirely. They exploit trust relationships, making them incredibly difficult to detect with traditional perimeter defenses.

Consider the typical developer workflow: a pull request is opened, tests run, dependencies are fetched, code is built, and artifacts are deployed. Each step is a potential point of compromise. When a malicious package like those in the Mini Shai-Hulud campaign is introduced, it executes its payload during the install phase, often before any static analysis or vulnerability scanning tools even get a chance to look at the "code." By the time the build completes, your CI/CD runner has already spilled its guts. We've seen incidents where entire cloud environments were compromised within minutes because a single compromised dependency executed in a highly privileged CI/CD context.

The data doesn't lie. Supply chain attacks are on a steep upward trajectory. Attackers are shifting their focus from directly breaching organizations to compromising the software and components those organizations rely on. The average dwell time for an attacker in a compromised environment remains stubbornly high, and incidents like the NYC Health and Hospitals data breach, with a 70-day dwell time, highlight how long these threats can persist undetected. Fo...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/xpUsaQUn6k

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

🔴 BREACH LESSONS

CISA's Credential Catastrophe: How AWS GovCloud Keys Landed on GitHub and What It Means for Your Supply Chain
May 18, 2026 · 8 min read
────────────────────────────────────────

## CISA's Credential Catastrophe: How AWS GovCloud Keys Landed on GitHub and What It Means for Your Supply Chain

Picture this: It’s 2 AM, and the SOC alert queue is quiet—too quiet. Then, a P1 blares. “Unusual activity detected in AWS GovCloud,” the alert screams. We’re still rubbing the sleep from our eyes as we jump on the bridge, but the grim reality sets in fast. Someone, somewhere, just pushed a highly privileged AWS GovCloud key to a public GitHub repo. And it’s not just any key; it’s a key belonging to a government contractor, tied directly to sensitive CISA systems. The immediate scramble isn't just about rotating credentials—it's about understanding the blast radius. How long has it been exposed? What has it touched? Who else has seen it? The clock is ticking, and every second is a potential exfiltration. This isn't theoretical; this is the CISA incident, and it’s a stark reminder that even the most critical infrastructure is vulnerable to human error and inadequate controls.

This wasn't some isolated, one-off mistake from an intern. This was a contractor for CISA—the very agency charged with securing the nation's critical infrastructure—inadvertently exposing not just AWS GovCloud credentials, but also details on how CISA builds, tests, and deploys software internally. Think about that for a second. It’s a blueprint for an adversary. It’s like leaving the keys to the kingdom under the doormat, with a note explaining the alarm system. We've seen this scenario play out countless times, in countless organizations, across every sector. The details change—sometimes it's an API key, sometimes a database password, sometimes a full configuration file—but the core problem remains: sensitive secrets ending up where they absolutely do not belong.

## The Problem: A Flood of Secrets in the Open

The CISA incident isn't an anomaly; it's a symptom of a pervasive, systemic issue. We’ve been called in to clean up incidents where entire cloud environments were compromised because a developer, under pressure to meet a deadline, hardcoded an API key directly into source code and pushed it to a public repository. We've seen database credentials for production systems sitting in public Gist snippets. This isn't about malicious intent; it's often about convenience, lack of awareness, or the sheer velocity of modern development workflows outpacing security controls.

The data doesn't lie. Every day, thousands of new secrets are accidentally exposed on public code platforms. Tools designed to scan for these secrets constantly find them, highlighting the scale of the problem. What makes the CISA breach particularly concerning is the context: AWS GovCloud. This isn't your standard commercial cloud. It's designed for highly sensitive government workloads, with stringent compliance requirements like FedRAMP High and ITAR. The expectation is a higher bar for security, yet the same fundamental developer hygiene issues persist. The leak included access to numerous internal CISA systems, providing a treasure trove of information for any sophisticated adversary looking to understand CISA's operational security posture and internal workings.

The timeline of discovery often compounds the problem. A secret might sit exposed for days, weeks, or even months before it's identified. By then, the damage could be extensive. Adversaries use automated tools to scrape public repositories for exactly these types of leaks. They don’t need to be targeted; they just need to be fast. Once a credential is out there, it’s a race against time, and usually, the attackers win that ...

────────────────────────────────────────

📰 Full analysis on The Signal:
https://t.co/qE8WspRXtJ

#cybersecurity #threatintel #infosec

[nolimit @n0limitSOC]

@The_Cyber_News insane!! AI is advancing very quickly in the cyber exploit world

[nolimit @n0limitSOC]

@perkmaybe hola