A Triage Framework for Dark Web Alerts That Won't Burn Out Your SOC

Buying a dark web monitoring feed without an aggressive signal filter is just paying an external vendor to flood your ticketing system with unactionable noise. Most “dark web alerts” sent by off-the-shelf threat intelligence platforms are re-hashed combinations of five-year-old credential dumps, consumer email leaks from third-party breaches, or false-positive domain matches scraped from public paste sites.

If your on-call engineer gets paged at 2:00 AM because an employee’s personal account showed up in a 2019 combo list, your triage process is broken. Small security teams need strict, deterministic rules to filter out vendor noise and surface only actionable risk. Here is the operational framework we use to triage dark web intelligence down to the handful of events that actually require human intervention.

Step 1: Strip Out the Recycled Breach Dumps

The single largest source of noise in dark web alerting is the endless recycling of old credential sets. Threat actors routinely bundle old breaches—such as Collection #1-5 or ancient LinkedIn and Adobe leaks—rename the archive, and re-upload it to Telegram channels or BreachForums to build reputation.

Before an alert ever reaches a human analyst or creates a Jira ticket, pass the raw ingest through a strict deduplication and freshness check.

Reject or auto-archive any incoming credential alert that meets any of the following conditions:

• Age threshold: The underlying breach event or paste is older than 30 days, unless accompanied by an active session token.
• Hash collision: The string sha256(username + ":" + password) matches a credential record already logged in your internal threat database.
• Non-corporate identity: The exposed identity uses a personal email domain (gmail.com, yahoo.com) and lacks any technical association with your corporate infrastructure or IP space.

If your monitoring tool alerts on domain mentions rather than full credentials, apply an immediate regex filter. Discard any match occurring inside domain name registrar lists, WHOIS privacy dumps, or broad threat-actor chatter that lacks specific contextual indicators (such as explicit references to your VPN, SSO endpoints, or proprietary software names).

Step 2: Run Alerts Through the Three-Factor Triage Matrix

Once you remove the recycled garbage, evaluate the remaining alerts against three deterministic variables: Asset Reach, Credential State, and Data Freshness.

                           +----------------------------------+
                           | Incoming Dark Web Alert Payload  |
                           +----------------------------------+
                                            |
                                            v
                      +-------------------------------------------+
                      | Is Asset corporate SSO / Cloud / VPN?     |
                      +-------------------------------------------+
                                     /             \
                               Yes  /               \ No
                                   v                 v
            +-------------------------------+    +---------------------------+
            | Is payload an active session  |    | Plaintext password or     |
            | token or stealer log < 7 days?|    | non-SSO SaaS credential?  |
            +-------------------------------+    +---------------------------+
               /                         \                     |
         Yes  /                           \ No                 v
             v                             v           +---------------------+
  +--------------------+         +-------------------+ | TIER 3: LOG & CLOSE |
  | TIER 1: PAGERDUTY  |         | TIER 2: AUTOMATED | | (Silent tracking)   |
  | (Immediate Revoke) |         | JIRA TICKET       | +---------------------+
  +--------------------+         +-------------------+

Factor 1: Asset Reach

• High Reach: Identity Provider (Okta, Azure AD/Entra ID), corporate VPN/ZTNA gateways, AWS/GCP root/IAM credentials, source code repositories (GitHub/GitLab).
• Medium Reach: Non-SSO third-party SaaS tools used by employees (e.g., Canva, Figma, marketing platforms).
• Low Reach: Personal accounts, external public forums, unverified typosquatted domains without active infrastructure attached.

Factor 2: Credential State

• Session Token / Cookie: Raw session state extracted via infostealer malware (RedLine, Vidar, Lumma). This bypasses traditional multi-factor authentication (MFA).
• Cleartext Password: Exposed plain text username/password combination.
• Hashed Password / Metadata: Password hash without cleartext, or a plain mention of a domain without credentials.

Factor 3: Data Freshness

• Critical (< 7 days): Recent infostealer log upload or active dark web forum sale post.
• Moderate (7 to 30 days): Moderately recent paste or marketplace listing.
• Stale (> 30 days): Aged credential set without evidence of active exploitation.

Step 3: Implement Automated Escalation Rules

