Red Team Handcuffs

[Music] awesome thank you so hopefully everyone can see my screen and hopefully everyone can see me and we'll get started without too much to do all right cool so we're going to cover four main topics today i'm going to briefly introduce myself uh i will talk a little bit about our team uh some of the stuff we're doing in the village today and then we'll talk about what we're going to cover what a red team handcuff is and kind of the conclusion all right so first off to introduce myself my name is caleb mcgarry i am a red teamer at microsoft i have been with the company now for a few years i am on one of several red

teams at microsoft so microsoft is a fairly large company we have i think four main red teams each one has a different area of expertise my team is responsible for what is known as edg uh edg as you can see on the screen stands for edge devices and gaming and the way i would explain it to people is if you think about like windows but nothing that is actually on the stuff that runs on your computer per se right so this includes things like windows update uh windows code sign all the build systems uh some of the other inherent security that gets baked in um stuff that's that's windows but you don't necessarily touch it right

so there are some components that we touch that you may actually touch but not a ton of them with devices this includes everything that's devices related so say from manufacturing to deployment to you know the images that go on the surface book and with gaming my team is responsible for the entire stack so that includes all the studios that we own that includes xbox um anything that runs on the console um you know to assessing testing the hardware potentially to say figuring out how to cheat in a particular game to um going out and testing a third-party gaming studio that we've just acquired to check the security of them we are a relatively small team

uh there are only eight of us and i think today most of us are actually present at the conference we are hanging out in the village serpent channel which i'll cover in a second uh please feel free to drop in you can talk to us directly and ask you know hey what's you know things like in your space or you know how is this done in potential at microsoft where possible we will try and share that information with you obviously there are going to be some things that we can't disclose but that's kind of the way life is at any major corporate company um i live in seattle i have two dogs one of which is featured on the screen up

there and the other one is upstairs hopefully being quiet and should not interrupt my talk and i put my link in here you can ping me there if you have a question you want to reach out you want to try and connect just tell me where you're from say hey i'm from b side saddle so that way i actually know who you are all right so i mentioned earlier i think in the last like couple of minutes that we actually have a village or something going on here at beside seattle and i'm going to take a minute and talk a little bit about it so in the village serpent channel there is a pinned post and if you look at that

pin post it will direct you to securitycenter.windows.com and it will give you a logged in a login username and a password that you can use to log in and what we have set up here is an enterprise md atp instance so mdhp stands for microsoft defender advanced protection i think they rebranded it recently to microsoft defender for endpoint so they changed the name as part of ignite a few weeks ago and in this environment we have onboarded a small domain so there's a couple of servers a couple of clients and we have done some activities within the environment right and uh there is the advanced hunting interface enabled so it will enable you if you log in and poke around to try and

figure out exactly what we have done and how admittedly there are some things that are like extremely obvious so say hey accessing lsas right but there are some things that are a lot less obvious and so the goal of the i guess experience if i'm going to call it that is to see if you can figure out everything that we did using the hunting interface right admittedly you could drop some other form of forensic tools on the box and you could you know run some sort of analysis and say get me all the files that have changed between a and b and potentially detect us right away but that's a little bit less interesting so um take your time

log in try and accomplish the challenge if you have any questions like i said we'll be in the channel and you can ask us about hey how's this feature work or was this you or did you do a b and c figure out see if you can figure out how we laterally move between systems um what sort of credentials an account we're using um i'm gonna put around and figure out what you can see um and then hit us up unfortunately we don't have any prizes um just by nature the way that we stood this up it isn't necessarily possible to do it in a a super awesome you know ctf manner but we do have a bunch of stuff there to

poke at um it is somewhat unique and uh if you are successful in finding some of the more unique things we have turned on live response and so you can potentially recover a file off disk and then analyze it and then go from there right so swing by and uh give it a look cool so today's talk is a little bit unique it's different than most of the other conference talks that we give or that i have given and the fact that it's not necessarily a hardcore technical talk uh when we were thinking about what we wanted to present at b-sides this year we decided to talk about some of the challenges that we have in doing our job and so one of the

main points that we have as part of our job are rules of engagement this is a fairly lengthy document with a lot of legalese that is written that every red teamer at microsoft has to sign when they come on board to do their job and the roes as i'm going to refer to them will differ between teams right so our talk um you should be aware is specific to us and it is specific to how we interact and do our work in the business right other companies consultants their you know major firms whatever may have different rules of engagement they have different limitations different restrictions um but these are ours and they force us to adapt and think

differently in how we approach our statement of work right we have to do certain things differently than potentially a real attacker because we have to change the way in which we operate due to these restrictions that are inherently placed upon us and this talk today is going to be about what those restrictions are why they matter and then how we solve them and our goal is to be able to work around them in such a way that we can continue to do our work and say a happy path without any impacts and still have the business impact right so as a red team our primary responsibility is to be a sparring partner for our associated blue

