Sunday, November 22, 2015

MMD-0044-2015 - Source code disclosure (part1) of bunch of ELF malware

MalwareMustDie,NPO is a white-hat non-profit security research workgroup launched in August 2012 for/by security professionals and malware researchers gathered to form a work-flow to reduce malware infection in internet. In this opportunity I, hereby, on behalf the active projects and field operational ELF malware research, am sharing first series of ELF malware source code collected in action and secured in 2015, wrapped in a form of RAR(version 5) password-archive.

As per internally decided, the archive was uploaded to the virus total with the hash of:

SHA256 (ELF-malware-in-C-leaks.rar) 
The password has a high character count and the archive was built in a way to avoid brute. You can receive the password by requesting it commenting this post with informing your current active email address and the detail of which security entity you are actually working with (or anti-viruses office, or law enforcement, or government related research you worked with, as entities allowed t receive these code) and the comment will not be published to the public, please feel free to test it first.

We will check each request. We do not share these codes to the individual/independent person without a clear information. Please bear with the slowness in response due to the check process and due the fact that we are a non-profit organization, with limited resources and only active in our spare time.

The archive will stay online for two months, after that period we won't share it anymore and will delete our files. Don't request the code after this time has passed. Please see Disclaimer and Sharing Guide for more information-->[here]

What can be achieved by these source code are:

- better mitigation of the leaked ELF botnet specific type/variants
- some hard coded clue for the distribution DOS attack logic to research
- several exploitation research that can be implemented by each ELF botnet
- you may publish research of these code(s), on a condition: mention us, #MalwareMustDie.
  (we really did hard effort in achieving, collecting & testing these codes, for free)

Below is the snapshot of the original archive, that you will see after you open it correctly.
The total codes shared in this part is 21 (twenty one) source code, all in C except one bonus in html.

I think I will see how this first part of the sharing goes, for the next part (part 2 of sharing) will be focusing on the share on source codes for the ELF threats that is coming from "specific" region :-)

Cheers from #MalwareMustDie

Thursday, September 17, 2015

MMD-0043-2015 - Polymorphic in ELF malware: Linux/Xor.DDOS


A share of knowledge I have, hopefully to make internet safer - @unixfreaxjp

The threat of Linux/XOR.DDoS, a China-made ELF backdoor & ddoser malware, a rather specific threat compares to other Chinese ELF ddosers, and it's still on going. I just received a good question (from I assumed from a victim of infection or a researcher) about why the found malware binary is not the same as what was firstly executed one. Well, this writing is short and covering the answer for the asked question only. But, the information maybe important for the mitigation and detection, and also various methodology I use for the sharing to other NIX mates, so I write this post with three processes I conduct to every ELF malware investigation: in reversing, debugging and forensics ways. Please bear with the poor english since I had few time to check, or to the lack of the explanation.

Polymorphic is a behavior of malware during self-reproduction constantly changes ("morphs") the file characteristic (size, hash, etc), and it may not be the same with the previous copy or as previous pre-infection state. The goal of this changes is to makes it difficult for signature-based antivirus software programs to recognize and detect the polymorphed malware.

Polymorphic method in malware is an usual practise in windows malware. In UNIX malware maybe it is not as commonly heard as in Windows; but since the nature of NIX malware are coming from networking, either to be "extracted" from encoder/infector files, downloaded or dropped by other malware from the beginning, so..I guess we have many hashes by default. But in this post, we are actually dealing with a polymorphic behavior malware just like ones infecting Windows during the self-copy method.. so I guess it is worth to write a bit.

The reported case was a real infection, a case of known gang/crooks, I am allowed to post the the attack log as per following:

Yes, it is a recent attack, please block the IP addresses.

The above log is typical Linux/Xor.DDOS ssh brute attack pattern. I announced the case not so long ago here (different cases, same attacker)-->[link] and the recent incident was reported too in here-->[link]. I uploaded this ELF malware sample into Virus Total w/the link is here-->[link].

Polymorphic PoC

When Linux/XOR.DDoS malware was executed, it will come to the stage that it seeks the place to self-copy it self, in my case the linux system call can show us the effort to write file like:

