SANS ISC handler Xavier Mertens reported a wave of near-identical phishing emails delivering an AutoIT-based payload injector that ends in VIPKeylogger, a credential-stealing keylogger that beacons to cphost17[.]qhoster[.]net. The lure in the sample he analyzed was a fake bank notification carrying a RAR archive named Bank_account_details.rar (SHA256: 5c4ca58e41c009c664a7134df12b0fdc0815f572e117fe67ca35582f19d9deab). (Source: Isc)

If your staff handle payment confirmations, statements, or wire instructions by email, that filename is designed to look like routine business. Inside the archive is a single VBS script, not an executable, which is often enough to slip past attachment rules that focus on binaries.

AutoIT works well for attackers for a simple reason: it is a legitimate Windows scripting and automation language, and the interpreter that runs the malicious script is an unmodified, signed AutoIT3 binary (SHA256: bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1). In this campaign it was renamed vijewyufveonabghulluonouceyasi.exe and dropped into AppData\Roaming\SetupFiles. Many organizations allow AutoIT because IT and business teams use it for internal automation, so it lands in the same category as PowerShell — a tool you cannot simply block outright.

"Yes, AutoIT is able to invoke any API call!" — Xavier Mertens, SANS Internet Storm Center

That matters because the script does not need compiled malware to inject code. It calls OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread directly from kernel32.dll to push shellcode into a hidden instance of charmap.exe, the built-in Windows Character Map utility. Your endpoint telemetry sees a legitimate interpreter starting a legitimate Microsoft binary.

The chain runs from VBS to gzip-compressed batch script to XOR-encoded payloads, then to process injection and a Run key for persistence. The end state is a keylogger recording what your employees type, which for financial services means online banking credentials, client account data, and email logins captured at the point of entry.

Attack Chain: From AutoIT Script to Credential Harvesting

The infection unfolds in four distinct stages, and only the last one touches a real binary payload. The VBS script (SHA256: f88d9094a90f7000a3fb2cd7c981e03357ce2b39df9de5ee1d0742e619e3860f) decodes an embedded Base64 blob, writes it to disk under a random name with a .bat.gz extension, then calls PowerShell to gzip-decompress it into a .bat file and delete the compressed original.

In the analyzed sample those artifacts landed at C:\Users\<user>\AppData\Local\Temp\tmp656234.bat.gz and tmp656234.bat. The PowerShell call uses only IO.FileStream, IO.Compression.GzipStream, and WriteAllBytes — no download, no network activity at this point, which is why perimeter filtering alone will not see the second stage arrive.

The batch file spawns another PowerShell instance that writes three files into C:\Users\<user>\AppData\Roaming\SetupFiles\. Each is stored Base64-encoded and single-byte XOR-encrypted, using keys 0x02 and 0x3D, decoded in a simple -bxor loop:

• vijewyufveonabghulluonouceyasi.exe — a legitimate AutoIT3 interpreter (SHA256: bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1), renamed to a random string.
• wwman — the AutoIT script that performs the injection, with no .au3 extension.
• Ennnn — the XOR-encrypted shellcode blob.

Execution is the interpreter plus script path as an argument: "...\SetupFiles\vijewyufveonabghulluonouceyasi.exe" "...\SetupFiles\wwmaw". Persistence uses a user-level Run key — value name Windows32 under HKCU\Software\Microsoft\Windows\CurrentVersion\Run, pointing at the same interpreter-plus-script command line (MITRE T1547.001). No admin rights are needed, so a standard user account is enough to re-launch the keylogger at every logon.

The AutoIT script itself is written to defeat string-based scanning. It starts with #NoTrayIcon to suppress the AutoIT tray indicator, and every sensitive string is hex-encoded and rebuilt at runtime by a small helper function that walks the string two characters at a time and calls Chr(Dec(...)). That is how kernel32.dll, OpenProcess, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, and CloseHandle stay invisible to a plain strings dump of the script (T1140).

The script reads Ennnn in binary mode, copies it into a DllStructCreate byte array, and XORs every byte with 236 (0xEC) in place. It then runs C:\Windows\Syswow64\charmap.exe with @SW_HIDE — a hidden instance of the Windows Character Map utility — and injects into it using the constants 0x1F0FFF for process access, 0x3000 for the allocation type, and 0x40 for read-write-execute page protection. Both remote-thread and process handles are closed immediately afterward (T1055, T1036).

The behavioral signature for SOC review is therefore a chain no normal workstation produces: wscript.exe → powershell.exe → cmd.exe → powershell.exe → a randomly named executable in AppData\Roaming → a hidden charmap.exe with an outbound connection. Character Map has no legitimate reason to talk to the internet or to hold RWX memory.

Post-injection, the shellcode runs VIPKeylogger inside that charmap.exe process. It captures keystrokes and harvests stored credentials, meaning banking portal logins, webmail passwords, and anything typed into a browser form are collected from a process your endpoint tooling sees as a signed Microsoft binary (T1056.001). For a finance team, that includes the credentials used to authorize payments.

