6 May 2012

Unusual cyber attack targets continue: This time Ethiopia


Unusual cyber attack targets continue: This time Ethiopia

May 3, 2012 by Snorre Fagerland - 1 Comment
Despite reports that digitally signed malware is becoming more common, it still calls for a bit of attention when a new stolen certificate is found.  Much signed malware is either signed with a certificate which is known to be on the loose, signed with a self-signed (and thus untrusted) certificate, or validly signed because the malware can be construed to be a valid product. This happens with droves of useless adware programs, for example.
A while ago we received a sample that had a new, apparently stolen certificate which still validated.

This sample was already detected by our sandbox-technology, but since it was signed it ended up on my table for verification. The sample has the MD5 d75fe3f39e969f782e5cc56a7d851384, but this hash will change as it installs itself, since data fields inside the executable change when copying.
Installation
The sample acts slightly differently depending on how it is started.
If it is just run without switches it copies itself to path c:\windows\help\ctfmon.exe, and installs itself in a slightly odd place – as a safeboot alternate shell:
HKLM\System\CurrentControlSet\Control\SafeBoot
AlternateShell = c:\windows\help\ctfmon.exe /i
HKLM\System\CurrentControlSet\Control\SafeBoot\Option
UseAlternateShell = 1
This functionality is little known, but the fact is that if AlternateShell/UseAlternateShell is defined, it is not only used for SafeBoot. Indeed, userinit.exe always checks UseAlternateShell and starts the corresponding alternate shell if this registry key exists. This is documented in Windows Internals; I just checked that it applies to at least XP still.
When run with the /i switch, it copies itself from ctfmon.exe to c:\windows\help\winrar.exe, and uses a CMD shell to start winrar.exe:
“cmd.exe /c “C:\WINDOWS\help\winrar.exe” /r”
It also checks the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall for the presence of the value UNEBOT and will delete this value if found. The reason for this is a bit unclear. There is no code in this malware that appears to add this value at any point, so a theory is that the UNEBOT value was used by a previous version. This was anyhow the name we chose for this malware; as good a name as any.
When it is finished with these installation tasks, it spawns explorer.exe, so that the user does not see anything odd. In testing, no delay or unexpected behaviour was seen.
Only after it is run with the /r switch will it contact its command-and-control server and attempt a download.
Download
This download request is quite nonstandard.
The malware sends 32 bytes of data. This is hardcoded in the executable:
-> C7701D29995FAE4281B691BB1D872E3B8877E64120F87B4C84819757147D760C
The response it expects to receive consists of another 32-byte buffer, where the first 16-byte buffer fills a dual role.  It is both the xor key which is to be used for decoding the encoded file which is next transferred, and the MD5 hash of the decoded executable. The first dword of the remaining data received contains the size of the file.
The malware expects this downloaded file to be a DLL with at least one export: “Entry”. This export is by default called directly in memory; this is determined by a bitfield in the malware’s configuration data. Alternatively, the DLL is saved to disk using the name patch.dll,  loaded using LoadLibrary, and the export is called normally.
Unfortunately, we don’t have a copy of this patch.dll. In our tests, the C&C server has never responded to any connection attempt by the malware. However, we see that when calling “Entry”, the malware supplies a memory address inside itself as a parameter, and this address points to the malware configuration data. Parts of this area also changes when the malware copies itself around.
C&C and origin
The command and control server (C&C) is in this case a hardcoded IP and and port address, 213.55.96.12:1723.
WHOIS shows that this IP belongs to an Ethiopian provider, Ethiotelecom:
inetnum:        213.55.96.0 - 213.55.96.127
netname:        Ethiotelecom
descr:          Leased by Corporate Customers
country:        ET


A little poking around showed that this malware was reported from one country only – indeed Ethiopia. So, is this an Ethiopian malware? No, apparently not.
First of all, the signing certificate belongs to a Chinese company:
CN = Harbin Zhuren Information Technology Co., Ltd.
L = Harbin
S = Heilongjiang
C = CN
Second, the file resources indicate that the build language ID is 2052 – which is Chinese.

So what is a Chinese signed malware doing in Ethiopia, calling back to an Ethiopian IP? We can only speculate about this, since we unfortunately do not know the delivery mechanism of the malware. Nor do we know who (if any) have been affected by it, but it makes sense to assume that the target is located in Ethiopia itself.
Though the target is unknown, it is a fact that China has economic interests in Ethiopia. Not only does Ethiopia import Chinese goods, but China has participated in construction projects and is involved in oilfield exploration, and has granted Ethiopia several large loans.
Anyhow, the stolen certificate was reported to Symantec Verisign for revokation on March 13th, and it was:
Serial Number: 20CAA206477F0244CD569982EE901E21
Revocation Date: Mar 17 05:42:01 2012 GMT
However, this malware sample is signed March 8th, which means it still validates. New malware will not.
The malware has also been reported to the Ethiopian Information Network Security Agency (INSA).


http://blogs.norman.com/2012/security-research/unusual-cyber-attack-targets-continue-this-time-ethiopia