SiegeCast: Access (Still) Granted

https://redsiege.com/access_still_granted

*UPDATE* This event has passed and the video and transcript can be found at the bottom! 

Red Siege is back with a brand new SiegeCast! This time we are going to show you that you dont always need that often coveted access to Domain Admin to get the job done.

On June 10th at 3pm EDT we will be presenting ” ACCESS (STILL) GRANTED “

Founder Tim Medin, along side Principal Consultant Mike Saunders, will show you tools and techniques to find vulnerabilities and demonstrate risk, without using Domain Administrator access. Domain Admin access is the goal for many penetration tests and red teams, but it is misguided. DA is a tool, not a destination. Sometimes, a penetration tester or red team will be unable to obtain this access, but it does not mean that the test is without value.

We encourage you to sign up for this webcast, as well as become part of the Red Siege community discord – https://redsiege.com/discord

Corey Overstreet will be in the discord as well answering any questions along side the discussion.

There, we will be taking our questions and interacting with the community, as well as posting links the coincide with the conversation.

We look forward to seeing you there!

Tim is the Founder and Principal Consultant at Red Siege. Tim is also a Principal SANS Instructor, the SANS MSISE Program Director and a SANS course author. Tim is the creator of the Kerberoasting, a technique to extract kerberos tickets in order to offline attack the password of enterprise service accounts. Tim hoLds GWAPT, GPEN, GMOB, GCED, and GCIH certifications and he previously held the CCNA certification

Mike is a Principal Consultant at Red Siege. Mike has over 25 years of experience in IT and security and has worked in the ISP, financial, insurance, and agribusiness industries. He currently holds the GCIH, GPEN, GWAPT, GMOB, CISSP, and OSCP certifications

Corey is the Senior Penetration Tester at Red Siege. Corey is a credentialed OSCE ,OSCP and OSEE and has participated as a member of the SECCDC. He has a enxtensive career as an experienced pentetration tester, red team operatior and has been engaged with Fortune 500 organizations across a variety of industries, including financial services, government services, and healthcare.

WATCH SIEGECAST

Transcript

Tim Medin (00:04):
All right, folks, welcome to our, I guess second annual, not annual, but second ever Siegecast. Just say second. Jim, stop talking. Thank all of you for coming. If you want to check out the Discord channel, so redsiege.com/discord, we’re going to have people fielding questions, we’re going to have Justin and Cory trying to field some of those or bubble those up for us later. You can also take a look in the chat here at GoToWebinar. Doesn’t usually, not quite as fluid as something like Discord, plus a Discord gives us sort of longer access to have better discussions in there as well.

Tim Medin (00:45):
But we’ll get to our main content here, to what we do, pen testing, stuff like that. With that, let me jump into it. I’m going to just introduce both of us. I’m going to go first, my name is Tim Medin, I am the principle consultant here with Red Siege. I teach with SANS, the lead author of the pen test course 560, also am one of the instructors for SEC 660 over at SANS’ IANS faculty, STI program director, been pen testing for a long time.

Tim Medin (01:21):
With me I have the ever-brilliant Mike Saunders, he’s the pretty face here at Red Siege. He’s been a consultant here for, I guess just over two years now, anniversary was last month. Been pen testing a long time. Wicked smart, spoken all over the place. What we’re going to do is we’re going to sort of split this up, you’re going to get both of our perspectives on this, we’re going to go back and forth a little bit throughout. Again, if you’ve got questions, put them up in the Discord, we’ll try to get to those if we can.

Tim Medin (01:55):
So of course the important piece here, we’re talking about access still granted. We don’t necessarily have to have that domain admin access as a pen tester, frankly as a bad guy, right? They don’t need that domain admin access. It’s a tool, it’s not a destination. If you think about the bad guys, their goal is to get inside your organization and steal the data that’s important to them. Could be financial information, something they could immediately turn around and use to quite literally pay for food for their kids, buy a car. They have some of the same boring needs that we do.

Tim Medin (02:39):
So they’re going to have these goals. They only need to accomplish as much as possible technologically to get to that data that helps them get to their goal, and, frankly, their family. I don’t want to humanize them too much, but realistically, that’s the life that they live in.

Tim Medin (02:58):
Now, sort of contrast that with us as pen testers, we often think about winning. We refer to winning as that domain admin, getting to that privileged access. But remember, that’s sort of a slight misalignment. Our goal here as pen testers, red teamers, offensive people, is the data, that business process, whatever it might be.

Tim Medin (03:27):
So what, of course, are some of those goals? Well, it depends on the adversary, it depends on this bad guy. It could be ransomware. The big rumors right now are surrounding Honda and the ransomware on the inside. Their goal isn’t immediately to take data, it’s to encrypt everything, cause them to pay, in a ransomware attack, and then immediately turn that into some sort of money that they can use to, frankly, live.

Tim Medin (03:58):
Could be intellectual property. Maybe their goal is to steal something from the organization maybe they can resell, or it could be nation-state, where they’re trying to steal some useful information, intelligence. We’re seeing, and this is, frankly, in my mind, quite dirty, but we’re seeing organizations, threat actors out there in the real world trying to steal research on COVID, which seems a little bit odd, but it also seems weird that it’s not shared, but that’s kind of a whole deeper thing.

Tim Medin (04:27):
Of course, we’ve got PII and the money and the financials, those are sort of obvious goals here as well. Again, this is the end goal. The end goal is not for the bad guy to administer your network. That domain admin is a tool, that privileged access is a tool, it’s not a destination. And if we as pen testers, or you’re contracting with somebody, and they as pen testers are looking for simply the technological win, again, it’s a misalignment of the goals. That focus on the business needs, the organizational needs, the important data, both from a organizational perspective as well as the data that’s important to that threat actor, that has to be our goal. We have to focus on that business risk.

Tim Medin (05:21):
So we go back to sort of the traditional penetration testing definition, I mean our goal as pen testers, as offensive people, pen testers, red teamers, whatever it might be, our goal is to model the tools and techniques of the real world attackers, because we want to find these vulnerabilities, exploit them … Now, in our world as a pen tester, we don’t want to crash things. We’re going to be more careful than maybe the real world adversary. I can’t take a production system offline if it’s going to have a benefit for me, but of course, a bad guy happily would if it would help them, so there are some constraints here. But the key here is we need to stay within that scope and the rules of engagement and the constraints to find the business risk and the potential impact.

Tim Medin (06:16):
You’ll notice here that the last piece here is not get to domain admin. It is not to take over the domain controllers, it’s to get to that business risk and potential impact, and help the organization improve their security practices and wrap those vulnerabilities in such a context.

Tim Medin (06:40):
So with [inaudible 00:06:45], there we go. So now question is, let’s take the domain admin out of the picture. What happens if we can’t get there? Right, now in the sort of traditional sense, we might be thinking, “Well, I lost.” Not necessarily. The data is still there, that privileged access is just a tool to access the data. There are many times or other ways we can access the same data. They don’t have to get into the vault, the bad guys, the thieves. They don’t have to get into the vault to rob a bank. They can just go to a single teller.

Tim Medin (07:20):
If we think about it that way, we don’t need all the money from the bank as the thief, we need enough money to be useful for us. And if we think about that perspective a little bit differently, it changes some of the sort of risk scenario. Whereas if we think about the bank vault as that domain admin, that privileged access, we’re going to guard that vault differently. But now, if we push that forward and we start looking at all the tellers as potential threats, we then end up guarding the bank a little bit differently. Is there data laying around that we might be able to find?

Tim Medin (07:57):
So with that, I’m going to turn it over to Mike here, he’s going to talk about using some of this access and finding some of the data without the privileged access.

Mike Saunders (08:08):
All right, thanks Tim. Yeah, so absolutely we’ve mentioned several times we’ve talked about data, because really for most organizations, data is what’s important. That’s where their livelihood ultimately starts and ends is that data, so we’re focusing on sensitive data, whatever that sensitive data may be. How do we find out what the sensitive data is? We ask the client and we start out a test. Before we even do that, when we’re scoping, we say, “What keeps you up at night? Like if your organization were attacked and data were stolen, what’s the data that keeps you up at night?” That’s what helps inform us on how to do that test so that we have a good understanding of what they’re trying to protect when we start out.

Mike Saunders (08:51):
Because otherwise, we go into an organization, we don’t necessarily even know what … We think something’s really important, they’re like, “Oh yeah, that doesn’t matter, the goods are over here.” Another thing that we think about is finding out who has access to the sensitive data, and there’s a number of ways you can do that. You can do that by querying active directory for groups that, for instance, have keywords, maybe admin in the name, or HR, or finance, depending on what your organization is. It might be engineering, if you’re trying to steal intellectual property from an organization, maybe your engineers are the people who have the best access for that.

Mike Saunders (09:35):
Then we target those specific users whenever we can, and we pivot towards the data. So we may find that we need to go to one system, and that system now has a second network connection that has access to another network that we don’t have access to from our first system, so we’re going to pivot through that system into that other network and continue to search for the data.

Mike Saunders (10:00):
A lot of what we do, you can go to the next slide there, Tim, is focusing around initial access with passwords. Something you’ve heard more and more about in the past few years is credential stuffing. It’s a little different than password spraying. Password spraying is I have a gigantic list of usernames, and I spray summer 2020. Credential stuffing is we’re taking credentials that have been found through other means. Lots of times an organization has been breached. Think any number of the breaches that have happened in the past decade, you can go out and you can find those passwords list, MySpace, LinkedIn, boy, so many of them, gigantic ones, I’m trying to think, like the RockYou word list, things like that.