team which is known as fire um and then also help secure the business right we want to find vulnerabilities and bugs for the adversary does and then get them pushed out and get them fixed all right so we have our happy path scenario and this is how we would operate ideally if everything went right and we didn't have any interruptions challenges or limitations placed upon us right the team would get together uh generally since we're a small team this may involve the entire team or just a couple of the seniors on the team and we'll sit down and we'll say okay this is our scope we have edg these are the things that we consider

high risks like hey there's a new console coming out this year we should probably have a look at it we should probably figure out how you know they're doing a b and c associated with that console if we can accomplish something unique let's schedule it in we'll designate some time whatever and we'll we'll decide what our goal is for that target um i mentioned the schedule so usually when we do a test and i'll reiterate this we have a set amount of time so we are definitely time boxed as part of the way that we do work and we'll calendar something in and say okay this is when we're going to do this task

this is the fun part of the job um we get to do the test and this is honestly why i do the job i like connecting the pieces and figuring out all the dots and identifying the problem and then you know exploiting it and accomplishing the goal uh we then release the results so on our team uh the way it works is we have kind of a bug bar right so if we decide that you know something is going to be a bug it has to be considered a violation of the secure development lifecycle so there's policy there's rules and regulations that are out there and if we file a bug it has to violate

one of those items so it has to be a technical bug we tend not to file say process bugs we file technical items um that would i guess be the equivalent of like a github issue against a project right we will open a technical bug like hey you have an integer overflow here and this impacts leads to remote code execution which leads to environment compromise which leads to you know whatever else that you need to fix so we file our bugs um and then we move on um we are involved in bug remediation to the extent that we will buy off on the customer solution but generally that's you know it's fairly light touch right the customer gets to

look at the flaw they get to decide how they want to solve it and then they get to you know deal with it and ideally we would then go on to our next target and it would be um a kind of an open and closed process right now the challenge is that's not really how things work anyone that works for a major business knows that things are just different so let's go back to monday i will come to work and i start between say 7 30 and 8 am and i fire up outlook which is my email client that i use and there's some email in there it says you know from someone that i may have

never heard of somewhere in the company and they might not even be technically inside of our scope right but they just managed to find us because we're in the directory hey listen um we're pushing this product to market uh it goes out on thursday and uh i need this thing done and uh can you help me with it right and a lot of times those are going to be generic security questions that we can punt off to another team right so we in our organization do partner heavily with other security teams so um we have within like what i consider the serpent core there is a component pen test team they do code reviews appsec

they are like a dedicated pen test team of specific components there is a threat modeling team a secure architecture and design team and they do that kind of service for our customers right and so a lot of times we can hand them hand the email person off to that customer but there might be cases where we're like okay it's probably merits getting looked at something that was a surprise and it fell through the cracks and so we have some challenges with this right so uh first what's the monitoring posture remember our job is to not just test the customer's environment but also to test the blue team's response within the environment and if there is something

new and foreign they might not have any monitoring at all and that represents a significant risk right it might be better in that case to pump them off to the blue team and be like hey onboard the monitoring do a b and c and then come back at some future point in time and we will consider you as a service timeline um when the business comes to you with a request like this they don't uh give you the desired time it's usually like we're going to market on this date or we have this thing that needs to be done by here um and you have to adjust um and then the environment right microsoft nowadays uh is a very diverse

environment right we have everything from say kubernetes with linux um i did a test on something that was that kind of environment recently down to say just you know straight regular windows you know.net a very microsoft stack um where on the other hand i might have something that is you know say perl kubernetes running in a container on linux somewhere um elsewhere within a data center and you know the developers that work for us have the ability to choose their technical stack right we don't prohibit what they can and can't use and so this environment may be very diverse it may be something that we're unfamiliar with and it may be something that we have to skill up rapidly on

and this represents some challenges when it is our job to potentially compromise the environment and accomplish a goal within it and so the problem is that forces us to work rapidly right um and as anybody knows that when you're speeding um you have to sacrifice a little bit of control of the car when you're going down the freeway and so we have to sacrifice somewhat with what we can do when we have a very tight deadline in an environment that we may be unfamiliar with where the controls may not be perfect and so that's kind of where the handcuffs come in um because if they weren't present things might be a little bit easier things might be a little bit um

less stressful and less strenuous for what we're trying to do it would be much more feasible for us to accomplish our goal if i didn't have some of these restrictions in place and the adversaries that we deal with and i will provide specific examples of these often don't have these limitations in place and so uh our job obviously is to potentially emulate an abstract it's not like the only thing that we're responsible for doing um but we need to do so in such a way uh where it's realistic enough that we are training the blue team but we're also providing the customer with what they're likely to experience when they are publicly exposed so handcuff will be the limitation that

