This FalconFriday is focused on lateral movement. Especially lateral movement through DCOM, a technique used by many red teams. This post is inspired by the recent post on DCOM by Dominic Chell over at MDSec.

Today’s content

• Lateral movement (ab)using DCOM.
• Lateral movement with the Service Control Manager (SCM).

DCOM

Summary: Find DCOM-based incoming lateral movement by tieing together network events and process creation events. Very low false positives rate compared to all other documented detections of DCOM lateral movement.

Blue: Lateral movement over DCOM is a well-known technique (ab)used by many attackers and red teams. Most EDRs I’ve seen lack the possibility to detect this technique. My guess is that not enough people have looked at it in enough depth from a blue team perspective. I can barely find any in-depth analysis of how to detect DCOM lateral movement in a realistic environment with a ton of noise. Most “detections” documented only mention looking for child processes of the dcomlaunch service or dllhost. Another detection often mentioned is the creation of Word/Excel with the “/automation -Embedding” flags, but in a realistic environment, this happens A LOT. As in, 1k+ per 24 hours.

Based on some basic procmon logs, DCOM lateral movement involves the following steps:

1. Attacker requests target server for an “object activation” of a certain COM object.
2. RPCSS, the “Service Control Manager for COM and DCOM servers” receives this activation request as an RPC over port 135.
3. RPCSS asks the DCOM launcher to activate the COM object. This triggers a process start of the requested COM object for the lateral movement (e.g. MMC, Excel, ShellWindows, etc).
4. Attacker calls a remote function on the COM object (e.g. “ExcecuteShellCommand”).
5. Depending on the remote function called, this usually triggers another child process.

Today’s rule tries to identify steps 2, 3 and 5. The hardest part of this detection is the link between steps 2 and 3. The communication between the RPCSS and DCOM launcher are completely opaque to most EDRs. Hence, it’s “impossible” to tie an RPC object activation request to a DCOM launch.

To overcome this, this query tries to look for steps 2 and 3 happening within a second from each other and reduces the number of false positives even further by filtering results that don’t include step 5. This is obviously error prone, but nonetheless it produces fairly fruitful results.

By applying the above steps, we you can reduce the 1k+ events mentioned above to 5–10 results per 24 hour. For this query, I’m really curious on how many false positive you get in your environment. Please reach out on Twitter (@0xffhh).

Fetch your copy of the query here on GitHub.

One improvement for you to consider, is that “time matching” is now based on the bin() function, which rounds down to the nearest x seconds (1s in this query). This can produce false negatives if step 2 and 3 are not rounded down to the same second (for obvious reasons). For production purposes, we recommend you to improve this by using datetime_diff instead. See the SCM query below for an example.

Red: The best way to bypass this, is to use one of the whitelisted processes for as DCOM object. Especially dllhost.exe and wmiprvse.exe are very interesting processes, you know why 😉

Another approach for bypass is by breaking the chain between steps 2, 3 and 5 as explained above. You don’t have any (direct) control over the timing between 2 and 3. But the parent-child relationship used to identify step 5 can be broken by spoofing the PPID. I’m not sure how resilient DATP is against PPID spoofing, but that’s a story for another time I guess.

Another blind spot is to perform your lateral movement as close to system boot as possible. This query ignores the first 5 minutes of events after system boot to reduce the noise of process creation of svchost.exe.

Service Control Manager (SCM)

Summary: Detect lateral movement based on creating and starting Windows services remotely using SCM.

Blue: Besides DCOM, a similar albeit noisy lateral movement technique is to abuse the SCM. If this doesn’t ring a bell, think PSExec. SCM allows authenticated remote users with the correct privileges to interact with the local services. So you can create, delete, start, stop services remotely on a machine. This is exactly what PSExec/SMBExec does. DATP doesn’t detect remote interaction with SCM as malicious as that would cause too many false positives.

This detection is based on the observations documented here on ired.team. I’ve validated these observations and built this rule around it. The general principle of this rule is fairly simple: the rule tries to detect network activity from services.exe followed shortly by the start of a new child process of services.exe (i.e. a service start). Note the significant difference here: for DCOM, the communication and child processes are spawned under svchost.exe. Here, both happen under services.exe.

The rule itself is fairly complex as I had to fight DATP and Kusto for performance reasons. The (intermediate) queries were producing too many results, which was causing issues with the joins. For this reason, almost every part of the query is documented in-line. If you have any improvements or feedback, please reach out (@0xffhh).

The query is fairly accurate, expect just a handful of events per week, with a few false positives.

You can find the query here in the FalconFriday GitHub repo.

Red: Obviously best is to stay away from SCM. Abuse of SCM is a kind of well- monitored, especially (remote) creation of services. If you have to do it anyway, consider:

1. Don’t start the service right after creation. Create it and wait for (or force) a reboot.
2. Start the process more than 10 seconds after the initial connection. You need to ensure though, that the TCP connection is not terminated. The “time” between network traffic and child process start is measured from the start of the network connection, not from the last network activity.
3. Perform the lateral movement in the first 60 seconds after the start of the services.exe.

Knowledge center

Other articles

FalconForce realizes ambitions by working closely with its customers in a methodical manner, improving their security in the digital domain.

KVK 76682307
BTW NL860745314B01