Brace for Impacket!

Detecting a Red Team (and Threat Actor) Favorite

Author Micah Babinski

Introduction and Objectives

In this article we’ll take on the mighty Impacket, an open-source Python library for conducting network-based attacks. This is not some obscure, boutique offensive tool; as the folks at RedCanary showed in their wonderful 2023 Threat Detection Report, Impacket was the second most prevalent threat that they observed last year, affecting more than one in twenty of their customers!

Impacket is popular with both legitimate penetration testers and Red Teamers, as well as cybercriminals and their counterparts in foreign adversary government hacking teams. I first heard about Impacket way back in 2020 while watching TheCyberMentor’s iconic “Zero to Hero Pentesting” series, which is still worth checking out!

My objectives for this article are:

1. 👨‍🏫 Understand Impacket basics, and examine what we know about how Impacket tools are used by malign actors.

2. 📋 Review the tools that make up the Impacket suite by showing a couple of well-known Impacket tools in action.

3. 🔭 Explore some of the lesser-known Impacket tools and how we might detect them (hopefully without a ton of false positives).

4. ✍️ Along the way, document some easily-shareable Sigma rules so that you can try these detection concepts out in your environment.

Quick Disclaimer

I am not claiming this to be the first nor the best article about Impacket detection — far from it! As stated above, my primary objective is education (both yours and mine) about Impacket, it’s event log and network artifacts, and how we can identify use of Impacket, responding before harm befalls our network. As always, I’ll provide plenty of links, mentions, and references to my favorite resources on the topic, so that you can explore what I consider to be the highest-quality, foundational resources for understanding and detecting Impacket.

Impacket 101

So, what exactly is Impacket, and why is it so popular? A good starting point is the GitHub repo that houses the project:

According to the project main page:

Impacket is a collection of Python classes for working with network protocols. Impacket is focused on providing low-level programmatic access to the packets and for some protocols (e.g. SMB1–3 and MSRPC) the protocol implementation itself. Packets can be constructed from scratch, as well as parsed from raw data, and the object-oriented API makes it simple to work with deep hierarchies of protocols. The library provides a set of tools as examples of what can be done within the context of this library.

Hmmm… 🤔 Respectfully, this is not the most helpful description, at least from my point of view! For me, a far more helpful resources for gaining a quick, high-level understanding of Impacket is this page, which offers summaries of each of the many Impacket CLI-style Python script modules contained within the project’s examples folder. These “examples” include tools for execution, Kerberos ticket manipulation, credential access, adversary-in-the-middle style relay attacks, and more. Truly, Impacket’s examples folder contains tools covering a veritable potpourri of the Mitre ATT&CK Framework!

Here’s a key point for defenders: While Impacket is often advertised as offering low-level programmatic access to network protocols, it is most commonly used by threat actors and pen testers in it’s higher-level module/scripts form — at least according to the hacking guides and threat intel reports I’ve found that include Impacket. Another way of saying this is, while Impacket offers enterprising attackers to build their own race car using it’s own granular set of nuts and bolts, most users simply choose one of the default options from the examples folder. Please drop a comment if you are aware of the documented use of Impacket base classes, which differ from the well-known example scripts!

Use of Impacket by Threat Actors

If Impacket is a well-loved tool among legitimate red teamers and pen testers, then what do we know about Impacket use by our adversaries, the malicious threat actors who keep us up at night (or keep us employed, depending on how you look at it 😏)? Over the course of a very brief web search I found numerous authoritative examples of criminal or espionage organizations using Impacket, including many from the past six months. A couple of notable examples include:

• Unnamed criminals using Impacket in an effort to deliver Ursnif malware (The DFIRReport, January 2023)

• Unnamed APT targeting the defense industry using Impacket (CISA, October 2022)

• ViceSociety criminal organization using Impacket to deliver ransomware to education organizations (Microsoft, October 2022)

Understanding Impacket’s Capabilities

It’s worth noting that all of these threat intel reports (as well as most others I found) only mention Impacket tools which fall within the “Execution” category of Impacket’s example script tools. These include wmiexec.py, atexec.py, and smbexec.py. I’m not sure exactly why these particular tools get the majority of the threat intel “love” but it could be because the other tools are harder to detect, less relevant to threat actors’ overall goals, or simply weren’t as interesting to the authors of the blogs and reports I read.

