Discussion of environments susceptible to lateral movement through resource-based constrained delegation (RBCD) attacks, prompting me to take a deeper dive into the topic
Last month Fortalice open-sourced BOFHound, an offline BloodHound ingestor for raw ldapsearch results. Along with BOFHound, we released a companion tool for it, pyldapsearch, and submitted a pull request to TrustedSec's CS-Situational-Awareness-BOF modifying the ldapsearch BOF to include the nTSecurityDescriptor attribute. Adam Brown wrote a post accompanying the release, which covered much of the tool's background, including blue team strategies for detecting BloodHound useful and the red team's reversion to more manual LDAP querying techniques. This blog will serve as a follow-up to that post, covering some usage strategies for ldapsearch + BOFHound and going into the updates that were recently pushed to BOFHound in version 0.1.0.
BloodHound has helped offensive and defensive teams since then conduct efficient and thorough auditing of Active Directory environments. For a while, reviewing Active Directory environments without BloodHound became almost unimaginable, and certainly unattractive. As the tool has evolved and grown, it has become a staple of the offensive tester's toolkit while simultaneously becoming an increasingly desired detection point for defensive teams. Several detection strategies have surfaced over the past 7 years. This post will cover a few helpful detection strategies. Some you may know of, and others, maybe not. Then we'll wrap by introducing two new tools which aim to give red teams a chance at avoiding detection when necessary.
Back in when I was getting started as a junior pentester, I vividly remember reading @byt3bl33d3r's 2017 post: Practical guide to NTLM Relaying in 2017 (A.K.A getting a foothold in under 5 minutes). I still recommend checking this out if you haven't already - it will cover the basics of NTLM relaying and background on some of the confusing pieces ([Net]NTLMv1/2 anyone?) that there's no need for me to repeat here. There's also a plethora of other great NTLM relay blogs and resources that I'll try to link to throughout this post, while I attempt to touch on the ever growing library of NTLM relay uses after 2021 introduced several new relay vectors.
ADCS has been a treasure trove for recent offensive operations while organizations are still catching up to the research released by Will Schroeder and Lee Christensen back in June. Amazingly, enough escalation vectors were dropped that 5 months later I still haven't found time to test and explore every one of them (suppose that means I'm still catching up too). Luckily, an ESC4 scenario prompted some digging into abusing ACL permissions to create vulnerable template states.
Active Directory Certificates and PKINIT are hot topics these days and our operators at Fortalice have been doing their best to stay on top of the new research and tools. My previous blog touched on PyWhisker and referenced one of its resources available on https://thehacker.recipes. While reading through the documentation there, a note near the bottom caught my eye, which stated: User objects can't edit their own msDS-KeyCredentialLink attribute while computer objects can.
On a recent red team engagement, our team was tasked with focusing on Active Directory Certificate Services (ADCS) exploitation. The objective was to identify certificate template misconfigurations and potentially achieve privilege escalation by abusing them. The concepts and attacks used were based around the work and whitepaper by Will Shroeder (@harmj0y) and Lee Christensen (@tifkin_).
Domain fronting is a generic technique based on HTTPS that allows an actor to hide the true destination of a communication from network equipment in the path. While domain fronting has been used in offensive engagements for several years now, the number of frontable cloud services continues to dwindle. Today, Fortalice is publicly adding another service to that list: Azure Front Door.