← All talks

Credential Compromise: Well what Now?

BSides Dallas/Fort Worth44:5243 viewsPublished 2021-11Watch on YouTube ↗
About this talk
BSidesDFW 2021 Track 2 Session 5 - 06 Nov 2021 Credential Compromise: Well what Now? An offensive and defensive look at user credential compromise. What an adversary hopes for and a defender prepares for. Nate ia a former sysadmin and Blue Teamer who turned to the Red Team "Dark Side". Nate currently leads a Red Team and lives in Dallas, Tx. When not identifying new attack paths, Nate can be seen having a beer in his garage or trotting his dog.
Show transcript [en]

hello everyone and welcome to credential compromise what now and often some defensive look at user credential compromise before we dive in here i want to provide a brief overview of what this is going to be and what it's not going to be so this is really going to be a basic overview of methodologies external attack mapping and really some tips and tricks for all level of folks i think there's something in here for for everyone and looking forward to diving in uh really this is a combination of things that i wish i knew when i was starting out my career in penetration testing and as i have evolved over the last few years what this is not going to be is a

step-by-step guide for offensive security tooling really in-depth methodology and it's not going to be a deep dive into red teaming and adversary emulation so who am i i am nate kirk i am based out of dallas i am a practice manager at praetorian and i specialize in network penetration testing and red teaming i've been in the consulting world for about four years now where i've executed lead and really dove into the offensive security side before i got into offensive security i was a cis admin and was a blue teamer as you can see i am a dog owner he might make a guest appearance in this and i am a non-certified beer taster you'll often

see me at some of the breweries here in dallas enjoying a beer especially during the fall now so background agenda so this talk has been on my mind for quite a bit as i started leading teams and working with folks that you know i was watching their shoes and had kind of sometimes stepped a little bit too far and wasn't quite ready and prepared uh i would often get the question and have the question myself of i've got credentials well what do i do now meaning attack path was successful especially with external penetration testing you end up with credentials but you're not really sure where to go next it's a bad problem to have but it is a problem

so this talk is going to definitely talk about that preparation part some of the attack paths that have to do with leading into credential compromise the post exploitation size side and also weaponizing ocean which is going to be a fun topic to cover um the agenda here is broken into two phases first starting out with the offensive perspective and then diving into the defensive perspective so let's jump into the offensive perspective so diving in preparation is key and really to kind of take a step back let's pretend the scope of an engagement or this engagement that we're going to hypothetically talk about is an external penetration test so we're taking the role of an external attacker trying to

get into either data from the external perspective or even get into the internal client or consumer environment um so really any external engagement like this i like to kind of take a methodical approach and first start with ocean pretty much every engagement should start with ocean and i think a lot of people are becoming familiar with ocean or open source intelligence gathering these days i've been seeing a lot of stuff especially on twitter talking about like do the post this picture of where you're at try to track it down um it's really awesome i enjoy doing that but there's also could be kind of a darker side of ocean and being able to weaponize it against an

organization so with that i usually start out with what's called like an external mapping phase and looking to see what i can find publicly regarding a client's dns kind of records looking for any kind of ip addresses um and then really diving into what their technology stack is and and what they're using uh as a platform it's especially important with understanding what a client's mail flow is as we start looking at some of the attack pads we're going to talk about uh some of this stuff is kind of boring and you know it's more fun to kind of dive into an engagement start kicking off you know any kind of vulnerability scanning looking for things to go exploit doing

some password spraying and guessing start sending out phishing emails but if you're not really prepared you're not setting yourself up for success and with that is just doing ocean and seeing what what you can additionally find um you know for some additional context we're usually given a scope for an engagement but sometimes when you're doing ocean you find things that are beyond the scope that should have been added to the scope in the first place or even that the client didn't know about and probably should so i always make sure testers are doing you know proper ocean and documenting as they go along with that kind of the more fun side is looking for employee names and

emails so that's diving into former breach lists meaning third-party breach lists not the client themselves but where their employees may have signed up for a service previously that was breached some of these are older there's some newer breech lists that have been kind of emerging over the last few years but regardless they are useful and then additionally social networking sites you know the classic linkedin go on and looking at people out there everyone does it these days easy to do so external mapping this is one of the keys to any kind of external penetration test this is a little boring it's a spreadsheet but i promise it's worth doing um it's it's really to stay

