The return of the spoof part 1: Parent process ID spoofing

Years ago (as early as 2009), my colleague Didier Stevens wrote a blog post about parent process ID spoofing. Back then, most companies were not as secure as they are now, therefore, most attackers got away with ‘basic’ exploitation, not having the need to do much obfuscation or deception.

Thankfully, the security posture of the majority of companies has drastically improved, rightfully so of course, as numerous cyber attacks have made the news in the last couple of years. Think of WannaCry, (Not)Petya and pretty recently, the Citrix vulnerability.

As security gets better and better, attackers need to find new and more creative ways of attacking an environment. At the end of 2018, Will Burgess gave a talk called “Red Teaming in the EDR age”. In this talk, Will proceeds to describe how more and more companies have EDR solutions in their environment and Will describes how attackers are approaching their kill chain to factor in these EDR solutions. A part of this new approach is deception, which is what this blog post will cover. We will take a look at two deception techniques, none of which are completely new. The first one, parent process ID spoofing, is described in this post, while the second one will be described in part 2.

As a red teamer, I feel like these techniques are not well known enough yet. Hence these 2 blog posts. I’m also pleased to announce that these techniques will be added to the SANS SEC699 course: Purple Team Tactics – Adversary Emulation for Breach Prevention & Detection course.

What is parent ID spoofing and why is it deceptive?

did lsass.exe really spawn notepad.exe?

Parent ID spoofing is actually a direct result of a “feature” since windows Vista was released. Since Vista, programatorically, it is possible to select a parent process. This means that you can select the process that you want to spawn your new process under. If this sounds confusing, allow me to illustrate with an example: normally when you would open a command prompt, the parent process spawning the command prompt would be explorer. However, since Vista you could create a new program that launches command prompt under another process such as chrome for example. Check out Didier’s tool SelectMyParent.exe for an easy proof of concept on how this PID spoofing works.

Why would anyone want to do that, you ask?
Well, imagine an attacker has embedded a malicious macro in an office document. Should someone execute the macro, the office program would spawn a new process under itself, be it PowerShell, command prompt or something else. Modern defensive mechanisms such as EDRs will cause alerts, as this is abnormal behavior, therefore either completely stopping the attack before it even begins, or at the very least alerting the security team that something phishy (pun intended) is going on. Instead, it would be easier if the macro contained code that spoofed the parent to spawn from explorer instead of the original Office parent process. This behavior looks normal, and is thus less prone to be detected.

Ok, this sounds serious, how can we detect this?
Unfortunately, task manager and process explorer or process hacker will all show the spoofed parent as legitimate parent, so these tools aren’t useful. However, Event Tracing for Windows (ETW)  is not that easily fooled! ETW is a tool that lets you log kernel or application-defined events to a log file. You can consume the events in real time or from a log file and use them to debug an application or to determine where performance issues are occurring in the application. As these are real time events, the ETW log will tell you what the original parent was. ETW is however not that easy to set up, as it is a programatoric interface and not a tool you can just install and forget about. Because of this, I created a python script to help detect these events. The script is based on FireEye’s library to ingest ETW events in python and Countercept code to detect PID spoofing. The script has to be run with admin rights as it will need to access kernel events.

Conclusion

Image result for all warfare is based on deception"

As defenses are getting better, attackers need to come up with creative ways to stay ahead of the defense. Sometimes this means digging up old and nearly forgotten tactics to deceive forensic analysts and real time protection software. Even though detection is possible, collecting ETW logs at scale is difficult, and not many companies do this already. Parent PID spoofing, combined with command line argument spoofing, is a dangerous combination that should not be overlooked by defenders. Stay tuned for my next blog post that will illustrate command line argument spoofing!

About the author

Jean-François Maes is a red teaming and social engineering expert working in the NVISO Cyber Resilience team. When he is not working, you can probably find Jean-François in the Gym or conducting research. You can find Jean-François on LinkedIn.

6 thoughts on “The return of the spoof part 1: Parent process ID spoofing

  1. awesome idea, I tested it using Didier’s tool while running sysmon (installed previously in my lab). and the only clue that you could have is an event of a process with arguments (child process and Parent ID).
    and as you mentioned its ETW is something not commonly used.

Leave a Reply