Using the three-factor matrix, map incoming events directly to standardized triage outcomes. Do not leave these decisions to analyst discretion—program them directly into your SOAR platform, Python triage scripts, or SIEM ingestion rules.

{
  "rule_name": "Infostealer_Session_Cookie_Escalation",
  "conditions": {
    "source_type": "infostealer_log",
    "asset_type": "sso_portal",
    "has_active_session_cookie": true,
    "log_age_days": "<= 7"
  },
  "action": {
    "severity": "CRITICAL",
    "escalation_channel": "pagerduty",
    "automated_playbook": "revoke_user_sessions_and_force_mfa"
  }
}

Tier 1: Immediate Escalation (Page On-Call)

Criteria: An active session cookie, or a cleartext corporate credential matching a High-Reach asset (Okta, Azure AD, VPN), sourced from an infostealer log under 7 days old.

Why: Infostealer malware captures active session tokens. Attackers buy these logs on marketplaces like Genesis or 2Eazy and import cookies directly into anti-detect browsers to bypass MFA entirely.

Action:

1. Fire a high-priority PagerDuty incident.
2. Execute automated session revocation via API (e.g., call Okta’s /api/v1/users/{userId}/lifecycle/revoke_sessions or run Microsoft Graph API revokeSignInSessions).
3. Force a password reset and prompt re-registration of MFA devices.

Tier 2: Queued Ticket (Business Hours Investigation)

Criteria: Cleartext corporate credentials for a Medium-Reach asset (third-party SaaS without SSO), or a stale cleartext password (> 30 days old) matching a corporate identity where MFA is enforced.

Why: The immediate risk of account takeover is lower due to MFA enforcement or isolated SaaS impact, but password reuse across personal and corporate assets remains a risk.

Action:

1. Generate a low-priority ticket assigned to the security queue.
2. Query internal logs (e.g., Identity Provider logs) for successful authentications using the exposed account over the past 7 days.
3. Notify the employee to update credentials on the impacted external service.

Tier 3: Log and Suppress (Zero Human Touch)

Criteria: Password hashes, personal email leaks without corporate infrastructure links, mentions of your brand on dark web forums without actionable context or leaked assets, or breach data older than 30 days without active tokens.

Why: Investigating domain chatter without concrete indicator metrics drains analyst cycles with zero measurable risk reduction.

Action:

1. Ingest into your threat intelligence platform (TIP) or cold SIEM storage for correlation purposes.
2. Mark ticket state as Closed - Informational.
3. Do not send notifications to the SOC or end users.

Step 4: Automate Revocation via API

To keep a small team effective, Tier 1 mitigations must happen in seconds, not the 20 minutes it takes an analyst to log into a dashboard.

If an alert triggers a Tier 1 escalation involving Azure AD (Entra ID), execute an immediate session kill script via PowerShell or Graph API before the analyst even opens the PagerDuty notification:

# Auto-revoke user sessions upon Tier 1 Dark Web Alert match
Param(
    [Parameter(Mandatory=$true)]
    [string]$UserPrincipalName
)

Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"

# 1. Revoke active refresh tokens / session cookies
Write-Host "Revoking active sessions for $UserPrincipalName..."
Revoke-MgUserSignInSession -UserId $UserPrincipalName

# 2. Force password reset on next sign-in
Write-Host "Forcing password reset for $UserPrincipalName..."
Update-MgUser -UserId $UserPrincipalName -PasswordProfile @{
    ForceChangePasswordNextSignIn = $true
}

Write-Host "Mitigation complete for $UserPrincipalName."

Measure the Output That Matters

If your security team is processing more than 10 dark web alerts per week per 1,000 employees, your ingestion filters are too wide.

Review your dark web alerting metrics monthly using two indicators:

1. True Positive Rate for Tier 1: Did the escalated infostealer log or credential actually correspond to an active session or valid password? If this drops below 80%, tighten your freshness and asset-reach constraints.
2. Mean Time to Remediate (MTTR) Tier 1 Alerts: Because Tier 1 events carry valid tokens, MTTR should be under 15 minutes (ideally automated down to under 60 seconds).

Stop treating threat intelligence feeds as a list of tasks for humans to read. Treat raw dark web data as unverified telemetry: filter it aggressively, automate the response for confirmed credentials, and discard the rest silently.