Let’s refer back to the helpful Impacket page from SecureAuth below:

We can see that Impacket contains lots of tools that go beyond simply executing commands on a remote host. Kerberos attacks, relay attacks, credential theft, MSSQL enumeration, and others also fall within Impacket’s scope. Just as the blogs and threat intel reports I found tend to focus on execution tools like wmiexec, the available detection rules and resources (one of my favorites from 13 Cubed can be found here) I found covering Impacket also seem to focus on detecting these tools. Makes sense, right?

So, to try to keep this blog post educational without retreading too much well-covered ground, I’ll next demonstrate some of Impacket’s better-known tools, and then we’ll take a crack at detecting some of Impacket’s lesser-documented tools! Let’s do this! 🏁🏁🏁

Impacket Does Remote Execution

Impacket can be run either on a remote “attacker” machine, such as one running Kali Linux, or on a local host in your lab if you don’t want to run Kali alongside your Windows lab VMs. Bear in mind that Impacket’s tools are heavily targeted towards an Active Directory environment, so for the best results, you should target a system running as part of an AD domain.

wmiexec.py

Here’s a straightforward example, in this case using wmiexec.py to execute the whoami command from a Kali machine, targeting my Windows host at 192.168.56.102:

Then, using a Splunk search to list processes created on my target host, I can see a burst of cmd.exe activity spawned by the WMI Script Provider Host (WmiPrvSE.exe):

Note the command line strings, whereby it appears that the result is directed to an admin share. These command lines are very specific to Impacket and considered one of the best ways to detect “off the shelf” Impacket usage. This helpful and robust Sigma rule uses these command line elements in tandem with other indicators to detect wmiexec and several of it’s execution-related Impacket cousins:

We can test the rule in our lab by first saving it, then converting it using sigma-cli:

…and then running a slightly adapted version of the resulting query in our lab’s Splunk search app:

Sure enough, all of the recent hammering on wmiexec.py in my lab is picked up by the search!

atexec.py

Let’s try out another interesting execution-focused Impacket tool: atexec. This tool uses the deprecated at.exe to create a scheduled task which runs the user-supplied command, runs the task, then immediately deletes the task. Sneaky!

Interestingly, when I ran atexec.py in my lab against the DC, the Sigma rule referenced earlier (HackTool — Potential Impacket Lateral Movement Activity) did not detect this activity. This may be because of deficiencies in the audit settings in my lab; however, I was able to create a set of rules to reliably detect atexec.py activity using windows event log process creation events (event 4688), sysmon file creation events, sysmon registry events, and the scheduled task log:

Below is an example Sigma rule which will reliably detect atexec.py usage using event 4688, with command line auditing catching the presence of a suspicious .tmp file stored in a temp folder, which contains the output of the attacker command:

title: Impacket AtExec Process Activity
id: ceccdcd7-ab57-407c-bd8f-78b2427eb283
status: experimental
description: Detect Atexec.py (Impacket) usage to send command output to attacker.
references:
    - https://www.13cubed.com/downloads/impacket_exec_commands_cheat_sheet.pdf
    - https://www.hackingarticles.in/impacket-guide-smb-msrpc/
author: Micah Babinski
date: 2023/01/08
tags:
    - attack.s0357
    - attack.execution
    - attack.t1053
    - attack.t1053.002
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4688
        NewProcessName|endswith: '\cmd.exe'
        CommandLine|contains|all|windash:
            - 'cmd.exe'
            - '/c'
            - 2>&1
        CommandLine|re: '^.*Temp\\[A-Za-z]{8}\.tmp.*$'
    condition: selection
falsepositives:
    - Unknown
level: high

Impacket’s Other Execution-Related Tools

I encourage you to explore Impacket’s other execution-focused tools (psexec.py, dcomexec.py, and smbexec.py), both with an eye towards the telemetry generated by running the tools, and with the desire to understand the underlying mechanics of how the tools operate. For instance, I found psexec.py to be an interesting technique for abusing Windows services, and it helped me better understand how service-related data is captured both within the Windows System and Security logs.

Impacket Steals Credentials

Now that we have an essential Impacket execution tool under our belt, let’s move on to some of the deeper cuts: the Impacket utilities designed for more subtle, incremental attacks, starting with credential theft.