Financial Services Under Threat: Credential Compromise at Scale

The business cost of this campaign comes down to a simple question: what do your people type during a normal working day? A keylogger does not discriminate between a personal webmail password and the credentials for your core banking platform — it records both, in order, alongside the window title that tells the operator exactly which system each one unlocks.

Because the shellcode runs inside C:\Windows\SysWOW64\charmap.exe — the signed Character Map utility that ships with Windows — the collection happens under a process name your inventory and application allowlists already trust. There is no unfamiliar executable consuming CPU and no rogue service to notice, so the credentials leave your environment under cover of a Microsoft binary.

For a bank, credit union, or payments firm, the material exposure sits in a handful of credential types:

• Customer-facing account access typed by staff during service calls, including account numbers and identity verification data read aloud and entered.
• Payment authorization credentials for ACH batches, wire initiation, and approval workflows — the accounts that move money rather than just view it.
• Administrative and domain credentials entered by IT staff on an infected endpoint, which convert one compromised workstation into access across your network.
• Trading, custody, and vendor portal logins, plus anything typed into third-party platforms your firm accesses on behalf of clients.

What an operator does with those credentials is where the loss becomes measurable. Valid logins let an attacker sign in as your employee, which means the activity carries legitimate permissions and appears in your logs as normal work. Fraudulent transfers initiated through an authorized session are difficult to reverse once settled, and lateral movement using harvested admin credentials broadens the incident from one endpoint to whatever that account can reach.

The persistence entry in the HKCU Run key matters for scoping as much as for cleanup. The keylogger restarts every time the user logs on, so if it survived on a workstation for weeks, you cannot narrow the exposure to a single session — every credential typed on that machine across the entire dwell period has to be treated as captured, including passwords rotated after the initial compromise.

That uncertainty drives your regulatory work. Under the GLBA Safeguards Rule, unauthorized acquisition of unencrypted customer information triggers notification obligations to your regulator, and state breach notification statutes impose their own deadlines and content requirements that vary by where your customers live. If any of the affected endpoints touch cardholder data, PCI DSS brings a separate set of requirements around access control and monitoring that examiners will test against the timeline you reconstruct.

Operationally, the response consumes more than your security team. Credential resets across affected staff, MFA re-enrollment, and forced re-verification of pending payment instructions all land during business hours, and each one interrupts customer service. If you cannot prove which keystrokes were collected, your safest assumption is the broadest one, which expands the reset scope and the notification population at the same time.

Reputational cost follows the notification letters. Customers who receive notice that their account details were exposed through your systems weigh that against the alternatives available to them, and your next examination will include questions about how a script attachment reached a workstation with payment authority. The recovery work is finite, but the scoping cost scales directly with how long the keylogger ran before anyone found it.

Detection and Immediate Response Actions

First Hours: Find the Persistence, Then the Host Process

Start with the registry. Query every endpoint for HKCU\Software\Microsoft\Windows\CurrentVersion\Run values whose data contains two paths — an executable followed by a second argument with no file extension. The value name in the analyzed sample was Windows32, and that two-argument shape is the cleanest single indicator of this chain, because the interpreter needs its script passed as a parameter.

Next, hunt the staging directory. Look for C:\Users\<user>\AppData\Roaming\SetupFiles containing extensionless files alongside a randomly named executable, and hash any binary you find there against the AutoIT3 interpreter SHA256 bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1. The interpreter itself is legitimate signed software, so name-based blocking fails; hash and path context are what identify it.

Then check process telemetry for anything spawning C:\Windows\SysWOW64\charmap.exe. Character Map has no business being launched by an unsigned executable in a user profile directory, with no visible window, and no user ever clicking it. Build a detection on that parent-child pair and you catch this family regardless of which random filename the next wave uses.

If you get a hit, capture volatile memory before you reboot or reimage. The stolen keystrokes and the shellcode exist only inside the running charmap.exe process — power-cycling the host destroys your evidence while the Run key quietly restarts the whole chain at next logon.

24 to 72 Hours: Credentials and Money Movement

• Reset every credential typed on the affected host during the exposure window, then revoke active session tokens, OAuth grants, and application passwords. A password change alone leaves an already-authenticated session working.
• Pull authentication logs for those accounts from the date the phishing wave began, not from the date you found the malware. In environments Capstone manages, Adlumin correlates that logon activity across managed environments and surfaces the anomalous sign-ins that follow keylogged credentials into banking portals and email.
• Review financial transaction logs for new payees, changed beneficiary details, and modified approval routing — the specific actions an operator takes once they hold banking credentials.
• Turn on process command-line capture in Windows Security event 4688 and PowerShell script block logging. This chain hides its intent in arguments and encoded strings, so without command lines your logs show only that PowerShell ran.
• Retro-hunt your mail gateway for archive attachments containing script files, and block that combination going forward.