organized and not to overlap uh this is my way of doing it um folks folks i've seen do like cherry tree doing other types of pen testing documentation i've seen folks doing it on a word doc don't know why anybody would do that um i've seen some people doing it in markdown really as long as you're tracking and keeping a good clean list of where you've been what you're seeing and where you want to go it really should work out the reason why and the reason i recommend people use an excel sheet is because it's easy to filter and also you can really automate a lot of the stuff to feed into like an excel

sheet last year omar beta and myself presented on a jupiter notebook that actually spit out an osen document similar to this and you know you can automate nessus and other vulnerability scanners to output documents like this um for you to go through and then fill out um really it's up to the in person of how they want to do this this is my way of doing it but do highly recommend automating a lot of the structure so really we're just trying to map out where we could go and what there is and really read out the noise is the biggest part a lot of stuff we see on externals is either dead not accessible either

blocked off by our firewall or is just no longer in production um so it's good to get a lot of that noise out of the way so you can focus on what's important so building an analytical approach to an attack path so this is really just a fancy way of saying slow down take your time and actually plan something out instead of just rushing into an engagement and kind of executing as you go so really doing a good job at ocean and then doing that initial map of the external client we can start to see what can we leverage against them uh what can we weaponize and then also are we getting familiar with this external are

we seeing weird technology stacks are we seeing things that could be used as a pretext and phishing engagements and are we seeing other like hintful tidbits that could lead us to compromising users i am going to go a little bit deeper into this and provide two external attack paths that are still pretty popular so this first one is pretty fun um if you're not familiar with password spraying it's pretty much bulk password guessing where we're using the same password and spraying it again against a bunch of usernames or emails typically email accounts that stays the constant throughout so what that means is i take a password that's usually commonly used like season 2021 like right now fall or winter 2021

and then spray that or guess that against maybe a thousand user accounts that i find um it's still pretty popular it's becoming harder to do as as we'll talk about there's more defensive mechanisms that can be employed these days um but it's still a fun one to talk about so when it comes to weaponizing osm for this i see a lot of people just jump in and just start passing spraying things and when i kind of say hey slow down like kind of analyze before you attack you start to catch kind of hiccups with it and what i mean by that is you know let's say most organizations use office 365 these days great service easy to use

problem is is if you don't go and check that this the client you're targeting is using office 365 and you've been password spraying all day or even all week and you're not getting anything and you come to me and i take a look and look at their mx records which you may have missed and they're actually using google workspace i've seen that before that's why it's always best to kind of take a step back it doesn't seem like you're actually weaponizing ascent by knowing what their mail flow is and knowing where to attack and target and taking advantage of some of that it really is and same with password policies this is a bit of an oddity but have seen

it quite a bit of password policies being exposed externally so let's say there's a password reset portal or maybe some documentations leaking through an external help desk portal where it's not really sensitive but to the right attacker in the right mindset you could leverage it so instead of me guessing short passwords and wasting time on that and not focusing on you know what could be a complex password um it could just be a character limit where if i know it's above 15 characters i know it's above 10 or 12 i'm going to start tuning my guests my guesses to go after that so incredibly helpful as well other things especially employee names the more you collect and the more you

can target and attack the easier it's going to be to guess someone don't get me wrong password guessing is not always the easiest thing but you're kind of increasing your your odds with the bet when you increase the number of employee names you have to guess against so doing a good thorough job on ocean really pays off on this because what if you collect a thousand usernames or emails and it's just that one extra that's the one password you guess you kind of never want to leave anything on the table when it comes to that um breachless trends this is a neat one so like i was saying a little bit a while ago it's

you know these are pretty outdated these days i think the really common one we we've seen people use is like the linkedin one i believe that's three or four years old now three or four year old passwords have been rotated multiple times especially when you think most organizations have like a 90 180 day even a one year rotation those are pretty pretty crusty so what i tell most folks and what i've seen is look at trends meaning look at passwords that could be maybe a default password like welcome to company name um or have some sort of weird lead speaker complexity to them i've even seen and compromised users using like company name and year but the

