Sysmon 13 — Process tampering detection

January 11, 2021

Olaf Hartong

This new version of Sysmon adds a new detective capability to your detection arsenal. It introduces EventID 25, ProcessTampering. This event covers manipulating the initial image/process to be something different than the process it was launched with. However, it is not intended to be a catch-all event for all kinds of tampering events. EventID 25 is specifically tailored towards attacks like process hollowing or the whimsically named process ‘herpaderping’.

The configuration schema has been bumped to 4.50 to provide for the new EventID.

To some extent replacing the initiated image is common behavior, for instance for some system processes. So building a proper baseline will be key here to filter some known noise but not cause blind spots for yourself.

Currently, the new EventID 25 will not show a direct relation to the process that initiated the tampering action. However, this can be retrieved by correlating on the ProcessGuid in some cases. Unfortunately, this is certainly not directly possible in most cases and then you’ll have to rely on your (properly configured) telemetry as well as your hunting skills. A skilled adversary will make some attempts to cover their tracks, but of course some steps in their behavior can be observed.

Configuration

To utilize the new event I would recommend enabling everything by default and only filtering some trusted processes that have the same behavior. Obviously, this is potentially causing a blind spot as well, should an attacker tamper with the filtered process. As long as your defenses are solid enough you’ll hopefully catch them in an earlier or later stage.

To enable the event you can use the following minimal configuration:

<Sysmon schemaversion="4.50">
  <HashAlgorithms>*</HashAlgorithms>
  <CheckRevocation />
  <DnsLookup>False</DnsLookup>
  <ArchiveDirectory>Sysmon</ArchiveDirectory>
  <EventFiltering>
    <RuleGroup name="" groupRelation="or">
      <ProcessTampering onmatch="exclude">
      </ProcessTampering>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Obviously, you’ll need to incorporate it into a larger configuration, like the one I am maintaining here.

The next step will creating a baseline for your systems; this event is not a very noisy one so you could even consider not filtering at all to have all the context you could get from it. There are however processes you would want to consider filtering, have a thorough look at them and build a list of known good ones.

Unknown image being tampered with, most likely due to a system process.

Besides the above example, which occurs several times a day using the early release version of Sysmon I’ve been testing with, there are some processes that also generate benign events.

Some example processes would include browsers like Edge, Chrome and Firefox. Another one is Visual Studio Code and some of its plugins like git.exe. Additional testing showed me that most Electron based apps will generate events. Keep this in mind when building a configuration for your workstations, on servers this shouldn’t be a big issue since they are (hopefully) not as abundant there. Slack for instance is a particular one, generating 5 consecutive events for a single process start.

Just filtering these on a system isn’t recommended, since this are also apps that an attacker would love to use for persistence. They are open all the time and generate enough noise to begin with to hide in. In these cases I would recommend baselining the behavior of a set of correlated events and trigger on outliers. This leaves a lot smaller abuse opportunity while getting less false positives.

Testing the new event

First, I started with the ProcessHerpaderping technique. This is a method of obscuring the intentions of a process by modifying the content on disk after the image has been mapped.

Process Herpaderping launching Calc, pretending to be Procmon.

Process creation event and the Procmon file create event.

ProcessTampering event that triggered, showing Procmon has been replaced.

As you might have spotted the ProcessGuid in this example is not identical. However, we need to learn a bit more about the GUID. In this case it does not seem to be a UUID. But what we are able to see is that they are in still HEX. So if we have a look at the 4th section which contains the different value from the events we captured, we see the following:

02de4985-ef0c-5ff9-8ea3-000000000800
02de4985-ef0c-5ff9-8fa3-000000000800

They are close, which is not super common on most systems, so these events have a relatively high probability of being related. In this example I’m obviously very certain since I generated them to begin with.

Some yaks were shaven in vain while I tried to understand the structure of the GUID a bit more. I hope Mark Russinovich can provide some clarity here. My best attempt was COMPUTERID-[TBD]-UNIX-TIME-[TBD]

5ff98ea3 =(HEX to Binary)>1610190499

5ff98fa3 =(HEX to Binary)>1610190755

While this had all the signs of it being a UNIX timestamp, it did come close, but it wasn’t. The date is right but the time is wrong, so this remains to be better understood. Carlos Perez, the author of the excellent community guide, explained to me he believes the GUID to be a sum of the TimeStamp, MachineGUID and ProcessID, which makes it unique on a millisecond base.

Events with a GUID so close to each other have a probability of being related, but they do not have to be. I have not been able to baseline this but it would be an interesting way of correlating events that have a potential relationship.

Next up was Process Hollowing. Process hollowing is performed by creating a process in a suspended state followed by unmapping/hollowing its memory, which can then be replaced with malicious code.

ProcessCreation event, showing all details of the initial phase.

This example binary launches svchost.exe as suspended, next the memory is unmapped and a piece of very basic code is inserted.

Finally the process is resumed and the new code will be executed, with no indication of this new process in the logging.

This is where the new ProcessTampering event steps in.

Note the ProcessGuid that will allow correlation with the ProcessCreation event to provide additional context into what caused this image replacement.

Finally, I wanted to see whether process injection techniques would also be caught by this new event type. This was not the case, which is by design. Process injection techniques, depending on the variant, can be detected by EventID 8 CreateRemoteThread and/or EventID 10 ProcessAccess.

During my testing these were the message types I was able to generate for ProcessTampering:

Type: Image is locked for access
Type: Image is replaced

Closing remarks

ProcessTampering is a very low noise and very useful addition to Sysmon. The amount of readily available information about what caused the event within the log entry is fairly limited. Knowing tampering occurred in the first place is still extremely valuable and will allow you to have a good look at these machines.

I did experiment with some DLL hollowing techniques, which I expect to also be visible in this new event. Sadly, I could not get my samples to properly execute on my test systems; they kept on crashing.

However, having a call stack in EventID 25 would be beneficial for sure. Since it’s not a very noisy event to begin with it will add certain value at limited overhead. I know the Sysinternals team has been looking into it, once they are able to populate it with useful data it might be added later. This is especially useful keeping in mind people sometimes (badly) tune their config to be somewhat less verbose; so they might lack some contextual events in EventID 1,8,10 if it isn’t an in-memory trigger to begin with.