Operating with AutoIt
AutoIt for offsec assessments.
Image credits: Jon - https://www.autoitscript.com/site/autoit/graphics/
Background
Earlier this year, I was working on building a little user simulation into one of my active directory labs. Nothing dramatic - web browsing, reading emails in Outlook, opening and closing apps at certain times. I was hoping simulating “regular” user behavior like this in my lab would make it more realistic and allow me to easily create and automate additional attack scenarios for my personal research and training gigs.
After a few Google searches and a tip from a friend, I came across AutoIt; which I had heard about before but never actually looked into or interacted with. I discovered that it’s a popular scripting language frequently used for Windows automation tasks.
Using AutoIt to automate Windows UI interaction is incredibly simple and I had some of the scenarios I wanted to build working in little to no time. My troubles started with me learning that AutoIt is capable of a lot more than basic UI automation tasks. I fell into a bit of a rabbit hole (that I honestly still can’t explain) toying with some of the language’s other capabilities.
OffensiveAutoIt
I’ve documented most of my notes and experiments from my on and off again relationship with AutoIt in the OffensiveAutoIt repo on GitHub. This blog post and the other posts listed here are supplementary material for the content found in the repo.
AutoIt
Here’s an explanation of what AutoIt is from its main site:
AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting.
AutoIt is also very small, self-contained and will run on all versions of Windows out-of-the-box with no annoying “runtimes” required!
AutoIt was initially designed for PC “roll out” situations to reliably automate and configure thousands of PCs. Over time it has become a powerful language that supports complex expressions, user functions, loops and everything else that veteran scripters would expect.
AutoIt and malware
Even though I had no idea about it when I first picked it up, it didn’t take me too long to find out that AutoIt has something of a reputation in the malware development/research world.
Probably because of how easy to pick up it is, you’ll see AutoIt frequently mentioned in discussions about skidware. But it isn’t only limited to skids; diverse threat groups have also used AutoIt for various purposes in a number of their campaigns.
So why this blog?
AutoIt is NEVER going to be the best language for malware development or Windows post-exploitation tooling and I won’t try to make it out to be at any point (seriously, it can be a real pain in the ass sometimes). I wrote this blog mostly to give examples of some situations where AutoIt might be useful during security assessments or for personal research - it doesn’t hurt to have options, right?
Use cases
The list below highlights some situations where AutoIt could be useful in the field. It not a comprehensive list, just a few ideas I had while messing around in my lab.
- AutoIt pre-installed
- Delivering separate payloads
- Execution in the context of a signed process
- .NET CLR
- UI automation and sending keystrokes
1. AutoIt pre-installed
Even though I’ve personally never encountered it, there are bound to be some environments out there where AutoIt might be installed on user PCs or servers. Remember, it’s a language frequently used for automation tasks by system admins.
If you’re ever in an environment where AutoIt is already installed on target systems, then there’s potential to abuse this opportunity to live off the land. You can write all your evil little post-exploitation scripts, upload them to the target system and use AutoIt3.exe as a medium to execute all your tradecraft.
2. Delivering separate payloads
A significant amount of AutoIt malware in the wild involves threat actors using AutoIt as a dropper/loader/packer for other payloads. Some notable examples include:
- Zebrocy - Downloader implants used by APT28 to deliver additional malware during their campaigns.
- CypherIt - A commercial packing service used by a wide variety of malware families.
- Frenchy shellcode - An AutoIt loader with a number of evasion and obfuscation features built in.
Some of the features CypherIt was advertizing. Image credits: https://raw-data.gitlab.io/post/autoit_fud/
I put together a few basic process injection scripts as examples of how simple it can be to use AutoIt to inject shellcode into target processes.
Injecting MessageBox hex shellcode into notepad.exe.
3. Execution in the context of a signed process
This is no doubt another reason why malware authors have been attracted to AutoIt in the past. AutoIt3.exe is a signed binary, meaning it’s possible to use it to execute any scripts you’d like to in the context of a signed/trusted process without having to jump through hoops to acquire or spoof your own code signing certificate.
I should mention that you don’t need to install AutoIt on target systems to use AutoIt3.exe. Just upload it and the script you want to execute on any Windows box and you’re good to go.
A keylogging script running in the context of the signed AutoIt binary.
4. .NET CLR
You can use AutoIt to host the CLR and execute .NET assemblies and even unmanaged PowerShell. Yeah, seriously…execute-assembly from AutoIt.
Some of the most fun I had playing with AutoIt was using the templates in the awesome AutoIt .NET CLR library to put together a PoC that wraps .NET assemblies in an AutoIt script and executes them using AutoIt3.exe. I documented the process in a separate blog post.
5. UI automation and sending keystrokes
This was the reason I picked up AutoIt in the first place and probably the reason I’ll keep it in my toolbox going forward. I’ve never been in situation where I’ve had to use UI automation during an engagement, but it’s been a sweet value add to the labs I use for personal research.
Developing UI automation/interaction tasks with AutoIt is a cakewalk. It’s definitely not the only publicly available option providing the capability to interact with Windows GUIs - but it is by far one of the easiest to learn and use.
Majority of the UI automation scripts I wrote are mostly janky user simulation programs and aren’t any fun. But I did decide to mess around and try using AutoIt’s UI automation and keystroke features to dump credentials from password managers.
Using UI automation to dump credentials from Bitwarden. View in fullscreen.
AutoHotKey
Just an FYI - an alternative worth mentioning for painless UI automation that’s blown up in popularity over the past few years is AutoHotKey.
AutoHotKey is an open-source and free scripting language for Windows, primarily developed for software automation, keyboard emulation and fast macro-creation.
Oh…before you ask - yeah, malware devs are already on it 😅
Detecting AutoIt malware
I listed a few resources that could come in handy when building or researching detections for AutoIt based tooling here.
There are also some great malware analysis posts worth checking out here. Feel free to send a pull-request and contribute more.
Conclusion
There are bound to be more hacky hacky use cases for AutoIt aside from the examples I’ve mentioned in this blog. I have to admit that I haven’t actually used any of this stuff outside of my own personal lab, but who knows - maybe I will someday ¯\_(ツ)_/¯
I’m not looking to convince anyone to learn yet another language - especially one that’s already got such a storied history of abuse in the past. But if you ever decide to go down this particular road, for whatever reason, then I hope that the content here will be useful.
References
- OffensiveAutoIt repo - https://github.com/V1V1/OffensiveAutoIt
AutoIt resources
