A bit more on moving to SYSTEM...

Last time, I covered using the Scheduler service to run a disk image in the context of SYSTEM. As I don't have a lot of interest in writing the remaing posts on the subject, I'll cover the topics here - maybe I'll get back to them.

First, I received a comment on my last post, which I responded to:
http://dariengap.blogspot.com/2006/06/admin-to-system-scheduler-service.html#comments

Thank you, j.j., for your unsolicited but welcomed input.

Some of the other means of running as SYSTEM are as follows:

• The documented CreateService(); create a service which, by default, will run in the context of SYSTEM.
• Assert the SeDebugPrivilege, then use some combination of VirtualAlloc() and CreateRemoteThread() or their native counterparts. When using this technique, the function pointer passed to CreateRemoteThread() can be your own copied code, or a Win32 (or third-party) function (such as LoadLibrary()). I believe this last was originally published by Jeffrey Richter.
• Use the SeTakeOwnership or SeRestore privileges to modify the DACL on a process object (optiona; the SeDebugPrivilege can be used instead) and the primary access token object for that process. A handle to this token can then be used with ImpersonateLoggedOnUser or CreateProcessAsUser. In the latter case, remember to use DuplicateToken - if you forgot, the very helpful return code will let you know what happened. Also, you can use the native API to set the process token on an already running process.
• Assert the SeDebugPrivilege and open lsass.exe and enumerate the handles to token objects in this process using Nt/ZwQuerySystemInformation. In my experience, there are two or more handles to tokens for SYSTEM that have DACLs that allow BUILTIN\Administrators to use without modifying security.

That is it for now...