Coming up this week on Breaking Badness. Today we discuss: How a Threat Actor Led a Charmed Persistence , What Slipped Through the Netlogon, and our fun game, two truths and a lie.
Here are a few highlights from each article we discussed:
How a Threat Actor Led a Charmed Persistence
- They gained initial access into the network using Office 365 accounts and domain administrator accounts to pivot. This is actually a great first spot to be in as a threat actor. Normally you have to escalate your privileges a bit before you can reach administrator access so they must’ve worked things well in their favor to get that initial access.
- They do not know how they obtained credentials at this time, but it had to be a phishing or spearphishing attack or some easy to guess credentials. Really the only way to get those here unless they were already on the system.
- After gaining access, they began downloading and exfiltrating sensitive files. So they also did the usual and enumerated accounts and what not in the active directory. They did all this through a reverse SOCKS proxy which allowed them to connect to a VPS to funnel all this data into.
- They did establish persistence. This is a typical strategy of creating accounts for themselves and what not after taking over the domain administrator.
- Once they were logged in as admins, they dropped a unique multistage malware. I have not yet been able to get a copy of the sample, but the analysis they show from CISA the malware had three stages, the dropper there, the next stage which decrypted the file, and then the final bit which is then used to create the tunnel and communicate with C2.
- In terms of recommendations from CISA, they covered the usual stuff like having an enterprise firewall, monitoring for exfiltration, etc.
What Slipped Through the Netlogon
- This vulnerability allows for instant escalation to Domain Admin without credentials.
- In terms of the original vulnerability, It’s possible to forge an authentication token for specific Netlogon functionality, and call a function to reset the password.
- This is cause of a flaw in the crypto authentication scheme used by Netlogon, and the flaw lets the attacker spoof any machine including the Domain Controller itself.
- Therefore, an attacker can send a special string of zeros in Netlogon messages. At the heart of all this is a failure in Microsoft’s implementation of AES-CFB8 where they failed to use unique, random salts for these Netlogon messages.
- All you have to have is TCP connectivity to the Domain Controller. Attackers are pretty capable of getting this.
- Exploit code is available, repeat, is available.
- The DHS issued a directive to patch all the stuff by 9/21.
- The straightforward way of exploiting the vulnerability: resetting the password, could have some drawbacks for the attacker.
- The thing is, that could break stuff in the Domain Controller and the broader environment.
- This is because resetting the password puts the DC in an inconsistent state. Its own original encrypted password is still in the registry and in lsass.exe.
- Most attackers probably would want to be more stealthy.
- Drik found a different way to exploit the vulnerability which is more elegant (for the attacker, anyway).
- It’s somewhat complex, but we’ll put the link to his blog post in the show notes. But NTLM is a key to this attack.
- The tl:dr is that it makes use of NTLM relaying. This takes advantage of NTLMs design and allows an attacker to stand up a server to which victims authenticate, then the attacker relays the authentication messages to the real server.
- One way of achieving this was through something called the “printer bug,” which is kind of a feature but it’s got some…issues. The main one for our purposes is that an attacker can trigger NTLM authentication of any machine that has the spoolservice enabled.
- The aim was to get the relayed connection to directly authenticate to the RPC endpoint of the DRSUAPI (directory replication service) protocol.
- This is interesting because while most machine accounts don’t have high privileges, the ones using this API—domain controller accounts—do.
- Dirk had to do a bunch of tweaking to get this relaying to work, having to do with setting the right flags in the challenge-response, passing integrity checks, that sort of thing, to keep it from puking. But he succeeded.
- Basically here are the conditions that would allow the attack to succeed, assuming the Domain Controller has not been patched and also assuming the attacker has access to some machine on the same local segment as the Domain Controller.
- There should be at least 2 Domain Controllers in the domain, since relaying back to the same Domain Controller does not work.
- An account is needed to trigger the printer bug (you can also use a POC in .NET that uses SSO if you have access to a Domain Joined box).
- The Print Spooler service should be running on the Domain Controller.
- You should be able to run Python and bind to port 445 for an incoming SMB connection which can be tricky on Windows, but clearly not impossible.
- Dirk’s got POC code and PCAPs of the attack on his Github.
Two Truths and a Lie
Introducing our newest segment on Breaking Badness. We are going to play a game you are all likely familiar with called two truths and a lie, with a fun twist. Each week, one us with come prepared with three article titles, two of which are real, and one is, you guessed it, A LIE.
You’ll have to tune in to find out!
Current Scoreboard
This Week’s Hoodie/Goodie Scale
How a Threat Actor Led a Charmed Persistence
[Chad]: 5/10 Hoodies
[Tim]: 6/10 Hoodies
What Slipped Through the Netlogon
[Chad]: 10/10 Hoodies
[Tim]: 10/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included on our podcast recap. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!
