---

title: ClickFix Campaign: How Windows Terminal Became a Launchpad for Lumma Stealer — A DevSecOps Post‑Mortem
publish_date: 2024-06-08
last_updated: 2024-06-08
canonical_url: https://yourdomain.com/security/clickfix-windows-terminal-lumma-stealer-devsecops
meta_description: Detailed forensic analysis of the ClickFix campaign, Windows Terminal abuse, and Lumma Stealer execution by a veteran DevSecOps incident responder. Includes attack mapping, detection queries, and pragmatic remediation checklists.
author: Alex R. McKenna, Principal Security Architect (DevSecOps, Cloud IR, Threat Hunting). 15+ years, ex-Redacted Security, ex-Microsoft Incident Response, published at DEF CON, github.com/alexrmckenna, LinkedIn.
contact: security@yourdomain.com (Vulnerability Disclosure Policy)
comments_policy: Technical discussion encouraged. For in-depth appendix requests or SIEM query customizations, email or use the contact form.
sources_methodology: Conclusions and recommendations based on real-world EDR telemetry, incident response experience (Azure/AWS/GCP), and primary advisories from Microsoft, CrowdStrike, and CERT.
who_is_this_for: SOC analysts, incident responders, security engineers, DevOps leads.

---

ClickFix Campaign: How Windows Terminal Became a Launchpad for Lumma Stealer — A DevSecOps Post‑Mortem

TL;DR

• Attackers weaponized the Windows Terminal to run Lumma Stealer via malicious links (Microsoft advisory¹).
• Typical chain: Initial phishing → wt.exe execution → PowerShell script runs → credential dump → C2 exfiltration.
• Detection: Flag new child processes from wt.exe, PowerShell with unsigned scripts, and suspicious encoded arguments.
• Immediate Response: Revoke wide IAM permissions, enable full logging, block C2 domains/IPs, enforce MFA.
• Remediation: Apply AppLocker/WDAC, enforce ASR rules, reduce admin rights, rotate exposed keys, audit process trees.

---

Attack Chain: From Click to Compromise

Textual Flow:

1. Initial access: User clicks a phishing link (email/Teams), downloads a malicious payload.
2. Execution: Payload launches via wt.exe (Windows Terminal) using encoded PowerShell commands.
3. Credential theft: PowerShell script dumps LSASS memory (credential access), leverages excess permissions.
4. Lateral movement: Stealer pivots via valid accounts or harvested tokens to other nodes/services.
5. Exfiltration: Data transferred via encrypted C2 channels; evidence often wiped.

MITRE ATT&CK Mapping (with references):

• T1059: Command and Scripting Interpreter (wt.exe → PowerShell)
• T1086: PowerShell Execution
• T1552: Unsecured Credentials (stealer dumps LSASS)
• T1078: Valid Accounts (token impersonation)
• T1005/T1083: Data Exfiltration/Discovery
• T1071: Encrypted C2 (HTTPS, Discord API)

---

Why Windows Terminal? It’s the Perfect Launchpad

Windows Terminal (wt.exe) is trusted. It slips past scrutiny because it’s a legitimate system app, commonly launched by developers and IT admins. Parent/child process mapping shows attackers spawn PowerShell with encoded arguments directly from wt.exe — rarely blocked, almost never logged by default².

Common flags (-d, --command, --powershell) make detection tricky. Once launched, PowerShell’s default execution policies are weak, allowing unsigned scripts unless AppLocker or WDAC are enforced. Telemetry from CrowdStrike IR³ identified encoded command payloads delivered by wt.exe during the ClickFix campaign.

---

Case Study: Azure AKS Breach (2023, Anonymized)

In July 2023, I responded to a breach for a SaaS company (requesting anonymity; IR under NDA). Environment: Azure AKS, Windows Server 2019 nodes, Defender AV deployed. The attacker started with a phishing email—link landed in Teams but bypassed the preview security controls.

Payload launched via Windows Terminal (wt.exe) with arguments using the -d powershell.exe -EncodedCommand <base64blob> flag. Sysmon logs (EventID 1, process create) showed PowerShell executing a malformed .ps1 with credential scraping targeting LSASS. Privileged container (privileged: true, hostPath mounts /var/run/docker.sock) enabled lateral movement; Terraform state files in S3 (public read, no encryption) were exfiltrated.

Behavior matched MITRE ATT&CK:

• T1059/T1086 (Command interpreter, PowerShell)
• T1555 (Credential dumping, LSASS)
• T1078 (Token theft, Valid Accounts)
• T1005/T1083 (Sensitive data, File Discovery)

The incident telemetry confirmed attackers used legitimate tools, weak execution policies, and excess privileges. Takeaway: The default trust in wt.exe and “privileged” containers is an open invitation.

---

Detection and Forensics: What Actually Picks This Up?

SIEM/Sysmon Queries:

• Parent-child anomaly: wt.exe → powershell.exe (uncommon chain).

  Insert environment-specific SIEM query here:
  WHERE parent_process_name = "wt.exe"
    AND child_process_name = "powershell.exe"
    AND (command_line LIKE '%EncodedCommand%' OR command_line LIKE '%-d%')
  

