
okay we will go ahead and get started and introduce our next speaker so next we have with us mr michael music michael is a usf computer science alumni and current graduate student at the georgia institute of technology he has experience performing analysis for and developing detective capabilities for fortune 500 companies and currently works as an offensive security engineer for international telecommunications company his main areas of interest are c2 malware offensive security tooling and how to detect them so with that being said i'll go ahead and let michael take over for his presentation the hole in your sock a look at how a compromise of your sim could be a disaster for your organization take it away
all right can you all hear me fine
testing testing good mic okay cool let me share then y'all are gonna see the uh infinity um inception screen share for a second okay how's that can you see just the uh just the prezzo yes i can okay cool alrighty uh that was a good introduction i there's gonna i do have to make one edit i think i submitted this talk she's probably a couple months ago and i've sent i've since switched employers so it's a little outdated but i'll catch you very much speed but thanks so much for the introduction um thanks everyone for joining and um of course thanks besides for having me so i'll jump right into this i think we've got like 45 minutes if we want to
allocate time for questions so um i'm going to try to try to make it quick i did prune down these slides quite a bit but there's a lot to talk about um so strap in uh to hear some of my uh hopefully coherent babbling about your sim and how to compromise it of your sim could be a disaster for your organization take a hole in your sock okay so i kind of want to run through the agenda real quick go through a road map what i'm going to talk about um so i'm going to start off by doing another introduction myself go over you know what i currently do and some of the things that i'm interested in
and all that all that jazz i'm going to do an overview just just talk about the topic talk about um why you would why why i want to talk about this and talk about some inspiration as well a little bit before that so how i came up with this idea and um you know why talk about attacking the sim and it's honestly the inspirations are for the most part they have to do with my my own mistakes as a as a sys admin um sysadmin mindsets as like a developer and and um as a security practitioner and then talk about why attack has attacked this him why would an attacker even target the sin and then talk about
the malicious use of the sin like what could an attacker get out of a sin you know if they were to compromise it and then also talk about prevention because i don't want to be the guy who's talking about some offensive related stuff and all the bad things that could happen and not talk about good things and how can we prevent it and and all that kind of stuff i don't want to leave anyone hanging i just think sometimes that's um that's bad taste right and another thing that i noticed about 30 minutes ago is some of the colors might be a little odd i noticed that i realized when i was developing the presentation i typically
do it at night so like my screen uh colors are are dimmed and i really only realized that some of the colors were purple um as of about 30 minutes because so bear with me if any of the colors are messed up so who am i uh well my name is mike music you can call me music you can call me mike you can call me michael it doesn't really matter but typically i go by mike i'm the i'm currently the threat management lead at rely quest i when i submitted the talk as well further said i was an offensive security engineer at a telecom but what i do right now i realized was i
pretty much lead a cross-functional team that we call threat management we we're really like a stock oriented research development team we focus on like threat intelligence developing detection signatures threat hunting party threat emulation and stuff like that i really work with a rockstar team um and within an organization that's really taking on some big challenges in security world so it's fun stuff um i've worked on the blue team i've worked on the red team for some years i'm still a noob right i've only been in security for geez maybe five years now i the time flaws i'm a usf cop site undergrad i'm currently a georgia tech grad student um for undergrad i refer for my grad
i graduate degree in studying cyber security i've got a few certs suck plus oscp osce which i think is now defunct but i have to double check um i've got a lot of different security really good interests mainly like c2 and malware detection and signatures how to catch the c2ml where um automation like i'm kind of a noob programmer but i like to automate things then lately i've been kind of dabbling in the threat intelligence and i realized as i was writing this list that a lot of the stuff that i i'm interested in i actually end up doing in my day-to-day so really really fortunate i'm really fortunate for that so that's about me
let's talk about the inspiration let's talk about why i want to discuss attacking a sin and what an entire could get out of it and really it boils down to um to a few of the different mics that that i've uh that i've become over the years you know usually due to my uh lyric layer eight issues like my own my own mistakes right we've got three different mics here we've got developer mic we've got early morning mike and we've got sysad and mike and i don't make these mistakes too often so don't think that i'm i'm just an insecure individual that can't be can't be fixed i wouldn't say these are systematic errors but
i feel like these are mistakes i made and when i made them i was thinking oh geez um this is this is not a smartphone this this this could end up like tainting logs and getting into the sim and being really valuable for an attacker so i'm gonna step through this real quick and just some scenarios here so you got a developer mike which is uh he's the guy who uses that script he wrote and when he's doing it he passes spreads in the clear as like arguments or something he's also the guy that writes quick scripts or new things or maybe downloads the latest offensive security tool for github and it's using it for a pen test
or something and he ends up hard coding credentials into that script and running it and thinks okay great so it works awesome that's uh that's developer mike that's the mistakes he's making then you've got early morning mike who maybe hasn't quite had his coffee yet he's the guy who's uh he's logging into the vpn to get into his regular infrastructure or he's logging into his workstation or something and he uh he's he types his username and he also types his password into the username field and um and ends up submitting that and sending that over to uh essentially sending that over into the sim he's the guy who tries to hunt down that long before he starts to talk and find
him in harassment
and have to go you know reset my password immediately and then you've got sis adding mike um he's the guy who misconfigured services he's the guy who's um who sends credit over over his ansible playbooks without the no log flag being set or he like writes an answer playbook that basically uses the creds like a command line a command line play and ended up passing him in the clear and logging them in the clear and he's also the guy who uses software quite frankly for cash that it's just not meant for so these are the kind of situations that i've been in that have caused me to think about this problem and um and then
i have down there what these all have in common well i think these are all common behaviors as bad as it sounds um we talk about security best practices we talk about you know making sure you're using the no log flagging hands while making sure you're um you know making sure you're not passing uh your credentials in the clear to rise command line arguments but honestly it happens sometimes people make mistakes and all of these behaviors contain log files and those tainted log files can end up making their way to the sim and once they made their way to the sim they basically become a treasure drone of data for attackers whether that be an
external attacker or even a malicious insider that you trust with the same access so that's kind of what all these scenarios have in common here so now that i talked about um why i thought of talking about this let's talk about what i'm talking about um so the objectives of the talk is really to um i'm not going to scroll this a little bit but i really want to talk to talk to you all about ways an attacker could abuse sim access i'd also like to talk about different ways that unintended data leaks into log files or how even intentionally log data can provide valuable context for an attacker um so two kind of different
scenarios one that you didn't mean for the data to get logged and two of the days being logged you intended for it to be logged but it's just valuable for attacker and then i also like to discuss how defenders can protect inside of the activity um like i said i don't want to leave everyone hanging it was just hey you're pumping data into your sim an attacker can use it don't leave you with that and why talk about this why why should why should we as security practitioners or as people with access you know to the sim or people who are engineering their sim uh think about this honestly sometimes you get so lost in
the day-to-day analysis within the sim whether you're like an analyst or an engineer doing back-end stuff or or something like that you kind of forget how much value it holds um you just log in you look at the latest alert you you know you go into the send you find the activity you write up a report find out it's a it's a false positive and you you're like okay whatever you kind of kind of lose sight of just how valuable it is as an asset um red teamers and pin testers um i often think they don't think about the sim i know i've uh kind of theory crafted before on some regular engagements i'm attacking it and
usually i was the only one to bring that up um of all the value that it holds um so red teamers can definitely use it as part of their um their operations part of their campaigns and it's it's valuable um also it's just an alternative perspective to the system i think that um sometimes just getting an alternative perspective is very useful and honestly because security organizations they are targeted that is a reality um there are plenty of adversaries out there that are that are specifically you know targeting security practitioners at you know at your organization it happens so uh why attack a sim well why not um while i go through this i'm kind of
gonna be approaching it from an attacker's point of view but i'll flip flop here and there a sim is a data order stream it's a treasure trove of data like i said before it's got all kinds of rich targeting data so you know it's got ip ip addresses for your organization cider ranges host names users um basically everything you would want for targeting as a as a pen tester or red teamer or as an adversary it's got vulnerability information some of that is um stuff like volume scan data that just gets pumped into the sim uh from nessus or you know tenable or i guess back in the day security center um or it could be information that
basically implicitly implies that a vulnerability exists not really explicit like the gold data it's also got a list of basically every security product you own hopefully if you're adjusting to the sim attacker can identify that you have that product it's got sensitive information um so you know in some situations it has credentials that are kind of leaked into logs it's got pii that's leaked into the logs it's got application logs that could give an attacker context into the applications configuration errors it has stuff like that and of course it's got your employee and your user traffic right so um that's super valuable and i think sometimes that's overlooked right like you have access to all of
your employees a lot of employee data that's that's um you know person identifiable and personally connected to them that's really valuable of course uh you probably have some type of user data there as well if you're selling a service then it's also useful for disruption and innovation like you know if you get access to the back end of the sim you can access all the different components you can deploy bank somewhere um you can use that as a pivot point for you know further attacks you can uh use the data in there for extortion you can obviously just steal the data and sell it or use it from up from other nefarious purposes and you can also kind
of evade defenders better because of the type of information you get from the sim this is also really compromisable like it's not immune to compromise your sim is not invulnerable um sometimes there's lag but there's really relaxed controls there's like a lack of multi-factor authentication oftentimes there's outdated clients used to connect to the sims there's site-to-site connections that you use maybe for your vendor to connect to a customer's sim and sometimes really widespread some access is necessary for the for the correct logging it's kind of usually got a large user population within the sim so like stock analysts need it back-end engineers contractors and vendors need access so there's typically a laundry list of users that have
usually privileged access to it and it's also not hard to find the sim on the network right like when you're scanning for splunk it's if you know exactly what ports to scan for um you can look for you know service counts that can imply splunk that you know the location of splunk you can look for you can perform all kinds of ldap queries to find similar information dns recon like it's not like the sims is it's not is is difficult to find on the network and of course the last thing that i haven't really listed here is that sims do have vulnerabilities like there have been plenty of instances where an actual like rce exists on the sim or
some other type of vulnerability exists on a sim software itself don't assume your your security controls are you know i mean so last little slide that's not just absolutely chock full of information before we get into it i'd like to introduce music music's law um and it's really just kind of a joke here but um this is the law i wrote up the more valuable your sim is to your defenders the more valuable it is to your adversaries and i think that's that's really true the more money you pump into your sim the more valuable shouldn't the more valuable the asset it becomes the more value an attacker could gain out of it um should they be able to access it i've
also got a nice graph here uh and a little meme for the meme tax and the graph for you know to satisfy the c cells out there so now let's talk about the malicious use of the sim or things that defenders already know a lot of the stuff if you work in the blue team i'm using slug for all my examples because it's what i got said in my home lab it's pretty common um if you're working with funk you probably know how to perform these queries you're probably pretty familiar with the data but a lot of you know red teamers out there they may not be familiar with it um and it also may just
offer a new perspective for defenders so i kind of broke out of different sections like target mapping credentialed that data theft stuff like that the first one here is target mapping and really you can basically map an entire network uh just you know your target's entire network if you're an attacker just by using send access without ever sending a single packet so getting access to the sim provides attackers like a rich list of ips sites host names domains etc you can also gather system function information network topology information segmentation context hardware and operating system information and sometimes there's an entire list of admins critical systems and of course the i.t stack in use at the target organization
and really all this is gathering all this will be gathered without sending a single packet outside of the sim of course um it's it's stealthy and i'm gonna give some examples of this stuff as we go through it so let's talk about target mapping um in this example i'm just kind of and this is pretty screenshot heavy right like just bear with me with it there's so i'm gonna walk through all these there's just so much data to to put in these slides this is i think 25 screenshots i have is about 25 percent of the total screenshots that i took while looking into this so um unfortunately they can't all be in here and unfortunately
the visuals aren't always perfect so talking about ips insiders and host names so firewall logs they provide um really an endless list of target targeting data for an attacker so you can basically look through the firewall logs um you can look through dhcp logs all that all that kind of data and identify of course individual ip addresses internally you can identify potential cider ranges internally for targeting you can identify typically the mac address which of course gives you um gives you all types of hardware information that's useful for attacking and that's just super valuable right like i can't count the number of times where i've happened it's hopped into like a network and um i pulled like the ip address of the
local host and i've like basically tried to deduce the cider ranges that i should start scanning scanning and do all that jazz and this is like an instant way to do that without having to worry about um doing it yourself and being noisy uh and then you got things like 80 logs i provide host names a lot of the times you can then correlate usernames within those active directory logs with the hostnames and you can get like a really really good mapping of username to hostname to ip address and that's invaluable you can see who's logging into what servers um you know what servers will pop you know like what stations to pop who to
target super super useful information um really valuable for an attacker a couple get good places to look for um for windows logs would be like 46 24s and 4769s which would be like your uh your successful authentications and your kerberos service ticket requests they're just going to be a lot of those um and they typically have like you know host names types all kinds of and usernames so it's a good way to kind of tile those together um now i'm also going to be including some spl as you can see here which is like the splunk uh query language essentially and i've got some samples i can't promise these will work in your environment if you if you're working
often you know um it doesn't always work out perfectly but um these are what i was running in my home lab this example spl is just a quick way to grab um potential cider ranges and then also just grab a massive list of usernames from your active directory logs and so if you look at some of these great shots these just give you some context i'm like what kind of data you can get so you get massive amounts of subnets usernames mapped to active directory donate domains map to any related computers and source ip addresses for them super valuable and then you can also deduce system functions and find admin hosts so if you look at like there's a lot of
ways to do this but you can look at destination ports like in this screenshot i can see that this source id is hitting these destiny shine fees traffic is allowed and sitting port 22 and 33.89 so you can kind of deduce the functionality of these systems or at least the types of protocols you could use to access them as an attacker you can also deduce based on the host name of course you know domain controllers look for look for host names with dc and then um if you're looking for splunk codes you could look for the stream at splunk sp k um there's just tons of ftp servers look for ftp sql servers look for sql
um you can gather all these host names and then basically deduce functionality from those names in the center you can also deduce based on 80 logs generated like domain controllers typically produce certain types of logs um member servers typically produce certain types of logs and then workstations typically don't produce certain types of logs so you can kind of deduce um to do their functionality just based on 80 logs of course it gets deeper like with uh something like edr technology logging or like sysmon or or something like that you can see processes being run and you can map those processes back to what type of host it most likely is so crazy amounts of data crazy amount of
contextual information from attacker you can also identify bastion hosts lots of use cases for this you could basically look for admin traffic to uh to one box from like a bunch of posts even hosted like an a underscore username or like an adm underscore username or something along those lines look for a bunch of admins log into a host say port 22 or 33.89 and then look for that hose then hitting a bunch of different hose on a totally different subnet could be a way to identify bastion hose um that gives you a couple things a it can help you identify kind of more sensitive protected sector ranges as an attacker it can also give you a good spot to
target for um credential dumping so you can identify hey all these admins are jumping on this windows box and then they jump into some other subnet if i pop that windows box why pop an ad and then pop that box and you dump else ass on that box jeez i mean you're going to get the keys of the kingdom so that's just kind of like the way that you can kind of piece these different um this different information together just from same logs and then um hardware os and cloud information just provides all kinds of data so of course i think i said this earlier but dhcp log provide your mac address um the mac address you can map
to vendors typically then that vendor you can kind of see uh get a rough understanding as to what type of hardware the hardware stack the target organization is running you can also get os information from logs so um in this case i've got i believe these are aws logs i have to double check maybe these are like some aws like um host logs and then i've also got um i want to see if there's like sysmon or ipos query but i've got a couple different log types that are um basically they show the operating system version so that's super common and very useful you know it wouldn't be nice if i could just find all the
uh windows xp boxes that still exist in their environment or even their windows server 2012 r2 boxes uh really helpful find all their linux servers good stuff um and then the cloud logs i mean geez this one's really endless but two really too really uh two things two examples i have here one s3 buckets so if they're logging um your aws s3 logs which i hope i hope every organization is it's really valuable um you can identify basically what buckets are public and then you you that's basically an instant one right there you can go traverse that publicly accessible bucket and then grab the data from within it um that's an instant win really and then um i am user console console
user logins this is something that i wasn't really aware of the granularity that it was logging until i kind of approached it from this angle and this would have been really useful on some campaigns that i've been planning in the past so when it comes to aws plugins you can see the username um you can see the user's username you can see the source id that they're logging in from and you can also see their authentication method in this case single factor authentication if an attacker gains access to the sim um they'll gather all this information they can go to all your different go through all your different aws accounts and try and basically brute force these
accounts and get in or at least they know the user target to get aws console access that would be that's invaluable that's really invaluable for me as an attacker and then of course uh you can identify all their api endpoints and that just gives you something that's likely externally facing to to kind of fool around with and see if there's any vulnerabilities clouded cloud information that's in your sin it's like a it's really a gold mine for an attacker i've got a couple more s3 examples here for finding public s3 buckets or got a couple more sbl examples for finding public s3 buckets and then also looking for single factor authentication within aws logs so some other stuff to look for as an
attacker would be public servers um so using firewall logs looking for um looking for servers that have a source rsc 1918 ip address but like a public sorry a destination local address but a source public address look for public facing like web servers for example using those firewall logs you can then combine this with the functionality that you can deduce through some some methods that i talked about earlier to get a really nice list of externally accessible targets and like what the target could be useful for like if you find a web server that's that's that's being accessed externally maybe you could also correlate that with internal data to see if there's any devs that are accessing that web server maybe
over like ssh or something to push changes um or god forbid they're making code changes locally that could give you like a way to pivot kind of into the network from externally if you don't have access to that network segment already so just an idea to kind of get you thinking about how an attacker could could identify different attack paths use that data and then you've got um just list data this is a really obvious easy one um you know whenever you're doing correlation with sometimes sometimes you'll have or even just enriching data within your sim for the sake of better analysis oftentimes you'll find like lists of administrative users find lists of service accounts you'll find list of
executives list of critical systems sometimes each critical system's functionality just as like a csv file within the same not uncommon that's an instant one for an attacker um i've got some sample spl here so this one's pretty simple it's basically just looking for um look for publicly accessible rdp and ssh servers like i said whenever i was talking about the uh the web server that's publicly accessible this is just another way for a for an attacker to uh to kind of nestle their way in and maybe access a subnet that they don't ever already have access to
so for finding vulnerabilities this is where it kind of gets interesting you can actually find vulnerabilities and misconfigurations using the logs in the sim whether they be like it's like a like something that's kind of implied through context information or something that's explicit explicitly kind of there right so using common log sources and attacker you can gain you can identify um common 80 oriented attack factors logging gaps or gaps in security product coverage in general which is great widely accessible network shares the use of older remote access services and even os versions and then misconfigured scripts performing automation tasks all kinds of things that you can use to identify vulnerabilities and misconfigurations within the network
so i'm going to start off with the 80 attacks and then talk about smb smb shares um interestingly enough there's a lot of ways to um do recon to identify 80 missed configurations without ever sending a single packet like to the domain controller or something like that just using the sim so this example wasn't looking at 4738 and i can identify that for this user at this time the um the password was set not to expire and that they were set to uh kerberos pre-authentication was to say it was a was disabled those two things right there are super useful i know personally whenever i'm targeting accounts um i do like some ldap queries i look for accounts that
are really old my password set not to not expire and of course the kerberos um uh pre-op not set not the curve without disabled basically opens up the target for a um asref roasting attack there's some other things you can look for too so in the same 37 47 38 logs you can identify um accounts that have been um basically that are vulnerable to unconstrued any type of various types of delegation attacks just by looking at these logs um some other things to look at if you look at 4769's if you as an attacker if you see the ticket encryption type as ox17 or ox18 it implies that rc4 encryption is being used for that um for
that kerberos service ticket request which of course opens up that which implies um just through contextual information here that the that that service itself on that service account is vulnerable to curb roasting and when i say vulnerable i basically mean that if you gather kerberos um service ticket it's easier to crack than using rc4 prescription so like that's it that's kind of the vulnerability that you can identify through the logs just through context like it's not saying flat out hey this guy's using um this guy's vulnerable to this attack but if you're a smart attacker you know what you're talking about you know you know you're looking for you can piece things together and kind of develop a road map for an attack
and then smb shares um a lot of things to look at here first off if you can just look at all the 5140s and i just parse out all the share names you can identify tons of open shares probably where you can just go through loot data that's an instant point instantly you'd be surprised you'd be shocked at all that uh all that useful data all the credentials are out there just sitting on shares so having that list of shares that are widely accessible um that's awesome for an attacker so just plain some simple data theft then another thing to look at is like look for access to the admin dollar sign share try to identify where all the
admins are logging into so that gives you an idea as to um possible you know possible uh accounts to compromise if that target that they're logged into via the admin if you're hitting the adapter and dollar sign share is valuable to you is it an objective um also just just popping that box and then like i said earlier running say memocats and gathering all the credentials that are that are sitting on that box that could give you access to all kinds of ad accounts so just another kind of uh attack path that an entire could kind of piece together um using these logs the last thing is like watering hole attacks if you look for say like you
know 50 users accessing one single share at some point in time um maybe you could plant some some lnk files there and then and um and do like a watering wool attack that way um maybe there's some other maybe you could like put a piece of hour up there and maybe users could access it if you name it a certified or something there's just there's all kinds of fun stuff you could do when you when you're looking at um smb share like access logs from the perspective of an attacker and i've got this little piece of spl here might be worth running your environment just to uh find instances of pre-op um required no no pre-op required
of a of non-expiring passwords and a password not being required for the user account
a couple more um things that could just help my attacker identify vulnerabilities within your within your network just from the sim one really obvious one scan data so uh people uh you know happen the whole time and it's it's very useful pumping data from like uh from tennable from your uh from your next scanners into your sim great stuff but it also is great for an attacker right it can help you identify individual vulnerabilities and help you identify the severity for the vulnerabilities open ports like i said like i see the port scan module reveals the open ports um whatever it's locked to the sim of the target that's really valuable you don't even have to do a port scan you can deduce
the target's functionality um also context clues for finding new targets uh i'd ask you all to raise your hands and maybe you can in the platform but i'm not sure that i could see it but just raise your hand if you name your pci scan something like pci nightly vulnerability scanner or something similar right or pci weekly volume really scan whatever your cadence is that scan name is logged within at least for um at least for security center in nasa's it's logged uh you know what's within some of the different log in synoptic here's an example internal pci network scan whenever i see this as an attacker i'm just going to look at what targets are
being scanned and i basically have your pci zone in my pocket super viable and then service accounts so um automated services possibly local credentials right like people misconfigure service accounts they have little scripts running under circuit or service kind of locally that might have their their credentials um you know stored on disk somewhere so look for um service account logins see where they're logging in from maybe you can find some local credentials there also look for a ton of failed service account logins this is like one of the most common things i see just massive amounts of 46 24s for a service account that could indicate like a misconfiguration could indicate a really old password maybe the password hasn't
been changed in 10 years maybe that password um it's adhering to an older domain password policy it's really weak just something to think about and then of course just look for service counseling along into a ton of hosts this is what i call like the blast radius test it's useful for something it's only useful for an attacker and for a defender to look for look for service guys that are logging into like 100 plus hosts you know maybe you have like um um if you have like some type of automation or like deployment service account that's like hitting every single host if that account gets popped it's got what i call the large blast radius and that
account is going to be super valuable for an attacker um so as an attacker that's something to look look for and it's something you can identify within the sim just looking at bombs and uh i'm gonna keep moving through these pretty quick but uh logging levels this one's valuable as well so where the windows works are the windows workstations logging do they have like um you know are they logging anything at all that works at the workstation level uh for windows servers login only the domain controller is logging understanding this stuff as an attacker gives you insight into the type of mentality that the security team has how serious they are about um you know
security and logging and all that jazz so it can kind of give you a it's kind of like a general vibe check for the logging status and and a view of their maturity um another thing is looking at their linux servers looking at their edr and av coverage like what's reporting elsewhere like what's logging like say a windows log but it doesn't have edr on it um what that can tell you an attacker is where you're safe to pivot to i can only imagine having this type of data at my fingertips and i've done some campaigns like crowdstrike edr um all the other ers are the bane of our existence and if i knew what box to hop onto
that didn't have edr that would have and i could run some of my other tools there that would have been great would have been great um i've got a little spl here of course this is going to be this you got to kind of tailor this to your use case but it kind of calculates your windows locking level percentage to kind of um give you an idea as to where you are and where you could be but you know of course tailor that um tell that for your organization hey mike we got about 10 minutes left okay cool so i'm going to run through this one pretty fast but credential harvesting um user credentials can
and they will paint log file is destined for the same it's going to happen it's just going to happen end user error causes this overly verbose logging configuration system admin error and bad software design um and sometimes sanitizing those passwords from log files is it's it's it's really difficult in fact sometimes it's pretty much impossible um and this is kind of what i'll call the end goal like right previously we're talking about things that a tiger could use to kind of step further in their attack chain just from the same this like in goals once the attacker gets this this in itself could be valuable they can basically say all right i'm done i've got all these credentials that
i've added from here um boom i'm good um could also be useful for the further attacks too so authentication locks like who typed their password wrong who's this phone ahead who's uh who's trying to log into the uh to the vpn here and he types his password this username hard to find in an automated fashion but if you were to manually look i bet you see a lot of this um who's passing credentials on the on the command line right what bonehead is running this and then linux servers i swear nowadays with windows logs and powershell utilities you're typically passing the creds as a secure stream so you're not usually going to see something like this
but linux there are ways to pass the of course there's plenty of ways to pass your password password securely but people are still using user mod and all kinds of other tools that and then using the dashboard password flag right happens all the time um i've kind of got a little something here that looks for common utilities using um 4688s and look at the command line portion of that blog to look for you know people that could be doing something like this but really just depends on how they're how they use the tool and then of course you can look at um all kinds of other stuff like sql logs right like look for people that are if
your sql queries and cells are being blogged oftentimes those contain passwords maybe it's an admin who's entering a password um on like they're well they're mainly in sql maybe it's like an automated process some applications are performance in the back end i think this these um these select statements were being run by um one of the applications that i was hosting here's all kinds of other examples of credentials that you can find in sql logs and then of course you've got various types of automation um frameworks and other software like in my example ansible was always a it was pretty bad about it um but of course i say visible it's it's my user error right so this is
an example of like whenever i ran an ansible um playbook that involved change updating the sql root password not only did it store the sql root password locally on the ansible server which is what you're seeing here it also ended up taking a log file on the target that basically included the included the password so that's what you're seeing here this is my mistake this is a configuration error you got to set the no log flag or whatever it's called but this happens this stuff really happens and then we've got data theft here so there's just all kinds of useful data um like pii et cetera et cetera application configs that an attacker could find
valuable as like an end goal the stuff you could just grab it from the sim and just boom he's done so you know user browsing data download history application info um the web page access history for public ips like if you've got customers coming in for public ips near logging what they're accessing that's tying those things together that's valuable for an attacker um user data that's sending web logs if you're logging like you know user input to your website in the clear geez gosh who knows what who knows what's available um sensitive info and database logs and um all kinds of other jobs so moving quick through this one um all kinds of this can happen it's it's
it's not totally common but it can't happen like if you're logging your uh your web logs like maybe you've got like my cloudfront or whatever um you could end up including sensitive user information within your logs and that could hit the sim so just something to be to think about um it's very valuable to an attacker's end goal and uh and it's sometimes hard to find you can also gather contextual information from sql queries and you can grab the other sense of information from sql queries themselves so identifying like what type of uh what type of uh you know user agents are being used to hit certain pages you can identify all kinds of interesting information like just
sometimes like for example like forum posts for users in this database example just information that could be valuable and then another one to think about here is your web proxy data like if you're logging your web proxy data and it contains user names and also contains the categories and urls are busy and stuff the sim is like it's got all kinds of uh mappings between usernames like that user's behavior so if you see somebody accessing something sketchy um or something that's generally i don't know taboo um that could be useful for an attacker just something to use for blackmail for extortion for bribing and all of the ability to identify what users access what is also just
it's basically the best way um to uh to kind of craft your phishing emails for for targets and i kind of want you to remember that ethics required security right like sometimes you lose track of you lose sight of just how much interesting data you're looking at how much um the users are trusting you so just as a somebody on the blue team you just gotta understand that there's all kinds of valuable data that's through tying user names ips to you know behavior it's um you got to be ethical last thing here is defensive agent so an attacker with sim access they gain inside the data that could allow them to better evade the defender things like
the search history uh they can actually look at your detection content if you've got rules in the sim your white list your blacklist traffic patterns alerts being generated stuff like that so um first things first once you get access to the send there's a good chance of using the stem there's a very very good chance they have some type of correlation rules you know running to catch attackers right so first things first look at those rules uh identify which rules are being triggered the most identify what log sources are associated with these alerts like are they never getting any alerts around their proof point maybe something's misconfigured are they only getting alerts around um a crowd
tracking nothing around like say windows logs maybe they're not logging much just really valuable defensive agent information for a firm factor um look who look what accounts are failing tons of logins so if you they've got some automated processors just blowing up they're just producing massive amounts of 4625 failed log events maybe you can kind of masquerade in there maybe you can start producing a you know large volume of logins as part of your brute force attack as an attacker um maybe they're maybe the analysts are numb to those types of alerts and then look at like dns servers and web proxies like what dns servers are talking about what's not talking about what about the dc's like are are they
talking loud so if you're doing like dns c2 for example you kind of understand what dns server you should you know point your traffic to maybe that really maybe the one that's really quiet just isn't monitored at all maybe the one that's most commonly used in the organization is then this is a really big one is server web proxies so oftentimes maybe your c2 can't get out through the um maybe c2 or like webex still can't get out through the the user web proxy but maybe you can identify within the sim what proxy all these servers are talking to it's likely more permissive they probably had to open that up to let kinds of traffic out
so as an attacker that's that would have saved me a lot of time i know that and then another thing to talk about is like aggressively address traffic information like look at what websites are commonly used maybe you can um if they're using aws maybe you should host your infrastructure in aws what other cloud switches services are in use you know um also look at geographic location for a lot of traffic understand what com what kind of uh where you can actually place your um place your infrastructure in terms of geographic location is outbound ssh allowed if so like what subnets are allowing that maybe you have to hop to a certain subnet and if that allows direct
alpine ssh that makes x feel a lot easier just some other things to think about that kind of that also falls in line with like looking for outbound direct dns like not having to route through an internal dns server make sure c2 makes excel over dns way easier same thing for direct web traffic like maybe a certain sub that um maybe a certain s is allowing you to bypass the proxy so if you can hop there make your life a lot easier as an attacker and then of course um looking at search history for the defenders so just an example in splunk you can basically query all the search history for users assuming your admin
and you can also you know you're watching the washers essentially seeing what they're looking at and then also rule tampering just seeing if you can alter rules to kind of make your stuff uh not get caught and then disruption um this goes kind of without saying you get access to the send depending on the same depending on your level access you can cause all kind of damage like mass alerting filling disk space lagging search times and even deletion of critical data this is just some splunk related examples like deleting events and just filling up the disk space and so moving quick here but what can you do uh what can you do about this like i'm
not going to say don't pump you know pull don't pump data that's exactly what you need to be doing but um but you can do a whole lot outside of just limiting data so take steps to defend the defenders right like put mfa on your sem that's that's step number one limit the same user population does everybody really need to have admin really look closely at the privileges and who actually needs some access audit the queries being running your sim i know the most sims have that capability just see who's running anything kind of weird audit alterations of sim content check who's disabling mass disabling alerts um ensure that no sensitive and compartmentalized information enters the
sim this is not always so easy but you know for example with splunk i know you can do like data anonymization and um there's a couple methods to do it to actually limit that data from hitting the sim so that's always a good thing to look at especially if you're doing like custom application logs always always always be careful about that and i've actually got that one next check for sql check your sql logs check your custom application logs check your web server logs before you put them in the sim um limits and access to specific network segments then once again limit access within the send so make sure you lock your permissions down big thing big takeaways here
secure your security infrastructure proactively test sometimes this i've encountered this sometimes like your red team test uh your campaign proposals can get a little political um so you may encounter kind of roadblocks and you say hey i want to attack the sim but you really need to be proactively testing this stuff it's something to take a look at and then develop contingency plans in case like you end up leaking data into the sim maybe test it out and see if you could do after the fact to kind of clean up make sure that data doesn't get indexed or delete the events or something test that contingency plan out or god verbatim gets popped you know have uh
run through that scenario and see what you would do so i had to run through that one pretty quick um that's pretty much uh that's pretty much it on the prevention side of things um i think we're pretty much at time for questions um so thank you all for uh for listening to my rambling the data sets here where all all the searches and stuff that i ran came from either my home lab data uh the mordor project data or the bossless socket so look at those if you ever need to do something similar um i've got some my info info down there but i also put some like future plans there i definitely need to
make a more detailed blog post because like i said there's way more screenshots way more examples um it's a real rabbit hole to go down great thank you so much mike this was a fantastic presentation and i'm going to open up the floor for paul so he can facilitate questions and answers all right mike we have a we have two questions so far the first one is have you seen any real world instances of a sum generating false positive alerts due to the client's lack of keeping the os or its host up to date you seen any real world instance of a generating false positive alerts due to the client's lack of unique os or its
host of the day right um i i have to say no no i don't think i've ever seen such an instance i've definitely seen instances where like you know your bone scanner will say that something's out of date or something it happens all the time but i've never seen a false positive in that stereo but i'm sure i'm sure it exists okay uh second question uh what do you think are useful mitigations for these techniques i'm not sure which one i think the ones you talked about yeah yeah i talked about a bunch this also answers the bottom one like mfa is a big one um i know a lot of organizations they do limit like
outbound access from the sims so like if the sim box gets popped itself you can't like use as a staging point for for further attacks um really i went over most of them like average inside limiting the same user population is a bigger one limiting roles within the send you know making sure not everybody has admin access not everybody can delete indices and events and stuff like that um those are probably the big ones okay i think and the third question just popped up i think you just might mentioned it but do you suggest multi-factor authentication for sounds that can become an issue when you have like uh you have some automated process that's interacting with your tools so
for some accounts no but for for most accounts especially like admin users and stuff yes okay those are all the questions so far i have um anybody else out there please submit a question if you'd like yeah happy to answer what i can well mike i just got one more popped in real quick uh photo it's um mike do you think cloud hosted some technique could be a prime target for attackers since they contain data from several customers yeah like multi-tenant um like cloud stem environments yeah it could be a prime target god forbid like a new rc pops up that allows you to get access to like multiple multiple tenants within like curator on cloud or something like that
that would be that'd be devastating they'd definitely be jumping on that so absolutely okay that's it for questions we just popped down one more i think i think somebody just uploaded one yeah i think something i do have a question for you mike so we didn't mention locking down access to the sim most you know small businesses are running um some form of flat network so they don't really have much network segmentation what are your recommendations in terms of properly segmenting your security tools your sim from your production network in a reasonable environment uh you know for a small business well i will say it's not only it's not just small businesses or the flat
networks as some of y'all probably know at this point but um yeah i mean i would say if you if you have no way of segmenting your network at that point it's you know um it basically just comes down to basically all the other mitigation steps you're just trying to defend against attackers um mfa limit user population limit the role access within the sim um be careful about what data you're putting into your sim before you start pumping custom application logs or anything that your users your like your customers might be hitting uh like api something that make sure to look real closely at it so you're not putting any sensitive information with your sim and
if you are um you know make sure you're going through and um sanitizing that that would be my my approach perfect thank you so much