Slashdot Mirror

Or... just tell people not to download crap from 'teh interweb'.

I suppose that anyone in the computer tech/repair shop industry might appreciate tools like Rootkit Revealer right now.

Hopefully Microsoft's project that hasn't been released yet will show up soon. They also have a few hints to detect rootkits installed on a system including two Slashdot links.

Hooray for AOL.

Check out this webcast from Microsoft. While not as in-depth as some of us would like, it has some good information on things you can do to prevent rootkit infection.

Also, check out SysInternal's RootKitRevealer. Not only is it a handy tool, but the page gives a pretty good definition of rootkits as they apply to Windows.

A root kit is a set of tools used by an intruder after cracking a computer system. These tools can help the attacker maintain his or her access to the system and use it for malicious purposes.

The term rootkit is used to describe the mechanisms and techniques whereby malware, including viruses, spyware, and trojans, attempt to hide their presence from spyware blockers, antivirus, and system management utilities.

The difference is, in unix type systems, SIGTERM and SIGKILL are handled by the OS and the process is only informed of them (so it can try to shut down properly), in Windows, the process is being asked nicely to close. Windows process is free to ignore these events.

No, no, and no. It's true that in the "Tasks" or "Applications" tab, hitting End Task will send a request (WM_QUIT) to exit. That's not what I'm talking about. I mean the Processes tab. That is handled by the OS; it routes through Win32 first but ends up at NtTerminateProcess (ZwTerminateProcess). Go read the API reference or even the DDK if you don't believe me. Maybe in the dark days of Win9x that was true, but the NT kernel is a real OS, no matter what other crap you layer on top of it.

There are only three states a process can be in where it's unkillable.

1. "Access denied". This happens on some system processes because they run as the user SYSTEM (equivalent to root), where your task manager process is not. The security descriptor on those processes is set so that nobody except SYSTEM (not even Administrators) can kill them. They can be killed by running task manager as SYSTEM. There are various methods to run a process under the system account; the easiest is by using the "at" command to have the scheduler service start it. Newer versions of task manager also have a list of processes it will refuse to kill, but you can still kill them by using pskill or some other third-party utility that has no such restrictions.

2. Process is stuck in the kernel somewhere. Happens when system calls never return, which isn't supposed to happen. Often due to bad drivers -- even with flaky hardware it SHOULD timeout eventually. I've seen add-on firewall software that hooks the TCP stack and can cause this condition. Sometimes you can get one unstuck by kicking the kernel in the head (i.e. removing or stopping the offending device), otherwise a reboot is the only way to clear it. Unless you're running a checked build with a remote serial debugger, but not many people outside of driver developers do that.

3. Process has a debugger attached. In this case, simply kill the debugger instead.

To be fair, he was complaining about an explorer hang (he only bitched that the system was pretending to be idling).

That's quite common in some situations, and Russinovitch dissecates one quite nicely in his blog:
http://www.sysinternals.com/blog/2005/08/case-of-i ntermittent-and-annoying.html

It was probably just the loading of all the client EXEs, DLLs,and template files from the server. Use FileMon to monitor all the I/.O requests your own PC makes when you fire up Word or Powerpoint. Now multiply that times the number of clients you had running MS Office from the file server.

Process explorer from SysInternals queries the performance counters of .Net apps, showing some interesting figures. A couple of the metrics shown are % time in JIT and % time in GC (relative to the total CPU time of course)

They are very interesting. Start a reasonably complex app, and do stuff for the first time. % time in JIT will probably be 1% (and keep dropping.)

The % time in GC normally sits around 1%.

Junction lets you make symlinks in Windows without installing the entire Windows Resource Kit tools. Also, CACLS.EXE for changing ACLs in Windows via the command line, since I have no fucking clue where you do this in the GUI. Some of the more usefule CLI commands in Windows, IMO. I hope this discussion wasn't limited to Unix or anything.

I'd still LOVE to have a kill -9 for Windows

Ever try PSKill?

