AutoHotkey Malware Loaders: How Attackers Weaponize Automation Scripts

Your endpoint ran a legitimate, signed executable. No macro, no PowerShell, no suspicious script extension. Your EDR stayed quiet. Inside that binary, an AutoHotkey script was decoding shellcode and injecting it into a trusted process.

TL;DR

• AutoHotkey (AHK) is a free Windows scripting language abused by attackers as a malware loader and keylogger
• Compiled AHK executables bundle an interpreter + script into a single .exe, making AV detection harder
• Real campaigns have used AHK to deliver DarkGate, AsyncRAT, LimeRAT, Revenge RAT, and credential stealers
• In December 2025, UNC6692 used AHK to deploy a full browser-extension backdoor suite (SNOWBELT/SNOWBASIN/SNOWGLAZE) in a campaign ending in domain controller compromise
• The DllCall() function gives AHK direct access to the Windows API — including VirtualAlloc and CreateThread for shellcode injection
• Detection requires a combination of YARA rules, process tree analysis, and EDR telemetry

Why This Matters

AutoHotkey is installed on millions of Windows machines. It’s used by power users, developers, and IT teams to automate repetitive tasks — macros, hotkeys, form fillers. Because it’s legitimate software, it often appears on allowlists and flies under the radar of security tools that focus on known-bad binaries.

Attackers noticed. Since at least 2018, threat actors have weaponized AHK in campaigns ranging from simple keyloggers to multi-stage RAT delivery chains. MITRE ATT&CK catalogues this as T1059.010 — Command and Scripting Interpreter: AutoHotKey & AutoIT. If you run Windows endpoints and haven’t thought about AHK as an attack surface, this is worth your attention.

What Is AutoHotkey?

AutoHotkey (AHK) is a free, open-source scripting language for Windows, designed to automate keyboard input and window management. A typical legitimate use case looks like this:

; Remap Caps Lock to Escape
CapsLock::Escape

; Auto-fill a form field
^F1::
  Send, firstname@example.com
  return

The key feature that makes it dangerous in the wrong hands: AHK can call any Windows API function directly through its built-in DllCall() function. This gives scripts the same power as compiled C code — without needing a compiler or triggering typical compiler-artifact signatures.

AHK scripts (.ahk files) can also be compiled into standalone executables. The compiled .exe bundles the AHK interpreter, the script, and any embedded files into a single binary. No AHK installation required on the target. No .ahk file extension to trigger file-based rules.

Why Attackers Choose AHK

Several properties make AHK attractive for malware development:

Attackers don’t choose AHK because it’s powerful — they choose it because it’s boring. A process named AutoHotkey.exe in the process tree looks like a sysadmin tool, not a RAT.

Attack Techniques

1. Keylogging

AHK was literally designed to intercept keystrokes. Malicious keyloggers written in AHK have appeared in multiple campaigns. The script captures keys and writes them to a log file or sends them to a C2 server.

#Persistent
SetTimer, LogKeys, 100
return

LogKeys:
  ; Reads clipboard and active window title
  FileAppend, % A_Now " | " WinGetTitle("A") "`n", keylog.txt
return

The DFIR Report documented a real intrusion (August 2022) where attackers deployed a renamed AutoHotkey.exe as module.exe, paired with a module.ahk keylogger script. The script captured keyboard layout and pressed keys — persisting via a scheduled task.

2. Shellcode Injection via DllCall

The most dangerous capability. DllCall() lets AHK call any Windows API function by name. Shellcode injection follows the same pattern as any C-based loader:

; Allocate executable memory
addr := DllCall("VirtualAlloc"
  , "Ptr", 0
  , "UInt", shellcodeSize
  , "UInt", 0x3000      ; MEM_COMMIT | MEM_RESERVE
  , "UInt", 0x40        ; PAGE_EXECUTE_READWRITE
  , "Ptr")

; Write shellcode bytes into the allocated region
DllCall("RtlMoveMemory", "Ptr", addr, "Ptr", &shellcode, "UInt", shellcodeSize)

; Execute via new thread
DllCall("CreateThread"
  , "Ptr", 0, "UInt", 0
  , "Ptr", addr
  , "Ptr", 0, "UInt", 0, "Ptr", 0)

The shellcode itself is typically stored in an external file (a .txt or .dat) and loaded at runtime — keeping the .ahk script clean of obvious payload bytes. Antivirus sees a text file; the AHK script reads it, decodes it, and executes it in memory.

3. The Same-Name Auto-Execute Trick

A subtler evasion observed in real campaigns: AHK has a built-in behavior where if the interpreter binary and a script file share the exact same base name in the same directory, AHK automatically executes the script with no command-line arguments required.

