Skip to content

Instantly share code, notes, and snippets.

@joswr1ght
Created January 16, 2026 14:37
Show Gist options
  • Select an option

  • Save joswr1ght/c81d42190d2c6c2439bc398d886fcde2 to your computer and use it in GitHub Desktop.

Select an option

Save joswr1ght/c81d42190d2c6c2439bc398d886fcde2 to your computer and use it in GitHub Desktop.
IR Playbook Example for Infostealer and Cloud Exfiltration EOI

IR Playbook - Windows Infostealer With Cloud Storage Exfiltration

Overview

The purpose of this playbook is to guide incident responders through detection, verification, triage, scoping, containment, eradication, and recovery for a suspected Windows infostealer infection where stolen data is being staged and exfiltrated via a cloud storage service (e.g., OneDrive/SharePoint, Dropbox, Google Drive, Box). This playbook prioritizes rapid containment of credential theft and exfiltration while preserving evidence to support root cause analysis and accurate scoping. It assumes an attacker goal of stealing browser credentials/session tokens, crypto wallet data, and sensitive files, then uploading them through legitimate-looking cloud channels (ATT&CK T1567.002). oai_citation:0‡MITRE ATT&CK

Description

This event involves one or more Windows endpoints exhibiting infostealer behavior (suspicious process execution, unusual browser data access, new persistence artifacts, credential access activity) along with indications of outbound data transfer to cloud storage. The EOI may originate from EDR telemetry, proxy/DNS/firewall logs, abnormal user sign-ins, cloud audit logs showing unusual file uploads, or user-reported symptoms (unexpected MFA prompts, account lockouts, “new device” sign-ins). Typical infostealers are commodity malware-as-a-service families with rapid delivery and frequent infrastructure churn, often used to bootstrap follow-on access. oai_citation:1‡Microsoft

Dynamic Approach to Incident Response

Apply these steps to detect, verify and triage, scope, contain, eradicate, and recover from the incident.

Detect Steps

Apply the following steps to investigate the Event of Interest (EOI). Use the information provided by the user to guide the investigation.

Start by capturing the “minimum viable facts” so your investigation doesn’t drift. You’re trying to answer: which hosts, which users/identities, which cloud storage provider, what data, and when.

Inputs to gather immediately (answer what you can now):

  • Which telemetry exists: EDR (Defender/MDE/CrowdStrike), SIEM, web proxy, DNS logs, firewall logs, M365/Entra audit logs, CASB?
  • Cloud storage in scope: OneDrive/SharePoint, Dropbox, Google Drive, Box, others?
  • Scope hints: single host/user or multiple? any VIPs? any regulated data?

