Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Quick, Unplug The Router!

Further Down The Spiral — Mon, 17 Jan 2005 23:28:00 GMT

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

smidgeonsoft — Wed, 19 Jan 2005 20:21:00 GMT

Thank you very much for these posts! Very educational and entertaining! It is information like this that lends credence to Microsoft's commitment to security. I look forward to further installments.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Chris Quirke — Fri, 21 Jan 2005 12:20:00 GMT

Sobering stuff. I work with home PCs that are hopefully not exposed to this detailed attack, and one thing I do is kill admin shares such as c$. I also disable "automatically restart on errors", so halting instead of rebooting on a STOP error gives a chance to see what's up.

IMO the OS should never restart on errors if they occur during OS boot (or if you like, a Safe Mode OS boot). There's no point in endlessly rebooting an unattended PC that never reaches a point it can be remotely admin'd; you just shred the file system.

In today's world of mainly stand-alone malware, it's easy to forget intrafile infectors exist <g>

Finally, I notice some common drive-by malware drop a non-malware IDE driver, but what I've read doesn't explain why. It could be to uniquely id the HD (more useful than the session IP) but I'd worry about raw disk access, below NTFS's abstraction layer.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Nektar — Sun, 23 Jan 2005 03:05:00 GMT

What I do not understand is if the system is compromised and so might likely provide false information to a security researcher, how come your wolf analysis program be able to gather all these info and be able to trust it.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Nektar — Sun, 23 Jan 2005 12:46:00 GMT

I believe that Micosoft should provide security guide in the spirit of this weblog instead of their current hardening guides which are very beginner like.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Robert Hensing — Sun, 23 Jan 2005 19:55:00 GMT

In response to Nektars comment about being able to trust data captured from a possibly rootkit'd machine. This is a very real and very valid concern. We spend a lot of time researching rootkits and collecting them off of customers systems. We feel we have a very strong knowledge in this area and our IR toolkit has tools to be able to detect the presence of all known rootkits (and probably even ones we don't know about). In the event that our rootkit tools come back 'clean' and we still can't detect the presence of a rootkit but feel that one must be there - we request an image of the system and we restore that image in a lab and we do our analysis there.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Robert Hensing — Sun, 23 Jan 2005 19:58:00 GMT

And in response to Nektars later comment about security guidance being in blog form vs. guide form - actually we feel exactly the opposite. Our ONLY concern with blogs right now is that they may 'dilute' our security guidance. If it's worthy of being blogged about and its stuff that customers need to know - our thinking is that it should be in a security best practices document / guide vs. in a blog, this way all customers have equal access to it.

OdeToCode Links For Jan 23

OdeToCode Links — Mon, 24 Jan 2005 07:20:00 GMT

Microsoft WOLF

Server: Microsoft-IIS/6.0\r\n — Thu, 27 Jan 2005 05:14:00 GMT

A day in the life of a incident response expert

Security Briefs — Fri, 28 Jan 2005 05:15:00 GMT

Advanced hiding techniques and Incident Response Team

Sergey Simakov blog — Fri, 28 Jan 2005 10:17:00 GMT

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

AT — Mon, 07 Feb 2005 23:53:00 GMT

No needs to be able contact MS Product groups to find out that WFP is not a security measure.

I've discussed this about 2 years ago with Secure@microsoft team.

http://www.24.odessa.ua/neowin/secure.txt
"This implies WFP can be circumvented or cancelled; it should not be presumed a replacement for having properly restricted user roles and a locked down system. So your assertion that WFP is sesigned to keep the system stable is correct - it is not designed as a security feature."

Unfortunately - some of my security ideas I've discussed with Microsoft - still not implemented :-(

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Lee S — Tue, 08 Feb 2005 09:44:00 GMT

