Microsoft SysInternals is Prone to False Negatives When Testing for Escalation of Privileges

[steven36]

If we didn’t already get the memo in 2014, the Sony hack serves as a harsh reminder of how easy it is for attackers to hide undetected, inside a network for long periods of time. While security vendors continue to deliver more and better automation for incident response, all tools – even the best ones – have limits. And sometimes the most trusted tools have flaws. This post outlines several circumstances in which we found in a popular suite of free forensics tools delivers a false negative for a basic indicator of Compromise (IoC) - escalation of privileges.

We found this issue when a customer asked us to benchmark our detection capabilities against Microsoft SysInternals, suite of network troubleshooting and monitoring tools that are incredibly useful – and free. While SysInternals was not designed for security forensics, it is commonly used by digital forensics and incident response teams as a cheap and easy to use approach for incident investigation and forensics in Windows systems.

In the course of our testing, we found that SysInternals fails to detect one one of the most common attacker behaviors - privilege escalation, a commonly used technique by hackers believed to be used in the Home Depot breach.

Given their popularity as breach forensics tools and what a common and fundamental Indictor of Compromise (IoC) privilege escalation is, we believe it is important to be aware that SysInternals is prone to false negatives. Knowing how popular these tools are, we understand people will still use them, but we have published a full report, with detailed screenshots at http://is.gd/qN9Sw2, in hopes that organizations that use SysInternals for security forensics will read this and do additional tests to check for privilege escalation.

We ran two different tests in which we took common enterprise scenarios, and used some exploits to simulate escalated privileges. We then outline how the SysInternal suit tools - : Sysinternals Process Monitor (procmon), Sysinternals Process Explorer (procexplor) and the lately launched Sysinternals System Monitor( sysmon) misses them, and what they should reveal.

Test 1

Setup

A fully patched (before KB3000869 patch was released) windows 7, 32bit computer running a malicious file (evil.exe - a metasploit generated meterpreter executable) as a user with local user privileges.

The Exploit

We leveraged a recently released Metasploit module for MS14-58, a month-old win32k.sys kernel exploit, to launch a notepad.exe and elevate it to nt authority\system token. Into that process, a new meterpreter listener was injected and communicated back to our attacking machine.

Investigation Results:

Proper tracking of the performed attack would require the monitoring tool to correctly display the process hierarchy and ownership (i.e. as “SYSTEM”). Below is the description of investigation results of common Microsoft tools.

1. Sysinternals’ Process Monitor (procmon) incorrectly displayed “user” as the notepad.exe process owner

Author’s Note: Windows Task Manager did not display the process ownership correctly. Instead of “SYSTEM” it displayed a blank as the user name for the malicious notepad.exe process.

Important Finding: When using procmon’s Log Capturing feature in this test scenario, procmon captured the incorrect ownership (i.e. “user”). When loading the captured log for later analysis, there was no evidence to the privileges escalation. This proves procmon Log Capturing to be inappropriate for retrospective investigation of suspected privilege escalation.

2. Sysinternals’ System Monitor (sysmon)- Created an entry in the event logger and incorrectly displayed “user” as the notepad.exe process owner

Test 2

Setup

After we were satisfied with the results in the first case, we have tried to execute another attack, this time from a different attack vector: the browser.

The victim computer was a 32bit Windows 7 running IE, surfing to 'evil' server.

The Exploit

We used Metasploit to run a malicious webserver that serves a page with the CVE-2014-6332 exploit. The exploit (eventually) causes iexplore to run a powershell process, which later runs another powershell process with a long command line (see image 7) - embedded in the command line is the payload itself (meterpreter), gzipped and base64 encoded. The exploitation process uses the .NET infrastructure in powershell to ungzip and de-base64 the payload.

The second powershell process terminates the first one and thus breaks the “parental relationship” between them (as can later be seen in the screenshots). After getting a user-privileged meterpreter prompt, we have used the same exploit from the previous test case (MS14-58) to elevate our privileges into “SYSTEM”.

Investigation Results:

1. Process Monitor correctly displayed the hierarchy but incorrectly displayed ”user” as running the malicious notepad.exe instead of “SYSTEM".

2. Process Explorer incorrectly displayed notepad.exe as running by “user” instead of “SYSTEM”. Process explorer does not show the full hierarchy and it is impossible to identify that the rogue powershell.exe process was executed by iexplore.exe. Process explorer was designed to monitor and display running process in real time, thus, it lacks the ability to correctly present process hierarchy in cases when a child process terminates the parent process. Restarting procmon will display the correct ownership of the process. However, restarting procmon is not an expected behavior of the investigator when using procmon.

3. System Monitor incorrectly displayed theprocess owner as “user”

Conclusion

Privilege escalation is a critical and commonly used technique that can result in a complete takeover the victim’s machine. It is important for Incident Investigation and SOC teams to check for it – period.

Few security teams have the financial and human resources at their disposal to do their jobs they way they should, making free tools such as SysInternals a godsend to the community. Knowing that SysInternals is prone to false negatives, FIND ANOTHER WAY TO TEST FOR IT.

Good security forensics requires good security hygiene, and no tool is perfect. Make sure the team and not the tools drive the process and double check your work.

Source