Analyzing AutoIt Malware: Tools and Techniques

hey everybody it's guy mcdoodfellow co-chair of the b-sides las vegas proving ground track our next talk is analyzing auto it malware tools and techniques by chris neal who was mentored by me guy mcdoudvilla thanks everybody for joining uh my name is chris neal i'm a threat researcher at taos intelligence and i've been there a couple years now and before that i was a sock analyst in the financial sector out here in california and skills wise i consider myself a generalist i have experience with penetration testing incident response malware analysis and just basic reverse engineering and i have a focus on obscure windows malware i like to look at the lesser known stuff because i think it's a

little bit more fun than the more popular stuff and i'll actually be talking about a kind of a kind of an obscure malware in this this talk actually so this presentation is called autowit malware analysis and introduction and in this presentation i'm going to be talking about how to get started with analyzing autoit and this is intended for researchers and analysts who are interested in autoit malware but don't have any experience with it it can be a little difficult to find all the info you need to learn how to do it so i've put all the basics together in a single presentation and hopefully by the end of this you'll be able to know everything

you need to decompile the obfuscate and analyze most most malware written in auto it so first thing we need to understand what autoit is and what autoit is is a it's a scripting language written specifically for windows that's intended for automating administrative tasks or basically anything a user wants to automate and it's a lot like visual basic and it's syntax and it's fairly easy to write and read and it's pretty legible as far as scripting languages go and it can do things like simulate user interaction like mouse clicks manipulating windows and one of its most important functions especially regarding malware is its ability to call functions within windows dlls which i'll go over here in a moment and

it's also compatible with the component object model or com and all of these things make it really attractive to malware authors because it provides a ton of functionality with a pretty small amount of code and there's a ton more functionality than what i've mentioned here and it's it's worth looking through the documentation to get a kind of a better idea of what it can do so here's an example uh code snippet from the auto documentation and it essentially just checks to see if a host can connect to the internet and then returns with either a true or false and it does this by calling a windows dll using the autowit function dll call and in the orange box you can see that

it directly calls the connect.dll and then the function is internet connected within that dll and so an autowit script can be compiled in one of two ways first is as an a3x file which requires auto it to be installed on the host or it can be compiled into a standalone executable which does not require an install and to create the standalone executable the script is compiled with autoexe which tokenizes the script then compresses it and then encrypts it and this tokenized script is then stored in the resource section of the final executable and it can uh it can also optionally be packed with upx during compilation but it's typically not the default setting and to see this

source code after compilation the binaries have to be decompiled with a decompiler that's specifically made for autowit and speaking of decompos decompilers these are the two most popular decompilers out there first being my ought to exe and the second being exc2 ott which both have pretty distinct differences and my favorite by far is my ought to exe it's really versatile and it will decompile almost any malware in my experience and it'll deal with a lot of obfuscation techniques which you can which actually can save you quite a bit of time and it can scan for altered script start addresses which is a fairly common anti-analysis technique and it's also really it has some really useful log output

in case something goes wrong you can go through it and try to figure out what's going on the second one is exe to ought which is different than autoexe the compiler it's pretty fast but at the expense of not being able to handle handle obfuscations scanning altered start addresses and it won't decompile a lot of malware because of that and another big drawback is that it doesn't handle 64-bit executables which is not a good thing in 2021 so this is better suited for non-malicious scripts if you just want to look at some sort of you know boring administration script or something like that but this typically won't work for malware so there's some other helpful tools that

will make your life a lot easier during analysis and a big one is the isn auto auto it's studio which is a free dedicated auto ide and it's got some pretty useful features like debugging syntax highlighting and a built-in code reference which are all really helpful doing during manual obfuscation because you don't have to keep looking up the documentation and all that stuff and it also has a dark mode which won't burn your retinas while you're analyzing these samples which is which is pretty nice and it's also uh really handy to have a just a good old regular text editor which can it can really be whatever you want but i definitely recommend using vs code