prevents us from doing that all right so without further ado we're kind of going to get into the first one so uh as a corporate red team right and we work for microsoft we have to be very careful about what resources we use um and so most of the time if you are attacking say a third party and the example i've got here is stuxnet right which was the major effort against the iranians that was largely done by the us and israel at the time and a modern malware author has the capability to use external resources that they may not have control over right um they can use shared vms they can use uh email accounts and machines in other

countries where they don't really know what will happen right where they are at risk of exposure where the fact that they can get compromised is a risk that they're willing to accept um and obviously this does you know generate some risk to their effort to attack you know a certain entity but um because the world is like largely interconnected and everything is online in some way shape or form they have the ability to hide within you know um i guess the data and the traffic and the noise that's out there right so stocks now use some domain names and i've got them listed here um and they're they're relatively generic there isn't anything super like unique that you might think out

about them you know there's a couple of dot orgs a couple of dot nets you know a couple of dot coms and they're just kind of a domain name and thousands of domain names get registered and used on a regular basis and nobody thinks anything of it they're words they're not relatively unique i mean there might be some reputation score that might say hey this thing is dangerous but that's really about it um and if someone were to potentially identify these and say hey they're part of a malware campaign um that challenges with attribution and so when you try and do this in our lab right if you log into village sherpa and you try and figure out where

our c2 box actually is um because we we do have obviously an attack system that we use to compromise it that is not present in the lab um attribution is hard right and being able to do attribution concretely uh takes a lot of time and so an attacker a real one can afford to take that risk right whereas we as a microsoft red team definitely can't and the reason why we can't is because we are dealing with potentially very sensitive data and anytime i pop a system right and i exfiltrate some sort of evidence that i was on that box right even if it's like something as simple as a screenshot i am putting microsoft

resources and microsoft systems at risk which means i have to maintain very concrete control over where that data goes um what happens to it and who sees it right if i get on the system and i decide to steal some data and i send it back to me and playing text over the internet and someone else is listening and they also intercept that data then i have just inadvertently exposed microsoft data to some third party and i have to figure out how to deal with that and so um that is a hard like problem to deal with right because the real attacker doesn't necessarily care if some third party may sniff the data that they're

doing right they still get the data in the end yes it might be a little bit less valuable if it's say ip but they'll have a copy of it right and the person that sniffs it might not realize what happened um whereas i cannot even take the risk that someone might sniff it this puts some challenges on us because uh this means obviously i have to have a data store which is under our control so we have to host uh within azure or within our lab environment that we maintain on premises in redmond and because of that there is definitely going to be a traffic feed to our endpoints and our endpoints are obviously well known they have to be

monitored they have to be controlled and the blue team immediately knows where they are and so if they see traffic going to and from a serpent endpoint from a potential box it is like hey we should go look at that we'll probably find them there and then the response might be different which isn't something that we want to have happen right we want to test the response process from end and actually challenge the blue team and and then it adds you know challenges for us too right because if we're doing anything unique or specific we have to have a way of tracking what we do and so the way we have chosen to deal with this internally on our end and i

have a diagram uh in the next slide that we'll talk a little bit about how we implement this technically is we decided that we would implement encryption obviously end to end for any of our tooling um in order to allow us to route our traffic through specific um third-party endpoints and it's not just the traffic that we encrypt right we also encrypt the payload so if for some reason the traffic is broken right they still have to figure out how to uh crack and get the payload and this does add additional tooling overhead i'll be honest it's not easy there is a simple implementation that i'll talk about using nginx proxies but it is something that we had to figure

out how to do because then i can choose to put um resources in areas outside of my control because i can guarantee that any sort of data that passes through them will never be able to be broken or taken by someone else that is an attacker right and then obviously the start and stop endpoints that have to be inside our network or a network that we are authorized to attack and so um let's let's think about this for a second you've got say the cloud right and you have your cloud hosting providers and they're out there and you know pick you know it doesn't and the reason why we like to use cloud hosting providers is because

uh honestly um everything in the world talks to the cloud hosting providers and we actually have resources that are hosted in other cloud hosting providers so some of those third-party game studios i mentioned do not always use microsoft resources or assets right and so and then we have microsoft right so for this scenario let's assume that we are attacking a target that is internal to our company um and we have figured out a way to go in so our infrastructure is on the right and so it's the red server and that's going to be where say our c2 runs in this or some sort of virtual machine or data store potentially where we'll actually store and control

the artifacts right we'll obviously have a log server there we'll have a few other things that are set up in place um not just to log the actions that we as an operator take but we will actually log and record all the traffic um i think it's several different points as it goes in and out of the network so that way we can say if someone says you know did this bike get sent we have the capability to say yes it did um and let's say we figure out a way to get on that endpoint all right so um i send somebody a phishing email i include a binary they click the link because that's what people do