Longer Term: Constrain Where Scripts Can Run

Write WDAC or AppLocker rules that deny execution from user-writable paths, including %APPDATA% and %TEMP%. That single control breaks the chain at the point where the interpreter and its script land on disk, no matter how the payload is encoded.

If your teams use AutoIT legitimately for build or test automation, keep one signed, inventoried copy in a controlled directory and allow only that hash. Everything else executes as an anomaly you can alert on.

Finally, tune your endpoint detection on behavior rather than file identity. The injection sequence here is OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread, requested with PROCESS_ALL_ACCESS (0x1F0FFF) and PAGE_EXECUTE_READWRITE (0x40) — from a script interpreter, which never has a legitimate reason to allocate executable memory in another process. Alert on that call sequence and the payload's obfuscation becomes irrelevant.

Hardening Against AutoIT-Based Malware

The single most effective control is application allowlisting that blocks unauthorized script interpreters by publisher or hash rather than by filename. The AutoIT3 interpreter in this campaign arrived under a random name, so any AppLocker or WDAC rule written against AutoIt3.exe would have missed it entirely. Rules keyed to the AutoIt Consulting Ltd signing certificate, or to known interpreter hashes, catch the same binary no matter what it is called.

Know what legitimately uses AutoIT first

Before you block anything, inventory it. AutoIT-compiled executables show up inside legitimate line-of-business software, printer utilities, and internal automation written years ago by staff who have since left. Run AppLocker in audit mode for two weeks and collect the results; you will get a short list of genuine business dependencies, and everything outside that list becomes deniable without breaking a workflow.

Preventive controls, in order of payoff

• Deny the interpreter by default. A WDAC policy that permits only signed, inventoried AutoIT builds removes the execution primitive this chain depends on. Where WDAC is too heavy, AppLocker publisher rules in enforce mode achieve most of it.
• Remove script file handlers. Unassociate .au3 and .a3x from the interpreter, and disable Windows Script Host for standard users with HKLM\Software\Microsoft\Windows Script Host\Settings\Enabled = 0. That kills double-click execution of the archived script stage before PowerShell is ever reached.
• Require signed scripts and log everything else. Set PowerShell execution policy to AllSigned on finance workstations, enable script block and module logging via Group Policy, and forward those logs off the endpoint. Local-only logs are worthless once an operator has code running as the user.
• Filter archives at the mail gateway, not just attachments. Inspect inside RAR and ZIP containers and quarantine any archive whose only content is a script file. This is a low-effort rule change with a very low false-positive rate.
• Separate the machines that move money. Endpoints used for payment approval, wire release, or core banking access should sit in their own segment with their own allowlist policy and no general web or webmail browsing. If a general user endpoint gets a keylogger, that separation limits what the operator can reach with the credentials collected.

Handle the trusted-interpreter problem

Allowlisting AutoIT for one business application creates the exact bypass attackers want, because a permitted interpreter will run any script handed to it. Pair the allowlist entry with file integrity monitoring on the approved installation directory, and restrict the interpreter to running scripts from a directory that standard users cannot write to.

Behavioral detection has to cover the gap that signing checks cannot. SentinelOne flags the injection sequence itself across managed environments — a scripting interpreter calling OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread against a hidden GUI accessory it has no reason to touch. Microsoft's attack surface reduction rule blocking JavaScript and VBScript from launching downloaded executable content adds a second, cheap layer on managed Windows builds.

When enforcement breaks something, resist the urge to add a broad path exception; add a publisher or hash rule for the specific binary instead. Review the allowlist quarterly against your software inventory, and treat any new interpreter appearing in a user-writable directory as an incident rather than a configuration issue.

The Critical Next Step: Credential Audit and Monitoring

The practical takeaway is a scoping decision, not a technical one: every credential typed on an affected host between first execution and cleanup should be treated as known to the operator, not merely exposed. A keylogger's output is a transcript, so partial resets leave whatever you missed still valid.

That means your reset scope is driven by time, not by role. If you cannot establish when the interpreter first ran on a given endpoint, assume the full period covered by your available logs and reset accordingly for the users who touched that machine. Staff with access to payment initiation, trading platforms, and customer account management tools sit at the top of that list because those credentials convert directly into transactions.

Two details are easy to miss when you scope the audit. Service accounts and shared administrative credentials typed interactively on the host belong in the reset set even though no individual user owns them. And anything a user typed that was not a corporate credential — personal webmail, a password manager master phrase, a banking portal for their own accounts — was captured in the same transcript, which is why a reset limited to Active Directory leaves real exposure behind.

Perform the reset from a known-clean device. Changing a password while the recording process is still live simply hands over the replacement.

Ongoing, credential exposure is a monitoring problem rather than a one-time cleanup. Adlumin ITDR watches authentication behavior across managed environments, so the use of a credential that was captured months earlier surfaces as an anomaly rather than as a successful login. Audit the affected window, reset on that basis, and keep authentication under observation afterward.