Stealer-as-a-Service & the Credential Ecosystem
After spending several weeks down in the artefacts – browsers, memory, loaders, and evasion – this week we zoom out and look at the economy sitting on top of all of that: Stealer-as-a-Service (SaaS) and the credential ecosystem it feeds.

If you spend enough time looking at infostealer campaigns, you start to see the same pattern:

  • A commodity loader drops yet another “new” stealer family.
  • Logs are exfiltrated to some panel you will never see directly.
  • A few days or weeks later, those logs quietly show up elsewhere as part of a sale, a breach, or a business email compromise.

From the attacker’s perspective, the stealer itself is just a sensor. The real value is in the pipeline of credentials it creates:

  • Browser cookies and tokens that bypass MFA.
  • Passwords that unlock banking, email, and internal portals.
  • Device fingerprints that make fraud checks comfortable saying “yes”.

In this post, we step away from pure DFIR and walk through:

  • How Stealer-as-a-Service is structured and monetised.
  • What actually happens to logs once they leave the infected host.
  • How that pipeline turns into account takeover, fraud, and ransomware.
  • Where defenders can realistically apply pressure with telemetry and controls.

The goal is to give you a mental model that connects the artefacts you are pulling in the lab to the real-world risk they represent outside your environment.

From Single Stealer Family to Stealer-as-a-Service

Historically, infostealers were often developed, operated, and monetised by the same group. Today, many of the big names you see in blogs and reports are commoditised services:

  • The developers maintain the codebase, panels, and infrastructure.
  • Affiliates or buyers purchase access (monthly, per build, or revenue share).
  • Operators handle distribution – malvertising, spam kits, cracked software, loaders, and access brokers.
  • Brokers and shops focus on selling the harvested logs.

This separation of roles offers a few advantages to the attackers:

  • Scale – one stealer codebase, thousands of affiliates.
  • Agility – developers ship quick updates for evasion, new targets, and bug fixes.
  • Resilience – if one distribution method is burned, affiliates can switch to another.
  • Specialisation – each piece of the pipeline is run by people who specialise in that phase: development, ops, distribution, or monetisation.

From a defender’s perspective, this means you are often not fighting a single “group” but dealing with an ecosystem of loosely coupled actors, all sharing the same log pipeline.

The Life of a Log: From Endpoint to Log Shop

To make this concrete, imagine a stealer run on an infected endpoint at time T. What usually happens next?

Collection on the host

Once executed, the stealer:

  • Enumerates installed browsers and applications (Chrome, Edge, Firefox, Brave, Opera; Telegram, Discord; password managers and wallets).
  • Pulls credentials, cookies, autofill data, and history from browser artefacts.
  • Extracts specific application tokens and config files.
  • Collects system fingerprinting data: OS, hardware, timezone, installed AV, IP, domain, language.
  • Often grabs a handful of files matching interesting patterns (desktop screenshots, cryptocurrency wallets, documents).

This all gets combined into a log bundle:

  • Password dump (plaintext or hashed).
  • Cookie/token file or database.
  • System information text file.
  • Sometimes browser history and bookmarks.
  • Optional extras – screenshots, small file grabs, wallet seeds.

Exfiltration to the panel

The stealer then compresses and encrypts the log bundle and sends it to a command-and-control panel. Common patterns:

  • Direct HTTPS POST to a custom panel endpoint.
  • Upload to a compromised website or simple PHP gate.
  • Relayed via CDN, file-sharing services, paste sites, Telegram bots, or custom APIs.

On the panel side, each incoming log is tagged and indexed with:

  • Timestamp of infection.
  • Country / IP / ASN.
  • Browser count and number of credentials.
  • Presence of “premium” apps (banking portals, cloud admin panels, corporate SSO, crypto exchanges).

The log now exists as a discrete item in a panel database, ready to be queried, filtered, and exported.

Distribution and monetisation

From here, logs can be monetised in several ways:

  • Retail log shops
    • Web portals where buyers search for specific domains, countries, or services.
    • Each log is sold individually, often with a built-in browser plugin that helps import cookies and sessions for one-click takeover.
  • Bulk sales to brokers
    • Large bundles of logs sold on a per-thousand basis.
    • Brokers then triage, sort, and re-sell “premium” items at a higher price.
  • Private customers and affiliates
    • Some logs are reserved for operators who focus on specific verticals:
      • BEC (business email compromise).
      • Financial fraud.
      • Crypto theft.
      • Initial access for ransomware or espionage.
  • Internal re-use
    • The same crew that operated the stealer might use logs directly for their own fraud or access operations.

