The end state of this campaign is a keylogger and a hidden remote desktop running on a machine your staff still consider clean. SANS ISC handler Xavier Mertens documented the chain on July 28, tracing it from a fake bank email to VIPKeylogger beaconing out to cphost17[.]qhoster[.]net. A separate analysis he references describes the same infection path ending in MedusaHVNC, a hidden desktop tool that lets an operator drive the machine invisibly alongside the real user. (Source: Isc)

The attacker chooses this route because almost nothing in it is malware in the traditional sense. The email carries a RAR archive named Bank_account_details.rar, which contains a VBS script that decodes Base64 data, drops a gzip file, and calls PowerShell to decompress it. That PowerShell then writes three files: a renamed AutoIT3 interpreter, an AutoIT script called wwman, and a shellcode blob called Ennnn.

AutoIT is a legitimate Windows scripting language with a signed interpreter. Threat actors still use it because it is easy to write and can call any Windows API directly — the script here invokes OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread to inject decoded shellcode into C:\Windows\Syswow64\charmap.exe, the built-in Character Map utility. If your endpoint tooling is watching for unfamiliar binaries, it sees a signed interpreter and a Microsoft-signed accessory instead.

Persistence is a plain Run key under HKCU named "Windows32", pointing the interpreter at its script file. So the interpreter relaunches after every reboot, and the injection repeats.

Success for the operator means credential capture from your browsers and applications through the keylogger, plus interactive access via the hidden desktop that survives password resets because they watch you type the new one. Mertens notes he detected a wave of similar emails delivering the same payload structure since the week prior, so this is a campaign rather than a one-off sample.

Execution Flow: AutoIT3 Interpreter Abuse and Payload Delivery

The delivery archive is Bank_account_details.rar (SHA256: 5c4ca58e41c009c664a7134df12b0fdc0815f572e117fe67ca35582f19d9deab), and it holds a single VBS script (SHA256: f88d9094a90f7000a3fb2cd7c981e03357ce2b39df9de5ee1d0742e619e3860f). That script does no injection of its own. It Base64-decodes an embedded blob, writes it to %TEMP% under a random name ending in .bat.gz, and hands decompression off to PowerShell.

The PowerShell one-liner is the first high-value hunting artifact, because it is unusual enough to pivot on. It builds an IO.Compression.GzipStream over the dropped file, copies it into a MemoryStream, writes the result out with [IO.File]::WriteAllBytes(), then calls Remove-Item on the .gz. The source file is deleted immediately after decompression, so disk forensics on a machine cleaned up hours later may only show the resulting .bat.

Execution of that batch file spawns a second PowerShell stage that stages three files into %APPDATA%\SetupFiles\:

• vijewyufveonabghulluonouceyasi.exe — an AutoIT3 interpreter (SHA256: bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1)
• wwman — the AutoIT script, extensionless
• Ennnn — the encrypted shellcode blob, extensionless

Each file is Base64-decoded and then XOR-decoded, using key 0x02 for one payload and 0x3D for another. Single-byte XOR is trivial cryptography, but it is enough to keep the embedded content out of reach of string-matching scanners while it sits inside the script.

The interpreter is then launched with the script as its only argument: "...\vijewyufveonabghulluonouceyasi.exe" "...\wwmaw". This is the pivot that matters for your EDR triage — the running process is a genuine, unmodified AutoIT3 binary carrying no malicious code in its own image. Detection has to come from the parent-child lineage and the arguments, since the binary itself is clean.

Persistence uses a Run key with a masquerading value name (ATT&CK T1547.001, T1036): reg add HKCU\...\CurrentVersion\Run /v Windows32 /t REG_SZ, pointing at the same interpreter-plus-script command line. A value called Windows32 in a user hive reads as system tooling at a glance and survives reboot.

The wwman script itself runs with #NoTrayIcon so the AutoIT tray indicator never appears. Every sensitive string is stored as hex and rebuilt at runtime by a small _O() function — kernel32.dll, OpenProcess, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, and CloseHandle never appear as readable text in the file (T1027, T1140).

