Threat Hunting for Dridex Attacks: Top Questions from Security Teams

I recently spoke on a threat hunting webinar with our partner Carbon Black in which we dove into Dridex attacks: how they work, why they’re so effective, and how security teams can detect them through a proactive threat hunting approach. For anyone who’s unfamiliar with Dridex, the malware evades signature-based detection and is built to harvest the banking credentials of victims.

Watch the On-Demand Webinar: Threat Hunting for Dridex Attacks

We received so many great questions from webinar attendees that we ran out of time before I could address them all. Below are the questions and answers.

Top Questions & Answers on Dridex and Threat Hunting:

Q: You talked about the evolution from network defenses to endpoints. What would you say was the weakest point in the “before” setting?

I think the user has always been the weakest link. The problem that continues to arise, though, is that the user has more and more exposure. In the pre-cloud days, a user’s exposure was typically email, internet browsing, or removable media. Of course, these are very simplified examples. In some instances less than 10 years ago, users did not even have the exposure from internet browsing. When I first started in the field, many of the viruses were strictly removable media or SMB worms or things spread via email. (Remember the “I love you” virus?) The other common attacks were coming in via compromised web servers—and still are thanks to poor configuration management.

Now those access points to the user are much greater and the number of uncontrolled users has grown. What I mean by uncontrolled users is those outside the controls of the corporate environment. Many companies today have systems, data, and tools accessed from outside the corporate security controls. Many of the most recent breaches have been because of trusted access from an untrusted system. The most recent Verizon breach in France is a good example of this—and a reminder of the additional risks posed by the evolution of the corporate perimeter.

Q: How would you make a watchlist from this Dridex hunt? I think something like process_name:winword.exe parent_name:acrord32.exe md5:* would be pretty taxing on the server.

Per Carbon Black Response query guides, trailing and leading wildcards (eg md5:*) can be more taxing on the server. That said, it would depend on the scope of the other terms in the query also. As I mentioned in the webinar, the examples I gave should just be considered a jumping-off point that can be tuned to your environment. In my experience, the wild card used here is much less impactful than using something like childname: *.exe or filemod:*.exe.

Some example queries you could try for both hunt jump-off points or watchlists include:

process_name:winword.exe AND md5:*
process_name:wscript.exe AND md5:*
path:C:\Users\*\AppData\Local\Temp\* AND -digsig_result:"Signed”
process_name:acrord32.exe AND childproc_name:winword.exe
-digsig_result:"Signed" AND childproc_name:svchost.exe
process_name:svchost.exe AND -parent_name:services.exe

I would also recommend following up on the Carbon Black community forums for other query and watchlist ideas.

Q: If using Carbon Black, how can threats affect you like this if you are in high enforcement? Wouldn’t you always be hunting “nothing” if properly configured?

We used the detection and response tool Carbon Black Response in the webinar. This question refers to Carbon Black Protection, the whitelisting tool. These tools are certainly complementary and a complete high enforcement implementation will significantly reduce the attack surface of the endpoint. However, I still stand by the statement that prevention is not enough. There have been and continue to be attacks that are being used to bypass whitelisting controls.

One of my favorite examples is the Squibilydoo attack, which has now been commoditized into various malware distributions. Carbon Black’s blog post on the Squibilydoo attack lists a block function, but that rule would have to have been put in place after the attack method was identified. Further I have seen environments where that block rule would prevent certain system functions to break.

Here’s another example of an advanced attack bypassing application whitelisting, detected by Red Canary in one of our customer’s environment. Their environment is running both high enforcement CB Protect and CB Response and as a general rule, it is very clean and controlled. When an attack does happen, it’s more advanced in some fashion and potentially more impactful.

Application whitelisting is one of the best steps defenders can take to secure their endpoints but as you can see, it is not impervious.

Q: Red Canary integrates with Carbon Black through API. Have you ever considered or do you think it would be worth threat hunting though API?

To answer this I’m going to split into two parts: first, a glimpse behind the curtain on how Red Canary uses Carbon Black, and second, and a couple thoughts on API use.

How Red Canary Uses Carbon Black:

Red Canary uses Carbon Black to monitor and detect threats on our customers’ endpoints by collecting all the raw process data as it is passed from the sensor to the Carbon Black server independent of the native Carbon Black API. This allows us to process the data in new and interesting ways, while still giving the customer access to the power of the Carbon Black Response platform. A full explanation of our data processing and detection architecture is too in-depth to fit in this post, but we encourage readers to subscribe to our blog and look for a future post related to the topic.

Using the API for Threat Hunting:

We currently use the API for threat hunting as part of validating our hypothesis, baselining our customer environment, and for targeted searches. From an internal perspective, we have two different ways we look at endpoint data. One is for detection, which follows the above mentioned data processing flow. The other is for search, including related hunt efforts. We use tools built around the API for these purposes, such as the Surveyor python tool, which is available for free on GitHub for those who want to try it out.

Related Reading: How to Baseline and Inventory an Environment in Minutes with Carbon Black Response + Surveyor

Q: If you had a limited number of CB licenses, where would you prioritize their deployment? For instance, would you target high profile machines (maybe a senior figure or an HR employee who receives lots of mail) or would you deploy to critical infrastructure such as DC’s, Wsus/SCCM infrastructure?

This is a fairly common question we receive, especially from new customers. The short answer is: prioritize deployment based on where your highest risk or most critical data resides. In most environments, this is probably going to be a mixed bag and will likely be a combination of key individual workstations and mission critical servers. The answer, though, ultimately comes down to where you need the greatest visibility.

Read more about Endpoint Detection and Response (EDR) and endpoint visibility

Q: How does your product approach things happening in Memory? How do you scale memory hunting?

Carbon Black Response and Red Canary do not natively capture process memory. We are looking at activity related to cross-process activity and leveraging that information to identify or infer certain types of attacks.

The best advice I would give for a CB Response and memory hunting effort is to use existing hunting efforts to drive targeted memory hunts. So, identify a suspicious process or context and then pivot into memory based on that narrowed of scope. If you are using Carbon Black Response, you could use the live response function to run a PowerShell script or memory capture tool to grab memory of the target process. The script that Jared Atkinson and Joe Desimone presented at the SANS Threat Hunting Summit this year is a great example to check out.

Q: Can you search for the Parent_process, but look for filemods from child processes?

With a native Carbon Black query, you cannot query the filemods of a child process; the filemod field only refers to the current process. If I had a query or a hunt idea where I needed three levels of information (e.g., Parent process is Adobe Reader, process is Word, and the child process of Word wrote a file named evil.dll), I would run the search iteratively. I would write script using the API to iterate through. For example I would first find all the processes where Word was the parent and a process wrote evil.dll: parent_name:winword.exe AND filemod:evil.dll. I would then take the process ID of all the parent Word processes and check for Adobe as the spawning process. This would take a bit of scripting effort, but is just an example of how you may be able to attack the problem. The other thing to consider is how prevalent each component of the search is. If the filemod is the least common occurring event, I would start in that context.

Q: How do you approach the detection of Kerberos abuse? (DCSync, Kerberoasting, etc)

For this kind of attack, it depends. The common methods that I am aware of for these specific attacks is using Mimikatz or PowerShell post exploit tools like these:

• http://www.harmj0y.net/blog/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/
• http://www.harmj0y.net/blog/powershell/kerberoasting-without-mimikatz/

In those cases, I would look for specific TTPs associated with the use of those tools. The Carbon Black user forum has a number of establish queries for identifying Mimikatz activity and malicious PowerShell use. The other thing I would focus my efforts on is the use of specific built-in tools and their relation to the account running them or the process spawning them. All of this comes back to establishing a familiarity with your environment. Who has domain admin access? How are they accessing the DCs? Make sure you have an understanding of what is happening in your environment so you can detect uncommon activities.

Related Reading: Want Better Security? Start With These 5 Proven IT Fundamentals

Threat Hunting Resources & Tools

Red Canary’s Security Operations Center is comprised of threat researchers and analysts who are constantly hunting for potentially threatening activity. We compiled a collection of our most popular threat hunting resources to help organizations continue improving their threat hunting skills. I would also encourage anyone who has further questions to Tweet to me or reach out to our team anytime. Our team is always happy to discuss things we are seeing, how we use threat hunting techniques, or any other security topic that catches your fancy.