[andydis]

nuorder

glad u got it, pm me and ill give you my msn address if you want? (u 2 twistedps)

would love to know ur ethereal results :-)

[Spookie]

ZinCite.A is a new Trojan horse that is dropped by the MyDoom.O worm.

ZinCite.A gives a remote attacker backdoor access, connects to other infected computers for unknown purposes and can receive uploaded executable files.

Creates the following Windows registry entries:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Services=Windows directory\services.exe

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Services=Windows directory\services.exe

Once installed, ZinCite.A opens TCP port 1034 and attempts to contact other infected computers.



Cleanup Tool Available Here from Symantec

[twistedps]

have any of you seen recent emails with .zip files about 1-2k and .com/.pif's in them?
I've been to a few client sites who are getting TONS of these, and some with scattered data in the body of the email...

I've tried dissassembling the .pif within these files, yet it seems to be packed/encrypted in some way that im unfamiliar with

it seems similar to this MyDoom.M file thats going around but its MUCH smaller as i stated previously.

I've tried running it and monitored my registry and such, and see no changes happen, the .COM/.PIF file seems to terminate with a weird system error, yet doesnt seem like something a virus would produce...

so far i havent seen any implications of this smaller .zip file, yet only time will tell...

the clients that ive seen this running on are commonly using Trend's newest pattern .945 i believe or .954 (i forget),..

its damn suspicious..
i'll be sure to update with any information i found...

sorry i stopped the dissassembly process yesterday, got rushed to a client site to do some stuff, and had to stop 'playin around' hehe..
by the time i got back trend already posted an analysis of it, so no further digging was required.

[andydis]

Quote

emails with .zip files about 1-2k and .com/.pif's in them?

hey mate, this netsky?

wanna up a sample?�

[brainbuster]

anyone knows how to use the backdoor spawning on port 1034
scanned 4 it and finds some boxes... no banners and stuff =\

[Xantix]

the backdoor is useless, it only gives an open port and then connection abort, absolutely useless like all the other backdoors which come with those worms (I remember that nearly every worm has a correspondent backdoor)
1034 is also well used so it wont be able to run everywhere
imho -> crap

[mortello]

brainbuster, on Jul 27 2004, 06:56 PM, said:

anyone knows how to use the backdoor spawning on port 1034
scanned 4 it and finds some boxes... no banners and stuff =\

You probably need to deencrypt the virus to see what you need to get in an infected box,.....a little like the original MyDoom epxloit....

so you need the skills or someone telling you what to do/giving you the tool to do it...

[Xantix]

how about reverse engineering the trojan itself

[twistedps]

twistedps, on Jul 27 2004, 05:30 PM, said:

have any of you seen recent emails with .zip files about 1-2k and .com/.pif's in them?
I've been to a few client sites who are getting TONS of these, and some with scattered data in the body of the email...

I've tried dissassembling the .pif within these files, yet it seems to be packed/encrypted in some way that im unfamiliar with

it seems similar to this MyDoom.M file thats going around but its MUCH smaller as i stated previously.

I've tried running it and monitored my registry and such, and see no changes happen, the .COM/.PIF file seems to terminate with a weird system error, yet doesnt seem like something a virus would produce...

so far i havent seen any implications of this smaller .zip file, yet only time will tell...

the clients that ive seen this running on are commonly using Trend's newest pattern .945 i believe or .954 (i forget),..

its damn suspicious..
i'll be sure to update with any information i found...

sorry i stopped the dissassembly process yesterday, got rushed to a client site to do some stuff, and had to stop 'playin around' hehe..
by the time i got back trend already posted an analysis of it, so no further digging was required.

I've spoken to Trend and Sophos about this problem, from what i can tell Sophos is saying that its a fragmented version of the MyDoom worm, but sicne its fragmented, it has no payload and doesnt do anything...

Quote

You probably need to deencrypt the virus to see what you need to get in an infected box,.....a little like the original MyDoom epxloit....

so you need the skills or someone telling you what to do/giving you the tool to do it...

Quote

how about reverse engineering the trojan itself

what do you think we've been doing?

Quote

