Log in

View Full Version : seems to some script kiddies autit v3 virus

blabberer
January 21st, 2008, 12:48
attached here with is a malware that kills cmd.exe probably sets hklm\\...\\..\policies (disabling regedit , taskmgr disabling folder options and shit the usual crap tricks possibly spawns NEW FOLDER.exe multiple times
and sets up a reg key as yahoo messenger in various places for autoruns)

scvhost.exe c:\windows\scvhost.exe
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

HKCU\Software\Microsoft\Windows\CurrentVersion\Run



it seems to be an autoit v3 executable

password is malware

it is a rar archieve renamed as zip

for anyone wishing to retrieve the autoit script
Kayaker
January 22nd, 2008, 23:30
It looks like it might have a keylogger of sorts in it. I noticed a reference to AttachThreadInput, as well as associated GetKeyState, GetKeyboardState functions. Googling for 'AttachThreadInput keylogger' will pull up appropriate references.


The autoit script kiddie shenanigans aside, it made me wonder what else AttachThreadInput could be used for. If it's that easy to intercept keyboard input from another thread, why couldn't an app create such a secondary thread to monitor keyboard input from its registration dialog?

The whole GetDlgItemText/WM_COMMAND mechanism of the primary thread would actually be a red herring. The secondary monitoring thread set up with AttachThreadInput would be doing the actual registration verification even while the user is typing in the information.

One of those "try it dummy and find out if it works" ideas I guess..


Quote:

The AttachThreadInput function attaches or detaches the input processing mechanism of one thread to that of another thread.


BOOL AttachThreadInput(
DWORD idAttach,
DWORD idAttachTo,
BOOL fAttach
);

Parameters
idAttach
[in] Identifier of the thread to be attached to another thread. The thread to be attached cannot be a system thread.
idAttachTo
[in] Identifier of the thread to which idAttach will be attached. This thread cannot be a system thread.
A thread cannot attach to itself. Therefore, idAttachTo cannot equal idAttach.
fAttach
[in] If this parameter is TRUE, the two threads are attached. If the parameter is FALSE, the threads are detached.

Remarks

Windows created in different threads typically process input independently of each other. That is, they have their own input states (focus, active, capture windows, key state, queue status, and so on), and they are not synchronized with the input processing of other threads. By using the AttachThreadInput function, a thread can attach its input processing to another thread. This also allows threads to share their input states, so they can call the SetFocus function to set the keyboard focus to a window of a different thread. This also allows threads to get key-state information. These capabilities are not generally possible.

The AttachThreadInput function fails if either of the specified threads does not have a message queue. The system creates a thread's message queue when the thread makes its first call to one of the USER or GDI functions. The AttachThreadInput function also fails if a journal record hook is installed. Journal record hooks attach all input queues together.

Note that key state, which can be ascertained by calls to the GetKeyState or GetKeyboardState function, is reset after a call to AttachThreadInput. You cannot attach a thread to a thread in another desktop.
dELTA
January 23rd, 2008, 13:19
Hehe, nice protection idea, someone should put that in a crackme or something. ZaiRoN?
JMI
January 23rd, 2008, 13:37
Zai is off to New York for a few days!

Regards,
dELTA
January 23rd, 2008, 13:50
Actually, he's not leaving until tomorrow. But he could also read this when he returns of course.
JMI
January 23rd, 2008, 14:29
True, but that would be ignoring the part where he said he is very busy at the moment ,"getting ready to go."

Regards,
L. Spiro
January 24th, 2008, 02:46
The guy next to me in the office just clicks everything without thinking about it and got this on his computer.

The version he got does not put a bunch of “New Folder.exe” files but rather it keeps track of the folder you put on the thumb drive and makes an executable with the same name (and hides the folder you added).

“AutoItV3” appears in the manifest of the executable(s) and they import the same suspicious functions so I am sure it is another variant of the same thing.


The same as above, this is a .rar file renamed to .zip.
This is the copy it always leaves on any thumb drives that go into his computer.


Once run, it takes over your computer, shutting it down if you do anything it doesn’t like, such as opening Task Manager.
The infected files in this case seemed to be msnmsgr.exe and vistaware.exe. I did not check the registry for changes.

I disable it on his computer (temporarily) by opening it with MHS and causing it to crash by deleting its code with the hex editor. After that it will not reboot your computer when it sees something it does not like.
I suppose most people have sandboxes or virtual machines so it wouldn’t be much of an issue (but my coworker does not).


L. Spiro
blabberer
January 24th, 2008, 12:14
heh it kills cmd.exe and anything else that kills cmd.exe doesnt kill a bat till now so kill them with bat

right click new text document
tasklist > foo.txt
notepad foo.txt
taskkill /f /im new* /im scv*

tasklist > foo1.txt

file save save as "foo.bat"
double click and be happy