At this stage, your numeric log ID in the panel is effectively a commodity credential package. The same endpoint infection that looked minor on your SOC dashboard can now be weaponised multiple times by different actors.

Why Logs Are So Dangerous: Beyond Plain Passwords

From a purely technical view, a log is “just” a bundle of text and databases. Where it becomes truly dangerous is in the context it provides:

  • Browser cookies and session tokens
    • Allow attackers to bypass MFA and device checks.
    • Let them walk into email, CRM, and admin portals as if they were on the victim’s machine.
  • Remembered passwords and autofill
    • Give direct access to banking, payment gateways, VPNs, and internal tools.
    • Often include credentials for developer tooling and cloud platforms.
  • System fingerprinting data
    • Helps attackers build fraud profiles that look legitimate to risk engines.
    • Enables hardware and IP mimicry when replaying sessions.
  • History, bookmarks, and downloads
    • Reveal which services the victim uses regularly.
    • Expose internal portals and vulnerable web apps that might not be public.
    • Give hints about job role, access level, and company structure.
  • Extra files and screenshots
    • Provide context for fraud (invoice templates, customer lists, internal documentation).
    • Show live Slack or Teams conversations that help social engineering.

All of this means:

A single, seemingly “low impact” endpoint infection can translate into systemic exposure across an organisation’s cloud, email, and financial footprint.

For defenders, the question is no longer “Was this host infected with an infostealer?” but:

  • Which accounts and services are now implicitly compromised?
  • How many of those accounts are shared, privileged, or used for administration?
  • How far did the attacker get before we detected or reset anything?

Linking Logs to Real-World Attacks

In many incident writeups, you will see a loose link between stealer logs and later compromises. In practice, the link can be quite direct:

  • A log contains M365 / Google Workspace cookies and passwords → days later, those accounts are used to send phishing emails to customers and staff.
  • VPN or RDP credentials from a log are used by an initial access broker to sell “RDP to company XYZ, domain admin potential” on an underground forum.
  • Panel data shows multiple corporate domains from the same company → these logs are bundled and pitched specifically to ransomware crews.

Because logs are searchable by domain, attackers can look for:

  • @company.com email addresses.
  • portal.company.com URLs in history or bookmarks.
  • admin, finance, payroll, vpn, jira, git, confluence in URLs and window titles.

The stealer developer does not need to know who you are. The log shop customer will happily filter for you later.

This is one reason why “just clearing the infection on the endpoint” is not enough. Once the log is out there, you are dealing with a separate threat surface that can outlive the original compromise by months.

Defending Against the Credential Pipeline

When you view infostealers as part of a Stealer-as-a-Service ecosystem, your defence strategy broadens beyond just “malware detection”. You are trying to:

  • Reduce the number of logs generated from your environment.
  • Limit their usefulness when they inevitably leak.
  • Shorten the window in which logs can be weaponised.

Let us break that down.

Hardening endpoints and browsers

Fundamentally, you want fewer logs leaving your environment:

  • Application control and script restrictions
    • Lock down which binaries and script engines can run (and from where).
    • Reduce the ability of commodity loaders to execute in the first place.
  • Browser hardening
    • Use managed browser profiles for corporate accounts.
    • Disable or limit “remember passwords” for sensitive portals where possible.
    • Prefer password managers with proper encryption and device binding over browser-native stores.
  • Segregation of identities
    • Avoid mixing personal and corporate accounts in the same browser profile.
    • Use dedicated admin workstations for privileged access, with minimal browsing.
  • Endpoint visibility
    • Ensure your EDR and logging stack actually captures the process chains, file access, and network connections we have discussed in earlier weeks.

Even partial success here reduces the volume and richness of logs that a stealer can extract.

Making logs harder to monetise

Assume some logs will escape. Your next goal is to degrade their value quickly:

  • Strong MFA and phishing-resistant flows
    • FIDO2/WebAuthn and device-bound credentials significantly reduce the value of stolen passwords and cookies.
    • Where you are still using SMS or app-based OTP, tighten session lifetimes and token reuse behaviour.
  • Conditional access and risk-based policies
    • Challenge or block logins when device, IP, or behaviour does not match established patterns.
    • Combine this with user notifications so unexpected approvals are quickly reported.
  • Short-lived sessions and tokens
    • Reduce the time window during which a stolen cookie or token remains valid.
    • Enforce periodic re-authentication for critical actions.
  • Credential hygiene
    • Enforce unique credentials per system; avoid shared accounts wherever possible.
    • Regularly rotate high-value secrets and admin passwords, especially after suspected stealer infections.

