Archive for the ‘Dropper’ Category

Is Someone Stealing Your Search Queries? Why Might They do That?

Friday, January 22nd, 2010

Banload is a malware name that is typically associated with banking trojan downloaders, but the Banload-detected sample covered in this post is a bit different than the norm.  The MD5 hash for this sample is 707D3477CBBEAD4923B17CE353D9761D. And, just to note, currently click fraud is reported elsewhere to challenge even the biggest, most technologically advanced online advertising companies. Some of the up-and-comers are committed to studying low intensity search abuse schemes as well.

Initially this DLL is loaded with regsvr32.exe, in order to perform an installation.  It installs a GUID in the “Browser Helper Objects” registry key which tells Internet Explorer where to find the DLL on disk.  Next it installs an executable (ctfmon_qj.exe) which will start any time the ctfmon.exe executable is launched.  It does this by inserting a “Debug” registry value in the “SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ctfmon.exe” registry key.  This causes ctfmon_qj.exe to be launched instead of ctfmon.exe, as it is being treated as the “debugger” for ctfmon.exe.

Ctfmon_qj.exe, when run, launches the actual ctfmon.exe; then proceeds to launches Internet Explorer.  This would guarantee that the browser helper object is loaded as soon as ctfmon.exe executes.  Once loaded, the DLL sits in Internet Explorer waiting for someone to navigate to a URL, such as clicking the “Search” button on google.com.  The destination URL is then scanned by the BHO for live.com, yahoo.com, and google.com.  If one of these domains are found in the URL, it starts looking for the search term, which is usually prefaced with something like, “&q=TERM” in Google’s case, or “&p=TERM” in Yahoo’s. It then harvests these query terms for later use and possibly evasion of click fraud detection algorithms.

After the term is found, a connection is made to takeasearch .com and the Bho sends the search term and a machine identification number, which is derived from your primary hard disk’s serial number.  The information that the takeasearch .com site returns tells the BHO what to do next.  There are several commands that can be returned from the web presence: DL:, GO:, REF: and OK:.

The first code path for the Bho to take depends on the returned data containing “DL: URL”. The BHO will send an Http GET to the URL as specified by the “DL:” command, saving the response to a file in the “C:\Program Files” directory, naming it “KB%i.exe”. The %i represents a random number generated by the rand() function.  The downloaded file is then executed via the ShellExecute() API.

If the response contains “GO: “, followed by a URL, the browser will be redirected to that URL.  There is also a timer that runs within Internet Explorer that will control the malware’s launch of a new instance of IE. This instance of  Internet Explorer is launched with a hidden window, so the browser runs on the system without the user’s consent or knowledge. The hidden browser will periodically connect to searchaccelerator .net with the machine identification token. As witnessed with the takeasearch .com result, if a “GO: ” response is provided to the hidden browser, it will be sent to several addresses that redirect the browser to its final destination. This final destination page is covered with ads that reportedly are “pay per impression” with revenues split between affiliates.

Here’s a sample conversation from the “hidden” Internet Explorer window. It is full of redirection:

1) GET http ://searchaccelerator .net/qi3.php?YBNz(shortened)
SERVER HTTP RESPONSE:
REF:http ://totalfinder .info/ search.php?q=Insurance%20recovery%20cars|GO:http ://totalfinder. info/clicks?719578181|DST:comparedby.us1234|RVER:80|TIMW:8|

We can see that the response contains several pieces of information, delimited by the vertial-pipe character. All of this information specifies the queries that the malware running on the user’s system is to carry out. The REF field tells the BHO to set the “Referrer: ” http header to the specified URL when sending a GET to the target URL, specified by the GO field.  The DST field is the browser’s final destination.

2) GET http ://totalfinder .info/ clicks?719578181
SERVER HTTP RESPONSE:
HTTP/1.1 302 Found
Server: Apache/1.3.41 (Unix) PHP/5.2.9
Location: http: //totalfinder .info/ search.php?q=Insurance%20recovery%20cars&sess=719578181

We can see in the response that the web server at totalfinder .info has redirected the browser via the “302/Found” HTTP response code to the next url. This subsequent url is also on the totalfinder .info domain, but this time, we observe high value search terms present in the URL itself: “Insurance recovery cars”. The redirection contains additional information, in our labs, we observed that these queries were most likely harvested from other infected systems, in an effort to randomize the redirected query terms.