just because of the auto it plug-ins and i've found that the regex search in it is really helpful and plus it's just great to have a code editor in general like vs code especially for windows it's got a lot of really really useful functions inside of it and of course for analysis we're going to be using a windows vm and i use windows 10 most of the time and some binary inspection tools like cff explorer or pe studio are good to have as well as a hex editor occasionally and last i used python for any scripting tasks like writing a diffusator which i'll be doing here in just a moment and so now that we've gone over the

basics let's hop into some actual malware analysis and the assembly the sample i'll be walking through today is actually some real world analysis i did for a blog post for for talos and a quick note about malware and ottawit uh tons of malware families have used autoit at one time or another and the families listed here have used it in at least one attack phase during a campaign and this is a non-exhaustive list these are just the ones that i thought of when i was trying to make a list but there's plenty more out there that use autoit besides these so the one we're going to be taking a look at is loader rat 1.1.1

and uh loda is essentially your typical rat that does things like steel browser cookies cache passwords all that good stuff it's not always obfuscated but for this example i chose one that is and um originally it was discovered in 2017 and it's been active ever since it's uh in my experience it's getting a little bit more common as time goes on i've been tracking it for a little over a year now and i actually published a series of blogs on the talus website if you want to go check those out if you want more know more stuff about lota after this so uh onto analysis the first thing we want to do is pop our sample into a

binary inspection tool like this one for example is pe studio and this is the easiest way to tell if you're dealing with a compiled autowit script and here in the orange box you can see that the version info metadata states that the version of auto it which in this case is version three and then of course it's always good to have the sha-256 hash of the malware sample as well so the next thing we want to do is try to decompile the script and we're going to be doing this in our analysis vm and i always start off with my autoexe first because i usually have to switch to it anyways if i use anything else

and once the decompilation finishes the script will appear in top section and we won't be using this interface to do any analysis though my autoexe will actually create files containing these scripts so we're going to be using those in a different program after this and at the bottom you have these output logs when something goes wrong it can be really helpful to figure out what was going on and then uh so speaking of things that can uh go wrong uh what can go wrong when you're analyzing this stuff uh one of the most common roadblocks is the script not decompiling especially with exe to odd which is why i always start out with my ought to exe

instead and not decompiling can be caused by a couple things either the script start address has been tampered with which is pretty common or the decompiler was tricked into decompiling a decoy script and this technique is outside of the scope of this talk but there's a great post about it by unit 42 which i'll be giving a link to at the end of the presentation and then another roadblock you'll run into is obfuscation and it's very likely that if you're dealing with malicious audit scripts uh it will be obfuscated uh which is well we'll be discussing that here shortly and the last thing another reason not to use exe to odd with malware is that it

actually may execute the script and the unit 42 post i just mentioned talks about that so it's definitely worth a read uh to understand how that works okay so let's let's say you've got over those roadblocks and you've successfully decompiled the script um if it's obfuscated it's going to look a lot like this jumbled mess and this giant blob of encoded strings will eventually be decoded when the malware runs it looks worse than it really is and eventually we're going to be able to make sense of all this all this junk and so in in most cases the two types of obfuscation that you're going to see in auto at malware is string and execution flow based and with

execution flow obfuscation the author will try to make the script really hard to follow by adding unnecessary or overly verbose functions or a ton of nested functions or anything that makes it really hard to follow what's going on and with streamlab string obfuscation there's going to be a routine or multiple routines that will decode the encoded strings in real time during execution and typically it will be similar to something like this this is a loaded rack decoding function shown here and it's usually found at the end of the script in most cases uh it's important to note that in auto auto it there's only a few different obfuscation choices that a malware author can use

purely because of the way auto it works and the way that the programming language operates and so our first step with dealing with this kind of obfuscation is to figure out how this function works so the decoding routine will be called hundreds hundreds and hundreds of times in this script so we need to figure out what this routine is doing each time it gets called so we can implement it ourselves and write our own decoder and this particular function takes two arguments the first is the encoded string and the second is a static key of sorts and in loader rat's case this key is stored as a global variable so our goal is to make this decoding