the backdoor is useless, it only gives an open port and then connection abort, absolutely useless like all the other backdoors which come with those worms (I remember that nearly every worm has a correspondent backdoor)
1034 is also well used so it wont be able to run everywhere
imho -> crap

not everything is gonna give you a command prompt when you telnet to it man, sometimes you have to send the right sequence of commands to get a reponse, thats how most client/server programs work... if you just send AAAAAAA to a smtp server, its not gonna do shit.

anyways ive been looking around the code a bit, but cant seem to find a part where its calling htons 40A (1034 in hex), i see a bunch of htons calls, but its hard to distinguish what its doing.. *i hate asm by the way lol*

[twistedps]

Spookie, on Jul 27 2004, 05:21 PM, said:

ZinCite.A is a new Trojan horse that is dropped by the MyDoom.O worm.

ZinCite.A gives a remote attacker backdoor access, connects to other infected computers for unknown purposes and can receive uploaded executable files.

Creates the following Windows registry entries:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Services=Windows directory\services.exe

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Services=Windows directory\services.exe

Once installed, ZinCite.A opens TCP port 1034 and attempts to contact other infected computers.



Cleanup Tool Available Here from Symantec

do you or anyone else here have a copy of that SERVICES.EXE file?
I would like to dissassemble it alone, since it would make things a lot easier.

[twistedps]

I've gotten the services.exe part where it starts making the file...

.text:0050766B loc_50766B:                         ; CODE XREF: sub_5075E5+56j
.text:0050766B                                     ; sub_5075E5+64j ...
.text:0050766B                 lea     eax, [ebp+FileName]
.text:00507671                 push    offset aServices; lpString2
.text:00507676                 push    eax         ; lpString1
.text:00507677                 call    esi; lstrcatA
.text:00507679                 lea     eax, [ebp+FileName]
.text:0050767F                 push    offset buf  ; lpString2
.text:00507684                 push    eax         ; lpString1
.text:00507685                 call    esi; lstrcatA
.text:00507687                 lea     eax, [ebp+FileName]
.text:0050768D                 push    offset aExe ; lpString2
.text:00507692                 push    eax         ; lpString1
.text:00507693                 call    esi; lstrcatA
.text:00507695                 push    ebx         ; hTemplateFile
.text:00507696                 push    80h         ; dwFlagsAndAttributes
.text:0050769B                 push    2           ; dwCreationDisposition
.text:0050769D                 push    ebx         ; lpSecurityAttributes
.text:0050769E                 push    3           ; dwShareMode
.text:005076A0                 lea     eax, [ebp+FileName]
.text:005076A6                 push    0C0000000h  ; dwDesiredAccess
.text:005076AB                 push    eax         ; lpFileName
.text:005076AC                 call    ds:CreateFileA
.text:005076B2                 mov     edi, eax
.text:005076B4                 cmp     edi, 0FFFFFFFFh
.text:005076B7                 jnz     short loc_5076C8
.text:005076B9                 inc     [ebp+var_4]
.text:005076BC                 cmp     [ebp+var_4], 2
.text:005076C0                 jl      loc_507601
.text:005076C6                 jmp     short loc_50772B

so basically its creating the file name, that jnz call you see has it get the tmp directory, then the windows directory, and i guess copies it over...

