There's a particular flavour of security fatigue that comes from reading about AutoIt malware in 2026. AutoIt-based droppers have been around for well over a decade, and Xavier Mertens has another sample in the SANS diaries: a fake bank email with a RAR attachment, a VBS and PowerShell staging chain, an AutoIt3 interpreter running a script that injects shellcode into charmap.exe, and VIPKeylogger as the final payload. Nothing about the technique has changed materially. That's the story.

Why attackers keep coming back to it

AutoIt was built to automate Windows GUIs. That means it ships with, or trivially wraps, everything you need to do the interesting things: call arbitrary Win32 APIs via DllCall-style functions, allocate memory, spawn processes, manipulate windows and input. It compiles to a standalone executable with no runtime dependency. It has a huge corpus of legitimate example code online, so writing it requires no real skill. And crucially, plenty of genuine software — installers, game utilities, line-of-business automation glued together by someone who left in 2016 — is AutoIt-compiled, which makes blanket blocking a conversation with the business rather than a checkbox.

That combination is the whole point. Attackers are not optimising for elegance. They're optimising for the ratio of effort to detection. A language that gives you API access, static compilation, and a plausible false-positive story is a very good deal.

The uncomfortable bit about detection assumptions

Much detection engineering has a bias towards the fashionable. Everyone has PowerShell script block logging turned on. Everyone has rules for mshta, rundll32, LOLBins, encoded command lines, and — since ClickFix became everyone's problem — the Run dialog. Fewer teams have anything meaningful for a compiled, self-contained binary that runs its own injection logic after a short script-based first stage.

That's the gap. Process injection is process injection regardless of what wrote the injector. If your visibility depends on catching the language rather than the behaviour, a compiled AutoIt binary walks straight past you. Mertens' framing in the diary is blunt about why it persists: it's "easy to write and powerful." There is no more sophisticated explanation needed.

What actually works against this class of thing

Some approaches work better than others, so let me be specific.

  • Behavioural EDR rules on cross-process memory operations. VirtualAllocEx followed by WriteProcessMemory followed by a remote thread creation, from an unsigned binary in a user-writable path, is a high-confidence signal in almost any environment. In this sample the target was charmap.exe, a trusted Windows binary launched from SysWOW64 with no reason to receive a remote thread. This is where the real detections live. Tune it on your own estate first — you will find legitimate offenders.
  • Application control on user-writable paths. AppLocker or WDAC blocking execution from %APPDATA%, %TEMP% and %LOCALAPPDATA% kills a very large share of this delivery pattern. It also generates the most pushback of anything on this list, which is why it is worth running in audit mode for several weeks before enforcing. The audit log is the negotiating position.
  • Inventory the legitimate AutoIt in your estate. Do this before you write any rules. Search your software inventory and file telemetry for AutoIt-compiled binaries and get a named owner for each one. Expect surprises: it is common to find a handful, some that nobody can account for and one that turns out to be load-bearing.
  • Don't bother with generic "AutoIt is bad" hash or name blocking. It doesn't survive recompilation, and the compilation stub varies enough between versions to make signature approaches brittle. Teams that try it tend to spend a sprint and get nothing durable.

The Defender-shaped answer

If you're on the Microsoft stack, most of this is already licensed and switched off. Attack Surface Reduction rules cover part of the ground — the ones blocking executable content from mail and webmail clients, and blocking executables unless they meet prevalence or trust criteria, both bite on this delivery pattern. That prevalence rule in particular is well-suited to freshly compiled AutoIt, because a one-off compiled dropper has no prevalence anywhere.

The catch is that the prevalence rule also bites on your own internally built tooling. If your developers hand out unsigned utilities, you will spend the first month writing exclusions. That's not an argument against turning it on. It's an argument for having a code signing story before you turn it on, which is a conversation worth having anyway.

What this says about the broader threat picture

A point worth repeating, as with ClickFix: our industry's mental model of "sophistication" is wrong in a way that costs money. We treat novelty as the primary threat axis and allocate attention accordingly. But the techniques that persist for well over a decade persist precisely because they're unglamorous and they work. Nobody writes a conference talk about AutoIt injection. Nobody needs to.

The operational consequence is that detection coverage should be audited against technique categories, not against headlines. Ask a simpler question of your SOC: if a compiled binary of unknown provenance injected shellcode into a legitimate process on a finance user's laptop tomorrow morning, which of our controls fires, and how long until someone looks at the alert? If the honest answer involves the phrase "depends on the sample," that's your finding.

The short version for a Monday morning

Pull a list of AutoIt-compiled executables running in your environment. Check that your EDR has behavioural coverage for remote process injection independent of the parent binary's type. Put ASR in audit mode if it isn't already, and read what it tells you. None of that is new advice — it's the same advice that would have worked in 2011, which is rather the point of the diary entry.

Old techniques don't retire. They just stop being interesting enough to write about, and then they quietly keep working.

Source: AutoIT Payload Injector — SANS Internet Storm Center