Subscribe
Share
Share
Embed
John Strand // John is starting a new series of webcasts called Attack Tactics. This first part is a step-by-step walk-through of an attack BHIS launched against a customer, with just a few obfuscating tweaks. He covers the tools,
A weekly Podcast with BHIS and Friends. We discuss notable Infosec, and infosec-adjacent news stories gathered by our community news team.
Join us live on YouTube, Monday's at 4:30PM ET
Oh.
Hello from Spearfish, South Dakota.
It's the Black Hills Information Security Podcast.
This is the podcast version of our webcast.
So slides that we reference may be missing, but you
can find the whole episode on our YouTube channel.
This is Attack
Tactics part one with John Strand and special guest, Derek Banks, and me, Sierra.
So this webcast is the beginning of
a series I thought would be a lot of fun.
Attack tactics.
So the 1st one will be offensive.
That's where we're going to talk about a component of a red team or a web application assessment.
And then the 2nd one, which is purely offensive.
We're going to go through the entire attack methodology.
And we discussed in the previous session, and we're
going to discuss the step-by-step defenses that your organization
could have in place to stop each one of those.
As much as I hate saying this, it's kind of like a cyber
kill chain for each one of our webcasts, God help me.
I know that every time I say that, Lockheed Martin gets a nickel.
So we're going to be talking about the attacks and we're going to be talking about the defenses.
Now, as much as possible, I try to pull these different uh,
red teams, web application assessments and the different attacks that we do
from actual penetration tests that BHIS does.
And whenever possible, I try to have the actual tester or
one of the testers that were on that engagement on the call and the webcast with us.
And in this webcast, we're going through an assessment that Derek did.
And I've also changed some things from parts of this parts of the red team.
So it doesn't exactly map off perfectly off of one of our reports and one of our customers that we did.
By the way, the slides will be available, but we'll release
the slides after the 2nd webcast where I fill in all the defenses for each one of the components.
So the overview, Derek, do you want to talk a
little bit about this test from an external perspective?
I didn't change much on this slide.
They had their standard setup on the DMZ, some VPNs,
some SharePoint servers, Office 365.
Anything else from an overview perspective that you think was important?
Uh, no, I think that about covers it.
They had moved their email into the cloud,
um, as well as the SharePoint install they had was also in the cloud.
Um, have to pause before you say that.
And I think, you know, the key thing that
we'll see here, as we walk through it is the single
factor was the biggest issue they had, single packer authentication.
And it's quickly getting to the point for a lot of our assessments,
if we're ever doing an assessment for an organization and they do not have 2 factor enabled.
It's pretty much a bad sign for them.
Would you say it's almost, I don't want to say a guarantee, but a very high
likelihood that we're going to be able to get into an organization if they just have single factor authentication.
Um, to some degree, yes, I think pretty
much if there is anything that's single factored.
And then also if it's tied internally to aid
to active directory, um, that typically, there'll be something there.
Yeah.
And both of those things are in play in this assessment.
But like every single good red team or penetration test
that's being done, you're always going to start with recon and G.
Now, what recon NG does for those of you that are relatively new, you can look at it up.
Just Google recon dash NG, and I'll take you to a repository that is currently
maintained by Tim Tombs.
Tim Tombs is a former employee of Black Hills Information Security.
And currently, he does a lot of subcontracting.
He still does work with us quite regularly, and we're still
maintainers, or we're supporters of recon engine and supporting code and also financially
supporting the open source project as well.
And recon NG is designed to tie together
all of the different components of open source recon that you
can pull without actually touching the organization.
Now, there are some modules that do touch the target organization,
but the vast majority of them are pulling from third-party resources.
Like you would poll information from have I've imponed about
possibly compromised email accounts and password hashes.
You could use things like punk spider, which has been released and updated,
to possibly identify services, ports, or vulnerabilities
for different web services, showdown to identify services that are exposed as well.
The idea is to find out as much as you can about
a target organization without touching it.
And the more you learn about an organization, generally, the
better the actual assessment, pen test, red team goes, because
you're not going to be stumbling into things quite so blindly whenever you do your assessment.
We're going to be looking for users, services, net blocks, vulnerabilities,
possibly even identifying various passwords and
credentials that are exposed on 3rd party sites.
In fact, Derek, have you talked with Mike Felch this morning yet at all?
Uh, not directly, but I didn't
hear from this morning's pod meeting about the cool thing he was doing.
Yeah, he's working on a new API for pulling down.
I think it was one.
7000000000 passwords that were exposed
online and then the ability to search that stuff.
That's what he did this weekend.
This weekend, I cleaned my house, and
Mike, instead, did something awesome that he wrote it.
So hopefully we'll have some blog posts coming out.
Cleaning house is awesome.
No, it's not.
really, really was not awesome at all.
So one of the things that was discovered was an
Office 365 redirect, and I used my own Office 365 account here.
Now, Derek, can you talk a little bit about what we mean by
a redirect whenever we go to a mail server and it shoots us over to an office 365 account?
Uh, yeah, so, uh, basically,
depending on what the MX record is, it'll redirect to the,
you know, from what your organization's email, uh,
you know, domain is to Office 365.
I think technically in this case, they might have been federated, but it doesn't really matter.
So essentially, you're checking mail out in the cloud.
You know, and we see the same thing not
just with Office 365, but also whenever we're attacking
organizations that use Google Apps domain as well.
And this is becoming, I don't know.
I want to get your take on this, but I think that this is becoming a bigger
and bigger problem in the security testing community.
Because by and large, these cloud providers for email,
they generally don't like you doing pen testing against Office 365
or doing pen testing against Google apps, and they frown upon that activity.
Yeah, they do.
Um, so when
we're talking about detection and some of the attacks that we
did against this organization, kind of setting it up for what's coming, did
Microsoft actually detect any of the attacks that we did against this customer or was it relatively under the wire?
Yeah, for this particular customer, no.
However, early on, and we
had a customer, when I say early on, I mean, when we started running into
customers that were using Office 365 email, there was some level of detection.
I don't know enough about the backend to know if that customer
had purchased something different or had something different setup.
I think for this particular customer.
We ended up actually performing password
spring against their on premise ADFS server.
So I don't think it was that, like, we were actually going
after something that was in, in their, uh, their asset.
And that kind of shows a little bit how if you have a service that's
exposed, like a SharePoint service or ADFS or something and it ties
directly into active directory, and you find user IDs and passwords,
we can then reuse those accounts in cloud services that
may be tied with the authentication back into the same active directory back end.
And it basically shows you shouldn't have anything that's doing direct
authentication back to active directory, exposed directly without it being behind some type of protection.
Like, I would say 2 factor.
I'll come back to that, but really behind a VPN.
Now, with 2 factor, what are some of the techniques?
I know we aren't talking about in this particular assessment.
What are some of the techniques that you've been using lately?
We've been using lately to kind of get around to factor authentication.
Oh, you mentioned Mike Felch a minute ago.
He wrote Cred Sniper, which I think is a
really interesting tool that does exactly that.
Um, you know, when you fish somebody for, what, you fish someone.
They click on the link, they get to a page that looks like their email,
and then they put their credentials in on the back end.
auto authenticates you.
Um, I think that's a project that I haven't
heard a lot of people talking about that will probably be sort
of like male sniper was when it was released that,
hey, look at this nifty thing that it does.
Oh okay, that's great.
Microsoft says that's not really a problem.
And the next thing, you know, we're getting phone calls from government organizations going, what the hell?
Yeah, like the FBI was probably my favorite phone call.
Um, and the final thing about this.
Uh, some of the other assessments that we've been doing lately, uh,
for doing password spraying directly against uh, like Office 365 and Google.
We've, look, the providers do not like
pen testers doing password spraying against their services.
And it gets into this really weird, murky gray area as
to whether or not it's legal that the customer allows you to attack their specific domain.
Does Microsoft allow you to do that.
And those are interesting conversations that we need to have.
However, for a number of these scenarios.
We have discovered that if we do password spring against something like Office
365 in particular Office 365, actually.
Microsoft does actually notify some of
our customers that a password spray or an attack was attempted.
But by and large, I think almost every single one of them, it was 2 weeks after the attack.
So it's not really good up to date telemetry on the attacks they're coming through.
So this becomes more and more of a problem that we as a testing
community and organizations are going to have to deal with to be ready for testing these various cloud services.
And you'll see why here in just a little bit.
Next one, creds.
Uh, it's, it's ridiculous to me how effective
it still is for us to find credentials associated with
a target organization online.
Now, for those of you that are relatively new.
to these webcasts.
What we mean by creds online is if your organization,
um, users, they, let's say at hackedcompany.com, on
at hackedcompany.com, goes to a 3rd party website, like Adobe
or LinkedIn or some other website, and that website is compromised
in a public way, where the attacker takes the credentials
from that public compromise, and then they post them out someplace like PaceBin.
They'll a lot of times post the email addresses and
the user accounts and the password hashes on these 3rd
party sites, and then you can pull those credentials down.
That's why stuff like Troy Hunt's have ibuponed has
been so important, is it's showing people just how often credentials
are, in fact, compromised, but with a little bit of digging,
very easy to go back to the root of where
that compromise was posted online and actually polo's hashes and then even crack some of them.
as well.
We talked a lot about Mike.
I was talking about them this morning.
I said, I think, not I said, he said this morning, I, last
week, I think that they were on a red team and he found 3 credentials that were compromised
in 3rd party breaches, and they worked for an engagement that he was working on.
So that happens.
So we have any questions so far?
Um, Brian asked, does,
does Microsoft, is they, are they able to tell when they've
been breached using, um, burp suite and power?
So that's exactly the technique that we do use whenever we're doing password spraying attacks.
And correct me, if I'm wrong, Derek, we generally use burp instead
of tools like Hydra, because Hydra doesn't follow redirects very well.
Whereas if you're doing a password spray with burp, you can enable
burp to follow the redirect, actually get to the size of the destination
page, and it tends to work better for password spraying.
Is that a correct assessment, Derek, in your opinion?
Yes, uh, if if I can't get the easy route
and male sniper doesn't work, I'll move Burke Suite.
Or if it's something that's not supported in male sniper at the moment.
Like, say it was a VPN page or something like that.
Um, yeah, it's my 2 choice.
Now, the reasoning behind, from what I've heard, this has not been confirmed.
But from what I've heard, especially with Microsoft, whenever you're
doing password spraying attacks against 365, they
have a proxy in the front of their server, which is a good thing they should be using application level proxies.
But the way the logging works, you have logging in 2 separate locations
on the proxy server and on the office 365 servers and
correlating those logs together and actually identifying a tax is kind of what the problem that Microsoft has had.
traditionally detecting these tax more or less in real time.
Now, there are Casby's.
You can actually get a cloud access security broker that
you can put on top of your cloud infrastructure that'll help detect some of these attacks and mitigate these attacks.
We'll talk more about that against the webcast next week.
We'll discuss that in more detail.
Yes.
Gordon had a question.
Do you guys find that password hashes are often crackable.
You figure with good password policies that even if you had the hatches,
you wouldn't be able to crack them effectively or efficiently.
That's a great point.
Derek, I'll throw that over to you just to recap it.
He asked if an organization has strong password
policies, doesn't mitigate the likelihood of
us cracking passwords on the edge of a net, or not on the edge of a net, or from 3rd party breaches.
And I think that there's a lot to that.
We have how the password's actually stored or this.
Is it MD5 or is it B Crypt?
How are they actually stored?
But then the complexity does actually factor.
So what are your thoughts, Darren?
Um, yeah, I think that by and large that, you
know, if you have a policy that said, uh, like
as 15 is what we currently recommend, it does make cracking,
uh, an NTLM hash, certainly more difficult,
but, um, I think, you know, the longer the password, the better.
But still to this day, and the majority of our customers.
I mean, we've had repeat customers come back and still have an
a character password policy because they just, they couldn't win the fight.
Security did not win play against operations.
And so, yeah,
it's just we don't see a lot of places still having long password policies.
We do have a couple of customers that do,
and it does actually make it a lot more difficult.
However, here's where this gets interesting.
Um, and we really should have, uh, we really should have Kent,
Jordan and Derek on to talk about password, uh, cracking.
Whenever you're cracking passwords or something like hash cat.
Let's say an organization has implemented a 15 character password policy.
Um, whenever you're running with Hash Cat, you can actually run it
with a rule set that does combinations of the password.
So if you have a password list, let's say that's Apple, dog, and cat,
it'll try Apple, dog, and cat, but then it'll do Apple,
dog, Apple, cat, dog, cat, Apple.
It'll concatenate those different words together.
And what you come up with is somebody could have a password of
company name, password one, two, three, four.
And if you have those 2 separate passwords in the password dictionary,
It'll take them and put them together.
So yes, longer passwords do make a difference,
but we still come up with ways to actually crack those passwords.
Using various dictionary shenanigans style
attacks, using tools like HashCat.
So it reduces the amount of passwords that are correct, but it doesn't completely mitigate them.
But as Derek said, the vast majority of organizations today still
run 8 character passwords, and I'll talk more about that a little bit later.
So some additional recon findings.
Credentials, office 365, support portals, proxy, citric servers.
Database servers exposed directly to the internet.
They had multiple VPNs.
This is something that I've seen in a number of organizations, and I added it into
this 1st example, where an organization will have like a Cisco
VPN, a juniper VPN, and then some other SSL software, VPN.
And I, uh, you know, so I have all the
testers send me the reports and I try to find some trends.
And one of the trends that I do see is multiple different types of technologies of play.
Database server should never be exposed.
Open internet, but we do see it.
And when we do see it, a lot of times we'll see organizations that are running a
Microsoft sequel, my sequel, and like Oracle databases, and they're running multiple different technology stacks.
With VPNs.
I asked some of the former customers why they were running
some of these, um, like multiple VPN providers, and almost consistently.
The reasoning came back that they
do that because they started with VPN X, and then they implemented a new provider, let's say, like Cisco.
And Cisco had its own VPN capabilities.
So they enabled those VPN capabilities.
But whenever they tried to remove the legacy VPN technology.
There was always an executive or an application or an API
or some customer or a service provider that
needed to access through the legacy VPN.
So they end up managing 2 separate technology stacks.
this is a consistent theme that I'm noticing.
With many organizations that have a very poor security posture,
is they have a diverse technology portfolio.
That means they're running like Apache.
That means they're running windows.
That means they're running BSD.
They're not consistently locking down on one specific technology stock.
And they have multiple different technologies doing the exact same thing.
So that's a consistent problem that we see.
Service desk, SharePoint, you mentioned as well.
Also a J-Boss server, that was exposed, and that gives
us management to J-Boss, so we can actually go through and talk to it directly.
So immediately these particular attacks attackers,
they tried to attack the J-Boss server using metasploit module.
So they tried using J-Boss phone scan.
And they were ultimately denied.
And, uh, the thing I'd like to ask about this,
Derek, whenever we do these types of assessments is kind of, at this point, a
little bit of due diligence to try these various exploits against
these services to see if there is an exploitable surface.
And that really kind of gets into a weird place between a vulnerability assessment and a red team and a black team.
But it is common for us to try to use these types of exploits
against the services and also get denied with remote exploits.
How often do you actually still see remote exploits successful in most organizations today?
Oh, from an external standpoint.
It's not very often at all.
Um, I think actually my entire time at Black Hills.
The times that I've actually used
a legitimate exploit.
Uh, internal or external is less than 10 and I've been here almost 4 years now.
And it's, you know, it happens, but externally, it's very rare.
You know.
So the next attack, default credentials.
This is something that we do all the time.
So for this one, I think that this particular
customer had like an expense reimbursement server, and it was exposed directly to the internet.
And you could actually access the management interfaces for that expense reimbursement server.
And it's very common for us to find services, be it J.
Bosby, an expense reimbursement server, be it a giro server, whatever.
We try a variety of different default creds.
And just, you know, out of curiosity.
I have seen in the reports that are reviewed, we have
better success with default creds than actual remote exploits gaining access to systems.
Your thoughts?
Oh yeah, especially when a
3rd party implements something, you know, like, um, you know,
a voiceover IP solution or something along that lines and there's an external component to it.
And you know, 3rd party stuff, it seems like I've seen a few of those.
Yep.
So yes, default creds definitely go after those.
And I think this is one of those areas that a lot of pen testing, red teaming,
black teaming, security assessment teams ignore.
And there's a number of reasons for that.
One, vulnerability assessment scanners by and large.
If you enable them to do password attacks against these services that are exposed.
It's very, very, very common for that to lead to a lockout scenario.
We actively start locking out domain accounts, especially if these services
are exposed directly to the inside of the network to active directory.
The other reason why they tend to be ignored
because those plug-ins are usually disabled, they're not actively scant for, so people tend to ignore them.
So we see these default creds for many services that haven't been
updated in years, and they're still there, and that's generally because
a lot of testers just don't even bother to test for them at all.
Um, you referenced black team and some people are asking what black team is.
They're saying is John overloading definitions?
I am overloading definitions.
Of course.
So let's go through the different teamings that we have.
And it's funny because I have a slide at the end of this that I talk about all the different teams, but let's talk about it now.
So a red team is where you're doing adversary simulation.
And if we're going down the full technical definition of what a red team is,
a red team will be technical, like external, trying to do attacks,
like we're talking about in this webcast, but it may also include physical penetration
testing, electronic trying to attack Zigby, uh, Bluetooth wireless protocols as well.
It may have a physical component and possibly social engineering.
Basically any means possible.
Try to get in.
One of the issues with a red team, though, is it's very much bound with a specific time frame.
So a red team will happen within a 2 week period or a month period.
And it's difficult with many customers because
it's hard for a human being to know something like a red team is coming
down the pipe on this specific date and time frame and
continue your security posture as business as usual.
Now some customers do that.
Like the CIO will hire us to do a red team and they won't tell anybody else.
However, it's also very common for CIO,
CTOs, managers, when they know that it's happening, to basically get all of their
security team and their network operations center together and say,
all right, everybody, we got Black Hills information security coming in, and
we know that they're coming in these weeks, we need everyone to be ready.
We absolutely, positively need to be set up and no vacation.
We got double ships.
And that's kind of harsh because it doesn't adequately represent
the security posture for the organization at all.
So a black team takes care of that.
What a black team does, it says within the next 6 months, we're going to attack your organization.
However, we're not going to notify you.
You're not going to know when we're going to come.
And you may not even know where we're actually coming from.
So it changes that entire methodology.
So it's no longer trying to work everything in in a 2 week period.
It's now spread out.
And to be honest, black teaming tends to incorporate a lot more
failure, a lot more low and slow kind of password attempts.
Spearfishing attempts where you maybe try to attack
10 or 15 users and then wait a few weeks and then try 10 or 15 more users a little bit later.
So it's basically a difference in time scale.
In a purple team, once again, having way too many terms,
is a collaborative penetration test, where the blue
team, the defenders, are seeing exactly what's being done, and then working
collaboratively with the red team, to develop better detects, to identify
the attacks that are happening more collaboratively.
So does that answer the question?
Right.
They didn't reply, but yes, they did.
Next attempt, password spray.
And this is ridiculous.
This is something that password
spraying gets us into more organizations than just about anything.
In particular, season and year.
If you look at BHIS shirts,
I'm not wearing I'm wearing a competitors.
I'm wearing a competitor shirt today that I got from a booth.
But it's very, very common for us.
Yeah, we support all of our brothers and sisters in the pen testing community.
It's very, very consistent that we have a password.
Like right now, it'd be spring 2018.
Um, that would be a password that would be used.
Now, some people may have password complexity in play where
they will not allow dictionary words, but they'll just simply change out like the
winter, the eye, and they'll change it to a one or something like that.
And in this particular example, gained access to a Mr. Smith account.
I actually think that was the account, Derek, I think it was literally a Smith account.
And, uh, gained access to finding
that with a SharePoint server in the situation that had authentication
tied directly into the domain controller where they could find that single password with that account.
And the tool used in this situation was burp, and then, of course, the season and year.
So Derek, anything else to add on this one?
I might have something.
Oh, we got some questions.
Frank says it should be yes.
Yes.
Okay.
We do have some questions if you want to take a breath of air.
Go ahead.
Oh, see, he's gonna change it, Rick.
Okay.
Um, can we can we go back to some of the other questions or Sure, let's go through some questions.
Okay.
When you attack, when you
attack, are you coming from one IP, would it be easy to block that IP that is spraying for passwords?
Yes, Bars?
Yes, and no.
Yes, it would be.
Um, it would be easy to just block that single IPO dress.
If that's what we actually do.
What we're doing now is we're actually working, once
again, you stay ready, or Mike has released a tool that allows
us to do password spurring via Amazon Lambda.
So basically it's not just coming from our IP address, but it's literally coming from Amazon.
We've had additional tools that we've used in the past.
Remember, Remux was one tool, a reverse multiplexing tool that we used a long time ago.
Or you could also use, they completely lost it.
What was the, what's the tool that spans up Amazon EC2 instances?
And then once they get blocked, it switch puts up another one, proxy cannon, that's it.
Proxy Cannon.
Um, thank you.
He almost got it right there.
So there's a number of different ways as an adversary
or a pentester that's doing adversary simulation that you
can actually federate your password attacks from multiple different IP addresses.
So, Derek, you want to add anything to that that I may have missed?
No.
He's on mute.
Yeah.
Sorry, there was a lot of background noise, Derek.
You're unmuteed now.
Oh, there we go.
Yeah, so I guess that I have
actually been in battles with the blue
team on a red team where they were blocking IPs
and, you know, it's just too easy to go through various means and get other IP addresses.
They'll throw away.
through VPN services or something like ProxyCanon.
So and then if we see that we're getting into that kind of battle, we'll just throttle it back.
I mean, are you going to detect, um, you know,
attempts where the password spray is coming in every like three, 4 minutes or at some random time.
So.
And that's just that kind of gets back to the red team versus black team.
What are the time scales that you're going to be dealing with as well?
Um, wires is asking, um, he
says he sees a text from Amazon all the time, how do you defend those?
Oh, looks like you'll have to come to part two.
Yes, you're going to have to come to part two.
Part two, we're going to be talking about defenses.
So we're going to go through this exact webcast.
I know that that always seems like a cop-out.
Well, if you want to answer that question, you're going to have to come to our next webcast.
We'll see you then.
It's going to be fine.
Then buy my book.
No.
But no, we didn't have enough to actually put in the defenses in addition to the offensive components.
So we're literally going to go through each one of these slides and we're going to talk
about the defensive capabilities, the event logs that should be triggered, different, like I talked about Casby.
We'll talk about that and the ability to detect attacks against cloud services.
So yes, that is all coming.
Any other questions?
Oh, there are, yes.
There are so many.
So we're going to get bringing a swap, but keep going because it's already 28.
All right, so the next one.
We go.
There we go.
Got Outlook Web access with Mr. Smith.
Now, what's interesting about this is look at that jump.
We may have grabbed the password from one service,
like SharePoint, but then we reused that same password in Office 365.
Having that separation, I think really helps for a couple of different things.
One, it becomes really important whenever we start talking about two-factor authentication bypass.
You may have one particular service where you can enumerate
user IDs and passwords, but you may not be able to use them on that service because of 2 factor.
You would have to back up, find another service, like outlook,
or exchange web services, or Office 365,
where that is not enabled, the 2 factor authentication is not
enabled, where you harvest the credential someplace, and then use them someplace else.
I mean, this is very, very, very consistent with
a number of the different attacks and the reports that I'm reading and what we're doing on
a regular basis is credential harvesting here.
Using those credentials someplace else.
And this is pretty easy.
I love this because whenever I was going through the report, Derek, it was basically the tool used.
Yeah, I just used a browser.
Just log in.
Dont try to get crafty.
Don't try to get tricky.
Just log in.
Uh, to this to this person's cloud-based email
and you now have access to their email.
So anything to add, Derek.
Uh, no, other than, um, you know, once we
get access to those other services specifically email, um, well, then we're going reading, right?
That's the next step.
There you go.
Let's setting it up for you.
One of the things that we love is pulling down global address lists.
Uh, and I found this really nice, um, I
found this really, really nice, like, Elvis Presley address book.
I thought I thought that was I thought that was nice.
We pulled down the address book.
Um, the global address list, and we're constantly trying to expand that attackable surface.
We may have access to one account.
But you use that one account.
You download the global address list.
You now have 100s, if not 1000s of additional accounts,
that you can go back and you can do that password spray against all of those accounts.
And that leads me to this.
Um, there were 5 more people in this organization
that were using the exact same password.
In this attack, once you guys got access to the initial service,
you went back, you redid the password spray, and you
got access to a whole bunch more accounts, and I'm going to fix this slide real quick.
Yeah, I think all said and done.
Um, yeah, it was a large organization.
I think we ended up having through various different passwords that were all really crappy passwords.
Um, some 200 and some odd accounts, which is a lot of reading email.
Yeah, that's a ton of reading of emails.
It's really weird.
You feel kind of snoopy.
Like you're stalking someone?
Because like whenever you're pen testing, you gain access.
It's just a shell.
Whenever you're reading someone's emails.
I don't know if it was you, but there was an assessment.
I think it was one David was on, where he shot
me some screenshots, and some of the screenshots were talking about wire
transfers, because that's what the customer wanted us to look into as wire transfers,
and a whole bunch of the wire transfers were actually wire transfers from
this guy's personal account to buy a house.
And you're just like, oh, that is so, why are you doing that on your work computer?
I did get somebody's email on my phone once.
That felt real dirty, real dirty.
Just, oh, how?
We had to call the help desk and like...
Not the BHIS helpdesk.
Just making that clear.
The clients helped us.
trick them into like having me, who
was not me, downloaded onto their iPhone, and we didn't have the right information, and I totally did.
It was so dirty.
Oh, that was social engineering.
I get it.
Yeah.
Yeah, you always feel the kind of dirty.
But reading other people's...
Yeah, you read through other people's emails.
You find out who they hate.
If this actually was, they didn't they didn't have that many things.
Um, Uriah had a question.
Um, going back to what this passwords rang thing.
Okay.
Do you find yourself making recommendations for stricter passwords for
privileged accounts when you can't win the overall policy?
Would that help?
Oh man, Derek, what are your thoughts on that?
Does it actually make things better if you're like, oh, we're only going to use long and strong
passwords for administrators and everyone else can use crappy 8 character passwords?
No.
Well, that was fast.
So, uh, there, uh, so it seems like a good idea.
The problem is, is if you have, you know, let's
say, you know, a 10th of your organization is IT and they're all using great passwords,
but then you're in a situation where these non-IT
folks, for some reason or another, we're an administrator on different machines.
Um, then I can, if I'm,
I can still gain some level of administrative access.
And if you haven't moved to Windows 10, I can then dump out that long complex
password, where an administrator is logged in, and it doesn't really make that big of a difference.
And I think that that kind of gets back to kind of a key theme.
If you know, like, the entirety of
your environment, you're like, oh, these are the only accounts we need to be worried about, then it would make sense.
But the fact is that these organizations are so incredibly complicated.
It's almost impossible to identify all the different paths to demand administrator.
And further, I think you were on a test last,
no, 2 weeks ago, maybe it was longer ago, where you didn't get domain administrator.
Uh, but you were still able to find highly sensitive documentation
from the accounts that you actually gained access to.
And I think that that goes to show, it's not an issue of always trying to get to main admin.
It's many times an issue of what are the sensitive data, what
kind of some, what kind of sensitive things can you do to that organization as well?
Yeah, we were just on a, a
couple weeks ago, I had a client where we didn't get domain admin
and they thought it was great, but we had 2 accounts, one that was an
administrator across all workstations and another was an administrator across all servers.
So what did it matter?
I could still go pretty much be admin anywhere besides the domain controllers.
Yeah, and that was a weird edge case.
I think you had to explain it to me with crayons, how it wasn't
that we were giving command administrator, but it was a weird, weird edge case.
All right, so let's move on.
Looking for VPN instructions.
This is something that I thought was great.
And this one's polled right out of that report.
With tools like Mill Sniper, just simply SharePoint
Access or going through emails and trying to identify how do normal users access the environment.
And I loved how there was like literally a part where you were
searching for how to gain access to the VPN, and it's like, literally, here's
a document, step-by-step instructions, download this executable.
By the way, here's the search for accessing the VPN.
It was basically like it was completely laid out for you.
Yep, it
sounded easy, but it took like 2 days to get to that point.
It read really easy.
But that is that is something, I don't know.
It's easy to find user IDs and passwords, but I think that
getting those certs, that is a lot more difficult to actually get those certificates.
And whenever we're like running things like male
sniper, it seems like, once again, male sniper is so useful for this, to
be able to search for things like creds, to be able to search for things like password to
be able to search, like, for things like, uh, uh, VPN search.
Yeah, I don't know.
My battery was full.
See if there's a battery charger on the floor for this.
It's got a yellow tip right there.
There it is, right there.
There we go.
Yes, the tip is yellow.
All right.
Oh, let's see if that makes my computer happy.
Yes, whoa.
I got bright, really, really fast.
All right.
So, um, so it's not just an issue of just trying to once
again gain access to a system, but it's how can you actually gain access to
that organization and use the built-in different protocols and services that are available?
So far, I'd like to point out at this point, no malware has been implanted on the organization.
And that's going to be a theme that'll start talking about from here on out.
It's not always about exploit spearfish gain access,
drop mower on the system, get C2, and then pillage.
Um, if you can do that, great, that's awesome.
But if you can get access to the environment through the VPN,
if you can get access to the environment using RDP or remote desktop
protocol or Citrix or any of those other services, that's even better.
Because the amount of detects that the organization's going
to have, are you coming into that organization are going to be a lot lower?
Um, I just basically pulled down male sniper.
One of the things I didn't do.
Um, and I'm trying not to do in any of these presentations is
trying not to use any screenshots from the actual reports.
So I'll go and pull down screenshots from our blog and put those in.
And this is an example of, uh, Male sniper, you can see where it's invoked here.
We import the module, male sniper.
And then you can basically do a search, invoke self-search,
mailbox, and we got Vladi on nanobotninjas.com.
And you're doing a search for specific terms, password creds,
credentials, and you could add in more terms, right?
Like you could do a search for VPN.
You could do a search for certificates.
You could do those types of searches and it'll pull back all of the
emails that have those specific phrases or words in them.
And then that allows you to kind of reduce or boil the ocean down,
to specifically the emails that are interesting to you as the
tester or an attacker can use, to basically further leverage their access deeper into the organization.
So, Derek, anything to add here?
No, I was reading the audience questions.
Oh, that'll suck your life.
Yeah.
That'll suck your life away.
It's hard it's hard to pay attention to all the things because they are crazy.
So hard to keep up.
No, that's why I'm here.
All right.
I can't keep up either.
So VPN access, now you just basically log directly into the VPN server.
Make sure that you get an IP address on the internal network with the credentials that have been invited to you and now you're on the network.
Now, post VPN access.
You've got to start doing some recon to try to identify where you're going to go next.
And for this, you can use built-in command line utilities.
You can use net user space forward slash domain.
You can use NetView, you can use PowerView to poll additional information.
We should tweet out, if someone can get us the link, um, Harmjoy
has amazing cheat sheets out on GitHub, uh, Harmjoy from Spectra Ops.
has some amazing cheat sheets for using tools like PowerView.
So if you just do a search on Power Review, cheat, cheat, harm joy, I'm sure someone will post that.
There we go.
There's there's like 5 or 6 cheat sheets that they have on their get repository.
You should make sure that that's the right one.
That's the, that's uh, that's not the actual cheat cheats, but that's okay.
I got to get, we got to get a little bit worried whenever people start sending us links like here, use this tiny.
I know, got it.
I just send it to you guys.
I just send it out.
So it's awesome because there's a lot that
you can enumerate, like domain administrators, you can enumerate additional
workstations, you can enumerate password policies.
It is amazing, what you can pull down.
And this is where this starts to get a little bit hazy when we're talking about detection.
Most organizations are trying to use just straight
power shell logging and logging anytime someone's using power shell.
That's going to be difficult in some organizations, especially if you don't do proper filtering on what's being done with systems administrators.
But we'll talk more about this detection a little bit later, but suffice to
say, there's amazing utilities and tools to actually find additional access.
Uh, one that I didn't talk about much here because I want to have a
total webcast dedicated to it, would be Bloodhound.
And also Death Star for enumerating the path to the main administrator.
Now, curb roasting, uh, this is by a very, very good friend
of Black Hills information security, Tim Medine, uh, from Red Sige Security.
They do a lot of consulting and subcontracting with us.
We absolutely love them.
Now, Derek, with curb roasting.
Let me get this straight.
You can actually pull down uh, password hashes
with curb roasting without having privileged accounts, correct?
Correct.
All you need is valid domain credentials.
And you don't even necessarily have to be on a machine that's
joined to the domain, use tools like impack it, um, and
proxy your traffic through, or if you're on the VPN, just not, you're already there.
Um, and yeah, just need valid credentials.
Yep, and you talked about unpack it specifically,
unpack it's a collection of a variety of different tools.
And the specific tool that you're talking about in in packet is
get user SPNs.PY, correct?
Yes, that's correct.
So now with that, this was weird.
This organization had, I think, 800 different
service accounts, how does that happen?
How does an organization end up with 100s and 100s of different service accounts?
Oh, wait, if you want me to answer that?
I was hoping you could, because I honestly couldn't figure out a good reason.
I've got an idea.
Brian says hard work.
Hard work.
So not good internal policies
in terms of how teams work together, how applications are integrated into the environment.
Um, you know, I guess you could take an approach to one
service account if it got popped, then, okay, now you have,
you know, you know, less chance of administrators
on different servers, but it turns out when you have 800.
Some of these definitely going to have a crappy password.
Um, not with curber roasting in particular.
I've been, I've gotten donated administrator out of the gate just from cracking one of the tickets.
And also, one of the reasons why,
once again, looking at reports over the past few years, one of the reasons why
I think you see organizations with these 100s of accounts is just it's an old organization.
Um, you have a domain that basically goes all the way
back to Windows 2000 active directory and then you upgrade
it to 2003 and you keep migrating um, to newer versions
and people don't ever really seem to clean up after themselves.
So you see these accounts, these service accounts, and not all of these are service accounts are used.
Many of them are still active.
They just set it up so it never expires ever.
And they still have the privileges that they had within the domain,
but people just don't seem to clean up service accounts.
They don't seem to clean up applications at all.
So this becomes a great technique to try to gain access to the environment.
Now, the next one, I was really, really
like shocked when I saw this on a report that we put out recently.
Group policy preferences and the passwords.
And for this, you use the PowerShell script, uh, get GPP password.
PS1.
And, you know, I
think if we were like 4 or 5 years ago, group policy preference files, we would expect to see that.
So let me explain what that is.
And then I'll have Derek talk about why we continue to see it even today.
Um, so whenever you automatically build workstations,
you can use group policy or group, um, group policy preferences.
So it'll push down a policy 2 systems, and it'll
automatically configure that system to be in compliance with the all the other systems in the domain work.
And as part of that you can push down a local administrator password to that system.
Now, to be fair, the GPP file is
actually, it actually has the password encrypted, which is fine,
except for Microsoft actually released the key to decrypt it publicly.
I think it was in a technet article.
So you could basically gain access to any of these GPP files.
And then you could quickly reverse that password.
Now, Microsoft patch this.
I think it was, was it 2013 or 2015, Derek, that Microsoft patched this issue.
I'm pretty sure it was 2013.
It wasn't that, it was, it wasn't like, last week.
But if they patched this, Derek,
how come organizations still have these GPP passwords in use?
Because the patch didn't go pull out all the passwords
from the XML files, um, that they left that up
to the reader, you know, because everybody reads all the knowledge-based articles for all the patches, right?
know I do.
Oh, go ahead.
I was just saying that and then, uh, you know, they don't they don't
change the uh, local administrator password ever.
Um, and then, you know, speaking as a former systems
administrator from a lifetime ago, I get, you know, if it's not broken, don't go fix it.
Uh, but this is pretty broken.
It's pretty broken.
Yeah.
And so kind of recap.
Basically, they, the patch stopped new
passwords from being basically used in that really easy to crack format,
but all the old stuff, it was incumbent upon the administrators to go fix on their own.
And that's at this point, you got 2 admin accounts from GPP.
Uh, you've got uh, 3 or 4 accounts from Kerberosting.
We already have 6 accounts from password spraying on the outside of the environment.
So there's just a multitude of different accounts that you can use now to basically try to start using those creds.
You know, you start logging in with remote desktop and authenticating
and seeing what you can actually gain access to, and then you use that.
Also, at this point, one of the things we do in
almost every single assessment, not every single assessment, but almost
every assessment that involves a red team or C2 pivot
is established secondary command and control.
Now, to be completely honest, a number of attackers
wouldn't have established a secondary command and control server with malware outside of the environment.
They just wouldn't.
If you have the level of access that we have at this point, you would generally
stay with the protocols that you have so you can fly
underneath the radar, but that actually gets into a fundamental shift of
how you can look at assessments and how they should work.
Um, one of the key mantras that I always like to say at BHIS is our goal is to get caught.
At some point, we desperately want our customers to be able to detect us.
And the reason why is we want to be able to identify those
clipping levels, where the organization's security technology and their architecture
is successful, and it is, in fact, working.
We don't always want to approach every single assessment with, can we hack you?
Now to be honest, we do have customers that we do that, but they're rare.
There are customers that have been doing this for a long time.
They have a good security posture.
We've tested them multiple years in a row, then we switch into a full
red team or a full black team to try to gain access to that environment.
With a lot of just standard pen tests or red teams.
You do want to identify the clipping level where someone could detect you.
And unfortunately, in this situation, a number of different command and control channels were established.
DNS, VS agents, standard HDPHDPS,
and none of them were actually detected, which is a bit concerning.
And we'll talk about ways to detect those in the next webcast.
Now you pulled the password hashes.
At this point, honestly, Derek, I thought you were just being mean.
Um, using volume shadow copies to pull
uh, basically all of the password hashes from the domain controller.
Um, the ntds.dIT file where the password hashes are stored.
And you pulled it from volume shadow copy.
Now, why would, as a tuster or
an adversary, a quote unquote bad guy?
Why would you pull the password ashes from a domain controller using volume shadow copy?
Um, well, why would you go after the passwords altogether, right?
I mean, uh, so, so, uh,
to take a step back to what you were saying for about, uh, you know, a secondary C2.
It was twofold, one, uh, we were a little worried that they were going to figure out we were BPanning in.
I never did, but, you know, we only had like 2 certificates,
you know, for, you know, time to whatever users we had.
Um, and so we're a little worried about that, but we're
also like on week 3 of the engagement at this point.
And, um, you know, we, yeah, we
kind of, we wanted to at least get the blue team, you know, blue team a chance, right?
So, but then why would you go after passwords?
Well, we, you know, this is a red team.
We had an objective.
Like, we weren't just going to go in and say, oh, look, we had to, ha ha.
No, I think they wanted us to go after some specific financial
type information that we're in, what was in their environment, and we
figured they were in databases, so we were going to go after database administrators, and for that, we needed credentials.
And so we went to go get all the hashes.
And now specifically on volume shadow
copy as somebody that's doing adversary emulation.
Why wouldn't you just use hash dump for metaspolite interpreter or any of the PW dump tools out there?
Why would you use volume shadow copy against a domain controller?
Yeah, so, um, you know, using something that's,
uh, well, historically, um, uh, using
something that was in, uh, you know, metasploit, uh, you had to
put like a, you know, session on the domain controller or, or
used something that injected into LSAS and I really didn't want to crash a
domain controller, which I've done in the past.
So you use volume shadow copy to go get a copy of
the file from the server because the NTBS dot files in use and you can't just go copy it.
And the
likelihood of crashing a domain by doing volume shadow copies using secret stump is very, very, very low.
Yeah, I mean, and now I don't even do that.
I just use replication services and secret stump and
just go and stream it off the server.
I don't log into them and controllers anymore.
Just pull it off.
All right?
Then crack passwords.
Now, you were talking about 8 character passwords earlier.
What are some of the reasons that you think that organizations still are using a character passwords?
Because this isn't this isn't the exception.
We're starting to see organizations kind of eke up to 10
character passwords, but it's rare for us to see an organization make the jump to 15 characters.
So, I think, um,
Unfortunately, if you have a mainframe in your environment, chances are there's
some overarching password policy in the mainframe only supports
8 characters, everybody thinks 8 characters.
We can't have 2 separate policies, one for your mainframe
password and one for your domain password because that would be crazy, right?
Or we could never make an exception for any kind of policy because
we're in 100% compliance across the board anyway.
Yep, yeah.
No.
And, you know, I think this particular customer did have
a main frame and it was just the cultural type thing.
Other organizations we see.
It's just a fight.
They can't, because the operations folks
just, they just think, 0 my gosh, now I have to have an 18 character password
policy and it has to have, you know, an exclamation and some numbers and some letters.
It got to be complicated character set and, you know, it doesn't.
And one of the things I talk about in the notes.
And by the way, for this webcast, every one of these slides has
full notes, sans like literature style.
One of the things I talk about is the NIST Green Book series.
You know, I keep talking about that.
That's something back in 1984 that developed a policy that was released in 85 that said 8 characters.
Oh, it said 8 or nine, but at any rate, everyone read that to be 8 characters.
And then they got picked up from policy to policy, to policy to different audit standards.
And we still see it today.
And I think also people get attached to their passwords.
Like, they love the fact that they used a password that
was their initials and then their last 4 of their social security number in college.
So they just keep using things.
Yeah, right?
Um, they just, you know, they they keep on reusing those again and again.
And it's funny how many organizations have fought this fight for
years to try to increase the password complexity.
And people are always like, like management.
I was always like, well, prove to me that an attacker can do this.
And then when a firm comes in and does prove it.
Then it's like, okay, well, now we've got to change it, and they maybe go to 10.
So it's funny to see how password complexity is eking up.
And then search and plunder.
And I didn't get into a lot of details.
You were talking about database servers or old legacy systems and
uh, And honestly, this is the goal, right?
Anytime an adversary is coming at your organization and they're
a targeted adversary, they have a goal and objective.
When you're doing pen testing, red teaming, black teaming, there should be
a goal and objective of what you're going to use all this access for
to gain access to something sensitive.
And different tools, you have share finder, male sniper at this
point, with 70% of the passwords of the organization, the entire organization
is effectively owned, um, by the adversaries.
And if it gets to this point, that's what we call a really
bad day at that point.
So a special note on Chris Nickerson.
I noticed that Sierra brought up Chris Nickerson's Twitter earlier, just a little while ago.
Somebody pointed out, and Chris was like, I'm going to call you out.
If you don't, if you're going to use Red Team, you don't have
physical, social engineering, electronic on this one.
So we didn't cover those.
And one of the reasons is we're at 1152 mountain.
This is going to be a series, right?
So the next webcast is going to be all about the defensive components
that would have made our lives completely difficult.
That's going to be increased password complexity standards.
That's going to be 2 factor authentication on absolutely everything.
It's going to uncover identifying services that are no longer
being used or service accounts that are no longer being used in disabling those.
Also, JP serp.
We're going to talk about what event IDs are going to be triggered in which situations.
So we want to break that up.
So some components will be broken out into dedicated sessions.
So there will be a dedicated session for just the physical pen testing and social engineering.
Sierra talked a little bit about social engineering, feeling
creepy about getting people's email and getting access to it.
So those things are absolutely on the menu and it's
hard to cover a whole engagement and just a one hour webcast.
But we absolutely love Nickerson.
We love layers consulting.
They're one of our sister pen testing firms up there with trusted Sack and
in guardians and secure ideas, people that we work with very regularly.
And we chat with all the time.
In fact, I think Nickerson is coming out for Weldos High Confest.
Is he confirmed?
He was here last year.
You don't remember all of this stuff off the top of your head?
No, I don't, John.
so much stuff
So much so much is going on.
But do check out.
Chris, next time he's presenting someplace.
All right, now, one of the final things I want to call everyone's attention
for, and this is something that's going to be tying into the next webcast, is
I'm not going to be talking about one specific technique to
detect and stop each individual adversary point.
And that has a lot to do with whenever we discuss
defense and depth over the years, over the decades.
A lot of people took that to me just spending a lot of money on defense.
Like you have AV everywhere.
Well, we've got 100,000 endpoints with AV.
That's a 100,000 AV engines.
And that's defense and depth, right?
No, it's not.
So we're going to be talking about for each component.
How can we overlap multiple views?
So if we dropped an agent, like VS agent, an implant on this organization.
We should be able to detect those by we.
I mean, blue teamers, should be able to detect those with endpoint antivirus, user behavioral analytics.
We'll talk about JP cert and logon tracer.
Netflow analysis.
Sim, specific event IDs that you can focus in on, and of course, endpoint firewalls.
So having multiple different components for each one of our different attack
steps or attack tactics, how you can actually detect, respond,
and stop these different components of what was being used.
So that's what's coming up next weekish, maybe, the next webcast.
So be on the lookout for a invite coming out
for the next webcast is going to dissect this.
We are not going to spend as much time talking about the attack.
We're going to spend a lot more time talking about the defenses and detections associated with it.
It'll be fun.
Pen testing, what we do, Black Hills information security, go through this quick.
pen testing, web assessment, mobile ops, red, black, purple, hunt teams.
Mergers and acquisitions, assessments, webcasts, and of
course, I think we do security memes better than just about anybody out there.
I think that we're, I think that's one of our core competencies.
Absolutely.
I think we rock at that.
Gift weets.
Also want to say thanks for those of you that are new to this webcast.
My name is John Strand.
We've got Derek on as well.
We've got Sierra behind the cameras, Briana.
And I'm associated with Security Weekly, Ions, Active Countermeasures,
Sans Institute, Black Hills Information Security, and I literally look
like a NASCAR driver with all the patches and all the things that are going on.
So here we are.
Do we have any final questions before we wrap this up?
We had so many questions.
I'm sorry I didn't get all of them.
I tried to hit the ones that kind of fit in as I could like keep up.
Send me an email, Sierra at bhs.co, if we didn't get to your question.
Thank you for everyone that was on 1st time.
Thank you for everyone that was on multiple times.
If you have a BHIS webcast punch card, punch it again.
See you on the next one.
Thank you, everybody.
Take care.
Bye.
See you, Derek.
Thanks for joining us on the podcast version of the Black Hills Information security webcast.
See you again next time.