open("/usr/bin/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777) ; depends, in mine is -1 EACCES (Permission denied)
open("/bin/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777)     ; depends, in mine is -1 EACCES (Permission denied)
In a well-hardened linux system and if the malware is not executed as root you should see the same result as per pasted above. And that time the malware will aim to the only their favorite heavenly place to copy: /tmp :
open("/XOR.DDOS.SAMPLE", O_RDONLY)      ; initial exec malware open itself
lseek(3, 0, SEEK_SET);                  ; set LSET to OFFSET to READ
open("/tmp/lgjgjmkkgd", O_WRONLY|O_CREAT, 0777); open self-copy target w/perm 777
read(3, "\177ELF\1\1\1\0\..");          ; read the malware bin
lseek(4, 0, SEEK_SET)                  ; set LSET to OFFSET to WRITE
14878 read(3, "\177ELF\1\1\1\0\…       ; copy process read..
14878 write(4, "\177ELF\1\1\1\0\…      ; copy process write

By reverse engineering the ELF malware, after seeking for a while, the assembly procedure below is responsible for the above operation: (the bigger picture click-->>THIS )

You can see the cascade of jumps during each error that might occur until it ends up to the accessed one for the self-copy purpose, starting from /usr/bin to /bin , and in my case it is ended with /tmp/[randomname]. The filename is random and the full path with the directory aimed is to be "fired" via an original API to execute the execve(), but we will go to this topic later on.

In Linux memory forensics the blob data copied can be seen clearly with some beautify effort, a good old hexdump is still a favorite in dealing with raw hex data:

## Copy process illustration (read and write of copy process) in the end of file:
00098bd0  6d 65 00 5f 64 6c 5f 6d  61 70 5f 6f 62 6a 65 63  |me._dl_map_objec|
00098be0  74 5f 64 65 70 73 00 5f  6e 6c 5f 43 5f 4c 43 5f  |t_deps._nl_C_LC_|
00098bf0  49 44 45 4e 54 49 46 49  43 41 54 49 4f 4e 00 5f  |IDENTIFICATION._|
00098c00  64 6c 5f 6e 73 00 5f 6e  6c 5f 6c 6f 61 64 5f 6c  |dl_ns._nl_load_l|
00098c10  6f 63 61 6c 65 5f 66 72  6f 6d 5f 61 72 63 68 69  |ocale_from_archi|
00098c20  76 65 00 77 63 74 72 61  6e 73 00                 |ve.wctrans.|
And the copy process was ended gracefully, as per debug check shows in the system call below:
read(3, "", 4096):   ; EO/termination w/no space
close(3);            ; end of copy (reading)
close(4);            ; end of copy (writing)

Nothing so special about operation above, but it is related to the next steps, let's go forward.. Now, we can see up to here that the malware was self copied! But why the file gets different?
The next system's call showing the effort to open the written file afterward with flag to write.. What's going on?

open("/tmp/lgjgjmkkgd", O_WRONLY); ; opening the copied file
lseek(3, 0, SEEK_END) = 625707 <==size  ; set LSET to the EOF for writing
; SEEK_END = *)    ; note the size of original malware
It looks like the pointer of LSET used to write is pointing to the end of the file itself, noted the SEEK_END flag. For the illustration see the paste "*)" position below:
## Illustration of the LSET set in the end of file..

00098bd0  6d 65 00 5f 64 6c 5f 6d  61 70 5f 6f 62 6a 65 63  |me._dl_map_objec|
00098be0  74 5f 64 65 70 73 00 5f  6e 6c 5f 43 5f 4c 43 5f  |t_deps._nl_C_LC_|
00098bf0  49 44 45 4e 54 49 46 49  43 41 54 49 4f 4e 00 5f  |IDENTIFICATION._|
00098c00  64 6c 5f 6e 73 00 5f 6e  6c 5f 6c 6f 61 64 5f 6c  |dl_ns._nl_load_l|
00098c10  6f 63 61 6c 65 5f 66 72  6f 6d 5f 61 72 63 68 69  |ocale_from_archi|
00098c20  76 65 00 77 63 74 72 61  6e 73 00 *<====          |ve.wctrans.*) <==
And then we have these two operation called timeoftheday() and writing the specific strings in the end of the file:
gettimeofday({1442479267, 397488}, NULL) ; for randomid() seed..
write(3, "wlpvpovdvi\0", 11) ; 'size is set to 11'
    ; write string "wlpvpovdvi\0"-
    ; in the LSET position (EOF)
So this is what happened for BEFORE and AFTER the writing:

So we see the file was added to 11 characters, which means we should have 11 bytes bigger for the size of file after this self-copy process, we'll get there..hang on!

Following the calls of the malware process, we can see the new file was saved:

close(3)  ; end of writing process..
And executed! Noted: execve() function is used to spawn the shell command.
execve("/tmp/lgjgjmkkgd", ..); ; main running process of XOR.DDOS in new PID
                               ; with new size (& hash)
You can see how it was executed in the saved process data in the /proc :-), so believe me, it doesn't really any fancy tools for UNIX forensics, since UNIX gods already provided us openly with everything:
lgjgjmkkg 14881 MMD  cwd   DIR  8,6     4096        7209106 /TESTDIR
lgjgjmkkg 14881 MMD  rtd   DIR  8,1     4096              2 /
lgjgjmkkg 14881 MMD  txt   REG  8,1   "625718 <== NEW SIZE" 829 /tmp/lgjgjmkkgd
lgjgjmkkg 14881 MMD    0u  CHR  1,3      0t0           1028 /dev/null
lgjgjmkkg 14881 MMD    1u  CHR  1,3      0t0           1028 /dev/null
lgjgjmkkg 14881 MMD    2u  CHR  1,3      0t0           1028 /dev/null per seen here it runs in new PID , not clone nor forking/threading since execution used the shell spawning. See the new size, it gets bigger by 11 bytes.

Below is the illustration of malware samples original and after copy-injected.

$ md5sum XOR.DDOS.SAMPLE lgjgjmkkgd
"7642788b739c1ee1b6afeba9830959d3"  XOR.DDOS.SAMPLE
"df50d096fb52c66b17aacf69f074c1c3"  lgjgjmkkgd

$ ls -l XOR.DDOS.SAMPLE lgjgjmkkgd| awk '{print $5, $6, $7, $9}'
"625718" Sep 17 lgjgjmkkgd
"625707" Sep 17 XOR.DDOS.SAMPLE
We have different hash and size.

Okay, we're done with the debugging and forensics. Let's see how the reverse engineering goes for this ELF malware binary for the above processes.

This is the part where the malware self-copy process was executed in my sample case. Noted: there are so many cases to trail with the similar codes in copying, write files and randomizing them, I counted about more than 4 scenarios prepared for this operation and the author really calculate every possibilities in his code to make sure the malware will run.

the jump to 0x804dfc2 will take you to the next process.

The assembly snip below is explaining the writing process to the done-copied file by the malware, it is not using the randomizing 11 characters but the malware was picking a hard coded xor crypt strings that is saved in 0x080cf120 (symbol: str.__Ff3VE._7).

The snprintf() is an API function that will lead (in the VERY end) to SYS_write at sys/syscall, since we deal with the statically compiled ELF many libc trails will appear in reversing the function, we may see more of these, sorry to say, unnecessary codes.

The timeoftheday() result which was shown during debugging is caused by the function which was called, named function randomid().

↑Obviously, is a self-explanatory that the timeoftheday() is fetching the system time as the seed needed in randomid() function.

There is an additional information too actually: I think maybe it is good for our community to know too: Linux/XOR.DDoS ELF malware is using a uncommon seen function to execute the shell command, it was called: LinuxExec_Argv() and LinuxExec_Argv2(), which was called to act as an API to execute non direct syscall basis commands by the malware (well, this is a static compiled binary), these functions are typical in characteristic, it is a very simple in use, easy to spot (smile) and these are responsible to call execve(), a linux system call commands (with the environment parameter parsed) to be executed during an infection, and also to call execvp() for the file execution purpose (with parsing the file path), i.e. shown in the code below:
You may want to see the reference of exec method with UNIX C library (libc) on execve, execvp at man(2) pages, and yes, UNIX gods are also providing us with good reference too.

Conclusion & reference

Yes, Linux/XOR.DDoS malware after copied and executed (read: successfully infecting us) will have a different size (11 bytes bigger..depends.. I only check one binary for this), and have a different hash. So this means that the malware spotted in the panel may not be detected by the scanner used inside of the Linux box if only detecting by the hash.

Many of us still think, Yeah..ELF malware..won't harm us or end users much.. But remember, IoT are mostly linux basis, take a look of the most of router's OS now. Also, the infection method and volume of ELF malware is getting better and bigger by days. As proof: We have about 6 of new ELF malware for 2 and half years span only! As MMD (read: MalwareMustDie, NPO), we suggest to be prepared to update the ELF malware detection quality as earliest as possible, once an ELF malicious binary hit a server the impact can be way much bigger than a PE hit a PC.

Below are links to the previous Linux/XOR.DDoS analysis:.

The "new" CNC of the threat:

Oh btw,the CNC is very alive even now...and sending the download/payload too. here's the pcap snips for a hard proof:

Kudos folks for convincing me to upgrade to git version from /usr/ports one:

Stay safe folks! Hope this short writing helps!


Saturday, September 5, 2015

MMD-0042-2015 - Hunting Mr. Black IDs via Zegost cracking

This is a short writing, Please bear the straight forward detail w/very few of explanation.
During investigating ELF malware I met this Windows PE binary, it contains an important infrastructure information used by Mr. Black actor (the one who loves attacking our MIPS routers), so I decided to check and post a bit here.

Win32/Zegost.rfn [link] (according to Microsoft)

The malware is sitting in the panel waiting to be distributed by the time I spotted:

The actor who put the PE binary in the picture was attacking my "router" with the other ELF binary one, a MIPS architecture of Linux/Mr.Black, a family of Linux/AES.DDoS, a China ELF backdoor and DDoS'er variant, with the source IP of attacker and CNC lead to that panel's address.

Seeing the panel, knowing that the PE (exe file) malware wasn't being distributed yet by the actor, so I decided to grab, analyze and expose it first, and then I may consider it being "even" for their attacking effort to my "router" (noted the quotes).

The PE is a Win32/Zegost variant, the dropper/backdoor type, I uploaded it in VT here --> [link], It drops, self deleted, auto-start set in registry, starting service (also set in many of the other boring stuff, and the point of interest of I am writing here is contacting mother hosts as backdoor.Below are some reversing snips I did during ID-ing the threat..

The infrastructure

The PE has the CNC hostname permutated DGA function and I managed to extract some of them:

Noted: The callback hostnames increased after we allow several CNC downloads. The malware DGA is generating many other fake domains.. For the botnet dissection, please focus is with the actual CNC established IP addresses only.

And each domains I checked as per snipped picture below:

I use the Kelihos fast flux milking script to milk IP addresses of the above domains:

$ cat domains.txt | bash
Kelihos FLUX check script by @unixfreaxjp
Sun Sep  6 01:04:57 JST 2015








The result of the IP milking is some of static legit IDC IP addresses in Beijing, China :-) as per listed below... At the first sight I thought these are CNC, but later on I found it very weird :-)||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | Beijing Qihu Technology Company Limited||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network||23724 | | CHINANET-IDC-BJ | CN | | ChinaNet Beijing Province Network
I investigated to find the IP addresses listed above IDC are belong to, a legit service in PRC/China.

