Impacket Detection – Part II: Detecting Impacket Attacks with Trovent MDR

Trovent MDR supports a wide range of different log sources as input, such as NetFlow data provided by routers, Sysmon logs and Windows events (shipped via Winlogbeat).

In the detection process Trovent MDR:

• normalises and enriches all received log data and

• processes normalised logs using the Trovent Stream Processor (TSP)

with the objective of detecting security-relevant events in near real-time.

(FYI: The Trovent Stream Processor is a Java application that enables the creation of complex analysis expressions on the basis of EPL – ESPER processing language.)

In order to use Trovent MDR’s rule-based detection capabilities to detect potential Impacket attacks, a simple approach is to:

• ship Windows security event logs to Trovent MDR from Windows hosts using Winlogbeat

• use events contained within Windows security event logs to trigger detection rules in Trovent MDR

In the following sections, we’ll explore this process using a few practical Impacket examples.

Detecting Impacket Attacks

Using the following examples, we’ll explore Trovent MDR’s rule-based detection capabilities for Impacket attacks:

• secretsdump.py

• changepasswd.py

• addcomputer.py

• smbexec.py

• wmiexec.py

• services.py

• reg.py

Detecting secretsdump.py

Secretsdump is a potentially severe attack, because it allows the extraction of NTLM hashes. These hashes can then be used for so-called Pass-the-Hash attacks which are also supported by a number of Impacket tools.

An attack using secretsdump triggers a high number of different events in the Windows Security Logs. In this particular example, we will try to write a minimal number of rules using as few Windows events as possible.

But, there is a caveat to this approach: This could lead to a high number of false positives in production environment! More on that later in this article.

To develop a suitable Trovent MDR detection rule, we need to pick an “event chain” that sufficiently resembles secretsdump. We chose 5156 -> 5145 -> 5145 as the event chain.

• Event 5156 is created by the Windows Filtering Platform which allowed a connection. With this event we can specify DestPort = 445 and NOT SourceAddress.contains('192.168'). The former indicates that our attacker connected to our victim machine over port 445, due to the fact that Impacket secretsdump communicates over the Server Message Block (SMB) protocol. The latter indicates that the connection attempt was done from a machine outside of the local network.

• Event 5145 is generated every time a network share object (file or folder) is accessed (5145(S, F) A network share object was checked to see whether client can be granted desired access. – Windows 10). Secretsdump generates two such events with RelativeTargetName = 'svcctl' and RelativeTargetName = 'winreg' respectively.

The command WHERE timer:within(10 sec) ensures that these events all occur within ten seconds. Furthermore, PrimaryIP = a.PrimaryIP checks that these events all originated from the same machine.

The detection logic described above is captured in the following Trovent MDR code snippet:

Detecting changepasswd.py

changepasswd.py allows attackers to change passwords for accounts.

The “event chain” we use to resemble changepasswd’s behaviour is 5156 -> 4624 -> 4661 -> 4738 -> 4634.

• Event(5156) is the same as in secretsdump and will be frequently used in the following Impacket attack scenarios.

• Event 4624 is triggered by a logon (4624(S) An account was successfully logged on. – Windows 10 ). LogonType = 3 indicates that it was a network logon which occurred during an Impacket attack.

• 4661 indicates that an object handle was requested (4661(S, F) A handle to an object was requested. – Windows 10).

• Event 4738 triggers every time a user object was changed (4738(S) A user account was changed. – Windows 10), which happens every time changepasswd is called. SubjectLogonId = c.SubjectLogonId links it to the same logon session as Event(4661) similar to how PrimaryIP links it to the same machine.

• Finally, event 4634 is the logoff event (4634(S) An account was logged off. – Windows 10) which always happens within the ten second time window.

• The detection logic described above is captured in the following Trovent MDR code snippet:

Detecting addcomputer.py

Addcomputer allows attackers to add users to the targeted machine.

The “event chain” we use to resemble the behaviour of addcomputer is similar to changepasswd with 5156 -> 4624 -> 4661 -> 4741 -> 4724. The first three events are the same as in the previous examples. Additional events required for this particular detection case:

• 4741 is the event for a created computer account (4741(S) A computer account was created. – Windows 10), which we again link to the SubjectLogonId and PrimaryIP of previous events.

• Event 4724 indicates that the account’s password was reset, which is the most powerful way to execute changepasswd, because it bypasses Windows password policies.

The detection logic described above is captured in the following Trovent MDR code snippet:

Detecting smbexec.py

This Impacket attack provides a semi-interactive shell using the Server Message Block (SMB) protocol.

The “event chain” of Windows events that we use to identify the behaviour of smbexec.py is 5156 -> 4672 -> 5140 -> 5145.

• Instead of 4624 (Logon) we now use 4672 (Special Logon).

• Event 5140 indicates File Share Access with the ShareName.contain('IPC').

