You are browsing the archive for threat hunting.

Event ID 7039 – out…pid a pid

February 26, 2021 in Compromise Detection, Sysmon, threat hunting

This event is not very well explained on the internet, so I took a liberty of describing it below:

The event message is as follows:

A service process other than the one launched by the Service Control Manager connected when starting the [SERVICE_NAME] service. The Service Control Manager launched process [PID1] and process [PID2] connected instead.

Note that if this service is configured to start under a debugger, this behavior is expected.

The message kinda tells us what happened – two different processes talk to SCM instead of one. It doesn’t really tell us WHY this happens.

Example from a case I looked at in response to a query on Twitter:

In this particular case the c:\windows\sysmon.exe was registered as a program that service process starts from. I believe this file was later manually replaced with a newer version of sysmon.exe. The little-known fact about distributable version of Sysmon (sysmon.exe from the sysinternals page) is that it is built as a 32-bit executable with an embedded 64-bit executable inside its resources. When launched on a 64-bit system the 32-bit version extracts and spawns that 64-bit version executable (note the PIDs and compare them against the Event Log):

Looking at it in general terms: when you register a service its configuration in Registry points to an executable file. This executable is then used to launch a service. Some services are not designed in a very good way. Once such programs are launched as a service, they spawn other processes, sometimes even batch files that may as well launch other programs. If one of these spawn programs talks to SCM the latter immediately recognizes that it’s not the same executable as the service process the service configuration points to. Such design is in general poor and could be a subject to possible privilege escalation (in a lolbinish way). And since this is a security concern the event 7039 is being logged.

And this leads me to the key reason I wanted to write an article. The Event 7309 tells you two things:

  • Whoever designed the service didn’t do the best job, OR, more importantly,
  • A bad guy may be using a badly designed service to escalate privileges.

Hence, you should be looking at these.

And last, but not least – does it mean Sysmon is designed badly? Nope. It’s designed in a clever way to use a single portable executable for 32-bit and 64-bit systems. The problem arises from a corner case in a way it was manually upgraded, instead of using the “-u” switch.

WerFault – command line switches v0.1

September 20, 2019 in EDR, threat hunting

I posted about werfault.exe a couple of times before. Some of the posts focused on persistence mechanisms, some on lolbinish behavior, but I thought it would be good to dedicate some time to describe the actual command line arguments this program accepts…


In my opinion werfault.exe accepts the most bizarre command line arguments combos on Windows platform ever. And despite werfault.exe process being executed so many times we are yet to see a comprehensive description of the switches it relies on. And what makes them stand out is that:

  • at a first glance, they look completely random
  • they use / rely on a bunch of weird, unusual and undocumented arguments, and finally,
  • many of them expect values in a numerical, often hexadecimal format that confuse every single analyst that ever put their eyes on it…

The below summary is my first attempt to take a stab at this topic so it may not be the most complete reference, BUT… we have to start somewhere.

The key to understanding werfault.exe command line arguments is to focus on the first switch being used. Yes, the very first thing werfault.exe is doing when it’s invoked it is checking the why:

  • -e: SQM Escalation
    • -e -p <num> -t <num> -r <num> -a <num> -f <num>
    • -e -p <num> -t <num> -r <num> -a <num> -f <num> -h <num>
  • -k : kernel-related
    • -k -lc <dump file name>
    • -k -lcq
    • -k -q
    • -k -rq
    • -k -l <string> <string> — live kernel
    • -k -lc <string> <string> — live kernel
  • -p: ?
    • -p <num> -h <num>
  • -pr: ?
  • -pss: ?
  • -s: process executed via SilentProcessExit mechanism
    • -s -t <num> -i <num> -e <num> -c <num>
  • -u : user mode
    • -u -p <num> -s <num>
  • /h – elevated hang reporting
    • /h /shared <shared>
    • /h /shared <shared> /t <num> /p <num>
  • /hc – ?
  • ??? -nonelevated – ??

The command line switch separator (- or /) that I listed above is actually important and its hardcoded form is what the program expects and compares against. This is somehow unusual and it escapes a typical pattern we are familiar with (either of these two characters – or / are commonly accepted as switch indicators).

I am aware of many other command line switches, but I am still browsing through the code, so I will update this post when I get more info.

What’s the lessons learned here?

If you see werfault.exe process in Sysmon or 4688 logs try to figure out what their execution is indicating. Sometimes, they may be an early warning of malware trying to do something that is prohibited on newer versions of Windows, but was fully acceptable on older. Also, if any program crashes, and it involves werfault.exe, you can use it to provide a feedback to the vendor/software developer…

There is literally a lot of goodness that can come out from looking at werfault.exe process invocations in general. Whatever crashes, hangs, breaks usual patterns is always an interesting thing to look at.