Proactive Threat Hunting – Practical Use Cases
In my last article, I explained how organizations can redirect attention away from alerts but invest in more fine-grained and proactive threat detection. I put forward an example for a simplified threat hunting process. Today, I’d like to share some practical use cases in establishing proactive threat hunting.
Don’t ignore your Anti-Virus (AV) logs
Many treat their AV as an install and forget kind of solution – the simplest mechanism out there to get rid of the known bad. That is a mistake. While it’s hard to expect fireworks from traditional AV when it comes to stopping targeted attacks, it’s important to understand that even state sponsored actors make mistakes or get lazy. It isn’t uncommon to see, especially in the later stages of attack, known malicious tools being dropped on compromised systems alongside the more customized ones. By analyzing those dropped crumbs it is sometimes possible to find a clue to a much more significant compromise.
So, what should organizations focus on if they face hundreds of blocked infections daily? Here are some good places to start:
- Seeing malware removed from directories like C:Windows* or C: root catalog is never a good sign. It means that a process with local admin or system privileges tried to put it there which usually means that the system was successfully exploited.
- Look for threat names or create a list of threat categories that are more interesting or rare. Each AV product maintains some taxonomy that describes threats matched by their signatures. While looking at coin miner scripts blocked in temporary internet files might be very time-consuming, looking through things classified as HackTools, PWStealers, Trojans may give better and faster results.
- Differentiate between type of scan blocking the threat. Threat blocked by an on access scanner in a user’s temporary directory will often mean the file was blocked before infection could be successful while a threat being removed by a scheduled scan will often mean that the infection could have been active for some time before it started to be recognized by the AV and hence the impact is different.
Monitor PowerShell usage
Over the years PowerShell evolved to become a very powerful and easy to use scripting language used by administrators to manage Windows environments. Attackers realized that all they need to accomplish their goals is already provided by this native, built-in Windows tool. It can’t be blocked by AV and it can be used to manage remote computers. Without proper restrictions and logging defined it also stays below the radar as essentially no files need to be created to run PowerShell commands. This means that even if attackers’ techniques are identified it can be very challenging to identify all impacted systems. Generally, a good approach is to first create filters over a few days from known good activity in the monitored environment. After this, what is left can be reviewed more closely. It is always a good idea to have a look at PowerShell invocations that are:
- Executed with the hidden parameter like powershell.exe -nop -w hidden
- With base64 encoded command or/and obfuscated like:
powershell -NoP -E W3N0cmluZ10kbWU9R2V0LUNvbnRlbnRDOlxXaW5kb3dzXHRlbXBcZnNmc2Rhcy50bX
- Referencing environmental variables or registry entries to get the code from and hence facilitate file-less attack like: C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -NonI -W hidden -c "IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String((gp HKLM:SoftwareMicrosoftBing devenv).devenv)))"
PowerShell commands can be monitored even using the native Windows event logging with proper auditing options configured. If collected centrally, a good data analytics tool can prove to be a great working base for threat hunters. Good article on using PowerShell by Blue Teams can be found for reference here.
Obviously, tools exist for example on the Endpoint Detection & Response market that will focus on detecting suspicious PowerShell actions directly on the endpoints further automating detection and prevention capabilities.
Set up traps
There is nothing more ‘rewarding’ than seeing an attempt to use a domain admin account that was planted as a decoy. Or seeing someone trying to use stolen credentials to authenticate to this decoy file server named FINANCE_OLNY. One possible way to create decoy credentials can be found in this article. When it comes to setting up honey traps, the sky is the limit here. There are some free open source as well as commercial solutions on the market. Alternatively some may find it interesting to define a percentage of their infrastructure on which to deploy high visibility monitoring on the network and endpoints level. While for many organizations this is too expensive or not practical to deploy everywhere, then smartly divided locations can provide indications that something is wrong for a fraction of the cost and effort. The good use case here is to look for lateral movement attempts targeted at the monitored assets.
Finally, there is nothing wrong in grabbing a set of known IoC (Indicators of Compromise) from public sources for example utilizing MISP as a central repository and automating checks for selected sets in your environment.
Starting with the known bad sooner or later ends with finding the new and unique threats in the monitored environment and turns the most mature organizations from Threat Intelligence consumers to Threat Intelligence producers.