By: Krystal Rennie, Director of Corporate Communications

In today’s rapidly evolving digital landscape, cyber threats can be identified around every corner, leaving the role of a threat research team to be non-negotiable. Through continuous monitoring, proactive analysis, and timely dissemination of threat intelligence, threat research teams are tasked with fortifying defenses and empowering organizations to stay one step ahead of cyber adversaries.  

In this blog post, we sit down with the Adlumin Threat Research team’s Director, Kevin O’Connor to discuss their pivotal role, shed light on Incident Response, and how the team’s insights are essential in the ongoing battle against cyberthreats. 

Kevin, please tell us more about your team’s role. 

The threat research team works to proactively identify threats that may have bypassed security controls. Another way to think about it is we look for new threats that have yet to be detected. Since they have yet to be detected, there are no rules to protect against these threats, like a specific new type of malware. The Adlumin Threat Research team looks specifically for these undetected threats so we can build defenses to identify those threats in the future.  

We’re also responsible for incident response for our customers. We work with customers when a breach has affected stored data or multiple systems and hasn’t been contained.  The team works with our customers to do complete, end-to-end incident response, identify the root cause, and eliminate the threat.  

Talk to us about the difference between investigation and incident response. 

An investigation analyzes a specific event that might have been triggered by a Managed Detection and Response (MDR) team or MDR software. An investigation looks at a particular event to see if it is malicious in nature, its disposition, and contain the threat from spreading.  

Incident response is the step that comes after an investigation, it includes a deeper dive into the events, additional analysis, potential reverse engineering, and most importantly, eradicating the threat. Then incident response determines the breach’s root cause and overall impact on the business and its assets. It focuses on discovering how the threat got into your network, how long it was there, what it did, and how it bypassed the defenses.  

What are the most common ways that attackers get in and what can customers do to protect themselves?

The most popular way attackers get in is through phishing or spear phishing emails.  

It’s the user who falls victim to these attempts and clicks the malicious link in their inbox that either leads them to a fake login site where they put in their credentials. The attacker can now access the e-mail account and associated productivity tools like OneDrive, Sharepoint and Word, where they can access files or add a malicious file. Or when users open infected attachments sent to them via email, the typical Word Document or PDF with malware is added to kick off the attack. The other half of it is being redirected to sites that then do browser-based exploitation; the attacker exploits your web connection to an accessed link to be able to put malware down on your device, I think those are the two paths within. The human interface between you and the computer results in a lot of exploitation.  

What adversary trends do you think we’ll see in the next year? 

I expect to see more examples of supply chain breaches that lead to compromise.  We saw it earlier with the MOVEit vulnerability, during SolarWinds, and even before that there’s been many examples of commercial software being used to attack the products customers. More advanced malware attackers look at supply chain compromises to enable attacks, especially widespread and against hardened targets.   

What are easy ways to quickly identify if you are being attacked vs being breached? 

It’s important to realize that most organizations are being attacked daily. Those daily attacks might be script kitties, but when we pull up any specific customer and look at their external network perimeter, we see attempts to get into any open services all the time, so the attacks are constant. 

In an attack, you’ll often see many signs of failed entry or exploitation attempts against the customer. So, if you think about an account inside of a customer, let’s say, the billing department, with access to all sorts of financial systems and billing data. And we see repeated phishing emails, maybe all using the same tactic, techniques, and procedure, to get that initial exploitation onto the victim’s machine – that might constitute an attack on your environment. 

Whereas, seeing things like excess connections from a specific host or something trying to reach back to your network is typically a sign of a breach. Other signs are actions taken on the network’s assets, like programs being installed, data being exfiltrated, or settings like security relevant logging being changed.  

What key items should be included in an Incident Response when a breach occurs? 

One of the most important parts that should be included in an Incident Response report is scope. With large-scale breaches, it can quickly reach numerous endpoints within your environment. You’ll need to know what network assets were compromised, what data was compromised, and what access the compromised users/systems have to the data. A timeline of infection and a timeline of exactly what was done, when, and how to contain it is also critical. 

Another key part of the IR report is the root cause analysis that explains how the attackers got into your system so you can close the door and lock it. Time is spent to eradicate the threat and if you don’t close that door the adversary could come back the next day and do the same thing over and over again. Plus, another attacker could also find the same door and exploit it. 

What do you enjoy most about your role?  

I enjoy finding new threats that haven’t been detected before. I love finding a new piece of malware that hasn’t been identified yet. It’s like when a scientist discovers a new animal in the wild. They found a new species of bird or beetle or whatever and get to document exactly how it works, what it does, and how it fits into the ecosystem. There’s a lot of technical investigation involved.  

For example, when we uncovered “PowerDrop,” a malicious PowerShell script that has set its sights on the U.S. aerospace industry, we discovered the malicious malware used advanced techniques to evade detection such as deception, encoding, and encryption. The malware runs remote commands against victim networks after gaining initial access, execution, and persistence into servers.

It’s a big puzzle that you put together, especially when you’re doing reverse engineering, it’s almost like an art and I enjoy it a lot.  

Incident Response and the Adlumin Advantage 

Most IR response firms use third-party tools and deploy it all over the environment to collect information and logs. A core capability of the Adlumin platform is we have insight into all the logs and events for the past three months or more for our customers, so we don’t have to deploy additional technology.  

