This is the first post discussing talks of the Active Directory Security Track of this year’s Troopers which took place last week in Heidelberg (like in the last nine years ;-). It featured, amongst others, a new track focused on Microsoft AD and its security properties & implications. This was the agenda.
The idea for this special track was born out of two considerations:
- we had noted there’s a lot of stuff going on in the space, both on the offense and on the defense side. And in pretty much every incident analysis & response project we were brought in recently Active Directory played a huge role…
- already in the early phase of the CfP several interesting submissions came in (maybe due to the fact that some big guns of the field had voiced very kind words in the past)… and creating an extra track simply relieved us from the burden to make a tough choice between those.
As this was the first Troopers since its creation where I didn’t have any official roles and out of personal interest (in a very distant past I happened to be the co-author of the first German book on Windows NT4 Security) I decided to spend the majority of conference day 2 in the AD track. In hindsight I’m tempted to say that the track was a huge success: brilliant talks, pretty much always a packed room, and quite good discussions after the talks. (yes, of course I’m biased, what makes you think that?).
In this post I will discuss two talks one of which happened in the “traditional” Defense track (albeit mostly because even the dedicated AD track did not provide enough space to accommodate all AD & Windows security related talks which the PC considered worthy of acceptance) and the other one was the opening talk of the new track. When I looked at the agenda, alas it turned out that Sean Metcalf‘s “Active Directory – The Journey” and Matt Graeber‘s “Trust” happened in parallel. Wtf! Tell me again it was a good idea & the right time to no longer be involved in the planning of the agenda 😉
With a heavy heart I decided to attend Matt’s talk as I have done some half-baked research (and projects) on trust myself a while ago and I was looking to learn more on the topic (which I did!). So let’s start with that one.
Matt Graeber: Subverting Trust in Windows
Video: here.
Accompanying whitepaper and blogpost by SpecterOps
Matt had given this talk before (like at DerbyCon 2017, at this point lots of kudos to Irongeek for his relentless work on providing those videos) but stated that he wanted the Troopers edition to be a bit more practical (hence “Hands-on Edition”) by including several demos.
He started by discussing typical questions in the context of software and trust. These include:
- Is the software from a reputable vendor?
- What is the intent of the software? [he added “does the software do what it claims to do?” which btw very much resembles the definition of “trust” in the RFC 4949 Internet Security Glossary, Version 2 which includes the following text: “that the system meets its specifications (i.e., the system does what it claims to do and does not perform unwanted functions)”]
- Can it be abused in any way?
- What is the protection status of signing keys?
- Is the certificate issuer reputable?
- Is the OS validating signer origin and code integrity properly? => focus on this one in the talk.
The intentions of code signing include:
- attestation of origin (=> place your trust in the protection of signing keys).
- attestation of integrity (“validate that files haven’t been tampered with”).
- but NOT attestation of intent.
Overall this leads to some naïve assumptions on the defenders’ side and related shortcomings like:
- if sth is signed (=> a tool reports the signature status of a binary as validated), it is trusted/considered trustworthy.
- security products may have non-robust signature verification methods.
- no warnings/enforcement might happen when known bad certificates are involved.
- many products/binaries aren’t even signed as of today.
To quickly test our assumptions as defenders he showed the following:
The main point here being that notepad.exe runs out of C:\Windows\Tasks (which is one of the few world-writable directories within the Windows folder) instead out of its default location (C:\Windows). Still one might be tempted just to note that the SignatureStatus is “Valid” and subsequently to go on.
He further provided some background on the way how signature verification is done on Windows where so-called Subject Interface Packages (SIPs) play a major role (some technical background on those can be found here, and this is some PoC Matt wrote to demonstrate subversion attacks on them). The SIP infrastructure is extensible by its very nature and usually relies on the WinVerifyTrust function from wintrust.dll. Another thing to know, and to keep in mind, is that there’s a several signature flavors and respective ways they’re stored (and potentially validated, e.g. the PowerShell command Get-AuthenticodeSignature might use [by default] a different approach than Sysinternals’ Sigcheck).
Demo 1: SIP Hijack Attack (starts at 29:06 in the video)
This can be summarized as follows:
- take own (potentially malicious) piece of code which, initially, doesn’t have a signature (“HelloWorld1.exe” in the demo).
- identify digital signature to be applied to it (e.g. from kernel32.dll, in the demo) and namely its thumbprint plus signature type (here: “catalog”).
- create a signature blob (from kernel32.dll’s signature and the associated catalog file) and add this to HelloWorld1.exe. in the course of the procedure adjust offset & size.
- at this point Get-AuthenticodeSignature will already properly identify the signature, but – not too surprisingly – a “Hash Mismatch” will be reported (I mean, you can’t just copy one’s file signature, add it to another file, and expect this to work, right? although Matt mentioned that there is malware actually doing/trying this).
- now modify the properties of the SIP in the Registry (hijack with a function that always returns “true”). this requires an elevated prompt (local admin).
- and, voilà, Get-AuthenticodeSignature now provides “Status: Valid”. Sigcheck will be fooled, too.
Demo 2: Certificate Cloning & Root CA Installation (starts at 46:56 in the video)
This attacks works as follows:
- the idea is to craft a code signing certificate chain that has look+feel of Microsoft cert chain.
- for this purpose take the cert chain from kernel32.dll, copy all three certs, clone them (but) with own key pairs & sign each one along the way. all this can be performed in non-admin context.
- evidently at the root of the new chain will be a self-signed certificate which, for now, is untrusted.
- sign HelloWorld2.exe with the leaf certificate and perform signature verification which, evidently, gives an error (“terminated in a root certificate which is not trusted”).
- now import the (cloned) root certificate into the root certificate store and all checks will just pass nicely.
The main point in the last step being that this can be done as a non-admin user (one just has to confirm a dialog popping up). This left many in the audience incl. myself stunned, and Matt had commented on this in his blogpost (see link above):
“Why non-admin users are able to trust root CA certificates is beyond my comprehension. That should not be permitted in any organization.”
In that post he also describes how to prevent this, by setting
Also, there is some discussion of authroot.stl which can help to determine which Microsoft-specific root certificates are trustworthy for code signing.
Matt concluded the talk with asking the audience “Has your trust in code signing changed?” and stated that he considers pretty much all existing tools as insufficient to fully determine the trustworthiness of (code) signatures.
Sean Metcalf: Active Directory Security. The Journey
I couldn’t see this live but I went through the slides and watched the video; on the basis of those sources I will provide the below summary. In any case some guys (incl. Florian Roth who also tweeted during the talk) told me it was a great presentation. Let me further state in the beginning that Sean is not only an excellent speaker but also a really nice guy. I had a good chat with him on Friday during the break of the Active Directory roundtable and he contributed quite actively to the discussion there. Many thanks for that, man!
Sean started by stating that in quite some aspects AD security has improved over the years. On the other hand still a number of things go wrong:
A tour of history through the Windows OS generations followed, with their respective security features and enhancements. He then highlighted the inherent/AD-related security issues of MS Exchange groups (this was also discussed in the day’s last talk on Attacking & Defending ESAE Forests which I’m going to cover in another post):
At this point Sean mentioned the ever lasting issue of permission requirements of 3rd party products which he nicely summarized in this slide:
The next section of the talk focused on Azure and here’s the main recommendations:
A very interesting part of the talk covered Kerberos, namely the risks related to Kerberos Unconstrained Delegation (for example see “Getting Domain Admin with Kerberos Unconstrained Delegation” by Nikhil Mittal and this Microsoft article on how to “Get rid of accounts that use Kerberos Unconstrained Delegation“).
Summary of mitigation advice:
Sean then discussed the complexity of accounts & rights, and the resulting avenues to compromise like
- GPO permissions
- AD Permissions
- Improper group nesting
- Over-permissioned accounts
- Service account access
- Kerberos Delegation
- Password Vaults
- Backup Process
The next part of his talk was titled “Microsoft Active Directory Security Guidance” (btw, here’s an awesome, just recently updated post on his blog on “Securing Domain Controllers to Improve Active Directory Security“) covering, amongst other, detection approaches:
After that he presented the well-known Tier Model, including a discussion of what’s missing:
- Removing local admin rights from users. [there was quite some debate on this during the roundtable on Friday as well, on ways how to handle/achieve this]
- Limiting broad system access for workstation admins & servers admins
- Limiting network access from any system to any system (host-based firewall with default block inbound rule).
- Practical guidance on achieving each tier with case studies.
- Service Account risks
These are the key recommendations which concluded his splendid talk:
That’s it for today, stay tuned for posts on other talks from the (not only) AD track.
Cheers, Enno
If you want to learn more about AD & Windows security here’s some options.
Public Trainings
At ERNW we have an experienced team of Active Directory security experts, some of them with more than a decade of experience in both attacking and protecting complex AD implementations. Those guys regularly give trainings where they share their knowledge.
These are the next public trainings (in German), through our partner HM Training Solutions:
On-site Trainings
If you want to perform an on-site training in your organization of any of the following #TR18 trainings (in English or in German) please contact info@ernw-insight.de:
Active Directory Security Summits
As we did in the past there will be two “Active Directory Security Summits” this year. Follow us on Twitter (see below) for the exact dates.
Please follow DirectoryRanger on Twitter for the latest news in the field, and for announcements of training and event dates.
AD Audit & Reporting Tool “Directory Ranger”
We’re currently developing a comprehensive new AD audit & reporting tool called Directory Ranger which will be released very soon. Product details can be found here. Please write an e-mail to customer@ernw-sectools.de for further information, a demo or a proof-of-concept implementation.