how malware prevents programs from running

In today’s battle with malware, I learned a couple of interesting new places in the registry to check:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Place a key in here named after the file you want to prevent running, then place a STRING value under the key named “debugger”. Now, set the value of “debugger” to cmd, or some other relatively harmless executable that ignores its standard input – and presto, the application matching the keyname won’t run. BAD MALWARE. NO COOKIE.

Ironically, this is also quite useful for the GOOD guys keeping relatively clueless but persistent users from running things they really shouldn’t, like notorious P2P clients. For extra points, create a file C:\null.cmd or similar that simply exits, and use that as the “debugger” – they don’t even see anything happening at all, it just “doesn’t work”. This will probably frustrate them enough to desist, at least for a while… particularly given how used they probably are to the machine not working, if they’re that persistently malwaring it up in the first place.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun

Place a STRING value in here, and ditto above. (This is where GPO disallowing particular mutexes (I think it’s by mutex, not filename) to run takes effect.)

The More You Know…

When Outlook stops getting new IMAP mail

The problem is almost certainly that its local cache is corrupt… which happens disturbingly frequently. The easiest way to fix it is to simply close Outlook, delete the local cache, then start Outlook again – the good news being that it works and your new mail starts showing up; the bad news being, of course, that it starts synchronizing /everything/ again.

Stick this command in a batch file, and you’ll have something that users can simply double-click to fix the issue. Just remember to tell them to CLOSE OUTLOOK FIRST! =)

del "%UserProfile%\Local Settings\Application Data\Microsoft\Outlook\*IMAP*-0*.pst"

Slow domain login on Windows 7

Had a client whose login to the domain took upwards of 40 seconds on his Windows 7 machine.  Oddly, completely deleting the profile from his workstation didn’t fix the issue – even after setting up the profile anew after first domain login, it still took upwards of 40 seconds.  Just as oddly, other profiles on the domain didn’t have the same issue on his workstation – they logged in in less than 10 seconds.

Never did figure out what caused it, but I did find a cure –

  • Run gpedit.msc.
  • Go to computer configuration.
  • Go to Administrative templates.
  • Go to System.
  • Go to User profiles.
  • Enable “Set maximum wait time for the network if a user has a roaming user profile or remote home directory” and set to 0 seconds

Problem solved; the user could now logon in less than ten seconds.