The events are constantly being saved to a secure source, where attackers can’t really modify them. This is important because if you gather log sources after the attacker has disturbed the environment, the logs may have been poisoned. So, it’s hard to determine the truth. 

Since our agent is already collecting logs and events, even before an incident happens, a lot of the data is already safely stored and logged, which means we can cut down on incident response times and gives customers some savings while giving us an advantage in responding and catching attacks. 

To learn more about Adlumin’s Incident Response offering, download our datasheet today or contact one of our cybersecurity experts for demo.  

By: Joshua Beach, Detection Engineer and Andrew Chapin, Threat Researcher

Welcome to the Unraveling Cyber Defense Model Secrets series where we shine a light on Adlumin’s Data Science team and explore the team’s latest detections and learn how to navigate the cyberattack landscape.

DCSync Attacks are hard to protect and used often by cybercriminals who aim to takeover your network. In this blog, we’ll walk you through the methodology, detection and  more, let’s begin:

Domain control is a common intermediate goal in many cyber attack scenarios including Advanced Persistent Threat (APT), Inside Threat, and Ransomware. Executing a Domain Controller Sync (DCSync) attack is a popular method for achieving domain control. Often reliant on the exploit tool Mimikatz, DCSync can also be performed with manual methods.

Methodology

A DCSync attack targets Windows Active Directory (AD).

In this type of attack, a threat actor targets a feature in AD called the domain controller (DC) which allows different parts of the network to share and synchronize data.

The domain controller is a high value target because it stores a secured database that contains sensitive information, such as user account records with usernames and password hashes.

During a DCSync attack, the threat actor attempts to trick the domain controller into sharing the user account information by utilizing the Directory Replication Service Remote (DRSR) protocol. This allows the threat actor to pretend to be another trusted domain controller that is part of the network.

A successful DCSync attack, allows an attacker to steal sensitive account records in the database. The attacker will then try to crack the password hashes and gain unauthorized access to user accounts (including to network admin or super-admin accounts) and gain more control over the network.

Detection

Adlumin has created a detection for DCSync Attacks that can recognize and alert on the methodology used by threat actors described above. This allows for quick mitigation and remediation for clients.

The starting point is to review Directory Replication Service Remote (DRSR) related logs found in the Windows security log. Specifically, events with ID 4662.

Then, logs are filtered to focus on entries where the requesting user possesses the necessary credentials to make domain requests. The logs are examined to identify any suspicious or unauthorized domain requests that may indicate a DCSync attack.

The challenge is to sift through benign activity in this subset of DRSR logs.

The DRSR protocol is primarily used within networks to provide redundancy for multiple domain controllers. Thus, DC to DC replication is considered normal, while DC to host replication is not.

Adlumin will flag any DCSync requests from non-DC hosts as potential malicious activity. A security team can then quickly identify and respond to any potential threats against the domain controllers running on the network.

Remediation View: 

The Problem

The DCSync attack methodology takes advantage of the Directory Replication Service Remote (DRSR) protocol to obtain sensitive information from a domain controller. This functionality is not a bug, but rather is intended activity to provide user friendly redundancy in a multi-DC network.

This technique involves an adversary masquerading as a domain controller (DC) and convincing the authentic DC to synchronize its database to the new rogue DC by issuing a replication request. The results of a successful DCSync attack will provide the adversary with password hashes of the targeted users. In most cases, this will include all users.

The Algorithm

By using the associated logs resulting from actual DCSync attacks, Adlumin is able to filter on their defining characteristics to build detections. A few of these factors include user replication rights, if the requesting machine is a DC or not, and access rights. This rule-based detection scans every 6 hours for any new cases of this occurrence and will alert you for further investigation.

User Actions

When encountering an alert indicating a domain user attempting DCSync requests, the objective is to determine if the alert is an active threat or a false positive. But how?

Let’s remember that attackers rarely perform actions in isolation. Threat actors tend to chain together several steps. Therefore, we can check for other actions in tandem with the DCSync request.

Below is a list of items to check:

Verify User Account and Behavior

Verify authorized creation of the user account and if the DCSync behavior is normal for your network. This detection alerts on DCSync related behavior, but some organizations have been found to back up their domain controller data to non domain controllers. If this behavior is normal and accepted within your network, disregard this alert.

Domain Controller Syncing
Ensure that the host machine of the suspected DCSync attack is NOT a domain controller. Failure to identify it as such may result in a false positive. DCSync activity between Domain controllers is generally benign.

Enumeration of Permissions
The attacker will often check which accounts have the required permissions to perform the DCSync attack before performing the attack. Here is an example command:

Exploit Command
To perform the attack a program must be executed to make the request to the other domain controller. We can check process execution on the machine that was the origin of the attack and search for any suspicious process execution that occurred at the time of the DCSync attack.

Text BoxHere are some example commands:

Persistence
If the attacker has compromised a domain admin account, they may get the permissions required to perform the DCSync attack to another account.
Text BoxHere is an example command:

Network Traffic
The most effective way to discover and identify a DCSync attack is through network monitoring. Confirming whether the attack originated from a DC IP address on your network is much faster and less prone to false positives.

Here are some example Suricata signatures:

1. Quarantine the DCSync user.
2. Identify which credentials were compromised.
3. Reset the credentials.

To make DCSync attacks more difficult, be sure to carefully control the following privileges in Active Directory:

• Replicating Directory Changes
• Replicating Directory Changes All
• Replicating Directory Changes In Filtered Set