dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
4178

Noah Vail
Oh God please no.
Premium Member
join:2004-12-10
SouthAmerica

Noah Vail

Premium Member

Instantly kill an executable as soon as it launches

Sometimes I like to play with new malware before I clean it and want to auto-kill it's executable files on launch.

The following command creates a registry entry to do that.
reg add "hklm\software\microsoft\windows nt\currentversion\image file execution options\malware.exe" /v Debugger /d Disabled
 

This attaches a disabled debugger to the .exe, effectively shutting it down.

Problem:
Windows assumes it can't locate the .exe and may pop up error notifications.
It can also fill up event logs - especially if malware.exe launches frequently.

So I tried a couple of things and this seems to work without popups or logging any errors.

reg add "hklm\software\microsoft\windows nt\currentversion\image file execution options\malware.exe" /v Debugger /t REG_SZ /d "C:\Windows\System32\taskkill.exe /F /IM malware.exe"
 

Instead of a disabled debugger we use a bogus one (taskkill) that shuts the executable down immediately upon launch.

I've also used this to quickly+easily prevent other apps from launching, especially if Group Policy isn't available.

One example - a fast way to prevent Avira popups
reg add "hklm\software\microsoft\windows nt\currentversion\image file execution options\avnotify.exe" /v Debugger /t REG_SZ /d "C:\Windows\System32\taskkill.exe /F /IM avnotify.exe"
 
reg add "hklm\software\microsoft\windows nt\currentversion\image file execution options\ipmgui.exe" /v Debugger /t REG_SZ /d "C:\Windows\System32\taskkill.exe /F /IM ipmgui.exe"
 

which is quickly reversed by running these two commands
reg delete "hklm\software\microsoft\windows nt\currentversion\image file execution options\avnotify.exe" /f
 
reg delete "hklm\software\microsoft\windows nt\currentversion\image file execution options\ipmgui.exe" /f
 

One advantage over a Group Policy Software Restriction is that this approach isn't path dependent.
It is easily defeated by renaming the executable, however - providing someone (or the malware algorithm) happens to try that.

norwegian
Premium Member
join:2005-02-15
Outback

norwegian

Premium Member


Do you ever have the settings to actually debug instead of stopping?
Is the .exe allowed to run fully, then you apply this key, or just as a stopper; I wonder if it extracts files that load the malware points and you stop it, then what are you achieving? Do you consider the info you gather before this point enough?

ashrc4
Premium Member
join:2009-02-06
australia

ashrc4 to Noah Vail

Premium Member

to Noah Vail
Try running your executable against one of these.
»nakedsecurity.sophos.com ··· crowave/
dave
Premium Member
join:2000-05-04
not in ohio

2 edits

dave to Noah Vail

Premium Member

to Noah Vail
To the best of my knowledge, if you have a registry entry for 'foo.exe' that mentions some debugger 'dbug.exe', then what the system does is to create a process running dbug.exe.

The debugger is supposed to initialize itself and then create a separate process to run foo.exe; so if the thing you run (dbug.exe) isn't really intended as a debugger, it likely won't run foo.exe at all.

Having the debugger create the debuggee is necessary to get the process ownership correct, so that an actual debugger can ferret around in the debuggee.

Certainly, for actual debugging, the debugger needs to be able to gain control before the debuggee has executed any instructions -- otherwise there would be parts that you could not debug. So even if I'm wrong about the startup procedure (which I doubt), it will not be the case that foo.exe (in my example) gets to do anything before the debugger can step in.

>This attaches a disabled debugger to the .exe, effectively shutting it down.

I don't think so - unless the word 'disabled' is special in some way, it attempts to run a debugger named 'disabled', which probably doesn't exist, and that's why you get a file-not-found error.

>So I tried a couple of things and this seems to work without popups or logging any errors.

Yes, but killing malware.exe is a no-op because no-one ever started malware.exe.

norwegian
Premium Member
join:2005-02-15
Outback

norwegian to Noah Vail

Premium Member

to Noah Vail

You also need the file name to set the key. If you're setting a key to stop a known name before it starts - then what are you achieving other than creating an extra policy after the fact?

I'm still a little confused, you want to test; but you want it to stop?
How are you logging what it is doing then?
redwolfe_98
Premium Member
join:2001-06-11

4 edits

redwolfe_98 to Noah Vail

Premium Member

to Noah Vail
i don't understand wanting a file to run and then to be killed, but i do understand wanting to prevent a file from running at all..

you mentioned avira's "avnotify.exe" and "ipmgui.exe".. i read that those processes can be prevented from running by modifying the files' "permissions":

(for windows xp-home, you have to boot into "safe mode" in order to be able to adjust "permissions" for files.. with windows xp-pro, you can adjust the file-permissions without first booting into "safe mode")

1. Boot into Safe Mode (tap F8 repeatedly after you restart the computer)
2. Log in using the Administrator account
3. Go to C:\Program Files\Avira\AntiVir PersonalEdition Classic\avnotify.exe
4. Right-click avnotify.exe-> properties-> security-> advanced
5. Under the Permissions tab click on SYSTEM under Permission entries:
6. Edit-> Traverse Folder / Execute File-> deny-> ok ->apply-> yes -> ok-> ok
7. Reboot the computer into Normal Mode (start-> shutdown-> restart)
- - - - - - - - - - - -

avira's "avswc.exe" is another avira-file that i block from running, in addition to blocking avira's "avnotify.exe" and "ipmgui.exe" from running..

i tried using "ACL", "access control list", to prevent the files from running, but the problem was that, since, when using "ACL" to block access to the files, the files could not be read, when i would run avira's updater, the updater would download and install new copies of the files which did not have the "ACL" restrictions applied to them..

as far as i can tell, adjusting the "permissions", as mentioned above, prevents the files from running..

before finding the information about adjusting the file-permissions, i had used "system safety monitor" to block the avira files from running, but something changed with one of the avira program-updates where "windows" would generate a message saying "ipmgui.exe" was not able to run", which i had not been seeing before the update for the avira program.. so, i could have just lived with it, or unblock "ipmgui.exe", if i didn't want to see the message popping up, saying that "ipmgui.exe" could not run.. i opted to unblock "ipmgui.exe", in SSM's rules.. it wasn't really hurting anything for it to run, not on my computer.. but, adjusting the file-permissions seems to have killed it, and without having the messages popping up saying "'ipmgui.exe' was not able to run"..

interestingly, at the avira website, avira says that the new free version of avira 13 doesn't generate any popup-ads.. i don't really know what to think.. first avira stupidly builds a spam-machine into the premium version of avira 12 (ipmgui.exe); now they say the free version of avira 13 doesn't have any popup-ads.. like i said, i don't know what to think.. i haven't installed avira 13 so it is hard for me to know what it is like or to comment on it.. the question is, if the free version of avira 13 no longer has any popup-ads, does that mean that, likewise, the premium version also no longer has any popup-ads (which were generated by "ipmgui.exe" )?
psloss
Premium Member
join:2002-02-24

psloss to dave

Premium Member

to dave
said by dave:

To the best of my knowledge, if you have a registry entry for 'foo.exe' that mentions some debugger 'dbug.exe', then what the system does is to create a process running dbug.exe.

Yes; what's even more interesting is if dbug.exe attempts to launch foo.exe without debugging...after I screwed that up, I had some reading to do after looking up "IFEO infinite loop."

Some unwanted-ware uses this. One example is the subtle usage on a system we hosed off in the summer:

Entries for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\a.exe [24 May 2012 04:40:33 GMT]:
'Debugger' = 'svchost.exe' (FID = 310)
 
Entries for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\aAvgApi.exe [24 May 2012 04:40:33 GMT]:
'Debugger' = 'svchost.exe' (FID = 310)
 
Entries for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\AAWTray.exe [24 May 2012 04:40:33 GMT]:
'Debugger' = 'svchost.exe' (FID = 310)
 
Entries for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\About.exe [24 May 2012 04:40:33 GMT]:
'Debugger' = 'svchost.exe' (FID = 310)
 
(700+ entries later)
 
Entries for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\~1.exe [24 May 2012 04:40:35 GMT]:
'Debugger' = 'svchost.exe' (FID = 310)
 
Entries for HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\~2.exe [24 May 2012 04:40:35 GMT]:
'Debugger' = 'svchost.exe' (FID = 310)
 

It's better tactically to know what file name one wants to undermine, so this is probably a better trick for the bad guys. (And some have been using it for plenty of time.)

norwegian
Premium Member
join:2005-02-15
Outback

norwegian

Premium Member


That would have you scratching your head if you were not aware of it.