In early December, Kaspersky Lab experts detected samples of the malicious program TDL4 (a new modification of TDSS) which uses a 0-day vulnerability for privilege escalation under Windows 7/2008 x86/x64 (Windows Task Scheduler Privilege Escalation, CVE: 2010-3888). The use of this vulnerability was originally detected when analyzing Stuxnet.
Using an exploit for this vulnerability allows the rootkit TDL4 to install itself on the system without any notification from the UAC security tools. UAC is enabled by default in all the latest versions of Windows.
After the Trojan launches in the system, e.g. in Windows 7, its process receives the filtered token (UAC in operation) with the regular user privileges. An attempt to inject into the print spooler process terminates with an error (ERROR_ACCESS_DENIED).Error occurs when TDL4 attempts to intrude into print spooler process.
Earlier modifications of this malicious program also try to penetrate the print spooler process. New modifications, however, attempt to use the 0-day exploit to escalate its privileges up to LocalSystem level.
Interestingly, the rootkit’s installer has a dedicated code allowing it to bypass some proactive protection tools. Some proactive protection tools hook the function NtConnectPort in SSDT to prevent TDL4 from injecting into spoolsv; if the port name is "\RPC Control\spoolss", they return a notification stating that there was an attempt to penetrate the print spooler process. The creators of TDL4 came up with a simple “solution” to this problem: they hook ntdll.ZwConnectPort in the TDL4 process and check the value of the parameter ServerPortName sent to the function (a UNICODE string); if it is "\RPC Control\spoolss", they replace it with an analogous one containing a symbolic link to the root directory of the object manager namespace.
TDSS has once again reaffirmed its status as one of the most complex and dangerous malicious programs there is.
PS. A huge ‘thank you’ to Vasily Berdnikov (Vaber) for helping prepare the material for this blog.
2010 Dec 20, 18:53
Re: the same or different?
We were writing about same exploit http://www.microsoft.com/technet/security/bulletin/ms10-092.mspx I'm sure because I'm in "Acknowledgments" list)