routine uh more readable so we can uh figure out the logic and write our own decoder and the best way to get this done is by replacing all the junk variable names with meaningful ones and we can do also do things to simplify it like putting that static key that's stored as a global variable and put it directly in the routine so it's a little bit easier to read and the code shown here is actually the same routine i showed on the last slide but cleaned up and you can tell that it's just a lot easier to read and a lot easier to figure out the logic behind it and so now that we can read the code we can translate it

into python and here we i have implemented the exact same logic into a function i've named decode and as you can see it's actually pretty simple once it's not so ugly and i've chosen a random string from the malware script and then stored it as a test variable while writing this and it's a lot easier to do this than to test the script on an entire file it goes by a lot faster and uh once i've got the decoding logic worked out i can just run the script and then see if the output is readable in this case i've got it to work and then once i run it i can see that that string equals encrypted

password and so now that we've implemented the code uh the decoding properly we can extend that script to find and decode each instance of the decoding routine being called into malware and i find that the quickest way to do this is to use regex to find each function call and then send the first argument to my python decode function and in this script i have the results print out distinct print to standard output but this can be easily extended to find and replace each instance within the malware itself and then just decoding the script that way but you can also just run the script and then have everything go to standard output and you can see here that just running

my script gives me a pretty good idea of what the malware is doing here in the orange boxes you can see it's doing things like targeting chrome opera filezilla and is likely making multiple registry changes and so there is a lazy way to de-obfuscate this but i don't recommend doing this if you feel that you shouldn't be running the malware because you do have to execute it and so you want to make sure if you're doing this you're going to disconnect the vm from the internet and the way this works is that we're going to be removing any calls to the sleep function and then run the script in isn studio with some minor modifications to the

decoding routine and so what we're going to do is add two calls to create text files and then output some data to those text files we need to add two lines of code to the function in specific places and then execute it first we need a file write function that outputs the current encoded string in a carriage return into a file and then second we have another file write call that writes the decode the decoded string and then a carriage returned to a second file and this gives us two files where an encoded string can be paired with a decoded string by the line number in the text file and sometimes this method is it can save

you some time but most of the time it's worth writing your own decoder because this this method is pretty messy and sometimes it's a little too a little too crude to get things done

and now that we can read the malicious script what should we look for oh redo this slide hold on

now that we can read the malicious script what should we be looking for one of the easiest things to spot are the autowit macros which begin with an at symbol and these won't be obfuscated since they won't work if there's any sort of string manipulation so they're pretty easy to find and these are typically used during system enumeration and the names are pretty much self-explanatory like os version or desktop height these are used pretty frequently to just gather some quick information and then send it back to c2 and so here's a non-exhaustive list of functions to keep an eye out for and as with macros the function names themselves are fairly self-explanatory what you want to look

for here is any interaction with dlls the registry system files or any apparent network functionality but the the function i do want to point out here is uh obj get or object get and this can actually lead to some pretty interesting finds while you're looking through the code because this is how autoit interacts with the component object model or com so always be keep an eye out for this because you'll definitely find something interesting once you once you find one of these and so last couple things is that ottawa malware will commonly store binaries as strings like the ones shown here and this is a sample of loader rat that had a proxy client stored as an unobfuscated

string that would later be converted to a dll using the binary to string function and then that dll could be used in c2 communications and binary stored as strings may or may not be obfuscated just depending on the author's choice and so here we have one last example of a binary being stored as a string and this is from the same lotus sample as the last slide this instance is pretty interesting because this is actually just a sqlite library which is used for the sole purpose of making a single wmi query via the autoit com interface and this query enumerates any antivirus products installed on the infected host and then later on in the script

loader rat will actually attempt to kill any processes that belong to those antivirus products and then uh before i go i just want to give you guys a few more things you can take with you and one of the most important things to do if you want to learn more about this is go out and find some samples on virustotal and just explore the tools that i mentioned that's the best way to learn this stuff it's also really helpful to go out and read the autowit docs in forums uh one thing you don't want to do is don't talk about malware or decompiling in the official autoit forums because they will ban you immediately so uh another helpful thing is to go