Injection follows the textbook sequence. The script reads Ennnn from @ScriptDir in binary mode, XORs every byte with 236 (0xEC) inside a DllStructCreate byte array, then launches C:\Windows\Syswow64\charmap.exe with @SW_HIDE. It opens that process with access mask 0x1F0FFF, allocates memory with flags 0x3000 and 0x40 — commit/reserve, read-write-execute — writes the decoded shellcode, and starts it with CreateRemoteThread (T1055).

Character Map is a legitimate Windows utility that has no reason to run hidden, hold RWX memory, or open network connections. A 32-bit charmap.exe whose parent is an AutoIT interpreter in %APPDATA% is the single clearest forensic marker in this chain, and it is what ties the on-disk artifacts to the running keylogger.

Business and Operational Risk from Remote Access and Keylogging

Two capabilities land on the same machine at the end of this chain, and they compound each other. A keylogger records everything typed, while a hidden desktop gives an operator a working session on your endpoint that the person sitting in front of it never sees.

The keystroke capture is the part that erodes your access controls quietly. Anything your staff type goes to the operator: domain passwords, banking portal logins, the master password to a password manager, one-time codes read off a phone and typed into a browser, and the contents of emails and documents composed on the keyboard. Credentials collected this way work like legitimate credentials, so the follow-on logins look like your own employees signing in.

The hidden desktop changes the economics further. Because the operator works inside a session your user has already authenticated, they inherit whatever that session can reach — mapped file shares, an open ERP or practice-management client, a signed-in email account, saved browser sessions to cloud tenants. Multi-factor authentication protects the login event, and this activity happens after the login event.

Consider which of your people this lure was built for. The delivery was a fake bank email with an attachment named for account details, which is aimed squarely at the person who is expected to open bank correspondence:

• Finance and accounts payable staff — access to payment runs, banking portals, and vendor master records, which is where wire redirection and fraudulent payment changes originate.
• Executives and their assistants — mailbox contents covering deal terms, personnel matters, and legal advice, all of which are readable through a live session without touching the mail server directly.
• IT and helpdesk accounts — privileged credentials typed during routine work, which extend the compromise from one workstation to servers and management consoles.
• Anyone handling regulated records — clinical, cardholder, or personal data displayed on screen and reachable through the same session.

Regulatory exposure follows from the credential theft itself, not only from files being copied out. If your environment holds electronic protected health information, an operator with an authenticated session can view records without generating any access pattern that looks abnormal, and HIPAA breach analysis has to treat that access as unauthorized disclosure unless you can demonstrate otherwise. Under PCI DSS, a keylogger on a workstation with access to cardholder data environments generally puts that segment in scope for incident handling and can affect your assessed status.

GDPR obligations turn on the same question. Personal data accessible from a compromised session counts as exposed, and your notification clock starts from awareness of the breach, which is difficult to establish precisely when the intrusion runs inside legitimate user activity for an unknown period.

The detection problem is what stretches your dwell time. The injected code runs inside charmap.exe, the Character Map utility shipped with Windows, so the process holding the payload is a signed Microsoft binary rather than an unfamiliar executable. Network connections and file access attributed to it will not match the pattern most teams look for when hunting unusual processes.

For the board, the practical framing is this: an incident of this type requires you to assume every credential typed on the affected machine is known to a third party, and to treat every system those credentials reach as potentially accessed. Password resets, session revocation, forensic review of financial transactions, and counsel-led breach assessment all follow, and those costs arrive whether or not files were confirmed stolen.

Detection and Forensic Indicators for AutoIT-Based Injection

Start with charmap.exe. Query your endpoint telemetry for any running or recently executed instance of C:\Windows\Syswow64\charmap.exe, and treat every hit as suspicious until you can tie it to a user opening Character Map. The injector launches it hidden (@SW_HIDE) purely as a container for shellcode, so a copy running with no visible window, no Explorer parent, and no user session activity is the clearest single indicator in this chain.

In the same pass, pull outbound network connections attributed to that process. Character Map has no business reaching the internet, so a socket owned by charmap.exe means the injected code is live and beaconing.

The next hour: process and injection telemetry

• Hunt on hash, not filename. The interpreter dropped here is a legitimate AutoIT3 build (SHA256: bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1) renamed to a random string. The name changes per victim; the hash does not.
• Flag any unsigned or user-writable executable in %APPDATA%\Roaming\ that spawns a Windows system binary as a child process.
• Look for the API sequence in your EDR's injection telemetry: OpenProcess with access mask 0x1F0FFF, then VirtualAllocEx requesting 0x3000 (MEM_COMMIT/RESERVE) with protection 0x40 (PAGE_EXECUTE_READWRITE), followed by WriteProcessMemory and CreateRemoteThread against the same handle.

