Hunting from Stealer-Log Marketplace Indicators

Infostealer output is traded as “logs”: one archive per infected machine, containing saved credentials, cookies, autofill data, system details and often a screenshot. Defenders can use exposure data derived from those logs to find compromised accounts and infected devices before the attacker uses them. Collecting this data raises legal and ethical questions, so use lawful channels only.

Signals at a Glance

Sourcing and Handling

• Use a commercial exposure-monitoring provider, a national CERT or a breach-notification service that handles collection lawfully. Do not buy from criminal marketplaces yourself; the legal exposure and the funding of criminals are not worth it. Involve counsel before you handle raw logs.
• Handle the data as sensitive: it contains real third-party credentials. Limit access, store hashes where you can, and delete on schedule.
• Treat the log date as the earliest the credential could have been abused, and review sign-ins from that date onward.

Load the exposed accounts into a watchlist and join them to sign-in logs. The aim is not just a reset but finding use of the credential since the infection date:

// Microsoft Sentinel (KQL) - exposed accounts with successful sign-ins from unfamiliar IPs
let Exposed = _GetWatchlist('stealer_exposed')
    | project UserPrincipalName = tolower(Account), ExposedAt = todatetime(ExposureDate);
let Known = SigninLogs
    | where TimeGenerated between (ago(90d) .. ago(7d)) and ResultType == 0
    | summarize KnownIPs = make_set(IPAddress, 200) by UserPrincipalName = tolower(UserPrincipalName);
SigninLogs
| where ResultType == 0
| extend UserPrincipalName = tolower(UserPrincipalName)
| join kind=inner Exposed on UserPrincipalName
| where TimeGenerated >= ExposedAt
| join kind=leftouter Known on UserPrincipalName
| where isnull(KnownIPs) or not(set_has_element(KnownIPs, IPAddress))
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, UserAgent, ExposedAt
// tune/validate: watchlist column names are yours; exclude mobile carrier and VPN ranges

Mapping the Log to a Device

A log header normally carries the machine name, OS username, public IP, locale and time. Match those against your inventory to find the infected device, which may be unmanaged or personal. A structured working record keeps the investigation consistent:

{
  "exposure_id": "<case reference>",
  "source": "<monitoring provider or CERT>",
  "log_date": "<YYYY-MM-DD>",
  "account": "<user@yourdomain.example>",
  "host_metadata": {
    "machine_name": "<from log header>",
    "os_user": "<from log header>",
    "public_ip": "<from log header>"
  },
  "matched_asset": "<EDR device id or 'unmanaged'>",
  "actions": ["password reset", "sessions revoked", "mfa re-enrolled", "device isolated"],
  "follow_up_review_until": "<YYYY-MM-DD>"
}

• If the matched device is unmanaged or personal, require a clean device and a credential reset before the account regains access.
• Feed confirmed infection details (loader family, path, timestamps) back into detections; this is how exposure data improves coverage.
• Expect partial matches: logs can be stale, and passwords may already have been rotated. Verify before escalating.