But there's only one IP address that shows different network, this leads us into a malicious utilized host in South Korea, and this is the malware panel's IP address itself..||4766 | | KIXS-AS | KR | | Sudokwonseobubonbu
The GeoIP confirmed:
"country":"Korea Republic of"
"isp":"Korea Telecom"

Shortly, that IP address (port 8086) is the only IP communicated with the malware via hostname: Law enforcement may prefer to have this PCAP traffic as PoC/evidence. The callback traffic was replied by the CNC and was sent in encrypted form as per recorded in traffic below, I am sorry, I didn't have energy to crack this further..

..and get the ID :-)

So..I have collected the first three (3) DGA generated basis domains from malware sample which are:
but the #1 and #3 are legit services.

There is only one domain that is really being used as CNC (see the PCAP), the other domains are just being used as decoys to confuse the investigation. And the real CNC hostname is :

"" w/Registrant email: ""
So now we learn more about the nature of Zegost in generating DGA and faking CNC domains.

Malware is served under domain which is having a super bad reputation in being used by Mr.Black ELF attacks and many more ELF attacks, for example:

Thanks to reddit folks to inform that the is a part of a Chinese dynamic hostname/DNS (DDNS) service provider.

We didn't know this detail until now. So it looks like that their services is used by the malware activities. It means the actor can be traced via contacting the abuse accordingly. We're on it for we have long list of malicious subdomains used now.


