All right.
Can everybody hear me?
Awesome.
Okay.
So we got a couple people still funneling in here, but I'm going to get kicked off and yeah.
Welcome to Weird Ways to DA.
Nicholas Anastasi.
Talked here at CypherCon for a couple years now.
Really excited to be here.
This is the quick about me slide.
I used to do like a bunch of bullet points and I just kind of mashed up everything I like into one.
So I hope you guys recognize something.
But yeah, yeah.
Outside of that, I work for Sprocket Security, a continuous penetration testing company based here in Madison.
Been with Sprocket for about six years.
Title right now is director of technical operations.
Do a lot of penetration testing.
Love hacking.
Obsessed with it.
Probably like a lot of you.
So yeah.
Today, right, we're going to be talking about some interesting paths to domain administrator.
Anybody who's not familiar, DA, domain administrator, is just a full control over an internal active directory network.
So you can assume either you don't have any credentials, you have credentials that were provided to you, that sort of thing.
Just base user credentials.
And you're able to escalate your privileges all the way to the point that you're able to act on behalf of an administrator inside of an internal network and take things over, execute code on machines, modify things, right?
It's kind of the crown jewels.
There's something that comes along with DA.
We like to call it the hacker high.
It's the dopamine hit that you get when you actually get those admin privileges.
And so a lot of these stories, right, are kind of based on the best experiences I've had with that.
We're going to start simple.
Hopefully funny, a lot of this.
They're kind of really weird paths, even though they're not like crazy complex.
I think you guys will have some fun with them.
And in addition, as we go through those, going to have some kind of takeaways and things like that for pen testers, blue teams a little bit, but really kind of methodology driving stuff for penetration testers as we go through.
So to hop into the first one here, called it Wall Street Bets.
I'll provide a lot of context here in a moment.
But this was mid-COVID, working on a... well, let me back up and preface this.
These are all real stories.
I've abstracted away a lot of this stuff.
You're going to see a lot of blurred screenshots.
But anyways, this was mid-COVID, the peak of GameStop trading and all that stuff.
But we had a manufacturing company that we worked with purchase another manufacturing company.
They added them to our scope.
And I found Exchange or OWA and kind of went crazy with it.
So back when OWA or Microsoft Exchange was out on the Internet all the time, right, the trick with self-hosted Microsoft services was, hey, I can password spray this and get access to an account in Active Directory, log in and do all my stuff, right?
And from there, right, we landed on some credentials, no multi-factor authentication anywhere.
And we'll show you the rest of it here in a moment .
But just some details, right, on this attack path for you guys.
So one of the... back when Microsoft Exchange and OWA were really popular, everybody hadn't transitioned to O365, the common way to actually enumerate a list of usernames that you could leverage for password spraying, guessing users' passwords, targeting Exchange,
was a timing-based attack.
So when you try to log into, if anybody's used ADFS or anything like that at the company they work for, if you try to log in and you enter a real username versus a fake one or a not real one in a company's network, right, the time it takes to respond is going to be slightly different.
So if Jay Smith actually works at Acme Corporation and I try to log in with his account, the amount of time it's going to take for Exchange to respond and say, hey, that's a bad password is going to be different than D.
Smith or something like that if they don't exist at the company.
So just to get that information out of the way, right, what I would do back in the day when we had Exchange all the time and in this case, the best way to actually perform this timing-based enumeration was to use a Metasploit module for OWA username enumeration.
The list that I used for users was this thing called Statistically Likely Usernames, but the funny thing is, and this kind of plays into it, the default password that is set by Metasploit for that login process or, sorry, the user enumeration process is just straight-up password with the assumption you're not going to actually guess a cred or guess a user's credential.
So I spun up the Statistically Likely Usernames list and started, hit start and was hoping , okay, I'd come back in an hour and maybe I'll have enumerated, you know, 20, 30 usernames , that sort of thing.
Immediately logged in successfully with admin password to this exchange instance.
I didn't even look away from my screen.
And one later found out that user was a global administrator in Azure and a domain administrator inside of the network.
But at the time, I was not aware of that.
So I took these creds, I was like, all right, awesome, I'll log into something.
Went over to a Fortinet VPN, logged in, no MFA.
And so on the network, relatively easy path to domain administrator after that.
This path doesn't work as much anymore as well.
But Kerberos-ing for users, cracking those hashes and then one of those users was a domain administrator, did the fancy DC sync stuff, got DA.
When I compromised a company in like 30 minutes like this, it, you kind of start to pillage and look for cool stuff.
After that, you do all the time, but depending on how much time you have, you want to dig in a little bit.
So my favorite thing to do is hunt down the IT administrator, find their workstation, log in, look at their stuff, what they're doing, that sort of thing.
And I did that.
The admin was using Windows 7.
And logged into the desk, this is not that long ago.
Logged into the desktop and, or already peed in after work was over and they had the Wall Street Bets discord right up on their screen.
Very active user, actually.
So really, really funny.
Screenshotted that right away.
I wish I could show a screenshot of the desktop with all the icons, because it was hilarious.
But yeah.
Grabbed a couple screenshots.
Reddit, Twitch, I mean, he's a nerd, right?
But it was just like us.
And pretty cool path.
Very, very quick.
But nevertheless, like very funny, the entire process.
I've never gotten that lucky again.
But pretty cool little war story.
As quick takeaways on this one, right?
This company just didn't have a security budget and they had one IT guy.
Very common in manufacturing.
Or at least certain companies, right?
Relatively small ones.
So if you're going to spend money on something, spend money on security.
And have more than one guy kind of managing IT infrastructure and security for an organization.
They went ahead and did that after we reported on this.
So awesome.
Sometimes you have to pwn a company to prove that they need to actually spend money somewhere.
So it was useful in that sense.
For kind of the penetration testers, though, follow the methodology, right?
If I didn't use the steps that I always used when I saw Exchange, this wouldn't have popped out.
Have kind of that run book that I go through.
Build out your methodology and work through it no matter what.
And then also nothing is too easy.
It's really common on a pen test to go, there's no way that will work.
And then it works.
So you always have to try out everything, right?
I'm going to skip on to the next one.
I'm calling this one push it to the limit.
This one I don't really have a reason.
Actually, okay.
So this one was relatively similar to the last one for the initial access vector.
It was password spraying Exchange.
I really wish we still had Exchange.
But cyber liability insurance now forces you to pretty much take it off the Internet.
So we have to spray O365, which is much harder to the point that I wrote a presentation about it last year.
But sprayed my way into OWA.
Couldn't log into the VPN with those credentials.
And I knew definitely that those users were in the VPN group.
I'll explain that in a moment.
Pillaged a ton of inboxes for MFA information or kind of login information, IT stuff that was sent out to the user.
And came to find out that last bullet was the case.
And I'll explain why here in a second.
So when you guess credentials targeting Exchange, and 99% this still works.
I haven't screwed with an Exchange server in a little bit.
But there's a methodology called DNT dumping.
It's really cool.
Look it up.
But essentially from the Internet, you can get a pseudo... who's familiar with bloodhound?
Okay.
You can get a bloodhound dump from Exchange on the external network.
Which is really, really strange.
It's not as well formatted in JSON and all that stuff.
But you get a full list of users, the groups they're in, that sort of thing.
You can yank it down.
So after I compromised a user, did the DNT Exchange dump and saw that the users that I had compromised or guessed credentials for were in that VPN group.
So when I'm over on the Cisco SSL VPN, I can't log in.
I'm like, what the heck is going on?
So I start pillaging through user inboxes.
Usually when a user gets first set up at a company, right, they get a PDF that's like, here's how you reset your password and set up your laptop and that sort of thing.
Screenshot here, straight from the documentation.
You'll see that the group, normal for Cisco SSL VPN, just duo SSL VPN.
The login is your username and the passcode is push.
So...
at first, right, I think you'd look at that and go, okay, where's the passcode being entered, that sort of thing.
Based on kind of previous experience that I had had with VPN configurations using duo, right, there's a way to set it up where you place certificates on the user's workstation and then you set up duo with the VPN so the user goes to log in.
They might not have to enter their password, but the VPN connection will validate that there are certificates on the machine and then you also have to approve the duo push.
If that makes sense.
In this case, there weren't any certificates on the machine.
So you could log into the VPN by entering their username, the password push and just MFA fatiguing them until they allowed you in.
So it was literally waiting until lunch.
Basically didn't have to spray passwords at all to get into this company.
And really, really cool.
Pretty scary.
It was really just kind of sitting duo spamming for a while until they accepted it.
Logged into VPN.
Again, relatively standard kind of attack path after here.
Actually the same as the last one, Kerberoasting to DA.
This was a caveat here, just kind of to add some more impact to this one.
It was somebody in the aviation sector.
So the cameras I got to look at were pretty cool on this one after we were kind of on the internal network.
But lessons learned are kind of takeaways from this one.
Make sure MFA is real.
I think this holds true for really bad setups like this, but additionally holds up for anybody who's implementing conditional access policies and things in Azure and O365.
Even though it feels like MFA is in place, it might not be because somebody changes their user agent when logging in, that sort of thing.
So some secondary validation there to make sure your setup is configured properly.
And additionally, don't be afraid of friction.
You know, I think security professionals in general, we walk the line between how hard do we make it for users, and if we make it difficult, it's more secure versus let's make it as easy as possible, which is less secure in some cases.
In this case, I think they wanted to make it as easy as possible for users to get on the VPN, but I mean, that makes it very easy for attackers to do the same.
For the red team, right, pillage, pillage, pillage.
Not joking about that.
Don't hit a wall and give up.
IT administrators love to write down how to hack the organizations that they manage.
So you just have to read documents and PDFs to figure it out.
In this case, you know, figured it out that way.
And additionally, keep a strong kind of background and toolkit, understanding the tech stack, kind of looking at this and going, okay, this is how this works and this is why it works, that sort of thing.
That background is really important to have, right?
So up next, right, we're going to transition away from kind of the funny paths and more into kind of some interesting domain administrator paths or kind of paths that I've had kind of recently.
So this one, deploy this, bro.
I'll preface all this by saying it's going to sound like a very cliche story, but I started off back in the day, or at least kind of my first tech job ever, was imaging computers for student labs in the back room of an old building with water that was literally dripping from the ceiling.
And so relatively familiar with Windows imaging and that sort of thing and Microsoft deployment toolkit, which comes into this one here.
The initial access vector was, right, we had an internal testing appliance placed on a client's network.
And so we were testing from there.
We weren't external trying to get our way in like the last two.
And we had to get credentials and then attempt to kind of escalate privileges to domain administrators.
So the initial vector there was relatively simple.
It's a responder layer two attacks to capture a hash and crack that hash.
But then the standard attack paths that I generally go through right from here is, hey, can I try to do Kerberos thing?
No, that doesn't work in this case.
Can I dump bloodhound and look at active directory permissions?
And is there DAQL abuse capabilities?
Can I modify other accounts on the network?
Can I abuse active directory certificate services?
No.
None of this worked on this network.
So had credentials and I was kind of sitting there twiddling my thumbs.
What we pivot to from that point generally and some of the testers that work for Sprocket in the crowd were doing this right now.
When you're stuck, you actually spider network shares looking for files that contain the word password and that sort of thing.
And you'll get lucky and you'll find a config file somewhere with a set of credentials for active directory in there, right?
In this case, kind of that standard methodology wasn't yielding anything.
But I went and kind of pivoted to looking for some other stuff.
I had recently read some research around like SCCM related attacks that have been popularized by a couple of pen test companies out there.
One of the things that I think got forgotten in that process was the first step in Windows imaging and deployment and that sort of thing.
Microsoft deployment tool kit, right, to actually boot a machine and image it on a network that isn't using Intune or something along those lines, you have to boot the machine up, do pixie boot, it pulls down something and you set up that machine with your configurations and settings and scripts and all that.
The file that's actually created to do that is called a Windows image file or a WIM file.
In that file, you can provision configuration things to grab down scripts and all that stuff as the machine is getting set up.
So on internal networks, when you're bouncing around doing a pen test, you might run into network shares called MDT, deployment share, things like that.
And often you'll find .WIM files sitting in there.
Those files are the ones that are actually being pulled down during a pixie boot process to image a new machine that's going to go on to the network.
You can configure those files to actually, or you can configure that WIM or that image to actually contain config files.
In this case, a file called bootstrap, I actually have it here on the next slide, a file called bootstrap.ini.
This is what will actually pull down scripts and stuff like that for you.
But you can also provision credentials for it.
So our normal network share spidering wouldn't have seen this config file because it was actually nested in a compressed or a WIM image file.
So the thing here, right, to back up the path is instead of just searching for files containing usernames and passwords, in this case, we kind of went for a very specific network share, grabbed the config file out of there, had credentials.
This user was not super privileged in this case, but after a little bit of DAQL abuse and bouncing around and things like that, we were, you know, able to get domain administrator from that user set.
But I think the cool thing to kind of call out here, right, is when you hit that wall, this kind of additional research and kind of the background knowledge yielded some cool stuff.
This is something I look for on every pen test now.
I've had it work a few other times.
It's not just limited to specifically looking at, you know, .bat files and PowerShell scripts and stuff like that on network shares as we're spidering around.
Lessons learned on this one, probably just switch to Intune if you're still doing manual imaging of workstations.
Probably sucks anyways, but it's also pretty insecure by default.
So make the swap over.
Additionally, it is crazy to me on internal networks that I test how often I can read from a thousand different network shares.
Limiting access to those network shares to, you know, a subset of users as opposed to allowing all domain users on the network to read from blah, blah, blah, and the deployment share and things like that is kind of crazy.
So restricting down network shares and that sort of thing.
For penetration testers, though, right, you're going to see a lot of files that are like 10 gigs, stuff like that, and stuff you don't want to pull down to actually dig through and look at.
But I'll tell you from experience, these WIM files are cool, but you'll also see VM backups and stuff like that that are worth taking a look at.
So don't just depend on your tools to find stuff for you.
And also kind of think outside the white paper box.
You're going to read articles and things like that, but diving in and kind of understanding the tech stack of it all is really important here for kind of finding those unique edge case privilege escalation paths.
But yeah.
And then up next, this one gets even weirder.
I'm going to stumble through this one a little bit, but we'll talk about it.
If anybody remembers from Shrek, some of you may lose your life, but that's a sacrifice I'm willing to make, he says.
So ended up choosing that.
So this one was actually really, really cool.
I also got to make the... I had the most fun creating the report and attack narrative for this one than I've probably had in, you know, recent years.
So I think it's pretty neat.
It's very complicated from a technical perspective, but just for some background, right, we're on an internal testing appliance for one of our customers.
I'd actually done pen tests for them for the past, like, three years.
So the easy stuff was, like, gone.
I couldn't do layer 2 attacks to capture hashes and relay them and that sort of thing from the Dropbox that we had.
So I copped out a little bit and I said, hey, give me some AD credentials that I can use to dig around and take a look at things.
I already knew from experience that there weren't going to be easy paths for me to take in Active Directory, but nevertheless, went ahead and did a very standard, not recent, maybe in the last two years attack path where you execute coerced authentication.
You'll probably look it up and you'll see Petit Patam.
It's where you force a domain controller to authenticate to whatever host you tell it to and then perform the ESC8 attack with ADCS, just relaying authentication to a HTTP end point to generate a certificate.
And we'll ‑‑ we have a slide here in a second where we actually look at the outline of that.
But then ran into some really kind of difficult edge cases where they presented themselves because the customer actually fixed stuff that we told them about, so had to get really weird with it.
So real quick kind of a background sort of explanation on Petit Patam to ESC8 attacks, right?
So what you can do if you have domain user credentials, we were provided them in this case, is you can go to a domain controller on the network and you can say, hey, can you authenticate or can you connect to this specific SMB share out there on a ‑‑ out there on the network,
right?
And you send a specifically kind of crafted request to that domain controller and it tests that end point.
So what can I do as an attacker?
I can listen for SMB connections and I can give that domain controller my IP address.
So in this case, right, we're basically capturing an authentication attempt from a domain controller, which is already kind of a big deal, but you can't crack it using traditional methods because of the way computer account passwords are set.
But regardless, right, we capture that authentication attempt and then we relay it on to a very specific HTTP end point called the ‑‑ it's an end point that's associated with Active Directory certificate services where you can request a certificate over HTTP as opposed to doing it with other protocols.
If I send the authentication attempt from my domain controller to that end point, I can essentially generate a certificate that can authenticate on behalf of that domain controller.
Hope that wasn't a little too much.
But really I'm using domain user credentials to take over the account of a domain controller on the network, right?
So awesome.
What do you do in that case once you have that certificate?
Well, generally what you can do is use a suite of tools from a researcher called ‑‑ his name is Dirk Jam.
But there's a tool set on GitHub called PKINIT tools, or PKINT tools, I always say one version or another.
But what it really does is it does some weird cryptography math that I don't understand to take that certificate and turn it into the ‑‑ an NT hash that can be used.
So just really quick, you can use a password to log in in Active Directory, you can also use a NT hash.
So you don't need to know a plain text password to actually authenticate.
So the trick is, right, I get the certificate, I recover the NT hash, and then I can authenticate as the domain controller everywhere.
I essentially have domain administrator.
In this case, however, when I attempted to do this, got that really weird error message that we're showing there.
Basically what it means is a domain controller or the domain controller that we're working with and the domain as a whole doesn't support PKINT authentication.
Fancy way of saying smart card, do everybody remember when smart cards were kind of cool for a minute?
I don't know if they're still ‑‑ I'm sure in government and things are being used.
But smart cards and a couple other services will use certificates to authenticate and or as like a MFA method.
And if you don't have that turned on or explicitly disabled or if you don't have it turned on or it's explicitly disabled for whatever reason, you can't actually authenticate using certificates through normal ways.
So when I tried to recover that NT hash, I ended up in the position where I couldn't do any ‑‑ I couldn't do it and I couldn't authenticate to anything.
So I hope that made sense.
Ended up in an even weirder situation after that, right?
So okay.
I'm stuck.
I have a certificate that is ‑‑ can authenticate as a domain controller, but I can't get like a piece of authentication material that I can use.
How can I leverage the certificate to talk to Active Directory or something like that so I can perform another attack to work my way towards domain administrator?
Well, there is another way to with certificates on networks.
It's called S‑channel.
It's a limited way of authenticating with a certificate to Active Directory, specifically LDAP.
So you can take that cert, talk to LDAP and say, hey, can I do some stuff?
And so what you try to do there then is, okay, what attacks can we do just with LDAP, right?
So a domain controller can't change passwords of other users.
It can't change ‑‑ it can't do much.
It can only really authenticate to itself or other machines in the context of like a domain user.
So the path here then with S‑channel authentication is to actually ‑‑ or this is kind of the typical path is to perform resource‑based constrained delegation.
How many people in the crowd know what resource‑based constrained delegation is?
Okay.
Cool.
Just checking there.
So from there, right, to perform resource‑based constrained delegation, you need to actually have a user with an SPN specified for it.
I hope I see some nodding heads here.
So right now, right, in this position, I have the certificate.
I control that user account that was given to me by the company that we're working with.
And I can authenticate to LDAP using that certificate.
So I'm going to try to set up resource‑based constrained delegation that allows me to impersonate admins on that domain controller.
To perform RBCD, which if you guys aren't familiar, the hacker.recipes, there's a ton of research and articles out there about it.
It really just lets you fake or impersonate, right, any account you want on a computer account out there.
So what you have to do is to set up RBCD is you need an account with an SPN or a service principal name specified for that account.
Domain user accounts do not have an SPN by default.
Computer accounts do.
So the trick here generally, and in Microsoft's infinite wisdom, they set up Active Directory to allow any authenticated user to provision 10 computer accounts on a network.
So if I compromise Joe Schmo, he can't do anything, I can still talk to Active Directory and say, hey, create a new computer account for me.
And it'll do it in most networks.
In this case, I had actually told the customer that they had misconfigured this or it was misconfigured in the past.
So they set the machine account quota, which is the value that specifies how many computer accounts you can create, to zero.
So I'm in this position where I'm like, okay, I can't set up resource-based constrained delegation anymore.
What the heck am I supposed to do?
So then came along a really cool article from James Foreshaw at Project Zero.
That's where the title of this section comes from, or sacrifices.
So James Foreshaw, and the guy who works at Project Zero, so he's very smart, outlined a methodology for performing SPN-less resource-based constrained delegation, basically by sacrificing an account you control.
So what you can do is carry out this entire attack path, but you basically make the user that you have access to invalid after you've performed the attack, which is very, very odd.
So doing this stuff is already nerve-wracking in itself.
Having to sacrifice the only method you have of communicating with Active Directory is even worse.
So this was a lot of double, triple checking commands, making sure my pinky wasn't hovering the enter key accidentally in the terminal, that sort of thing.
So I won't go through, I actually told the guys on our team this, I won't go through the entire kind of technical explanation of how this works, but instead kind of just show off some commands.
I started writing it out, and it probably should be an entire presentation in itself.
It's really, really cool.
But I'll just show you to kind of demonstrate how odd it is, right?
So from this perspective here, I'm just going to repeat myself again, I don't mean to get annoying, but we have access to a domain user account, sprocket.user, in this case it's called, and we have a certificate for the domain controller, and we can only authenticate over S-channel to LDAP with that certificate and talk to LDAP using the sprocket.user account.
So to leverage this, right, what you first have to do is leverage a tool called pass assert, which lets you do that S-channel based authentication, to talk to LDAP and set up resource-based constrained delegation using that user account that doesn't have an SPN.
So you're basically setting something up to fail.
It's not going to work if you actually try to leverage it.
So go ahead, set that up, that's what this screenshot is here.
Then this is where it gets really, really weird.
So you take the password that you know for the user that you control, the sprocket.user, and you actually convert their password into an NT hash.
With that NT hash, you then, well, then you request a ticket granting ticket for that user using the NT hash specifically, right?
So we're getting another piece of authentication material using that NT hash that we just generated.
From there, you actually inspect the ticket granting ticket and grab the ticket session key.
Really weird.
You take that and you reset the user's password to the ticket session key, and then you can perform resource-based constrained delegation.
So all of that is weird technical stuff.
Really, this was like two days of staring at a terminal and a screen, more than it was actually typing things, making my notes look good.
I got to write a really cool attack narrative titled sacrificing sprocket.user for the greater good.
That's probably the coolest title I've ever gotten to write.
For this one, though, the lessons learned, one, don't be as big of a dork as Nicholas and spend a few days on this.
There is actually a write -up.
Some of our, we were taking a look at it before this, the hacker.recipes that I mentioned, there's actually a walkthrough on how to do this now on the website that they have, which is really, really neat.
He's actually got commands written out at the time.
I was just kind of piecing stuff together to make this happen based off Forshaw's article.
But lessons learned, you only have to mess up once.
Same thing for Red Team.
They only have to mess up once.
I think that saying kind of is a little goofy.
But regardless, for the guys who do defense and kind of manage networks in here, those goofy findings that you get on your penetration testing reports, unless you can tell they're coming out of a Nesta scan or something like that, actually are valuable,
especially the ones related to securing active directory and implementing best practices.
So when I tell a customer, hey, set your machine account quota to zero as opposed to leaving it as ten, that actually makes my job harder.
It's not something that is just kind of a goofy best practice thing that I write down for fun.
It's valid and legitimate.
So implementing those sort of things are very worthwhile.
And then from penetration tester's side, I can see myself in the early days giving up on this one.
It took a lot of reading and digging in and finding out that this was even possible in the first place to make something cool here.
I will say that this was a very weird thing.
I doubt I will ever use it again.
But super, super cool.
And yeah.
So awesome.
All that technical crazy stuff out of the way.
Now we got a fun one again.
So does anybody recognize the logo on the left side of the screen there?
That's what I was guessing.
Open LDAP, the open source implementation of directory services, that's what they chose for their logo.
A creepy worm.
So this is my favorite pen test of all time.
It was actually my third or fourth test ever or engagement that I ever did.
Which kind of speaks to how fun it really was.
You can see that the bullet points list here is a lot longer.
That was kind of for comedic effect.
But also it is that complex.
Especially to the point that I made a flow chart for the customer and put it in the final report and I pulled it out for you guys to take a look at.
Really, really interesting stuff here.
So to give some background on this customer, they knew how to make, they got hired for an IT position and they said you have no budget.
Have fun.
And so this actually really amazingly talented IT administrator went and built a network out of open source products and tooling.
And they also nerded out on a lot of neat things that coincidentally I was doing research on and setting up at home at the time.
So it's pretty neat.
They were using a mail service or kind of an alternative to O365 called Sogo, I believe.
Yeah, I see some faces kind of look, yeah, I know.
I had never heard of it either.
But pretty standard like business collaboration suite.
So you got email and calendar and stuff like that.
Completely open source, self-hosted.
For this customer, went ahead and password sprayed that Sogo thing.
Of course there were no tools to do it.
So it was just throw it in burp suite and hope for the best and iterate through.
Actually had to enumerate user names off of LinkedIn for this one.
I'm way too lazy to do that nowadays and talk about afterwards why.
But ended up successfully guessing a credential for a user and logging into this kind of shared mail suite that I've never seen in my life.
As I'm digging through the inbox of the user, I found this.
This almost feels like a hack the box machine when you look at it.
Here is your VPN configuration.
Install it.
And just had some background like as a Maxis admin in the past.
So I was like pretty quick, I was like, oh, crap, okay, this is awesome.
So grab the, it's a mobile config file.
You can grab it on Mac OS, double click it, it'll install.
In this case it provisioned a VPN configuration and you enter the user's credentials and you're logged in.
So relatively straightforward, but super weird, especially where I found it.
Once I was logged in to the VPN, started looking around and ended up on a file share.
This is another like I was really into some Linux stuff at the time and started reading a ton about ZFS file system, if anybody's familiar.
ZZZ snapshots is one of the tutorials out there.
They'll tell you to create that to actually like store snapshots of your file system as you go along.
And so I had the permissions to read through clients and users and things like that.
So I'm looking through all the user directories, hey, do I have credentials anywhere, that sort of thing.
But the IT guy does what every IT guy does before you do the pen test two weeks before.
They go through their home directory and they're like, crap, I have to delete all the password.txt files and that sort of thing.
So I go into the ZFS snapshots instead of the user's home directory and found a filezilla config that he had deleted a week prior to us actually starting the test.
I don't know if he ever expected me to get to this point, but we did.
And with that filezilla config, it gets even weirder, that allowed me to establish a remote desktop connection with a Windows server hosted in AWS that they had a site -to-site between the on-prem kind of office site and this web server that they were using to provide like client,
the client SaaS application that this IT developer also worked on and built and that sort of thing.
Once there and logged in with that remote desktop connection, was able to actually log into a local Microsoft SQL database.
Logged into there, right, I was looking for credentials that would get me access to, I had found a key pass database in that user's or the IT admin's home directory that couldn't crack the hash on, that sort of thing.
So I was looking for any creds I could use as this IT admin to SSH into something or log into certain panels that we'll look at in a minute and didn't have his password, but I dumped the user database out of this local Microsoft SQL database and, yeah,
it's such a blurred screenshot, I'm sorry guys, there's not much to look at there, but the IT admin also had an accountant here and the password that he had stored in plain text in this DB could be used to unlock his key pass database.
So even more hack the box.
Grab this password, I go back, grab the key pass database off of the file share that we had access to and went ahead and unlocked his key pass database and that kind of popped open another path right from here.
So then with those credentials I could log into his Windows workstation, a couple different things and all of that.
Also right from that workstation access that I had, I was able to grab a root AWS credentials, so all of AWS was like pwned at this point.
But then I'm searching around and you know how I said it was like all open source everything?
There was no like local active directory.
They just had web services, random things that they were hosting that were open source, all of that.
So one of the things that they had running was a super micro IPMI web interface.
With credentials that were in, Peter's looking at me.
In the credentials that were in that key pass database, let me log into the super micro instance and come to find out this was like the only way I could interact with other servers that he had running on the network.
I knew that there was a some sort of open LDAP or service on the network to actually allow me to authenticate to the SOGO mail thing in the first place.
So I'm hunting down the Linux version of a domain controller on the network.
I start browsing around through the IPMI interface and land on something called Bacula.
Does anybody recognize Bacula?
Does anybody recognize Borg, the backup solution?
One hand.
It's really just a scheduled, it's almost like time machine, but for Linux.
Bacula, Borg is for local workstations.
You can use it yourself.
Bacula is built to do multiple systems at scale.
So these guys were using Mac OS across the board.
This IT admin had set up Bacula to pull backups from those workstations whenever they came into the office.
Anybody who's provisioned backups or even like VPNs on Mac OS and VPNs in general, right, know there are usually pre-run and post-run scripts that you can implement along with those backups.
So something that runs before, maybe clean up some files or runs afterwards to send a ping somewhere or something like that, right?
The thing you can do as an attacker, however, and mind you, this is all through an IPMI web UI, which I don't, if anybody's ever worked with it, it's the most miserable thing in the world.
You can't copy and paste anything.
So it sucked.
But I logged into this Bacula server and I provisioned it to actually write a private SSH key to the open LDAP server.
So all of the server Linux instances that he was running were also getting backed up with this box.
In retrospect, as I was creating this, I don't know why I didn't just steal the backup and pull everything out of it, but maybe my VPN connection was too slow, I don't know.
But created a script that basically wrote a SSH key to that open LDAP server, triggered a backup manually, and then I was able to SSH into that open LDAP server and, I don't know, I wasn't sure what to do next.
So at this point, we kind of have DA.
We can interact with the open LDAP server as root or administrator, that sort of thing, and we can SSH straight to it, talk to it.
And normally, if anybody's kind of gone through stuff or done DC sync attacks before and dumped kind of DIT files out of active directory, you probably have used secrets dump to do that from the impacket tool suite.
There is no secrets dump for open LDAP.
So this is something that kind of blew my mind.
I remember sending KCR CEO a screenshot of this back in the day because it was so crazy.
But if you are on an open LDAP server and it is not encrypting the traffic, you can run TCP dump on that box and live grab creds as they're going over the air.
So it was a pseudo kind of fake DC sync, but was able to sit there, run TCP dump for like an hour, then open the PCAP and pull creds for everybody out of there.
And they were plain text.
They weren't hashes.
So we didn't have to crack anything.
It was really, really cool.
The lessons learned... I don't know.
Like... pay for something.
I mean, this was like...
the IT guy did not need to know that this all needed to be gotten rid of.
It was more of a pitch to management to actually spend some money on security and things like that.
So now they are in a fantastic place.
They've been with us for a long time.
It's O365, very minimal attack service.
They did a great job.
So really, really fun one.
I will talk about this one forever.
It still is my favorite, even though it does feel like a hack the box machine.
Really, really fun.
I will say, like, takeaways on this one, right?
You're going to find environments where you can't use your normal testing methodology.
And so you kind of got to get weird with it.
Especially nowadays, right?
The simple kind of standard stuff on external networks that you used to be able to do, that password spraying into DA, Kerberoasting, blah, blah, blah, that we talked about at the beginning, generally isn't really possible anymore.
So doing stuff a little stranger, not looking up hack tricks, port 443, that sort of thing.
It goes a long way.
And in addition to it, I guess do hack the box machines and you'll be a good pen tester.
So yeah, I appreciate everybody's time.
I'm a little ahead of time here.
I talk kind of fast.
So open to any questions, open to go back to any slides.
Yeah.
Kick it out to you guys.
Cool, cool.
Yeah.
What do you use to crawl file shares?
Pie whisker.
No, man spider is what we like to use for crawling file shares.
They're really, Brett asked, but there are tools out there that you can point at network file shares on an internal network with a set of credentials and tell it to go look at each of those file shares and look for strings, file names, that sort of thing.
It's way easier than it used to be when you just had to establish a SMB connection and look through all the files and configs and text files to hopefully find a password or something like that.
And man spider or pie whisker or not pie whisker.
Yeah.
Sorry.
Pie snaffler.
Sorry.
They all got weird names.
They'll kind of let you automate it a little bit.
You can just add, run something on the command line and it'll check even the contents of like PDF files, PNGs, that sort of thing for you.
So yeah.
Awesome.
Anything else?
All right.
Everybody wants to eat.
Okay.
Thank you, everybody.
I appreciate it.