company name is felt slightly weird and different like something you just wouldn't guess off the top of your head or even think about so sometimes weaponizing a breach list doesn't necessarily come from just doing an inline password spray of taking passwords from reachless taking user names spraying it can sometimes be looking and analyzing what that data is and really leveraging it in a meaningful way another thing you can often hear me kind of using email and username kind of mixing those two up sometimes they're the same a lot of times they're not so let's say for example my email address is nate.kirk at example.com makes sense but what if my internal like active directory username or just you know

internal authentication mechanism username is nkerk at example.com well if i go and password guess against nate.kirk at example.com all day i'm not going to ever guess that password or ever compromise that account even if i do guess the right password because you're you don't have the right username um so but if i do use that right password against that in kirk at example.com it would be the right username so taking that extra time to validate usernames or validate if email addresses are indeed their usernames does pay off a lot of times i've seen folks struggle struggle struggle and then all of a sudden hey just take a step back did you validate no go validate sure enough they

get an immediate hit off of like fall 2021. so sometimes it helps just take that extra step dive a little bit deeper and weaponize what you find um a lot of times i find username conventions off of um like breachless data where someone's you start seeing some oddities and they're like ah it doesn't match their email addresses i bet that's a username convention and even going a bit further and analyzing metadata from files that are uploaded like when documents are signed and then created or pdfs are rendered you know the username of the computer will often be rendered into that as metadata and being able to pull that using tools like power meta or pi meta

incredibly powerful to do and then another common attack i think we all know this one leading to credential compromise is email phishing this is always a favorite one because you can come up with different pretext or kind of the cons like the thoughts that that could get someone to to click um is pretty fun so with this um and weaponizing ocean on these are especially that mail flow again understanding what kind of tech stack they're using and being able to kind of tune and target what that tech stack is you know maybe there's a blog post someone just recently posted on how to bypass a certain flavor of a web filter or maybe there's actually an

exploit for one of those email filters or web gateways it's it's anything is kind of possible with that especially with external mapping as well so when you're doing that initial ocean run and doing that initial external mapping like we talked about earlier diving into that stuff makes a difference and looking to see you know you know going to the company website and like oh look they've got like their corporate events posted here i see they're all kind of drinking the same coffee here that's a bad example but you know looking to see what kind of pretext you can come up with based on that um some of them could be a little bit more evil like there's a

charity this company is very specifically involved in sending emails regarding this charity might look normal and blend in um you know you can find some interesting things off that employee profiling is also an interesting one um and and pulling as many names as you can in and then kind of dissecting those and and kind of building specific pretext for specific targets and that could be another kind of evil one that i like to do personally is target interns they typically don't have a good handle on information security yet depending on the industry and it's a little evil but but something fun to do and you can typically find and sort through these people using tools and and the right approach

to like linkedin for example i'm also kind of doing the high risk high reward stuff of targeting executives things like that so really taking that extra step diving into what you can leverage and then being successful could lead to a credential compromise so your password guessing or your phishing campaign was successful and what do you know you've got credentials well what now so with this i always feel like the room's on fire a bit and kind of saying to myself this is fine when i've got credentials and i'm a little bit concerned maybe the blue team's catching on or or maybe i'm going to get reported to help desk or maybe there's a sock analyst that saw something weird today

i always kind of tell folks and have to tell myself occasionally is it's fine um we got this we have the right approach we just need to kind of chill out and with that i usually do this in kind of a three-phased approach of burn weight and then leverage um so burn what i typically mean by that is burn your infrastructure really just remove it from the external side a lot of this is especially when you're worried about getting caught by like the blue team um this really applies to kind of more general net pin um like if you're having an objective with maybe the client that they want to test some some defensive capabilities and we're

trying to evade that or even some like really light red teaming this isn't really advanced red teaming stuff but didn't want to call it out there um really if you're just really kind of generically worried about getting caught with that burning meaning remove public access it makes it so much more difficult to triage where if you have a really good pretext and a really good fishing campaign when they go try to triage that they sandbox it what if the link's just dead and the pretext looks legitimate enough where they're kind of like i don't know like we should probably reset this person they're kind of slow about it instead of your phishing campaign is still alive and it immediately just

