Modern intrusions increasingly do not look like that. The file on disk is a real, signed, well-known application. It launches normally. The malicious part is a library it loads on the way up, sitting quietly in the same folder, riding the trust of the program that loaded it. A growing share of that malicious code is now Python, executed inside a process that has every reason to look legitimate.

This post explains the technique at the level a defender needs, then spends most of its length on the part that matters: how a small team detects it and makes it harder, without buying anything new.

How DLL Side-Loading Works, In Plain Terms

When a Windows program starts, it needs supporting libraries (DLLs) to run. To find them, Windows follows a defined search order. For many applications, one of the first places it looks is the folder the program itself launched from.

That search order is the opening. If an attacker can place a malicious DLL with the right name next to a legitimate, signed executable, the legitimate program will load and run the attacker’s library, because it looked in its own folder first and found a match. The process is signed and trusted. The code running inside it is not. This is DLL side-loading, catalogued in the MITRE ATT&CK framework as Hijack Execution Flow: DLL Side-Loading (T1574.002), and the Windows DLL search order it abuses is documented publicly by Microsoft.

The Python angle is a refinement, not a different idea. CPython ships as an embeddable runtime. An attacker can deliver a trusted application alongside a Python runtime library and a script, and use side-loading so the script executes inside the trusted process. Offensive tooling has productized this pattern; the Black Hills Information Security tool “Pyramid” is a well-known public example that loads an embedded Python interpreter into a process and runs Python entirely in memory, which keeps the actual logic off disk where file-based scanning would see it. Loading and executing code from memory rather than a dropped file maps to Reflective Code Loading (T1620), and the Python execution itself to Command and Scripting Interpreter: Python (T1059.006).

We are deliberately not publishing a build-it walkthrough. The technique is public and well-understood by attackers already. What is underused is the defense, so that is where the rest of this goes.

Why This Slips Past Common Defenses

Three properties make this effective, and each one points at a detection idea.

• The process is trusted. Allowlists and reputation systems that key on the executable see a known-good, signed binary. They are not wrong about the file. They are looking at the wrong layer.
• The malicious code can avoid disk. When the real logic runs as in-memory Python, signature-based file scanning has little to inspect. Detection has to move to behavior and to what gets loaded, not just what gets written.
• It blends with normal Python. Plenty of legitimate software embeds Python. The signal is not “Python ran.” The signal is “Python ran somewhere it has no business running, loaded from a place it should not be.”

The defensive thesis follows directly: you cannot reliably catch this by judging the executable. You catch it by watching which libraries trusted processes load, from where, and whether that pairing makes sense.

Detection: What to Look For This Week

You do not need a new platform for most of this. You need the right telemetry turned on and a few specific questions asked of it.

Turn On Module-Load Visibility

• Deploy Sysmon with a maintained configuration. Sysmon Event ID 7 records image and DLL loads, including the loaded module’s path and signature status. A widely used, well-commented community baseline (commonly referred to as the SwiftOnSecurity Sysmon configuration) is a reasonable starting point and is free. Without module-load logging, most of the hunts below are not possible.
• Confirm your endpoint protection or EDR records library loads and surfaces unsigned or unknown-hash modules. Many products collect this but do not alert on it by default.

Ask These Specific Questions

• Is a signed, trusted binary loading an unsigned or unknown DLL from a user-writable directory? Side-loading frequently stages the malicious library in a path the user can write: a Downloads folder, a temp directory, %APPDATA%, or a “portable app” folder. A reputable application loading an unsigned DLL out of C:\Users\...\Downloads\ is a strong lead.
• Is a Python runtime library loading inside a process that is not a Python application? An embedded interpreter library (for example, a python3xx.dll) loaded by a program that has no legitimate reason to embed Python is worth a hard look, especially if no corresponding python.exe is involved.
• Is the loaded DLL name legitimate but the path or signature wrong? Compare the module name against where it should normally live and who should normally sign it. A correctly named system or vendor DLL loading from an unexpected directory is a classic side-loading footprint, sometimes described as a phantom or relocated DLL.
• Did a trusted process start making network connections or spawning command shells shortly after an unusual module load? The load is the setup. Out-of-character network egress or child processes from a normally quiet application is the payoff, and the correlation is a high-confidence signal.

Build a Small Baseline

You cannot spot “abnormal” without a sense of “normal.” Spend an afternoon listing the handful of legitimate applications in your environment that genuinely embed Python or load DLLs from non-system paths. That short allowlist turns an overwhelming stream of module-load events into a much smaller set of exceptions worth reviewing.

Hardening: Make the Technique Expensive

Detection tells you it happened. The following make it less likely to work at all, and none require new licensing for most small environments.

• Block execution from user-writable locations. Application control that prevents executables and DLLs from running out of Downloads, temp, and per-user profile paths removes the most common staging ground. Windows Defender Application Control and AppLocker can both enforce this; start in audit mode to measure impact before enforcing.
• Move toward application allowlisting. CISA has long recommended application allowlisting as a high-impact control. Even a partial rollout on high-value systems (finance workstations, administrator endpoints, servers) meaningfully constrains where untrusted code can run.
• Be deliberate about “portable” applications. Self-contained apps that run from a single folder are convenient and are also the natural delivery vehicle for a bundled malicious DLL. Treat unsanctioned portable apps as something to detect and discourage, not background noise.
• Turn on script and command logging. Enable PowerShell script-block and module logging, and command-line process auditing. Even when the malicious logic is in-memory Python, the surrounding activity (how it arrived, what it spawns) often surfaces here.
• Reduce standing local administrator rights. Many side-loading chains are far less effective without the ability to write to protected locations or install services. Least privilege on the endpoint is unglamorous and remains one of the most effective controls available.

The Honest Framing

DLL side-loading is not exotic and not new. It is well-documented, actively used by both criminal and state-aligned actors, and effective precisely because it borrows trust your tools have correctly assigned to legitimate software. The Python and in-memory variants raise the bar further by keeping the meaningful code off disk.

The takeaway for a resource-constrained team is not “buy a side-loading product.” It is a shift in where you look. Stop asking only “is this executable bad” and start asking “does it make sense that this trusted process just loaded that library, from that location.” Most of the telemetry to answer that is free. Most of the hardening uses controls you already have. What is usually missing is the decision to turn them on and the small baseline that makes the alerts mean something.

What Secure Roots Is Doing

We help clients operationalize exactly this shift: validating that module-load telemetry (Sysmon Event ID 7 or the EDR equivalent) is collected and retained, writing a starter set of hunts for trusted-process-loads-untrusted-library and embedded-Python-where-it-does-not-belong, building the short legitimate-software baseline that suppresses the noise, and staging an application-control rollout in audit mode before enforcement so it does not break the business. The work is scoped to fit a small team and to lean on tools the client already owns.

If you want to know whether you could even see this technique in your environment today, that is a question we can answer quickly.

Contact Secure Roots

References

• MITRE ATT&CK: Hijack Execution Flow: DLL Side-Loading (T1574.002), Reflective Code Loading (T1620), Command and Scripting Interpreter: Python (T1059.006). attack.mitre.org
• Microsoft, Dynamic-Link Library Search Order, learn.microsoft.com (documented Windows DLL search behavior the technique abuses).
• Black Hills Information Security, “Pyramid” project, public documentation and repository (cited as a well-known public example of in-memory embedded-Python execution; referenced for defensive context only).
• Sysmon documentation, Microsoft Sysinternals, learn.microsoft.com (Event ID 7, image/DLL load logging).
• SwiftOnSecurity Sysmon configuration, public community baseline (commonly used free starting configuration).
• CISA guidance on application allowlisting and reducing administrative privileges, cisa.gov.
• Microsoft documentation, Windows Defender Application Control and AppLocker (application control and audit-mode rollout).

So the criminal economy did what it always does. It stopped attacking the part you fixed.

The fastest-growing identity attacks in 2026 do not try to beat your MFA. They wait until you have already passed it, then steal the result. The attacker does not need your password or your one-time code. They need the small piece of data your browser holds after you log in, the session cookie that says “this person already proved who they are.” Steal that, replay it, and you are inside, with MFA showing a clean bill of health the whole time.

