A threat activity cluster is a grouping of security alerts which are related to a unique or similar activity taking place in an environment. It leverages less of the standard IOCs in the pyramid of pain such as IP addresses, hashes and domains where actors are now well rehearsed with disposing of between attacks and more on the low level details in an attack.
How does it work?
- Knowing who is doing the attacking while a ransomware attack is taking place, and their usual behavior, can give a defender valuable insight into what the attacker might do next.
- A threat activity cluster doesn’t allocate which actor is responsible but can provide insights if the undetermined actor has been seen before in your environment.
- Threat activity clusters don’t necessarily include the more common aspects of attacker behavior such as TTPs or standard IOCs such as domain and IP addresses. Instead it is the more detailed and specific characteristics which an actor may overlook trying to hide.
- While having a ransomware note is great, it may only identify the ransomware as a service group and not the initial access broker or affiliate who deployed the ransomware.
Cant we just use Mitre ATT&CK TTPs?
Nothing is wrong with TTPs of course. A threat informed defence is a sensible approach. If you analyse TTPs used in attacks on organisations like yours or in the same region or better yet organisations like yours and in your region, you can begin to build a picture of where you should focus your defensive efforts.
But TTPs are quite high level. Someone attempting Brute force attack against your remote access service doesn’t narrow down the list of who it is very much. Also every actor will try every trick in the book, more so once they breach your perimeter, i.e. Looking up actors who attempt Kerberoasting or DC Sync does not give you a narrow list of suspects.
Also while it is interesting knowing a particular actor who attempted to compromise your network, for me it is not as interesting as knowing when an unknown actor makes repeated attempts
A step towards correlation
Actors deploying ransomware tend to reuse a lot of the same tools, techniques, and procedures as its simple human nature to repeat what has worked in the past, at least at the start. Some ransomware groups have created instructions for their affiliates to follow. An example of this is the playbook recovered as part of the Conti ransomware group takedown.
If an affiliate follows this example playbook to the tee, then filenames, folder paths and usernames will allow you to link them to the specific playbook. If they change the details from the playbook to their own filenames/username specific standards but do not change them between attacks then while we do not know who they are we can begin to start correlating their attacks.
While a threat activity cluster is not the same thing as an attribution, it can lead to an attribution, that is when enough correlating evidence is acquired.
Are the correlations between filenames in incidents? file1.bat may not be as generic as you think. Also if they rename a file what is the extension they add to it? Also dont forget to look at the folder paths they use when creating or moving files around. Again people tend to repeat patterns whether they are aware or not. I am doing it now as I type this post when selecting heading styles, I immediately gravitate to what I always use.
The same logic applies for usernames. If they create an unusual username once the infiltrate your network, what is it? If the run queries against your Active Directory, they will likely run their queries in a specific order be it user accounts with SPNs then domain admins then domain trusts or the reverse.
If someone is trying to brute force login to your network, what are the usernames they are trying? Is it a large dictionary of usernames or a small defined set of specific IT based usernames? This may not seem interesting but what about when you see the same usernames attempted at a different organisation? The IP address being used will most likely be different but an actor is less likely to try a different set of usernames.
Good IOC types to focus on in identifying clusters are:
- user-agents: can you identify patterns in user agents (you may need to cross reference the device type)
- usernames: are there patterns in the usernames, specific compromised credential sets used or in the case of brute force attempts can you identify strange dictionary user sets (i.e. a very unusual username attempted)
Of course, multiple different actors could be using the same large dictionary of usernames but add the ISPs of the proxies they are using and this may give you another point of correlation.
While a lot of actors are now living off the land and using toolsets they find, if they do download any software then again they will go for software which is familiar to them first. This could be port scanning software or archiving software.