look through this decompiler source on github go find the my autoexe stuff and it's all open source and it can be pretty helpful to understand how this stuff is compiled and decompiled and there's a ton of good blog posts out there that have a lot more information and the one i would like to point out was the unit 42 blog on those decoy scripts just look up unit 42 out of it and it'll be one of the first things you get and then i uh did write a series on loader rat that um i've been following for a year or so and uh go look those up if you want to learn more about loader rat they're

pretty interesting i think and hope you guys enjoyed the talk

excellent well that was great uh so i guess what we want to start off with is one of the questions from the channel or from the discord channel uh coolacids asks how often do you come across benign samples and what's the weirdest sample you've come across either malicious or benign sure yeah uh i actually run well i look a lot through like virustotal and you know malware repositories like that so most of what i find is malicious i don't see a whole lot of you know benign things getting uploaded to virustotal but not that it doesn't happen i have run into them i've seen some pretty weird malware that just looks for some pretty strange

stuff like very specific things with uh sometimes like specific games it'll look for game files for you know very like unusual games that most people haven't heard of uh almost like like candy crush games kind of like kind of like that where they just look for any sort of um you know save files and stuff like that and then send it back to c2 and that's literally all it does so there's weird stuff out there like that and then there's a lot of other stuff that is is is quite you know quite dangerous where they you know are looking for any sort of banking information credit card information social security numbers uh stealing credentials and whatever they can so it kind of runs

the whole gamut where there's benign things all the way to you know very malicious uh just depending on you know where you're looking okay what about a breakdown of 32-bit versus 64-bit sure yeah um okay so uh so i believe it's uh ought to exe um or exceed uh the the decompiler i was talking about that actually doesn't really handle malware very well it does not work on um 64-bit binaries so some sometimes you need to convert 64-bit to 32-bit so you can use that d-compiler and there's a great blog by uh hexacorn uh i'll put the link in the discord so everybody can check it out uh that goes over how to do that

it's actually pretty interesting because you just run essentially a script that runs through and changes some bytes um here and there and that's literally it there's not a whole lot of difference between 64 and 32 bit between between them for auto it it's very close um so sometimes you may need to do that i haven't run it too many times but it's definitely a thing that you might run into so i'll be posting the vlog here in a sec sure no worries now i know auto it's been around for quite a while and it predates power shell how widely do is it still used uh versus powershell i mean powershell has some advantages versus auto it so

what how often do you still see it used in the wild uh quite a bit um if you go on let's say you just go on virustotal or something and you just do you know as a string search for auto it version 3.3 or whatever version you're going to find like thousands and thousands of samples and a lot of them are going to be malicious and there's new ones popping up every day i like load of the one i was just talking about i've been tracking that for over a year now and it's you know gotten a lot of traction in the last i would say year um it's still just as common as it was when

people first started abusing it um and in some respects it's more common um with steelers and stuff like that um and so i think the reason it's becoming more popular it has come become more popular is that it's really easy to code when you're reading the code it's super easy to understand you don't have to understand a lot about you know programming paradigms and stuff like that and how to interact properly with you know the windows api and stuff like that and it's it's so easy to you know interact with things like com and um you know some of the more complex apis with windows it's ridiculously easy in auto it so it's just it's a shortcut of sorts it's not nearly

as hard to program and it's really powerful for for what it is okay why do you so with with powershell becoming more integrated into windows i think there it there's no longer any aspect of windows system administration that can't be done with powershell do you see any shortcomings of the autohit versus powershell yeah i i think that the for one to me the binaries are huge if you do the um standalone binaries they're like 20 megs or something like that because it includes it includes like so many different libraries and things like that and um it can be a you know a 1 000 line script and you have like a multi-megabyte file and if you don't want those big