goes to like a fake officer 65 landing page or some like obvious credential harvesting page they're going to probably immediately go disable that account that person's compromised like this is bad or even if you're feeling a little bit more nefarious you can actually kind of do closed loop with a lot of these pretexts meaning the pretext itself once that user submits credentials it then forwards them on to a legitimate website that has to do with the pretext um or even once uh once you're done with this campaign like let's say you get 10 hits within a couple minutes a couple hours who knows but you're worried about getting caught by burning it you can just redirect your phishing site to just

go straight to like a legitimate website the redirect's a little funky but if some if it gets sandboxed and just hits a regular website that has to do with the pretext much more difficult takes more time to triage while you're having fun with those credentials the biggest part here and i think the biggest takeaway is kind of being chill waiting for things to simmer down mostly with yourself where you've got credentials don't get over excited don't start missing things and not leveraging what you've got just take your time leverage these credentials carefully so i'm going to talk about this more later on but timing makes a difference when using credentials let's say you catch credentials during the middle of the day

you might not want to use them immediately what if logging into something and you know triggering some alert ruins your day that that would not be fun if you get caught doing that or trip up some person and also like i said don't forget about all that pre-work you did with that external mapping and really just be prepared for the worst with this what if what if your credential gets burned immediately or something happens um that's it's always a concern so with this out of the way let's talk about the more fun stuff so let's say you've got credentials you're not worried about being caught all that's fine let's talk about the next phase um

authenticated information gathering so we've got credentials let's pretend this client's got office 365. i talk a lot about office 365 because you know the majority of clients and corporations we test are using it in some some manner even if they're not using it for mail flow it can still be utilizing it for some of the other services that they have um so like i say before kind of going for the gold and hitting that vpn portal what if we grab some additional information so if we do get these credits burned if the user freaks out resets their password something happens um we want maybe an additional way to get in or just more data we don't want

to leave empty-handed for the day we can go after azure and off dro 365. granted you know these don't always work depends on the maturity of the organization depends on if pin testers before you have found this but i'd say like 60 percent of the time i find some gap here and the gap is within conditional access policies with with azure and microsoft online services um conditional access policies if you're not familiar kind of think firewalls for your services pretty easy to set up they're a little tricky they're mostly turned on by default now so if you have a new tenancy in office 365 they should be turned on but if you haven't set if you have an

older tenancy these were not originally turned on for all services the biggest gaps i typically see is with the az module and the ms online module with powershell being able to kind of hook into those backend services and being able to query them the same with office 365 exchange web services or ews which is kind of a legacy protocol can still be leveraged to go hook into office 365 and pull some good data also have to say it's still looking at you on primo w and ews just because you migrated to azure and office 365 for mail flow does not mean your on-prem stuff doesn't still work um have seen that oftentimes where really good set up in office 365.

great conditional access policies can't get anywhere you look on-prem and oh no owa is not protected i can just log in and do whatever i want concerning i really wanted to call out here a huge call out for daftac highly recommend if you're interested in this kind of stuff and interested in the office 365 realm which i'm talking about here go out and check out his github repo great stuff really great tooling and really appreciate his support with the community over the last few years so with that i want to kind of call out one of my favorites here and some of the you know kind of post exploitation you can do with this information gathering

um so this is leveraging the ms online powershell module um could have mfa enabled could not always worth trying um the specific commands you can find out in davtax cloud cheat sheets really interesting and helpful stuff this is just an example here of the connect msol service where you actually connect up um typically if they've got mfa you'd be prompted you kind of know when to back out um and then this is the command like getting the msl user command where it pulls down just by default the user principal name which would be like that sign in or username um and then also the display name um kind of interesting rate you can take these offline you've got all their

usernames now so let's say you've got 500 from ocean you've been password spraying you pop five or ten well now all of a sudden you've got maybe a thousand fifteen hundred that you didn't have and it broadens that you know capability of you spraying and popping more accounts and potentially finding other users maybe more powerful users with a bad password set um really that's kind of known but some of the more interesting things is if you do the dash all with the get msol user command it will pull all attributes that are synced up to azure that meaning it is optional per client so some clients have different things some just check the box of like sink all

