This find is due to Sara. A quick check in the traffic logs for a host sent to the help desk showed a bit odd network traffic. We saw the computer polling laptopantivirus.microsoft.com/block.php. Looking quickly you think, well that’s Microsoft – it’s okay! Well, Microsoft using PHP? That’s not overly likely and the “laptopantivirus” part seems sketchy. If you look at the IP address it’s 195.88.190.54 – Registered to Bigness Group based in Russia.
See below
DoH! is meeting THIS WEDS Jan 27th at 7pm! Again at GWU/Foggy Bottom.
Greetz “Tu Snipa”. Adam, great blog entry: http://www.thecoverofnight.com/blog/?p=214
Great link here: http://www.secureworks.com/research/blog/index.php/2010/01/20/operation-aurora-clues-in-the-code/
Basically they found a CRC algorithm in the binary that Googling appears to indicate is used only in Chinese language forums. Very nice hard data point.
Now that the Symantec write up seems legit here’s a little background digging I did the other day on the domains. I think this sort of information is mainly idle speculation, but rather than simply presenting opinions I’m going to provide screenshots. This is based on looking up network information for the domains listed by Symantic, namely:
Here’s what I saw:
Interestingly here, the first hostname is in Korea – not China. If you want to ping up the admin the info is listed as:
Another domain sl1.homelinux.org is again shared hosted, and it has multiple domains including those associated with Russia:
Another hostname 360.homeunix.com has a little more info. The hostname is set to localhost, but the domain appears to be in the US:
Same with update.ourhobby.com
Though in fairness it appears to be only a US based service:
Li170-40.members.linode.com actually had some info:
If you look above you see the IP is US based with US based points of contact – though one appears to be Canadian as well.
yahoo.8866.org, finally this one appears to be in China
A lot of the speculation is based on IP addresses and where they resolve to. I believe this is a poor way to do analysis. If I were a criminal or a nation state, I would certainly own a lot of 3rd party easy hosts and create a very complex path that would be near impossible to establish my true identity. I don’t believe the Chinese would be easily attributed back to Chinese IP addresses. Additionally, if you look at the above, it’s not entirely clear that China is the sole source. There are Chinese, Korean, and US hosts/domains. This might provide things to think about as others are speculating about attribution based on where the malware connects back to.
UPDATE:
Saw this link associated with the email address (ppyy@bentium.com): http://archives.neohapsis.com/archives/postfix/2001-05/1841.html. Further if you look up the domain 8866.com you see things like: http://google.com/safebrowsing/diagnostic?site=8866.org/
The more I see the more it looks like a regular malware domain. Maybe “the real badguys” hacked 8866.com to then hack google and those 36 other companies, but if I wanted to say off the radar at all this seems like a really bad idea. I’m thinking regular malware.
All screenshots are from www.centralops.net or www.robtex.com
The following write up is available from McAfee at: http://vil.nai.com/vil/content/v_253416.htm
It’s a nice detailed technical write up, but look below:
Why do they hide the hostname and not provide the IP address? Do they think the attacker is unaware of the discovery? Is McAfee selling that information as a “professional service”? Seriously, its only value is to enable network IDS sensors and staff to identify and block any such traffic, but apparently a hostname is too much to ask.’
UPDATE:
Plug for Symantec, they actually drop names here: http://www.symantec.com/security_response/writeup.jsp?docid=2010-011114-1830-99&tabid=2
Values are:
I had heard from a knowledgeable source that he thought the Symantec writeup was crap. McAfee and Symantec seem to agree on a lot of details though. Point Symantec and thanks for the info!
I have been monitoring what appears to be a custom IRC based bot infection for several weeks. The current executable has an MD5 5663af5192f2963093b489c1eff171c3. The executable is a VB6 P-Code project that wraps the real payload in the VB virtual machine. Basically they create a packer using VB.
The bot calls itself Plague Bot and C&C is readily seen by network traffic analysis – though it does has some limited antidebugging anti-wireshark techniques. It grabs files from hxxp://www.hentaimoviez.com/ct/ Pound.exe (formerly grabbed Weed.exe). The current IP is 174.132.234.74. The IRC C&C is running at: 174.133.63.91.
The binary was first submitted to VirusTotal on 1/12/2010 and also submitted to various AV vendors. Here’s today’s result on VirusTotal:
Please visit Adam’s Blog at the Cover of Night for much further analysis.
I was almost pwned by an Acrobat reader exploit while visiting a page on blogger. I was forwarded to a 3rd party site. It autoloaded a PDF that appears to attempt to exploit the 3D vulnerability. Likely: http://www.securityfocus.com/bid/37761
The attack appears to have failed on Windows 7 64 bit and Acrobat Reader 9.2.
I cannot confirm the attack is for the cited bid, but it appears that way. After I have time for further analysis I will post more.
Sara Laughlin
Matthew Wollenweber
The George Washington University
{belevume, mwollenw}@gwu.edu
A network IDS alert for Poison Ivy detects a possible attack from 72.52.166.40. The signature and traffic are insufficient to verify a malicious incident. Further analysis shows a portable executable downloaded from 121.14.149.32. Automated analysis indicates no virus but odd behavior. Detailed analysis indicates this is Trojan.Win32.BHOLamp which is likely a Poison Ivy variant. The initial dropper has MD5= e361fbcc45e23bc0913ded251dd9753c and drops a DLL for a backdoor with MD5=2c97cef5389caaf82cff40c98a9bdb13.
On January 7th, 2010 GWU ISS Security identified a potential threat by a signature alert on a network sensor. Later analysis confirmed a security threat not currently detected by most antivirus products. This report details how the malware was detected and the analysis of the threat. Additionally, we hope this informs readers of a current threat.
Initial detection is based upon an alert from a custom signature for the Poison Ivy Remote Access Trojan server. The signature looks for a common binary message observed in Poison Ivy communications. However, the signature is not definitive. Below is an example hit on the signature
Next we searched the IDS for other entries associated with the suspected victim IP address. We discovered the victim recently downloaded a Packed PE (executable file). Downloading executables is quite common so we still were reluctant to identify the traffic as malware.
We proceeded to analyze the PE as our next step. Unfortunately this step should have been delayed. If we had examined the attacking IP address, seen below we would have been far better off.
A quick googling of the IP yields:
Our IDS logs traffic associated with an alert. From that we obtain the file and HTTP GET Request.
Manual inspection of the above indicates an EXE appeared to be transferred and that a username and computer name was sent to the server. The MD5 of the executable is e361fbcc45e23bc0913ded251dd9753c.
Initial analysis was automated by the standard series of online tools. Virustotal had no successful hits. Anubis and ThreatExpert were inconclusive.
Browser Helper Objects are fairly common, but some of the CLSIDs were odd.
CLSIDs are sufficiently large as to be unique for any application. A CLSID of all 0s struck me as unprofessional. Additionally, the executable dropped a DLL:
The file name is random, but the path and MD5 (2c97cef5389caaf82cff40c98a9bdb13) appear constant.
We repeat the automated analysis with dropped DLL. Again no detection with VirusTotal. But with ThreatExpert we see the following:
The DLL connects back to the original host with the same page that downloads an executable. This further indicates malware.
Curious, we continue to Google CLSIDs and finally discover: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FBHO.gen!LL
This confirms the malware as Trojan.Win32.BHOLamp.
The following screenshots indicate the attacking IPs are shared hosted computers residing in China. The type of hosting and country of origin do not necessitate that the traffic is malicious but when combined with ambiguous behavior one should consider such factors.
The malware does not always immediately call back to the remote server. Therefore, if one relies only on ThreatExpert that key piece of evidence might be missed. Loading the DLL into IDA Pro we find no URLs and few strings in the executable. However we see large data sections. Therefore we decide to run the DLL in Immunity Debugger. This is done as follows:
You run rundll32 with the DLL filename and function as arguments. Next we configure Immdbg to break on every module load and wait for OQpEg5WJ to be loaded. Not seeing anything immediately interesting we continue to watch modules load until an internet related module is loaded. We know to expect modules to be loaded because of the following code:
As expected we see the following:
Urlmon is loaded first followed by Wininet and WS2_32. We set standard breakpoints on WS2_32.send and various Wininet openinetnetconnection type functions. Despite running standard Immdbg anti-debug scripts the malware still detects debugging and crashes. However, we scan memory for “http://” and find the relevant URL and also confirm it’s the only malware related URL (namely http://121.14.149.132/hia12/ter.php).
Many IDS analysts are reluctant to classify an event as malicious without a confirmed antivirus hit. This paper demonstrates a case study where our systems detected a probably event and we manually verified the incident despite the malware not being detected by any AV products. This is especially important due to the ability to rapidly pack malware and for polymorphic kits like Poison Ivy. Reversing the binaries confirmed the malware, but one should also consider the behavior indicated by tools like Anubis/ThreatExpert combined with network traits such as location and domain names.
http://www.efblog.net/2009/02/creating-online-polymorphic-malware.html
http://www.threatexpert.com/report.aspx?md5=2c97cef5389caaf82cff40c98a9bdb13
http://www.threatexpert.com/report.aspx?md5=e361fbcc45e23bc0913ded251dd9753c