Thursday, September 3, 2015

MMD-0041-2015 - Reversing PE Mail-Grabber Spambot & its C99 WebShell Gate

I don't know about the origin of the infection, but when I talked with Mr. Christopher Lowson while examining the CNC of the threat, I guessed a PC was infected with this malware and the callback is why me and Mr. Lawson talked. Beforehand, thank's to the Emerging Threat to allow me to write this up, I will start this report from the malware analysis to its CNC gates, in as secure manner as possible.

The unknown SFX RAR .Net PE malware (sounds lame enough?)

The sample is a PE (6222e15ed2c71429c472e5f0fa40d727) and it was reported a week ago (2015-08-27 15:10:48 UTC). A grep info in pescanner will show you:

File:    ./Release.exe
Size:    263514 bytes
Type:    PE32 executable (GUI) Intel 80386, for MS Windows
MD5:     6222e15ed2c71429c472e5f0fa40d727
SHA1:    a9316503ad6dd9e10fa8506fe69cc5aa7cc4eafe
Date:    0x54E0521F [Sun Feb 15 08:00:31 2015 UTC]
EP:      0x41d7cb .text 0/4
CRC:     Claimed: 0x0, Actual: 0x4a8a2 [SUSPICIOUS]

The CRC differences is showing packed/archives or both, I tend to check further the insides for sure with my beloved UNIX shell reversing tool, the almighty radare:

..this is showing overlay of SFX Rar file. A test (t command) in unrar shows the contents safely:

Testing     MAPIEx.dll                            OK
Testing     NetMAPI.dll                           OK
Testing     aa.exe                                OK
Oh, it seems there are two run time dll to run the aa.exe, Let's check again what is the aa.exe:
MD5 (aa.exe) = fa056e635791f18b21898bc0ff6a9978
aa.exe: PE32 (GUI) Intel 80386 Mono/".Net assembly", for MS Windows

The above result is a self explanatory. The point is: Always do static analysis beforehand, it is very important to recognize which binary we are dealing and how is the best way to deal with before we start firing some disassemblers to check its bits or opcodes.

Okay, since now we know how it's developed, let's decompile it in the same way it was built. You'll find these loaded resources:

OutlookContactsViewer.Form1.resources (Embedded, Public)
OutlookContactsViewer.Properties.Resources.resources (Embedded, Public)

The above resources is having the code to execute the malware, so the rest of this reversing is just depending on our skill to read that code.. I will cover the important parts only to PoC the badness of this binary and won't share the full code for the security purpose, as follows..

Peeling the malcode :-)

This is how the malcode was started... by initiation some variables and starting the main function to call to its loading-form:

And the loaded form has the main code of main functions for overall malcode operation:

As you can see it has two commands of "extract" and "spread". Between the "===" delimeter string, the data/text will be filled by email addresses grabbed from functions: GetMailsFromContacts(), GetMailsFromHeaders() and GetMailsFromMessages().

Functions called due to the "extract" command is the text formulation of the strings following by the POST command to send data to the web gates with URL defined in the initialization variable part.

Now we know the purpose of the runtime file is; NetMAPI library was used to perform email-grabbing act i.e. as per snipped below code in GetMailsFromContacts()

..and it is added with the regex to grep the email addresses in GetMailsFromHeaders() and GetMailsFromMessages() parts:

The same library also being used to spread spam via "spread" command (below), is a PoC that we also have a kind of spambot too here. Noted that the subject, body message and the attachment variables hard coded in the initiation part was stored here:

I snip some significant codes (only) that's utilizing HTTP protocol for uploading grabbed emails to the gate as per below, to understand and to figure ways to mitigate the threat further:

To be noted this malware reads the multipart encoded part of an email too:

A sample traffic captured for the uploads is here:

So we have the good idea what the malware is doing, yes? It sends spam, it grabs email address and uploaded them to the remote gate.

The gate

The gate is a hacked sites, I spotted the c99shell by the first time I see it. I spent much time studying c99shell before, the link is here-->[link]. This one looks injected to the compromised web site via PHP vulnerability that allows remote file uploading.

It is the latest standard version noticing this command list:

This is the up.php gate's code:

So this is how the up.php works in receiving the request, using GeoIP (by Maxmind) API to check the location of POSTed IP, making directory of that country code (if not exist) and writing files with the list of grabbed emails in it (if succeeded), it explains many directories with country code names. It also make logs of access and has the ban access function too, the details for that is written in the included func.php.. Please noted the "Nothing to do.." decoy.

It's not being used but below is snipped for the logging and banning codes, I "secured" it a bit:-)

This is what files were injected and created in that panel, if you see the same files in your servers please delete or secure them all + fix the PHP flaw that caused the file upload.

The email data of the victims that has been grabbed was plenty.. thanks to Mr. Lowson to clean this threat's gate to stop this badness. Below is the snip per 4 lines each data in the CO (randomly picked) directory..

Unknown threat with zero detection

I don't think we had any PE detection signature for this malware (in VT check): [Release.exe] [aa.exe]