As for the technique, every loving file on my Windows boxen are MD5 checksummed and the master list is kept in an encrypted volume along with all my NDA stuff using DriveCrypt. If I have any reason to suspect something has tinkered with on my systems, and once a month no matter what along with other major maintenance, I do a diff on checksums. It's not hard, just a bit of tedium until you script it, just as with monitoring log files. I consider it right up there with my regular virus checks despite the fact that my security policies here would prevent one from even getting into a system in the first place. Insurance (risk management).

As for the technique, every loving file on my Windows boxen are MD5 checksummed and the master list is kept in an encrypted volume along with all my NDA stuff using DriveCrypt. If I have any reason to suspect something has tinkered with on my systems, and once a month no matter what along with other major maintenance, I do a diff on checksums. It's not hard, just a bit of tedium until you script it, just as with monitoring log files. I consider it right up there with my regular virus checks despite the fact that my security policies here would prevent one from even getting into a system in the first place. Insurance (risk management).

As for the technique, every loving file on my Windows boxen are MD5 checksummed and the master list is kept in an encrypted volume along with all my NDA stuff using DriveCrypt. If I have any reason to suspect something has tinkered with on my systems, and once a month no matter what along with other major maintenance, I do a diff on checksums. It's not hard, just a bit of tedium until you script it, just as with monitoring log files. I consider it right up there with my regular virus checks despite the fact that my security policies here would prevent one from even getting into a system in the first place. Insurance (risk management).

This has probably already been said but I'm pissed and am having a casual browse before bedtime....

Sysinternals

If you must use Windows these fine folk are well worth a visit (should be mandatory...)

Here's your problem with that.

Let's just say that such a tool compares kernel modules and key system files to a list of approved modules' checksums. A rootkit could easily modify the list with its own checksum, so if this was a totally automated process, it wouldn't work.

The other options include having the user sign/validate the checksum list, but that will increase the complexity of the process to the point that most OSes/distributions will not include such a tool. If the signature is performed by a key that is managed by the OS directly, once again, the root kit could automate this process as well.

On another note, the Windows Security model allows for different rights levels: guest, user, power user, admin, AND System. Administrators can elevate to system (there are tools with the appropriate API calls for this ... try psexec from SysInternals). And system is the rights context that is required for access to things like SAM password stores in the registry, etc. Administrators cannot just "navigate" or "browse" to these critical points with the standard toolsets.

I like the idea of using hardware to force read-only critical sections for high security systems, and for items like what F-Secure can offer for normal-security systems.

Here's your problem with that.

Let's just say that such a tool compares kernel modules and key system files to a list of approved modules' checksums. A rootkit could easily modify the list with its own checksum, so if this was a totally automated process, it wouldn't work.

The other options include having the user sign/validate the checksum list, but that will increase the complexity of the process to the point that most OSes/distributions will not include such a tool. If the signature is performed by a key that is managed by the OS directly, once again, the root kit could automate this process as well.

On another note, the Windows Security model allows for different rights levels: guest, user, power user, admin, AND System. Administrators can elevate to system (there are tools with the appropriate API calls for this ... try psexec from SysInternals). And system is the rights context that is required for access to things like SAM password stores in the registry, etc. Administrators cannot just "navigate" or "browse" to these critical points with the standard toolsets.

I like the idea of using hardware to force read-only critical sections for high security systems, and for items like what F-Secure can offer for normal-security systems.

how about RootkitRevealer from http://www.sysinternals.com/

rootkit revealer.

I've had to deal with a highly infested windows system a few times. There are a lot of ways to deal with it; my favorite is reformat and hand them Mepis (or another easy distro) but some people can't handle that. I had one system in particular I couldn't completely clean up, I had logged in safe mode and cleaned, but there was still something (with no services or processes I could see running) going on. So I grabbed this Rootkit Revealer and it found my problems. It was a cinch to log in under dos and get rid of the problems (although in retrospect I could have used Knoppix or another LiveCD.

So there are good Windows rootkit revealers, you just have to look for them.

http://www.sysinternals.com/Utilities/RootkitRevea ler.html

Strider Ghostbuster,, a Microsoft developed technique for detecting all persistant and stealthy rootkits .

Just convince Microsoft to make it available.

There is also SysInternal's Rootkit Revealer, which although not quite as general, is still hard to fool.

has a "revealer" and a great write up

