TrustedSec - The Tale of the Lost, but not Forgotten, Undocumented NetSync: Part 1
They say, “Everything old is new again.”
Or, if you are a Game of Thrones fan, “What is dead may never die.”
For me, however, a mentor once told me, “Everyone is going forward. I’m going backward.”
Enter NetSync…
I find Twitter to be a good source for InfoSec tactics, techniques, and procedures (TTPs). Anytime I see a tweet published by Benjamin Delpy (@gentilkiwi), the father of Mimikatz and Keko, I am quick to capture the contents into my workflow. However, one tweet in April 2019 about a little-documented feature within Mimikatz called NetSync caught me by surprise. What is also interesting is that in the thread of this tweet, Delpy referenced a previous tweet back in 2016. I tried looking at the wiki page on the Mimikatz GitHub for more information on NetSync, but I had no luck finding any information beyond the two tweets. I also came across Delpy’s 2017 BlueHat IL talk, but beyond these three resources much of what else I found was documented incorrectly or just said that the module existed.
Finally, I came across an amazing slide deck by Teymur Kheirhabarov called Hunting for Credentials Dumping in Windows Environment. On top of his well laid-out presentation and in-depth research for both offensive and defensive purposes, there were two slides devoted to NetSync. This served as an amazing starting point, but of course with my inquisitive nature, always having a million questions, I needed to do the deep-dive myself (one of the best ways I learn). Having said that, this blog post will attempt to answer the following questions over a two-part series:
Part 1:
- What is NetSync and How Does it Differ from DCSync?
- How is NetSync Executed?
- What is Needed to Perform This Attack?
- What are Some Paths of Attack?
- What are Some Early Indicators to Detect NetSync at the Host-based Level?
- What are Some Possible Controls to Deter NetSync?
1.1 What is NetSync and How Does it Differ from DCSync?
Machine account hashes are often overlooked by both red and blue teams and there is more to Mimikatz than just sekurlsa::logonpasswords. Within the Mimikatz lsadump module, there is a feature called NetSync.
NetSync allows an attacker to take the NTLM hash of a Domain Controller (DC) machine account (‘usually’ identified by ending in ‘$’) and using it to obtain the NTLM machine account hash of another machine account through impersonation (similar to, but different from, DCSync). Where DCSync can obtain user account passwords, NetSync is limited to machine accounts. The other main differentiator between DCSync and NetSync is that DCSync will make use of Microsoft’s Directory Replication Service (DRS) Remote Protocol, whereas NetSync uses the older Netlogon Remote Protocol (MS-NRPC). Delpy puts it best in explaining the difference between the two attacks, “Some will say it’s a castrated DCSync, some will say it’s enough to play with silver tickets ;).” But first, a bit more on what is happening under the hood of this whole process. Feel free to skip ahead to the “What is needed to perform this attack” section if you are not interested.
1.2 How is NetSync Executed?
1.2.1 A Quick Background on Machine Hashes
Historically, machine account passwords are often ignored during a penetration test. They would be captured via Responder in the form of a NetNTLM hash and are not ‘typically crackable’ offline via a password brute-force to recover the plaintext password (more on this below). Additionally, these hashes are not ‘passable.’ From a blue team perspective, machine accounts themselves maybe filtered out in detection queries for being too noisy. Intrusion Analysis (IA) or Incident Response (IR) analysts may also believe the suspicious activity is normal or should be ‘disregarded’ since the source user is a computer account (‘usually’ denoted by ending in a ‘$’) and not attributable to an actual ‘user.’ Thus, forgetting that machine accounts can move laterally, Kerberoast, or be used by tools like BloodHound. This leads machine accounts to be overlooked by both red and blue teams. For all of these reasons, we should not ignore the use of machine account hashes.
In Active Directory (AD) there are two main objects, users and computers. As users have passwords, and as such their respective hashes, so do computer objects too. According to Sean Metcalf (@Pyrotek3), “The computer account’s password is used to establish a secure session with an AD Domain Controller, which is used for user authentication (as well as LocalSystem and NetworkService credentials). The computer stores the machine account password in the registry location:
HKLM\SECURITY\Policy\Secrets\$machine.ACC
[at the individual computer level].” In an AD environment, passwords are stored in the ntds.dit file/database.
By default, a machine account password rotates every 30 days and is initiated by the machine. However, this attribute can be changed in AD to any period between 1 and 999 days (more on this in Part 2). It is important to note that these passwords do not expire in AD and are exempt from the corporate domain policy. Lastly, machine hashes are 120 characters, which makes them difficult to crack if stronger encryption methods are employed (e.g., NTLMv2).
One last thing to note about machine account hashes in a Windows environment is from Ned Pyle and Manish Singh:
It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.
So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.
This will be important to keep in mind when we discuss controls to deter NetSync. With a brief overview on machine account hashes, we can now examine the MS-NRPC protocol, which NetSync leverages.
1.2.2 Breaking Down NetSync and MS-NRPC
As we will see through the next sections, NetSync can really be broken down in three (3) protocols: SMB2, DCERPC and MS-NRPC.
NetSync itself lives in the MS-NRPC (Netlogon remote protocol) interface, which is used for user and machine authentication on domain-based networks. The following slides will break down MS-NRPC as it relates to NetSync, and by following the Mimikatz code:
In an accompanying blog post, Wes Lambert (@therealwlambert) steps through each NetServer Request and Response communication call to provide an understanding of what exactly is taking place at the network level. The above represents my understanding and is a general overview of the communication process NetSync uses. Lambert shows the breakdown at the packet level more in depth.
With some background now on machine account hashes and the underlying MS-NRPC, we now have a basic understanding of what is happening when NetSync is executed. Thank you to Carlos Perez, and his Mimikatz course, and Wes Lambert for help with the above protocol diagram breakdowns.
1.3 What is Needed to Perform the NetSync Attack?
At the time of publishing this post, there is no other tool that fully weaponizes NetSync behavior other than pure stock Mimikatz. While the necessary NetServer functions have been fully implemented in Impacket, what is not implemented is the full NetSync functionality into secretsdump.py (shout out to Alberto Solino [@agsolino] for taking the time, breaking down nrpc.py and explaining this to me 
). As such, we will use Mimikatz 2.2.0 (x64) to execute the attack.
In order to execute NetSync, an attacker needs the following:
- The FQDN of a domain controller (/dc)
- The machine account name of the domain controller (/user)
- The NTLM hash of the domain controller (/ntlm)
- The machine account name of the target (/account)
With all four (4) pieces of information, we can execute the attack:
Notice that both the NTLM and NTLM-1 hashes of our target victims (WEF$ and WIN$10) were returned.
1.4 What are Some Paths of Attack?
Next, I will provide both the offensive and defensive operators with visual representations of attack paths for when NetSync could be executed and how the DC$ machine hash could be obtained. During the DerbyCon 2018 presentation “The Unintended Risks of Trusting Active Directory” by Lee Christensen, Will Schroeder, and Matt Nelson, I realized the full power of NetSync could be leveraged, weaponized, and applied to viable attack paths in an attempt to capture the NTLM hash of a DC. In their talk, they introduced both the ‘printer bug’ and the Discretionary ACL Modification Project (DAMP).
1.4.1 Using the Print Spooler Service (aka the ‘Printer Bug’)
The printer service (or ‘spooler’ service, identified by its running service ‘spoolss’), is enabled by default and is used to assist in printing operations. The (RpcRemoteFindFirstPrinterChangeNotification(Ex)) method is also exposed via remote procedure call (RPC), and “[REMOTESERVER] allows for sending a notification when a new print job is created.”
The spooler service runs as the Windows SYSTEM account, to which any domain user can authenticate and coerce if the print spooler service is enabled. Remotely invoking this method will force an authentication attempt to the target ‘printer’ as the SYSTEM account. The machine’s hash can then be captured, to an attacker-controlled endpoint, and used in further attacks, such as NetSync, if it can be downgraded from NetNTLMv2 to NetNTLMv1 with Responder and ultimately cracked offline.
It is important to note that any domain user can conduct this attack—a Domain Admin account (thanos) in this example lab, just happened to be used.
1.4.2 Using Remote Machine Hash Extraction
In this scenario, our attacker has compromised a member of the Domain Admins Group. Using the DAMP toolkit, we can enable and access the Remote Registry service to implement a backdoor to obtain the machine hash of a DC. Below, I used a Domain Admins member account and provided the trustee to a regular user who is not a member of any other privileged group.
After obtaining the DC$ hash, we can then execute NetSync. It should be noted that the purpose of Christensen, Schroeder, and Nelson’s work with the DAMP project was to prove that “membership in a system’s local administrator’s group isn’t what ultimately matters. What actually matters is what local/domain groups have access to specific remote resources based on the host service security descriptors.”
As Schroeder told me, “You have to have admin access on the target when you’re implementing the backdoor, but the trustee/principal can be the security identifier of any user/group in the domain.” Again, the purpose of using DAMP in this ‘attack path’ was to show another possible avenue to obtain a DC$ hash in order to NetSync. Thank you to Schroeder for always talking the time to answer my many questions on DAMP.
In part 2, we will examine the detection components as well as possible mitigatings.
The post The Tale of the Lost, but not Forgotten, Undocumented NetSync: Part 1 appeared first on TrustedSec.
from TrustedSec https://www.trustedsec.com/blog/the-tale-of-the-lost-but-not-forgotten-undocumented-netsync-part-1/
Comments
Post a Comment