and from there we then have a you know a connection from there um obviously this is going to go somewhere else in the cloud right and so the example i gave earlier using nginx pass-through proxies um is actually very simple and very easy to set up right so say we're encrypting data already and we're doing it using say open ssl so it is going to already be encrypted and i ship it off to an nginx passthrough proxy the nginx passthrough proxy will route it to a different load proxy and then it can run back down to us and so if someone is saying they compromise that server right and they decide to sniff the traffic

that is coming to the nginx press to proxy it is already encrypted they won't have a way of doing anything with it and yes they might actually be watching on that server for potential weakness and they might potentially be able to redirect that traffic elsewhere but they can't decode the contents and therefore we're not going to put microsoft data at risk and then obviously we have multiple hops so we'll have two or more proxies chained up to send this traffic between them and the reason is our blue team is brilliant um they have long since figured that you know if they see traffic going to a specific endpoint they can say hey what else is talking to

that specific endpoint oh hey it's serpent resources this is obviously going to be the red team and then once again that may change the response and that's not something that we want to do um and so we have multiple hops that forces them to say okay well we see traffic going to this cloud provider it looks anomalous or there was an alert on this box that caused us to look and see where the traffic was going but we don't necessarily see anything else that's talking to that same home point and so then they have to escalate and start the response process in a much more normal manner which is good all right this next one is

kind of significant because it impacts a lot of the way things are working specifically now that we're in a pandemic and everybody is remote um obviously personal devices are out of scope for us right and this is you know for very good business reasons but common malware that is out there does not have this restriction right so one of the more common things that we're seeing specifically this year is hands-on keyboard operated ransomware so like ransomware will get on a system um it will report brackets and environment and it actually might get someone that is actively controlling it or potentially directing the spread of it or doing some sort of action as a result of that ransomware

infection so you'll have hands on keyboard and that interaction can enable it potentially to cross identity domains across environments and to spread further and because this year more so than any other year when everybody is virtual uh you have a lot of personal devices that may be used to connect to corporate environments right people will connect to a virtual machine that has access to the corporate network and they'll inadvertently bridge you know between their personal device and the corporate network or they'll have a phone um that has like a two-factor authentication token on it and they'll use it to connect inside to the corporate network um but we can't go after them right that's a it's a

personal device it's it's there are a lot of restrictions with regards to them and in many cases it it is against the law to be frank right now in our case we also intentionally choose not to ask for that kind of permission because it is it is possible that we could go back to our legal team and we could say hey can we figure out a way to do this but um we want to work in such a way that the employees or the organizations that we test have full trust in the red team right they need to know that if we're going to come in and we're going to own them we will do our best not to impact any

one of them on a personal level right as a red teamer uh oftentimes you will get on someone's device right and it may be a work device but regardless you will occasionally see personal data there right someone might be paying bills from their work laptop or something and they might have you know oh they're buying a house and because of that they need to talk to benefits and they've got like a credit check application on their desktop and you need to not touch it right and you need to be sure that they will have a trust in you that even though they're doing that activity from a corporate device which may or may not be sanctioned

that their data is secure and that you're not going to go invade their personal life right we don't want to uh go after them and so the way in which we deal this is kind of via an assumed breach scenario and uh this isn't always how we function with these things right so assume reach is the concept that you start from somewhere within the environment uh using some sort of permission level and you just assume that your perimeter is compromised now in our case we actually do crack the perimeter so we don't do it in every engagement but periodically so i'd say at least three times a year maybe like once a quarter or so we will

go out and crack the perimeter right so it is our job to prove that that risk exists and then we can use that justification or other access that we get as a result of cracking the perimeter to work to maintain and assume breach posture um and generally for us right now um this is in the form of an unauthenticated network access uh to the large corporate environment right so um we don't start inside a specific identity domain we don't start with a privileged position anywhere and we don't use trusted insiders right and then once again is specific to our red team they don't go out and ask somebody to run malware in an environment for us

um we will start unauthenticated just assume we have network access and uh prior to covid that was a lot you know that was that was very logical because um you know large corporate network 115 000 of your closest friends are on the network uh it is entirely reasonable to assume that somebody will click the link even if you have reached the perimeter within the last few months that somebody will respond to efficient email and run malware right and when you have the amount of noise and traffic on your network of that size it becomes very hard for a blue team to stop and defend and prevent every single instance of it from uh infiltrating the network right

so that made sense if we needed to impersonate someone we can contact hr and we could we could work on it now it's a little bit different when everybody is remote because the corporate network is largely just vpns between devices now but that same sort of principle still apply still applies right um but well that's the posture that we'll usually start with so inside the network impersonating someone but not necessarily a specific user in animation perform

all right so the next major challenge that we have is that we have kind of a static tool set so we are a relatively small team so as i mentioned at the beginning there are only eight of us and one of them is a manager um and that leaves seven of us more or less to get our operations done and we are generally specialized in a variety of things so our team has what is known as a skills matrix and every person is required to fill it out once a year and so it's basically a list of the technologies that we need to know in order to do our job and you rate yourself on a scale of one