Mike Saunders (10:46):
These organizations have been compromised, their usernames and passwords are stolen, they’re posted online. Well, we can go and look those up, and the reason we do that is because humans such at making good passwords, and we reuse passwords whenever organizations let us do that. So I might have a password for Netflix, and because I don’t want to try to come up with a new password at work, I reuse my Netflix password. Well, if Netflix gets compromised and that password database gets stolen, now people know my name and they know my password, and if I signed up for Netflix using my work email account, which people do things like that all the time, I can now correlate a work user to this third party service and take their password and try it at their actual work account.

Mike Saunders (11:39):
And lots of times that works. We’re using those credentials in what’s called credential stuffing to try to get access into systems, and it works effectively many times. As an organization yourself, you can monitor for leaks of your own user’s passwords. There’s a service called dehashed.com, I don’t know if that price is still accurate, $129 a year to monitor for your organization. There are also other services. Troy Hunt has, what’s the name of that? You’ve Been Breached, is that what it’s called?

Tim Medin (12:15):
Have I Been Pwned.

Mike Saunders (12:16):
Have I Been Pwned, Troy Hunt’s service, can also tell you as an individual if your credentials have been involved in a compromise, and if you are an administrator for organization, there’s a way that you can signify that you are in control of the organization and then get records for all of your employees within that domain, there’s a way to do that as well. So you can monitor for all of them. But we don’t need all of the passwords, we just need one password to get in. That’s all it takes. We don’t need 100 accounts to pop, we just need one to get initial access, and many times that one password is all we need.

Mike Saunders (12:56):
So once we have a password, we’re going to move towards password spraying. Password spraying, credential stuffing are part of the same set of attacks. Now, the difference as I mentioned before with password spraying is we’re taking one password and trying it across a bunch of accounts, and having a lockout policy will not help your organization here, because we’re not testing one account with a bunch of different passwords. We’re testing one password against a bunch of different accounts. So we’re not going to lock any accounts out doing this, knock on wood, if we do it correctly. Nothing’s going to get locked out, so you need other types of approaches. If you’re familiar with Fail2Ban, say, for instance, with SSH, you can tarpit an SSH connection so that if you try to connect too many times from a certain IP, it’ll eventually say, “No, back up, not going to let you do that anymore.” There are other ways of doing that in other authentication systems.

Mike Saunders (13:55):
But a lockout isn’t going to help you. And once we have initial access, we can use something like DomainPasswordSpray from Beau Bullock. If we have access onto a system, we use that and we like to use that because it prevents from locking out accounts. In its default configuration, it will query the domain, look for the fine-grained password policy and then find out all the users who are within one failed guess of locking out of their account, and then it will not guess for those accounts. That’s handy to make sure that we don’t lock people out.

Mike Saunders (14:31):
Attackers don’t necessarily care so much about that, although they don’t want to give away that they’re there. But we do not want to cause outages, and you don’t want to lock out a bunch of accounts.

Mike Saunders (14:43):
If you’re on the defensive side of things and you’re here today, detection is the biggest thing you can do around password spraying. Prevention is very difficult. So detection is what you want to do, you’re looking for Event ID 4625, which signifies a logon failure, and you want to have some kind of alert when a certain number of events happen within a certain predefined period of time. And you’ll have to do some monitoring within your own organization to find out what that background level of noise is for regular lockout, because if you set it too low, people are fat-fingering their password all the time and your alerts are going to be going off all the time. If you set that number to way too high, so way too many number of events have to happen, you might not get notified if an actual event is happening.

Mike Saunders (15:38):
So this next slide is a screenshot, it’s actually between Tim and someone else that he was with on an engagement, but you can read it there, but the summary is that he did a password spray and he did fall 2017 on an external, a VPN, single-factor, no MFA, ended up getting successful connection. Once he had a successful connection into the environment, Kerberoasted and pulled a bunch of user tickets

Mike Saunders (16:12):
The thing is, it only took one password. That’s the beauty of password spraying. If we can do our OSINT and get usernames, and if your organization has predictable usernames, say first initial, last name. I wrote a blog article a while back about doing that password spraying against various services, and the first part is building a username. And you can build a list from census data to start out. If you just took the first initial and the thousand most common last names from census data, you have 26,000 possible usernames that you can spray against an organization, and right there is a good base to start with.

Mike Saunders (16:52):
And season and year still works. It’s worked for a long time and it’s still going to work for a long time, it’s the gift that keeps on giving. And one thing we really like to do, especially with remote, but also internally, once we have that one account and we have access to the network, the first thing I’m going to do is I’m going to Kerberoast and I’m going to pull all those tickets so I can start password cracking.

