Envilder – Version-Controlled Secret Mapping for AWS and Azure

Published June 13, 2025 Updated August 9, 2026

This article has been substantially updated after feedback from Envilder maintainer Marçal Albert Castellví. The original June 2025 version incorrectly described the project’s implementation, installation, command syntax and AWS SSM retrieval model. Those errors have been corrected, and the article now covers the significant changes to Envilder since the original publication.

Envilder is a Node.js command-line tool and set of runtime SDKs for mapping application environment variables to secrets held in AWS Systems Manager Parameter Store or Azure Key Vault. It does not introduce another vault or secrets service. The secret values remain with the cloud provider, while a JSON file committed alongside the application records which secret each variable should resolve to.

[envilder] — Version-Controlled Secret Mapping, showing envilder.json fields $config, provider, DB_PASSWORD and API_KEY routed to AWS SSM and Azure Key Vault.

That mapping is the part I missed when I first covered Envilder in June 2025. I described it as fetching parameters recursively from an AWS SSM path and turning them into environment variables. It has never worked that way. Every variable is explicitly declared, so changing which secret an application consumes produces a repository diff that can go through the same review process as an application change.

The project has also moved considerably since that original article. AWS is no longer the only provider, there is now a GitHub Action for CI/CD, and .NET, Python and Node.js SDKs can resolve the same mapping directly at application startup without writing a .env file to disk.

Overview

A normal secret manager answers one part of the configuration problem well: where should the sensitive value live? AWS SSM Parameter Store and Azure Key Vault already provide storage, access controls, auditing and integration with their respective cloud identity systems.

The application still needs to know which value it expects and where to find it. That relationship can end up scattered between deployment scripts, CI configuration, application code and settings changed directly in cloud consoles.

Envilder puts that relationship into an explicit mapping file. A basic AWS configuration looks like this:

{
  "$schema": "https://envilder.com/schema/map-file.v1.json",
  "DB_PASSWORD": "/my-app/prod/db-password",
  "API_KEY": "/my-app/prod/api-key"
}

{

"$schema": "https://envilder.com/schema/map-file.v1.json",

"DB_PASSWORD": "/my-app/prod/db-password",

"API_KEY": "/my-app/prod/api-key"

}

The names and provider references can be committed safely. The values are still retrieved from the secret store at execution time.

This makes a change from one secret path to another visible in Git. Someone reviewing a pull request can see that DB_PASSWORD now points somewhere different without gaining access to the password itself.

Features

Explicit Secret Mapping

Envilder does not enumerate an SSM hierarchy and infer variable names from whatever happens to be underneath it. Each application variable maps to a specific provider-side value.

On AWS that means individual ssm:GetParameter requests rather than ssm:GetParametersByPath. SecureString parameters are requested with decryption enabled, so the executing identity also needs permission to use the appropriate KMS key where required.

I prefer this design to path discovery for application configuration. It is more verbose, but the repository tells you exactly what the application expects. Adding or removing a secret becomes intentional rather than an accidental consequence of changing the contents of a parameter hierarchy.

AWS SSM And Azure Key Vault

The original release was AWS-only. Envilder added Azure Key Vault support in 2026 and now uses the same mapping model with either provider.

An Azure configuration can declare the provider and vault directly in the mapping:

{
  "$schema": "https://envilder.com/schema/map-file.v1.json",
  "$config": {
    "provider": "azure",
    "vaultUrl": "https://my-vault.vault.azure.net"
  },
  "DB_PASSWORD": "my-app-prod-db-password",
  "API_KEY": "my-app-prod-api-key"
}

{

"$schema": "https://envilder.com/schema/map-file.v1.json",

"$config": {

"provider": "azure",

"vaultUrl": "https://my-vault.vault.azure.net"

"DB_PASSWORD": "my-app-prod-db-password",

"API_KEY": "my-app-prod-api-key"

}

Google Cloud Secret Manager is listed on the project roadmap but is not currently supported.

CLI, CI/CD And Runtime

The same mapping is now consumed in three different places.

The CLI can resolve values into a local .env file. A GitHub Action provides the equivalent mapping for CI/CD. Runtime SDKs for .NET, Python and Node.js can instead resolve the secrets during application startup and keep them in process memory without creating a .env file.

That reuse is probably the most useful improvement since the original release. Local development, a build pipeline and production application startup no longer need three independently maintained descriptions of the application’s secret requirements.

Controlled Push

Envilder can also push values back to the configured cloud provider. That is useful when initially populating an environment or intentionally rotating a value, although I would keep the IAM or RBAC permissions for that operation separate from normal read-only application access.

Installation

Envilder v0.13.0 requires Node.js 22.12 or later. There are no pre-built Go binaries and the old installation command in this article was incorrect.

You can run Envilder directly through npx:

npx envilder --version

1	npx envilder --version

Or install the CLI globally with npm:

npm install -g envilder

1	npm install -g envilder

For AWS, configure credentials with permission to read the SSM parameters referenced by the mapping. SecureString values are decrypted automatically when the executing identity has the required KMS permission.

Usage

Create an envilder.json file containing the application’s mappings:

{
  "$schema": "https://envilder.com/schema/map-file.v1.json",
  "DB_PASSWORD": "/my-app/prod/db-password",
  "API_KEY": "/my-app/prod/api-key"
}

{

"$schema": "https://envilder.com/schema/map-file.v1.json",

"DB_PASSWORD": "/my-app/prod/db-password",

"API_KEY": "/my-app/prod/api-key"

}

Resolve those values from AWS SSM and write the resulting environment file:

npx envilder --map=envilder.json --envfile=.env

1	npx envilder --map=envilder.json --envfile=.env

Azure Key Vault can be selected from the command line where the provider is not already defined in the map:

npx envilder --provider=azure --vault-url=https://my-vault.vault.azure.net --map=envilder.json --envfile=.env

1	npx envilder --provider=azure --vault-url=https://my-vault.vault.azure.net --map=envilder.json --envfile=.env

Runtime SDKs

The runtime SDKs remove the intermediate environment file completely.

Python applications can install Envilder from PyPI:

pip install envilder

1	pip install envilder

Then resolve the application’s mapping during startup:

from envilder import Envilder

Envilder.load("envilder.json")

from envilder import Envilder

Envilder.load("envilder.json")

The .NET package integrates with the standard configuration system:

dotnet add package Envilder

1	dotnet add package Envilder

It can then add the mapped values directly to application configuration:

var config = new ConfigurationBuilder()
    .AddEnvilder("envilder.json")
    .Build();

var dbPassword = config["DB_PASSWORD"];

var config = new ConfigurationBuilder()

.AddEnvilder("envilder.json")

.Build();

var dbPassword = config["DB_PASSWORD"];

Node.js applications have an equivalent SDK:

npm install @envilder/sdk

1	npm install @envilder/sdk

Security Relevance

Envilder does not solve secrets management as a whole. AWS IAM or Azure RBAC still decides who can retrieve a value. The underlying provider still owns storage, encryption, auditing and rotation. Envilder will not tell you whether an application has excessive privileges or whether the secret itself should exist.

Its narrower contribution is making the application’s dependency on those secrets explicit.

That becomes useful in environments where configuration otherwise accumulates outside the normal code-review process. If an application’s database credential moves from one secret to another, the mapping changes. If a new third-party API key becomes necessary, another mapping appears. If an application stops needing a secret, the corresponding entry can disappear.

None of those changes reveal the value, but they leave an ordinary Git history showing what the application was configured to consume and when that changed.

This also sits reasonably well with the cloud-native security model. Envilder does not proxy secret requests through another hosted service or require teams to migrate values into a separate vault. Authentication remains AWS or Azure authentication, and access remains visible through the provider’s own audit facilities.

Where It Fits

I would look at Envilder for teams already using AWS SSM Parameter Store or Azure Key Vault but handling secret consumption differently in local development, CI and production.

It is less compelling if you already have a mature secrets platform with application integration, policy enforcement and a well-managed deployment abstraction that provides the same contract. Envilder deliberately does not attempt to compete with HashiCorp Vault or the cloud secret stores themselves.

There is also some operational responsibility in committing the mapping. Secret values are absent, but paths and names can still reveal application structure, service names and the existence of sensitive integrations. That is usually an acceptable trade for an internal repository, but it should not be mistaken for information with zero sensitivity.

Conclusion

Envilder is a better project today than the one I covered in 2025, but the bigger correction is that I misunderstood its original design.

The useful part was never recursively downloading an SSM path. It was making the relationship between an application variable and a specific cloud-managed secret explicit and version controlled.

The additions since then make that model considerably more practical. The same contract can now follow an application from a developer laptop into GitHub Actions and then into .NET, Python or Node.js at runtime, while the actual values remain in AWS or Azure.

That is a relatively small layer in a secrets architecture, which is probably why it is useful. Teams that already trust their cloud provider to hold the secrets do not necessarily need another place to put them. They may just need a better record of which application is supposed to consume what.

You can read the Envilder documentation here: https://envilder.com/

The source code is available on GitHub: https://github.com/macalbert/envilder

Buffer

whitelist-bypass – WebRTC Tunnels Through Video-Calling Platforms

whitelist-bypass tunnels internet traffic through commercial video-calling platforms, aimed at networks that permit an approved list of domains and block everything else. Tunnelling over WebRTC isn’t new. What caught my attention is what this project chooses to ride.

Whitelist censorship is a different problem from a blocklist. A blocklist leaves the rest of the internet reachable, so a proxy on some unremarkable host usually gets you out.

A whitelist inverts that. Only approved destinations resolve and connect; everything else fails. To get through, your traffic has to be one of the approved destinations, not merely look unlike a blocked one.

whitelist-bypass’s answer is to send your data to a video-calling service the censor has already allowed. A device on the censored network places what looks like an ordinary call to VK Call, Yandex Telemost, or WB Stream; a machine on the free internet answers, and the traffic you actually want rides inside that call.

It all rests on the platform’s media server sitting on the approved list. Whether a given platform is permitted, and stays permitted, is a fact about one network at one moment. The tool doesn’t control it.

Two tunnels, and why there are two

The project gives you two ways to carry data through the call, and the second one exists because the first can be throttled.

DC mode opens a WebRTC data channel – an SCTP stream, the same primitive a browser uses for peer-to-peer file transfer – and pushes a SOCKS5 tunnel through it. Your traffic becomes data-channel payload, relayed by the platform’s media server like any other call data.

Video mode does the same job, but encodes the data onto a published VP8 video track instead. It’s there for a reason the repository makes clear: some media servers rate-limit data channels while passing video freely, and on at least one supported platform the publisher’s track has to be video at all.

So when the data channel gets squeezed, the tunnel moves into the one stream a video call can’t do without. Both modes share the same framing and multiplexing above the transport, so the only difference is which stream carries the bytes.

The recommended deployment runs headless on both ends: pure Go on the Pion WebRTC stack, talking to the platform’s media server directly with no browser in the loop.

What is actually in the repository

I cloned the current main branch (commit 747f8f2, 3 September 2026) and read the source rather than the description of it. The tunnel is real code, not a README promise.

The shared relay under relay/ implements the SOCKS5 proxy, the data-channel and VP8 tunnels, a connection multiplexer and an obfuscator. Separate headless creators handle each platform – vk, telemost, wbstream and dion – each its own Go module that creates or joins a call through the platform’s API without a browser.

The obfuscator is a deliberate choice. It derives a secret from the call’s join link, hashes it with SHA-256, and uses that key with XChaCha20-Poly1305 authenticated encryption and random per-message nonces; it also pads keepalive frames.

So the payload inside the call is encrypted independently of the platform’s own transport security, keyed by something both ends already share: the link used to join the call. Any smoothing of the video track’s timing is separate transport code, not part of the obfuscator.

It’s genuinely multi-platform. The joiner – the client on the censored side – targets Android, iOS and Linux; the creator, on the free side, targets Windows, macOS and Linux. On Android it runs as a system VPN, so all traffic flows through the call.

iOS is more involved. The source tree carries two forms: a proxy app that exposes a local SOCKS5 endpoint another app points at, and a VPN app that uses Apple’s Network Extension capability for system-wide routing.

Only the proxy build ships as a prebuilt IPA in the v0.3.8 release. The VPN app is in the source and its build target is documented, but it needs signing and that capability, so if you want it you’ll be building and signing it yourself.

Where it sits among WebRTC tunnels

Carrying a tunnel over WebRTC is well-trodden ground. Pion’s own ecosystem list includes Tor’s Snowflake, weron, rtctunnel and a WebRTC socket proxy, and whitelist-bypass sits on that same list. So the interesting part isn’t the transport but the carrier it rides.

Snowflake, the closest well-known relative, uses volunteer browsers as ephemeral WebRTC proxies to reach Tor. whitelist-bypass instead points at named commercial calling services and leans on them being individually whitelisted by the censor.

That’s a sharper bet, and a more fragile one. It works precisely because a specific platform is on the approved list, and it stops working the moment that platform comes off it. The video-track fallback is the same logic one level down: when the cheap channel is squeezed, you move to the stream the service can’t throttle without breaking the calls it exists to carry.

Darknet has covered the covert-tunnel idea before, from the enterprise side. ProxyBlob runs a SOCKS5 tunnel over Azure Blob Storage, betting that a cloud endpoint is too ordinary to block. whitelist-bypass makes the same structural move against a stricter filter, with a consumer platform as the cover instead of a cloud service.

The claim to be careful about

The project says that to deep-packet inspection the tunnel “looks like a normal video call”. That’s the load-bearing claim, and it’s the one this article can’t verify.

So does it actually look like a video call on the wire? Confirming that needs a real censored network, live DPI equipment, and traffic analysis over time, none of which a source review gives you.

There are reasons for genuine caution. A real video call has a characteristic traffic shape: bitrate, packet timing, the rhythm of a codec reacting to a moving image. A tunnel that’s pushing bulk data through a VP8 track is under pressure to depart from that shape.

The project does offer configurable VP8 pacing and padded keepalive frames, controls plainly aimed at the problem. But whether the result survives statistical traffic analysis, rather than simple protocol matching, is an empirical question and an arms race. It isn’t a property you can read off the code, so I’d treat “looks like a video call” as the project’s design goal, not a measured result.

Two smaller cautions follow from the design. It depends entirely on the carrier platform staying whitelisted, so it’s only ever as durable as that political fact. And the obfuscator keys on the join link, so a session is only as secure as that link’s distribution: anyone who has the link has the key.

Maturity and provenance

The repository is MIT-licensed, sits at around 1,630 stars and 100 forks, and is actively developed: seventeen releases, the most recent (v0.3.8) in July 2026, commits running into September, six contributors led by one. That’s real momentum for a project barely six months old.

The 0.3.x version line is honest about where it stands, too – software shipped through release artefacts and still changing, not a settled release.

There’s one practical consequence of the anti-censorship purpose. The project’s public contact is a Telegram channel rather than a corporate page, and its authorship is a handful of pseudonymous GitHub accounts. For a tool whose users may be on the wrong side of a national firewall, that’s unremarkable.

It does mean, though, that the repository points at no named organisation, no identified maintainer and no published security audit. Anyone deploying it for real is trusting the code and the build, and should read both.

Reviewed 6 September 2026 against commit 747f8f2. I verified the source-level mechanism, build surface, release history and dependency choices directly; I didn’t run it against a live target, and its DPI-resistance claim is the project’s own, not independently confirmed here.

You can find whitelist-bypass here: https://github.com/kulikov0/whitelist-bypass

WRAITH – Browser Hooking and Blind XSS Page Mirroring

WRAITH is a browser-hooking framework that combines a BeEF-style command channel with the evidence collection normally associated with tools such as xsshunter-express. A JavaScript hook calls home over WebSocket, appears in an operator console and can receive capture, social-engineering and local-reconnaissance modules.

The public repository appeared on 1 August 2026. Its three commits all landed that day: the initial code release, a metadata correction and a documentation update. The package declares version 1.0.0, but there is no GitHub release and the project describes itself as work in progress.

Darknet first covered BeEF in October 2006, when its modular console and list of controlled browsers were the story. BeEF still uses a hooked browser as a beachhead for command modules. WRAITH keeps that model, adds the one-shot evidence expected from blind-XSS tooling, then tries to make the captured page navigable.

The hook itself is small enough to follow. It derives its callback address from the script URL, connects to the public /ws/hook endpoint and sends a browser fingerprint. The operator can deploy JavaScript modules to that live browser; completed results return over the same channel and are persisted by the server.

Page Capture fires automatically by default. It records the origin, URL and referrer, reads JavaScript-visible cookies, serialises the DOM and attempts a screenshot. The implementation labels the two important failures instead of hiding them: HttpOnly cookies are unavailable to JavaScript, while Content Security Policy or cross-origin images can prevent a useful screenshot.

Page Mirror takes a different route. When the operator follows a link, the command is relayed to the hooked browser. That browser calls fetch() with credentials included, reads the response and sends the returned HTML back to WRAITH. The request therefore carries cookies that JavaScript cannot read directly, including an HttpOnly session cookie, because the browser attaches them to an eligible same-origin request.

HttpOnly still does its job: the cookie value is not exposed to the hook. It does not prevent code already executing in the origin from asking the browser to make an authenticated request. WRAITH makes that distinction visible in its practice lab, where the captured cookie list is empty but a mirrored request can still reach a session-gated page.

The operator is not remotely driving the victim’s original tab. WRAITH removes scripts from the returned HTML, inserts a base URL, intercepts link clicks and blocks form submissions inside a sandboxed frame. Each selected link becomes another credentialed GET request through the hooked browser.

A server-rendered application with useful links can become a navigable evidence set. A client-heavy application whose interface depends on JavaScript will not replay faithfully, and a workflow that requires a form submission is deliberately stopped. Calling it a mirror is fair; treating it as a complete remote-browser session is not.

For a red-team engagement, the useful sequence starts after authorised JavaScript execution has already been achieved. Page Capture establishes where a blind payload fired. Page Mirror can then inspect same-origin pages available to that browser session without first extracting the session token. Cross-origin reads remain subject to the browser’s Same-Origin Policy.

What was tested

I cloned the current main branch, installed the locked Node dependencies and started WRAITH on loopback. The operator console, demo page, practice lab and hook script each returned HTTP 200. All twelve JavaScript files passed Node’s syntax checker.

The public-bind safeguard also behaved as documented. Starting the server on 0.0.0.0 without an operator password exited with status 1 and refused to expose the console. I did not connect a second browser, deploy an overlay or exercise Page Mirror against anything outside the bundled local lab.

Installation

The documented Docker route requires Node.js 18 or later, Docker and Docker Compose. The repository’s setup sequence is:

git clone https://github.com/Arcanum-Sec/wraith
cd wraith
./setup.sh

git clone https://github.com/Arcanum-Sec/wraith

cd wraith

./setup.sh

setup.sh asks for the public address and operator credentials, generates a session-signing secret, writes a protected .env file and starts the container. A local development route is also documented with npm install followed by npm start.

The service refuses a public bind without an operator password, but the hook endpoint must remain reachable by design. A real deployment therefore needs more than a password: the project’s deployment guide recommends TLS, a per-cohort credential and removing the service between exercises.

The server becomes part of the evidence boundary

WRAITH persists captured credentials, DOM content, scan results and mirrored page HTML under data/sessions.json. It keeps as many as sixty mirrored pages per session and caps stored HTML at two megabytes per page. Hiding a session in the console does not delete it; the operator has a separate permanent-forget action.

That makes the WRAITH host sensitive even in an authorised exercise. The data directory can contain the same application content and credentials the engagement was intended to demonstrate. Retention, access control and teardown belong in the test plan before the first payload is delivered, not after the console has collected evidence.

WRAITH is not a BeEF replacement yet

BeEF has accumulated thousands of commits, an extension system and a large catalogue of command modules. WRAITH currently ships a much smaller set: three login overlays, page capture and a browser-based port scanner alongside the mirror. The comparison is useful because it shows the design lineage; it does not establish feature parity.

Blind-XSS tooling usually proves that a payload executed and returns a snapshot. A classic browser hook supplies an interactive command channel. WRAITH joins those stages and adds credentialed, same-origin link traversal without claiming that it has stolen an HttpOnly cookie.

That boundary is not new. Darknet covered evilreplay in July 2025: it also uses JavaScript already running in an origin to act through an authenticated browser session without reading the cookie value. The difference is operational. evilreplay aims at interactive post-exploitation control, while WRAITH’s Page Mirror deliberately narrows the job to credentialed same-origin GET traversal, strips scripts and blocks forms. WRAITH packages that traversal beside blind-XSS capture and a persistent module channel; it does not establish a new session-riding mechanism.

The unresolved part is browser behaviour over time. WRAITH’s own network-scanning notes already distinguish reliable loopback checks from LAN modes affected by newer browser controls. Page Mirror depends just as directly on fetch behaviour, session policy and the shape of the application being mirrored. With no automated test suite and no code revision since launch, those boundaries still need to be exercised on the browsers and applications an engagement actually uses.

Download WRAITH and inspect the source on GitHub.

Praetorian – Offensive Security Tools Built Around Portable Go Workflows

Praetorian’s Roman names suggest a coordinated offensive security suite. The repository dependency graph shows a looser and more useful structure: independently installed Go tools, several direct workflow connections, and a shared SDK used by part of the collection

In the ten repositories assessed on 9 August 2026, four imported capability-sdk: Brutus, Pius, Vespasian and Trajan. The other six did not. Brutus also imported Nerva directly, while Aurelian imported Titus. The shared SDK arrived after the tools it now connects.

That result sets the boundary. These projects cover familiar parts of an assessment, including service fingerprinting, credential testing, secrets scanning, asset discovery, API assessment, Bluetooth Low Energy testing and cloud security. They fit Darknet’s Hacking Tools coverage, but a Roman name alone says nothing about whether two tools exchange data or share an implementation.

The strongest case for the collection appears where Praetorian has reduced deployment work or removed translation between stages.

Titus packages secrets scanning for several environments

Titus is a secrets scanner with 487 detection rules drawn from NoseyParker and Kingfisher. It can inspect source trees, Git history, container images, archives and documents, then validate supported credentials against their source services. The same detection engine is exposed through a command-line tool, a Go library, a Burp Suite extension and a Chrome extension.

Its build options also show what “portable” means in practice. The accelerated build uses Hyperscan or Vectorscan through CGO, while a pure-Go target remains available for systems where those native dependencies are unsuitable. The current source instructions build it with:

make build

1	make build

The output is written under dist/titus. Prebuilt releases are available as a separate route. Those are the installation claims the repository supports; its Vectorscan clone command installs a build dependency, not Titus itself.

Titus therefore consolidates detection, file handling and credential validation behind one interface. The rule count does not establish coverage by itself, and successful validation proves that a credential works at the time of the check, not what access its owner intended. Those questions still belong in the assessment around the tool.

Nerva and Brutus form the clearest pipeline

Nerva fingerprints more than 170 protocols across TCP, UDP and SCTP. It expects another scanner to find open ports, then identifies the services behind them and emits structured results. Checks for common service misconfigurations require an explicit option and are absent from its default fingerprinting pass.

Brutus consumes those results and tests credentials across 27 protocols. Its documentation includes a complete pipeline from network discovery through service identification to credential testing:

naabu -host 10.0.0.0/24 -silent | nerva --json | brutus creds -P passwords.txt

1	naabu -host 10.0.0.0/24 -silent \| nerva --json \| brutus creds -P passwords.txt

On an authorised assessment, that command lets Naabu identify exposed ports, Nerva determine what is listening, and Brutus apply an agreed password set to the relevant services. This is the collection’s most concrete integration: Brutus imports Nerva, and the documented data path removes a parsing step between them.

The Brutus name also collides with Darknet’s own archive. Brutus AET2 appeared here in 2006 as a Windows remote login cracker, while THC Hydra followed in 2007. Praetorian’s Brutus addresses the same broad job with a maintained Go binary and an input path from current discovery tooling. The shared name does not indicate a relationship between the projects.

Caeruleus consolidates a fragmented Bluetooth workflow

Caeruleus applies the same engineering approach to Bluetooth Low Energy assessments. Its documentation starts from a workflow split across bettercap, deprecated BlueZ utilities and custom Bleak scripts. Caeruleus combines discovery, interaction and assessment functions in one Linux binary, with JSON and JSONL output for later processing.

This is useful consolidation because the underlying task normally crosses several utilities with different interfaces. It is still bound to Linux, compatible Bluetooth hardware and the operating system’s Bluetooth stack. One binary reduces setup without removing those environmental constraints.

The remaining repositories spread across other stages of an engagement. Pius maps organisations to internet assets, Vespasian discovers API surfaces, Hadrian tests API authorisation, Augustus targets large-language-model applications, and Aurelian examines cloud environments. They need to be assessed against the established tool in each category; their common authorship and implementation language do not supply that comparison.

The shared SDK marks a partial product boundary

Praetorian describes capability-sdk as a shared Go SDK for building security capabilities for the Guard platform. It supplies common Target, Finding and Capability types. Its architecture diagram shows a “Chariot Adapter” in a separate chariot repository. Both the Guard and Chariot names appear in the project’s own documentation; the public material does not explain the difference.

The four imports measured on 9 August establish a real integration layer, with six assessed repositories still operating outside it. Direct dependencies add another layer: Brutus uses Nerva, and Aurelian uses Titus. This produces a partially connected collection in which some tools can run independently, some hand work directly to another repository, and some can also emit types intended for Praetorian’s platform.

That architecture leaves a practical test for each project. A portable binary matters when it removes installation work on an engagement system. Structured output matters when another stage actually consumes it. A replacement matters when it preserves the coverage and reliability of the incumbent while reducing operational friction. The Nerva-to-Brutus path demonstrates all three properties; the other repositories have to demonstrate them in their own domains.

Browse Praetorian’s open-source repositories: https://github.com/orgs/praetorian-inc/repositories

AI IR Overlay – Incident Response Specification for AI Agents

An OAuth token can be valid, the API call authorised, and the action still be something nobody intended. The agent used the credential it was given, through the interface it was approved for, and the audit log records all of it correctly. Nothing in that sequence resembles an intrusion, because nothing was intruded upon.

AI IR Overlay extends established incident-response practices with AI-agent inventories, graded containment, evidence capture and controlled recovery.

That is the case AI IR Overlay is built around, and it is a genuinely awkward one for an incident response programme. There is no compromised account to disable. Identity telemetry is accurate and unhelpful. The question is not whether the credential was stolen but what the agent was told, what it could reach, and how much of that it did before anyone noticed.

The framework is a specification for answering those questions: 24 playbooks, three JSON schemas, two runnable reference implementations, Apache 2.0, one author. It is better than its adoption numbers suggest, and it stops in a specific and interesting place.

What it actually supplies

Three artefacts, mapped onto NIST SP 800-61 Rev. 3 and cross-referenced to NIST CSF 2.0, the NIST AI RMF and the OWASP Top 10 for Agentic Applications.

An AI Bill of Materials — YAML, one per production agent, recording service identity, scopes, tools, write targets, memory settings and retrieval sources. The insistence throughout is on what the deployed agent can reach rather than what the design document says it should. An agent wired into email, a CRM and an ERP has three separate blast radii before anyone has looked at the model, and that map costs far less to build on a quiet Tuesday than at two in the morning.

A containment ladder, M0 to M5, replacing the single kill switch. M1 is the rung that matters: “All write tools are stripped from the agent’s tool set”, with read and query tools left running. That is the containment shape you actually want for an agent sitting inside a business process, because destroying the session and rotating every credential also destroys the state needed to reconstruct what happened.

A minimum evidence set across six classes — prompts and responses, tool-call records, retrieval traces, memory state, configuration state, and identity or downstream audit logs. Wider than endpoint telemetry by design, because the opening case produces no unusual process tree and no suspicious authentication event.

None of this asks a SOC to invent a new discipline. The command structure, the evidence handling and the recovery process all stay where they are, which is the framework’s best decision and the reason it is worth the reading time.

What the validator proves

scripts/validate.py is 279 lines. It performs JSON Schema validation and date-staleness checks against the AI-BOM and privilege-matrix files — no subprocess call, no network access, nothing that executes the systems being described.

That is more useful than it sounds. A containment-test date that has gone stale becomes a build finding, which is more than most control frameworks manage. Two qualifications matter, though, and both are easy to overstate in the other direction.

Staleness only fails a build in strict mode. By default the validator prints STALE-WARN and exits zero; --strict turns those into errors. A team wiring this into CI without the flag gets warnings the pipeline does not enforce.

And a passing build says a control was declared, not that it works. The validator confirms an organisation has written down that it has a kill switch and written down when it last tested one. Whether the switch functions is outside what any schema check can reach. That distinction is the whole subject of this framework, so it is worth not blurring in the one place it can be measured.

Where the automation stops

The actuation layer is more complete than a quick look suggests. There is a 19KB kill-switch API contract in schemas/kill-switch-api.md, referencing M1 a dozen times, and a runnable demo in reference-impls/kill_switch_demo/ implementing the M0–M4 contract against a synthetic tool registry — M5, controlled re-enable, is explicitly out of scope. A second reference implementation, evidence_exporter, ships adapter stubs for each of the six evidence classes. The interface for moving an agent between containment states is specified and demonstrated.

What is not specified is when to move it.

The kill-switch overview is explicit, and the wording repays reading closely:

the ≤ 10-min Tier-1 SOC activation owner assumes a staffed Security Operations Center available to receive the incident-commander order. For purely autonomous agents in 24/7 operation where no SOC is staffed off-hours (and the agent owner is the only human in the loop), the M3/M4 activation path requires automation that this v0.33.0 specification does not yet define.

So the documented activation path assumes a staffed SOC. The escalation path to M3 or M4 assumes a human incident commander reachable inside ten minutes, and where that assumption fails, the specification says so and stops. No signals, no thresholds, no policy for which mode to enter at what scope.

The hole sits exactly where the agent is most autonomous and the team is smallest. An organisation with a 24/7 SOC has the least need of an automatic trigger and matches the operating model the specification assumes. A two-person team running an agent unattended overnight has the most need and gets an acknowledged gap.

One smaller thing, on the same page: it describes itself as v0.33.0 while the current release is v0.35.0, and nothing has been pushed to the repository since 9 July. Version drift on the safety-controls page is the drift that costs most.

What the archive says about this problem

Darknet reviewed FIDO in 2016 — Netflix’s orchestration layer for automated incident response, evaluating and scoring malware detections. Its own capability list at the time read: “Enforcement – Currently work in progress (disable accounts, reset passwords, kill NIC etc).” Correlation and scoring were built. Acting on them was not. FIR arrived a year later with the case-management half.

Ten years on, AI IR Overlay lands on the same boundary from the other side. It supplies the containment contract and a working demonstration of it — the enforcement half FIDO left unfinished — and leaves the autonomous decision to adopters.

That continuity is the finding. Two projects, a decade apart, different problems, and both stop where a machine would have to decide on its own that something is wrong enough to act. The interface is the tractable part. The trigger is not, and naming it keeps the missing piece visible rather than implied.

For the offensive side, this doubles as a concrete definition of impact. We have covered PyRIT and mcp-scanner for exercising agent attack surfaces. Finding the prompt injection is the easy half. If the target cannot put the affected agent into read-only mode, cannot disable one high-risk tool without killing the service, and cannot export its retrieval and tool-call history afterwards, those are findings in their own right.

What teams can use today

Treat this as a planning and tabletop framework, not as proven operational containment. The maturity evidence is thin and the project does not hide it: one contributor, 479 commits, one star, no forks, no issues opened or closed, and no documented production incident. The end-to-end walkthrough in the repository is synthetic and labelled as such.

So run the exercises and do not report the maturity levels upward. Take one production agent, write down what it can actually write to, try to put it into read-only mode, and try to export six classes of evidence covering the last hour. Any of those three failing is a real gap in a real system.

And then ask the question the specification leaves open: if that agent misbehaves at three in the morning and nobody is watching, what moves it to M3? On present evidence the answer is a person who has not been woken up yet, and AI IR Overlay has not written down how to replace them.

You can read the specification here: https://github.com/jacobideji/aiiroverlay

MSSQLand – Lightweight MS-SQL Interaction Tool for Lateral Movement and Post-Exploitation

MSSQLand is a .NET Framework 4.8 utility designed for interacting with Microsoft SQL Server database management systems during red team operations and security audits. Built for constrained environments where operations must be executed directly through beacons using assembly execution, the tool enables operators to traverse linked SQL Server instances, impersonate users, and execute actions without needing complex Transact-SQL (T-SQL) queries. The project was released in March 2026 and fills a critical gap in SQL Server post-exploitation workflows where traditional database tools are unavailable or impractical.

Unlike SQL Server Management Studio (SSMS) or Python-based tools like mssqlclient-ng, MSSQLand is optimized for lateral movement scenarios where an operator already has initial SQL Server access but needs to pivot through linked instances or escalate privileges via impersonation. The tool automates the tedious process of manually crafting Remote Procedure Call (RPC) and OPENQUERY statements across linked server chains, allowing red teams to focus on execution rather than syntax debugging.

Features

Linked server chain traversal with automatic OPENQUERY and RPC Out handling for multi-hop SQL Server scenarios
User impersonation via EXECUTE AS USER to escalate privileges within database contexts without needing system-level permissions
Configuration Manager (ConfigMgr) support for exploiting and enumerating Microsoft Configuration Manager deployments (formerly known as SCCM/MECM)
Connection testing mode that validates credentials without executing queries, ideal for a minimal OPSEC footprint during reconnaissance
Clean Markdown-compatible output tables suitable for direct paste into engagement reports and documentation
CSV export format option for automated processing and integration with other toolchains
Assembly execution ready, built with Cobalt Strike, Havoc, Sliver, and other C2 frameworks in mind
Multiple authentication methods, including Windows authentication, SQL Server authentication, and Kerberos tickets (via external tools)

Installation

MSSQLand is distributed as a pre-compiled Windows executable. Download the latest release from the GitHub Releases page and transfer the executable to your target environment or beacon working directory.

# Download from GitHub Releases
# https://github.com/n3rada/MSSQLand/releases
# For operators compiling from source
# Requires Visual Studio with .NET Framework 4.8 SDK

git clone https://github.com/n3rada/MSSQLand.git
cd MSSQLand

# Open MSSQLand.sln in Visual Studio and build for x64 Release

# Download from GitHub Releases

# https://github.com/n3rada/MSSQLand/releases

# For operators compiling from source

# Requires Visual Studio with .NET Framework 4.8 SDK

git clone https://github.com/n3rada/MSSQLand.git

cd MSSQLand

# Open MSSQLand.sln in Visual Studio and build for x64 Release

The tool is designed for assembly execution from C2 frameworks. No installation or registration is required on the target system, making it suitable for operations in restricted or monitored environments.

Usage

This repository does not provide a global --help flag in the traditional sense. The following usage information is reproduced verbatim from the README and GitHub documentation.

MSSQLand.exe <host> [options] <action> [action-options]

# Connection test only (no action executed)
MSSQLand.exe localhost -c token

# Execute specific action
MSSQLand.exe localhost -c token info
MSSQLand.exe localhost:1434@db03 -c token info

# Linked server chain traversal
# Format: server:port/user@database or any combination
# Semicolon (;) separates servers, forward slash (/) specifies impersonation
MSSQLand.exe localhost -c token -l SQL01;SQL02/admin;SQL03@clients info

# Configuration Manager actions (cm- prefix)
MSSQLand.exe sccm-db.corp -c token cm-devices
MSSQLand.exe sccm-db.corp -c token cm-scripts

# CSV output for automation
MSSQLand.exe localhost -c token --format csv --silent procedures > procedures.csv

MSSQLand.exe <host> [options] <action> [action-options]

# Connection test only (no action executed)

MSSQLand.exe localhost -c token

# Execute specific action

MSSQLand.exe localhost -c token info

MSSQLand.exe localhost:1434@db03 -c token info

# Linked server chain traversal

# Format: server:port/user@database or any combination

# Semicolon (;) separates servers, forward slash (/) specifies impersonation

MSSQLand.exe localhost -c token -l SQL01;SQL02/admin;SQL03@clients info

# Configuration Manager actions (cm- prefix)

MSSQLand.exe sccm-db.corp -c token cm-devices

MSSQLand.exe sccm-db.corp -c token cm-scripts

# CSV output for automation

MSSQLand.exe localhost -c token --format csv --silent procedures > procedures.csv

The tool supports flexible host specification, including optional port numbers (default 1433), user impersonation contexts, and database contexts. Linked server chains use semicolon separators and support bracket notation for server names containing delimiter characters. Port specification only applies to the initial host connection; linked servers use configured names from sys.servers.

For detailed action-specific help, use the -h flag with a search term or append -h to an action name. For example, MSSQLand.exe -h adsi shows all Active Directory Services Interface-related actions, while MSSQLand.exe localhost -c token createuser -h displays detailed help for the createuser action.

Attack Scenario

A red team operator gains access to a Windows system during an assumed-breach engagement. The operator discovers that the compromised user account has SQL Server authentication credentials stored in a configuration file. The target environment uses linked SQL Server instances across multiple tiers (web database server, application database server, reporting database server) with trust relationships configured between them. Traditional lateral movement paths via SMB or WinRM are heavily monitored, but database connections are considered normal administrative activity and generate minimal alerts.

The operator loads MSSQLand via Cobalt Strike beacon assembly execution and performs a connection test to validate credentials without triggering database audit logs. The test confirms access to the web tier database server. Using the info action, the operator enumerates linked servers and discovers that the web tier server has an RPC Out trust configured to the application tier server, which in turn links to a reporting server with elevated privileges. The operator constructs a linked server chain using the -l flag, specifying SQL01;SQL02;SQL03, and executes commands through the chain without needing to manually craft nested OPENQUERY statements.

From the reporting server context, the operator discovers a Configuration Manager database. Using MSSQLand’s cm- prefixed actions, the operator enumerates managed devices, scripts, and deployment packages. The cm-devices action reveals high-value targets, including domain controllers and executive workstations. The operator extracts device records, identifies targets with recent check-in timestamps, and uses the information to prioritize next-stage objectives. The entire reconnaissance and lateral movement phase completes without generating suspicious PowerShell or WMI events, as all activity flows through legitimate SQL Server protocols.

Red Team Relevance

SQL Server lateral movement remains underexploited in many red team engagements despite its prevalence in enterprise environments. Linked server trust relationships frequently span security boundaries, allowing operators to pivot from low-privilege web application databases to highly privileged reporting or Configuration Manager instances. MSSQLand removes the primary friction point in SQL Server post-exploitation: the need to manually construct and debug nested T-SQL queries while operating through a beacon or constrained shell.

The tool’s assembly execution design makes it particularly valuable for C2 frameworks where interactive console sessions are limited or monitored. Operators can execute complex multi-hop database traversals with a single-line command, reducing engagement time and minimizing the detection surface. The Configuration Manager support is especially relevant given that SCCM/MECM databases are high-value targets for privilege escalation and infrastructure mapping, yet often lack the hardening applied to Active Directory or endpoint management systems.

MSSQLand also addresses OPSEC considerations that plague traditional database tools. Connection testing without query execution allows credential validation without touching audit-logged tables. The clean output format integrates directly into reporting workflows, reducing the post-engagement effort required to document database access paths. For operators who regularly encounter SQL Server instances during engagements, MSSQLand provides capabilities similar to what BlockEDRTraffic offers for EDR evasion, what SmbCrawler provides for SMB share enumeration, or what CredNinja delivers for credential validation: a focused, practical tool that solves a specific operational problem without requiring extensive T-SQL knowledge.

Detection and Mitigation

SQL Server audit logging should be configured to capture connection attempts, privilege changes via EXECUTE AS USER, and cross-server queries using linked servers. Organizations should monitor for unusual linked server traversal patterns, especially chains that originate from web-facing database servers and terminate at privileged infrastructure databases. Access to the Configuration Manager database by non-administrative accounts warrants immediate investigation, as these databases contain sensitive device inventory and deployment information.

Network segmentation should restrict database server communication to legitimate application tiers. Web tier databases should not have direct RPC Out trust relationships to reporting or management databases. Where linked servers are required for business functionality, implement the principle of least privilege by restricting linked server login mappings to specific service accounts with minimal permissions. Disable xp_cmdshell and other extended stored procedures unless explicitly required and audited.

Blue teams should deploy database activity monitoring solutions that detect OPENQUERY and EXECUTE AT usage patterns inconsistent with normal application behavior. Anomalous login times, source IP addresses outside expected ranges, and rapid sequential queries across linked instances are reliable indicators of post-exploitation activity. For Configuration Manager environments, restrict database access to designated SCCM infrastructure servers and alert on any connections from workstations or non-administrative hosts.

Frequently Asked Questions

What is MSSQLand and how is it different from SQLRecon?

MSSQLand is a .NET Framework 4.8 tool for interacting with Microsoft SQL Server instances during red team operations. Unlike SQLRecon, MSSQLand was built from the ground up with object-oriented programming principles for easier extensibility and modular action development. It simplifies traversal of linked server chains and user impersonation without requiring operators to manually craft complex T-SQL queries.

Does MSSQLand work with Cobalt Strike and other C2 frameworks?

Yes. MSSQLand is designed specifically for assembly execution from C2 frameworks, including Cobalt Strike, Havoc, Sliver, and similar platforms. The tool requires no installation or registration on the target system, making it ideal for operations in constrained or monitored environments where traditional database tools are unavailable.

Can MSSQLand traverse multiple linked SQL Server instances?

Yes. MSSQLand automates linked server chain traversal using the -l flag with semicolon-separated server names. The tool automatically generates the necessary OPENQUERY and RPC Out statements, allowing operators to pivot through multiple SQL Server instances without manually crafting nested T-SQL queries. For example, MSSQLand.exe localhost -c token -l SQL01;SQL02;SQL03 info chains through three servers in a single command.

What authentication methods does MSSQLand support?

MSSQLand supports Windows authentication and SQL Server authentication, and can work with Kerberos tickets when used with external ticket injection tools. The tool also supports user impersonation via EXECUTE AS USER to escalate privileges within database contexts without requiring system-level permissions on the target server.

Does MSSQLand support Microsoft Configuration Manager (SCCM) exploitation?

Yes. MSSQLand includes comprehensive Configuration Manager support with cm- prefixed actions that align with Microsoft’s official PowerShell cmdlet naming convention. Operators can enumerate managed devices (cm-devices), scripts (cm-scripts), packages, and other ConfigMgr infrastructure to identify high-value targets and prioritize next-stage objectives during engagements.

How does MSSQLand maintain OPSEC during database reconnaissance?

MSSQLand includes a connection testing mode that validates credentials without executing queries, allowing operators to verify access without touching audit-logged tables. The tool also provides CSV export options for automated processing, reducing the need for interactive console sessions that might generate suspicious activity logs. All operations flow through legitimate SQL Server protocols rather than PowerShell or WMI, minimizing detection surface in monitored environments.

Conclusion

MSSQLand addresses a practical gap in red team tooling for SQL Server post-exploitation. Its focus on linked server traversal, user impersonation, and Configuration Manager enumeration makes it directly applicable to real-world engagements where database access exists, but traditional lateral movement paths are blocked or monitored. The tool’s design for assembly execution and its minimal OPSEC footprint align with modern C2 workflows, and its clean output format reduces friction in both the operational and reporting phases of engagements. For red teams operating in Windows enterprise environments, MSSQLand is a focused addition to the lateral movement toolkit that complements broader frameworks without requiring extensive database expertise.

You can read more or download MSSQLand here: https://github.com/n3rada/MSSQLand

Credential Stuffing in 2025 – How Combolists, Infostealers and Account Takeover Became an Industry

Stolen credentials are now the single most reliable entry point into enterprise networks. Compromised credentials accounted for 22% of all confirmed data breaches in the period covered by Verizon’s extended credential stuffing analysis accompanying the 2025 DBIR, making it the most common initial access vector for the third consecutive year. Credential stuffing, the automated replay of stolen username-password pairs at scale, requires minimal skill, costs almost nothing to run, and succeeds at rates that make it economically rational to run campaigns against thousands of targets simultaneously. Multi-factor authentication (MFA) remains the single most effective control against it, yet deployment gaps persist across sectors that should know better.

The Credential Supply Chain

Credential stuffing depends on a supply chain that runs from infostealer malware through dark web markets to attack tooling. Malware families, including Lumma, RedLine, StealC, and Acreed, scrape browser password vaults, saved cookies, and autofill data from compromised machines. The harvested data is identical to what tools like DumpBrowserSecrets extract during post-exploitation: saved passwords, session cookies, OAuth refresh tokens, and autofill entries pulled directly from Chrome, Edge, Firefox, and every other major browser. Attackers package that raw material into structured files known as combolists, formatted as email: password pairs, cleaned of duplicates, and categorised by service type or geography before selling them on.

Combolists trade freely across dark web forums, Telegram channels, and dedicated cracking communities. The initial access broker ecosystem documented throughout 2025 has normalised validated credentials as a commodity. Fresh lists built from recent infostealer logs command significantly higher prices than aged database dumps because they have higher validity rates. The Verizon analysis found that only 49% of a user’s passwords across different services are distinct. That figure is what makes credential stuffing economically viable: breach one service, and there is roughly a 50% chance the same password works elsewhere. Across millions of accounts, that probability becomes near-certainty.

The tooling that drives attacks is openly available. OpenBullet and its successor, SilverBullet, are credential-stuffing frameworks originally released as penetration testing utilities, now standard tools in account-takeover (ATO) operations. They automate the full attack loop: loading combolists, rotating through residential proxies to dodge rate limiting and IP blocks, sending login requests that mimic legitimate browser behaviour, and logging successful hits. Attackers also buy and sell custom configuration files, known as configs, that define the authentication flow for specific target services. Unofficial marketplaces offer configs for specific banking portals, SaaS platforms, and enterprise single sign-on (SSO) providers alongside combolists and proxy subscriptions.

Three Case Studies from 2025

In late March 2025, coordinated credential stuffing attacks hit five major Australian superannuation funds simultaneously: AustralianSuper, Rest Super, Hostplus, Australian Retirement Trust, and Insignia Financial. As BleepingComputer reported on the coordinated attacks, attackers compromised over 20,000 accounts across the five funds, with four AustralianSuper members losing a combined AUD 500,000. The attackers used combolists from prior unrelated breaches. AustralianSuper offered MFA but did not enforce it at login, a gap that regulators identified as the primary enabling factor. Retirement funds make attractive targets because account balances are high, withdrawals are slow to reverse, and many members check their accounts infrequently.

In April 2025, VF Corporation notified customers of a credential-stuffing attack against the North Face online store. BleepingComputer’s coverage of the April incident confirmed that attackers used credentials from earlier unrelated breaches to access accounts and exfiltrate names, email addresses, shipping addresses, phone numbers, purchase history, and dates of birth. Payment card data was not exposed, as a third-party provider handles payment processing. The April attack followed a March incident that exposed 15,700 accounts across The North Face and Timberland. It was the fourth credential stuffing incident against VF Corporation brands since 2020. The pattern reflects a structural problem: tens of millions of customer accounts, high password reuse rates, and authentication systems not designed to detect low-and-slow validation campaigns.

The Change Healthcare breach in February 2024 remains the most consequential recent example of credential-based initial access. The ALPHV/BlackCat ransomware group entered UnitedHealth’s Change Healthcare subsidiary through compromised Citrix credentials on a remote-access portal without MFA, as confirmed in Congressional testimony from UnitedHealth’s CEO. The attackers moved laterally through the billing network and deployed ransomware that shut down payment processing for healthcare providers across the United States for weeks. The incident produced a $22 million ransom payment and an estimated $872 million in reported disruption costs in the first quarter alone. One set of valid credentials on one unprotected endpoint caused one of the largest healthcare-sector disruptions in US history.

Detection and Evasion Techniques

Modern credential stuffing campaigns specifically target the detection mechanisms most organisations have deployed. Attackers bypass velocity-based controls that flag high volumes of failed login attempts from a single IP by rotating through residential proxies. They distribute attempts across thousands of IP addresses so each one generates only a handful of requests, staying below alert thresholds. Third-party CAPTCHA-solving services handle challenge pages, some of which are automated via machine learning and others through human labour farms. Tools that emulate legitimate browser environments, including correct JavaScript execution, realistic mouse movement patterns, and authentic request timing, defeat browser fingerprinting.

The MITRE ATT&CK framework categorises credential stuffing under T1110.004 (Brute Force: Credential Stuffing). Defenders should monitor for several specific signals: unusual geographic distributions of authentication requests, spikes in failed logins spread across a wide IP range rather than concentrated at a single source, and successful logins from IP addresses tied to residential proxy services. Account logins from devices or browsers with no prior history on the account also warrant investigation. The Verizon analysis found that credential stuffing accounted for a median of 19% of all authentication attempts across SSO providers, meaning roughly one in five login attempts was not legitimate.

One underappreciated detection gap is the window between credential exposure and organisational awareness. Dark web monitoring tools available to enterprise teams in 2025 make it operationally achievable to track stealer log markets and paste sites for corporate email domains. Many organisations still treat that monitoring as optional rather than a core detection layer. Credentials circulate in combolists for months before the affected organisation becomes aware, and attackers exploit that window systematically.

Regulatory Response

The 23andMe case produced the most visible regulatory outcome tied directly to credential stuffing. A 2023 attack using combolists accessed approximately 6.9 million customer records. The UK Information Commissioner’s Office fined the company £2.31 million for failing to implement adequate security, specifically the absence of mandatory MFA for accounts holding sensitive genetic data. In March 2025, as Wired reported in its coverage of the 23andMe bankruptcy, the company filed for Chapter 11, with the credential stuffing incident and its downstream legal consequences cited as contributing factors. Regulators in the UK and EU now reference the case as evidence that weak authentication controls constitute a material governance failure, not a technical oversight.

CISA’s 2024 guidance on phishing-resistant MFA explicitly identifies credential stuffing as a primary threat driver. It recommends hardware security keys and passkeys using the WebAuthn standard as the only controls that fully eliminate the credential reuse vector. SMS one-time passwords and Time-based One-Time Password (TOTP) codes provide partial protection but remain vulnerable to adversary-in-the-middle (AiTM) interception, a technique increasingly applied against accounts whose value justifies the extra effort.

CISO Playbook

Phishing-resistant MFA enforced across all externally facing authentication endpoints, including VPN portals, SSO providers, and remote desktop services, eliminates the primary path for exploitation. Password screening against known-breach corpora at login and account creation, using services such as the Have I Been Pwned API, removes credentials already circulating in combolists before attackers can validate them. Rate limiting and progressive account lockout on all authentication endpoints, including API login flows that teams frequently overlook, cuts the volume of attempts that reach the validation stage.

Bot detection that analyses behavioural signals, including request timing, device fingerprint consistency, and session cookie behaviour, provides a second line of defence against campaigns that have already bypassed IP-based controls. For organisations on legacy identity infrastructure, a full platform replacement is not the immediate priority. Enforcing MFA on the externally facing authentication layer, regardless of what sits behind it, addresses the highest-risk exposure first. The Change Healthcare incident is the clearest available proof of what one unprotected endpoint costs at scale.

There is no technical solution that eliminates credential stuffing entirely. Password reuse persists, infostealers continue operating at scale, and combolists will keep growing. The practical objective for defenders is to raise the cost of a successful attack on their specific environment above what attackers can profitably tolerate, and to detect the attempts that do succeed before they compound into something worse. Given that 22% of breaches in 2025 started with a valid credential, organisations that treat authentication hygiene as routine maintenance rather than a strategic priority are already in the breach statistics.

Frequently Asked Questions

What is credential stuffing, and how does it differ from brute force?

Credential stuffing uses real username-password pairs stolen from previous breaches and automatically replays them against other services. Brute force generates password guesses from scratch. Stuffing is faster, quieter, and far more effective because it exploits password reuse rather than attempting to crack unknown passwords. A combolist of 10 million verified credentials will outperform any brute-force dictionary attack against the same target.

What is a combolist, and where do attackers get them?

A combolist is a structured file of email-and-password pairs compiled from data breaches, infostealer malware logs, and dark web markets. Attackers source them from initial access broker forums, Telegram channels, and dedicated credential marketplaces. Fresh lists derived from recent infostealer campaigns are the most valuable because their owners have not yet rotated the credentials.

How do attackers bypass rate limiting and CAPTCHA during credential stuffing?

Attackers use residential proxy networks to distribute login attempts across thousands of IP addresses, keeping per-IP request volumes below detection thresholds. CAPTCHA challenges are handled by third-party solving services, either via automated machine-learning methods or by human labour farms. Tools such as OpenBullet and SilverBullet emulate realistic browser behaviour, including JavaScript execution and mouse-movement patterns, to evade browser fingerprinting controls.

Does multi-factor authentication stop credential stuffing?

Phishing-resistant MFA using hardware security keys or passkeys under the WebAuthn standard fully eliminates the credential reuse vector. SMS one-time passwords and TOTP codes reduce exposure but remain vulnerable to adversary-in-the-middle interception. The Change Healthcare breach, which resulted in $872 million in disruption costs, occurred on a Citrix portal with no MFA. Enforcing MFA on every externally facing authentication endpoint is the single highest-impact control available.

What are the most common targets for credential stuffing attacks?

Enterprise SSO portals, VPN gateways, e-commerce account login pages, financial services platforms, and healthcare provider systems are the most frequently targeted. Retirement and superannuation funds have emerged as high-value targets in 2025 because account balances are large, members check accounts infrequently, and MFA enforcement has historically been optional rather than mandatory.

How can organisations detect credential stuffing attacks in progress?

Key signals include spikes in authentication requests distributed across a wide IP range rather than concentrated at a single source, successful logins from residential proxy IP addresses, account access from devices or browsers with no prior history, and unusual geographic distributions in login activity. Continuous monitoring of dark web stealer log markets for corporate email domains provides early warning before credentials are actively exploited. The Verizon 2025 DBIR found that credential stuffing accounts for a median of 19% of all SSO authentication attempts, so baseline volume analysis is also a viable detection layer.

This article covers techniques used by both attackers and defenders for educational and research purposes. The tools and marketplaces described are documented by security researchers and law enforcement agencies.

Most Viewed Posts

Search

Recent Posts

Overview

Features

Explicit Secret Mapping

AWS SSM And Azure Key Vault

CLI, CI/CD And Runtime

Controlled Push

Installation

Usage

Runtime SDKs

Security Relevance

Where It Fits

Conclusion

Related Posts:

Footer

Most Viewed Posts

Search

Recent Posts

Tags