3) http ://totalfinder .info/search.php?q=Insurance%20recovery%20cars&sess=719578181
SERVER HTTP RESPONSE:
<html><body><form name=”formrfgz” action=”http://68.169.70. 144/ go.php” method=”GET” target=”_top”><input type=”hidden” name=”c” value=”—truncated for brevity—”></form><script language=”JavaScript”>formrfgz.submit();</script></body></html>

On the third leg of redirections, we can see the that we actually load a regular web page with some html and a javascript.  On this page there is a form, with an action attribute that contains a URL to which the formrfgz.submit() function will tell the direct the browser to fetch this url.

4) http://68.169.70. 144/ go.php?c=truncated-for-brevity-again
SERVER HTTP RESPONSE:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Content-Type: text/html
Location: http ://3151.90539.discover-facts .com/jump1/ ?affiliate=3151&subid=90539&terms=insurance%20recovery%20cars&sid=TRUNCATED&a=zh5&mr=1&rc=0

Again, we see another 302 status redirect to a different URL.

5) GET http ://3151.90539.discover-facts .com/jump1/ ?affiliate=3151&subid=90539&terms=insurance%20recovery%20cars&sid=TRUNCATED&a=zh5&mr=1&rc=0
SERVER HTTP RESPONSE:

<script language=”javascript”>
function v3clicktoit ()
{
document.clickit.submit();
}
</script>

<body bgcolor=”#FFFFFF” OnLoad=”Javascript:v3clicktoit()”>
<form name=”clickit” method=”POST” action=”/jump2/?affiliate=3151&subid=90539&terms=insurance%20recovery%20cars”>
<input type=”hidden” name=”kw” value=”insurance recovery cars”>

The fifth redirect loads a regular webpage as was seen in redirect 3, and it uses the same submit() javascript function to direct the browser to “POST” the form, to the next URL.

6) http://3151.90539.discover-facts .com/jump2/ ?affiliate=3151&subid=90539&terms=insurance%20recovery%20cars
SERVER HTTP RESPONSE:
<frame name=’target’ src=”http ://r.looksmart .com/og/ ad=725195471;ag=732989664;kw=930857280;qt=insurance%20recovery%20cars;ip=127.0.0.1;geo=0;vid=0;rm=|http ://www.comparedby .us/ lander.aspx?pmkeyword=insurance%20recovery%20cars&referrer=looksmart-a&camp=Moxy+H+RON&group=Moxy+H+RON&keyword=insurance%20recovery%20cars”>

As we near completion of our redirects, we can see a frame on this page, which loads the ‘target’ url which is on the r.looksmart .com domain.  It contains many parameters in the URL, which was shortened a bit, but still shows some of the interesting pieces of information being passed along.  From what we’ve seen thus far, we can speculate that there is an advertisement id, advertisement group, keyword id, query term, the computers external IP address, geological location id, and a the destination URL.

7) http ://r.looksmart .com/og/ …
RESPONSE:
HTTP/1.1 302 Found
Location: http ://www.comparedby .us/ lander.aspx?pmkeyword=insurance%20recovery%20cars&referrer=looksmart-a

After this last “Found” redirect, we arrive out our destination. Here is a list of final destinations for the Bho and hidden IE process, and matching query terms returned by the servers:

iaf .net — injury lawyer
yb .com — maricopa employment
theyellowpages .com — car insurance quotes
comparedby .us — sewing material
theyellowpages .com — fish window cleaning
comparedby .us — memory tattoos
glimpse .com — QUEST SECURITY
allthebrands .com — sowing machine
yellowpages.lycos .com — teleflora
hotjobs .com — lyrics to anberlin unwinding cable car
hotjobs .com — mortgage companys in brownsville
theproductdepot .net — where does ivy tech culinary arts program rank
healthline .com — commercial locksmiths contra costa
yellowbook .com — will st johns wort stop pantic attacks
freepornvideos .com — anniversary party
hilcoind .com — scoliosis
longmontflorist .com — hall funeral home
milehigh-harley .com — www rentals
comparedby .us — advanced driver improvement