Sysinternals RootkitRevealer

.. RootkitRevealer is your friend.

http://www.sysinternals.com/Utilities/BlueScreen.h tml

lsof and more at Mark Russinovich's Sysinternals:
http://www.sysinternals.com/utilities/handle.html

http://www.sysinternals.com/utilities/autoruns.htm l

Shows you everything that loads on startup, and all internet explorer extensions (BHO, etc.)

Invaluable when dealing with spyware.

HTH. HAND.

NT is a fairly unique Client/Server kernel design, meaning that it allows OSes to run on top of the NT kernel design (reducing traffic to the NT kernel)

...by not actually sending messages to the NT kernel for a lot of APIs. Instead, many Win32 APIs call user-land stub routines that trap directly to the kernel, with the kernel calling routines to handle those traps.

This is, of course, completely different from the way Linux and OS X work. In those OSes, many UNIX APIs are implemented as user-land stubs that trap directly to the kernel, with the kernel calling routines to handle those traps.

Application threads talk to the Subsystem kernel, which talks to the NT Kernel.

...except when they talk directly to the NT kernel.

Also things fails like Kernel Panic which both the different OSX BSD and Linux kernels technologies are prone to do.

Yes, but neither of those systems are prone to blue screen halts. (Well, I don't think Linux's panic screen is blue.)

(I.e., the terminology might be different in NT, but the concept exists. Statistics on how often particular Linux kernel releases, OS X releases, and NT (including NT 5.x) releases die in the kernel might be interesting.)

User identities are confirmed by using an Authentication Package. All of the packages that Windows includes require the user's password or smartcard interaction. It is documented how to write a new package; it is possible to create a package that would allow an administrator to act with the authority of any user. No one has done so AFAIK, and it doesn't look too simple.

An even easier way to impersonate a user on the local system is to manufacture a token: tokens are used to identify the authority behind a process. Anyone with TCB privilege (SYSTEM by default) can directly manufacture a token using NtCreateToken that contains user and group identities of whomever you want. This only works on the local system, though.

This is another case of the underlying system being capable, but Microsoft dropping the ball at a later stage. I think the justification for not being able to impersonate other users is the same as for not being able to assign ownership of objects to other users, except to restore backups.

About processes you can't kill: see the latest Sysinternals blog entry. It's due to buggy drivers that don't cancel IRPs correctly: a process can't exit until all of its IO is canceled. As for deleting files, that's a property of the locking system. You can still rename the files, though. That's what SFU does.

Try Process Explorer from http://www.sysinternals.com/

The L got left off the URL. Sorry. Try again

It scans all files and registry entries at a high and low level then compares the two to see which files and registry entries were hidden to the high level scan.

You can get a great tool for detecting rootkits as well as a nice little explanation of them here.

More often than not these days, the real tough buggers have randomly generated process names. Here's how I clean a machine:

Tools required:

Process Explorer(procexp) from http://www.sysinternals.com/
autoruns.exe from the same, or hijackthis.exe from http://www.merijn.org/
Any good virus scanner(McAfee's Enterprise scanner is decent. Use a simple scanner if possible, not a scanner/firewall/spam filter/personal servant. It will be generally be faster and simpler.
Ad-Aware from http://www.lavasoft.de/
LSPFix from http://www.cexx.org/lspfix.htm/
Updated Stinger from McAfee http://vil.nai.com/vil/stinger/
Experience enough to know valid windows processes and files.

Have all of this on a USB drive or CD. Will probably fit on a 64mb drive, unless your virus package is bulky.

Boot to safe mode

Start Task Manager or Proc Explorer and kill anything that doesn't look good, or everything that you know isn't part of windows. You could go to Control Panels:Admin Tools:Services and stop all services first, this will narrow the field.

Run Stinger, just let it scan memory and running apps. Don't wait for it to do a full system scan.

Run Ad-Aware, do the same. Just trying to ditch bad things that are actually running.

If you've gotten this far in 15 minutes, the machine probably isn't in too bad of shape. Dump all temp files, c:\temp, c:\winnt(windows)\temp, c:\documents and settings\username\local settings\temp, c:\documents and settings\username\local settings\temporary internet items

Update virus definitions and do a full scan. Latest SuperDAT from McAfee or Definitions from Symantec or whoever you use, should also be put on the USB drive or CD.

So, virus scan didn't deal with it, or couldn't stop/remove it? This is where it gets tricky and completely manual. This is the point where most people give up, since you really need to know what should be where in Win2k/XP/2k3. I'm really not thinking of 95/98/Me, if those are hosed just wipe it clean and move to XP home for $99-199

Run HiJackthis and look for gremlins. This tool really requires an eye for what is supposed to be there, but pay special attention to startup objects and BHOs(Browser Helper Objects aka evil Internet Explorer plugins)

Add/Remove programs. Go through it with the client. Anything they don't recognize, or know they don't need, ditch. This can be risky, since people forget, but compared to a reinstall . . .

Now for the real manual part . . .

Run lspfix and check for foreign entries. There are normally 2-4 LSP's present. I usually only do this if there are persistent network failures.

Check Hosts file at c:\winnt(windows)\system32\drivers\etc\hosts There really should only be one entry in here, for 127.0.0.1 localhost. You may have already checked this with hijackthis

Browse to c:\winnt(windows). Sort by date. On a default install, the file modify dates are going to be a long time ago. If you see anything from within the last few months, get suspicious. Ignore log/text files, but don't ignore those without an extension. Do the same for c:\winnt(windows)\system32 This can be a bit trickier, there are way more files in system32 than winnt(windows), but the same rule generally applies. Anything from the last 3-6 months is suspicious.

Do the same for c:\program files Delete any empty folders that your previous uninstall didn't remove. You should have an idea what is supposed to be here, after doing Add/Remove programs, so hack and slash the folders that you don't think belong.

In one of these deleting sprees you are sure to find something bad that won't let itself be deleted, usually a .dll that is registered and can't be removed. Never fear! Write down the .d

I can map my keyboard, with xmodmap on linux, but it is hard to do that on a per user basis on a windows box

Solution A: http://www.sysinternals.com/Utilities/Ctrl2Cap.htm l

Solution B: http://www.winstuff.de/show_registry.html?sid=50

pskill from www.sysinternals.com will provide you with process killing goodness.

I figure, you'd want to replace something like WINLOGON.EXE, or whatever the closest equivalent of init there is on Windows. I'm sure there are people here who are a lot more knowledgable about how WinNT starts.

I suspect you'd have to replace either CSRSS.EXE or SMSS.EXE, and the app you replace it with would have to be a native application, so it couldn't be CMD.EXE which is a win32 console subsystem application. More info on sysinternals, here and here.

Note that I/O will be your primary difficulty -- the only API available to you was designed for output only during the blue screen phase of Windows NT's boot process, and for display BSODs. You will probably have to install a device driver that enables access to a text console and use that for IO.

This can be done, as both Windows Setup and the Recovery Console seem to use this approach.

I figure, you'd want to replace something like WINLOGON.EXE, or whatever the closest equivalent of init there is on Windows. I'm sure there are people here who are a lot more knowledgable about how WinNT starts.

I suspect you'd have to replace either CSRSS.EXE or SMSS.EXE, and the app you replace it with would have to be a native application, so it couldn't be CMD.EXE which is a win32 console subsystem application. More info on sysinternals, here and here.

Note that I/O will be your primary difficulty -- the only API available to you was designed for output only during the blue screen phase of Windows NT's boot process, and for display BSODs. You will probably have to install a device driver that enables access to a text console and use that for IO.

This can be done, as both Windows Setup and the Recovery Console seem to use this approach.

autoruns is invaluable to cleaning the crap that programs install and have set to run when you login/boot.

Group policy *YAWN*
Please wait while your sysadmin applys every bloated
hack he can think of...

However as a local admin you can Nerf most group policies.
http://www.sysinternals.com/

A mere 5 clicks on "End Process" and you actually get something shut down ? You lucky, lucky bastard.

Whenever I try to terminate a process using Windows own inbuilt tools it either takes a godzillion attempts or it tells me "You can't shut that down, it's a system process" (Yes, I know. I'm trying to remove a f****ing virus from my friends daughters machine which is running with system privileges...)

Thankfully Sysinternals excellent Process Explorer lets me view and kill any running process whatsoever. And when you say kill, it kills ! (Mind you at this point I often discover it really was a system process and Windows crashes)

Still it's the only way to get rid of some of the more persistent nasties you get on a Winders box so it's well worth the trouble.

Go to http://www.sysinternals.com/ and click on Process Explorer.
This is a replacement for Windows Task Manager. To replace it, just select Options->replace Task Manager.
Now the goodie here is that when you select a process in process explorer and click delete, it _instantly_ removes the process!

Oh and here is another tip for you:
You don't have to press ctrl-alt-delete to get access to the task manaager.
Simply press ctrl-shift-escape and it will pop up.

The task manager has to be somewhat end-user focused, and tries to be smart about not letting you kill things the typical user probably doesn't want to actually kill ("my compute is slow, i'll start killing random processes until it speeds up!")

If you want more "just kill it already", and want to stay in a GUI (since kill/taskkill/etc exist), I'd recommend Process Explorer, where most of those checks that try to help out the typical user aren't done.

http://www.sysinternals.com/Utilities/ProcessExplo rer.html

• Standard PS2 stuff (COM, LPT, game port, floppy)
• Standard IDE controller and ATAPI devices
• OHCI, UHCI, EHCI USB hubs
• Lots of USB HID stuff
• Standard 1394
• ACPI, PCI, DMA, standard busses and bridges
• A standard processor driver
• External modems
• Filesystems (these are a pain to write anyways)

• SCSI controllers
• 'Hardware' RAID controllers
• Video *
• Sound (although the SB16/AWE32 compat drivers are MS)
• Smart cards
• Video decoders/encoders
• Network cards
• Specialized USB devices
• AGP busses

• My Winbond SD/MMC card reader

netstat -lp --inet --numeric-ports

Actually, it would be more along the lines of "lsof -i -n"

Just knowing the ports won't tell you which process is responsible for them.

I'm sure there's a Windows equivalent if you use that

Sysinternals has some very nifty freewares that give this info and more.

Still, I'd rather keep the firewall. I like granularity. What if I want to limit access to certain source ips? Limiting them on application level might still leave open to buffer overrun kind of vulnerabilites.

if you have no anti-virus software installed, how can you say with any authority (or confidence, for that matter) that your system isn't completely compromised, and you're simply unaware of it?

simple. it's not running in my tasklist. nor is functionality lost. I know what's in my registry to start normally, and I can check to see if something additional is there. my homepage doesnt automatically set and change itself. there are no random items in my systray. i don't get random pop-ups when not using the computer.

Identifies all startups (including the more hidden ones). It even identifies IE plugins. Definitely in a class of it's own.

Sysinternals' Autoruns is my choice of weapon.

Actually, the NT kernel can run just fine without the Windows GUI - look at the Recovery Console or the code that runs when you Install, or the chkdsk that runs if you don't dismount the disks cleanly.

You can even write Native application for the NT kernel, to do things like backups and so on.

http://www.sysinternals.com/Information/NativeAppl ications.html

In fact in NT before 4.0, all the Win32 stuff was run in _user_ mode, in the CSRSS native application, even graphics drivers. Even now, things like the start menu are in a user process, explorer.exe. You can replace it with whatever you want.

All this is someone moot admittedly, given that 99.999% of Windows applications are Win32 and need CSRSS running, but the architectural distinction between a kernel and a user interface is still very much present.

"Running windows without admin rights is a nightmare."

It certainly isn't easy, unless you're willing to invest significant technical time and effort into the project -- which is, I'm sure, a big part of the reason why most people don't do it.

That being said, I'm the admin for an organization with about 60 or so Windoze stations, and I can say that it can be done for most things. It most often involves figuring out what the defective program is trying to do, and then allowing it access to just where it needs.

The two most vital tools are FileMon and RegMon, both free from SysInternals (http://www.sysinternals.com/). They monitor file system or registry accesses. In the vast majority of programs can be made to work just by applying some ACLs on program-specific registry or filesystem branches.

There's no way in hell your "typical home user" could do this, though, which is, I expect, the problem and point.