to five that information is public so it shared with everybody else on the team and it is shared with the team lead and so we can then decide how to get training where our weaknesses are what we need to do you know who is going to be a specialist and whatever um but even then with that sort of layout we still have a very limited um resource capability right adversaries are not this case so in a prior life prior to working at microsoft i had the opportunity to work out east that is what was known as the cyber defense center in annapolis junction maryland which is right next to fort meade and there were a lot of teams that were there invested

just right in particular tooling for the government say malware you know components used for security assessments you know stuff to do defensive work potentially and there were entire complexes of thousands and thousands of employees that worked at that place to accomplish a specific goal and because of this um if you're attempting to emulate say a nation state adversary you know a nation state adversary may have the capabilities to retool or at least modify a tool of someone else's right so they may not always use their own tooling um for every single engagement right they can basically start fresh from the ground dog they'll have those resources they can say okay we know that these indicators

were happened we're burned here let's just start refresh right it may not always be that way but they have that capability in our case if we spend say three months developing say really cool malware framework a and we use it to do something you know we are impacted by that and so for us the cost to retool is relatively high right we may have to start refresh with their design we have to figure out how to get things done um you know and if the signature is tight good right so say that the blue team has figured out how to signature a specific tactic that we're using um say i'm doing some form of memory

injection to dump tokens for you know something out of memory and they realize that i'm calling a particular api for that and that nothing else in the system should ever call this api and so they put us you know a detection in place and it becomes high fidelity detection um the time just to work around that right and i might only have to change one api within our tooling can still take a couple of days depending on what i need to do right so we do have a test environment where we can test things out and we maintain our own uh azure tenant right so we own serpent.dev and we do you know security testing

there things before we use them against our targets for this reason but it still makes it relatively tough right um and obviously i have a set time in which i need to get something done and so the way we deal about this is on our team we have a very tight cadence for how we manage tool development and i know a lot of red teams tend not to um like really structured things they prefer much more free form and i very much understand why but because we have limited resources and we need to accomplish a lot um we have like a stand up and we operate in sprints and if you're going to build a

tool someone is going to look at it and they're going to want to know you know what's the purpose and how what the impacts of it are and how it will work there are a couple other things we also try to do so i've mentioned one of them on the slide here that in the industry there is the concept of what is known as a silent alert

so a silent alert is when there's something that triggers the detection that doesn't necessarily notify the user right and so a lot of our tooling is signatured in that way shape or form right this allows microsoft or the business to have some uh form of control over what we do right um they're able to say hey your tooling is only on these systems it hasn't leaked outside the company there isn't anything that we need to be worried about there isn't any sort of response that we need to take and this is important right it's not like we tend not to use a ton of o-days as part of our work but we may use say an end day or we may use a security

weakness that is not publicly known um as part of the work that we do and so because of that we have to guarantee to the company um that that information will be secure right and so our stuff does get signature to an extent and then with the ttps so which is tools tactics and procedures that we use and i don't have a screenshot of this here but we maintain a really robust wiki it's organized by the mitre attack framework um and when we have say a ttp there is a time so it gets created at you know date foo and periodically it will get aged out and by aged out i mean that we will hand that

exact same ttp in a script that will you know perform that in some way shape or form off to the blue team and we will let them fully signature um or at least make some effort at stopping it right if their signature is bad we'll continue to use it and we'll let them know that it's bad um but this forces us to innovate on our own schedule right so we can say hey all right we're doing this i know within six months we should not be able to do this and therefore we will take actions a b and c in order to solve this problem potentially right if there is a password sprayable endpoint um there's a periodic time where we'll

say password spread and then we'll be like okay we need to get this reported needs to be done you can't necessarily sit on this um and then for the team and i talked about the skills matrix earlier we're going to hire people that can do development across a wide variety of languages right we have a couple of people that are experts in.net we have a couple of people that are great at python powershell scripting et cetera and a couple of people that do native code um c c plus plus etc um and that are pretty good at you know same memory stuff and this allows us to somewhat spread the workload of the tools development

that we need to do um across the team because for the different environments that we we target and our i guess i think our team among world teams is somewhat unique that we have such a broad and diverse environment because we have say the gaming studios and they use uh a lot of different technologies under the sun then this allows us to make sure that we are able to cover them adequately um and then obviously we'll do some sorts of uh occasionally we'll do periodic tests to just make sure that things are still working like i'll drop my car to disk so icar is a file that will flag a defender alert that will trigger you know response

automatically and so we can use this to make sure that okay this is happening but our tool's not being signature once again we do this within our own test environment that we have specifically stood up for this purpose and uh we do run mdhp in that that is the primary thing that we use to check and see um what triggers the detection right this is not the only anti-malware engine that we will face or that we may potentially have to evade which is the primary one that we test against right so defender and mdhp and we do deploy those same tools that we uh use or work against on our attack systems to make sure that they are secure