Then perform endpoint-centric detection on the suspect host(s):

  • Confirm basic host and logged-on user context:

    hostname
    whoami
    quser
    ipconfig /all
    Get-Date
  • Identify suspicious processes, command lines, and parent/child relationships (look for LOLBins, weird paths, one-off binaries, “single-use” droppers):

    Get-CimInstance Win32_Process |
      Select-Object ProcessId, ParentProcessId, Name, CommandLine |
      Sort-Object Name | Out-Host
    
    # Quick hit list: user profile execution paths
    Get-CimInstance Win32_Process |
      Where-Object { $_.CommandLine -match 'AppData|Temp|Downloads|\\Users\\' } |
      Select-Object ProcessId, ParentProcessId, Name, CommandLine
  • Enumerate persistence (infostealers commonly use Run keys, scheduled tasks, services, WMI event subscriptions):

    # Run/RunOnce keys
    reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
    reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
    reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce"
    reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce"
    
    # Scheduled tasks
    schtasks /query /fo LIST /v | more
    
    # Services (non-Microsoft, weird binary paths)
    Get-CimInstance Win32_Service |
      Select-Object Name, State, StartMode, PathName |
      Where-Object { $_.PathName -and $_.PathName -notmatch '\\Windows\\System32\\' } |
      Sort-Object Name
    
    # WMI event subscriptions (if present, treat as high-suspicion)
    Get-CimInstance -Namespace root\subscription -Class __EventFilter -ErrorAction SilentlyContinue
    Get-CimInstance -Namespace root\subscription -Class CommandLineEventConsumer -ErrorAction SilentlyContinue
    Get-CimInstance -Namespace root\subscription -Class __FilterToConsumerBinding -ErrorAction SilentlyContinue
  • Identify active network connections and likely exfil tooling (rclone, curl/wget ports, sync clients, unusual TLS destinations):

    # Connections with owning process
    Get-NetTCPConnection -State Established |
      Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess |
      Sort-Object RemoteAddress
    
    # Map PID -> process/command line
    $pids = (Get-NetTCPConnection -State Established).OwningProcess | Sort-Object -Unique
    Get-CimInstance Win32_Process |
      Where-Object { $pids -contains $_.ProcessId } |
      Select-Object ProcessId, Name, CommandLine
  • Look for “staging” directories and recent file bursts (common before upload):

    # Recent files in common staging locations
    $paths = @("$env:USERPROFILE\Downloads", "$env:TEMP", "$env:APPDATA", "$env:LOCALAPPDATA")
    foreach ($p in $paths) {
      "=== $p ==="
      Get-ChildItem -Path $p -Recurse -ErrorAction SilentlyContinue |
        Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-2) } |
        Sort-Object LastWriteTime -Descending |
        Select-Object FullName, Length, LastWriteTime -First 200
    }
  • Capture quick security log “signals” (useful even without Sysmon):

    • Process creation auditing is often absent by default; still pull what you have:
    # Security log quick skim for the last 24h
    $since = (Get-Date).AddHours(-24)
    Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=$since} |
      Select-Object TimeCreated, Id, ProviderName, Message |
      Select-Object -First 200 | Out-Host

CTI enrichment as you identify candidate indicators (hashes, domains, IPs, file names, mutexes) should begin during detection to quickly separate commodity noise from known active campaigns. Use VirusTotal, Talos, and OTX for rapid pivoting and related IOC discovery. oai_citation:2‡VirusTotal

Verify Steps

Verify the event to confirm it is an incident. Use the steps here, augmented with other insights that you collect:

Verification is about proving two things: (1) the endpoint is running infostealer behavior and (2) data movement to cloud storage is abnormal and likely unauthorized. You do not need a full reverse engineering answer before you contain—infostealers are “credential theft + export + upload” problems, and time works against you.

  • Confirm malware execution and persistence with higher-fidelity tooling where available:
    • If you have Sysinternals available, use it to validate suspicious processes and file/registry activity. oai_citation:3‡Microsoft Learn
    • Validate suspicious binaries:
      • Check signer, file path, compile time anomalies, and hash reputation (VT/Talos/OTX).
  • Prove credential access / browser data theft indicators:
    • Look for access to browser credential stores (Chrome/Edge “Login Data”, “Local State”), cookie DBs, and password vault-related files.
    • Look for LSASS access attempts, credential dumping-like behavior, or abnormal token usage (common in follow-on activity). oai_citation:4‡Microsoft
  • Confirm exfiltration via cloud storage:
    • Endpoint: correlate a process with outbound connections during the suspected window.
    • Network: proxy/firewall logs for spikes to cloud storage endpoints from the host.
    • Cloud: audit logs showing unusual uploads, mass sharing, or new OAuth app grants (if the cloud provider is M365/Google/Dropbox).

If any of these are true, treat it as confirmed incident requiring containment:

  • Unknown binary executed from user-writable path and persistence established.
  • Evidence of browser data harvesting or credential/token access.
  • Abnormal volume of uploads or new cloud sessions/devices closely following suspected execution.

Triage Steps

Apply triage analysis with a company decision maker to prioritize the incident response effort based on the following criteria:

Triage determines urgency, blast radius, and what you can safely disrupt. For infostealers, the decision-maker needs a clear view of credential exposure risk, sensitive data exposure risk, and operational impact of isolation/resets.

Business Impact and Exposure