attributes have fun some are more selective about it it depends on like the the organization right like there's no right or wrong way to do it um but some organizations do sync up phone numbers addresses job titles of the person even supervisors uh names and addresses and and contact information talk about kind of social engineering haven where you all of a sudden have a lot more detail a lot more context to people um i've had successful engagements where we're stuck on an external manage to get account get into this kind of data all of a sudden we can start calling people trying to capture mfa tokens doing things like that and really escalating off of this kind of this point here

another thing which is probably my favorite subject with this is the description field if you've done internal penetration tests before maybe you've seen the description field containing passwords where that same description field gets synced up to azure id contains the same password probably my favorite example of that is we were doing an engagement organization up there had synced the description field with service accounts as well so they were syncing up pretty much every user of the azure ad including all their service accounts pretty poor service account management where a lot of service accounts were da's they were syncing their da's up their sync to service account up there with the password in there that was a da

that dea was also a global admin in azure and office 365 so we've owned that and then sure enough no mfa on their vpn for service accounts because they're non-human and all of a sudden we're inside their environment within the week as a da it's you know it's interesting the kind of stuff you can see and granted that's not every engagement right but every engagement if you do the same steps over and over and kind of build out state to a regimented methodology but still be willing to try new things you'll eventually find cool stuff like that and be able to laugh and kind of reflect back on that like now for me so i didn't want to call this out as

well a little bit harder as a lot of the services that are used by these tools do have mfa most of the time but it's always worth trying um even if you're on a blue team and want to see what some of this does it's mostly all passive um but definitely worth a shot trying to do when you have credentials um some great tools recently released over the last couple years with azure hound aad internals and then really some of the broad ones like scout suite and road tools these are great for kind of mapping out attack paths where you have a cloud foothold and are looking to either get internal or just looking to compromise

additional entities up there so moving away from cloud moving to kind of the on-prem side so remember this attack path i was talking about earlier the attack tech mapping here or external mapping um knowing where you can log in ahead of time is pretty much crucial to this um so you've got credentials you're kind of chill you've got you know where you're going to go all of a sudden you take this big long list like let's say you've got a thousand and only like 20 were logging portals you can filter this down now you just have a nice long list of where you can go log into you're not scrambling trying to run like go witness

or eyewitness trying to find all these random portals once you have credentials and you're worried about a blue team blocking you out you know exactly where to go from the get-go once you have the credentials so doing this initial mapping phase is so important um and also then knowing um when you should log in or should you log in um we're about to jump into that but timing can make a difference um especially uh with uh mfa pushes where if you're gonna start sending push notifications at the wrong time could get you caught um but also like where should you log in i just say try it all and try it with every single account that's the biggest

thing so if you pop 10 accounts but one account is you know maybe a new user that you're not aware of all of a sudden that one account didn't enroll in mfa and you've got internal access off the vpn for that but the other nine accounts are set up properly they're good to go they're kind of longer term accounts but that one account and if you log in the first time with one of those accounts or like ah they've got mfa i'm done with this if you don't try every account you could leave something on the table and miss out on an opportunity so try it all try it everywhere but take your time and and document it

as you go don't miss screenshots so fun topic mfa workarounds so you've got the credentials you know where you're logging in dang they've got mfa set up multi-factor authentication um so let's say we're targeting their vpn portal um the timing is key with a lot of the stuff um let's say you hit an account at 11 pm at night and this person's on the couch watching some tv they're like i didn't just sign in that's weird i should probably report this um or you hit it during the middle of the night and they're asleep and you're just sitting there push push push why isn't this person hitting approve it's like well it's middle of the night

they're asleep so timing is key i like to target right in the morning and right around lunchtime so right when they're signing on i looked on linkedin figure out where they're living um or even using some of that authenticated data i found from from azure 8e or ms online and look okay they're in central time zone i'm going to hit them right at 8 30 9 a.m central um oh they're on east coast i'll get up an hour early try to hit them then hit them right after lunchtime so when they're coming back it's just all about kind of getting in that repetition of you know when they sign every and every day they hit that