secretsdump.py

Secretsdump.py uses a grab bag of techniques to retrieve credential secrets from a target, including cached credentials from the registry, NTDS.DIT, and Kerberos keys. All of this is achieved with a very light footprint on the target host, because no malware is actually running there. A network monitoring solution like Zeek is well-suited to the task, however! Zeek can monitor the Distributed Computing Environment/Remote Procedure Call (DCE/RPC) activity in your network, which will record a fairly-distinct trail of activity left by secretsdump.py.

I won’t pretend to understand this stuff all that well (if you are knowledgeable please recommend some good reading on this topic in the comments!), but from what I read, the Microsoft Directory Replication Service (DRSUAPI) uses DCE/RPC to implement replication between domain controllers. Secretsdump.py works in part by abusing this service endpoint, requesting user credentials using the GetNCChanges method. While this activity may include legitimate domain controller replication, it also provides a network-based detection concept for secretsdump.py.

title: Possible Impacket Secretsdump.py Activity
id: 8d1476b7-0f57-43a4-b56b-50bfab66943d
status: experimental
description: Detects attempts to retrieve/dump credentials using the DL_DRSGetNCChanges() method.
references:
    - https://www.extrahop.com/company/blog/2021/dcsync-definition-and-protection/
    - https://www.secureauth.com/labs/open-source-tools/impacket/
    - https://wiki.samba.org/index.php/DRSUAPI
    - https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/9b4bfb44-6656-4404-bcc8-dc88111658b3
author: Micah Babinski
date: 2023/04/13
tags:
    - attack.s0357
    - attack.credential_access
    - attack.t1003
    - attack.t1003.003
    - attack.t1003.006
logsource:
    product: zeek
    service: dce_rpc
detection:
    selection:
        operation: DRSGetNCChanges
        endpoint: drsuapi
        id.resp_p: 49666
        named_pipe: '49666'
    condition: selection
fields:
    - id.orig_h
falsepositives:
    - This may detect legitimate Active Directory domain control replication/sync activity (perhaps filter by inbound/outbound IP addresses of your known DCs)
level: low

If you are new to Zeek, I highly recommend checking it out! I gained familiarity using this tutorial series from Kevin Thomas:

Impacket Targets Kerberos

GetUserSPNs.py

GetUserSPNs.py targets the Kerberos network authentication mechanism by reporting Service Principal Names (SPNs) associated with normal user accounts. These can in turn then be used to conduct Kerberoasting, an attack where the Ticket-Granting Ticket is used to obtain a vulnerable Ticket-Granting Service (TGS) ticket that can be brute forced.

In the example below, I’ve used GetUserSPNs.py to retrieve the TGS for my vagrant user, whom I’ve artificially added an SPN to using the setspn Windows command.

As this tool requests the ticket using the vulnerable RC4 HMAC encryption type (the one that can be brute forced), we have a couple of opportunities to detect this. One is to check out Windows event ID 4769, which records Kerberos service ticket requests, and filter for the vulnerable encryption type, stored as 0x7 in the log:

Luckily, Florian Roth has this Sigma rule which can reliably detect this activity:

On the network side, Zeek’s kerberos.log file can detect the transfer of the vulnerable TGS request from the attacker to the target DC. This provides another vantage point from which defenders can detect these credential access attempts:

A rule to detect this activity by monitoring Zeek data may look like this:

title: Possible Impacket GetUserSPNs Activity
id: 73822599-97d8-411f-8ee1-e57ecac118c7
status: experimental
description: Detects attempts to create vulnerable Kerberos Ticket Granting Service (TGS) tickets using the RC4-HMAC encryption type.
references:
    - https://www.blackhillsinfosec.com/impacket-defense-basics-with-an-azure-lab/
    - https://github.com/fortra/impacket/blob/impacket_0_10_0/examples/GetUserSPNs.py
author: Micah Babinski
date: 2023/04/13
tags:
    - attack.s0357
    - attack.credential_access
    - attack.t1558
    - attack.t1558.003
logsource:
    product: zeek
    service: kerberos
detection:
    selection:
        cipher: 'rc4-hmac'
        request_type: 'TGS'
        success: true
    condition: selection
fields:
    - id.orig_h
    - client
    - service
falsepositives:
    - Unknown
