Some times ago we stumbled across the following Joe Sandbox analysis report:
Some striking facts:
- New Password.exe is dropping a PE file to C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\72.tmp
- New Password.exe is creating a copy of the previously dropped file to C:\WINDOWS\system32\hyli.igo
- New Password.exe modifies Microsoft Word security settings: HKEY_USERS\Software\Microsoft\Office\11.0\Word\Security, Level, AccessVBOM
- Winword.exe is is launched silently, parent process is unknown
- Winword.exe loads 72.tmp
- Winword.exe sets an autostart registry key to hyli.igo: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, Shell, Explorer.exe rundll32.exe hyli.igo atkhnt
- Windword.exe starts svchost.exe and queues an APC
- Svchost.exe loads 72.tmp
One of the most interesting parts of the persistence procedure is actually the malicious code injection into winword.exe. As described winword.exe is not started by New Password.exe und 72.tmp is not injected into winword.exe by a known injection technique (e.g. such as WriteProcessMemory, CreateRemoteThread). Thus New Password.exe must have used an alternative way to start and inject it's code into a trusted process.
The shed light into the injection technique we checked a couple of things:
- Who is the parent process of winword.exe?
- What is the meaning of the windows registry keys Level, AccessVBOM in Office\11.0\Word\Security
It turns out that the parent process of winword.exe is svchost.exe which covers among others the DCOM Server Process Launcher service and not New password.exe:
If the registry key AccessVBOM is set to 1 Microsoft Word allows macro code full access to the Visual Basic Object Model. If Level is to 1 Word enables the untrusted executing of macro code.
Thus we got the suspicion that New Password.exe has injected remotely a macro into Winword.exe. To validate it we have checked a couple of things:
- Macro code injection would be done with the help of Windows COM
- The Prog ID to controller the Microsoft Word App via COM would be "Word.Application"
- The string "Word.Application" as well as the CLSID would be somewhere in the memory of New Password.exe
- COM helpers are implemented in ole32.dll and oleaut32.dll, thus New Password.exe should have loaded it
The suspicion seems to be true:
As a next step we searched in the static disassembly (a part of Joe Sandbox 7.0.0) and found the following interesting parts:
According to the disassembly the code is creating a new Word.Application object. As an effect the DCOM Process Launcher service is creating winword.exe.
Next the code fetches the Document->VBProject property. With the help of VBProject.VBComponents it is adding and executing the function qvkosy (Declare Function qvkosy Lib "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\72.tmp" (By Val s As String) As Long) which loads effectively 72.tmp . This all happens hidden from the New password.exe process.
The trick of injecting / loading a macro remotely with the help of COM is very stealthy and we have not seen any analysis of that technique. However code to create and execute remotely visual basic code in Office applications is known for years (http://forums.codeguru.com/showthread.php?249705-Excel-Automation&p=754023
Controlling and validating COM behavior is hard because all calls are actually dynamic (via the IDispatch interface) and identified by DISPIDs (checkout the following code for enumerating DISPIDs for a particular object: http://www.joesecurity.org/resources/enumdispids.cpp
). As a result understanding this technique is helpful to improve protecting mechanism in protection systems such as HIPS.
Finally the technique works successfully on Vista and W7 even if the New process.exe does not increase its privileges through UAC. It seems that all sub processes of DCOM Process Launcher Service have permissions to write to C:\WINDOWS\system32\ as well to modify HKLM keys.