um this is kind of an interesting one as this is explicitly forbidden in our oes and it is that basically we cannot weaken the security of any system that we get on um and the way i believe it has worked is that we have to maintain the same posture for the security of the systems that we compromise as uh the same or greater security posture of a system that we compromised right um and this is somewhat unique right because it means there are certain things that adversaries commonly do when they get on a box that we cannot do right so if you get on a box and you're an actual attacker one of the first

things you're probably going to want to do is turn off telemetry right you don't want to allow login traffic to show what you do afterwards after you got on the system or at least you want to have some sort of way in guaranteeing that any action you take on the system won't be locked so you might trigger an exception you might say hey don't note this data you might turn off some sort of defensive software maybe you'll route audit events to null or something like that so in that way shape or form your actions aren't taken or stored we can't do that right um it's just not something that we have the capability to do

um and it's explicitly forbidden and so for us the reason why this matters is it makes it uh harder to actually emulate an actual attacker right um normal attackers would relatively easily blind the blue team and a lot of attacks against say anti-malware systems that are out there will involve some sort of denial of service some sort of disabling of the system some sort of you know um [Music] action which which prevents the system from communicating back to the endpoint um we can't really do that right we're forbidden from doing such things we have to make sure that our binaries and the code that we run do not trigger an alert in the first place

right they might get logged right and a lot of the stuff that we do do does get logged and potentially generates an event but it doesn't generate a high enough fidelity event for it to trigger an alert um and this is just because we have to make sure that the blue team has a concrete record or track of whatever we did um if i find a system that say internet exposed and i've got an example here right so there's a system that's internet exposed and say i successfully brute force it get through the defenses and i get onto the box right um you know that i might not be the only person on that system

right there might be someone else that has brute force that and also gotten on that system yes i might have a better word list than me because i know generally what internal password patterns are potentially for the team or the system that i'm trying to brute force but someone else may have figured it out and i have to be confident that um i can equivocally say what actions are mine and what actions are not mine in the event um that i am not the only person on that box right specifically for systems that are exploitable the end day vulnerability this is a risk right there are people that are out there that reverse microsoft patches

on a fairly regular basis um and so that's something that we have to take into account the other one in the middle is the customer data is a hard no so for all of you that use our products so first thank you but understand that we do not touch your data ever and so if i'm testing say xbox and i want to go see if i can say compromise a specific account what we will do is we will create an account in advance so we will create an account just like a regular user um we'll run it through the process everything get it onboarded it'll be an account that we control that we know about

and then we will go out and we will target or compromise that specific account but we have to be careful that we don't touch anyone else's account right you don't want to trigger a privacy you don't want to trigger customer data exposure in any way shape or form attackers don't have this problem right they don't really care if they look at your data or bob's data or whatever they just care that they get the goal right um they probably are more annoyed if they see data that isn't relevant than uh data that is potentially useful for them so because of this we've had to take um some kind of unique approaches so i mentioned that we're a tool

development team and one of the things i think that is unique about our red team at microsoft is we are a build it over a biox team and i think that in general as part of the corporate culture the company we are an engineering company and so people tend to want to build things in-house and you may have multiple different copies of the same thing that has been built multiple different times

but people will build it in-house right rather than potentially purchase a completely viable product that does that thing successfully off the market and we do use some cots products but very very few um and so because of that we have an internal team restriction that our tooling has to go through the same release process that all internal microsoft products have to do um and that does include things like we get our tooling code agreed by the component pen test team um we get our tooling threat model our tooling has to perform authentication at a specific level and if there's a standard that deprecates the use of specific authentication so say you know tls 1.0 is deprecated

our tooling cannot perform authentication using that deprecated standard either um honestly it's kind of annoying at times because it does require us to potentially modernize or change things and then make sure that our tooling is up to the same standard that it needs to be um we love all our actions uh we try and do this via automation as much as possible right so um every operator or when you are on an engagement you will have a dedicated attack system you'll have a dedicated tissue system your actions and activities that you take are supposed to be from those systems and we will collect all the actions and activity that happens on those systems and we store them for an extended period

of time um and then the c2 obviously automatically logs all the commands anything that goes through it traffic etc and this is deployed within a specific network environment that allows us to capture all the traffic right that's mandatory um we don't give it to the blue team when it's done but we do maintain that data in the event that it's ever needed that which brings me to the next point that there is an internal deconfliction process that is set up so the blue team does have a way in the event that they actually think that say something is a real event of making sure that it isn't the red team right um they have to work for their mail it's