The Shift: From Stealing Credentials to Stealing Sessions

When you authenticate to a web application, the server does not ask for your password on every click. It issues a session token, usually stored as a browser cookie, that stands in for the full login for hours or days. That token is a bearer token: whoever holds it is treated as you, no questions asked.

This is the soft spot. Two well-documented techniques target it directly:

• Infostealer malware. A user runs a malicious installer, a cracked application, a fake browser update, or a poisoned search result. The payload, a commodity infostealer, sweeps the machine for browser cookie databases, saved passwords, crypto wallets, and authentication tokens, then exfiltrates them in seconds. Established families such as LummaC2, RedLine, and Vidar built this market. According to BleepingComputer’s reporting on the REMUS infostealer, newer entrants are being sold as a managed service with rapid feature iteration, lowering the skill required to run these campaigns.
• Adversary-in-the-middle (AiTM) phishing. The victim clicks a phishing link and lands on a reverse-proxy page that sits between them and the real login portal. The user sees the genuine site, enters credentials, and completes the MFA prompt. The proxy passes it all through to the real service and quietly captures the session cookie that comes back. Phishing-as-a-service kits have made this turnkey; Microsoft and other vendors have publicly tracked AiTM kits behind large-scale business email compromise campaigns.

Both paths end in the same place: the attacker holds a valid, already-authenticated session. No password reset alert. No failed-login spike. No second MFA prompt, because the token was minted after MFA succeeded.

This maps to known adversary behavior in the MITRE ATT&CK framework, specifically Steal Web Session Cookie (T1539), Steal Application Access Token (T1528), and Forge Web Credentials (T1606). These are not novel research ideas. They are catalogued, observed, in-the-wild techniques.

Why This Should Worry Non-Technical Leaders

It is tempting to file this under “an IT problem.” It is not. It is a business-risk problem, for three reasons.

It defeats the control you told the board you bought. Most organizations have communicated, internally and to customers or regulators, that MFA protects their accounts. Session theft does not break that statement so much as route around it. If your risk register treats “MFA is enabled” as the mitigation for account takeover, the register is now optimistic.

It targets the accounts that matter most. Infostealers do not care whose laptop they land on, but the operators triaging the stolen data do. A finance controller’s session into the payments portal, an executive’s email session, an IT administrator’s session into the identity provider: these are sold and reused first. Business email compromise built on a hijacked, already-trusted mailbox is far harder for staff and partners to spot than a spoofed lookalike domain.

It is being industrialized. The reason this is a 2026 story and not a 2021 footnote is the supply chain behind it. Stolen credentials and session data flow into automated marketplaces. Initial-access brokers buy in bulk and resell to ransomware affiliates. The gap between “an employee ran a bad installer at home” and “a ransomware crew has a valid session into your environment” is now measured in hours, not months.

What to Do This Week

None of the following requires new budget or a new product. All of it reduces exposure to the specific techniques above. The goal is not perfection; it is to stop being the account that gets reused before lunch.

Shorten the Window

• Reduce session and refresh-token lifetimes on your most sensitive applications: email, the identity provider itself, finance and payment systems, and administrative consoles. A stolen token that expires in hours is far less valuable than one good for two weeks.
• Require reauthentication for high-risk actions: changing MFA methods, adding mail-forwarding rules, modifying payment details, or creating new privileged accounts. A replayed session should not be enough to move money or rewrite the rules of the mailbox.

Bind the Session to Something the Attacker Does Not Have

• Turn on the conditional-access and continuous-evaluation features you most likely already own. In Microsoft Entra ID, Google Workspace, Okta, and comparable platforms, policies that re-check device compliance, location, and risk signals mid-session can invalidate a token that suddenly appears from an unmanaged device or an implausible location. Microsoft’s documented Continuous Access Evaluation is one example of this category of control.
• Where your identity provider supports phishing-resistant authentication (FIDO2 security keys or passkeys) and token-protection or device-binding features, prioritize them for administrators and finance staff first. These raise the cost of both AiTM proxying and raw token replay. Treat this as a phased rollout, not a same-day switch.

Find the Infections Feeding the Pipeline

• Treat infostealer detection as a named priority for whatever endpoint protection you already run. The early signal is often a single user’s machine briefly contacting an unfamiliar host and reading the browser profile directory. Make sure that telemetry is on and reviewed.
• Watch the identity provider sign-in logs for the tell of session replay: the same account active from two distant locations or device types within a short window, sign-ins with valid session state but no corresponding interactive MFA event, and new mailbox rules or OAuth app grants shortly after an unusual sign-in.
• Constrain personal and unmanaged devices. A large share of infostealer infections originate on home machines where work accounts are also signed in. Conditional access that distinguishes managed from unmanaged devices is one of the highest-leverage controls available here.

Plan the Response Before You Need It

• Write down, in advance, how you revoke sessions. For your top five applications, know exactly how to force a global sign-out and rotate tokens for one user and for everyone. Practice it once. Account takeover response that starts with “how do we kill all sessions” wastes the hour that matters most.
• Brief your finance and executive-support staff. The realistic attack is not a clumsy spoof. It is a real, internal, already-trusted mailbox asking for a routine change. Reinforce out-of-band verification, a voice call to a known number, for any payment or vendor-detail change, regardless of how legitimate the request looks.

The Honest Framing

MFA is still essential. Nothing here is an argument to turn it off, and an organization without MFA has bigger and more urgent problems than session theft. The point is narrower and important: MFA is a control against credential abuse, and attackers have moved one step downstream of it.

The organizations that handle this period well will not be the ones that bought a new acronym. They will be the ones that treated the session, not just the login, as something worth protecting: shorter lifetimes, device-aware policies they already pay for, real attention to the endpoints feeding the criminal supply chain, and a rehearsed way to pull the plug.

You proved who you were at the door. The work now is making sure that proof cannot be picked up off the floor and reused.

What Secure Roots Is Doing

We are working with clients to run a focused identity-resilience review: an inventory of session and token lifetimes on the systems that would hurt most, a gap analysis of existing conditional-access and continuous-evaluation policies (using capabilities the client already licenses), a check that infostealer-relevant endpoint telemetry is enabled and monitored, and a short tabletop on session-revocation response. It is designed to fit in days, not quarters, and to use controls you already own before recommending anything new.

If you want a clear-eyed read on how exposed your most sensitive accounts are to session theft, we can help.

Contact Secure Roots

References

• BleepingComputer, “Inside the REMUS infostealer: session theft, MaaS, and rapid evolution,” May 2026 (industry reporting on the infostealer-as-a-service market and session theft).
• MITRE ATT&CK: Steal Web Session Cookie (T1539), Steal Application Access Token (T1528), Forge Web Credentials (T1606), Modify Authentication Process (T1556). attack.mitre.org
• Microsoft, Continuous Access Evaluation and Conditional Access documentation, learn.microsoft.com (continuous session re-evaluation as a category of control).
• CISA guidance on phishing-resistant multi-factor authentication, cisa.gov (FIDO2 and passkeys for high-value accounts).
• General industry reporting on adversary-in-the-middle phishing-as-a-service kits and infostealer families (LummaC2, RedLine, Vidar) as the established market preceding newer entrants.

The default configuration, on the other hand, is a security incident waiting to happen. And the gap between “works out of the box” and “production-ready” is wider than most teams realize—because the people selling these tools are optimizing for first-run delight, not for your audit posture.

We’ve been saying this for months internally. A widely-circulated LinkedIn post made the same case last week and it’s been making the rounds with security leaders ever since. We agree with the diagnosis. This post is what we’d add to the prescription.

What Your AI Coding Assistant Can Actually Do

Take Claude Code, GitHub Copilot, Cursor, Windsurf, or any of the agentic peers. Out of the box, with the defaults vendors ship, a typical AI coding assistant can:

• Run shell commands. Not just ls and git status. Anything the user can run. rm -rf, curl | sh, psql -c "DROP TABLE …".
• Read your filesystem. Not just the project directory. With default permissions, it can read ~/.ssh/, ~/.aws/, ~/Library/Keychains/, your browser cookie database, your .env files.
• Use your credentials. Whatever the running user has access to—cloud roles, GitHub tokens, database passwords—the agent has access to.
• Modify files. Including ones it didn’t read first.
• Reach out to the internet. Defaults often allow WebFetch(domain:*)—anything, anywhere.
• Call MCP tools. Connections to Gmail, Slack, Jira, GitHub, Linear, your CI system, your databases.
• Install packages. npm install, pip install, brew install—real attack surface, real supply-chain exposure.

That is not a productivity tool. That is production infrastructure with delegated authority. A new full-stack engineer doesn’t get this much trust on day one. Your AI agent does.

The Incidents Are Already Public

This isn’t theoretical. In July 2025, an autonomous AI agent at a major dev-tools company executed a chain of operations that deleted a production database during what should have been a code-freeze window. The instruction “don’t write to production” did not prevent the deletion. The audit trail to reconstruct what happened was incomplete. The agent was operating with credentials that should never have been in its session in the first place.

In January 2025, security researchers at Wiz discovered DeepSeek’s ClickHouse database exposed to the internet with no authentication, leaking chat history and operational data. The defenders never knew it was exposed. The attackers needed nothing more than curl.

In late 2024, the LangChain Python REPL agent CVE (CVE-2023-29374, since hardened) showed how a single tool the AI was permitted to call could be coaxed into arbitrary code execution by an attacker controlling part of the input.

The pattern: the failure mode is not “the AI made one bad decision.” The failure mode is “the AI made 200 decisions in 10 minutes because there was no governor, no audit, no kill switch, and no human in the loop.”

What a Real Baseline Looks Like

We organize the controls into eight families. Each maps to NIST SP 800-53 Rev 5, NIST AI Risk Management Framework 1.0, OWASP Top 10 for LLM Applications, and the AI-specific clauses of ISO/IEC 42001. Compressed:

1. Identity & Access. The agent’s authority is explicit and minimal. No Bash(*). No WebFetch(domain:*). No $HOME-level filesystem reads. MCP tokens scoped to the smallest verb that does the job—a search-only Gmail token, a read-only Slack token. Production credentials never reach a development agent.

2. Secrets Management. No .env in repos. No keys in permission-rule text. No credentials in audit logs. Vault by default—KeePassXC for solo operators, 1Password Teams or HashiCorp Vault for organizations. Quarterly rotation, immediate rotation on exposure.

3. Input/Output Validation. PreToolUse hooks scan every file write for secret patterns (sk-ant-, sk-proj-, AKIA…, ghp_, JWTs, RSA headers). They block, log, and surface a reason. Bash commands are linted against a dangerous-pattern list before they run. Tool results are scanned for prompt-injection markers before the agent acts on them.

4. Logging & Audit. Every tool call generates one append-only JSON line: timestamp, session, tool name, args hash, args (with secrets redacted), exit code, response size. The log file is integrity-hashed weekly. For regulated workloads, the JSONL is shipped to your SIEM with detection rules tuned to the high-risk events.

5. Network Egress Control. Per-domain WebFetch allowlists. MCP traffic through an inspectable proxy. OSINT and scanning work routed through a VPN endpoint—never the operator’s home IP. DNS sinkhole for known exfil destinations.

6. Filesystem Boundary. Project-root scoped reads. Hard deny on ~/.ssh/, ~/.aws/, browser cookie databases, password-manager files. Symlinks resolved before allowlist check.

7. Supply Chain. MCP servers provenance-verified. Plugins reviewed. Claude CLI / Copilot extension / Cursor version pinned. Model selection policy documented. Hook scripts version-controlled and code-reviewed before deploy.

8. Incident Response & Kill Switch. Documented procedure to terminate the agent session, revoke credentials it touched, preserve the audit log, and snapshot filesystem state. Rehearsed quarterly. Customer-disclosure templates pre-drafted.

The Ten Controls Every CISO Should Require

If you want a shorter list to send your engineering leaders, this is the one:

1. The AI agent does not have $HOME-level filesystem access.
2. No secrets in .env files committed to any repo (git log --all -- .env returns nothing).
3. No API keys embedded in permission rule text or hook scripts.
4. PreToolUse hook blocks writes containing known secret patterns.
5. PreToolUse hook blocks curl | sh, rm -rf /, mkfs, dd of=/dev/*.
6. PostToolUse hook logs every tool call to an append-only JSONL with secret-pattern redaction.
7. WebFetch is allowlisted per-domain; no wildcard egress.
8. MCP tokens are scoped read-only or to specific verbs—no admin, no write_all.
9. Production credentials are unreachable from development agents.
10. The kill procedure is one page, rehearsed quarterly, and available in print.

If you can answer “yes, demonstrably” to all ten, you’re at Baseline Tier 2 maturity. If you can’t, you’re not.

What Secure Roots Is Doing

Before we sell this engagement, we ran it on ourselves. The day this work started, an audit of the founder’s ~/.claude/ and ~/Desktop/SecureRoots/ revealed:

• An .env with live Anthropic and OpenAI API keys (locally, never committed—but exactly the pattern attackers harvest from compromised machines).
• A 2022-era project directory with a plaintext AWS access key, AWS secret key, and a Windows administrator password.
• Three live API keys embedded in Claude Code permission-rule text from past sessions, plus a real test credential of the form email:password.
• Two-hundred-forty-six permission patterns accumulated across two years of use, including wildcard Python execution, macOS Keychain enumeration, and full Chrome control with arbitrary JavaScript execution.
• Zero hooks. Zero audit log. Zero kill switch.

We rotated, scoped, hooked, and logged. We wrote the configuration package, the operator policy, the incident runbook, and the SIEM detection rules. The internal triage record is the first appendix in the engagement evidence we provide to clients.

The point is not that this is hard. The point is that even practitioners who write about this for a living don’t have it done unless they consciously do it. The default is permissive; permissive is the same as wrong, once it stops being a toy.

Where This Lands for Your Environment

For LA-area defense subcontractors preparing for CMMC L2, this maps directly to the AC, AU, CM, IA, and IR practice families. For medical and dental practices, it maps to HIPAA Security Rule §164.308 administrative safeguards and §164.312 technical safeguards. For CA state and county agencies, it maps to the StateRAMP Moderate baseline through the underlying NIST 800-53 Rev 5 controls.

The framework is one document. The engagement to apply it comes in three shapes: a free 90-minute discovery scorecard, a 40-hour fixed-fee Mini Hardening for SMB teams, and a vCISO retainer for organizations that want continuous coverage. For state and county procurements, we structure it as a phased Assessment / Remediation / Operational SOW with option years.

The future of AI-assisted development is not just faster. It needs to be safer, governed, observable, and revocable. None of those are optional, and none of them happen by accident.

Contact Secure Roots →

References

• Anthropic — Claude Code settings and hooks documentation: docs.claude.com/en/docs/claude-code/
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST AI Risk Management Framework 1.0
• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system
• OWASP Top 10 for Large Language Model Applications 2025: genai.owasp.org/llm-top-10/
• Model Context Protocol specification: modelcontextprotocol.io
• HIPAA Security Rule, 45 CFR §164 Subpart C
• CMMC Model 2.0
• Wiz Research — DeepSeek ClickHouse exposure disclosure, January 2025
• LangChain Python REPL agent OS command execution — CVE-2023-29374
• Secure Roots — AI/LLM Governance Baseline 1.0 (internal framework, anonymized excerpts available under NDA)

The attackers, a group tracked as TeamPCP running a campaign dubbed “Mini Shai-Hulud,” embedded malicious preinstall scripts into those packages. The moment a developer ran npm install, the script executed. It harvested GitHub tokens, npm credentials, AWS keys, Azure secrets, GCP service accounts, Kubernetes tokens, and GitHub Actions secrets—then exfiltrated them through attacker-controlled repositories created under the victims’ own GitHub accounts.

The same campaign hit the PyPI Lightning package (versions 2.6.2 and 2.6.3) and the intercom-client npm package, which alone sees about 360,000 weekly downloads. TeamPCP isn’t new. They’ve previously compromised packages tied to Checkmarx, Bitwarden, Telnyx, LiteLLM, and Aqua Security’s Trivy. This is a campaign with operational discipline, repeat success, and a growing victim list.

If you’re reading this and thinking “we don’t use SAP packages, we’re fine”—that’s exactly the wrong takeaway.

This Is the Pattern, Not the Exception

Supply chain attacks have evolved from notable incidents into a continuous threat category. Look at the trajectory:

• SolarWinds (2020) showed that a trusted update mechanism could be turned into a delivery vehicle for nation-state malware reaching 18,000 organizations.
• 3CX (2023) demonstrated that a compromised software vendor could ship a backdoored desktop client to hundreds of thousands of customers without anyone noticing for weeks.
• MOVEit (2023) proved that a single vulnerability in a widely deployed file transfer product could cascade into one of the largest data breach events in history, hitting thousands of downstream organizations.
• Okta (2022, 2023) reminded everyone that identity providers and the support tools around them are themselves high-value supply chain targets.
• XZ Utils (2024) revealed how a patient adversary could spend years building maintainer trust on an open-source project before planting a backdoor that nearly reached the Linux distributions running half the internet.

Each of these was treated as a watershed moment. Each one was followed by another. The SAP npm compromise is not the end of this story—it’s the latest chapter in a book that keeps getting longer.

The pattern is clear: attackers don’t need to breach your perimeter when they can breach the people and code you already trust.

Why This Threat Is Different

Traditional security thinking treats vendors and dependencies as background infrastructure. You vet them at onboarding, get a SOC 2 report, sign a contract, and move on. The vendor is a checkbox in a procurement workflow.

Supply chain attackers exploit exactly that mental model. They know your developers will run npm install without reading the changelog. They know your IT team will apply vendor updates because that’s what good IT teams do. They know your finance team will accept a routing number change from a known supplier because the email came from the right address. The trust you’ve extended to your vendors is the same trust the attacker hijacks.

And the scope of that trust is enormous. A modern application doesn’t have a dozen dependencies—it has hundreds, often thousands once you count transitive dependencies. Every one of those packages is maintained by someone you’ve never met, hosted on infrastructure you don’t control, and pulled into your build pipeline by automation that runs faster than any human review.

The SAP attack worked because preinstall scripts execute automatically. No user interaction required. No warning. The first time a developer noticed anything was when secrets started showing up in attacker-controlled repos.

This Isn’t Hypothetical to Us

Through the SolarWinds period, I worked alongside a major municipal client. Like every organization with a vendor footprint that touched the affected products, they had to verify, contain, and respond—at scale, under pressure, with the news cycle moving faster than the technical investigation. The lesson from that period is the lesson from every supply chain event since: by the time you’re reading the headline, the question isn’t whether you have exposure. It’s whether you’re already looking for it.

That’s the posture we bring to the environments we support today. We assume the next compromise is in transit. We watch for the indicators that matter—unexpected outbound connections to code-hosting platforms, anomalous package installation activity, secrets appearing in places they shouldn’t, credential usage patterns that don’t match the developer’s normal behavior. We pay close attention to the build pipelines, the developer endpoints, and the third-party access paths that are most often abused in these campaigns.

A campaign like the SAP compromise is a reminder of something more fundamental than any specific IOC list: you cannot detect what you cannot recognize as abnormal. Almost no defender had TeamPCP-specific indicators in advance—the malicious packages were published live, and the public IOCs followed disclosure, not the other way around. What separates the organizations that catch this kind of attack quickly from the ones that catch it weeks later is rarely a more exotic threat feed. It is whether they have already done the work to understand what normal looks like in their own environment.

That is why we put so much weight on baselining network and endpoint activity as a foundational control. When you know which build servers normally talk to which package registries, which developer machines normally push to which GitHub orgs, which cloud accounts normally call which APIs, and what the day-to-day rhythm of those flows actually looks like, you have something no IOC feed will ever give you: the ability to notice when something deviates. A new outbound connection from a build host to a freshly created GitHub repository under a developer’s own account isn’t suspicious in the abstract—it becomes suspicious because it doesn’t match the baseline.

The threat is real, it’s current, and it’s growing. The work isn’t to promise it will never reach you. The work is to know your environment well enough to see it the moment it does.

Questions to Ask This Week

If you’re running a small or mid-market business, you don’t need a Fortune 500 security budget to make meaningful progress on supply chain risk. You need to ask the right questions of the right people, and you need to start now.

Ask your MSP or IT provider:

• What is your patch and update verification process when a vendor pushes a new release? Do you wait, test, or auto-deploy?
• Do you maintain a Software Bill of Materials (SBOM) for the systems you manage on our behalf?
• If a tool you deploy to our environment was found to be compromised tomorrow, how quickly could you identify which of our systems are affected?
• What egress monitoring do you have in place for the systems you manage?

Ask your software vendors:

• Do you publish an SBOM for your product? Will you share it with us?
• What is your process for verifying the integrity of third-party libraries you ship in your software?
• How are you authenticating updates pushed to our environment? Code signing? Certificate pinning?
• What is your incident notification commitment if you discover a compromise in your supply chain?

Ask your development team (or the team that builds your custom software):

• Are we pinning dependency versions, or are we pulling “latest”?
• Do we have lockfiles committed and enforced in CI?
• Are we running preinstall and postinstall scripts in our build pipelines, and do we have any controls on what those scripts can do?
• Where are our developer credentials stored—on developer laptops, in environment variables, in a secrets manager?
• If a developer’s machine pulled a poisoned package last week, what credentials would have been exposed, and have we rotated them?

Ask your finance and operations teams:

• When a vendor requests a change to payment information, banking details, or contact information, what is our verification process?
• Do we require out-of-band confirmation—a phone call to a known number—before any vendor change is processed?
• If a vendor’s email account was compromised tomorrow, would our process catch a fraudulent invoice or routing change?

If any of these questions produce blank stares, you’ve found your starting point.

Concrete Controls That Reduce Real Risk

Beyond the questions, here are the controls we recommend organizations implement or verify within the next 30 days:

• Baseline normal network and endpoint activity—then alert on the deviations. Before you spend another dollar on threat intelligence, make sure you have a reliable picture of what normal looks like. Which servers talk to which destinations on which ports. Which developer machines push to which Git providers. Which cloud accounts call which APIs and on what cadence. Which processes are normally spawned by your build runners. Once that baseline exists, the anomalous outbound connection, the unexpected GitHub repo creation, the rogue process at 3 AM all become visible. Without it, you are looking for a needle in a haystack you have never measured.
• Pin and lock your dependencies. Use lockfiles. Don’t pull latest. Know exactly what versions of what packages are running in your production environment.
• Maintain an SBOM. For every application you build or operate, you should know what’s in it. When the next compromise is announced, you should be able to answer “are we affected?” in minutes, not days.
• Disable or sandbox install scripts where you can. npm and other ecosystems support flags to skip preinstall and postinstall scripts. Where the workflow allows, use them.
• Monitor egress for unexpected destinations. The SAP attackers exfiltrated to GitHub repos under the victims’ own accounts. That’s hard to spot if you’re not watching for it. Build detections for unusual outbound connections from developer machines and build infrastructure—especially to code-hosting platforms.
• Rotate developer credentials proactively. If any developer in your organization has installed a package from a compromised maintainer in the past 90 days, assume their machine-resident credentials may be exposed. Rotate GitHub tokens, npm tokens, cloud keys, and any long-lived secrets accessible from developer endpoints.
• Move secrets out of developer machines. Secrets managers, hardware-backed keys, and short-lived credentials dramatically reduce the blast radius when a developer machine is compromised through a poisoned package.
• Require out-of-band verification for vendor changes. Banking changes, contact changes, configuration changes pushed by a vendor—none of these should be processed solely on the basis of an inbound email or message.
• Inventory third-party access to your environment. Every MSP, every consultant, every SaaS integration with API access. Know what they can reach. Reduce standing access. Move to just-in-time access where possible.

What Secure Roots Is Doing

We’re actively monitoring our clients’ environments for the indicators of compromise associated with the SAP npm campaign and the broader TeamPCP activity. That includes watching for anomalous GitHub egress, monitoring for the specific package versions involved, scanning for credentials that may have been exposed through developer endpoints, and validating that our clients’ build pipelines aren’t running compromised dependencies.

For organizations that aren’t our clients yet—if you don’t know whether your developers pulled any of the affected packages in the past two weeks, that’s the first call to make this week. If you don’t have egress monitoring on your build infrastructure, that’s the second. If your vendor change process can be defeated by a convincing email, that’s the third.

The supply chain isn’t somewhere out there. It’s already inside your environment. The only question is whether you’re watching it as carefully as the attackers are.

Contact Secure Roots →

But here’s the part most articles won’t tell you: the agency built to help you through exactly this kind of moment is operating with one arm tied behind its back.

The Safety Net Has a Hole in It

CISA—the Cybersecurity and Infrastructure Security Agency—is the federal government’s front door for cybersecurity guidance, threat intelligence sharing, and incident response coordination. When a nation-state adversary turns its attention to American businesses, CISA is supposed to be the agency that sounds the alarm, shares indicators of compromise, and helps organizations harden their defenses.

Right now, CISA has lost roughly a third of its workforce. Budget proposals have targeted nearly $500 million in cuts. The counter-ransomware initiative has been impacted. Stakeholder engagement and industry partnership programs have been slashed. The agency’s temporary director was reassigned to another division of DHS. Cybersecurity assessments and trainings have been paused.

This isn’t a political statement. It’s a situational reality that changes your risk calculus.

When the federal cybersecurity agency is stretched thin during an active conflict with a capable cyber adversary, the practical implication for your organization is simple: you need to act as if no one is coming to help. Because right now, at the speed these threats move, they probably aren’t.

What You’re Actually Up Against

Iranian cyber operations aren’t what most people picture. These aren’t lone hackers in basements. These are structured programs run by intelligence services, military units, and organized proxy groups—and they’ve been building capability for over a decade.

Since Operation Epic Fury launched on February 28, an “Electronic Operations Room” has coordinated activity across dozens of pro-Iran hacktivist groups. The tactics range from website defacements and DDoS attacks to credential harvesting, data theft, and hack-and-leak campaigns designed to create fear and operational disruption.

But here’s what matters for your planning: the most dangerous Iranian cyber actors don’t announce themselves. While hacktivist groups are claiming DDoS attacks on social media, state-sponsored groups like APT34 (OilRig) and APT42 are quietly probing networks, exploiting known VPN vulnerabilities, and using stolen credentials to move laterally through systems. Their objectives aren’t vandalism—they’re access, persistence, and the ability to cause damage on command.

The sectors facing the highest direct targeting risk include defense, government contractors, financial services, energy, healthcare, and any organization with ties to Israel. But if you think your company is too small or too unrelated to be a target, consider this: Iranian actors have historically targeted supply chains to reach their actual objectives. Your company might not be the target—but your access to a target’s network might be.

Your Wartime Checklist: What to Do This Week

This isn’t a strategic roadmap. This is a list of things your team should verify or implement within the next seven days. None of these require new budget. All of them reduce your exposure to the specific tactics Iranian-aligned actors are known to use.

Patch These First

Iranian cyber actors have repeatedly exploited a specific set of vulnerabilities. If you have any of the following in your environment, patch them now—not next maintenance window, now:

• VPN appliances: Pulse Secure/Ivanti, Fortinet FortiOS, Citrix NetScaler, and F5 BIG-IP have all been exploited in documented Iranian campaigns. If you’re running any of these and haven’t applied the latest security updates, you have an open door.
• Microsoft Exchange: ProxyShell and ProxyLogon vulnerabilities remain some of the most exploited entry points for Iranian actors.
• Log4j: Still being exploited. Still unpatched in many environments.

If you don’t know whether these exist in your environment, that’s the first problem to solve.

Lock Down Remote Access

• Enforce multi-factor authentication on every remote access point. Not just VPN—RDP, cloud admin portals, email, everything. Iranian actors exploit default and stolen credentials as a primary tactic (MITRE T1078, T1110). MFA is the single most effective control against this.
• Audit all active VPN accounts. Disable any that aren’t currently needed. Reduce the attack surface.
• If you’re still using single-factor authentication on anything externally facing, fix it today.

Review Your Vendor and Supply Chain Access

• Identify every third party with remote access to your network. MSPs, software vendors, IT consultants—anyone with credentials or a tunnel into your environment.
• Verify that their access is scoped to the minimum necessary. Remove standing access where possible and move to just-in-time access models.
• Ask your critical vendors directly: have they reviewed their own exposure to these threats? If they can’t answer that question, you have a supply chain risk.

Monitor for the Right Things

• Alert on the use of unauthorized remote access tools: AnyDesk, TeamViewer, ngrok, and similar. Iranian actors and their proxies use legitimate tools to maintain access and avoid detection.
• Watch for brute force activity against externally facing services, especially outside business hours.
• Monitor for new or unexpected administrative accounts. If a new Domain Admin appears that nobody created, you may already be compromised.
• Review DNS logs for connections to known Iranian infrastructure. Threat intelligence feeds from vendors like Palo Alto Unit 42, Mandiant, and CrowdStrike are publishing updated indicators of compromise specific to this conflict.

Prepare for the Worst

• Test your backups. Not “verify they exist”—actually restore something. Iranian-aligned actors have deployed wiper malware in past conflicts. If your backups aren’t offline, immutable, and tested, they may not survive an attack.
• Dust off your incident response plan. Does your team know who to call at 2 AM on a Saturday? Do you have retainers in place with an IR firm? Do you have a communication plan for customers and partners if you get hit?
• Run a 30-minute tabletop exercise with your leadership team. Scenario: it’s Monday morning, your systems are down, your data is being leaked on Telegram, and a hacktivist group is claiming credit. What do you do first? If no one has an answer, you have work to do.

Brief Your People

• Send a company-wide advisory reminding employees to be vigilant about phishing, especially emails referencing the conflict, military news, or government communications. Iranian actors have used current events as lures in spearphishing campaigns for years.
• Remind your finance team to verify any unusual wire transfer or vendor change requests through a secondary channel. Voice calls to known numbers—not replies to the email that made the request.
• If you have employees with ties to the defense sector, government contracting, or Israeli business partnerships, they should be considered higher-risk targets for social engineering.

A Note on Threat Intelligence

If your organization subscribes to a threat intelligence platform, now is the time to use it. Palo Alto’s Unit 42, SentinelOne, SOCRadar, Check Point, and Mandiant have all published detailed threat briefs specific to the current Iranian cyber escalation, including indicators of compromise, targeted sectors, and observed TTPs.

If you don’t have a threat intelligence subscription, CISA’s Iran threat overview page still provides foundational guidance and published advisories. Even with reduced capacity, the advisories that are published remain valuable.

The Real Risk Isn’t the Attack—It’s the Assumption

The most dangerous assumption any organization can make right now is that this doesn’t apply to them. That they’re too small. Too unrelated. Too far from the conflict.

Iranian cyber strategy doesn’t require every target to be strategic. Disruption at scale—hitting hospitals, banks, manufacturers, service providers—creates fear, erodes confidence, and amplifies the political message. You don’t have to be a defense contractor to be useful to that objective.

The organizations that come through this period intact won’t be the ones with the biggest security budgets. They’ll be the ones that took a hard look at their fundamentals this week—patching, MFA, backups, access controls—and made sure the basics were solid.

You don’t need a nation-state defense budget. You need to not be the easy target.

What Secure Roots Is Doing Right Now

We’re actively working with our clients to conduct rapid risk assessments focused on Iranian threat actor TTPs. This includes vulnerability scanning against known exploited CVEs, MFA gap analysis, backup validation, and abbreviated tabletop exercises designed to test incident response readiness in under an hour.

If your organization needs help getting through this checklist—or if you want a professional assessment of your current exposure—we’re here.

Contact Secure Roots →

Except none of those people were on the call. Every face was synthetic. Every voice was cloned. And the money is gone.

This isn’t science fiction. It already happened—and the price tag was $25.6 million.

This Is Now the #1 Threat Keeping CEOs Awake

According to the World Economic Forum’s Global Cybersecurity Outlook 2026, cyber-enabled fraud has overtaken ransomware as the top concern for chief executive officers worldwide. That’s a seismic shift. For years, ransomware dominated every boardroom conversation. Now, the thing executives fear most is being impersonated by their own digital likeness.

The numbers back it up. Seventy-three percent of global leaders surveyed reported that they or someone in their professional network was directly affected by cyber-enabled fraud in 2025. In North America, that figure hit 79 percent. And AI is the accelerant—87 percent of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk of the past year.

We’ve crossed a threshold. The threat isn’t just that someone might send a phishing email pretending to be your CEO. The threat is that someone can become your CEO—on camera, on the phone, in real time—and no one in the room can tell the difference.

Real Attacks. Real Losses. Real Executives.

This isn’t theoretical. Here’s what’s already happened:

The $25.6 Million Video Call (Arup, 2024) A finance employee at UK engineering giant Arup joined a video conference with what appeared to be the company’s CFO and other senior leaders. Every participant was a deepfake. Over the course of the call, the employee was directed to execute 15 separate wire transfers totaling $25.6 million across five bank accounts. By the time the fraud was discovered, the money was gone.

The $499,000 Zoom Call (Singapore, 2025) A finance director at a multinational firm in Singapore authorized a transfer after a Zoom call with company leadership. The attackers had proactively suggested the video call—a move that created false confidence. Every executive on the screen was AI-generated. The company lost nearly half a million dollars in a single session.

The Italian Defense Minister Scheme (2025) Criminals used AI-generated audio to impersonate Italy’s Defence Minister in calls to corporate executives, claiming they needed emergency funds to help free journalists held abroad. At least one executive wired €1 million to a Hong Kong account before the scheme was uncovered.

These aren’t outliers. CEO fraud now targets an estimated 400 companies per day. AI scam activity surged over 1,200 percent in 2025, far outpacing the growth of traditional fraud.

Why This Is Different from Every Other Threat

Business Email Compromise (BEC) has cost organizations billions for years. But until recently, it had a natural ceiling: a well-trained employee could spot a suspicious email. The grammar was off. The domain was wrong. The request didn’t feel right.

AI has removed that ceiling.

Deepfake voice cloning requires as little as three seconds of audio to generate a convincing replica of someone’s voice. Executives who speak on earnings calls, podcasts, webinars, and YouTube interviews are handing attackers exactly what they need. Combine that voice with a deepfake video generated from publicly available photos and footage, and you have an impersonation that can fool even close colleagues.

This is no longer BEC. This is multimodal impersonation—email, voice, and video combined into a single attack that exploits the one thing your security stack can’t easily filter: human trust.

And the attackers know where the money moves. They study your org chart. They know who reports to whom. They know when your CEO travels, when your CFO is in meetings, and when your finance team processes large transactions. The call comes at exactly the right time, from exactly the right person, asking for exactly the kind of action that wouldn’t normally raise a flag.

What the C-Suite Needs to Do—Now

This threat requires executive-level action, not just IT-level tooling. Here’s what we recommend to every leadership team we work with:

1. Establish Out-of-Band Verification for All High-Value Transactions

No wire transfer, vendor change, or financial authorization should be completed based solely on a video call, phone call, or email—no matter who appears to be making the request. Implement a mandatory callback protocol using a pre-established, trusted phone number. If the CEO calls and asks for a transfer, your finance team hangs up and calls the CEO back on a known number. Every time. No exceptions.

2. Reduce Your Executive Digital Footprint

Audit how much high-quality audio and video of your leadership team exists publicly. Earnings calls, keynote presentations, podcast appearances, and social media videos are all raw material for voice cloning and deepfake generation. You don’t have to go silent, but you should understand the tradeoff and make deliberate decisions about what stays public.

3. Run Deepfake Tabletop Exercises

Most organizations run phishing simulations. Almost none run deepfake simulations. Conduct tabletop exercises where a synthetic voice or video of your CEO requests an urgent wire transfer. Measure how your team responds. Do they follow the callback protocol? Do they escalate? Or do they comply because it looked and sounded like the boss?

4. Implement Multi-Party Authorization

No single individual should be able to authorize a high-value transaction. Require dual or multi-party approval for any wire transfer, vendor payment, or account change above a defined threshold. This single control would have prevented every case described in this article.

5. Update Your Incident Response Plan

Your IR plan likely covers ransomware, data breaches, and phishing. Does it cover executive impersonation? Define what happens when an employee suspects they’re on a call with a deepfake. Who do they contact? How do payments get frozen? How do you preserve evidence? If you don’t have answers to these questions, you have a gap.

6. Brief Your Board

Boards are increasingly being held personally accountable for cybersecurity failures. Gartner’s 2026 cybersecurity trends report highlights regulatory volatility and executive liability as top-tier concerns. Your board needs to understand that deepfake fraud is not a technology problem—it’s a governance problem. If your organization doesn’t have controls in place and a loss occurs, the question won’t be “how did the attacker get in?” It will be “why didn’t leadership act?”

The Uncomfortable Truth

The technology to impersonate any executive, in real time, with high fidelity, is now widely accessible. It doesn’t require a nation-state budget. It doesn’t require deep technical expertise. Off-the-shelf AI tools can clone a voice in seconds and generate a convincing face in minutes.

The organizations that survive this era won’t be the ones with the most advanced detection tools. They’ll be the ones that built verification into their culture—where no one, regardless of title, can bypass the process. Where “trust but verify” isn’t a poster on the wall but a protocol that runs every time money moves.

At Secure Roots, we help leadership teams build exactly that kind of resilience. From executive threat briefings to tabletop exercises to incident response planning, we work with organizations to close the gaps that AI-powered fraud is designed to exploit.

The Bottom Line

If your organization hasn’t stress-tested its ability to detect a deepfake impersonation of your own CEO, you’re already behind. The attackers have the tools. The question is whether your people have the training and your processes have the controls to stop them.

Don’t wait for a $25 million wake-up call.

Talk to Secure Roots →

This isn’t a movie plot. It’s happening right now, at companies of every size, across every industry.

The Threat Is Real—and It’s Growing

North Korean operatives, directed by the DPRK regime, are fraudulently obtaining remote IT positions at companies worldwide. They use stolen identities, AI-generated resumes, deepfake video, and U.S.-based accomplices who host “laptop farms”—residences where dozens of company-issued devices sit, remotely controlled by workers operating from China, Russia, and elsewhere.

The numbers are staggering. According to the U.S. Department of Justice, coordinated enforcement actions in 2025 revealed schemes impacting more than 136 U.S. companies and generating millions in illicit revenue funneled directly to North Korea’s weapons programs. The FBI has established dedicated victim notification and information portals for affected companies. An Arizona woman was sentenced to over eight years in prison for running a laptop farm that serviced more than 300 companies and generated over $17 million for the regime. In a separate case, five individuals pleaded guilty to enabling North Korean IT worker fraud, with one defendant alone placing workers at 64 U.S. companies through a single front company.

And these are just the cases we know about.

In a January 2026 episode of the SANS Institute podcast Blueprint: Build the Best in Cyber Defense, cybersecurity investigator Zak Stufflebeam shared a detailed case study of uncovering multiple counterfeit IT employees within a single organization. His investigation revealed a pattern of suspicious indicators—from AI-generated resumes and rehearsed interview responses to unusual VPN activity and unauthorized access requests. The full talk, “Infiltration Alert! How to Catch Fake IT Employees in Your Network”, is essential viewing for anyone responsible for hiring or network security.

What We’ve Seen in the Field

At Secure Roots, this isn’t a theoretical concern—we’ve encountered these patterns firsthand at organizations we support.

One of the most effective detection strategies we’ve implemented involves monitoring for unauthorized remote access tools. We set up detections that alert on the use of tools like AnyDesk, TeamViewer, Google Meet screen sharing, and similar remote desktop software. When those alerts fire, we investigate. What we’ve found, more than once, is employees sharing their screens—or full remote access to their machines—with individuals who have no authorization to access company systems.

Sometimes it’s a well-meaning employee getting help from a friend. But sometimes it’s something else entirely: a hired “employee” who can’t actually do the work, relying on an outside party to perform their job duties while they collect the paycheck. That outside party could be anyone, anywhere in the world.

This is one of the core tactics in the DPRK IT worker playbook, and it’s why monitoring for remote access tool usage isn’t optional—it’s a frontline defense.

Red Flags Every Organization Should Watch For

Whether you’re a small business with ten employees or an enterprise with ten thousand, these warning signs apply. Based on FBI advisories, Stufflebeam’s investigation, and our own field experience, here’s what to look for.

During Hiring:

Inconsistencies between a candidate’s resume, LinkedIn profile, and interview performance are a major indicator. AI-generated resumes are increasingly polished, but the person behind them may struggle with basic technical questions when asked to go off-script. Watch for candidates who refuse to turn on their camera, request that company laptops be shipped to addresses that don’t match their stated location, or insist on communicating through non-company platforms.

After Onboarding:

Monitor for remote desktop and screen-sharing tools being installed or used outside of approved channels. Track VPN connections from unusual geolocations—especially connections that seem inconsistent with the employee’s stated residence. Watch for access patterns that don’t match normal working hours, or multiple audio/video sessions running concurrently on a single endpoint. Pay attention to employees who request access to code repositories, cloud storage, or sensitive systems beyond what their role requires.

Financial Indicators:

Requests for payment through non-standard channels, digital payment services linked to foreign accounts, or reluctance to provide standard tax documentation are all warning signs the FBI has highlighted in its advisories.

What You Can Do Right Now

You don’t need a massive security budget to start defending against this threat. Here are practical steps you can implement today.

1. Verify identity at every stage. Don’t just check a box during onboarding. Require live video verification during interviews—ask candidates to hold up their ID on camera. Use E-Verify for employment eligibility. Re-verify identity periodically, not just at hire.

2. Monitor remote access tools. Build detections for AnyDesk, TeamViewer, Chrome Remote Desktop, and similar tools. Alert on their installation or usage, and investigate every alert. If an employee is sharing screen access with someone outside the organization, you need to know about it.

3. Cross-reference applicant data. Check your HR systems for duplicate resume content, reused phone numbers, or overlapping email addresses across different applicants. North Korean operatives often recycle identity components across multiple applications.

4. Restrict laptop shipping. Require that company devices are shipped only to verified addresses that match the employee’s confirmed identity. Better yet, require in-person pickup or use an identity verification service at the delivery point.

5. Enforce least privilege. Limit access to what each role actually requires. Monitor for access requests that go beyond scope, especially to source code repositories, cloud accounts, and sensitive internal systems. As the FBI noted, North Korean workers have been caught copying company code repos to personal accounts and cloud storage for exfiltration—and later using that stolen data to extort their employers.

6. Train your hiring teams. HR staff, hiring managers, and technical interviewers need to know this threat exists. Share the FBI’s advisories. Watch Stufflebeam’s SANS talk as a team. Make it part of your security culture, not just your SOC’s problem.

This Isn’t Just a Big-Company Problem

Small and midsize businesses are targets too—often easier ones. Smaller organizations typically have fewer identity verification controls, less network monitoring, and leaner HR teams that may not catch the inconsistencies. If you have remote workers and you’re not actively verifying who’s behind the keyboard, you have a gap.

The FBI’s IC3 has published multiple public service announcements specifically addressing this threat and encouraging all organizations to report suspicious activity. If you suspect a fraudulent worker, report it at ic3.gov.

Conclusion

The fake IT worker threat is one of the most underestimated risks in cybersecurity today. It exploits the trust we place in our own hiring processes—and it funds some of the most dangerous programs on the planet.

But it’s also a threat you can detect and defend against with the right awareness, the right monitoring, and the right culture. Start with identity verification. Build your remote access detections. Train your people. And don’t assume it can’t happen to you—because the adversary is already counting on that assumption.

References & Resources:

• Zak Stufflebeam, “Infiltration Alert! How to Catch Fake IT Employees in Your Network”, SANS Institute Blueprint Podcast, January 5, 2026. Watch on YouTube
• FBI Internet Crime Complaint Center, “North Korean IT Workers Conducting Data Extortion”, January 2025. Read the PSA
• U.S. Department of Justice, “Justice Department Announces Coordinated, Nationwide Actions to Combat North Korean Remote IT Workers”, July 2025. Read the announcement
• FBI Cyber Division, “DPRK IT Workers” advisory page. View on FBI.gov

If your organization needs help building detections for unauthorized remote access tools or strengthening your hiring verification process, contact Secure Roots. We’ve been in the trenches on this one.

Introduction

In the cyber-underground, alliances are often loose, opportunistic, and temporary. But recent reporting suggests something more structured: three of the biggest ransomware actorsQilin, LockBit, and DragonForce—are forming what amounts to a cyber cartel. They are no longer competing; they are coordinating.

This shift matters because it changes how defenders must think about ransomware: from isolated attacks to coordinated business ecosystems.

Who’s Who: The Players

Qilin Known earlier as Agenda, Qilin has run a full ransomware-as-a-service (RaaS) program since 2022. It offers affiliates polished extortion kits, leak sites, and negotiation portals. Qilin’s playbook includes double extortion and use of legitimate tools (RMM, scheduled tasks) to blend in before detonation.

LockBit LockBit is the veteran—responsible for thousands of global incidents and now reinvented as LockBit 5.0. It continues to operate as a structured criminal enterprise, complete with branding, affiliate recruitment, and “press releases” for its breaches.

DragonForce DragonForce is newer but rising fast. Analysts note it has adopted a cartel-style model, offering white-label ransomware, absorbing rivals, and sharing infrastructure with partners. In short, it’s not a single crew—it’s an ecosystem builder.

The Cartel Concept

Reports from multiple sources now suggest these groups are collaborating—coordinating attacks, sharing affiliates, and aligning pricing. In traditional crime terms, this is a cartel: a syndicate designed to regulate competition and stabilize profit.

If this proves true, it signals a maturity in the ransomware economy: organized markets, not chaos.

Why It Matters

The implication for defenders is serious. A cartel means shared tooling, faster attack chains, and greater resilience to takedowns. It also means your detection coverage against one actor may suddenly apply—or fail—across several.

But here’s the twist: this cartelization also gives defenders a chance to train smarter. If the adversaries are coordinating, defenders can coordinate their emulation.

Emulate Before They Arrive: Testing Your Defenses Against a Cartel’s Style of Attack

Imagine Qilin, LockBit, and DragonForce as the cyber-equivalent of a multinational conglomerate—testing their business model on your network before product launch. The only rational response is to test yourself first. That’s where adversary emulation comes in.

Emulation means rehearsing their tactics before they do, safely and within scope. It’s not “red teaming for show”—it’s Purple Teaming with purpose.

Step 1: Build the Adversary Profile Start by translating each group’s known behaviors into a MITRE ATT&CK map:

• Qilin favors credential theft (T1078), scheduled tasks (T1053), and Safe Mode evasion (T1562.009).
• LockBit affiliates rely on phishing, RDP exploitation (T1133), and automated encryption scripts (T1486).
• DragonForce affiliates experiment with white-label malware, data-theft APIs, and public shaming leak sites (T1654).

From this, you can identify what telemetry your defenses should detect.

Step 2: Design a Safe, Controlled Exercise Use controlled emulation tools or internal scripts to simulate those behaviors—never real ransomware. Run them in your test or segmented environment under a strict Rules of Engagement document. Involve legal, compliance, and your SOC leads.

Step 3: Run It as a Purple Team Sprint Your Red Team executes realistic behaviors; your Blue Team monitors and tunes detections in real time. Run it as a one-week cycle:

• Day 1: Credential abuse & lateral movement simulation.
• Day 2: Persistence and privilege escalation checks.
• Day 3: Mock data staging and exfiltration test.
• Day 4: Simulated encryption and recovery validation.
• Day 5: After-action review and detection tuning.

This schedule fits perfectly with your existing 8 AM–4 PM Purple Team exercise framework.

Step 4: Measure What Matters Don’t just grade by “we saw the alert.” Track:

• MTTD – Mean Time to Detect.
• MTTC/MTTR – Mean Time to Contain/Recover.
• Coverage Gaps – Which techniques lacked detection or logging.
• Remediation Velocity – How quickly you closed those gaps.

These metrics tell you how your defenses perform under cartel-grade pressure.

Step 5: Deliverables Every emulation run should end with:

• Executive summary: current resilience posture, business impact, and top 3 investment priorities.
• Technical appendix: detection rule IDs, log sources, gaps, and proposed Exabeam/EDR improvements.
• Runbook updates: communication flows, backup restore validation, legal response templates.

Beyond Reaction: Building Institutional Muscle

Running these cartel-based emulations does more than sharpen the SOC. It forges cross-team trust: IT learns what Security needs; Security learns what Ops can actually deliver; Leadership sees resilience quantified.

The exercise converts fear into data. And data is how you win.

Conclusion

The rumored Qilin–LockBit–DragonForce cartel isn’t just a headline—it’s a mirror. It reflects how professionalized the underground economy has become. But it also gives defenders a new playbook: study, emulate, rehearse, and improve faster than the adversary can adapt.

Cyber defense is no longer just detection—it’s pre-experience. Emulatie before they arrive. Because once they do, the test has already begun.

Every day, somewhere in the world, someone’s credentials are sold before their morning coffee brews.
Not because they were famous. Not because they were rich.
Because their data was available.

Cybercrime has matured into an industry with HR departments, customer service, performance metrics, and profit goals. These aren’t lone wolves in dark rooms anymore — they’re professionals with quotas, bonuses, and a business plan. They’ve made cybercrime a career.
And your identity is the product line.

The Profession of Crime

Think of today’s threat actors as a workforce. There are developers writing malware, brokers auctioning stolen credentials, negotiators handling ransom payments, and marketing teams designing phishing campaigns that look exactly like your company’s real emails.

Cybercrime isn’t chaos — it’s commerce.
And just like legitimate businesses, criminals want maximum return on minimal effort. That means targeting whoever’s easiest to breach — not whoever’s biggest.

By 2025, the global cost of cybercrime will surpass $10.5 trillion annually.
It’s not an underground problem anymore; it’s a parallel economy.

Why You’re Already a Target

There’s a dangerous myth that smaller companies and everyday individuals “don’t have anything worth stealing.”
But the data says otherwise:

• Nearly half of all data breaches hit small and midsize organizations.
• Over 60% of those businesses close within six months of the attack.
• 53% of breaches involve personal information — the digital DNA of identity.

Cybercriminals don’t chase prestige. They chase opportunity. They run scans for misconfigurations, open ports, and weak passwords. If you appear on their screen, you’re already on the list.

The Currency of Identity

Identity has replaced gold, oil, and cash as the most liquid commodity on earth.
A username and password might sell for a few dollars; a full identity — with bank logins and tax records — for hundreds.

Every time a password is reused or an employee clicks a fake login page, that identity joins the supply chain of the cyber underground.
One actor steals it, another buys it, a third monetizes it.
It’s specialization, division of labor — the same principles that make your business efficient — weaponized against you.

The Human Factory

Groups like Lapsus$ didn’t need elite zero-day exploits to breach tech giants; they used MFA fatigue, insider recruitment, and phishing.
They didn’t break in through code — they walked in through people.

Attackers run social engineering the way marketers run ad campaigns: A/B testing subject lines, refining scripts, automating outreach.
It’s not personal. It’s pipeline.

That’s why Secure Roots focuses on the human layer — the point where technology meets trust. Because defending systems means defending people first.

Professional Defense for Professional Crime

If the attackers have professionalized, your defenses must too.
Security can’t be an afterthought or a once-a-year audit. It has to be a living practice — measured, refined, and embedded in your culture.

Start with identity:

• Strong, unique passwords and password managers.
• Multi-factor authentication that isn’t a reflex click.
• Continuous credential leak monitoring.
• Zero-trust access controls.
• Regular tabletop exercises and recovery drills.

These are the habits of resilient organizations — the ones that survive the storm while others wonder how it happened.

The Optics of Strength

When customers, investors, or partners look at your company, security is part of what they see.
A breach isn’t just a technical failure; it’s an optics crisis.
It says, “We weren’t prepared.”

At Secure Roots, we help organizations project — and prove — resilience. Because reputation is built in peace and tested in chaos. The strongest roots aren’t visible, but they hold everything in place when the storm hits.

Closing

Cybercriminals are professionals.
They plan. They measure. They execute.

So must we.
They’ve made cybercrime a career.
Make security your culture.

This post is for anyone who wants to understand sextortion: what it looks like, how to prevent it, and how to respond if it ever happens to you or someone you care about.

Sextortion: How to Stay Safe and What to Do If It Happens

Sextortion is one of the most damaging online crimes because it attacks both your privacy and your sense of dignity. Over the past year, I’ve personally assisted individuals who were targeted in sextortion schemes. Sitting with them through the panic, shame, and uncertainty showed me how devastating this can be — but also how resilient people are when given the right tools and support.

This post is for anyone who wants to understand sextortion: what it looks like, how to prevent it, and how to respond if it ever happens to you or someone you care about.

What Sextortion Looks Like

At its core, sextortion is blackmail. The attacker gains access to intimate material — or convinces you to send it — and then threatens to share it unless demands are met.

When I was working with one victim, the scammer claimed to have screenshots of private video chats and demanded money in exchange for silence. The threats felt immediate and overwhelming. In another case, the attacker simply fabricated images and relied on fear to pressure the victim. In both situations, the blackmailer’s real weapon wasn’t technology — it was fear.

Proactive Protection: Steps to Reduce Your Risk

While no prevention method is foolproof, there are practical things you can do right now to lower your exposure:

• Think before you share. Once intimate material leaves your device, you lose control of it.
• Strengthen your accounts. Use strong passwords and turn on two-factor authentication.
• Stay alert to red flags. If a stranger online suddenly showers you with attention, pushes for private chats, or asks for explicit images, that’s a danger sign.
• Talk to teens. Both of the cases I assisted involved adults, but many victims are minors. Predators thrive when kids feel too ashamed to talk to parents or mentors.

Reactive Steps: What To Do If You’re Targeted

If you find yourself in this situation, here’s what I’ve seen work in real life:

1. Don’t pay. One victim I worked with almost wired money. After they cut off contact, the attacker moved on — because they had no leverage once the fear was broken.
2. Stop engaging. The more you talk, the more they manipulate. Block and walk away.
3. Preserve evidence. Save messages, screenshots, usernames, and payment demands. This is critical if you involve law enforcement.
4. Report it.
   • File with the FBI Internet Crime Complaint Center (ic3.gov).
   • Contact local police.
   • If a minor is involved, report to CyberTipline.
5. Tell someone you trust. In one case, the breakthrough came when the victim finally told a close friend. The relief of not being isolated made all the difference.
6. Care for your mental health. Attackers count on shame. Don’t give them that power — talk to someone, whether it’s a counselor, a mentor, or a crisis hotline.

What I’ve Learned Helping Victims

When people are targeted, their first reaction is usually panic: “My life is over if this gets out.” That’s exactly what attackers want you to believe. But the reality is that sextortionists are after quick money, not a long battle. When you refuse to engage, cut them off, and involve the right authorities, they often vanish.

The most important lesson: you are not alone, and you are not powerless.

Resources

• FBI Internet Crime Complaint Center (IC3): ic3.gov
• National Center for Missing & Exploited Children: report.cybertip.org
• Suicide & Crisis Lifeline (U.S.): Dial 988
• Crisis Text Line: Text HELLO to 741741

Closing

Sextortion thrives on silence. The attackers count on you being too afraid or ashamed to fight back. The way we win is by breaking that silence — by talking about it, by supporting each other, and by reporting these crimes.

If you’ve been targeted, remember: your worth is not defined by an attacker’s threats. You are stronger than the fear they are trying to create.

Take Action

• Share this post to spread awareness.
• Talk about sextortion with friends, family, and colleagues.
• Reach out if you or someone you know needs guidance. No one has to face this alone.