A saying in my country says: "What we don't know, even small mater, may hurt us badly" ..I guess this is the case. Don't say about VirusTotal result can not represent detection in this case since several AV products installed in PC was letting infection happened without having detection either.

See this case well, even a simple .NET malware using a straight new DLL abuse vector calls for malicious purpose, if it is unknown, it's just lethal enough to damage us. So firstly please rely more on our own security common sense than just letting automation made by industries 100% control the way we must think and act, WHAT IF things went wrong? The risk is always be in our hands as users/victims < the moral of this story.

Just another saying: "One who admit the FAILURE has the chance to IMPROVE. One who just making EXCUSES will NEVER improve.."



Friday, August 28, 2015

MMD-0040-2015 - Dissecting & learning about VBE Obfuscation & AutoIt Banco Trojan

The background

MalwareMustDie (MMD) today is having the third anniversary. due to this occasion, I wrote this post as the anniversary celebration :) The point is to introduce some methodology in dissecting obfuscated script malware using the real life sample of VBE encoded case with multiple obfuscation. Why I pick this VBE is because the recent raise of the visual basic scripted malware, as in its stand alone VBE, in attached macro of Microsoft Office documents too, so hopefully this writing can share some idea to those who want to know more in how we used to dissect them in MMD. Another reason is to introduce many tools for practical malware analysis that can be performed by everyone who want to start to learn. It's not that difficult, so let's learn it together!