RegSrvc.exe      ← renamed AutoHotkey interpreter
RegSrvc.ahk      ← malicious script (same base name)

Running: RegSrvc.exe
→ AHK auto-loads RegSrvc.ahk silently

This means the process tree shows only RegSrvc.exe with zero arguments — no script path, no suspicious flags. Command-line logging reveals nothing. Detection rules that look for .ahk file references in process arguments will miss this entirely.

4. The Compiled Loader Pattern

The typical delivery chain looks like this:

Phishing email / malicious URL
  → HTML / XLS / LNK dropper
    → VBScript or PowerShell stage
      → Downloads three files:
          AutoHotkey.exe (legitimate interpreter)
          payload.ahk   (malicious script)
          data.txt       (encoded shellcode or config)
        → AHK executes → shellcode in memory → RAT/backdoor

The key evasion point: only AutoHotkey.exe touches disk as a “suspicious” binary, but it’s legitimately signed. The actual payload bytes never appear as a standalone .exe that AV can scan at write time.

Real-World Campaigns

Morphisec AHK RAT Loader (2021)

Morphisec Labs tracked an AHK-based campaign delivering multiple RATs: AsyncRAT, LimeRAT, Revenge RAT, Vjw0rm, and Houdini. At least four distinct attack chain variants were observed. In one variant, the AHK loader executed a legitimate application as a decoy while dropping a VBScript that fetched HCrypt — a malware loader — which then installed AsyncRAT in memory.

The campaign demonstrated how AHK enables a “launcher abstraction layer”: the RAT payload never executes directly from a suspicious process, it always spawns from a familiar-looking AutoHotkey binary.

DarkGate via AHK (2023–2024)

McAfee Labs documented DarkGate — a sophisticated crimeware toolkit — using AHK as a stage in its infection chain. The initial vector was an HTML file containing a malicious Internet Shortcut (.url) designed to evade Windows Defender SmartScreen. Subsequent stages downloaded:

1. A VBScript launcher
2. A PowerShell fetcher
3. Three files: AutoHotkey.exe, a .ahk script, and a test.txt containing encoded shellcode

The .ahk script read test.txt, decoded the shellcode, and executed it — ultimately loading the DarkGate payload. The use of AHK was specifically chosen to insert a legitimate binary into the chain and delay detection at the SmartScreen boundary.

UNC6692 — Snow Flurries Campaign (December 2025)

The most recent documented AHK campaign, tracked by Google Threat Intelligence Group (GTIG) / Mandiant, demonstrates how far the technique has evolved. UNC6692 launched a multi-stage intrusion in late December 2025 — beginning with email flooding and Teams phishing — that ultimately ended in domain controller compromise.

The AHK role: The phishing landing page (hosted on AWS S3, styled as a “Mailbox Repair and Sync Utility”) tricked users into clicking buttons that downloaded two files: a renamed AHK interpreter (RegSrvc.exe) and a script with the same base name (RegSrvc.ahk). No command-line arguments needed — the interpreter auto-loaded the script.

The first AHK script installed SNOWBELT, a malicious Chromium extension masquerading as “MS Heartbeat.” A second AHK persistence script then launched a headless Microsoft Edge instance with the extension loaded:

; Persistence AHK — ensures SNOWBELT extension stays running
if !CheckHeadlessEdge(){
  Run 'cmd /c start "" "msedge.exe"
       --user-data-dir="%LOCALAPPDATA%\...\System Data"
       --headless=new
       --load-extension="%LOCALAPPDATA%\...\SysEvents"
       --no-first-run',,"Hide"
}
ExitApp

The full SNOW malware ecosystem that AHK bootstrapped:

From initial phishing to domain controller compromise, the attack chain included LSASS dumping, Pass-the-Hash, and NTDS.dit exfiltration — all bootstrapped by a two-file AHK drop that triggered with zero suspicious command-line arguments.

Fauxpersky — AHK Credential Stealer (2018)

Cybereason Research documented Fauxpersky, an AHK-based credential stealer that disguised itself as Kaspersky Antivirus. It spread via USB drives by copying itself to all connected drives. Once running, it:

• Captured all keystrokes via AHK’s native keyboard hooks
• Exfiltrated credentials through Google Forms (a legitimate HTTPS endpoint)
• Displayed a fake Kaspersky UI to avoid suspicion

Fauxpersky showed that you don’t need sophisticated shellcode to do serious damage with AHK. The language’s built-in capabilities are enough for a fully functional credential stealer.

Detection

Static Analysis: YARA

Compiled AHK executables store the original script in the RCDATA resource section. This makes static extraction straightforward — you can pull the plaintext script from a compiled binary using 7-Zip (<binary>.exe\\.rsrc\RCDATA). YARA can match on AHK magic bytes and suspicious API strings:

rule AHK_Malware_Loader {
  meta:
    description = "Detects compiled AHK binaries with shellcode injection capabilities"
    reference   = "MITRE T1059.010"

  strings:
    $ahk_magic  = { 3C 3F 41 48 4B }         // <?AHK header
    $ahk_str    = "AutoHotkey" wide ascii
    $virt_alloc = "VirtualAlloc" ascii
    $create_thr = "CreateThread" ascii
    $rtl_move   = "RtlMoveMemory" ascii

  condition:
    ($ahk_magic or $ahk_str) and
    (2 of ($virt_alloc, $create_thr, $rtl_move))
}

Process Tree Analysis

Legitimate AHK usage rarely spawns child processes or makes network connections. Flag these patterns:

• AutoHotkey.exe spawning cmd.exe, powershell.exe, or wscript.exe
• AutoHotkey.exe making outbound connections to non-local IPs
• A renamed binary (not named AutoHotkey.exe) that imports AHK-related strings
• AutoHotkey.exe reading files with unusual extensions (.txt, .dat) from temp directories

Sigma Rule — Suspicious AHK Network Activity

title: AutoHotkey Unexpected Network Connection
status: experimental
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    Image|endswith:
      - '\AutoHotkey.exe'
      - '\AutoHotkey32.exe'
      - '\AutoHotkey64.exe'
    Initiated: 'true'
  filter_local:
    DestinationIp|startswith:
      - '127.'
      - '192.168.'
      - '10.'
  condition: selection and not filter_local
falsepositives:
  - Legitimate AHK scripts with network features (document exceptions)
level: medium
tags:
  - attack.execution
  - attack.t1059.010

Sigma Rule — Suspicious AHK Child Process

title: AutoHotkey Spawning Suspicious Child Process
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\AutoHotkey.exe'
      - '\AutoHotkey32.exe'
      - '\AutoHotkey64.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection
falsepositives:
  - Complex legitimate AHK automation scripts
level: high
tags:
  - attack.execution
  - attack.t1059.010

EDR Telemetry

On an EDR-monitored endpoint, look for:

Windows Event Logs

• Event 4688 (Process Creation, with command-line auditing enabled): shows AHK binary launch and arguments
• Event 7045 (Service Installation): AHK persisted as a service
• Sysmon Event 1 + Event 8 (CreateRemoteThread): catches cross-process injection from AHK

What You Can Do Today

For defenders:

1. Inventory AHK usage. Query your asset management or EDR for all endpoints running AutoHotkey.exe. Legitimate use should be rare and documented.
2. Enable command-line process auditing. Windows Event 4688 with command-line logging shows AHK binary launches and their arguments.
3. Deploy the Sigma rules above in your SIEM. Start at medium alert level; tune for your environment.
4. Block unsigned AHK binaries at the AppLocker or WDAC level if AHK isn’t part of your standard software catalog.
5. Extract scripts from compiled AHK binaries using 7-Zip during incident response — the source script is sitting in the RCDATA resource section.

For red teamers:

6. AHK compiled loaders are fingerprinted — use obfuscation or consider alternative scripting languages if evasion is required. RCDATA extraction is a known IR technique.
7. Rename the binary but know that import table and resource strings still betray AHK lineage.
8. Test against modern EDR before assuming AHK DllCall-based injection is clean — behavioral detection has improved significantly since 2021.

Related Posts

• Living Off the Land: How Attackers Use Windows Built-in Tools — AHK abuse fits the LoTL pattern; same detection philosophy applies
• Windows Trusted Process Abuse: How Attackers Hide in Plain Sight — process tree analysis and parent-child anomaly detection
• Digital Parasite: Attacker Tradecraft in 2026 — broader context on how attackers layer legitimate tools
• C2 Without Owning a C2: Living off Legitimate Services — Fauxpersky’s Google Forms exfiltration is a variation of this pattern

Sources

• McAfee Labs — The DarkGate Menace: Leveraging AutoHotkey & Attempt to Evade SmartScreen
• Morphisec — AHK RAT Loader Used in Unique Delivery Campaigns
• Cybereason — Fauxpersky: CredStealer Malware Written in AutoHotKey
• The DFIR Report — Collect, Exfiltrate, Sleep, Repeat
• NVISO Labs — The SOC Toolbox: Analyzing AutoHotKey Compiled Executables
• MITRE ATT&CK — T1059.010: AutoHotKey & AutoIT
• The Hacker News — Experts Warn About Ongoing AutoHotkey-Based Malware Attacks
• Google Threat Intelligence Group (GTIG) / Mandiant — UNC6692: Snow Flurries Campaign