The idea is not that your controls will stop every replay attempt, but that they make logs less predictably useful for opportunistic buyers.

Responding to confirmed stealer infections

When you confirm a stealer infection on an endpoint, the response should be wider than just that device:

  • Treat all credentials and cookies from that host as compromised.
  • Reset related passwords and revoke refresh tokens across key services (email, SSO, VPN, finance).
  • Involve the identity team early; this is not just an “endpoint” issue.
  • Assess whether the infected user had elevated access or access to shared accounts.
  • Monitor for suspicious logins from new devices or locations in the days and weeks after.

Where possible, build standard operating procedures for “stealer on corporate endpoint” incidents, so you are not improvising every time.

Telemetry That Actually Helps

Earlier weeks of this series discussed artefacts and telemetry at the endpoint and network level. In the Stealer-as-a-Service context, certain signals become particularly important:

  • Process and memory telemetry
    • Identifying loader behaviour, injection into browsers, and access to browser artefacts.
    • Detecting stealer families via YARA (on disk or in memory).
  • Browser and application logs
    • Failed vs successful logins.
    • New devices or locations.
    • Unusual OAuth grant activity or app consent flows.
  • Cloud identity and access logs
    • M365/Azure AD, Google Workspace, Okta, etc.
    • Detection of impossible travel, atypical access patterns, and risky sign-ins.
  • Fraud and payment system telemetry
    • Changes to supplier bank details.
    • New payees created shortly after logins from unusual devices.
    • Patterns of invoice tampering or mailbox rules pointing to BEC.

When you connect the dots, you want to be able to say:

“We saw an infostealer infection on host X at time T. Within 24 hours, we saw new logins from unfamiliar devices to accounts A, B, and C. We blocked or challenged those logins and forced password resets and token revocations.”

This is the operational reality of defending against Stealer-as-a-Service: not perfection, but speed and coverage in detecting downstream abuse.

Intelligence Value: Tracking Panels, Logs, and Buyers

Beyond immediate defence, stealer logs and panels are rich sources of threat intelligence:

  • Tracking panel domains and infrastructure over time can reveal:
    • The evolution of a specific stealer family.
    • Reuse of hosting providers, certificates, and passwords.
    • Links to other tools, loaders, and infrastructure.
  • Looking at log shop inventories (when they leak or are indexed) can show:
    • Which countries and industries certain actors target.
    • Whether your organisation or sector is already present in existing dumps.
    • Overlaps between different stealer families and the same log brokers.
  • Analysing leaked log bundles from previous cases gives insight into:
    • Which portals and internal sites consistently show up across victims.
    • Common patterns of poor credential hygiene.
    • How long logs tend to sit between collection and use.

If you are in a position to run your own honeypots or sinkholes, you can even observe stealer operators and buyers in near real time, turning the ecosystem back on itself.

The key is to make sure this intelligence does not just live in your notes but feeds back into:

  • Detection engineering (new YARA, Sigma, EDR content).
  • Awareness campaigns (explaining to users why personal browsing on work machines is risky).
  • Policy changes (browser and identity hardening, application control).

Bringing It All Together

Over the last few weeks, this series has moved from individual artefacts to broader tradecraft:

  • We started with specific malware families and loaders.
  • We explored cloud artefacts, browser credentials, and Windows forensics.
  • We dug into memory forensics and evasive loader behaviour.
  • This week, we stepped back to view the Stealer-as-a-Service ecosystem those artefacts feed.

The big takeaway is that infostealers are not isolated events. They are input devices for a credential economy that:

  • Converts single endpoint infections into long-term access.
  • Powers fraud, BEC, ransomware, and data theft across sectors.
  • Is resilient precisely because it is modular – developers, operators, brokers, and buyers can be swapped in and out.

For defenders, this means:

  • Treating stealer infections as identity compromises, not just malware alerts.
  • Designing controls that reduce log volume, degrade log value, and shorten the window of usefulness.
  • Using the insight you gain from DFIR and lab work to inform practical hunting, detection, and hardening in production.