Abuse of Active Directory Certificate Services (AD CS) has become a staple of our internal network assessment methodology. In fact, I can’t recall an internal I’ve done in the past two or more years that didn’t feature ADCS abuse in some manner or another.
We can all agree that when AD CS abuse works as intended, it is fantastic. As Tinus Green stated in his BSides talk, AD CS abuse is the teleport scroll to the top of the mountain. It allows us to rapidly gain high-privileged access to the domain and, from there, can target more lucrative objectives.
During an internal assessment, I performed an NTLM relay and ended up owning the NT AUTHORITY\SYSTEM account of the Windows server. Looking at the users connected on the same server, I knew that a domain administrator account was connected. All I had to do to compromise the domain, was compromise the account. This could be achieved by dumping the memory of the LSASS process and collecting their credentials or Kerberos TGT’s. Seemed easy until I realised an EDR was installed on the system. Long story short, I ended up compromising the domain admin account without touching the LSASS process. To do so, I relied on an internal Windows mechanism called token manipulation.
The abuse of constrained delegation configuration, whereby a compromised domain user or computer account configured with constrained delegation can be leveraged to impersonate domain users to preconfigured trusted services, is a common attack path in Active Directory. For each trusted service, a unique service ticket is used, that explicitly corresponds to the service type for which it was requested. For example, to access Windows file shares, a CIFS ticket is required. Meanwhile, to leverage the WinRM protocol, a HTTP service ticket is required instead. Compromise of such service tickets aids in lateral movement and further compromise.
Using the Windows Remote Procedure Call (RPC) interface is an interesting concept when conssidering the fact that it allows you to call functions, over the network in a remote process. I wanted to better understand how RPC worked, and decided to build my own RPC interface to help with that. As a result, I wrote an RPC interface that will spawn a reverse shell given an IP address and a port. In this post I’ll show you how to do just that and what I learnt in a few sections:
Intro
In this blog post I want to show a simulation of a real-world Resource Based Constrained Delegation attack scenario that could be used to escalate privileges on an Active Directory domain.
I recently faced a network that had had several assessments done before. Luckily for me, before this engagement I had used some of my research time to understand more advanced Active Directory attack concepts. This blog post isn’t new and I used lots of existing tools to perform the attack. Worse, there are easier ways to do it as well. But, this assessment required different approaches and I wanted to show defenders and attackers that if you understand the concepts you can take more than one path.
Intro During an internal assessment, I came across monitoring software that had default credentials configured. This monitoring software allowed for the creation of sensors, but, none of which would allow for code execution or any other things that could compromise an underlying system. Turns out, it was a vulnerable version based on a publicly known CVE, but there was no public exploit code. Join me in this quest on building an exploit!
(If you’re new to this project, read the intro first)
For the past few months, I’ve been working on porting the USaBUSe stack from the custom hardware (AVR+ESP8266) to the Linux USB gadget stack. I wanted to make the techniques more accessible to people unfamiliar with embedded development, and I also wanted to take advantage of the variety of possibilities inherent in having a fully featured Linux environment to work in. I presented this work at HackCon in Norway.
Given the prevalence of Microsoft Active Directory domains as the primary means of managing large corporate networks both globally and in South Africa specifically; one of the common first goals of many internal penetration tests is to get Domain Administrator (DA) level access. To assist with this, a plethora of tools and techniques exist, from the initial “in” through to elevation of privilege and eventually extracting and cracking all domain credentials.
Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo – long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?