Mike Saunders (17:19):
So this case study number one kind of thing, do a password spray, and I’m trying to think which particular event this is, because there’s so many that have happened this way, but I started one in an external for a company, it was an external and an internal pen test, and on day one I did, it was a fairly small external footprint, not a lot of users, but I built a good username list and give it a shot. Single-factor VPN, password sprayed, got into the VPN, and from that point was able to join the domain, Kerberoast, access data on data file shares, access SharePoint, which is something very often contains sensitive data, and once we have credentials, we can get into SharePoint.

Mike Saunders (18:15):
We didn’t have to escalate, so even if we Kerberoasted and we didn’t get any type of domain admin accounts that we could crack passwords for and we didn’t get any access to any SQL servers or anything like that, if I can get access to SharePoint, I’m very likely going to get access to data.

Mike Saunders (18:33):
And in this particular case study, accessing PII, personally identifiable information that’s living on a SharePoint server, starting just from a password spray and a bad password, got all the information that that organization cared about from the SharePoint server. Never had to escalate privileges, never got admin, never got local admin, none of that. All of the information, the keys to the kingdom, or rather the most sensitive information for this company lived on that SharePoint server.

Mike Saunders (19:05):
So with that I’m going to turn it over to Tim, because he’s going to talk about Kerberoasting, because he knows a little bit about that.

Tim Medin (19:12):
Yeah, I just want to hit on one point here, a nuance that Mike said that’s critically important. We wrote this slide, I forget when, but I don’t remember which specific engagement this was for, because this is a very common set of steps. In fact, it happens so often, you’re like, “Name the one,” you’re like, “Really?” Narrow it down to, I don’t know, a dozen or so, right? This sort of typical path where we don’t necessarily have to escalate, we just go straight to the sort of important data.

Tim Medin (19:47):
Now, once you have access already, an important thing, sort of a first step, [inaudible 00:19:56], by the way, Discord, I posted a channel. If you want to dive more into the Kerberoasting attacks, we did a webcast a while ago, check that out. But Kerberoasting, what this allows me to do is any authenticated user or system, what I can do now is we can ask for tickets for any service account inside the organization. I’m not going to go into too much depth here because there’s just a couple of slides here, and we don’t have time to necessarily go into that, but I can request these tickets. These tickets are encrypted using the password hash of the target service account.

Tim Medin (20:38):
What this means is I can request any one of the tickets, I could then start cracking … What I might be able to do is determine the password for that underlying service account. So this is an offline crack for service accounts deep inside the organization that frankly, I probably couldn’t even talk to those systems directly. Maybe that database server is firewalled off and I can’t access it.

Tim Medin (21:09):
The key here is, this is important discussion I was having with somebody else, I didn’t get permission before I had to name names, but you probably know who it is, there’s a common misconception to do Kerberoasting, it only matters if that target system is privileged. That is absolutely not true. I could use that to access the data. Let’s say that SQL account is crackable, but it’s not a domain admin or even a local admin. I can still use that to probably access that data. I could do silver tickets. Again, feel free to check out the pair of links we posted in the Discord channel, redsiege.com/discord, if you want to check some of that out. But that is an important first step.

Tim Medin (21:58):
To do this, there’s a number of great tools. There’s Invoke-Kerberoast, the PowerShell script. There’s, I can never pronounce this correctly, Rubeus. We can use a number of different tools, we can use Mimikatz, whatever, to grab these tickets, and then Hashcat. Now, we’re not going to go through all the nuances of Hashcat here, because that would be, frankly, its own presentation, but here we’re using Hashcat with the 13100, that’s the mode for Kerberoasting, and we’re going to attempt to offline crack the password for that underlying service account.

Tim Medin (22:43):
Now, to go through sort of a second case study, very common method here is we gain access to a laptop. Think about the real world. If you read the Verizon breach reports, one of the biggest ways in is a phish. So essentially, for all intents and purposes, the bad guy is starting with access on your network. Not privileged. This could be Steve in marketing or Sally in accounting, it doesn’t matter who it is as long as there is some sort of access. And doesn’t matter how unprivileged; marketing should not have access to your sensitive data. But marketing can still request these tickets.

Tim Medin (23:29):
Now, a key sort of with that is the domain controller doesn’t decide whether it should give you the tickets or not, it just says, “Here’s the tickets you send it to the target system, let that target decide if you have access.” So then we could do the Kerberoasting crack, for example, and then the database password, access that database. And now we can start pulling out PII, financials, whatever it may be that the bad guy needs here.

Tim Medin (23:58):
So the bad guy wants are the important pieces. Again, they have kids to feed, they have car payments. They need that information. Their goal is not to get into your organization and then administer it, get to that domain admin. Now, if they get domain admin, cool, but there’s also oftentimes alerts around escalating privileges. Or they created a backdoor domain admin account, there might be alerts that are triggered that would get the bad guy caught. There’s no reason to take more action necessary to accomplish the same task. So what data is important to them, and then, frankly, get rid of it.

Tim Medin (24:46):
Mike had an important point a little bit earlier. If you landed, for example, on an engineering person’s workstation and you’re going after intellectual property, there is no reason to escalate. There’s exactly no reason to pivot, because the data is right there. In fact, escalation or pivoting might get the bad guy caught, or frankly, us as the penetration tester.

Tim Medin (25:14):
What we want to do is we want to demonstrate the risk if there is a breach. So even if it is the random lowly user on the network, if that data is littered throughout the organization, the risk is increased. So we will find this time and time again, in fact Mike has a fantastic blog post, I love this blog post, Finding the silver lining in getting your teeth kicked in. Both of us had this experience about the same time, where we had access as a regular user, we had a horrible time trying to escalate, trying to move, and happened to be that there was some of that data lying around. So we looked for some of those files and those shares on various computers, file servers around the organization.

Tim Medin (26:11):
Mike’s going to go to this more depth in just a second, but I’ll tell you a scenario. This was late last year, if I remember, and they were having a tough time, I was having a tough time. I was on site, they were doing a fantastic job with security, had a horrible time getting past the alerts for lateral movement, and then I just took a step back, I went for a walk, came back inside, like, “You know what? Let’s just look for the data. Let’s look for the important pieces.”

Tim Medin (26:40):
Now, this was a financial organization, would’ve had very wealthy investors, and in my case, and the users’, the way they were sharing data is they would open up file shares, and I found bank accounts and routing numbers all over the organization with balances that are significantly larger than I’ll probably see in my lifetime, these massive numbers. And from the attacker’s perspective, they don’t need all of it, they just need one of those giant accounts to turn quite well. So with that, I’m going to turn it over to Mike.

Mike Saunders (27:16):
All right, thanks Tim. So talking about searching file shares, it is decidedly low-tech and on the face value, not really sexy. However, I will tell you that I’ve had more wins just spelunking file shares than I have just about anything else, because that’s always the blind spot that companies have. They have to have file shares, and they don’t do a good job of securing them. If you’ve ever been a Windows administrator, you know that … Like once that’s out there, you’re never pulling that share back and fixing the permissions, you’re just kind of duct taping it and trying to make it work.

Mike Saunders (28:02):
One of the things we can do is we can go out and do that manually, and if you’ve done it enough times, you start to get that sniff test just scrolling through directories and be like, “Ooh, there’s going to be something good in that one.” But you can automate that as well, especially in very large organizations. Power View is a great way to do it. If you are going to use Power View, make sure you use the dev branch for PowerSploit. Do not grab the master branch, because that doesn’t have all of the features and updates. But PowerView is just a PowerShell tool that goes out and helps you get situational awareness. It goes out and it checks what shares you have access to. If you use things like the Find-InterestingDomainShareFile or, I think it’s Find-DomainShare, and you add -CheckAccess, what it will do, it will take the token for your current user that you’re executing as, and will try to access every share that it can find in the organization.

Mike Saunders (29:03):
And if it doesn’t have permission, it won’t even return that in the output. It’ll only return the ones that you actually have permission to access. You can use Find-InterestingDomainShareFile to actually give it some wild cards. By default, it’s going to look for things like passwords, sensitive, admin, secret, it’s going to look for unattend XML files, VMDKs, creds, things like that, but you can do really targeted searches. It will look at those shares, see what it has access to, and then search those shares for those kinds of files and then return back that output.

Mike Saunders (29:39):
So as an attacker, the thing to be aware of, this is noisy. Doing this, it is noisy, you’re going to be seeing a lot of network traffic. The thing is that lot of times people aren’t auditing access to file shares. If you put some canary files out there in your file shares and look for someone to access one of these files, and I believe that I talked about that in a blog not too long ago, it’s part of that GPP Deception blog that I had. But that idea of accessing file shares and putting a folder out there that no one should be accessing it, if someone does access it, that’s a sign that someone’s spelunking in your network and could be a sign for things to alert on.

Mike Saunders (30:25):
So along those lines, we’ve got another case study. And Tim mentioned that blog article about finding the silver lining in getting your teeth kicked in, and talking about apex defenders, and you can go on to the next slide there Tim. So with this idea of these apex defenders, these are really, really well-defended organizations. They’re people who have implemented good security, they’ve got good alerting, they’ve got good visibility. They’ve done both the prevention side and they’ve done the detection side, these people are deadly and you have to tread really lightly.

Mike Saunders (31:06):
And in this particular organization, I had spent several days trying to just get code execution, and I didn’t get anywhere. And finally I got a Cobalt Strike Beacon running, and within like a minute of me getting it running, the SOCK had alerted the customer that, “Hey, looks like your pen tester got a beacon.” And he’s texting me right after that, I was like, “Are you kidding me? Are you kidding me right now?” So I was not getting anywhere. Everything I was doing was being seen, except for these file sharing. And I just remembered I hadn’t found much for files, but I was sitting there after work one night eating supper, and I remembered there was this one file share that I thought was interesting that I needed to go back and take a look at, had these files that were interesting.

Mike Saunders (31:56):
And I didn’t know what they were, so I went and did some more research. And it turned out, these files are used by banks, if you look at X9.37 files. What they are are these files containing data that get passed between banks. So if Tim writes me a check, I receive a check, I endorse it, and I deposit, my bank scans that check and takes a picture of the front and the back, and then using the routing number and the account number sends that information back to Tim’s bank to get payment, and Tim’s bank has the copy, the front and the back of the check, to verify that that was correct.

Mike Saunders (32:37):
Well, these X9.37 files contain the routing number and all that information and also contain the scanned images of the checks. And I hadn’t found anything, and then all of a sudden I had tens of thousands of scanned check images, so then all of a sudden had a bunch of account numbers. That was something that was important. And I’ve actually found these in other organizations as well. So searching on those file shares, we find credentials to get us into systems. If you see a file share, very often, I don’t know why, but we find Windows IS servers with their [inaudible 00:33:14] shared out. And we can grab the web.config, which very frequently has a connection string in there to a SQL server backend, and we have that SQL server password. Well, once I’m on the SQL server, I have access to a lot of data, especially if that is for an SA type account.

Mike Saunders (33:32):
We also, though, have file sharing and looking for files on Linux systems as well, and in Linux, we don’t have PowerView, necessarily, but we do have the find command, and the find command … Oh, that’s interesting. We must’ve saved this slide before we updated the slide. Glad we spent all that time talking about it, Tim.

Tim Medin (33:58):
So a little break in the fourth wall, there’s that little thing in the corner. Mike and I were chatting back and forth, and it should not have been a discussion, it should’ve been delete and move on, discussion and then I didn’t delete it, so sorry Mike.

Justin Connors (34:11):
I also saw that and was wondering what it was and I just left it here.

Mike Saunders (34:16):
I figured Tim [crosstalk 00:34:17]-

Tim Medin (34:17):
Okay, here’s the deal. We’re going to turn this [inaudible 00:34:19]. So the code word to get in the drawing for a shirt, if you go into the random channel and type find/student, we’ll randomly pick some of you folks to give a shirt to, so that’s going to be our [inaudible 00:34:34]. This is not going to apply to YouTube folks, I’m sorry, too much time to do that, but if you are live, go into the random channel in Discord, type the find/student and we’ll randomly select a few of you to give a shirt. All right, so go ahead Mike, sorry.

Mike Saunders (34:49):
No problem. So we do have the find command, and the find allows us to search for files on local file systems or mounted file systems, if we might mount them, across the network. We can look for world readable files, and we use the -o=r, which means for other, the other group equals read, that’s world read access. And we look for certain files, like for instance, any type of configuration file, or files named id_rsa, which are of course your SSH private key files.

Mike Saunders (35:28):
We also, when we’re looking on systems not just for finding data but for finding ways to privilege, escalate, setuid and setgid executables, so you can search for these, and these will tell you whether or not you have files that are setuid or setgid which can sometimes be used to escalate privileges on the local system.

Mike Saunders (35:53):
When you’re on a Linux system, let’s say you have access to a Linux system but you have creds for a Windows system, very often times you can mount that Windows file share from a Linux system, and then search the Windows file share using the find command. So it’s very flexible and you have that power that the Linux command line gives you when you are in a Linux environment.

Mike Saunders (36:23):
So the next case study is talking about finding files. So go back one, Tim, there you go. About finding access to data on a Linux system. In this particular environment, Tim and I were on a pen test that had precisely one Windows system, and everything else was Linux, it was an entirely Linux environment. And I happened to gain access, I got shell on a Linux system through basically a default password in a NoSQL type database web configuration utility. I had shell access to this system, I didn’t have access to any other systems, I only had access as the user that this SQL server was running as.

Mike Saunders (37:10):
I used that world readable find command that we had in the previous slide, I used that command to see what I could see. It turns out that the server also had Chef on it, and Chef is a Linux orchestration type software that allows you to configure and administrate a bunch of different machines. And the Chef configuration was world readable, that’s what that screenshot’s showing you. That red box is the R and X. X means that anyone can change into that directory, and R means anyone can read it. So I could read the Chef backup files. Those Chef backup files got me access to MySQL usernames and passwords. From those MySQL usernames and passwords, I got access to some MySQL databases.

Mike Saunders (38:04):
And with those MySQL databases, I found incredibly large amounts of data. This particular one, I would connect to it and it would just hang, and I couldn’t figure out why. Well, I finally realized that by default, MySQL tries to cache all the table names, and so it was trying to cache the table names, I had to turn that off. And when I connected, I found that this one table alone had over 800,000 rows of data. We had over 1.1 million tables of data that were in, I shouldn’t say rows, that was 800,000 tables within one particular database is what that screenshot’s showing you. And in the entire breadth of their MySQL servers, we had 1.1 million tables of data to access. Obviously we didn’t have time to go through all of those during the test, but we very quickly dumped the output, did some search for things like PCI and password and things like that, and gained access to all kinds of PCI data, and their customers’ data that was stored in these databases.

Mike Saunders (39:14):
And that was the only escalation I had. I didn’t have MySQL admin creds, even, I just had permission to read databases with permission to read on a Linux file system, and that was all the further I got. I never moved laterally to another system as far as command execution went, but I didn’t have to, because I found the things that they were most concerned about, got access to it through a default password, and then bad file permissions.

Mike Saunders (39:43):
So this next slide is a quote from, I believe it’s Tim MalcomVetter, yeah. So, “I can’t believe pentesters, read teamers still focus on getting Domain Admin. DA is in most cases a waste of access. It’s inefficient, and if you’re modeling sophisticated adversaries, abuse the path of least privilege, usually the path of least noise,” and that is absolutely true. Getting DA is fun, and we still do the DA dance when we get it, and it’s still great, but don’t stop once you get domain admin. Okay, you got domain admin? When an executive looks at a report and it says, “Oh, they got domain admin, I don’t know what that means.” It doesn’t have any impact.

Mike Saunders (40:29):
But if you can show the executive, “Hey, here’s your Social Security number,” redacted, of course, in a report, or, “Hey, here’s all of your customers’ Social Security numbers and credit card information, why are you storing that credit card information? But if that information happened to be there, that demonstrates impact. Saying we got domain admin didn’t get us anywhere. But if we got domain admin, we should very easily be able to pivot into other systems and use that domain admin access to pivot towards that data.

Mike Saunders (41:01):
Going to turn it back over to Tim, he’s going to talk about another way of demonstrating impact. You’re on mute, Tim.

Tim Medin (41:12):
… am on mute, this is my day. Screw up the slides, screw up the audio. Very similarly, Jeff McJunkin, good friend of mine, very talented pentester, attacker, offensive person, very similarly to what MalcomVetter was saying, but kind of in a more practical sense in a way, was he described that getting domain admin is sort of like using cross-site scripting with the script alert. It shows you have access, but show me the impact. What is the actual impact? Yes, you can administer my network, cool. Can you get to the data? Don’t forget, the key here is that business risk. So very, very important here.

Tim Medin (41:59):
So with that, I’d like to thank Mike for joining me in this webcast, I enjoyed it. We’re going to take some questions. By the way, the slides and the recording will be available here at some point. I think Justin’s going to pop in and chuck some questions our way.

Justin Connors (42:17):
Yes, yes I am.

Tim Medin (42:20):
He is Red Siege, according to the video [inaudible 00:42:22].

Justin Connors (42:23):
The Red Siege. If I had a shirt, it would be … So I’m going to go backwards, hopefully I don’t butcher anybody’s names. But [Jay Sarkeesian 00:42:34], has anyone ever had that issue where you attempt to Kerberoast but get no entries found returned?

Tim Medin (42:40):
Yeah, I mean, that’ll happen sometimes if they haven’t configured some of those services to do it. There’s probably some that are, like some of the machines will do that themselves, but you don’t care about those because realistically machine account passwords are not crackable. So yes, it does happen sometimes. It just depends on some of the configuration, but by and large you will find some.

Justin Connors (43:03):
All right, [inaudible 00:43:03] said do you guys know any places where you can practice Kerberoasting?

Tim Medin (43:09):
No, but it’s not terrible to sort of build your own lab. So you can go to Microsoft, download the evals for Windows Server, for example. Build your own lab, set up the SPNs. It’s cool, because it will give you the sort of admin side on how to set some of those pieces up, and then use the tools to pull some of that back yourself.

Tim Medin (43:32):
I don’t know, are there some hack in the box, this might be a Mike and Corey question, are there any of the Hack the Box challenges where you can do some of this? I think most of it’s just build your own lab and test.

Mike Saunders (43:43):
Someone mentioned in the chat about a Hack the Box machine, maybe active? I’m not sure. Yeah, it looks back, here, it looks like possibly Active is the Hack the Box machine that does that. And someone also posted a link in the chat to DetectionLab, which is a set of Vagrant and Packer scripts to build a lab environment for doing various kinds of detection.

Tim Medin (44:11):
Nice.

Justin Connors (44:12):
All right. D. Medin says with file shares, have you guys found a good, efficient way of searching file content for files on massive file shares?

Tim Medin (44:20):
I mean, those just take time. It just takes time to search it. I mean, we can use the same sorts of tools, but it’s going to just take time to sort of churn and burn. If you can, run it directly on that system and search it yourself, it’ll be significantly faster. Less data transfer across the network and just quicker all-around performance. By the way, that, D. Medin there, that is the only other Medin I’ve met that I’m not related to, which was creepy when he came to the table at Wild West Hacking Fest, I thought I was being social engineered. I still think I may be. It may be the most elaborate con to get a shirt.

Justin Connors (45:04):
We got one from the GoToWebinar, it was not named, it was just from web. It says, how do we keep useful tickets and credentials artifact from remaining on the machine? Or is it a matter of changing the password frequently with PAM or MFA?

Tim Medin (45:17):
Well, so in this case, it’s not where the tickets are just sitting there, you’re requesting the tickets yourself so they will always be fresh. There’s also additional tools where I can request the tickets on a non-domain joined computer or within a user session and such. So it’s not like I’m finding tickets laying around that I’m reusing, that’s a different piece.

Mike Saunders (45:42):
As far as passwords go, there are various options, LAPS is one of them. There’s a few other things for using, some centralized password managers, CyberArk did it way back in the day, I know there are others, that will allow you to check out a password and then within a certain number of minutes after that password is used, the password is rotated automatically, so the passwords will never be valid for more than a short period of time.

Mike Saunders (46:12):
That being said, be aware that even if the password is changed, I believe the token is still valid if you have a session that’s active, so the password is changed, but you’re still logged in with that previous password, the token can still be used to access other machines.

Justin Connors (46:38):
And that, unless I am missing-

Tim Medin (46:40):
One more just came in. How much data do you steal to prove impact to the client? This is an important piece, and the answer is I want as little of their sensitive information on my computer as possible. Sometimes it accidentally happens, but I never take it. And the reason is, if I’m taking data out of PCI environment, now in a way, I am a breach. Medical facilities, I am not a doctor. I am not in charge of the care of any of those patients. If I take their medical information back to my system, technically I’m a breach. I can’t lose data that I don’t have, so I don’t want client data on my system, because then I can’t lose it. So I’ll take screenshots, immediately redact them to limit the potential impact there.

Mike Saunders (47:39):
Yeah. Another thing we do, for instance, with a web app type of thing, or even if it’s local and we have access to a SQL server is rather than selecting all the rows that have SQL, have, say, for instance, Social Security numbers in it, I will select the top one or top five rows, something, just to give me a little bit to verify that there’s actually data in there, and then I do a select count, rather than select the data so I can show a screenshot that says, “Here’s one row of data that contains a Social Security number, and here’s a screenshot that says you have 100,000 Social Security numbers in that table.” That way we don’t have all that data. We proved that it’s there, and then we just take a count of the amount of data that’s in that database.

Tim Medin (48:30):
Yeah, sort of related to that, I was at a presentation a while ago, and kind of a junior person was up there, very, very sharp, but he’s like, “I grab all the data,” he kept going on and on and on about how he’s grabbing all the data and using that to sort of shame them, and I raised my hand, I’m like, “Your liability, don’t do that.” He went on and on and on and it sort of escalated, like, “Look, you are a breach. You are not authorized to have that in your system, technically you’re a breach.” And it was sort of an interesting discussion there.

Tim Medin (49:04):
You can demonstrate impact, and I see this too, people say, “Well, I’m not demonstrating the impact unless I have it.” Now, if people can’t read the literal next step because I have portions of it or I have, if I have the count on my screen, if that doesn’t demonstrate access, why would it be any different if I grabbed the whole thing? So just don’t put yourself in that position, you don’t want to be the liability, you don’t want to be the risk. Again, I can’t lose data I don’t have, and I don’t want client data. Mike and Corey give me crap all the time because I’m deleting client stuff from internal repository sometimes too soon because I just don’t want to have it.

Mike Saunders (49:47):
Along those lines, when I am pulling data that I need to prove access, like sometimes, for instance, let’s say you’re doing a Cobalt Strike type of assessment, so all your operations through a beacon, a lot of times you have to download files to see what’s in the files, it’s the easiest way to do it. So you download these files. Those files are going to a VM. I am inspecting them on a VM, and when that assessment is done, I blow up that VM and I have a new VM for every customer assessment. That way it’s not on my base machine, I don’t have to worry about those artifacts sitting around on disk. I blow away the VM after every assessment, I pull down the very minimal amount that I have to, and then when I’m done, nuke it so that if something ever happened to my machine, I am not the breach for my customer.

Mike Saunders (50:40):
Jay Sarkeesian, what’s your go-to method for getting your initial demand foothold? Season year, season year, exclamation point. Password1, or welcome123.

Tim Medin (50:54):
Yeah, the passwords are, I love those. They’re the gift that keep on giving.

Mike Saunders (51:04):
Organizations are getting a lot better at patching the things that are really critical. We don’t find EternalBlue very often on networks, we don’t find remotely exploitable types of vulnerabilities that we can get a shell on a system very often. It’s mostly credential abuse is what we end up doing.

To continue getting up to date information on all of the live events, discussions, educational webcasts and giveaways – Please subscribe to the Red Siege Email list.