.text:005076C8 loc_5076C8:                           ; CODE XREF: sub_5075E5+D2j
.text:005076C8                 push    edi
.text:005076C9                 call    sub_50737C
.text:005076CE                 pop     ecx
.text:005076CF                 push    edi           ; hObject
.text:005076D0                 call    ds:CloseHandle
.text:005076D6                 lea     eax, [ebp+FileName]
.text:005076DC                 push    eax
.text:005076DD                 lea     eax, [ebp+CommandLine]
.text:005076E3                 push    offset aS     ; LPCSTR
.text:005076E8                 push    eax           ; LPSTR
.text:005076E9                 call    ds:wsprintfA
.text:005076EF                 push    44h
.text:005076F1                 lea     eax, [ebp+StartupInfo]
.text:005076F4                 pop     esi
.text:005076F5                 push    esi
.text:005076F6                 push    ebx
.text:005076F7                 push    eax
.text:005076F8                 call    memset
.text:005076FD                 add     esp, 18h
.text:00507700                 lea     eax, [ebp+ProcessInformation]
.text:00507703                 mov     [ebp+StartupInfo.cb], esi
.text:00507706                 mov     [ebp+StartupInfo.dwFlags], 81h
.text:0050770D                 push    eax           ; lpProcessInformation
.text:0050770E                 lea     eax, [ebp+StartupInfo]
.text:00507711                 push    eax           ; lpStartupInfo
.text:00507712                 push    ebx           ; lpCurrentDirectory
.text:00507713                 push    ebx           ; lpEnvironment
.text:00507714                 push    ebx           ; dwCreationFlags
.text:00507715                 push    1             ; bInheritHandles
.text:00507717                 push    ebx           ; lpThreadAttributes
.text:00507718                 lea     eax, [ebp+CommandLine]
.text:0050771E                 push    ebx           ; lpProcessAttributes
.text:0050771F                 push    eax           ; lpCommandLine
.text:00507720                 push    ebx           ; lpApplicationName
.text:00507721                 mov     [ebp+StartupInfo.wShowWindow], bx
.text:00507725                 call    ds:CreateProcessA
.text:0050772B 
.text:0050772B loc_50772B:                           ; CODE XREF: sub_5075E5+E1j
.text:0050772B                 pop     edi
.text:0050772C                 pop     esi
.text:0050772D                 pop     ebx
.text:0050772E                 leave
.text:0050772F                 retn
.text:0050772F sub_5075E5      endp

this seems to be where it is creating the file putting all the crap up, and you can see it then creates the process, and exits... just like the exit call would be called below..

now back up before this... in the previous quote..

the second compare jmp

Quote

...
.text:005076BC                cmp    [ebp+var_4], 2
.text:005076C0                jl      loc_507601
.text:005076C6                jmp    short loc_50772B
...

(i believe this is what happens if something fails, maybe if the file is existant... it just clears and exits)

.text:0050772B loc_50772B:                          ; CODE XREF: sub_5075E5+E1j
.text:0050772B                 pop     edi
.text:0050772C                 pop     esi
.text:0050772D                 pop     ebx
.text:0050772E                 leave
.text:0050772F                 retn
.text:0050772F sub_5075E5      endp

now im not too great at assembly, i left out some of the callsto getting tmpdir and getting windir, but you can get the jist of whats going on i hope...
ineed that services.exe file to do further research, so lemme know if ya got it.

:) hope tihs helps someone.

[Xantix]

here you go
I infected a korean machine and got the trojan, be careful its detected by av scanners
pass: onlyforgso

I also renamed the services.exe because on some machines the windows file protection goes crazy and you cant remove the file anymore

A decompiled version of the exe would help me very much as I'm doing research myself on it also.

Lets go for it m8 :)

Attached File(s)

•  trojan.rar (6.58K)
  Number of downloads: 69

[Spookie]

Quote

have any of you seen recent emails with .zip files about 1-2k and .com/.pif's in them?
I've been to a few client sites who are getting TONS of these, and some with scattered data in the body of the email...

I've tried dissassembling the .pif within these files, yet it seems to be packed/encrypted in some way that im unfamiliar with

it seems similar to this MyDoom.M file thats going around but its MUCH smaller as i stated previously.

Lovegate.BA was documented by Trend on the 26th. It is 153,600 bytes uses Pif.s as well

Quote

the backdoor is useless, it only gives an open port and then connection abort, absolutely useless like all the other backdoors which come with those worms (I remember that nearly every worm has a correspondent backdoor)

I have to disagree with you on the crap comment. I think who ever is behind it put some thought into it.

This post has been edited by Spookie: 28 July 2004 - 06:58 AM

[twistedps]

thanks for the quick reply and the posting of the services.exe file, seems to be a good find...
this was also upx packed, packed size 8k, unpacked size 10k...

some of the interesting things that i tried to find before...