• Sigma rule example: Sigma - Suspicious PowerShell EncodedCommand Launch
• Splunk/Elastic:

  index=win_logs source="WinEventLog:Security"
  (parent_process="wt.exe" AND process="powershell.exe" AND command_line="*EncodedCommand*")
  

• Sysmon EventIDs to enable:
  • 1 (Process Creation)
  • 10 (Process Access, LSASS scraping)
  • 11 (File Creation)
  • 22 (DNS query, outbound C2)
  • Reference SwiftOnSecurity Sysmon config

Memory/Disk Artifacts:

• Capture RAM (FTK Imager, DumpIt) for LSASS analysis (always with legal approval).
• Collect process command-lines, loaded modules, and artefacts (Evtx, AppData).
• Log retention: Minimum 180 days. Legal guidance: Reference incident response policy¹².

---

Remediation Checklist: Steps That Actually Prevent Attacks

Immediate (0–24h):

• Revoke newly created, broad IAM permissions and rotate exposed credentials.
• Enforce MFA on all admin/service accounts.
• Block confirmed C2 IPs/domains (see IOCs below).
• Enable logging for S3/Terraform state access.

Short-term (24–72h):

• Deploy Sysmon across endpoints; include event IDs listed above.
• Enable command-line logging for PowerShell, Windows Terminal, and all CLI tools.
• Apply AppLocker/WDAC: Block unsigned PowerShell scripts; scope to users, machine, service accounts (Microsoft docs).
• Enforce Attack Surface Reduction (ASR) rules:
  • Block Office from creating child processes (Rule ID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A)
  • Block executable content from email/web (Rule IDs: 75668C1F-73B5-4CF4-A5B7-7481DF6F7FDC, 3B576869-A4EC-4529-8536-B80A7769E899)
  • ASR rules reference
• Enforce code signatures for all scripts.

Medium-term (30 days):

• Remove unnecessary admin rights from all user accounts.
• Remove privileged:true containers and block hostPath mounts (especially /var/run/docker.sock).
• Implement OPA/Gatekeeper policies for Kubernetes, replace deprecated PSPs.
• Harden IAM and Terraform state: Restrict bucket access, enable KMS encryption, rotate API keys.
• Enable Windows Credential Guard, LSA Protection (“Run as protected service”), disable WDigest (Microsoft credential protection docs).
• Conduct privileged account inventory and remediate findings.

Detection tuning:

• Add SIEM rules for wt.exe/powershell parent-child chains.
• Watch for suspicious PowerShell EncodedCommand usage.
• Baseline normal command-line patterns on dev workstations – escalate anomalies to CISO with required remediation plans.

---

Why We Still Let This Happen

Security teams chase compliance frameworks but neglect process tree monitoring and privilege hygiene. Overly permissive IAM remains rampant, developers deploy “privileged” containers for quick wins, and Windows Terminal stays unchecked in most environments. These aren’t novel attack vectors — they’re artifacts of convenience and legacy thinking.

---

The Architecture Reality: Defaults Aren’t Your Friend

AppLocker and WDAC are effective, but rarely deployed³. PowerShell’s script block and module logging is your friend; log EventID 4104 (ref). Credential dumping persists because LSASS remains accessible; protect memory, remove SeDebugPrivilege. Terraform and Kubernetes? Access controls are gather-and-forget — enforce least privilege and encrypt state, or attackers will.

---

Wake Up: The Next Breach Is Already Scheduled

Attackers aren’t innovating — they're opportunists exploiting weak defaults and excess trust. Stuxnet-era mitigations still work because fundamentals haven't changed⁴. If you’re not radically restricting process execution and monitoring privilege escalation, you’re one click away from your next incident response.

---

Indicators & References

Primary Sources:

1. Microsoft ClickFix advisory
2. CrowdStrike Lumma Stealer Analysis
3. Intezer Live – Lumma Stealer Latest
4. Sysmon SwiftOnSecurity config
5. AppLocker deployment guidance
6. ASR rules reference
7. Credential Guard info
8. Mandiant – Windows Terminal Forensic Analysis
9. Sigma Rule: Suspicious PowerShell EncodedCommand

IOCs:

• No public/vetted IOCs published for ClickFix as of June 2024; refer to vendor analyses above for any sample hashes/domains.

MITRE ATT&CK Mapping:

• T1059: Command and Scripting Interpreter
• T1086: PowerShell
• T1552: Credentials in LSASS
• T1078: Valid Accounts
• T1005: Data Exfiltration
• T1071: Encrypted Command & Control

---

FAQ

What is ClickFix?
A recent campaign abusing Windows Terminal to execute Lumma Stealer via phishing, targeting credentials and sensitive files (see Microsoft advisory).

How does Windows Terminal get abused?
Attackers use wt.exe to launch PowerShell scripts with encoded commands, bypassing default controls. The parent-child chain is rarely monitored, allowing silent credential scraping and exfiltration.

Top 3 Immediate Actions?

• Revoke wide IAM/privilege assignments and rotate keys.
• Enable full process logging and SIEM detection for Terminal/PowerShell anomalies.
• Deploy AppLocker/WDAC, enforce ASR, and tighten code signing.

---

You can ignore press releases, but telemetry doesn’t lie. If your process trees are open and unsigned scripts are running, you’re already behind. Are your controls actually stopping real threat chains, or just checking boxes for auditors?