Almost all shellcode I see in malicious documents (PDF, Word, Powerpoint, …) found “in the wild” does the following:
- download a trojan from the Internet using HTTP
- write the downloaded executable to SYSTEM32
- execute the downloaded executable
This infection method only works if the user is local admin. If the exploited program has no rights to write to SYSTEM32, the shellcode will just fail and the trojan will not infect the machine.
To protect yourself and/or your users against this type of attack (I’m not talking about targeted attacks), restrict the user rights. Windows Vista and later versions do this for you with UAC, even if you’re an administrator.
On Windows XP, you have to use a normal user account in stead of an admin account to achieve this. But running non-admin on Windows XP is not always easy. If you really need to allow admin rights on Windows XP, you can still prevent high-risk applications (like Adobe Acrobat and Microsoft Office) from having full control over the system by restricting their rights. This is done by using a restricted token for the processes of these applications.
There are 2 popular tools to launch programs with a restricted token:
- DropMyRights by Michael Howard
- StripMyRights by Kåre Smith
Both tools create a restricted token (by removing privileges and denying groups that provide local admin rights) and then launch the target program with this restricted token.
It’s not always easy to launch a program with DropMyRights, as there are many ways a program can be launched on Windows. For example with a file-type association or from a browser. To help you configure Windows to always restrict the rights of a specific program, StripMyRights also support the “Image File Execution Options” method with the /D option. The “Image File Execution Options” is designed to allow you to launch a program automatically inside a debugger. In the “Image File Execution Options” registry key, you specify the debugger to use. But this can really be any executable.
Example: to restrict the rights of Adobe Reader, add StripMyRights to the AcroRd32.exe Image Execution path like this:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\acrord32.exe] "Debugger"="StripMyRights.exe /D /L N"
This way, each time AcroRd32.exe is executed, StripMyRights executes first, creates a restricted token and then launches AcroRd32.exe with this restricted token.
But executing StripMyRights before executing the target application doesn’t always yield satisfactory results, sometimes it breaks the application, because of the broken process tree.
That’s why I developed an alternative, LowerMyRights.dll, to be presented in an upcoming blogpost.
Didier Stevens 
Hello Didier,
Sandboxes are also great tools to restrict suspicious (or sensible) softwares into a restricted area. (http://blog.rootshell.be/2008/07/04/lets-play-in-sandboxes/)
Files created on the file system (like /system32) are instead created inside the sandox. This could be helpful to track actions performed by a malicious piece of code!
Comment by Xavier Mertens — Sunday 27 September 2009 @ 13:49
[…] Preventing Malicious Documents from Compromising Windows Machines « Didier Stevens […]
Pingback by TwittLink - Your headlines on Twitter — Sunday 27 September 2009 @ 15:02
Hi Xavier.
Yes, sandboxes are great tools too, I remember your blogpost. I use Sandboxie myself.
The advantage of DropMyRights and StripMyRights is that they are easy to deploy. You could use an AD GPO to deploy them in case of an emergency, for example a new vulnerability is being massively exploited and you can’t update the vulnerable program immediately.
Comment by Didier Stevens — Sunday 27 September 2009 @ 17:06
y’know, i’ve never really had much difficulty running as a non-admin on my XP box. i only ever run as an admin when i’m applying updates (no more than once a week if that) or need to install something new (which i try my best to keep to a minimum – to the point of opting for portable apps instead).
that said, i also use sandboxie, not just for browsing and email but for reading documents from the outside world as well.
and i use application whitelisting which, if i’m not mistaken, would likely stop the 3rd step of the system compromise you describe (unless further exotic execution is used).
Comment by kurt wismer — Monday 28 September 2009 @ 17:37
[…] under: My Software, Quickpost — Didier Stevens @ 17:50 I wasn’t going to mention SAFER to restrict the rights of an application, because Software Restriction Policies can be bypassed. But a Tweet by Edi Strosar made me review […]
Pingback by Quickpost: SAFER and Malicious Documents « Didier Stevens — Monday 28 September 2009 @ 17:52
@kurt wismer
Neither do I had real issues running as a non-admin on XP. Except when developing COM and ActiveX components with VS6.
Comment by Didier Stevens — Monday 28 September 2009 @ 18:03
Thanks for sharing this important information. This article is very useful and can help anyone who wants to protect his/her PC from malicious documents and viruses.
Comment by Machine Manufacturing — Tuesday 29 September 2009 @ 10:50
Hello,
No comment
start taskkill /IM explorer.exe /F
c:\DropMyRights\DropMyRights.exe “c:\windows\explorer.exe ”
not so bad !
Comment by krazykatfelix — Sunday 4 October 2009 @ 9:09
@krazykatfelix
Thanks! To restrict the rights of explorer.exe and all the programs it starts, it’s even better to create an Image File Execution Options for explorer.exe This way, explorer.exe will never start with full rights.
Comment by Didier Stevens — Sunday 4 October 2009 @ 10:27
[…] Software, PDF, Vulnerabilities, bpmtk — Didier Stevens @ 0:00 Another very effective way to prevent malicious documents from infecting PCs, is to prevent vulnerable applications from starting other applications. As almost all shellcode […]
Pingback by Preventing Applications From Starting (Malicious) Applications « Didier Stevens — Monday 5 October 2009 @ 0:02
I used to use http://sudown.sourceforge.net on my shared machine at home, but I had hard time when installing most of the programs. In the end I lost track of which users installed this program and that programs.
Comment by Michael Lim — Wednesday 28 October 2009 @ 10:33
“That’s why I developed an alternative, LowerMyRights.dll, to be presented in an upcoming blogpost.”
Any update on this, Didier?
Comment by Drewfus — Wednesday 5 May 2010 @ 0:03
@Drewfus Will be posted this month.
Comment by Didier Stevens — Wednesday 5 May 2010 @ 10:43
I am also very interested in LowerMyRights.dll, is there any progress on it?
Thanks!
Comment by dlimanov — Sunday 13 June 2010 @ 19:24
@dlimanov I like to have this type of software running on my systems for a couple of months before I release it. Hope to post it this month.
Comment by Didier Stevens — Sunday 20 June 2010 @ 18:49