approve it just blends in with their normal activity you want to avoid that suspicion especially when it's more like adversary simulation or doing you know some lighter red teaming source ip restrictions this is an interesting one so let's say we just want to bypass mfa completely when you're on prem and you're working do you notice you don't have to do mfa as often depending on the organization you're at that's because they have conditional access policies or have policies in place on on their you know authentication provider allowing certain ip addresses to kind of bypass their their multi-factor authentication which makes sense you would assume someone coming from an ip address would be trusted but what if they're evil what if what if

it's me that just pulled up in your parking lots hanging out on your guest wi-fi what if your wi-fi is active directory integrated with no certificates and i can just go sign into it and go out through your regular internet what if i did that what if what if you have it region based where anybody from the u.s can just log in seeing that bad idea but definitely start thinking okay i can't get around these push notifications what if i try something else that's within reason and within scope of course but it's something to consider and put on the table if it's the right engagement for that um you know man the middle mfa interception is becoming popular these

days and it's becoming pretty mainstream to be honest um i it's something that kind of i didn't think would work and all of a sudden it started working a few years ago and now there's some really cool tools and offensive uh security tooling that that works great for it for proxying these connections like evogen x2 is a great one i'd like to call out it does take some tweaking and tuning and some some of that external mapping right um you know evil james 2 uses specific fishlets that are very highly dependent per each organization and if you use the wrong one it's never going to work or even take some tuning and building and kind of customizing to get it to

work and it takes that additional step to get it working properly so a little bit so kind of increasing the fun meter here mfa enrollment and account takeover so let's say organization has its mfa enrollment exposed externally it makes it convenient it's understandable could it be abused absolutely so with this there's really kind of two trains of thought with it um especially the way that i like to approach it is i go after people that likely have not set up mfa yet and are likely going to fall for a fishing campaign it kind of falls on the same side of the the road here again evil with interns a little bit evil with new hires

you know with with these folks and what i've seen in the past is interns are kind of short shorter term employees and likely just kind of keep hitting the i'm just going to put off enrolling in my mfa for another couple days and that couple days turns into a couple weeks if it's not being enforced properly or not enforced at all same with new hires where if you have typically a 12-day grace period i'll try to find especially a large organization that are hiring on a lot of people at the same time i'll target those groups of people hopefully get one of them to either fall for a fish and then try to enroll myself in their

mfa and take over their account in the middle of the night so they have no idea i've locked out their account but it's the middle of the night signing the vpn establish persistence in some manner move and then i'm in um or over a weekend where they just don't think about it um another one that's a little bit higher risk higher reward but i'm seeing less of these days which is good is executives that just don't want mfa um and they get some sort of pardon from security governance not to have mfa or a strict password policy um it's becoming less common but don't want to call it out it is higher risk where these people are becoming better trained

um there also have more security controls around them there are some organizations that strictly watch executives and it's even a service now from some people like a premium service a little bit higher risk but higher reward where if you do compromise these people they don't have mfa all of a sudden you're the cfo that's pretty wild so high risk high reward up to you to try and up to account of the scope and the limits you've got so ramp ramp up of the fun zone here gaps in mfa we did touch on this a little bit earlier really if they've got really good mfa everywhere you just want to try to find the holes in it

especially when it comes to like conditional access policies just finding that little tiny gap is a big one sometimes it has to do with ews like the legacy protocols that you people just aren't disabling because there's some weird application that needs it um that works a lot of times um legacy infrastructure that's on prem where they think it's shut down but it's really not or they just kind of forget about it it's just hanging out there like those on-prem exchange servers i was talking about even on-prem sharepoint services where it's like oh it's fine it's shut down but it's really not and then going a step further with that the decommissioned infrastructure these are probably my favorite kind of

attacks where after you're done with it and you jump on a debrief call and they're like no no no that's that was shut down years ago i don't know what you're talking about and then pull up your screen you walk them through kind of a demo of it and they're like getting on the phone with the sysadmins and security immediately a couple examples of this would be as you're going through and mapping out that external phase of kind of marking down like this is pretty weird i want to go back and double check this especially when it comes to remote access and like rd gateways and then like old horizon view instances things like that

