Tag: recovery

  • 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!

  • “But I Reset the Password” – Remediating an Enterprise After a Targeted Attack

    Determined human adversaries, or DHA for short, have changed the information security game for everyone.  Many customers take actions in attempt to evict an emplaced attacker – actions that result in alerting the attacker to the organization’s knowledge of their presence, but don’t truly evict the attacker from the network.  In this blog, we will discuss why a simple password change or implant cleanup does not impact a DHA – and provide insight into a comprehensive process for eliminating their presence.

    The “H” in DHA is Human

    It sounds obvious, but it is easy to forget the human aspect of a DHA.  Unlike normal malware infections (sometimes referred to as “commodity” malware), a human can identify and respond to changes in the target environment.

    For example, a simple bitcoin mining application or botnet implant is one of likely thousands of hosts involved in the attacker’s scheme.  In most cases, it doesn’t matter which machines commodity malware infects, rather it is about how many machines they infect.  Removal of one, 10, or 100 nodes from a botnet dents the capability of the attacker, but does not significantly impact their operation.

    In contrast, DHA implants typically have a specific interest in their targets.  Typically, a DHA attacker will work to obtain access to a specific target.  Once access is obtained, they will commonly setup multiple footholds within the enterprise to ensure that a single implant removal does not eliminate their access altogether.

    Implants, Credentials, and You

    Malware implants are only part of the problem in a DHA infiltration.  Once embedded, a DHA is likely to perform some sort of credential theft – either to elevate their current level of authorization, or to establish resilience in their forms of authorization.  Resilience is key to a DHA and ensures continuing access and authorization to their target should their implants be discovered.

    Credentials can provide durable access to a target, especially when paired with a powerful service, such as session virtualization (i.e. Remote Desktop Protocol) or remote management (RPC, WS-Man, SSH, etc.).  With a sufficiently powerful credential, an attacker can re-establish access placing their target right back in the same situation they thought they remediated.

    Tipping Your Hand

    An attacker may change their persistence technique if they realize their existing implant has been discovered.  Changes to command and control channels (the network path used by the attacker to communicate with the infected host), implant family, and other attributes surrounding the event may change, thus rendering prior research less useful.

    Taking a Coordinated Approach

    Responding to a DHA attack requires a coordinated strike addressing the ABC’s of the infection:

    • Accounts (any identities known to be compromised by the attacker)
    • Backdoors (the means that the attacker is communicating with “victim” endpoints, such as the malware implant or published management port)
    • Command and Control (the network path used by the attacker to interface with the backdoor)

    When planning to evict a DHA, ensure that your planning includes a concerted approach to eliminate as many of these aspects as possible as part of a single effort.  Successful eviction will result in the attacker losing access and authorization to the enterprise, forcing them to attempt to establish a new entry point.

    Bring in the Experts

    When planning this activity, consider engaging consultants who specialize in remediating networks after a targeted attack.  Consultants specializing in targeted attack perform this activity regularly and are typically more familiar with cleaning up targeted attack scenarios, thus their activities are less likely to cause unnecessary downtime and will be more aligned to disruption.