Hi everyone! Today, we are happy to announce a new significant release of Impacket v0.9.23 by SecureAuth and the open source community, our collection of Python classes for working with network protocols and much more.
Impacket release 0.9.23 is available now! A couple of brand-new examples scripts, Python 3.9 support, library improvements, fresh features, and even a security fix for a path traversal vulnerability are some highlights of this release.
Let’s take a look at the new exciting features.
What’s New in Impacket Release v0.9.23?
Gold, Silver… and now Bronze
In December 2020, another Kerberos authentication vulnerability was made public, the Kerberos Bronze Bit Attack (CVE-2020-17049). Jake Karnes, Managing Consultant at NetSPI revealed his research after Microsoft released a patch to fix it. The Kerberos Bronze Bit attack was named in the spirit of the widely known Golden Ticket and Silver Ticket attacks and exists in the way the Key Distribution Center handles service tickets and determines whether or not they can be used for delegation.
Let’s start with some Kerberos fundamentals. In general terms, delegation refers to the ability of a service account to act on behalf of a user account to access resources with the access privileges of the latter. The most common example is a web application impersonating a user when it accesses a backend database and retrieves some data under the user’s authority.
Microsoft offers two types of delegation: without restrictions, known as Unconstrained Delegation, and restricted to only certain services, which comes in two flavors: Constrained Delegation and Resource-Based Constrained Delegation. The Kerberos protocol, by itself, doesn’t have the ability to restrict delegation to a specific group of services. For this reason, Microsoft implemented two extensions that allow achieving this behavior: Service for User to Self (S4U2self) and Service for User to Proxy (S4U2proxy).
The Bronze Bit Attack uses both protocols. First, it obtains a service ticket for a targeted user to a compromised service via S4U2self. Then, it tampers this service ticket modifying the forwardable flag. With this tampered ticket, it uses S4U2proxy to obtain a service ticket for the targeted user to the targeted service. Finally, with the last service ticket, the attacker can impersonate the targeted user.
So, surely you are wondering why is this possible? The answer: the forwardable flag is only protected by encrypting the service ticket with the first service’s password hash. If an attacker manages to compromise this service, it’s game over (unless you’re patched). They will be able to decrypt the ticket and flip the flag bit.
@jakekarnes42 used Impacket for the attack implementation and opened the pull request (PR) #1013 that added a new force-forwardable flag to getST.py. Thanks Jake, for using Impacket for this great implementation of the attack!
Command Execution on Steroids
As you all know, Impacket Release v0.9.23 comes with a bunch of examples tools that we can use right away for executing commands and spawn shells on remote endpoints. I like to call them the *exec.py scripts. Each of these scripts uses a particular method to achieve a different type of execution: full interactive shells, semi-interactive ones, or just run a single command. What all these have in common is that cmd.exe will be running on the host… at least until now.
Sometimes, some command processors are more useful than others in particular aspects. Imagine, you find yourself in a situation where you need to run PowerShell instead of cmd.exe with one of our tools. You have some options, for example, you can run each desired PS command passing it as a script argument, or maybe you can get a PowerShell reverse shell via a one-line command. However, there are scenarios where this is not always feasible due to network restrictions or some Endpoint detection and response (EDR) products. This led to the conclusion that it would be great to have the capability to run PS commands automated on the scripts.
With this in mind, @snovvcrash issued two PRs #1035 & #1037 in order to add a shell-type option that lets you use PowerShell as the command processor for the semi-interactive shell mode in dcomexec.py, smbexec.py, and wmiexec.py.
That’s not all. A couple of lines back, I mentioned EDRs as a roadblock in remote command execution. Some detecting mechanisms used by these products and blue teams look for cmd.exe execution and output streams redirection traces.
To avoid these detections, @aconite33 issued PR #605 (finally merged in PR #1088) to add a silentcommand option to run commands without spawn a cmd.exe console in atexec.py, dcomexec.py and wmiexec.py. This option doesn’t show any output, which means no share is written, and there are no redirects. This allows you to fly under the radar.
Thanks guys, for these great enhancements!
Making GPP Passwords Great Again
The year is 2012, the Group Policy Preferences are great (its passwords are AES-256 bit encrypted!), and Microsoft publishes the AES private key on MSDN… and Microsoft publishes the private key? Yes, that happened.
The Group Policy Preferences (GPP) is a collection of Group Policy extensions that deliver preference settings to domain-joined computers. For example, some of them were used to set administrator passwords across groups of workstations. Each GPP has an associated XML file where these credentials are stored. These files are present in the SYSVOL shared folder of a Windows Domain Controller and can be accessed by any authenticated users!
Putting the pieces together, it didn’t take long for researchers like Emilien Gauralt or Alexandre Herzog to write articles about the issue, and others like Chris Campbell, to release some tools to exploit this. Two years later, Microsoft released a patch that prevents administrators from putting password data into a GPP. However, these passwords are still present among us.
@podalirius and @ShutdownRepo issued PR #1064 to make GPP passwords great again. They added the example script Get-GPPPassword.py that decrypts GPP passwords remotely using streams for treating files instead of mounting shares. Additionally, they included an offline option in PR #1086 to parse and extract GPP passwords from a specified XML file.
Improving LDAP Relaying Attacks
With the new Impacket Release v0.9.23, we have improved LDAP relaying attacks. Let’s assume you are running ntlmrelayx.py and someone took the bait. An HTTP NTLM authentication attempt is triggered, and an LDAP relaying attack is launched. Time to escalate privileges in the domain!
ntlmrelayx.py has some special flags and supports a shell feature that allows attackers to interact with the LDAP service and perform different operations, including those to escalate privileges. However, there are some scenarios where these features are not enough to exploit an Active Directory ACL attack path successfully.
To facilitate AD exploitation from an LDAP relaying attack, @AdamCrosser added some new features to the LDAP Interactive Shell in PR #1076. These new commands allow, for example, enable or disable a user account, reset a user or computer account’s password, configure resource-based constrained delegation (RBCD) on a computer account object or read the Local Administrator Solution (LAPS) password associated with a given computer account, among other features.
If you want to learn more about how to exploit Active Directory ACL attack paths, read this fantastic article by Adam Crosser.
Fixing Path Traversal Vulnerabilities
Fixed multiple path traversal vulnerabilities in the smbComNtCreateAndX, findFirst2, and smb2Create functions of smbserver.py (CVE-2021-31800). The vulnerabilities were discovered and fixed by Omri Inbar (@omriinbar), AppSec Researcher at CheckMarx. More details in PR #1066.
Python 3.9 Support
As new versions of Python are released, we’ll try to be compatible with them as soon as possible. With the release of Python 3.9, we started to add compatibility to the core library and most of the example scripts. We want to also thank @meeuw and @cclauss for their contribution.
Impacket currently supports versions 2.7, 3.6, 3.7, 3.8, and 3.9 of Python. On the other hand, this will be the last release to fully support Python 2.7. As you all know, this version is no longer supported for more than a year. Our intention is to keep fixing bugs for this version; however, all new features or improvements will not be developed with backward compatibility.
Are you still needing more? Don’t worry, you can check out a fully detailed list of all new enhancements in the release notes here. Have fun!
Getting Impacket Release v0.9.23
If you want to know more about these examples and library functionality you can find it at the Impacket site or you can also get it grabbing the latest stable release directly from GitHub:
To install execute the following command from the directory where the Impacket’s distribution has been unpacked: python3 -m pip install . (for Python 3.x) or python2 -m pip install . (for Python 2.x). This will install the classes into the default Python modules path; note that you might need special permissions to write there.
As always, thanks a lot to all these contributors that make this library of Impacket Release v0.9.23 better every day (since the last version):
Feedback and PRs are very welcome. Contributions from the community are the mainstay of this open-source initiative!
If you have any doubts, questions, or suggestions, don’t hesitate to contact me at @0xdeaddood or drop us a few lines at email@example.com.
We hope you enjoy this new release. Happy hacking!