um a lot of times these were spun up and then spun down rapidly when the work from home craze happened and they maybe just spun them down but didn't completely clean them up one of these examples is an rd gateway that i found um i actually found it i think over it was earlier this year and what it was was the the actual login portal you know within with a standard rd gateway to kind of takes you into a vdi pool it's the standard microsoft one when you sign in takes you into like an rdp pool you can launch out when i signed in there no mfa but there's nothing there and i was like

okay this isn't anything crazy but i started thinking about i was like well this thing is like these technically can be used as like an rd gateway itself um meaning i i'm not launching like a vdi instance or connecting through it like the web interface to like a known remote desktop instance somewhere else but i can actually use it as like a gateway into their environment so what i did was i actually pulled some of that azure information earlier you can go further than just users you can pull computer names as well so i pulled computer names started looking at those found what looked to be like a vdi server internally and could do a little bit of enumeration

because you can look at groups in azure 80 as well figured out i was in one of the groups that had access to that server and then actually use that external rd gateway to pivot in and connect to it through like an rdp client pivot through it into the internal and then connect into that vdi server and sure enough had immediate access no mfa jumped on a call with their tech team and they couldn't believe it so there's there's oddities like that and to be honest it's sometimes worth trying um and it's the one out of a thousand chance but if you do a thousand engagements you might end up coming across it another interesting one was i hit a it

was an external um vdi i'm not going to name the vendor but there's an external vdi type of system and it appeared to be defunct and completely decommissioned but the weird thing was is when you'd hit it it would just kind of throw weird errors the page would render but it's just not happy um and when you tried signing in it would just say like dns name not found it was just strange um so i i ended up looking at the certificate that was expired on it and found out what the uh found out what the dns name was for that host and it was like just say like vdi1.example.com i then modified my local hosts file to

vdi1.example.com at the ip address that that thing was sitting at rendered the website again sure enough logged in the first chance had internal access off that same kind of i talked to their tech team and security team they couldn't believe it they're like we thought that was shut down we tested it last year none of us could sign in we thought it was dead but we were leaving it up just in case how did you figure that out it's just it's just digging a little bit deeper and having that external mapping kind of laid out with kind of question marks of like if i do get credentials and this is my one chance getting into the environment

am i going to leave it on the table that's kind of you know the vibe with that of make sure you follow through with everything you can

so diving into the defensive perspective um the preparation is key i know this sounds familiar but and it's always easier said than done of course but having good patch management and inventory management externally and even doing that external mapping exercise like i was describing earlier where you really do map everything out and have a good foundation of what's out there whether it be the it team or the security team or even a third party such as penetration testers it should be done fairly often um especially when it comes to like i was describing earlier with jumping on some of those debrief calls and and the number of times i've heard oh that shouldn't be out there it's not

insurance when you show them that it is it's it's shocking um and then that validation and verification of is it really decommissioned is it really being used should it be out there and minimizing that external attack surface as much as possible so this one this one's some a topic i enjoy talking about especially with with a lot of the new technologies that are out there so enforcement through technology is not policy i know this is a touchy subject but wanted to call it out um a lot of organizations will roll out policies you know more written policies of saying hey don't set passwords to this send them to this don't click on phishing links don't do this don't do

that you always have the one end user that will ignore that and just kind of type the password to get the green meatball and the check mark at the end of the day it's best to enforce these things through technology controls or technical controls the first here on this list being password length this is kind of a hot topic these days i'm not putting any direct recommendations here as i know nist has some different guidance there's other folks that have different guidance really what i would encourage is looking at at least 12 characters anything that's 15 characters and above is better mainly because it makes it harder for me to guess if it's 15 characters i'm gonna

have a tough day if it's longer than that i'm going to have a really tough day also reducing that password rotation um to make it easier for for the employees so you know technical controls have to go in balance with the business so there's always that trade-off of what kind of controls do i have placed to make the bat you know that balance and strike the balance with with you know the user interaction with this um what we've seen really success with is increasing that character length and reducing the password rotation you know accommodating if you're having to memorize a 16 character password only do it every 180 to 365 days um it makes it a lot easier for folks to