NOt sure how you fixed this for sure, but we had a similar problem today... Symantec found the dlls noted, but no fix. Tech had tried removing the dll and/or renaming and then it blue screened and couldn't get back. Ended up restoring (which wouldn't have had to do) and getting a fresh infected system. Files were dropped 12/19/2004. Booted in safe mode, deleted or renamed the dlls, deleted gifs noted, and copied winlogon.exe from the dllcache folder over. Found a user that had been created by someone else in admins group, removed this and we were in business. Thanks for the interesting reading.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Robert Hensing — Tue, 08 Feb 2005 17:09:00 GMT

Sorry I guess I should have called that out in the blog. Since winlogon.exe has been modified on disk to recover the system you need to boot to the recovery console and copy a good copy back to system32 (i.e. from the dllcache or from the latest hotfix uninstall directory). You may even be able to rename winlogon.exe while the system is booted to something like winlogon.bad and then copy the one from the latest security update back to system32

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Martin — Sat, 12 Feb 2005 17:18:00 GMT

We just had a similar problem but we solved it in a different way. One of our W2K Servers was behaving "strange" but there were absolutely NO visible problems. All known virus scanners found NO problems. But there was one, we felt it.
The solution was tricky :
We just dig a defrag on the server. In the report the server said : ...was unable to defrag the following files... -> There was a listing of non visible files. Their location was in %SYSROOT%\SYSTEM32\drivers\etc\fonts{00 08...}\

Impossible to browse, impossible to delete. There where also some services, not showing up in the service list, only visible via msinfo32.

None of the services was visible with regedit.

The only way to stop them was to rename them with another server (visible) and restart the infected one. Then it was also possible to delete the files via the command line (looked like a complete operating system with storage in RECYCLER.BIN).

We deleted the invisible services with another server (network registry). The name of the services : Atarpisrv (calls ATA122.exe)
PowersupplyManager
r_server

Thank you for your interesting article. Best regards from Martin

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Robert Hensing — Sat, 12 Feb 2005 23:55:00 GMT

You did some pretty good detective work - it sounds like you had a rootkit on your box that was hiding the services. Most if not all current rootkits can usually be spotted by connecting up to the affected machine from a 'known good' machine across the network and examining either the file system, the registry or both. The rootkits usually only hide stuff locally - they haven't bothered hooking the redirector yet.

This is precisely the kind of stuff my team deals with every day - if you ever want help or a second opinion in the future don't hesitate to give us a call.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Martin — Sun, 13 Feb 2005 14:33:00 GMT

Hello Robert,
the only thing i'm wondering about is : We once (1 year ago) had some weak passwords but we cleared this problem. Since then we have no weak passwords.

How do the intruders get into the machine with no weak passwords ?

Best regards from Martin

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Robert Hensing — Sun, 13 Feb 2005 19:42:00 GMT

Intruders get into your machines by using the philosophy of the "3 p's".
Passwords
Patches
Ports

