１．Background
For the better insights of this analysis you can view my interview with good Q & A in here (link).
VXRL(credit) contacted us regarding an APT phishing email that included a download link to a malware being hosted on a Geocities website.
Sample/Evidence.
*) Because we think its an APT attack we cannot disclose all of the contents of the email.
After receiving the request to takedown and URL information, much of the received malware information was very unclear. I also examined the signature detection rate which turned out to be none. There was too few details. Without the definite proof Geocities would not be able to do anything I decided to reverse engineer the APT.
Here are the results of my analysis please use it to remove the malware.
From the URL the malware was hosted on GeoCities Japan , Geocities is not a malware or malicious site but a free website hosting for blogs and homepage.
The account “vbiayay1” was used to host the actual malware sample.
The contents of the hosted malware file was VBScript encoded script.
This was a “Wow” moment for me, it was the first time I have seen this type of file from Geocities.jp and the file looked suspicious so I decided to do some more analysis.
VBScript is a subset of Visual Basic and for people who have used Visual Basic or any VBA macro it should be a familiar programming language. However VBScript is designed to be run and executed within the browser and only can call functions considered basic such as file access and printing. Microsoft VBScript can be executed under Windows Script Host or Powershell.
2. Reversing marathon of base64
First I manually decoded the VBScript encoded sample , leading to the following code:
*) if you want to know how this is possible contact me directly @malwaremustdie
The code by using Windows Script Host VBScript creates and object in the shell (read: CMD) and executes a run of the following code:
powershell.exe -w hidden -ep bypass -Enc "etc etc etc".
The meaning is, during script execution powershell hides the output (-w hidden) and executes "etc etc etc" which is the base 64 coded command (Enc = EncodedCommand) without authentication (-ep bypass, ep = ExecutionPolicy).
Windows PowerShell is a useful and extensible command line developed by Microsoft Interface (CLI) shell and scripting language.
Designed on the basis of object oriented, it is based on .NET Framework. PowerShell is having strict policy for performing the script execution, however, by using optional execution parameter the attacker can utilize PowerShell to run a malicious script. Once called Microsoft Shell (MSH, codenamed Monad).
Continuing the decoding of the "etc etc etc" code, leads to the following script↓
Once again its a VBScript , this script creates a web client object and uses the proxy setting and user rights to download a file from a url and execute the file.
This allow the opening of a .doc (MS word) file.
Then by utilizing IEX (Invoke-Expression) commandlet will allow it to execute a script under Windows PowerShell and download and execute a .ps1 file from another url.
Lets dive into the .ps1 file↓
Once again its a base 64 encoded code, and it shows that it used the IEX command to decode.
Looks like this malicious actor really likes base 64 , so back to reversing the base 64 manually.
The above is the decoded code, but its another base 64 encoded code. (_ _|||)；；；；
However it finally revealed some of the infection code, the actual malware payload is in this base 64 code.
The code also revealed infection vectors for 32 bit and 64 bit , it hides itself as a fake “Security Update” process and uses powershell.exe to execute the base 64 code by decoding it with an IEX command.
Ok, back to decoding base 64 again!!
Once decoded the 2 functions came up and a shellcode appeared.
The above codes are all self-explanatory, read the commands line by line. It explains how a powershell can be used as lethal vector to exploit a bad malware by process injection, and all are in a script!!!
３．Copy/Pasting PowerSploit/CodeExecution PoC
The last part looked familiar and after searching the MalwareMustDie tweets, it turned out to be a PowerSploit/CodeExecution PoC code.
Copy-and-Paste rulzzz….(maybe)
This is one of the reasons I am against releasing malware code to the public.
GitHub is full of these types source codes.
４．ShellCode
The main payload of this sample turned out to be mostly a copy and paste job of the PowerSploit/CodeExection and the shell code and multilayered base64 encoding is original to this sample.
So to reveal the actually shell code we have decode the rest using base 64 again…oh no..
$Shellcode = [System.Convert]::FromBase64String($Shellcode32)
Once decoded the shellcode header can be analyzed as:↓
We could just reverse engineer it as is, however it might take some time..
So looks like we need and XOR , Key “0xe9” and byte length: 0x2183 . I didn't want to write it further before, but now is okay, here's a simple explanation for this XOR stuff. Poison Ivy malware itself is the XOR resulted binary. It will inject the actual payload to the userinit.exe (we will go there in following section) as the SECOND shellcode. This XOR resulted shellcode data contains basic information of the campaign itself.
Its getting late and I need my beauty sleep, and I can’t spend much time on this so I will share a neat way to handle this shellcode :)
So I used assembly and created a PE binary file using this shellcode.
Saving the shell code data in the .text section of the assembly file and the entry point(EP) will be "adjusted" by the compiler during compilation process therefore you can execute this shellcode as a binary PE file. This method is very useful when analyzing shellcodes. And by using a Unix environment you can create this PE without risking an infection. (For this sample I conducted most of my analysis in FreeBSD)
By using gcc or nasm to compile the PE file can be created in FreeBSD.
So we can now analyze the code for further analysis and behavior analysis of the malware without any risk.（＾－＾ｖ
So it turns out that much of the behavior of the sample conducts many malware actions, the shellcode extracts information of its victim and calls back to a C2 server and other nefarious actions.
Writing out exactly what the payload does will take a very long time but here is the draft of the sample’s payload behavior diagram in a hand writing I made for my own memo during stepping (sorry for an ugly hand writing) ↓
(This hand writing diagram contains the shellcode process, for both shellcodes used by FHAPPI. The first one is what had been injected by the powershell.exe, the second one is what had been injected into the userinit.exe process. I’ll clean up once I get to it, besides the malicious actor could be reading this post too. So once the necessary steps are taken I might clean this up)
Shellcode is a piece of code used as a payload that uses software security holes in computer security. Shell codes are often written in machine language. In order to allow an attacker to control an intruding machine, they often launches a shell, for that a machine language code is executed.
Shell code is not necessarily just to start a shell, even without opening any shell, intrusion of malicious commands can be performed, for example, executing a specific function of a library by addressing specific work space in kernel for execution of a malicious activities, so it is said that the name of shell code is insufficient. However, other terms have not been established so far.
５．POISON IVY
The shell code utilizes many system calls and hence the shell code itself is somewhat bloated.
The following picture is the list of DLL calls I yanked from forensics.
(sorry for not cleaning this up, #neverenoughtime)↓
*) you will need to sort these out by analyzing the flow of the malware in assembly mode.
I notices this is a 「Poison Ivy」 during the first stage of trace-assembly analysis of the shellcode:
As you can see a fake 「userinit.exe」process was made, and a malicious code was injected in the process and then to be executed. The victims will see a BAD 「userinit.exe」process is doing bad stuff. This is a typical Poison Ivy scheme. Further, the usage of the certain combination of DLL is showing a typical pattern of the threat too. More over, the date stamped in the MUTEX name is mostly used by Poison Ivy (specific format).
What looks like a mouse, should be a mouse..
If you want to see the whole figure of Poison Ivy used by this campaign, you will need to compile it as a binary and analyze it as per described above, or you can decrypt the XOR with a patience, and then go by opcode per opcode reversing. It is very do-able, and as the proof you can see the following screenshots of what I decrypted by radare2 (I only use one r2 shell for this under a FreeBSD OS, no fancy stuff, if I can do this then you can do the same)
Another shellcode in a shellcode..
In the malware prosess "userinit.exe" there was a shellcode being injected. It looks like this:
This second shell code was generated during the XOR-decrypting process when PowerSploit (malware script of powershell.exe) injected the first shell code, and the first shell code to then injecting this second shell code into userinit.exe process. First shell code is the whole PoisonIvy itself, second shellcode is the installed infectious payload to the client's PC. See the screenshot I took while cracking the first shell code by XOR below in radare2, it shows the second shell code was formed during the first shell code was XOR-decrypted itself:
↑It's hard to see or noticing malicious part of the second shellcode by ASCII view, let's see it in binary mode↓
Now I see the suspicious「 CreateThread 」DLL call printed out in there, very suspicious.
The type of this shellcode is in x86-32 with the size of 255 bytes.
To get more idea on how it works, you will have to see it's flow with any tool you prefer, but I have my beloved one, and the result is like this:
It called the mapped addresses in the kernel prepared by the previous shellcode for kernel32.dll,advapi.dll, ws2_32.dll and kernelbase.dll, so one need to run the powershell script to see the exact address use. I see the usage of the VirtualAlloc, CreateThread, LookupPrivilegeValueA, AdjustTokenPrivileges, CreateFileA, getsockname, sleep, GetComputerNameA, GetPriorityClass, SetPriorityClass DLL functions were called.
To explain it a bit more, Poison Ivy shellcode during injection of the userinit.exe process was direct/undirectly involved in loading the necessary DLLs in the kernel space. The second shellcode (injected to the userinit.exe) has two types of "calls", the short ones are caling to the "Hint" address of the function in a DLL in memory map and second one is aiming for the "RVA" addresses.
To confirm about which address belongs to which functions of what DLL, one needs to know which DLL that was beforehand used or loaded by the malware and then during the condition of "infection" or during the simulation of that infection, the dump of the related DLL can show exact addresses that are applicable. For this case, there are many ways to dissect this, in the Windows OS there is tool called PE Dumper. This tool (or similar ones) will show which are RVA and Hint calls addresses and goes to specific functions. This is why I can know precisely which call were used. Noted: I can not be too transparent for not inspiring other bad guys to do the same.
In my test PC (it's a 64bit windows since I run it as image under BSD) the snapshot of kernel.dll calls can be seen as per following screenshot picture:
The reversed process for the second shellcode can be disassembled as per what I did in below report (it is the "head" of the longer analysis).
You can see this "bad" userinit.exe is operated and creating the file called 「Plug1.dat」, it made socket for the further works, and querying PC info through 「HKEY_LOCAL_MACHINE\SYSTEM\Setup の SystemSetupInProgress」, we'll see the values sent afterward. The next malicious process will be executed too. And these overall process will be looped. I had to terminate the process of loop itself in the 9th time, so I save the data of the Plug1.dat to Plug9.dat.
The process being executed by the second shellcode can be seen clearly. I made a graph to describe it as per below:
※）memo: A hand-made diagram I wrote was actually describing the whole process of the shellcode injected via powershell.exe, which also having the process traced of the second shellcode. The both shellcode are in interaction during the infection process.
...now it started to sound like a mouse too..it is a mouse!
Up to this point, there is no doubt this is a Poison Ivy.
６．ＣＮＣ and Network Traffic
Since time is somewhat limited lets ignore the small stuff and focus on WS2_32.DLL cause it looks interesting. It seems that there is a socket(),gethostbyname() and a connect() call. These revealed hostname and IP address for the callback, along with minor information.
The IP address is a dial-up IP in South Korea.↓
Network/BGP Information→「61.97.243.15||4766 | 61.97.243.0/24 | KIXS-AS | KR | kisa.or.kr | KRNIC」
So the hacker was utilizing another country for the CNC purpose, let's see more:
Hostname: web.outlooksysm.net
This is the used domain's WHOIS info:
Domain Name: outlooksysm.net Registry Domain ID: 10632213 Registrar WHOIS Server: grs-whois.cndns.com Registrar URL: http://www.cndns.com Updated Date: 2016-05-27T11:24:02Z Create Date: 2016-05-27T11:19:45Z Registrar Registration Expiration Date: 2017-05-27T11:19:45Z Registrar: SHANGHAI MEICHENG TECHNOLOGY INFORMATION DEVELOPMENT CO., LTD. Registrar IANA ID: 1621 Registrar Abuse Contact Email: domain@cndns.com Registrar Abuse Contact Phone: +86.2151697771 Reseller: (null) Domain Status: ok https://icann.org/epp#ok Registry Registrant ID: Registrant Name: Liu Ying Registrant Organization: Liu Ying Registrant Street: Nan An Shi Jing Hua Lu 88Hao Registrant City: NanAnShi Registrant State/Province: FuJian Registrant Postal Code: 009810 Registrant Country: CN Registrant Phone : +86.13276905963 Registrant Phone Ext: Registrant Fax: +86.13276905963 Registrant Fax Ext: Registrant Email: missliu6@sina.comSo we know where this asshole is coming from...
Just analyzing the code is not enough evidence, I needed a safe way to execute PE file to conduct further behavioral analysis. This way I could capture all the CNC/C2 traffic.↓
In this traffic was sent my test PC info (knew this after decoded) （＠。＠；；
The first transmission has a size of 256 bytes…this looks interesting…↓
So by looking ups some reference material turns out that this 256 byte transmission is an identifiable traffic pattern for the Poison Ivy RAT. (The Challenge and Response Traffic for Poison Ivy) ↓
Poison Ivy: Poison Ivy also known as PIVY is a RAT (Remote Administration Tool) , its a back door style malware. Many espionage related malware utilize this Poison Ivy kit in APT(Targeted Attacks)
７．Conclusion
This APT campaign utilized many variants to falsely have the victim download a malicious VBScript , which then downloaded a secondary staged attack .doc file and opening it. Behind this action it quietly executes a PowerShell(PowerSploit) attack to infect the victims with Poison Ivy into a process running in memory.
This was an unique instance where a modified PowerSploit PoC code was utilized in an APT infection and shows the potential dangers of such an attack.
Poison IVY malware is what was actually injected in the malicious process userinit.exe created or prepared by the PowerSploit used shellcode. The concept of infection is fileless, it's avoiding known signature for detection by multiple encodings and wraps, and it is also 100% avoiding the original attacker's working territory. This will make the current APT campaign has better chance of success other cases caused by similar payload.
This APT campaign utilized multiple accounts on Geocities Japan, leading to the possibility that there is a larger APT campaign being conducted. The TPPs of this attack were the first to be recognized in Japan, and after discussing the attack with my friends and fellow researchers we have named it “Free Hosting (pivoted) APT PowerSploit Poison Ivy” (FHAPPI)
Credit: El Kentaro (FHAPPI Idea and logo、credit), Luffy, Syota Shinogi 、Ino Yuji (credit) ++
To avoid further victims I really hope that the vbiayay1 account on Geocities.jp gets taken down quickly and the malware deleted. I hope that this analysis can help in the investigation and the countering of this threat.
Also from the analysis I am certain that the Korean IP address 61.97.243.15 is a CNC for Poison Ivy therefore recommend blocking access to and from this IP.
I also have already contacted Gmail regarding the email sender , the following address were used:
1. wisers.data@gmail.com
2. health.pro.demo30@gmail.com
These accounts can be used in other APT campaigns, so I suggest blocking & start tracing these addresses.
I also hope that malware source codes and PoC are not shared in public.
８．Sample
I’m still working on this , so I will only share the hashes for the samples.
I will add the VT URLs once I am done.
1.MD5 (Meeting_sumｘｘ.doc) = 0011fb4f42ee9d68c0f2dc62562f53e0 2.MD5 (ｘｘｘ0301.ps1) = b862a2cfe8f79bdbb4e1d39e0cfcae3a 3.MD5 (Meeting_ｘｘｘ.doc) = 0011fb4f42ee9d68c0f2dc62562f53e0 4.MD5 (ｘｘｘ0301.ps1) = b862a2cfe8f79bdbb4e1d39e0cfcae3a 5.MD5 (ｘｘｘ0301.wsc) = 7c9689e015563410d331af91e0a0be8c 6.MD5 (shellcode-bin) = cb9a199fc68da233cec9d2f3d4deb081 7.MD5 (stupid-shellcode.exe) = 661d4e056c8c0f6804cac7e6b24a79ec Other samples. (credit: Syota Shinogi) MD5 (f0921.ps1) = e798a7c33a58fc249965ac3de0fee67b
９．Update.
９．１．Finding other Geocities accounts.
Thanks to Syota Shinogi’s help (credit) in further researching he found another Geocities Japan account.
It uses the same PowerSploit shell code and the .doc file was a document in Mongolian , possibly targeting users in or related to Mongol.
Screen shot ↓
９，２．File name contains the APT information
URL and attack campaign related information : ↓
This shows the attack date, target ID and some form of versioning/series type of information.
９．３．The Deletion process of the APT malware files
With the help of the Yahoo Incident Response Division (YIRD) and JP-CERT/CC and other great security folks in Japan the files was successfully deleted.
The following files were deleted.↓
※）Deletion confirmed time : 2017 March. 11th 10:00 am
thank you all for your help.
９．４．FHAPPI Campaign targeting Mongol
The user lgxpoy6」contains data for Mongolian APT target. The infection vector is the same, judging from the date it started sometime in September of last year. Many artifacts and web sigs has gone or faded but, what the heck, so lets analyze this too for the malware improvement comparison..
The first installer script was not obfuscated using base 64.
It utilizes VBscript but not encoded, and executes powershell.exe directly however the execution process itself is the same as the campaign explained in above.↓
The encode command executed by powershell.exe has the same format ↓
Mongolian Decoy Document ↓
Still uses PowerSploit to inject the malware into memory , no changes here.↓
A slightly different shell code design ↓
The Mongolia related campaign also uses XOR but a different key “0xd4” but the byte length is the same “0x2183”
The CNC is in the mainland of China, with the hostname(S)
IP/BGP Information: 116.193.154.28 | 116-193-154-28.pacswitch.net. | AS4766 | JIULINGQIHANG-CN | CN (Room 413, No.188, Dong Han Men Nan Lu, CHINA)
The Poison Ivy version used in the Mongolia campaign is the same as the main analysis shown above that aims "other" country.
The interesting part is the hostnames used in the Mongolia campaign were hardcoded two hostnames instead of one (the main analysis APT is only have one hardcoded domains). However please see the template used, this version of PIVY can contains up to 3 (three) hostnames (or IPs).
PS: Did you see what domains that was used? ;)
Hmm, okay, good, now we know exactly who is behind this attack..
#MalwareMustDie!
Wed Mar 15 01:17:48 JST 2017 @unixfreaxjp / MalwareMustDie,NPO - Reversed and published the report
Thu Mar 15 05:42:14 JST 2017 @luffy(credit) corrected some Japanese wording in documentation. (thank you)
Fri Mar 17 00:48:30 JST 2017 @elkentaro translated the whole documents into English
※）PS: I might update this later with more material.
0 件のコメント:
コメントを投稿