remember and it encourages them because they hate having to change it every 90 days if you entice them with that hey you only have to change it once or twice a year but it has to be longer they kind of go they start to enjoy it a bit more especially when you can do some fun sentences with it and encourage that kind of usage um the biggest piece here that i hope everyone takes away from this is those two things will not work password rotation or password length and password rotation if you don't have good filtering in place and that is a technical control so what password filtering is is essentially just saying you know having

a technical control there there's like azure id password protection or identity protection i think that doesn't an ad azure id these days don't quote me on that one i always mix up those services names um but what it does it says hey you can't set your password to this list of passwords that are just bad and sometimes it can be customized most of the time so if it's company name one of those weird companies names i was seeing in the breach list you can suck in entire breach lists um really when you're preventing them from using the guessable passwords my job becomes almost near impossible of trying to find those it becomes incredibly difficult to find

a 12 character password that's not something commonly used it becomes a lot more targeted and i have to start relying on other methods so jumping in here um i think we all know i was going to talk about this next is mfa enrollment and enforcement of mfa mfa should always be enforced on pretty much every service or the majority of all services especially those that lead to any kind of data or internal compromise for all employees from day one um part of the on like getting people online and part of getting them enrolled into the organization should be signing up for mfa that first day a 24-hour grace period the whole 12 to 60 day grace period

just opens up the opportunity for an attacker to try to find those people and take advantage um same with when it comes to enrollment do not set a standard password for everyone i will find it and i will leverage it to compromise as many accounts as possible it's also a pretty bad one mfa enrollment try to keep it internal if possible i understand the external side but it kind of comes down to that you know ease of business and ease of user interaction so if you are exposing it externally definitely stick to that one day enrollment period and also when it comes to enrollment allowances where i don't know the person lost it how do they reset it can they just do it

online those security questions can be guessable there should be a manual process on that where they they have to talk to someone with phone in hand and a manual verification process and the big part with this is make sure help desk is following it as a penetration tester and red teamer i have had interactions with helpdesk before of resetting passwords and accounts where they do not check who i am i am not susan from accounting i am nate from praetorian and they don't check that kind of stuff and they will reset susan's password who i have and then reset her mfa for me because i'm pretending to be someone i'm not that kind of stuff is weird to say but

is is pretty common um so make sure helpdesk is following that those kind of policies and procedures and then of course i have to do a few plugs here practice does make perfect any kind of internal or external penetration testing meaning a third party or an internal team of doing these kind of penetration testing and doing these kind of reviews and it really doesn't even boil down to penetration testing or offensive security but even just doing like third-party reviews and bringing in the subject matter expertise when you need it i'm not an expert on office 365. i sometimes consult with people that do and can help me and guide me through situations and i'm nate i hope organizations do the

same where especially talking about the conditional access policy stuff these days where a tiny gap could cause an entire compromise of an organization of looking and reviewing that kind of stuff and not just office 365 but doing that for cloud providers hosters your on-premise infrastructure things like that of bringing in the people to make sure it's properly secure and organized and clean um also reviewing any kind of policies and procedures for testing and making sure that it's collaborative and making sure you're scoping it properly and getting the correct help um and you know that is a touchy subject but did want to kind of bring it up of you know make sure it's being driven for the right reasons

it's not a checkbox each year but it's a way to get better and to push the organization to to become more secure and part of that is you know real adversaries aren't looking for a check box they're looking for a compromise um granted it has been kind of the world of low hanging fruit these days but eventually that's going to run out and some of the more mature organizations will have have a lot of trouble so with that um i do want to give a special thank you and shout out to adam crosser and thomas hendrickson appreciate the support on this and the kind of sme review that that i really appreciated um as we're

kind of wrapping things up here i'm going to be online feel free to reach out to me especially on discord i'm going to be on um all day watching the the other talks and and being interactive if you reach out to me on discord after today i should be able to respond but i'm always available on twitter check out my github i have a few things out there not much i'm going to start contributing more in the future but really i'm going to leave the rest of time for any kind of questions and appreciate everyone coming out and appreciate the besides team for accepting my talk this year so hope everyone has a good one and enjoy the

rest of the talks

you