In environments Capstone manages, SentinelOne flags that remote-thread creation into a suspended system process at the behavioral level, which matters because the interpreter itself is a signed, legitimate scripting binary that file reputation alone will pass.

The next 24 hours: filesystem and persistence sweep

Sweep user profile directories for a renamed executable sitting alongside two extensionless files — in the documented sample, the AutoIT script and the XOR-encoded shellcode were named wwman and Ennnn. That trio in one folder under AppData\Roaming is a strong signature on its own.

Then dump every value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run and inspect the ones that pass a second argument to an executable. This sample used the value name Windows32 with the script path as an argument, since the interpreter needs the script handed to it on the command line. Run keys with arguments are rare in normal software, which makes them cheap to review across your fleet.

If you can read recovered script content, search for AutoIT source that builds API names from hex pairs at runtime — a small decode function converting strings like 6B65726E656C33322E646C6C into kernel32.dll. Static string scanning for API names will miss this entirely, so grep for the decoder pattern and for DllCall instead.

The next week: retrospective hunting

Re-run the interpreter hash and the charmap.exe parent-child pattern against archived process logs going back as far as retention allows, and check whether the same mail wave reached other mailboxes.

Confirmed hosts should be reimaged and the associated accounts reset, including any credentials stored in a password manager unlocked on that machine.

Immediate Containment and Remediation Steps

Isolate the affected host at the network layer before you touch anything on it. Pull the switch port or apply an EDR network-quarantine policy, but leave the machine powered on — the injected payload runs inside a hosted process, and a hard shutdown destroys the only copy of that decoded shellcode you will ever have.

Capture memory next, while the injected thread is still live. A RAM image taken with a tool like WinPmem or Magnet RAM Capture, followed by a disk image, gives your responders the decoded payload, the C2 socket state, and any credentials the keylogger buffered before it sent them. Once you kill processes or delete files, that evidence is gone and you lose the ability to say what was taken.

Then terminate the chain in order. Kill the renamed AutoIT3 interpreter (vijewyufveonabghulluonouceyasi.exe in the documented sample, though the filename is random per victim), then the hidden Character Map process hosting the shellcode, then any PowerShell still attached to the session.

Remove persistence and the staging directory:

• reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v Windows32 /f — the Run value the dropper writes.
• Delete the %APPDATA%\Roaming\SetupFiles folder, which holds the interpreter, the wwman AutoIT script, and the Ennnn shellcode blob.
• Sweep %TEMP% for leftover .bat.gz and .bat artifacts from the first stage.
• Sinkhole or block cphost17[.]qhoster[.]net at your DNS resolver and egress firewall so any host you have not found yet loses its channel.

Block the interpreter itself if your business does not need it. Inventory legitimate AutoIT use first — some vendor installers and internal automation genuinely ship it — then write a WDAC or AppLocker rule based on the publisher and file hash rather than the filename, since this campaign renames the binary on every run. Document the exceptions you grant so the rule survives the next application owner who complains.

Treat every credential that touched the host as compromised. Reset domain passwords for anyone who logged in during the compromise window, revoke active sessions and Kerberos tickets, re-enroll MFA where a one-time code may have been typed on that keyboard, rotate saved browser passwords, and force a new master password for any password manager unlocked on that machine. Adlumin correlates the authentication events that follow — a reset account signing in from an unfamiliar location, or a service account suddenly used interactively — across managed environments, which is how you confirm whether stolen keystrokes were actually used.

Hunt adjacent systems on the same subnet and in the same mailbox distribution before you close the incident. The delivery was email, so other recipients likely received the same archive; search your mail gateway for the RAR by hash and by attachment name, and query endpoints for the SetupFiles path and hidden Character Map executions. Anything that matches gets the same isolation and imaging treatment.

Rebuild the confirmed host from a known-good image rather than cleaning it in place. Restore user data from backup copies taken before the first execution, verify the restored files do not include the dropper, and return the machine to production only after your monitoring shows no outbound traffic to the C2 domain for a full business cycle.