files then you have to have auto it installed on the endpoint um or whatever system you're using so it's kind of harder to use it's not native so it's not as clean to you know use auto i.t like a across an entire network or anything like that and like powershell is integrated so it's just it makes more sense for powershell for like large administrative tasks only like a corporate network or anything like that and um kind of going back to you know it's easier to program auto it's easier to program in so i think that's the main reason why you know people are using that instead of powershell um just because it's not as complicated looking as powershell i

really think that's it yeah i mean it really reminds me a lot of visual basic in some ways oh yeah absolutely sometimes when i see some auto it code i think i'm looking at visual basic but i'm you know not um a lot of similarities like syntax wise okay what about uh server versus workstation do you see any malware that are that's targeting a specific types of installations i have not run across that um to me the the the areas i see ottawa used in a lot are just kind of like you know spray and pray malware just send out a bunch of instances of this malware and hope somebody clicks and somebody you know gets it to run on

their system and then hopefully you'll get something out of it i i don't think i've ever seen something that was really targeted towards specific um like you know operating systems or you know more more kind of advanced tactics it's it's very it's all very basic but it doesn't make it any less malicious or dangerous sure so nothing specifically targeting like ade or you know uh member servers or additional domain controllers or stuff like that yeah not that i've not in the research i've done i have not run across that but i would not be surprised if if there's been someone out there that has has done that because it's auto it's totally capable of doing those

things um as for you know interacting with active directory i'm i don't know if that's like native to autoit but i'm sure it could do that no problem right well it's not necessarily native to powershell either you have to have those modules installed in order to interact with directory true yeah so yeah i mean theoretically i don't see why that couldn't happen so i mean that is probably a pretty good avenue to do some do some extra research in sure are there any other types of frameworks or languages like autoit available for the sort of system administration or is it this is pretty much it um that it's the only one that i know of

it's kind of in this family um where you know it's not just a scripting language it's kind of like a to me it's kind of an in-between between like a compiled language and then like a you know scripting language where you can have like a standard you know compiled binary or you can just run a script if you want to install the library and the uh well the uh you know auto it on on a client or something like that i don't know of any other that are what languages that are like windows specific like auto it um but i'm sure if someone took the time they could make you know python to be kind of similar but

i think that'd be quite a task to you know compete with ottawitt sure what about comparing this to something like ansible or chef where you're doing deployment work and you know you're installing things at a target but you're making sure that you know you're you're this this whole idea of um only changing the state once is that something that ottawa supports or is that more of a configuration management paradigm yeah i i don't think ottawa supports that like as it is um i know a lot of it is just for uh automating like tedious stuff like you know if you need to go through and just like change some settings or something on a on an endpoint

you know you can push it out through uh whatever you know whatever an admin uses to push stuff out so i i don't think it you know goes quite that far but yeah i mean i'm sure someone could also implement implement that as well because ottawa is from what i've seen and what i've you know done some research on it it's really versatile and it's really powerful for being such a simple language okay all right all right so we've got about two minutes left um looking to see if there's any questions left in the channel is there anything that you didn't have time to add that you'd want to touch on now hmm let's see i i think the

the main thing with the hexacorn blog i was talking about because that's a that's one thing you might might run into um and one thing i would like to touch on just just real quick is that um one of the hardest things about researching autoit is understanding how like the the compiler actually compiles auto it and like tokenizes the script and then you know store like compresses it and then stores it in the resource section that's all closed source so um if you do want to get involved in that it's a it's a bit harder actually quite a bit harder than just learning how to decompile and stuff like that so that's one thing i'm i'm personally

going to start looking into um because it's it's not a common thing to know a lot about so uh i think if you do want to get into that the best way to do that is start looking at the decompiler githubs going through the source code and then just seeing what they're doing and um because you know they've gone through and done all the work of understanding it so i think it's the best way to uh understand it if that's what you want to do sure okay well excellent well thank you so much and uh this has been a great talk i learned a lot thanks and yeah thank you very much thanks thanks for having me