not just hey was this the red team or hey what's this not right they obviously have to you know provide some sort of reasoning data or potential signal for why they believe it is a b or c and we will respond within a timely manner likewise um going back to the example from the previous slide if i brute force an internet exposed endpoint i will probably let the blue team know right away right that's a scenario where i would not be comfortable saying that hey this system has not been compromised by someone else potentially right and so if we find a vulnerability of the sort that crosses an identity boundary right so um say i find a vulnerability that gets

me into like a code sign environment um and it's significant i would reach out i would say hey there's this thing right we have a way of doing that and i would let them follow their standard incident response process to make sure that the system is not compromised and that just allows the business to have that kind of level of assurance that we are the only people that are in an environment when we should be right that's never a fun scenario to get somewhere and then find out that you're not alone um red teaming is one of the places where you want to be the only guy in space you don't want to have other travelers

there with you and i think this is the last major limitation that we have and that is that we're time boxed right so most of our engagements happen from uh a max of 12 weeks so we have a max of one quarter to do it and resource wise well we can have as many as seven people on the engagement potentially eight our manager is technical and he does lean in from time to time which is awesome um but we are time boxed right uh and an adversary that comes against microsoft um or an adversary that attacks a specific property of ours may have years to do this right um they may be outside you know the legal reach of uh our

company and they may just literally wake up every morning and say hey it's my job to come you know go do microsoft and uh whereas we have a very short amount of time to learn about our environment um and then compromise the target right and some of our shorter tests we might only have like two to four weeks right um it might be a really rushed test or you know we have to immediately go out and check something because say there was an incident there and someone wants to you know see if there's anything else there right and then there are obviously going to be times when uh we can't test right so um it's october and the october 2020

windows update or windows release is out uh now would probably be a bad time for me to go test windows update doesn't mean that i couldn't test windows update it just might be a bad time for me to do it and one of the things that i want to do is maintain a friendly relationship with the business so they don't get mad at me and they will let me come and do the testing and so i'm going to delve into a little bit more details this is one of the cooler pieces of tooling that we've written and i think the next slide i have here we'll talk a little bit in detail about how the tooling works

and so remember how i mentioned our assume breach mentality so one of the things that we prefer to do is not have to ask for a user right or not have to say start with an authenticated network user somewhere right that makes the test a little bit um less realistic right so instead what we'll try and do is during the course of other tests all right um occasionally you'll get into an environment and you'll be like uh this environment isn't super useful we're not necessarily testing this didn't land where we thought it 100 would land right you do plan things out right you're not going to try and wander you know across the entire corporate environment or entire scope of

whatever you're testing but sometimes you'll get some access and it just doesn't make a ton of use we will persist there right um and we invest a significant amount of time into persisting there right so that way if i ever need to come back and test something that is say one to two hops away from where we are persisting i can activate that persistence i can then perform the actions that i need to do in a much shorter quicker manner and it forces the blue team to have to hunt for that persistence off-band right this gives them something to look for on a daily basis right they might be specialized in hunting in a particular environment so

say someone is specialized in hunting within the gaming telemetry we might not be testing gaming um on any given day of the week but if we are persisting with that environment that person that's working there looking at the telemetry probably has a signal somewhere where they can you know potentially find us it might be hard for them to figure out what it is um but we intentionally choose to persist and leave artifacts in specific places um so that way we can challenge our blue team and force them to actually understand and make sure that they have the coverage of the telemetry that they need obviously um there's automation involved and this does require us to plan out our

engagement several cycles in advance which you know obvious doesn't always work as i mentioned sometimes the business comes back and says hey we need you to do a um but if we have that persistence it will work so the framework that we've built um is fairly simplistic so when we're thinking about this um it's been a couple years now before we started building this the idea being that we wanted to put minimal effort into it right but we wanted to have something that would adequately enable us to properly uh translate or talk to the targets we're persistent on and so in this diagram here i've got a controller and a storage and so the storage account you should think of as

something just like an azure blob right uh you can use any storage uh of your that your of your case right so basically it just hosts some data um in our case it will eventually host an implant that we're going to send back to our target right and the controller once again fairly simplistic um not a lot of ton of coding skills required um it just needs to talk to some endpoints and manage things right um and we use uh a pattern in such a way that enables us to basically load it's called an observer pattern for those of you that are developers um to load different um endpoints that it needs to talk to and push data to

them but the controller is fairly simple it just checks the key value pair against a database and if so it then grabs something from the storage blob and i'll return it to that endpoint where it needs to go um and then we've got our targets the internets and transports so and the controller as i mentioned can talk to the transports so and our c2 is a separate entity outside of this right so um the c2 is a large investment right we are not the primary authors of the c2 that we currently use at microsoft it is developed by another team although we do contribute um there is largely one c2 that everybody kind of contributes to that is