Preventive Controls: Blocking AutoIT Abuse at Scale

Start by answering one question: does anything in your environment legitimately run AutoIT? Most business software does not, and if the answer is no, the fastest control available to you is a deny rule on the interpreter itself. A Windows Defender Application Control (WDAC) or AppLocker publisher rule that blocks binaries signed by the AutoIt project, backed by a hash rule for the interpreter build seen in this campaign, removes the entire execution path without touching anything users need.

If AutoIT is business-critical — some vendor installers, kiosk scripts, and legacy line-of-business automation genuinely depend on it — allowlist narrowly. Approve the specific interpreter version by hash, and approve the specific scripts you run by hash as well. Anything else calling the same interpreter gets denied.

One detail from this sample should shape how you write those rules. The injector script was named wwman with no file extension at all, and it was passed to the interpreter as a command-line argument.

Blocking

.au3

by extension does nothing here. The interpreter reads whatever file path it is handed, regardless of what that file is called.

Write your policy against paths and hashes instead. Deny execution of any interpreter from %APPDATA%, %LOCALAPPDATA%, and the user Downloads and Temp directories, since no legitimate deployment of AutoIT drops itself into a roaming profile folder under a random name. If your developers or vendors maintain AutoIT automation, require it compiled and Authenticode-signed, and configure your allowlist to accept only that signing certificate.

Two upstream controls cut the chain before the interpreter ever lands:

• Change the default file association for .vbs and .js to Notepad through Group Policy, so a double-click on a script pulled out of an archive opens it instead of running it.
• Block or quarantine RAR, ISO, and IMG attachments at the mail gateway, or strip them for inspection — these container formats are used because they carry scripts past filters that look at attachment types.
• Enforce Constrained Language Mode and script block logging for PowerShell on standard user endpoints, which limits the .NET object instantiation that decoder stages depend on.

For monitoring, the highest-value signature is not the interpreter's presence but its arguments and lineage. Alert on any AutoIT interpreter whose parent is wscript.exe, cscript.exe, powershell.exe, or a browser process, and on any interpreter invoked with a single extensionless argument pointing at a file in the same user-writable directory. Legitimate AutoIT automation is usually launched by a scheduled task, an installer, or an explicit user action, and that difference in parentage is easy to baseline over a week of telemetry.

Tune your EDR to treat the cross-process write sequence — process open, remote allocation, memory write, remote thread creation — as high severity when the source process is a scripting interpreter rather than a debugger or installer. Suppression rules written for developer tooling frequently swallow this pattern, so check what your current exclusions cover before you assume the rule fires.

Finally, keep a recovery path that does not depend on cleaning an infected host. N-able Cove maintains recoverable images across managed environments, so when a workstation runs a credential-stealing payload you can rebuild it from a known-good point rather than trusting a removal routine. Pair that with a documented credential-rotation list for the accounts that user touched, and the rebuild becomes a same-day task instead of a multi-day investigation.

Key Takeaway: Disable AutoIT3 Unless Actively Required

The decision this campaign puts in front of you has little to do with any one sample. AutoIT3 is a legitimately distributed, signed scripting runtime with unrestricted DllCall access to the Windows API — which makes it a general-purpose loader that anyone can drive with a plain text file.

Nothing in this infection chain required the actor to compile a single binary. The custom work sat in encoded blobs on disk; the execution capability came from a tool that ships as a normal, downloadable utility. Controls that assume malicious capability arrives as a malicious executable have nothing to grade in this scenario.

The interpreter also arrived under a randomly generated filename, so any mental model that treats AutoIt3.exe as the thing to look for misses it entirely. What matters is what the file is, not what it is called on the day it lands in %APPDATA%.

So the priority is an inventory question, and most organizations have never asked it: does anything in your environment legitimately need AutoIT? Vendor installers, kiosk automation, and older line-of-business scripting sometimes do. Far more often the runtime is present because someone installed it years ago and no one revisited the decision.

Answer that question in writing. Identify which business processes depend on the interpreter, name an owner for each, and remove the runtime from every host that has no documented need for it. Where AutoIT stays, it stays as a recorded dependency rather than an unexamined installed component.

Taking the interpreter off machines that never needed it removes the stage of this chain that performs the injection, and it does so without affecting anything your users rely on.