A friend was sending us a VB encoded script (with thank's), he sent me a lot of good samples and I really appreciated. The file named "ContratoAssinar.vbe (4bb9a041ab9cdd8398f95c0dd8a364b0)" and I find it very interesting, so I think I'd better to make some notes here about the way I dissolve it for others who may handle same threat.

The origin of the threat is from South America (to be precise, Brazil), The file looks like coming from an attachment of malvertisement email campaign of the malware. The file name itself is quite popular, with a bit of net surfing will give you good information about the campaign of this malware.

VBE malware script

The malware is encoded using the Microsoft's Scripting.Encoder program, it looks like this:

I tend to use the script provided by the vendor for these purpose so I used this script-->[link] to decode it (the instruction is in that page, it is really really self explanatory) and it was resulted into another partial-obfuscated script as you can see the whole data in the below image:

You will see some area in the above code that I separated them into colors:
The yellow area is the part where this script is to be assured to execute in the right system command & path/file name, it was started in the first line a SUB name that execution the latest part in the overall script.

The red part is the data area where the actual malware script command for the next level is obfuscated, following the red arrow will lead you to the blue area of logic where the data to be final-deobfuscated in the below series of deobfuscation commands.
Orange color part is the part where deobfuscated commands to be executed, and following the blue arrow can lead you to the actual malicious mysterious strings to be executed by the obfuscated malware script.

To understand the flow of obfuscation in several language of programming that I faced so far in MalwareMustDie and facing to obfuscation I tend to discipline myself to follow my own committed rules as per shared below:

1. Make the code to be simplified, beautified, make it easy to you to stare at (I read)
2. Break the codes into pieces, and comment them, make sure you know how each component works, do not be shy to make many comments, and I make tons of them too, it is for your own good.
3. To securely simulate the code to debug is strongly suggested. Use any compiler/interpreter that helps, if not..use our brain for it by making some notes, in this level in most of the time in heavy obfuscated challenges we must go back to point 1. again, but so be it,do it happily!
4. Do not get frustrated, enjoy the cracking like you are eating ice cream, it will end before you even know's all be solved in time, believe it! When you are in a rush or in some pressure your brain cells can not focus to the decoding effort fully, only when we relax we can fully use those cells, and if you push it hard, your work will not be effective and mistakes will occur. A one little mistake of a single byte will drag you to a time-consuming trouble-shooting debugging later on which will lead you back to square one..and that is mostly how a failure starts, so noted this point number 4 well, PS: this point also goes to the boss/management of the reverse engineers, understand this point well if you want your team to do good work!
5. Write it, don't expect your brain to memorize every work result you do, make it searchable for yourself (or for your team..or others) to be used for later reference, be smart in documenting stuff and manageable, we are educated people not like those crooks who made these craps we decode, we're better than them.

What we learned from the first level decoded VBE script is: The malware coder is trying to hide the path confirmation instruction to trigger execution by SUB-ing the call for executional path in the last part of the script. He also obfuscate another malware script in the stub of variable value to be decoded again by the instruction following that stub, and after that pass the decoded value into execution.

To understand this I just simply replace all of the random-look strings into a dull-like var-x or anything that can differ it to the real code token, you can choose any variable name you like which that is so "you" so you will recognize it instantly. That will help you to recognize the actual malicious logic the malware coder tried to hide it from you. This method is used in most programming language based malicious obfuscation I am working with, I think I've tried and tested it enough, it works in Java(with or without Script)), VB, PHP, Perl or AutoIt malicious obfuscation code that I face for these good three years..and it still works! Even some crooks tried hard to mitigate this method with some silly tricks but that just simply doesn't work, since this is just a simple coding matter. So please remember: "To simplify the code!"

In this case the memo of the above rule and process applied to this sample is as per seen in this pastebin--> [link]
Noted: I tweaked some code so you won't run it in harmful way if you just copy paste and run it, it will burp the garbled code as per below picture :-)

Below is the explanation of the paste and the next steps:
There are two environment that the gods of Windows provide us to deal with visual basic scripting in any machine with wscript.exe and cscript.exe, I use wscript.exe only for checking the break point using Wscript.Echo command to check the variable result. In the paste you will see some of simple breakpoints to check the vital values of the script. As per seen in the below screenshots:

After the breakpoint's debugging lead you to the correct result you would want to copy paste them to a text, in this point you can run the script with the cscript.exe to get the text result in the console as per snapshot below:

The full code is beautified as per below:

Please noted words "nome correto do exe" which means something like "correcting the exe's filename" in Portuguese, that was shown in the new malware code script result after the decoding.

Again we still have to deal with the visual basic script, but all of the code are readable. It's obviously it downloads the zip file from the internet and save it to a certain folder and extracted into %appdata%+random folder name into random filename +.exe extension. The script is neat, it has the originally coded randomize functions and original coded SUBs for downloading the remote file from hard coded IP address of using microsoft.xmlhttp and objects.
To be noted, our payload is a zip file contains the text file that can be viewed in Virus Total in here-->[link] or can be viewed by the picture below:

Noted: If you analyze a malware please drop the idea of WYSIWYG (what you see is what you get), because every appearance that you see was meant to fool you.
Example: this Text File.
Isn't it amazing to see that in this era there is still a crook who want victims to download 6Mb of malware unrecognized? Well, here is one of them..

The IP that serves this malware is located in Germany:

  "ip": "",
  "hostname": "",
  "city": null,
  "country": "DE",
  "loc": "51.0000,9.0000",
  "org": "AS12586 GHOSTnet GmbH"

The AutoIt PE "Banco" banking trojan

A quick check will confirm the badness of this "text" file which is actually is a PE:

I love to use pyew since the day we start MalwareMustDie and thank's to Mr.Joxean Koret to develop it, I just want him to know that I use it all along for three years non stop :-) along with many shell tools I use. It is VERY useful for the UNIX shell that can not be used to compile full binary to run other binary analysis tools since it runs on python. And it has many useful disassembler functions too. Here's the snip of the payload in this story:

In order to find the best way to do it, static analysis is a must. The pescanner is assuring many details for the further reversing purpose:

Just to make sure it's not an false detection I tend to re-check it with the other beloved tool I use, you all know what it is:

For friends with the Wndows OS environment, don't worry! PEStudio can statically analyze this malware very good, take a look of how many indicator was raised an dthe detection of the AutoIt overlay below:

OK, to reverse it, since this is the AutoIt malware, I just prefer to decompile it for the analysis. I use this good tool for it -->[link]
The result is as below, it is bringing us to "another level" of obfuscation :-)

Don't worry. We can go back to our rules above to analyze it properly, with some patience, a good 1 hour and good macro editor you can have a much better view in no time :-)

You can see there some DLL struct scripted for the usage malicious calls of and some PE binaries blobs ( which those are there to be used for the x64 or x32 OS process injection). Please try to decode the AutoIt script by yourself and trail its variable one by one. It's good to see a readable code is it?