used by the red teams at microsoft um but we are the primary authors of the persistence tool set the reason why we do this is say there is a change in the c2 um that would require us to like reroll the c2 completely right hey there's a security bug in it you got to blow it away got to build a new one right you don't want to lose your implants you don't want to have to deal with you know regaining your positions with an environment and so the persistence framework is built to maintain those positions in such a way that we can securely know what's going on now all right as i mentioned the storage is

basically going to hold implants and an example here would be one of our transports is azure active directory and almost any system in the world that is say microsoft owned will talk to azure active directory in some way shape or form and you can look up users within your directory all right so assuming you're running under the context of a specific user uh you can look up a user and you can look up their profile and you can look up some strings that are associated with that user like properties right and um there is a popular multimedia application that is out there that um has a small bootloader or i guess a small loader application that runs on

startup if you log into your your operating system um to prepare it to load so that way it doesn't take forever to boot or the multimedia application doesn't take forever to start up right and this multimedia application um it loads a font driver and that font driver does not exist right but um because the it checks for it every time windows boots um it goes out and it looks to see if it's there if so it loads it if it doesn't it it goes and loads some script right and we know where that script is located on disk and so we can change that script or rather we have modified that script in this case let's say

on one of our impacted boxes that runs this application um to check uh for a value in azure active directory right it's relatively normal it's most likely going to be expected network traffic there's no big red flag hey it's just looking something up on azure active directory via you know encrypted connection whatever it doesn't trigger any alerts by default and what it does is it may go out and look up for a user and it may check a specific profile property and then it will say is the profile property signed if so do something if not do nothing and it comes time for us to activate that persistence mechanism right so we may have placed it on this

person's box and it triggers maybe once a month so when i talk about persistence here i'm talking about long-term persistence right we might hide out in an environment for months potentially as much as a couple of years before we decide to activate our persistence mechanism right now we're going to activate this mechanism and so i'm going to go out and my controller will reach out to azure active directory it will modify that a property on this profile right so it's a user that i created right so i have the ability to update it with say an encrypted or signed string next time that person boots their application will reach out they'll retrieve that string of code

it'll say hey this is signed properly can i decrypt it right because we've baken a key and our persistence mechanism that is left on the client and then it will execute it right and what will happen is we'll then ship an implant down to that affected device right so it'll reach out we'll retrieve something from storage and then get shipped down to the device that implant will then call back to our c2 and we are immediately active um within the environment and we're generating live traffic right to the c tube um because the implant obviously doesn't call back like on a monthly basis right it might call back using a jitter you know at most once an hour right

because operators need to do stuff they need to have a much more uh timely callback to work with the device and the code that runs on the targets or the clients is often thrown away code right it does like two things and it has to do these two things right it has to make sure that the payloads that get are signed and that they are encrypted properly right so it can decrypt them and then it can validate the signature and then it can then execute them so that way we can be sure that any code that it executes is from us um and is you know under our control but we invest time into figuring out how

to persist on devices that we get onto um and a lot of times we make our persistence specific to the environment right if i get on a web application um and i notice it's running some sort of code at startup and i can inject into it i might choose to persist that way whereas if i get on say a linux box and i can add a cron job i might choose to persist that way right but we invest time into making um and we have some components right to make sure that these persistent scripts run in a very specific manner um and then the other portion so from the transports on all that is generic right um

i only need to write the stuff that updates say if i'm using github as a transport mechanism but i only need to write the code that pushes stuff to github or makes a change that the persistence mechanism can check once and i can reuse that because that is outside the reach of my blue team they can't signature that right because i'm using a different mechanism to communicate that they don't have control over and that forces them to always be hunting always be responding and it lets us start from within environments in an assumed reach mentality per se right because we've popped in we've gotten our persistence mechanism there once um and they may have trouble finding it

so let's go back to our scenario at the beginning where we were targeting food right the customer came and said hey can you do foo assuming food was valuable we'll say yes right um and we might even have say infrastructure already built right so we use terraform heavily um so that we can deploy all of our infrastructure you know um with like one or two clicks um we might already have a persistence mechanism that is one or two hops away we might be able to activate it within say the next week right because the challenge with the persistent mechanism persistent mechanisms is they're not always readily available to be activated but it might only be one or two hops

away and so that will let us do a test to the environment um that can help us challenge our blue team right because they'll suddenly see some signals start up they'll suddenly see something potentially going against a target and we can evaluate the security of that target in such a way that they'll be challenged and you know to wrap things up this largely works because we have fairly tight coordination with our blue team right we have gone through the trouble of sitting down with the blue team which like i said is called fire in our place and they are some of the best hunters i have ever worked with and best forensics people and literally one of the best blue teams

i've ever had the privilege of working against um and they they know we're going to do it right they know that we have this sort of building in place they know that we have the sort of mechanism they know that it's something that they need to figure out how to deal with and they are accepting of it right and it lets us challenge them um and continue to meet the business needs without having to break our rules of engagement right which is pretty awesome all right any questions

you