If you have exposed ports (i.e. no firewall, weak router ACL's etc.) then they will compromise your machine remotely using either weak passwords or missing patches.

You say you fixed your weak password problem; but everyones definition of 'strong' varies. Is 'Password;1' strong? technically it meets length and complexity requirements at 99% of IT shops in the world - but it's one of the weakest / lamest passwords ever - don't ever use that!

So I guess what I'm saying is - if you changed all your admin passowrds and made them 'stronger' and you are still getting hacked remotely then you have a problme with:
1. Ports - check your firewall rules
2. Passwords - provide an example of a 'strong' password you have used in the past
3. Patches - what's your security patch policy like? How long does it take to deploy all critical security patches for your OS and applications?

Finally - it is possible that when the attackers had access previously they installed a backdoor hidden by a rootkit which you now cannot see - this backdoor server would run as SYSTEM and probably allow them to connect up remotely, anonymously, without using an NT password - thus it wouldn't matter what you changed your admin passwords too - if they've installed a backdoor server process on your windows box you can change passwords till your blue in the face and they will still have access.

You should have someone come in and verify the security of your servers (my team for example could perform a security check of the box that was previously hacked to see if we can find any evidence of persistent malware). Keep in mind that no incident response analysis will ever be 100% guaranteed - if your box was hacked and you have evidence that the attackers have continued to gain access you should immediately flatten the box and rebuild it securely.

How do you rebuild securely?
1. You buy Windows Server 2003 (more on why i a second).
2. You un-plug the network cable from the machine
3. You install the OS by booting from the CD.
4. During setup you either leave the local admin password blank (preventing the use of this account for network authN) or you create a really strong 30 character or more pass-phrase on the account.
5. after setup completes and you reboot - you login as the admin and you immediately enable the firewall on all adapters.
6. You then plug the network cable in, configure your Internet access settings and hit Windows Update.
7. You let WU fully update the box and reboot as needed.
8. You then consider locking down the security even further using security templates from our Windows 2003 security guidance based on the role of the sever.

In the near future we will be releasing Win2k3 SP1 which I would recommend slip-streaming into a build of Win2k3 you host on a network share. This way you can install Win2k3 over the network using something like RIS or a network boot disk and you can have a Win2k3 SP1 box during setup - this will greatly improve your security as well.

If you can do all of that - your machine won't get hacked during or shortly after setup. If you build a Windows 2000 machine and leave the cable plugged in to your internet presence I can't guarantee it won't get exploited during hte latter half of setup (after the network stack initializes) or after you reboot for the first time. Win2k has no built-in firewall and doesn't make you think about good admin passwords during setup.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Martin — Mon, 14 Feb 2005 11:54:00 GMT

Hello Robert,
i did some further investigation on this topic, here's the result (strange but true) :

On Jan 8th at 2.16am we had an AUTOMATIC update with a MS Servicepack (KB 870763 WINS). Strange because we have disabled automatic updates on all machines.

Then we found serveral files that where copied to the machine with the same timestamp : 2.16am, including ftp.exe tftp.exe aso. Also the "Computer" that was hidden behind the %SYSVOL%\SYSTEM32\etc\fonts.{00 08..} was created at that time. We made some copies of the .ini files of the proud intruders.

Can you tell me how it is possible to start an automatic update without any user interaction and the automatic update service disabled ?

I think the problem is might be bigger than we think...

Regards from Martin from the snowy Austrian mountians.

re: Advanced hiding techniques: The mystery of the trojaned Winlogon.exe

Robert Hensing — Mon, 14 Feb 2005 16:40:00 GMT

Why do you think it was automatic updates that updated your machine? It most assuredly was NOT automatic updates - it was a miscreant patching your machine to close the hole they used to exploit it. It is very common for the miscreants to patch and then harden your machine once they get on it to prevent 're-hacking' or 'leech hacking' as they like to call it by other crews.

You were more than likely exploited by the WINS vulnerability on this server becuase you didn't have the patch installed - there has been public WINS exploit code available since shortly after we released the bulletin. This is why it's so critical that organizations perfect their patch management policies and adopt the ability to deploy all critical patches within 24 hours.

If you think it was automatic updates that installed the patch becuase the account that did the installing was SYSTEM that's a red herring. While the automatic updates service does run as SYSTEM by default, so does WINS and that's the service that was most likely exploited here.

In the future when you find something is strange on your machine, please don't hesitate to give us a call. :)

Tools of the miscreant trade: Execute a .GIF like a .EXE

Chris' Comments — Wed, 16 Feb 2005 06:34:00 GMT

Tools of the miscreant trade: Execute a .GIF like a .EXE

Chris' Comments — Wed, 16 Feb 2005 06:37:00 GMT

Advanced hiding techniques and Incident Response Team

Sergey Simakov blog — Thu, 24 Feb 2005 10:10:00 GMT

re: New weapon in the war - F-Secure reveals Blacklight - an anti-rootkit tool - try it today (remember to rename it

Robert Hensing's Incident Response WebLog — Sun, 13 Mar 2005 17:35:00 GMT

IIS 5 services won't start at Win 2000 | keyongtech

IIS 5 services won't start at Win 2000 | keyongtech — Thu, 22 Jan 2009 10:41:10 GMT

PingBack from http://www.keyongtech.com/4362460-iis-5-services-wont-start