I beautified & cleaned the 186+ of obfuscated variables and functions used in this obfuscated decoded source code, so if you want to snip into the result first without taking effort to decode or cleaning nor beautifying code, you can see it in MMD pastebin to see how the malicious operation calls and self PE injection technique and tricks (like there is a thread injection to modify other thread's contents) that were all done by this AutoIt's codes, the link is here-->[link].

How AutoIt can inject memory?

It's a simple way to inject actually, it forms object of DllStruct by the AutoIt programming code, to feed the object with the parameter and hard coded binary data (which are obfuscated) to form several malicious performance, and write it into specific address in the memory. This is the main concept of this AutoIt/PE malware works to infect the victim. Some of the tricks for allowing that action was formed with the preliminary tricks to bypass security. The variable name is telling you which part of process it is being used actually so it is a bit traceable. Frankly speaking I never thought will face this exploitation-like action when seeing this sample in the beginning. But I will make simple explanation below but not too detail yet, since many parts are still being investigated now.

In the pastebin data, for the early injection operation, please watch the value of $var30 and $var120 which are loaded with binary data to be used to perform the injection for running process. I spot the memory writing operation by script is about as per snipped below;

The above snippet code can show you how the memory injection can be perform by this script. The deeper ROP analysis is actually needed to understand the details of this. When fully run, I can see the PE was written in the memory from the source address 0x410DAD and by the VirtualAllocEx symbol calls of system32.dll on base memory 0xE80000 and with the big size (length) PE file:

Also, if you have a tool so trace steps of a process in Windows environment, you will see in steps how the sample is forming injection to the foreign address by injecting itself:

Just for fun, I compiled the first bin loaded to inject to understand what it is, the compilation is the PE with value of binary $var30 string (just for curiosity..I know this will end up to nowhere) that was called by DLLStruct snipped above, so the entry point for reverse engineering of that binary can be "factorized", you can get the sample in here [link] for you to analyze it using any disassembler software. You'll see something like this:

Well, the 0x4001e5 doesn't make any sense to me, and this loopbacks to the main entry. lol :-)So we know this maybe not a shellcode.

Anyway.. please enjoy the further analysis of the calls made from the decoded PE(AutoIt) :-)

Summary of the PE's malicious behavior detected:

Instead the memory inject & thread modification, the other activity of the PE is: The sleep time taken after executed (see the beautified source code), some of the detection of the VM (access to \VBoxMiniRdrDN / VBoxHook.dllU / VMware), it seeks for FWPUCLNT.DLL (windows firewall). Creates registry autostart with changes file view setting of explorer (I don't know what this is for..but there's no good in it) and..

HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced EnableBalloonTips
Etc activities for instance:
Self rename file extension of itself into .exe
Binding to local INET socket to open & listening port 2038
Mutex: "\BaseNamedObjects\2015.0.11"
And some strings to mitigate these security products:

The callback

The malware is contacting the remote host as CNC in Brazil with IP and sending CNC poke data via a HTTP/1.0 POST, that IP is having a very bad reputation IP-->[link]:below is the evidence:

It is our team's drill to search the fresh CNC information as much as possible to support the work of law process who would like to follow a crime investigation for the case. So in this case too, I extracted some information, so if I may minimum please do the same for the cases that you spotted.

Lookup result for the domain called:

;; ANSWER SECTION:         1800    IN      A

;; AUTHORITY SECTION:         3600    IN      NS         3600    IN      NS         3600    IN      NS

;; ADDITIONAL SECTION: 3275   IN      A 3275   IN      A 3275   IN      A
Ip address origin (GeoIP & ASN):
  "ip": "",
  "hostname": "No Hostname",
  "city": null,
  "country": "BR",
  "loc": "-23.5477,-46.6358",
  "org": "AS7162 Universo Online S.A."
The domain is registered with an email contact of ARNALDOBALTAZAR@GMAIL.COM to ENOM.COM:
Registry Domain ID: 1895096489_DOMAIN_COM-VRSN
Registrar WHOIS Server:
Registrar URL:
Updated Date: 2015-07-07T05:57:31.00Z
Creation Date: 2015-01-10T15:12:00.00Z
Registrar Registration Expiration Date: 2016-01-10T15:12:00.00Z
Registrar: ENOM, INC.
Registrar IANA ID: 48
Registry Registrant ID:
Registrant Organization: "SOUZACRUZFERRAGISTA"
Registrant Street: "AV BELA VISTA2
Registrant City: "GOIANIA"
Registrant State/Province:
Registrant Postal Code: "74938110"
Registrant Country: "BR"
Registrant Phone: "+55.6198515323"

Sample for analysis learning purpose

It's downloadable in a 7zip format from here -->[link]
The payload in 7zip format is here -->[link]

The next challenge...encryption VBE:

Kudos the cool coders of great tools & OS we use:

Happy anniversary to MMD friends! Stay safe! #MalwareMustDie!