This is the “what could be lost” conversation, grounded in evidence you can defend.

  • Identify impacted user(s): role, privilege level, access to sensitive systems/data
  • Determine whether regulated data may be involved (PII/PHI/PCI, source code, finance)
  • Assess whether the endpoint is used for privileged access (admin tools, VPN, cloud consoles)
  • Decide whether to invoke breach counsel / regulatory workflow based on evidence of exfil

Operational Priorities

This is the “what do we do first” list—fast actions that reduce harm.

  • Isolate the endpoint(s) (network containment) if credible infostealer indicators exist
  • Rapidly disable or reset credentials for the impacted user(s) (prioritize privileged accounts)
  • Invalidate sessions/tokens in identity providers and key SaaS platforms (where possible)
  • Preserve evidence before destructive actions when feasible (but don’t delay containment if exfil is active)

Communications and Stakeholder Handling

Infostealer incidents often expand into identity compromise. Set expectations early.

  • Establish a single incident channel and timeline owner
  • Notify IAM / M365 / cloud team to prepare session revocations and audit log pulls
  • Notify legal/privacy if exfiltration is plausible and data classes are unknown

Scoping Steps

Evaluate the system to identify Indicators of Compromise (IOCs):

Scoping is about expanding from “one bad host” to “who else is touched.” Infostealers spread through shared credentials, reused passwords, browser sync, and token/session replay rather than classic worming.

Primary IOC categories to collect from the first host:

  • File hashes (SHA256 preferred), file paths, signer info
  • Process names + full command lines + parent process
  • Persistence artifacts (Run keys, scheduled tasks, services, WMI subscriptions)
  • Network indicators: domains, SNI/JA3 if you have it, IPs, URLs, user-agents
  • Cloud indicators: app IDs, OAuth consent events, new devices, session locations, upload targets

Host hunting ideas (Windows fleet):

  • Search for the same hash/path across endpoints (EDR “file prevalence”)
  • Hunt for execution from user-writable paths:
    • %AppData%, %LocalAppData%, %Temp%, %Downloads%
  • Hunt for common exfil utilities and patterns:
    • rclone, winscp, curl, powershell -enc, certutil, suspicious mshta, wscript/cscript
  • Hunt for unusual scheduled tasks and Run key entries with recent creation times

CTI pivoting:

Use the observed IOCs to check other systems in the environment for similar indicators. This can include other endpoints used by the same user, endpoints in the same department (shared installers/docs), systems where the user has authenticated recently (VPN, VDI, jump boxes), and cloud/SaaS tenants where the user’s sessions or OAuth grants could be replayed.

Contain Steps

Apply containment actions to prevent further unauthorized access:

Containment for infostealers is a race: stop exfiltration and stop credential reuse. Contain at multiple layers (endpoint, identity, network, cloud storage), because any single control can miss token replay.

  • Endpoint containment (preferred order when possible):

    • Isolate host from network using EDR isolation, or pull network cable / disable Wi-Fi (preserve power state if you plan memory capture).
    • Block execution of the identified binary/hash across the fleet via EDR.
    • If active exfil is observed, block outbound to the specific cloud storage endpoints at proxy/firewall temporarily (surgical blocks; avoid breaking legitimate business if the same service is heavily used).
  • Identity containment (high priority):

    • Force password reset for the impacted user(s) and any accounts whose credentials may be stored on the device (browser-saved, RDP clients, password managers).
    • Revoke active sessions/tokens in your IdP and key SaaS platforms (M365, VPN, EDR console, Git providers).
    • If the user had privileged roles, treat as privileged credential exposure and rotate secrets/keys they could access.
  • Cloud storage containment:

    • Identify the destination service (OneDrive/SharePoint, Dropbox, Google Drive, Box).
    • Temporarily restrict sharing/external collaboration for the impacted user if evidence supports it.
    • Quarantine or preserve uploaded artifacts (do not delete until evidence is preserved and legal/privacy approves).

Additional Monitoring

Use additional monitoring and logging capabilities to enhance visibility and response:

Additional monitoring should focus on (1) repeat execution, (2) follow-on access using stolen creds, and (3) continued uploads or data staging.

  • Enable or increase:
    • EDR telemetry retention/export for the affected host(s)
    • Proxy logs with URL categories and upload volume metrics
    • DNS query logging (client IP + query + response)
  • If you can deploy it quickly:
    • Sysmon with a known-good configuration (process create, network connect, registry, file create) to improve visibility for ongoing hunting
  • Monitor cloud audit signals:
    • New device sign-ins for impacted user
    • Unusual geography / impossible travel patterns
    • Mass download/upload or mass sharing events
    • New OAuth consents or app grants

Data Collection

Gather and preserve pertinent evidence to use for subsequent analysis tasks:

Evidence matters because infostealers are often “quick-hit” and you may need to prove what data was accessed and where it went. Prioritize capturing volatile data if you suspect active credential/token material in memory, then collect disk/log artifacts.

On the endpoint (preserve before cleaning):

  • Record system state (time, hostname, user, network config)
  • Collect process + network + persistence outputs (from Detect section) into a case folder
  • Acquire memory (if feasible) using WinPmem (recommended by Volatility docs) and analyze with Volatility3. oai_citation:8‡volatility3.readthedocs.io
  • Collect key artifacts:
    • Windows Event Logs: Security, System, Application, PowerShell (if enabled)
    • Browser artifacts (Chrome/Edge user profiles) with legal approval
    • Prefetch, Amcache, Shimcache where available (tooling dependent)
    • Scheduled task XMLs, Run keys exports, WMI subscription info

Example: export event logs quickly:

$dest = "C:\IR\Collect\$(hostname)_$(Get-Date -Format yyyyMMdd_HHmmss)"
New-Item -ItemType Directory -Path $dest -Force | Out-Null

wevtutil epl Security "$dest\Security.evtx"
wevtutil epl System "$dest\System.evtx"
wevtutil epl Application "$dest\Application.evtx"

# If present:
wevtutil epl "Microsoft-Windows-PowerShell/Operational" "$dest\PowerShell-Operational.evtx"
wevtutil epl "Microsoft-Windows-Sysmon/Operational" "$dest\Sysmon.evtx"

Volatility3 analysis starter set (run on your analysis workstation):

# Identify profile / basic info
python3 vol.py -f memory.raw windows.info

# Processes, command lines, network
python3 vol.py -f memory.raw windows.pslist
python3 vol.py -f memory.raw windows.pstree
python3 vol.py -f memory.raw windows.cmdline
python3 vol.py -f memory.raw windows.netscan

(Adjust plugins based on the image and OS version; follow the Volatility3 Windows tutorial flow.) oai_citation:9‡volatility3.readthedocs.io

Network/cloud logs to preserve:

  • Proxy/firewall logs for the host/user around the execution window
  • DNS logs for the host/user
  • Cloud storage audit logs for uploads, shares, external links, device registrations
  • Identity provider sign-in logs and token/session events

Eradicate Step

The eradicate step consists of data analysis to confirm the evidence indicates attacker activity, followed by eliminating the attacker's artifacts on the system.

Data Analysis

Data analysis should produce: a high-confidence timeline, a list of additional IOCs, and a determination of likely data exposure paths (what was accessed and uploaded). Treat CTI as an amplifier—use it to enrich and pivot, not as your only proof.

  • Build a timeline:
    • Initial execution time (prefetch/process telemetry)
    • Persistence creation time (tasks/Run keys/services/WMI)
    • First outbound connection to cloud storage / suspicious domains
    • Upload window(s) and volume
  • Validate the malware family and capabilities:
  • Identify follow-on activity:
    • New logons from unusual devices/locations for impacted user
    • Any lateral movement from the host (RDP, SMB, remote service creation)
    • Any new OAuth consents/app registrations associated with the user

Eradicate