In all search queries above, the common points of redirect are 206.161.121. 110, 68.169.70. 144, local-search-pages .com, discover-facts .com, find-dozens .com.  Not coincidentally, all of the domains hide behind the same privacy registration service, making whois registration information unavailable.

In some instances, the search query is handed off to pay-per-click advertising sites and in others it passes the search directly to a site with an affiliate-id. It’s a complicated trail to follow, considering all of the redirections and affiliates, but the end result is artificially generated traffic to ad-serving sites. And stealing real search queries, misspellings and all, help to create data that best replicates input from a real online “consumer”.

Cutwail/Pandex reader_s.exe Continues to Deliver Spambots and mmx Evasions throughout Shutdowns

Monday, August 10th, 2009

Cutwail (also known as Pandex) malware is not a new family name on the bot scene. However, the Cutwail/Pandex botnet is described as one of the largest and most active botnets currently known. This resilient botnet managed to bounce back after both the McColo ISP and the more recent Pricewert/3FN ISP shutdowns in California, both of which brought down global levels of spam for a short time and cut off the control servers where many bots retrieved their command and control instructions.
To further the botnet’s resilience and spread, the distributors of the malicious executables attempt to re-pack and re-obfuscate the components to evade security file scanners on victim systems. The executable runtime behavior may change across variants just a bit, but the fingerprint and physical makeup changes dramatically. This type of evasion, of course, is ineffective against a behavioral-based solution like ThreatFire. Cutwail is succesfully prevented from running on ThreatFire community user systems on a daily basis.

Some of the latest Cutwail/Pandex variants are themselves delivered in a variety of ways to a user’s system, renamed to reader_s.exe and run (note, other prevalent and current variants are renamed to update.exe). Reader_s.exe drops 0.exe, which drops an ADS or “alternate data stream” to the drive. This sort of location on the drive is tricky for a user to spot, because the svchost.exe:ext.exe stream cannot be seen as a file within an explorer window. This ADS executable code is installed as a system service by the Cutwail dropped executable 0.exe. Then, 0.exe launches and hijacks a svchost.exe process, communicating from it over an encrypted channel to a set of ip addresses. These communications eventually result in the compromised system gathering information to spew enough spam to help generate over 74 billion messages a day from the botnet.

The packing and evasion techniques implemented within these executables changes over time. One of the recent techniques is one that we have seen before in a variety of Fakealert executables in the past — intermixing random mmx instructions into the compiled code itself. These instructions have no functional purpose whatsoever. They simply modify values within the mmx registers arbitrarily. Intermixing the mmx instruction set unexpectedly within functions using the general-purpose intel instructions can cause problems for recognizing Cutwail malcode for emulators, backend automation, and AV scanners themselves — the evasion technique can be effective.

You can see one such function that was modified with mmx “nop” filler:

Protecting your system from becoming a part of the largest, most active botnet on the web requires an effective behavioral based layer like ThreatFire.

South Korea and U.S. Government Sustained DDoS

Thursday, July 9th, 2009

The botnet driven distributed denial of service attack that started over the weekend has been attacking American agency web sites like the White House web site, the FTC site, NYSE site, FAA, NSA, Dept of Homeland Security, the Treasury, and many more agency web sites is a pretty bold thing to do. The botnet also has many South Korean web sites in its crosshairs as well, including the president’s and various news and commerce sites.

We are examining the binaries involved, and ThreatFire could have protected those systems from the bot, stopping its dropper, and in turn, prevented at least some of the DoS flood on these U.S. and the many South Korean web sites. The underlying code itself appears to be fairly unsophisticated.

One of the malicious DoS components is delivered unpacked, sets itself up as a service, and contains a handful of commonly used user agent strings to camoflage its GET and POST traffic. Interestingly, we find “Accept-Language: ko, UA-CPU: x86″ in the http headers. We are further looking into an unusual dependency on pcap for network traffic requests: pcap_open, pcap_sendpacket, and other functions are abused by this malware, but it uses common winsock calls to perform its network activity too.
Here it uses an extremely common registry editing technique to disable the compromised host’s Windows firewall:

In the meantime, government, network operators and web masters in both countries are working to tame this thing.