• 5145 is the event generated every time a network share object is accessed, which we already used in previous examples. In this case we included RelativeTargetName = 'svcctl' as an additional condition.

The detection logic described above is captured in the following Trovent MDR code snippet:

Detecting wmiexec.py

Similar to smbexec, the Impacket script wmiexec.py provides a semi-interactive shell, but using Windows Management Instrumentation (WMI) instead.

The chain of Windows events that we are focusing on for detection purposes: 5156 -> 5145 -> 1.

• 5156 and 5145 were already used as events for previous Impacket detection examples. In addition, for this particular case of detecting wmiexec.py , the detection rule ensures that the field RelativeTargetName is set.
• Event 1 is the “process started” event, where we check whether ParentCommandLine contains b.RelativeTargetName. Please note that Event(1) does not originate from Windows security logs, but rather from the Windows service Sysmon. However, using the Winlogbeat agent, Sysmon logs can be easily extracted and shipped from the monitored Windows host(s) – alongside the regular Windows security logs.

The detection logic described above is captured in the following Trovent MDR code snippet:

Detecting services.py

The Impacket script services.py runs the Service Control Manager Remote Protocol which enables an attacker to manipulate the services running on the victim machine. services.py can be used to stop essential services or even start services that aren’t meant to be running.

The collection of Windows events that we use for detection purposes in this case: 5156 -> 4624 -> 5145 -> 4674.

• The first two events are the filtering platform and logon events that are used in the previously described detection scenarios.

• Event(5145) has an additional condition of LogonID IS NOT NULL which is used to relate the events 5145 and 4674 with more than just the PrimaryIP.

• Event 4674 is triggered when an operation is attempted on a privileged object (4674(S, F) An operation was attempted on a privileged object. – Windows 10). For detection purposes, we added the condition that the field ObjectTypeis set to 'SERVICE OBJECT'.

The detection logic described above is captured in the following Trovent MDR code snippet:

Detecting reg.py 

For our final example, we constructed a detection rule for Impacket’s reg.py script. Similar to reg.exe, reg.py allows attackers to manipulate the Windows Registry.

As in the prior example for services.py, the sequence of Windows events that we are looking for is: 5156 -> 4624 -> 5145 -> 4674.

The only difference is that we have added the condition ObjectName = 'RemoteRegistry'.

The detection logic described above is captured in the following Trovent MDR code snippet:

Rule-based Detection of Impacket Attacks Works! But…

What have we achieved? All of the above Impacket attacks can be detected successfully using the rule-based detection engine integrated in Trovent MDR. But, there are some drawbacks. As for any detection mechanism, false positives are always a challenge!

False Positives Resulting from Sparse Logs

Some of the tools available in the Impacket suite exhibit behaviour that only generates very few security-relevant events/logs. In other words, for some of the Impacket tools it is very difficult (or impossible) to define a chain of Windows events that can be used to reliably detect malicious behaviour without drowning in a flood of false positives.

For the examples above, this is typically not the case. However, other Impacket tools, such as getArch, smbclient or rdp_dump, do not generate sufficiently meaningful logs for detection purposes. Any detection rule written for these tools will be:

• far too generic

• based on underlying events that commonly occur in Windows infrastructure

As a result, such detection rules will flag countless events that very often not represent malicious behaviour.

Multiple Detection Rules Triggering for One Impacket Script

In order to identify which Impacket attack was performed we not only need to be sure that these event chains don’t occur naturally in non-malicious scenarios, we also need to have unique chains.

Otherwise, we encounter the problem that more than one detection rule triggers for only one Impacket attack. This dilemma can be perfectly illustrated with services.py and reg.py:

• They both cause the same sequence of Windows events (5156 -> 4624 -> 5145 -> 4674) with the only difference being that reg.py contains ObjectName = ‘RemoteRegistry' as well.

• Practically this means that only one rule triggers for an Impacket services.py attack, while both rules will trigger for an Impacket reg.py attack, meaning that we won’t be able to attribute the triggering of the respective rules to a specific attack.

If this were the only case in the illustrated example, we could probably argue that it isn’t all that important to be able to differentiate between these two attacks. However, this problem is compounded for tools where we are already lacking meaningful security-relevant logs to begin with (e.g. getArch or smbclient).

What’s Next? Improved Detection Based on Deep Tracing with YAETWi

In order to address the challenge of false positives resulting from naturally occurring (non-malicious!) event chains and multiple detection rules triggering for one attack type, we require deep tracing capabilities.

Using deep tracing, the behaviour of malicious processes can be analysed at a granular level, and consequently the chain of Windows events required for detection can be expanded and defined more precisely.

If you recall, in the first article in this series we explained:

• Why our Trovent Security Research Team developed its own ETW tracing tool YAETWi

• How YAETWi makes life easier for malware analysts and pentesting experts.

In the third and final part of this article series, we will examine how the precision of detection can be substantially improved by using this purpose-built tracing tool. Stay tuned!