Once the evidence confirms malicious activity, proceed with eradication to remove the attacker's access from the affected systems:

  • Endpoint remediation (default-safe approach for infostealers):
    • Re-image the endpoint from a known-good gold image (preferred) rather than “cleaning.”
    • If re-image is not immediately possible:
      • Remove persistence artifacts identified (tasks/Run keys/services/WMI)
      • Quarantine/remove malicious binaries via EDR
      • Validate no additional payloads were dropped (EDR scan + offline scan)
  • Credentials and secrets:
    • Reset passwords for impacted user(s)
    • Revoke sessions/tokens in IdP and critical SaaS
    • Rotate any secrets accessible from the endpoint (API keys, SSH keys, cloud access keys)
    • If a password manager was used on the host, assume vault/session exposure until proven otherwise
  • Fleet-wide controls:
    • Block known IOCs (hashes/domains/URLs) across EDR/proxy/DNS
    • Hunt and remediate any other endpoints with matching IOCs or execution patterns

Recover Step

The recover step applies root cause analysis, vulnerability remediation, compensating control verification, and testing to return systems to production:

Recovery is about restoring business operations with confidence that stolen credentials and replayable sessions won’t immediately re-compromise you. It also requires you to fix the original delivery path (phishing, malvertising, trojan installer, drive-by) so you don’t repeat the incident next week. Use established incident handling guidance to ensure you close out detection and prevention gaps. oai_citation:12‡NIST Computer Security Resource Center

Root Cause Analysis

Perform root cause analysis to identify all the compensating controls and defenses that could have prevented the incident:

  • Determine initial access vector:
    • Email attachment/link? Malvertising? “Cracked software”? Fake browser update? GitHub-hosted payload?
  • Identify control failures:
    • Why did execution succeed (AppLocker/WDAC absent? macro/script controls weak? user local admin?)
    • Why wasn’t exfil detected (proxy visibility gaps? no upload telemetry? cloud audit logs not enabled?)
    • Why were credentials reusable (weak MFA enforcement? legacy auth? no token binding, no CA policies)?
  • Produce a control-focused narrative:
    • “If we had X (control), Y (stage) would have been prevented or detected faster.”

Remediation Strategies

Using the root cause analysis results, apply remediation strategies to mitigate future attacks.

  • Identity hardening:
    • Enforce phishing-resistant MFA where possible
    • Reduce standing privilege; use separate admin accounts and privileged access workstations
    • Conditional access policies for risky sign-ins and device compliance
  • Endpoint hardening:
    • Remove local admin where not required
    • Implement WDAC/AppLocker for high-risk populations
    • Block common script abuse paths (PowerShell Constrained Language where appropriate, ASR rules, etc.)
  • Network/cloud:
    • Improve proxy logging for upload events and destination categorization
    • Enable/retain cloud storage audit logs; alert on anomalous uploads/shares
    • Consider restricting third-party cloud storage clients if not business-approved

Compensating Control Verification

Verify the compensating controls in place to mitigate attacks:

  • Validate that EDR blocks the known sample hash/path and alerts on similar behavior
  • Run a controlled simulation for “exfil to cloud storage” detection coverage (Atomic Red Team has tests mapped to T1567.002). oai_citation:13‡atomicredteam.io
  • Confirm cloud audit alerting triggers:
    • unusual upload volumes
    • external sharing link creation
    • new device sign-in for high-risk users

Testing and Verification

Test the functionality of the system following recovery to verify that the systems meet the needs of the organization:

  • Endpoint:
    • Validate user can perform required work after re-image and policy changes
    • Confirm EDR health, logging, and patch posture
  • Identity/SaaS:
    • Validate MFA/CA policies do not break critical workflows
    • Confirm revoked sessions are actually invalidated (re-auth required)
  • Monitoring:
    • Confirm alerts fire for: suspicious process execution from user-writable paths, unusual cloud uploads, risky sign-ins

Repeat the Response Actions Loop

Remember to repeat the response actions loop (scoping, containment, eradication, and recovery) as needed to ensure the incident is fully resolved. This may include additional data collection, analysis, and remediation steps.

Complete the response actions loop when there are no additional indicators of compromise.

Schedule a Debrief

Following the completion of the incident response activities, schedule a debrief with the incident response team and stakeholders to review the incident, response actions taken, and lessons learned. Apply these lessons learned to improve future incident response activities.

References

Use these references as needed to augment your analysis while executing the playbook:

Version Control

Version Date Summary of Changes Author
1.0 2026-01-16 Initial playbook.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment