Initial Access Brokers & Ransomware Chains
Over the last few weeks we have followed commodity malware from the endpoint up: stealers, loaders, evasion, and Stealer-as-a-Service. This week we keep zooming out and look at who is buying that access and what they do with it – specifically, Initial Access Brokers (IABs) and ransomware affiliate chains.

By now the pattern should feel familiar:

  • A user clicks something they should not.
  • A loader runs, a stealer or RAT lands, logs or beacons leave the network.
  • For a while, nothing obvious happens.
  • Weeks or months later, the same organisation appears in a ransomware note or extortion leak.

On paper, these can look like separate events: “phishing incident in April” vs “ransomware in July”. In reality, there is often a straight line between them, with several distinct actors in the middle:

  • Commodity malware operators collecting logs and initial shells.
  • Initial Access Brokers packaging those footholds and selling them on.
  • Ransomware affiliates buying access, escalating privileges, and deploying lockers.
  • Data-theft crews exfiltrating and staging terabytes for double or triple extortion.

This post unpacks that chain step by step and focuses on:

  • How Initial Access Brokers work and what they actually sell.
  • How ransomware affiliates typically operate once they buy access.
  • Where your previous work on loaders, stealers, and credentials fits into this picture.
  • Which telemetry, controls, and playbooks give you a realistic shot at disrupting the chain before you hit “all files encrypted.”

The aim is to turn “ransomware” from a scary end state into a series of detectable stages that map back to things you can influence today.

What Is an Initial Access Broker?

At a high level, an Initial Access Broker is exactly what the name suggests: a middleman who specialises in getting into networks and selling that access onward.

Instead of running full campaigns end-to-end, IABs focus on:

  • Discovering and exploiting weak points:
    • Vulnerable VPNs and remote access portals.
    • Public-facing web apps and misconfigured services.
    • Leaked credentials, reused passwords, and stealer logs.
  • Turning those weak points into reliable footholds:
    • Valid RDP or VPN credentials.
    • Web shell access.
    • Domain user sessions in cloud or on-prem environments.
  • Packaging and advertising that access:
    • “US manufacturing company – revenue $200M – RDP access to AD domain users”
    • “EU law firm – 500 seats – full M365 tenant access via global admin creds”
  • Selling to buyers who are primarily interested in monetising the access, not in getting it.

For ransomware affiliates, IABs provide a shortcut: instead of running broad opportunistic campaigns to find one interesting victim, they can shop for access that matches their playbook and risk appetite.

From a defender’s point of view, this splits the threat into distinct phases:

  • Phase 1: someone finds a way in and establishes low-to-medium privilege access.
  • Phase 2: that access is sold or handed off.
  • Phase 3: a different crew handles post-compromise activity and monetisation.

Understanding that separation is key, because the artefacts and signals you see in Phase 1 are often what give you the best chance to stop Phase 3.

Sources of Initial Access

Initial Access Brokers do not magically materialise domain admin sessions. They rely heavily on the same building blocks we have already covered:

1. Stolen credentials and stealer logs

The Stealer-as-a-Service world from Week 9 is effectively a firehose of credentials and tokens. IABs will:

  • Buy stealer logs that contain:
    • VPN, RDP, Citrix, and SSO portal credentials.
    • Corporate email and admin panel logins.
    • Browsing history and bookmarks that reveal internal URLs.
  • Triaging logs to find:
    • Domains and companies that meet their “size threshold” (e.g. > 100 employees, certain industries).
    • Credentials linked to high-value roles (IT, finance, executives).
  • Testing and upgrading access:
    • Turning stolen browser sessions into real logins on live infrastructure.
    • Registering their own devices as “trusted” where device-based controls are weak.
    • Dropping lightweight implants or web shells on reachable hosts.

In many cases, the original stealer infection and the IAB’s activity will be separated by weeks, and the only link is an infostealer incident that might have been dismissed as “just another malware alert”.

2. Vulnerable external services

IABs also hunt for classic perimeter weaknesses:

  • Unpatched VPN appliances and edge devices with known RCE or auth bypass bugs.
  • Single-factor RDP exposed to the internet.
  • Old Citrix or remote app gateways with existing exploits.
  • Misconfigured identity providers or SSO portals.

They combine these with:

  • Credential stuffing using stealer logs and leaked datasets.
  • Simple password spraying with industry-themed or location-themed guesses.
  • Exploit kits targeting specific appliances (Pulse, Fortinet, Citrix, etc.).

The output is the same: stable, repeatable access that can be logged into on demand and demonstrated to a buyer.

3. Web application and CMS compromise

For some buyers, access to a high-traffic website or CMS is just as valuable as a VPN login:

  • Web shells on corporate portals and blogs.
  • Compromised WordPress/Joomla/Drupal admin accounts.
  • API keys with read/write access to customer data.

These are often sold separately, but can still serve as stepping stones into internal networks or cloud environments.

Packaging & Selling Access

Once a broker has one or more footholds, they treat them like inventory. On many underground forums and marketplaces you will see:

  • Auction-style posts
    • Starting bid for access to a specific organisation, with a “buy now” price.
    • High-level description: country, industry, turnover, employee count.
    • Access details summarised: RDP, VPN, Citrix, M365, ERP, etc.
    • Sometimes rough indicators of privileges (“local admin on X servers”, “domain user”, “M365 global admin”).
  • Bulk or private deals
    • Repeat customers (often ransomware crews) get access to curated lists of victims via private channels.
    • Brokers may offer a menu of opportunities per geographic region or sector.
  • Service models
    • Some IABs run closer to a “managed service”: they keep access warm, run basic recon, and hand over detailed network maps to the buyer.
    • Others simply supply raw credentials and let the buyer figure it out.

The price depends on factors such as:

  • Turnover and brand recognition of the victim.
  • Type and level of access (domain admin vs regular user; on-prem vs cloud).
  • Sector sensitivity (healthcare, legal, finance tend to command higher prices).
  • Freshness of access (recent logins vs stale credentials).

In all cases, the outcome is similar: your environment can be listed and sold to multiple interested crews without you ever seeing a single brute-force attempt, because the initial foothold came from a stealer log or direct exploit, not from noisy guessing.

From Access to Ransomware: Common Affiliate Playbooks

Once a ransomware affiliate buys access, the playbook tends to look familiar across many families. Details vary, but the phases are consistent.

Phase 1: Stabilise and verify access

The affiliate will first make sure the broker’s claims are real:

  • Log into VPN, RDP, or cloud portals.
  • Confirm privileges and environment (AD domain, number of hosts, security tools).
  • Plant one or more persistence mechanisms that are under their direct control:
    • New local or domain accounts.
    • Scheduled tasks or services.
    • Web shells, backdoored line-of-business apps, or management agents.

At this stage, activity might look like:

  • Logins from new IPs or countries via valid credentials.
  • Creation of strange scheduled tasks or services on one or two machines.
  • On cloud platforms, new devices enrolled or app passwords created for legacy protocols.

Phase 2: Reconnaissance and privilege escalation

Once they trust their foothold, affiliates start mapping the environment:

  • Enumerating AD structure, GPOs, and trust relationships.
  • Searching for file shares, backup servers, and critical applications.
  • Hunting for credentials in memory, LSASS, browsers, and configuration files.
  • Leveraging standard tools (AD management consoles, PowerShell, WMI) and off-the-shelf frameworks (Cobalt Strike, Sliver, etc.).

Privilege escalation can involve:

  • Abusing misconfigured services and scheduled tasks for local privilege escalation.
  • Re-using local admin passwords across machines.
  • Dumping LSASS and using extracted hashes/tokens for lateral movement.
  • Exploiting edge devices and management consoles (RMM tools, backup software) that already run with high privileges.

From a telemetry perspective, this tends to light up as:

  • Unusual use of administrative tools from non-admin workstations.
  • Sudden spikes in LDAP queries or AD enumeration commands.
  • Remote execution tools (psexec, WMI, WinRM) used between unusual pairs of hosts.
  • Security tooling tampering (disabling services, uninstalling agents, editing GPOs).

Phase 3: Lateral movement and staging

With elevated privileges, affiliates spread laterally to:

  • File servers, database servers, and hypervisors.
  • Backup infrastructure and DR appliances.
  • Domain controllers and management servers.

They may deploy:

  • C2 beacons or agents on key servers.
  • Custom scripts for inventory and data collection.
  • Tools to access cloud tenants from on-prem or vice versa.

They will also prepare for:

  • Data exfiltration: staging large volumes of files to a central location.
  • Encryption: identifying where to deploy lockers for maximum impact.

The more “professional” crews will:

  • Keep noisy tools away from domain controllers and critical systems until the last possible moment.
  • Re-use internal IT paths (remote management tools, jump servers) to avoid detection.
  • Blend into normal admin workflows where possible.

Phase 4: Data theft and encryption

The final stage combines mass data exfiltration with ransomware deployment:

  • Large file transfers to attacker-controlled servers or cloud storage.
  • Deployment of the ransomware payload via:
    • GPOs or logon scripts.
    • RMM tools already deployed in the environment.
    • Custom orchestration scripts using PsExec, WinRM, or proprietary agents.
  • Mass encryption events beginning within minutes across many hosts.

By this point, the defenders’ options are limited to:

  • Containing blast radius (network isolation, shutting down services).
  • Restoring from backups (if those have not been compromised).
  • Managing the legal, regulatory, and business fallout.

The important thing is that Phase 4 is the end of a long chain, not the start. Your best opportunities to break the attack were earlier – often at the access stage sourced from stealer logs and IAB deals.

Where Earlier Weeks Plug In

Everything you have explored in Weeks 6–9 feeds directly into this IAB and ransomware story:

  • Browser & credential artefacts (Week 6)
    • Explain why stealer logs are so valuable to IABs.
    • Show which credentials (VPN, SSO, admin panels) are likely to leak from a single infected endpoint.
  • Memory and loader forensics (Weeks 7–8)
    • Give you the technical insight needed to confidently label activity as stealer/loader behaviour.
    • Provide configs, C2s, and artefacts that feed into detections and IR playbooks.
  • Stealer-as-a-Service ecosystem (Week 9)
    • Bridge the gap between endpoint infections and log shops where IABs shop for victims.
    • Emphasise that stealer incidents are often pre-ransomware events, not isolated malware cases.

When you see an infostealer infection now, the question to ask is:

“If this log ends up in an IAB’s inventory, what could they credibly sell access to – and what will the ransomware crew be able to do with it?”

That mindset shift – from “clean the host” to “protect the identity and access surfaces” – is central to defending against modern ransomware.

Disrupting the Chain: Practical Levers

You cannot control what happens on underground forums, but you can influence the value and longevity of the access being sold.

1. Treat stealer and loader incidents as identity events

When stealer activity is confirmed:

  • Force password resets for affected accounts (local and cloud).
  • Revoke active sessions and refresh tokens where possible.
  • Invalidate trusted devices and app passwords tied to those accounts.
  • Avoid re-using the same credentials in new accounts.

Document this as a clear runbook so that:

  • SOC and IR teams do not stop at “malware removed”.
  • Identity and access teams are consistently pulled in.
  • Residual access in IAB inventories is degraded quickly.

2. Make external access harder to resell

Focus on where IABs derive value:

  • VPN and remote access
    • Enforce strong MFA, preferably phishing-resistant where feasible.
    • Restrict which accounts can authenticate remotely.
    • Monitor for new device enrolments, unusual client versions, or strange geo/ASN patterns.
  • Cloud admin and high-privilege roles
    • Minimise the number of standing global admins.
    • Use just-in-time elevation where possible.
    • Log and alert on changes to conditional access, MFA settings, and app consent.
  • RDP and legacy protocols
    • Avoid exposing RDP directly to the internet; use gateways and brokers instead.
    • Disable legacy authentication where possible.
    • Watch for brute-force behaviour, but remember that valid stolen credentials bypass rate limits – so look for unusual geo/device instead.

The idea is to make the journey from “stolen credential” to “stable, sellable access” as fragile and noisy as possible.

3. Hunt for early signs of IAB and affiliate activity

Even if credentials are stolen, the broker and buyer still need to touch your environment to verify and upgrade access. Telemetry to focus on includes:

  • New logins from unusual locations shortly after stealer incidents.
  • Logins to VPN/SSO portals with old or dormant accounts.
  • Creation of new local or domain admin accounts with odd naming conventions.
  • Scheduled tasks, services, or run keys created by accounts that typically do not perform admin work.
  • Sudden spikes in AD enumeration, share discovery, and lateral movement tools.

Where possible, tie detections back to the timeline of known stealer infections:

  • “We saw a Lumma infection on host X on May 3rd.”
  • “On May 8th and May 12th, we saw logins from unfamiliar IPs to this user’s VPN account.”
  • “Those logins were used to create a new local admin on server Y.”

This temporal correlation is often what turns a generic anomaly into a high-confidence IAB or affiliate lead.

4. Build playbooks for “suspected IAB access”

Rather than waiting for ransomware to appear, design specific responses for situations where you suspect access is in play:

  • If you see strong signals of IAB-style behaviour but no encryption yet:
    • Contain affected accounts and hosts.
    • Perform a targeted sweep for web shells, new admin accounts, and persistence.
    • Reset credentials and tokens broadly where necessary.
    • Engage legal and leadership early – this is not “just a SOC ticket”.
  • Capture and preserve evidence:
    • Keep logs, memory dumps, and disk images where appropriate.
    • These will be invaluable if you later discover that the same environment was being actively marketed or re-sold.

The goal is to treat “someone is trying to turn this environment into inventory” as a critical incident in its own right.

Ransomware Without Encryption: Data Theft and Extortion

One final wrinkle is worth calling out: not every “ransomware” operation looks like classic encryption plus note. Increasingly, crews will:

  • Skip encryption altogether and focus purely on data theft + extortion.
  • Threaten to publish sensitive data or notify regulators/customers.
  • Use stolen M365/Gmail access to send extortion emails from internal accounts.

In these cases, the IAB and affiliate chain still exists, but the monetisation path leans more on data exposure than availability loss.

For defenders, this reinforces a recurring theme:

  • Identity and data access controls matter as much as backup and restore.
  • A single set of stolen admin credentials can be just as catastrophic as encrypted file servers.
  • The same stealer logs feeding classic ransomware can fuel pure extortion plays.

Your detection and response posture should not rely solely on spotting encryption behaviour; it should also focus on unusual data access and exfiltration.

The big picture is that modern ransomware is not a single piece of malware; it is a workflow that stretches from a user clicking a link to an underground auction listing to an affiliate staging lockers on your domain controllers.

For practitioners, the practical takeaways are:

  • Treat stealer and loader infections as the start of an identity incident, not the end of a malware one.
  • Build controls that make it harder to convert stolen credentials into durable, sellable access.
  • Watch for IAB and affiliate behaviours long before encryption day – weird logins, new admins, enumeration, and lateral movement.
  • Use DFIR, memory forensics, and threat intel not just to write reports, but to shape detections, playbooks, and hardening that interrupt the chain.