Welcome back. And thank you, Corey and Matt, for supporting us,
supporting the Red Team Village, supporting DEF CON and the community.
And without any further ado, take it away. You're live.
Thank you.
Thanks, Omar. So this talk is called Breaking the Attack Chain,
Unexpected Wins and Fails from Two Stimulated Adversaries.
So here's the agenda. We'll start with who we are,
and then we're going to cover some wins and some fails
across a broad variety of different categories of Red Team topics.
And then we'll finish off with some of our just notes,
and also we'll open up the floor for questions.
So who we are. Matt, you want to say who you are?
Sure. So I'm Matthew Edelberg.
I'm a Principal Security Consultant at Optiv.
I also help lead the Adversary Simulation Team.
That's pretty much our fancy way of calling what we do
for our red, purple, and physical-based,
real-world scenario-based-driven operations.
Also authored and developed several open-source tools and frameworks,
mainly focusing around EDR, evasion, and bypassing security controls
and remaining low underneath the radar.
That's really where my passion is.
I did do, for a while in the beginning of my career,
focus a lot on wireless.
So kind of that whole spectrum, sort of one area, a different area.
Also, I've spoken at numerous different conventions,
you know, DerbyCon, B-Sides Las Vegas, HackFest URCON.
Really just passionate about red teaming operations
and the nuances and always improving that concept of
sharpening that spear, staying low to the ground.
I'm going to turn it over now to Corey
to kind of give a brief introduction as well.
So I'm also a Principal Security Consultant at Optiv,
specializing in Adversary Sim, or red teaming,
or whatever you want to call it, depending on the buzzwords of the day.
I've participated in some open source tool development,
and then my passions really center around data aggregation
and building lab environments for the red teams, basically.
So before we begin, I wanted to basically caveat this.
Red teaming is a different thing to different people.
This presentation is based on our experience
during our engagements, real-world scenarios.
These are not made-up scenarios.
A lot of them include real screenshots from real engagements.
Everyone does this differently, right?
So some people's definition of a red team is just an app testing team.
Some people's definition of a red team is a full-blown,
zero-knowledge assessment every year or every two years or whatever.
So everything in this presentation is also situational.
So we're not going to cover the client's demands.
We're not going to cover that it was raining that day
or whatever reason we have for each scenario.
So there might be a little bit of background information
that we're going to gloss over, but it should be fun.
This talk is going to kind of be a briefing style,
so it's kind of almost like if we're talking to you,
it could be if we're a red team or if you're a blue team,
it's sort of covering our debrief of a lot of these scenarios
that we've encountered on different assessments.
So kicking off the first topic here, we'll be met with some OSINT stuff.
Yep. So we all know what OSINT is.
It's one of the most, I always believe it's one of the most vital things
when you're starting off an engagement.
You know, we're basically just professional Googlers.
Well, one of the things that differentiates, you know,
just quickly Googling, seeing what you can get
and like a deep methodical approach is honestly the level of detail,
whether you have proper API keys, you're scraping the right data.
And as I kind of say this, all those different things we know,
they can be sometimes an endless rabbit hole where you go down
and you never know if it's going to yield you stuff.
You could be starting to pull down, you know, employees,
Instagram posts, Facebook, you know, all those types of social media things,
pulling out, trying to see if there's maybe a picture or something
or some kind of metadata that you can scrape.
And you can be doing that for thousands of pictures
and it may yield nothing.
But oftentimes, it's still a very vital role
and can lead to a lot of unexpected wins and successes,
which we're going to talk about.
And you can kind of see with this great example, a bit of background.
We like to call this, you know, hashtag Mondays might delete later.
I see no problem.
A bit of the background on this is we were looking at a client,
we were doing a remote breach simulation,
which is our terminology for Red Team Ops.
And we did that typical, started building the profile,
looking at who the employees were,
trying to get an understanding of what information was out there
until we stumbled across the company's Instagram account.
And this picture was originally taken by another employee
that the company's Instagram account kind of liked and retweeted.
It was basically just, which we have blurred out,
a bunch of PII information, which included, you know,
date of birth, home address, credit card, bank transactions,
a lot of other very sensitive stuff.
But there was a lot of these types of pictures just sitting on Instagram.
So one of the things we always like to drive is sometimes
we don't even need to get inside the network, get domain admin,
do all those cool lead hacks to get that crown jewel vital data.
They provide it to us.
And I would say that this is not just that one unique time.
This is something that's constantly out there.
As a lot of companies, they train their users,
they don't click on phishing links, don't click on this,
but they don't teach them, don't post this or this is bad,
this is something sensitive,
especially when it comes down to certain departments.
When you look at a marketing team,
they're not given the same level of training that maybe someone
that actually handles sensitive, like, you know, credit card data
in the sense that those two different things,
the awareness there is there are huge gaps.
And that leads us to our next sort of major one that we love to look at
are paste sites.
You know, there's many different ones, Pastebin, anything like that.
I mean, scraping these are just...
you can yield a plethora of data.
I mean, it's not a lot of money.
I mean, correct me if I'm wrong,
but I believe now for a pro license for Pastebin,
you can, for $50, you can scrape to your heart's content.
You put that in, say, like a Caldana instance, like Elk,
and it just endless scrapes.
You can kind of just make a search thing like search client name
and look at every single thing that references this.
And that's honestly something so simple, so unique and so fast
that you can yield things like usernames, credentials, APIs,
hell, even credit cards and other sensitive PII.
As you can kind of see,
we've been able to pull out actual credit card information
going right down to the user's security questions,
where they live, their phone number,
all that information.
With all that information, we were able to actually,
because the client was a bank, provide an impact scenario
where we could actually bypass all the security controls
and start doing some financial banking on behalf of this individual.
Because all their controls were like,
what's your bank account number?
What's your security answer for this?
What's your secondary one?
And do you still live at this address?
What's the last four digits of your phone number?
All those typical security controls to prevent fraudulence are all out there.
Great plate hackers constantly are dumping data there.
And in the top example, we actually can still find valid credentials.
We found two-year-old valid credentials to a third-party portal,
which led us to have access to a setup site.
And from there, we were able to get enough information
that allowed us to establish a foothold into their internal network.
So something like that can sit there for years
before it's even discovered by the client.
And that drives the impact so much more.
So what can you do?
And this will be the style of that debrief,
is how do you break this chain?
In the sense of all these wins, how do you break this?
How do you prevent this from happening?
And it's really hard, especially when data is out of your control,
when you get stuff on those PACE sites,
it's next to impossible to take it down.
So there's no surefire of, oh, this is up there,
we'll bring this down, we'll cease and desist,
and that will be the end of it.
Especially like what I was just describing with PACE sites
and being able to scrape and have that local database.
Once it's there, it's hard to get rid of off every individual who's scraping.
So it really comes down to understanding what's out there.
Find those information sources through profiling or intelligence gathering.
We like to call it public information profiling or data intel.
It's performing that on yourself, your company,
regularly to understand, oh, there's new data coming out there.
Now I have to adjust.
So it might be, hey, we discovered a couple of clients,
there's sensitive data out there, we need to contact them now
and get all that stuff scrubbed.
So that way it's not valid anymore.
And things like that, as well as awareness training,
not just looking at, hey, users, don't click on links,
or if you get a phone call from someone suspicious,
don't follow the instructions, but training them through impact.
Here's a picture of something, and do you think this is sensitive?
Well, here's what an attacker looks at it as,
and this is why it's so impactful.
And just kind of visually explain to them
why this is so detrimental to post.
And that can oftentimes help reduce that gap
from like this big to like this big.
You're always going to still have a little space,
and that's where intelligence sources come into play.
So those were some pretty cool wins you had there, Matt.
But I figured we could cover some failures, right?
So obviously, a lot of successes do happen,
but also failures happen.
And I think maybe blue teams and red teams can learn
from some of our red team failures.
So this is what I like to call the red herring domain.
So basically, the TLDR is that email alias domains
do not make great password guessing or enumeration targets.
So we all remember when Office 365 enum worked perfectly.
Those were the halcyon days of, man, that was a good time.
But basically, the client had clientdomain.com
was their email address. That's what they used publicly.
It was on all over their website and everything.
So we figured this has got to be... this is easy.
That's what their domain is.
We started password guessing,
and we're getting all kinds of weird results.
Valid user, invalid user, bunch of 401s and weird...
like some users have two vectors, some don't.
It was very incongruous with what we're used to seeing.
And basically, we were like, hold on.
Is this really their email domain?
So we actually used reverse DNS, or reverse Whois.
Vue DNS has a very cool reverse Whois tool
where you can basically type in the contact information of a registrant.
So, you know, info at clientdomain.com or whatever.
And then you can view all the other domains that are registered to that email address.
Obviously, it can get a little hairy if you have, you know,
anonymization with the Whois records.
But basically, we used that.
We pulled up a list of all the valid domains that were registered to that client.
And we looked and actually for each one, we went through and checked them against Office 365.
And then eventually, we found the real one, which happened to be myclientdomain.com.
So it was just sort of a weird scenario where we basically burned a few days
on an assumption that this was obviously the domain,
when in reality, the domain was something else.
So I guess the takeaway is to trust your gut.
Check and then double check, right?
If you're getting incongruous results or something that doesn't match up
with what you're expecting when you're executing a tool
or whether you're doing it manually, dig into it.
Figure out what could lead to these different results.
You know, the getUserRealm functionality of Office 365,
you can use to sort of manually inspect each individual element
and see, okay, is this a valid domain in Office 365, etc.
Those sorts of manual checks can keep you from doing these fails.
So Matt's going to cover another funny one about building.
Yes, we thought it'd be fun if we both share our experiences in the fail realm.
So this is the one I like to call wrong building.
So like I kind of said, that rabbit hole, it can lead to so many great results.
It also can bite you.
So in this kind of bit of background here was the situation.
We were hired to do a physical breach assessment
to break in physically into a building.
The building in question was this large commercial high-rise
and we're listed as safe arguments in the story, the seventh floor.
So we did a lot of OSINT and we were able to find some information,
including a page for the building that basically listed out,
you know, who is the property managing company,
like who is the actual person on site, what were the vendors,
even forms to fill out.
Say, for instance, if you were one of the tenants there and say,
you know, telecom went out or pipe burst, paperwork and all that stuff,
you know, who to contact, here's like the, you know,
all this other information to know which building and everything like that.
It was great.
We were so happy because right there we could create a perfect scenario.
And we did.
We kind of decided to come up with a scenario that we were, you know,
coming into the building,
going to be doing some telecom fixing on some of the floors.
We got even so detailed.
We were able to kind of create a fake work order.
We were able to find out uniforms for that vendor and we addressed,
you know, perfectly right down to the level details.
We had called beforehand,
knowing when the office manager for the client was out.
So we left the voicemail.
We left lots of different things just pretending to be the property manager.
Say, Hey, we have some guys coming into the building.
They're doing some work with telecom.
I've been getting a lot of calls throughout the day,
just people verifying them.
I just wanted to let you know that they should be at your floor in the next
20, 30 minutes.
I'm just stepping up for lunch.
So I may not be able to be reachable by phone, but if they do,
have them show the work order and make sure everything like that,
their names are blah and blah and everything like that.
So we really had provided enough information so that way they could go
listen to the voicemail and say, okay,
there has to be a work where we have to check all those things.
So we were kind of creating that self-validation.
So we get up there, talk to the receptionist.
The receptionist goes, okay, I got to go get the office manager.
Point this at the, you know, like the sitting area.
We're sitting there, just sitting there.
And then maybe we kind of realized it's been a while,
but maybe another five, 10 minutes later,
the office manager came out with someone else who was the property manager.
And they were like, so who are you guys?
You're not anyone I've ever worked with.
You don't even work at the company I've never worked with.
I'm like, oh, well, you know, so-and-so that's the property manager contact us.
He probably, he left a call. He was like, yeah, but here's the thing.
He works on the bottom floor in the retail section.
I handle all the commercial high rise and corporate stuff.
So I'm going to ask you again, who are you?
What do you do in that situation? You kind of have egg on your face.
You know, we had done such great OSIN and everything like that.
But the problem was,
we didn't realize that the building was split property managers for retail
and the corporate renting.
And in that moment, like your perfect pretext and everything like that,
just goes out the window.
So me and my colleague were sitting there.
We literally had this conversation, just staring at each other,
not to like sweat and everything like that.
You can't just instantly pull up like to get a jail-free card.
Like, ah, this was a scenario and stuff.
You try to always want to deescalate.
So you do your best.
Like, okay, that seems really weird.
You know what, let's just stop.
Let's take a moment.
I called someone who was obviously a co-worker of mine
and pretended like I got the voicemail.
And it's like, hey, there's some issues.
Can I explain the situation on the phone?
We're not going to do any more work.
All this stuff, just trying to really paint it off
that we don't want to do anything
because obviously they're very tense and upset.
So it's really taking those steps to deescalate it.
And it ended up, you know, we're like, okay, well, you know what?
Let's give a business card.
Give us the business card.
We're going to call.
Let's maybe get on there.
We can figure this all out.
But I will tell you,
that was the most awkward elevator ride down
when they came with us in the elevator
and were just sitting there like,
this elevator is going so slow.
The moment we got to the ground floor,
we shook their hands.
I'm pretty sure we had a little bit of sweat on our hands
and we're just like bolting right out.
So those are the things where, you know,
sometimes OSINT can really, you know, bite you in the butt.
All right.
So taking a left turn here.
So a different category than OSINT, initial access.
So initial access, you know,
we can define it as, you know,
that initial point of compromise, right?
So nowadays, starting from that perimeter environment,
a lot of attack services are heavily limited.
Companies have, you know, nothing but 80 and 443.
It's pretty much SSO everything,
redirect everything through their central auth,
and everything's multi-factor, right?
So the approach here as an attacker is to prioritize
that breadth-first search for that weak point, right?
So, you know, if it's Office 365
and they have basic auth enabled on AWS
or something like that,
that would be an example of a weak point.
Or, you know, here's some other common techniques.
Obviously, we're not going to cover any of these in depth,
but password guessing is really common.
Web app vulnerabilities, if you can get deserialized
or some other, you know, similar, you know,
roll your own web app issues.
Spear phishing is common.
Phone pretexting is common.
And then lastly, physical access isn't easy,
especially as a backup plan.
It works pretty well.
So multi-factor spear phishing.
So phishing is dead, long live phishing, right?
We have seen, especially in the past couple of years,
that phishing is really getting a lot of eyeballs
as far as tooling solutions
and just general alerting and controls.
Attachments don't work from the perimeter anymore
with an email filter.
Email filters have their own URL filtering now.
Any email that's sent to more than five people,
for example, might just get blocked
because they're assuming it's a spear phish.
People are good at reporting them.
I mean, I guess it's like over the years,
we finally started to get better at training people
and developing technical solutions
so that it's actually not as successful.
However, it does still work, even with two factors.
So we like to actually focus not necessarily on passwords,
but actually on tokens.
So there are MFA-compatible phishing tools
like Evilginix or Mudlishka
that actually let you gather the tokens.
So you're actually, with these tools,
you're essentially sending a message with the URL in it,
the user is browsing to that URL,
and then they are basically using you as a proxy
to interact with the real site.
So if they're using your site as a proxy,
you can capture all the authentication tokens,
API tokens, whatever it is that that user is sending.
And why do we like tokens?
Because tokens are harder to track.
Lots of people don't have anomaly alerting
or anything like that on token usage, right?
So if I log in from a new device,
it says, whoa, this is a new device,
you need to authenticate it.
But if I just take the already valid token
and replay it onto another device,
oftentimes it just works without any sort of double checks
or anything like that.
The other reason why we like tokens
is because they're hard to reset.
So a lot of the traditional IR procedures,
they focus around Active Directory, right?
So you reset your Active Directory password,
you lock the Active Directory account.
That doesn't necessarily have any triggers
to a third-party SSO site.
So if it's Okta or another provider,
there's no link to Active Directory
that necessitates a token refresh
or a deletion of all the tokens
when a user has an incident and the password is reset.
So here's a scenario.
Basically, here's a screenshot of Evogenics output.
The SID token, this is specific to Okta,
but basically, after the user had authenticated
to our Evogenics,
and then they had pretty much realized,
you know, okay, that's not great.
But we were actually able to use that token
to access their Okta portal, basically,
which had access to, you know,
not only all their other third-party apps,
but also VPN or other similar,
you know, higher security context things,
which potentially could yield to a foothold.
So, you know, before I cover breaking and detaching,
last thing I want to mention,
just if you're a red teamer,
next time you get a token,
or if you do phish a user with that,
you know, Evogenics or another solution,
do what you would do with a credential
and actually do stuffing.
You know, try to use that API token
across as many different applications as you can,
and you might be surprised at how easy it is
to just put the token in and then go.
I mean, with Okta, for example,
you literally just put that SID token in your browser,
go to the company's Okta site,
and at least at the time that this gig was executed,
it worked.
There was some JavaScript sub-resource integrity stuff
that we had to bypass,
but it was, you know,
API tokens or Vera tokens,
it's definitely a good area to focus.
So, breaking the attack chain, right?
How do you fix this?
Because it's really tricky to monitor.
Like, Okta doesn't have default alerts
for geolocation token usage, right?
So, you should generate those alerts, right?
So, figure out how within your SIEM or whatever
to alert on token usage,
not just password usage, right?
Instead of suspicious login events,
maybe look at suspicious token usage
or just a session happened to move
from this site to this site or whatever,
or a different user agent or whatever.
And also, build those connectors
so that those tokens are automatically reset
if the user does change their password.
Or, if it's not automatic,
build it into a playbook
so that your incident response says,
a user got phished.
Not only do we reset their Active Directory password,
but we also reset their Okta tokens
or their Office 365 tokens
or any kind of tokens.
Typically, there are tools within these web portals
to actually manually refresh a user's session.
So, build that into your IR playbook
so that you don't have that token
that's been outvalid for 24 hours
after the password was changed.
And then lastly, here's a little shout-out.
Generate IOCs for known tools.
So, for example, Evogenics actually has
a hard-coded IOC built into it.
It's been published on Twitter before.
I won't say exactly where it is in the GitHub,
but if you're using Evogenics
and you haven't forked it and edited it out
and removed the IOC from it,
it should be easy to be detected, right?
Attackers sometimes use off-the-shelf tools
like Evogenics, and that's relatively easy
as a blue team to download those tools,
run them, execute them, and see what that looks like
and then generate IOCs based on that.
So, after some successes, I'll cover a failure.
So, this is what we call the traveling user problem, right?
So, we have, on breach engagements,
set off alerts with bad IP hygiene.
We typically like to use non-attributable IP space, right?
So, Amazon, Azure, VPNs, etc.
But that's a double-edged sword, right?
So, users don't usually use AWS, right?
And also, geographically improbable access.
So, like, if a user is based out on the East Coast
and you're using a US West Amazon instance,
that could trigger an alert if you sign in as that user
and it says, oh, this user just signed in from here
and then they signed in from there.
And also, you know, reusing that single cloud...
you know, we're lazy, right?
We're red teamers, we have so much going on.
But sometimes we get lazy, we'll reuse the same IP address
that we've obtained for multiple accounts, right?
So, you know, maybe we log in on that one instance
and then we log in as another user just to test those credentials, right?
That's an easy indication that not only is it an AWS IP
that's authenticating to our VPN,
but also they just authenticated as two valid users
and it's not, like, an office location, right?
So, for red teamers, how not to fail?
Know your IP space, right?
Use some of those blue team tools in your red team engagement.
So check your ASNs, right?
So I put some links at the bottom of different services
you could use to check the, like, IP reputation
or, you know, sort of the footprint of the IP addresses
that you're using.
And tell the story as well, right?
That's sort of our 2020 breach team slogan is tell the story.
But basically, one IP is mapped to one valid account forever.
So if we're going to trigger a valid login as a user,
if we're going to actually start that pathway of emulating,
that's when we'll say, let's go into it.
Let's make this IP address this user's IP address
and then keep using that for the rest of the engagement, basically.
So that is very... it's harder.
Obviously, they can still alert on, hey, this is an AWS IP logging in
and that shouldn't be the case.
But also, they can say, well, they did log in here
and they logged in there and maybe they're just using a VPN or whatever.
So it can be a powerful thing.
Yep. Now we're going to flip over to foothold.
And before we kind of go there,
let's kind of do a little bit of an explanation.
When we talk about, like, initial access versus foothold,
we're really kind of differentiating the two kind of concepts
of, hey, we were able to get some access through password guessing.
It may have given us a small step in,
but we're not at the stage where we can, you know,
start using our post exploitation frameworks, whatever that is.
That's what we call the foothold.
We've established the beachhead and we're moving.
We begin that privilege escalation and moving laterally.
So that's the major definition and difference.
So in this example, which we're going to kind of talk about,
this is actually a runoff of what Corey was just describing
with the Okta and SIDS and Tokens.
So we were inside their portals
and we were able to get access to several different applications
because we sent out a phish and one user clicked it.
So we had tons of access, but only through their portals,
like the tiles and whatever, you know,
substant applications that were exposed to the internet.
So as we're going through all these different sites
and third-party applications,
because we had access to the email account,
we saw an email had been triggered.
We're like, okay, that's kind of weird because it was an IT ticket.
And what basically it outlined, as you can kind of see right here,
was, hey, something's gone wrong.
And it basically was, I clicked on this.
I know it was something bad.
I've already changed my password twice,
which kind of goes back to what Corey said on how valuable
resetting those Okta or, you know, those tokens and SIDs are,
because at the end of the day, we didn't need,
like the user had changed her password so many times,
but we were still in.
They had already, they also attached our email.
So our Spearfish email, as well as the, you know,
security alert of sign-on that we had triggered by logging into an application
that we weren't aware of had like that notification prompt built into it.
We were just pillaging through the data,
trying to get as much information we can to help kind of solidify our next stage
of moving into that foothold.
So I helped us ticket with our Spearfish and all this stuff.
Pretty damaging, right?
Hard to kind of back, you know, move around in something.
So going back to my initial thing with the story about the building,
you have to always deescalate.
So what did we do?
We removed the attachments and we replied back saying, sorry, my bad.
And within a few seconds, because good old help desk,
they closed the ticket instantly with a nice little message saying, hey,
don't worry about it, I'm glad you were able to be assisted,
if you have any other questions.
And we also took an additional step by actually adding a mail rule
that any type of emails that were related to this help desk ticket
would be put into the user's junk bin.
So she would never see it.
With all of this, we were able to then kind of do a comprehensive
internal Spearfish.
Starting on a couple of the employees that reported to this user
with a typical great macro document.
It was an Excel timesheet that they actually had been passing around,
all the staff passed around.
And we basically just added a few verbiage saying, hey,
we're having trouble seeing it, you have to enable macros.
Can someone take a look at this and see if this is right?
And we sent that out, and with maybe half an hour, an hour,
we received our good trusty beacon.
We love to see those come in.
So that was a great example of how just because something happens,
a ripple in the whole environment is kind of created,
they can't always be a wave.
And if you know how to handle and deescalate,
you can take that ripple and make it invisible.
If you don't, you leave it there too long,
or you don't handle it properly,
you can definitely make that ripple into a giant wave.
And now instant responders are investigating,
and your whole office burned.
So small things can really take time just to deescalate it.
And it's nothing technical, it's just using soft skills and communicativeness.
So how do you stop against this?
One of the biggest things we've seen, and you can kind of take from the story,
is that training.
It actually turned out after when we did a debrief with the client,
that the client actually had a separate portal for incidences.
So helpdesk handled the day-to-day issues,
I can't log in, my password, those types of issues.
But there was a whole separate portal for like,
hey, I think I've been spearfished, something's weird, I'm seeing something.
And because they put that ticket in the helpdesk,
there was different responses and everything like that.
Helpdesk, they weren't trained or aware that maybe this is something weird.
This user provided a lot of data, and then all of a sudden, deleted, deleted,
and saying, my bad.
If you read that thing, it kind of looked like this person
was two different people talking.
But their SLAs and everything like that,
they were just trained to not spot weird or anomalous behavior.
And that's the key word.
We always talk about indicators of compromise,
but there's indicators of anomalous.
And if you can stay and live in those indicators of anomalous,
you're going to have a higher chance of success, as kind of described.
So really teaching your users how to properly handle those incidents.
Don't just call the helpdesk. Helpdesk is not security, so to speak.
And then kind of really focusing on when you get those types of events,
like prioritizing a real-time communication.
Don't wait for an automated message, don't do anything.
And that's both on the user's front and on your IT and security team.
In this example, you saw all of them were message-based.
Putting in a ticket is great, you have all the evidence there,
but following up with a phone call saying,
hey, I'm really worried something happened.
You have someone on the phone now, you're talking to someone,
or you go in the office, you can find them.
Talking, being in person, it changes the level of severity
and forces people to react faster.
A ticket, most of the time, may not come in at the same urgency.
And that really can change the amount of time we have as an attacker
to be successful.
And just by de-escalating, we had enough time to figure out
a good, convincing internal spearfish, which we love to do,
because you're bypassing all those mail filter controls.
We looked at them and saw, oh, all the users are passing
this Excel document around, we can put a macro payload in it.
And that just adds to the legitimacy of the attack and the story.
All right, those successes were great, but let's cover some failures.
All Red Teamers should probably know this, but putting all your eggs
in one basket is bad.
Sometimes, even the best tools are buggy.
We use Cobalt Strike. It's a great tool, it's very powerful,
but obviously, it's not perfect.
This was at a time when, basically, this was right before
the Cobalt Strike 4.0 release, and there was a bug in execute assembly
at one point, where if you executed anything in execute assembly,
it would crash the beacon.
So, you know, the little screenshot's kind of funny,
but I'm sitting there, and I run, you know, I had worked really hard,
and I had done all my Red Team things, and I finally got this beacon.
And I was like, all right, I've been working really hard,
I should use this, I should take this opportunity, seize the moment,
and really go and do all my, you know, do my reconnaissance,
do my situational awareness, and try to move laterally, etc.
So the downside of that is I didn't really think about, you know,
the presence of that bug, and also how much I was relying
on that single beacon. So luckily, I did set up persistence
before I executed that, so it came back the next day
when that user logged in, but it was a long 24-hour period
of basically waiting and saying, I shouldn't have done that,
I shouldn't have executed that, you know, it was kind of a kick yourself
moment when you just potentially burned a couple weeks of work
just because you got excited when that beacon came in.
So I guess the takeaway here is, if you are, you know,
once you finally land that shell or that foothold,
don't necessarily go and use it immediately.
Maybe take some time, just exist in the environment,
gather some information, listen passively, etc.
And then maybe establish a backup C2 or another foothold
before you start executing higher impact actions, right?
So start out as low and slow as you possibly can, and then
ramp it up as time goes on instead of having your automation
and everything ready to go for that initial beacon to go.
Maybe let it persist and just sort of blend in
for a little bit before you go all the way.
So now we're going to cover lateral movement.
So we didn't put a lateral movement overview slide
because, you know, it would have been like 20 slides
of what lateral movement is, right?
It's something different to everyone else,
but basically lateral movement is establishing more pieces
of the attack chain within the internal environment, right?
So, or compromising users, or etc.
Basically, this scenario is what we like to call
acts like you belong, right?
So blue teams know publicly available tools, right?
They can go out and they know about GitHub, guys.
Like, it's a public site.
Anyone can go on there and download whatever tools.
You know, they can download ImpactKit.
They can download anything that's on there.
They know about it, and they can use it, right?
Tools can stand out from the baseline, right?
So, you know, user agents, for example,
if you are using PowerShell and the environment
doesn't use any PowerShell, it's a classic example, right?
If they don't use PowerShell and you do,
then now you're standing out from the baseline.
And typically, you know, this has been, you know,
there's wall bins and etc., but living off the land
or blending in is probably the best way to go
if you're red teaming, right?
It's harder to catch someone who's using the same tools
as every other user in the environment.
So this is a scenario where, basically,
we had a limited foothold, so we had that C2 access.
We had credentials, so we had plain text credentials
for this user.
Basically, we, you know, enumerated our access.
This is net user output.
Of course, we didn't actually run net user.
That would be way too loud.
We generated this from LDAP.
But, you know, we looked at our group memberships,
and we saw one of those group memberships is Citrix, right?
So instead of, you know, oh, let's move LIDAR,
let's run ImpactKit, or let's run CME or Bloodhound
or whatever, you know, let's just log in to Citrix
and see what's in there, right?
Not only is there potential footholds there if they have access
to Citrix desktops, but also, you know,
you never know what you might find.
So on the right here is a screenshot of that Citrix portal.
So we logged in, and essentially this, you know,
everything's censored because it's client stuff,
but basically this was a SCADA environment
that we basically had direct access to monitor
a lot of their high-sensitivity SCADA applications
and devices within the environment.
Without, you know, we didn't use any real tools to do this.
All we did was proxy our traffic through our beacon
and then just log in.
So that's... and that's... they didn't detect it
because that's very difficult to detect a normal user
logging into their normal thing that they normally do, right?
So now Matt's going to cover a lateral movement fail.
Yes. So this was an engagement where we were dwelling
in the client's network for three weeks.
They had no visibility into what we were doing.
As you can kind of see from our maps,
we had a lot of access.
We had basically been able to move through,
basically compromise.
In fact, at one point we became the security team,
which was a key part of this story.
So as we're moving laterally through the environment,
there were lots of TOIs, targets of interest,
that the client had set up for us to compromise.
Kind of, hey, once you're in, it's not just,
hey, get domain admin, that's like the easy, cool thing,
but show that impact, that value.
That'd be like, you know, decrypt credit cards,
access our secret sauce that's stored on this network,
you know, access data, all the sorts of things
that can really show like, oh my God, we have been hacked
and our data, our business critical stuff
has been compromised, like that integrity.
So how we actually managed to establish
our initial foothold was on a box where there was a domain admin.
So yay, we had access.
We hadn't really used this account yet,
because for most of the port as we're moving,
we were able to simulate using different users,
jumping to various jump boxes,
or getting to different systems, kind of blending in.
And one of the goals was to get access to shipping manifest
and all this type of very powerful information
related to SKUs and all that stuff.
So, unfortunately, we couldn't get onto any of the user's machines
because they were in a different environment.
They were in like a subdomain,
but the domain admin account actually had privileges,
and it was actually still an administrative privilege level set,
high integrity on those boxes.
So we were able to authenticate as this domain administrator
on one of the warehouse's computers.
Well, that was where it was kind of getting weird,
because the account was designed as a backup account for TVs and stuff.
And eventually, like I kind of said,
we were in the security IT guy's chat room.
That's actually the Malware War Room Council,
that's what they called it.
We were seeing like, why is this account logging in here?
And then they were starting to see tidbits.
So as they were going back through and knocking down our beacons,
we were kind of going around in a different direction.
But we eventually lost all but one or two hosts.
We still had access in the environment,
but we had to start all the way back from square one.
And why this is one we like to talk about,
especially when we're kind of going through any type of our debriefs
internally and stuff is, you know, DA is cool and stuff,
but oftentimes companies and stuff, they're going to look for that.
Are their DA accounts logged into random places?
I know most of the time that's where everyone goes first.
They have a lot of controls around,
but you can do a lot with like other types of accounts.
Like I kind of said, IT security guys, admins,
they have a lot of the same access that a domain administrator.
And oftentimes when we look at this,
like these types of goals and end results,
like maybe compromise an application,
get access to the database behind it,
where like all the credit card or juicy information is.
Domain admin doesn't really play into the fact.
Domain admin just gives you administrative rights on the box.
It doesn't give you, you know, admin rights into an application.
So that's something where you always want to keep in mind.
So we always kind of look at it like, who are you logging with?
Is there value to it? Like, you know, it might be an easy skeleton key,
but are you going to create more waves than it's worth?
And this is a great example of that.
We pretty much, we were in over 50 boxes
moving through different environments
and we had to go all the way back to square one.
So breaking this chain, it really comes down to baselining
and understanding your environment.
There's a great term called least frequency.
If you're not familiar with it, the concept is that
if you're baselining to the point where you know your environment,
you know, like what user agents everyone uses,
you know, your Google Chrome or a Firefox shop,
all those types of things, that's your baseline.
Everything's going to be the same until you see some differences,
like Internet Explorer user agent stuff.
And those are the least frequent objects or events
that now you can drill into, well, why did that happen?
If everything else is standard operating procedure,
you've seen this for day in, day out for like three or four years,
and then you see this one event for the first time,
you kind of can shuffle all that stuff off to the side
and focus in on those few unique new events.
May not be malicious right away, but you can start digging
and that's how you can make this large cloud of noise,
something smaller and easier for your team to handle and manage.
But when it comes down to lateral movement,
the great tips we often recommend are, you know, auditing your ACLs,
making sure that, you know, users don't have unnecessary privileges.
That's often the easiest pitfall for lateral movement.
To go back to what Corey said about, you know, the Citrix and stuff.
One of the issues was there were so many unnecessary privileges
that gave us hops, skips, and jumps in the environment
that just made us so much more successful.
There are other great tools.
I'm really surprised this one is not talked about a lot or used.
It's called Net Cease.
There's a link right down there that we provided.
Essentially, what it does is it prevents the remote call to net session in Noom,
which if anyone's familiar with, that's how most great tools
that are out there on GitHub or in the hacker space get all that,
you know, who's currently logged in.
It doesn't disable or hamper it.
What it does is it changes who can call it remotely.
If you're on the box, you can call it.
It doesn't matter your privileges, but if you're remote to a box,
it can only be certain ones rather than what's default,
which is anyone that's in the domain user group.
It kind of changes it to be power users, administrators, or another group.
And with that patch and that little registry change,
which can be pushed out through group policy,
it really does hamper your ability to see,
oh, I need to be user X and I'm user Y,
and I need to figure out now where user X is.
You can't just start hitting every box and looking at any...
using any tools to find that user.
It really changes the game.
Also, making sure, you know, privilege accounts are protected,
you know, there are protected user groups
or credential delineations and delegations.
Make sure that, you know, you're not...
if someone logs in a service account or something like that,
they're not just stale, sitting in memory,
or they're not just easily available.
Really kind of protecting the actual sensitive
of credentials or hash credentials.
So now we're going to kind of talk about persistence.
It's one of those... it's more of an art form, I like to say.
There's great techniques or something like that,
but whenever you hear about a new one on Twitter
or there's an article, most of the time,
people pay attention because they really get scared,
and that's, like, the focus of patching,
so when you find vulnerabilities that allow.
So I always like to take the arts form.
And it really comes down to, like, you know,
you could go that crazy route that they might have it patched,
but if, say, your payload or whatever, you know, binary, DLL,
whatever you want to have it, can persist on disk,
or it stays on disk.
It could be somewhere in, like, you know, the user app data,
temp folder, something like that,
and whatever security appliance is just not alerting on it,
if you have, say, you know, a bat file or something
where it drops into a start follow of a user and calls it,
it's probably not going to get detected
if it looks right telling that story again.
So in one of the scenarios we did,
we were persisting on multiple different machines,
and what we ended up doing was just dropping a bat file
that would call gpupdate.exe, but our binary,
our evil binary was gpupdate.exe,
because it was obviously putting app data.
So when you looked at it, strictly from the point,
oh, the process, you know, the binary gpupdate started up
when the user kind of logged in, and it wasn't as suspicious.
I mean, if you drilled in, you would have seen,
well, why is gpupdate not in C system Windows 32?
Why is it in app data?
And one of the great things about that is that
if they're looking at things like what this file is,
there's something else that's already kind of dragged
their attention towards it, so you're already kind of burnt.
But just staying pretty low, making tiny ripples,
you hang around that, you know, indicators of anomalous.
If someone looked at it, they probably wouldn't blink twice
until they looked at the file path or other attributes of the file.
And now it comes down to, I think this is one of our favorite ones
to talk about, is conference rooms.
So we were on an engagement that was getting close to the end,
and it was very late when we had managed to finally get through,
and we really wanted to establish persistence
because we couldn't afford to lose.
We were really coming close to the tight line of the end.
So it's very late at night. Okay, perfect.
So we decided, okay, we know what their conference room systems are.
So we put a beacon with persistence on it, thinking, you know,
no one's going to look at them. It's pretty late on a Friday.
No one's going to, you know, do anything about this until Monday, if anything.
And let's be honest, no one's going to come in over the weekend
and use the conference room machines.
But it was a pretty solid idea.
What actually happened was their SOC was like,
why is there traffic coming from the conference rooms at 2 a.m.?
Like, what? Is someone using these?
And that in itself was actually louder than anything we had done previously
to get in because it didn't make sense why these conference rooms
every so often would call out to the internet and stuff like that.
And that really was kind of like the problem was
we thought we were being really stealthy and quiet.
And for all purposes, like, you know, there was no artifacts left.
There was no, like, alerts from the EDR consoles or dashboards.
It was just someone saying, well, this traffic, it looks weird.
Our traffic baseline is that, you know, 8 a.m. to 5 p.m. is a lot.
And then afterwards, it's a little. And then all of a sudden, there's a big spike.
So it's like, OK, what's going on here?
And then they dug deeper and deeper.
And it's really hard to come back from that because they've done everything right.
Like, that's so low of an indicator that there's nothing you can really mask
besides maybe figure out a better story.
So as I was saying before, this whole persistence, it's really an art form.
There's no, like, silver bullet that if you do this,
there's no way anyone can persist on your environment.
You know, patching and keeping up to date is always a great thing.
But kind of like the stories we just kind of described, like, it doesn't matter.
It really comes down to how are you monitoring? Do you have a good baseline?
Do you understand, like, what processes typically should start up for every different department?
Does HR just use Google Chrome and Outlook and all the services related to that?
So, OK, there's your baseline for that department.
And looking around, like, file locations, you know, the ones that hackers love to use,
you know, all those, looking for things that are spawning from there or starting up there,
that will give you a huge indication, like, nine times out of ten,
there should never be a DLL in temp or app data that's starting up right when a user logs in.
And of course, the one that got us burned is the unusual net communications.
Looking at those things, if you can drill down that precise,
you have a very mature environment and a very mature way of handling instances
that's going to make any, like, challenge, red teamers job a lot harder.
Also, application whitelisting is your friend. It's not ours.
When we're on a box, whatever way, you know, might be in Excel,
Word documents that bypass that, but, like, trying to get persistence,
it's next to impossible if you have a strong whitelist application going.
You know, dropping binaries, like we just described, makes it a whole lot harder.
And then making sure whatever we're trying to slingshot through,
that's not, you know, being caught in any of those chains to get to the nasty
that we call our backup payload, making sure none of that.
All of those things are not blocked through application whitelisting.
It can just be a nightmare. By the time we get it all figured out,
you know, we've persisted too long, not moving.
So it's definitely a key thing to definitely keep up monitoring
and baselining and getting a good understanding for your environment.
So we're now coming to the end.
All right. Yeah, so conclusions, or, you know, confessions of an attacker.
So here's some of our sort of lifting the curtain a little bit.
Attackers use what they know works, right?
So, you know, we use Cobalt Strike because we know Cobalt Strike works.
We, you know, custom stuff is great. We experiment with it quite a bit.
But if it comes down to we have one shot, we have one, you know, DLL or one EXE
that we're going to do, which C2 do you want to use, right?
We're going to, if it comes down to a choice like that,
we're going to make the choice of the most reliable tool, right?
So oftentimes that can be easier for blue teams to identify
because the tool set is shrinking as you're relying on more well-developed
or well-known tools.
Also, one end-to-end attack chain can be easier for us to manage, right?
So as, you know, as cool as it is to have four or five different footholds
that are totally unrelated, different C2, different initial compromise,
different physical locations, that's great.
But the reality is we're, you know, we're red teamers,
so we're doing this in a condensed timeframe with restrictions
on how long we have.
So oftentimes we end up with just one end-to-end attack chain.
And along the way, all those chain breaks that we described
are ways that would just basically send us back to square one
where we'd have to start over and say, we did this, this, and this.
However, they had this security control or they caught us or whatever,
and now we have to start over.
So it's actually, you know, it's... the chains are more fragile
than they might appear.
Users who report incidents are honestly one of the things that comes up
more than we'd like it to because there's really nothing we can do
to stop it, right?
We can't stop users from emailing their security team and saying,
hey, this looks weird.
Obviously, we showed an example of how we can do anti-evasive maneuvers
and say, oh, actually, never mind, my mistake.
But if someone's going to pick up the phone and call a user
or if the user picks up the phone and calls up security people,
we're not a part of that conversation.
We can't really work around that.
So that's where that security awareness training and just relying
and trusting on your users is actually really hard to get around.
And then obviously, defense in depth, it really does win in the long run, right?
So this works for real attackers, right?
Because if you're trying not to get hacked, you're running away from a bear.
So as long as you're not the slowest, you probably won't get eaten.
But defense in depth makes it harder.
Every step along the way gets harder when you have, oh, well, we got a foothold,
but now they have all these really strong local firewalls,
so we can't move laterally as easily because everything's blocked
to everything else, right?
That's an example of defense in depth.
That's not protecting you from spear phishing,
but that is helping if you do get to that breach status.
It's going to be restricted in the scope of it.
And then Matt has some final conclusions on tools or defensive controls.
Yes, defensive controls.
We kind of talked a lot about this.
We kind of at some point hit small, you know, an inch into this type of topic.
You know, tools are great, you know, as we kind of described before.
We highly recommend, you know, modern tools, proper configurations,
but they're kind of useless if you just buy them in an audit mode.
And that's what we kind of see a lot is, is the deployment that they're not,
you know, you might have the greatest security stack of 20 different products.
You might have 14 different ADR agents on there,
but if they're not properly tuned or configured, there's tons of gaps.
And that's where hackers and attackers love to live is just in those gaps.
It's pretty much where it is.
Hey, look, there's a gap or a blind spot in our, in this client's network.
That's where we are going to start.
We're going to live in this gap and we're going to try to move as much as we can in there
because you guys don't have any visibility. We know that.
So if we know that, you know, hey, you guys are monitoring PowerShell,
but you know, we can use C sharp or hey, we can, you know,
you guys have great lockdown for a lot of stuff, but macros are really easy.
We could use macros. We can use water hole attacks, you know, set up.
In fact, hey guys, you know, your ADR is only set up to detect, you know,
process injections or something like that, anything like that.
There's tons of little things like that.
And that's where really tuning and tightening up can really make a huge difference
in the success of your defensive controls.
Also that kind of comment I made before about audit.
We often see the latest and greatest, you know,
oh, this is going to stop every, you know, threat, cyber threat known to mankind.
We detect, oh, days before they even thought of tools, but you ran in an audit mode.
So someone's not looking at the dashboard. You don't see a blinking light appear.
And so we continue on our way through the environment.
It's really, it's really hard to do a lot of that stuff.
And that's where like hiring, you know, red team sims
or doing those types of engagements.
So that way you can see what's out there, understand what, you know,
people are doing and seeing where those gaps are in your product.
That's highly valuable than just, hey, I'm going to buy a product
and just, you know, plug a few buttons on it
and hope that I got everything right.
Really having it go through those trials and stuff
in a live fire engagement is going to help you guys more than anything.
Also, we know this, and this is probably going to be
one of the most frequent questions asked.
You know, well, if we do all this stuff, then, you know,
it's not usable for my environment.
You know, users can't log in as easy or they can't do things
that they used to do as quickly and stuff.
And now they're going to complain that they're affecting
or affecting their ability to do their job.
And, you know, it's going to hurt the company's bottom line.
But, you know, it's that type, it's a hard conversation
you have to have with the business about, you know,
you have to change the way you guys have been using stuff
to make it more secure.
It's very hard.
I mean, I don't envy anyone who has to deal with those conversations
on a daily basis, but it's necessary to have.
And I think if you approach it properly,
and with a lot of, you know, information and guidance
and recommendations, even from third parties,
you can definitely get a lot of value out of that.
And the last thing, of course, we've mentioned
throughout this whole thing is baselining.
Baselining, baselining.
Know your environment inside and out.
If you do, that's the biggest thing from our red teaming experience
that has killed us or stopped us dead in the water
is if you can baseline and discern us from the rest
of your normal traffic, even if we're logging in through RDP
and we're using all the same stuff you're normally using,
if you can find out that we're not who we're pretending to be,
you're going to have a lot better success right then
if you do anything that I just described.
Baselining is probably the biggest key,
and that's why we left it as the largest bullet point.
Really, just least frequency.
Get in tune with your environment.
Get really in tune. Get very close to it.
Get unnecessarily close to it.
And with that knowledge, you'll definitely be able
to spot the anomalous behavior.
All right, so we have a few minutes left.
If you guys have questions, put them in the Discord channel.
If you guys are in Discord, it's the Briefings Main Talks channel.
We're both in there, and we can try to answer some questions
in real time before we wrap up.
You can hit us up on Keybase or Twitter if you have any questions
or just want to chat. We're always available.
We love picking other teams or other people's brains
in the industry, so definitely hit us up if you ever have a question.
Other than that, I just want to say thank you
to the Red Team Village for letting us speak today,
and thank you guys for showing up for our talk.