Tracking Command and Control Communication

With all of the great detective technology we have today we have a number of ways to track adversary activity. If the threat you’re tracking is a human adversary within your enterprise, any gap provides an opportunity for them to reestablish persistence using a different type of malware and a different command and control channel. Here are some ways you can track an adversary within your enterprise using Microsoft 365 Defender and C2 Monitor – my Powershell TCP tracker.

Tracking

First thing first, once you identify a command and control address do not simply block it if you believe it is associated with a human adversary. Command and control channels are a great way of finding other compromised endpoints within your enterprise. Additionally, incomplete interception simply informs the attacker that you’re aware of their presence. This may cause them to use other previously undetected compromised endpoints to establish a different form of persistence, likely with a new communication channel.

If your enterprise already has Defender for Identity set up you can find out which devices are querying for the C2 DNS name by querying the IdentityQueryEvents table, ActionType “DNS query”.

IdentityQueryEvents
| where ActionType == 'DNS query'
| where QueryTarget endswith 'attackerdomain.com'

You can also see if any Defender for Endpoint clients are attempting to resolve the malicious domain by searching through the DeviceEvents table for ActionType “DnsQueryResponse”

DeviceEvents
| where ActionType == 'DnsQueryResponse'
| extend AdditionalFields = todynamic(AdditionalFields)
| evaluate bag_unpack(AdditionalFields)
| where DnsQueryString endswith 'attackerdomain.com'

…or by looking at the RemoteUrl or RemoteIP columns of the DeviceNetworkEvents table.

DeviceNetworkEvents
| where RemoteUrl contains 'attackerdomain.com' or RemoteIP == '1.2.3.4'

If you aren’t using Defender for Endpoint you still have a number of options available. Every piece of network infrastructure within your enterprise can be weaponized as a sensor:

  • Firewalls are great for monitoring communication with known attacker IP addresses
  • Proxy servers can be used to monitor for attempts to connect to web protocols
  • Routers can be used to covertly send traffic through a network path of your choosing or to a spanned port
  • Some DNS servers, such as Infoblox, provide DNS query monitoring which is ideal for tracking attempts to resolve attacker addresses (or DNS-based command and control)

You can also instrument your Windows endpoints to log any network connections using Sysmon and forward the associated logs to your SIEM for tracking and alerting.

Interception

One of the challenges of monitoring command and control communication post-interception is that most of it will be blocked (assuming you’re blocking at both the endpoint and the edge, which is best practice – more on that in a later post). The good news is that you can set up your interception strategy to enable monitoring of communication attempts.

First, there are the obvious post-interception monitoring capabilities: firewall, proxy, SIEM, or EDR block events. But what about those shadow IT devices which may be missing from your enterprise solution – such as IoT devices, non-enterprise BYOD, or rogue devices?

One technique I like to use is deploying a Powershell script I like to call C2 Monitor (link). This simple script is basically a TCP server which logs any connection attempts in an event log.

C2 monitor can be deployed on any Windows endpoint. Personally, I would recommend a stand-alone box with no domain association and different local credentials. If you have a SIEM solution, consider deploying the agent to this device to watch for connection attempts.

When you are ready to perform interception, create a new zone on your most authoritative DNS server corresponding to the attacker’s command and control address. Add a record for each record used by the attacker and point it to the machine running C2 Monitor. Now, any compromised device that uses your internal DNS for name resolution will check in with the C2 Monitor system instead of the attacker’s system and will be logged.

Happy hunting!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s