level: low

Impacket Can Upload Files to Vulnerable Systems

smbclient.py

One of the coolest capabilities that Impacket offers is smbclient.py, which gives an attacker the ability to list, modify, create, upload, and download files on a remote system. This capability maps to several Mitre ATT&CK techniques, including Lateral Tool Transfer, Exfiltration Over Alternative Protocol, and File and Directory Discovery. The options for running smbclient.py are shown below:

After entering the interactive SMB session, you can list the various command options available to you by typing “help.” In my lab, I emulated a process of using the SMB client to perform lateral tool transfer. After entering the SMB session using a compromised user (mcorrigan), I selected the C$ share, created a directory called “NothingToSeeHere,” and uploaded an empty file creatively called “evil.exe”.

Switching over the file explorer on my target machine, I can see that the evil.exe file is now present in the new directory:

Let’s look and see what evidence has been left in our logs. From Sysmon event 11 (file event), I can see that the .exe file was created, although the user tagged in the log event is not mcorrigan, it’s NT AUTHORITY\SYSTEM:

Also, not that the “Image” field in the event shown above shows a value of “System” — this is normally the process executable used to create the file. I wondered what would happen with the following SPL search:

index=sysmon EventCode=11 Image=System TargetFilename="*.exe" User="NT AUTHORITY\\SYSTEM"
| table _time, ComputerName, User, Image, TargetFilename

Here I am looking for files created with an .exe extension, an image value of “System” and the user of “NT Authority\System”. I returned four records, and found that each one represented Impacket activity in my lab:

Of course, your mileage may vary, and the activity shown here might be normal in a given environment! Here’s the rule in Sigma format if you want to try it out, either as an alert or starting point for threat hunting:

title: Suspicious Exe File Event With System Image
id: 2ace112a-1717-4648-b0f8-51796f36c58e
status: experimental
description: Detects potential SMB file creation activity associated with Impacket smbclient.py.
references:
    - https://github.com/fortra/impacket/blob/impacket_0_10_0/examples/smbclient.py
author: Micah Babinski
date: 2023/04/16
tags:
    - attack.lateral_movement
    - attack.t1105
logsource:
    product: windows
    category: file_event
detection:
    selection:
        TargetFilename|endswith: '.exe'
        Image: System
        User: 'NT Authority\Sytem'
    condition: selection
falsepositives:
    - Unknown
level: low

The logon event for the user mcorrigan is also suspect, as it uses Logon Type 3 (network logon), and the vulnerable authentication package NTLM. In my lab, the Source Workstation Address is a private IP address, but in a real detection scenario, alerting on events matching these properties originating from public IP addresses would be a wise choice. You can adapt the following Sigma rule to accomplish this!

Conclusion

Thus concludes our (slightly haphazard) tour of Impacket capabilities. I hope you’ve learned some Impacket basics and also gained some insights into the non-execution capabilities of the library. I certainly have!

To be honest, I really struggled with the analysis and documentation of Impacket. This experience has revealed to me that I have a lot still to learn about the interplay network-based attacks and underlying Windows protocols. Throughout the writing, a familiar and frustrating pattern would emerge — I would begin to explore an Impacket module, test it in the lab, write a little introductory paragraph, and then go to find evidence of the activity in my Splunk instance, only to find that I could not find anything distinguishable!

Besides providing a pathway for further learning, this experience shows me why Impacket is such a useful and popular tool among legitimate pen testers and threat actors. If you have some thoughts on ways to expand my network-based detection capabilities, please let me know in the comments. I welcome feedback on my work in any form.

For those who may be interested, here are the Impacket rules which I wrote for this piece:

And as always, happy analyzing! 🧐

About the Author: Micah Babinski is a security professional living in Portland, OR, working as a threat detection engineer for Zyston, LLC. After 10 years working in the Geographic Information Systems (GIS) profession, Micah pivoted to security in 2020, pursuing an interest that developed since sitting next to and befriending the InfoSec team when he worked for the City of Portland. Micah's interests in security are threat detection, incident response, automation, system integration, and interoperability. Micah believes that personal connections, between and among security professionals and the users and customers they serve, is the key to success. Besides cybersecurity, Micah enjoys playing Scottish bagpipes, traveling, baking, and going on back country adventures in the Pacific Northwest and beyond.