.text:00401FB8 loc_401FB8:                           ; CODE XREF: sub_401F0E+84j
.text:00401FB8                 push    6
.text:00401FBA                 push    1
.text:00401FBC                 push    2
.text:00401FBE                 mov     [esi+6], ax
.text:00401FC2                 call    ebp
.text:00401FC4                 push    10h           ; namelen
.text:00401FC6                 push    edi           ; name
.text:00401FC7                 push    eax           ; s
.text:00401FC8                 mov     [esi+14h], eax
.text:00401FCB                 call    ds:bind
.text:00401FD1                 test    eax, eax
.text:00401FD3                 jnz     short loc_401F94
..... [when jnz is called]
.text:00401F94 loc_401F94:                           ; CODE XREF: sub_401F0E+C5j
.text:00401F94                 push    dword ptr [esi+14h]; s
.text:00401F97                 call    ds:closesocket
.text:00401F9D                 push    0FAh          ; dwMilliseconds
.text:00401FA2                 call    ds:Sleep
.text:00401FA8                 mov     word ptr [edi], 2
.text:00401FAD                 and     dword ptr [esi+8], 0
.text:00401FB1                 push    40Ah          ; hostshort  
.text:00401FB6                 call    ebx; htons
.... [notice push 40Ah]... thats 1034 in decimal, its in hex at the moment.
so it seems this is where its creating the socket... and binding to the port.

ok did some searching again for 2min...
im having trouble figuring out where its getting the actual call for connected..
one thing i did notice that was a bit weird is this one out of two strings..

00401170 aZincite        db 'zincite',0         ; DATA XREF: sub_401C50+5Ao
.text:00401170                                        ; sub_401F0E+40o

its being used here:

00401C9D loc_401C9D:                            ; CODE XREF: sub_401C50+2Aj
.text:00401C9D                                        ; sub_401C50+36j ...
.text:00401C9D                 push    esi
.text:00401C9E                 mov     esi, ds:lstrcatA
.text:00401CA4                 lea     eax, [ebp+FileName]
.text:00401CAA                 push    offset aZincite; lpString2
.text:00401CAF                 push    eax            ; lpString1
.text:00401CB0                 call    esi; lstrcatA
.text:00401CB2                 lea     eax, [ebp+FileName]
.text:00401CB8                 push    offset String2 ; lpString2
.text:00401CBD                 push    eax            ; lpString1
.text:00401CBE                 call    esi; lstrcatA
.text:00401CC0                 lea     eax, [ebp+FileName]
... in the file creation process i believe

and....

00401F4E loc_401F4E:                            ; CODE XREF: sub_401F0E+3Aj
.text:00401F4E                 push    offset aZincite; "zincite"
.text:00401F53                 call    sub_402746
.text:00401F58                 mov     ecx, [esi]
.text:00401F5A                 mov     [ecx+10h], eax
.text:00401F5D                 push    dword ptr [esi]
.text:00401F5F                 call    sub_40272D
.text:00401F64                 call    sub_401D22
.text:00401F69                 push    dword ptr [esi]
.text:00401F6B                 call    sub_401C50
.text:00401F70                 mov     ebx, ds:htons
.text:00401F76                 and     dword ptr [esi+8], 0
.text:00401F7A                 add     esp, 0Ch
.text:00401F7D                 lea     edi, [esi+4]
.text:00401F80                 push    40Ah           ; hostshort
.text:00401F85                 mov     word ptr [edi], 2
.text:00401F8A                 call    ebx; htons
.text:00401F8C                 mov     ebp, ds:socket
.text:00401F92                 jmp     short loc_401FB8
.text:00401F94; ---------------------------------------------------------------------------

which seems to be used in the binding of the port....
its POSSIBLE, im not saying this to be positive at all, but this may have to be a passphrase or something to get access.... idonno, i need to look at it a LOT MORE, but i have to rush off to a client site..

if any of you have anything to contribute from yer own findings lemme know! it would be greatly appreciated, i can only do so much heh

[Spookie]

Quote

its POSSIBLE, im not saying this to be positive at all, but this may have to be a passphrase or something to get access.... idonno, i need to look at it a LOT MORE

F-Secure -Zindos is the write up on the trojan. You might find this interesting.