McMcbrad
Level 20
- Oct 16, 2020
- 967
Hi all,
I'm sure by now we have all heard about Emotet threat. The way it gets distributed is via documents with malicious Macro. Users are tricked into executing the macro.
Upon execution PowerShell is launched usually with -e argument (encoded string). After the -e argument an obfuscated code can be found.
To test antivirus protection capabilities, I have created an Emotet of my own.
It's actually a fairly simple loader.
It contains highly-obfuscated code, which has 3 commands only: it imports BitsTransfer Module, downloads a malicious file (really malicious,) and then runs it. This simulates the Emotet delivery method.
This is how my Emotet-wanna-be looks like.
View attachment 249029
Upon uploading it on VirusTotal VirusTotal
I saw there are 4 products flagging it immediately. Kaspersky, Eset, ZoneAlarm (Kaspersky again) and Cat-QuickHeal.
I then created a second version of it:
This time it didn't use a -noexit argument, which makes it less suspicious.
This time it has been detected only by Kaspersky.
More advanced explanation:
The sample imitates an Emotet loader, in fact I got inspired by Emotet, which Microsoft claims to have blocked with machine learning model in seconds... there was this sort of post on their blog, if I am not mistaken. Hope the Emotet team doesn’t come after me with copyright claims
So I downloaded a malicious sample and uploaded it on a benign website (won’t disclose all details for security reasons). This way I bypassed web filter blacklists
The Emotet loader simulator uses BitsTransfer (Emotet uses System.Net.WebClient) to download the malicious file and write it on the Desktop. Writing to the desktop decreases machine learning sensitivity as opposed to writing in temp folder or somewhere else.
To make things a bit more interesting, I used a hex editor to modify slightly the malicious file downloaded, which bypassed any reputation technologies. Finally, PowerShell executes the sample. To decrease machine learning sensitivity throughout the whole process, on the second sample, I’ve removed attributes such as hidden window, no exit and others.
I used a tool widely available on the web to obfuscate the code, just like Emotet creators do. It hasn’t been encoded with base64 (unlike Emotet) but has been concatenated, which makes it human unreadable and also, bypasses signatures and heuristics. To bypass the execution policy, I ran the code as an argument, not as a script.
It took me less than 20 minutes to do all that and the result - few of them failed already. The malicious sample was a variant of nanocore rat (known for its privilege escalation) and was successfully executed in all test cases. There was not even a UAC prompt. Avast’s IDP kicked in and removed nanocore, but wasn’t smart enough to correlate it to my loader. Defender and Malwarebytes did nothing. Kaspersky detected everything upfront, Eset detected the first one, probably due to attributes, commonly used by malware.
I'm sure by now we have all heard about Emotet threat. The way it gets distributed is via documents with malicious Macro. Users are tricked into executing the macro.
Upon execution PowerShell is launched usually with -e argument (encoded string). After the -e argument an obfuscated code can be found.
To test antivirus protection capabilities, I have created an Emotet of my own.
It's actually a fairly simple loader.
It contains highly-obfuscated code, which has 3 commands only: it imports BitsTransfer Module, downloads a malicious file (really malicious,) and then runs it. This simulates the Emotet delivery method.
This is how my Emotet-wanna-be looks like.
View attachment 249029
Upon uploading it on VirusTotal VirusTotal
I saw there are 4 products flagging it immediately. Kaspersky, Eset, ZoneAlarm (Kaspersky again) and Cat-QuickHeal.
I then created a second version of it:
This time it didn't use a -noexit argument, which makes it less suspicious.
This time it has been detected only by Kaspersky.
The sample imitates an Emotet loader, in fact I got inspired by Emotet, which Microsoft claims to have blocked with machine learning model in seconds... there was this sort of post on their blog, if I am not mistaken. Hope the Emotet team doesn’t come after me with copyright claims
So I downloaded a malicious sample and uploaded it on a benign website (won’t disclose all details for security reasons). This way I bypassed web filter blacklists
The Emotet loader simulator uses BitsTransfer (Emotet uses System.Net.WebClient) to download the malicious file and write it on the Desktop. Writing to the desktop decreases machine learning sensitivity as opposed to writing in temp folder or somewhere else.
To make things a bit more interesting, I used a hex editor to modify slightly the malicious file downloaded, which bypassed any reputation technologies. Finally, PowerShell executes the sample. To decrease machine learning sensitivity throughout the whole process, on the second sample, I’ve removed attributes such as hidden window, no exit and others.
I used a tool widely available on the web to obfuscate the code, just like Emotet creators do. It hasn’t been encoded with base64 (unlike Emotet) but has been concatenated, which makes it human unreadable and also, bypasses signatures and heuristics. To bypass the execution policy, I ran the code as an argument, not as a script.
It took me less than 20 minutes to do all that and the result - few of them failed already. The malicious sample was a variant of nanocore rat (known for its privilege escalation) and was successfully executed in all test cases. There was not even a UAC prompt. Avast’s IDP kicked in and removed nanocore, but wasn’t smart enough to correlate it to my loader. Defender and Malwarebytes did nothing. Kaspersky detected everything upfront, Eset detected the first one, probably due to attributes, commonly used by malware.
Last edited:
