Our next speaker, first time at DEF CON, Michael Lundvik is going to be taking a dump in the
cloud. So get ready. Please give him a warm welcome. Hey, what's up? Well, first of all,
hi, mom. Second of all, kind of excited, obviously. Didn't really think the title would go
through, but sure, we're leading into it. So the talk is called taking a dump in the cloud, and
it's more of taking a data dump from the cloud than taking an actual dump in the cloud. But,
yeah, we'll get into it later. So I'll start by introducing myself. My name is Melvin Lundvik. I
go by the alias FlungvikOnline. I used to be a C-sharp developer. Now I'm a red teamer over at
TrustedSec. I work at the target operations team. I'm extremely lucky to be able to
work with such extremely talented individuals. I do Twitch streams. I can't say I do them every
Sunday. People are going to call that out. I try to do them some Sundays. I used to do them every
Sunday. I don't do it anymore. I'm also part of a Norwegian technical hacker podcast called
Shellcast. If you speak or listen Norwegian, then maybe that's something for you. I run a very
unsuccessful YouTube channel that you probably don't want to look at, but if you want to, go
ahead. I maintain the Sharp Collection and UMSI Fail Program. I'm also part of the
project. Maybe some of you heard about it. Maybe not. I also have some other projects that I've
added to the GitHub over time. So we're going to go through this sort of as a story, right? So I'm
releasing a toolkit. I'm going to talk you through what got me started into the developing
process of that toolkit and sort of how it all began. So it began back in 2020 or mid of 2020. I
was doing an external penetration test against a customer, and one of the things we do when we do
this is we do a test, right? And most customers, they typically have Microsoft Office. So I was
going to do a password spraying attack against Microsoft Office. In my mind, such an attack is
split into three different modules. You have the enumeration phase, the spraying phase, and the
exfiltration phase. During enumeration, you'll try to identify as many possible email accounts
which would be linked to accounts in the actual client's tenant as possible. Typical resources
are Hunter.io. Probably, I'm guessing a lot of people heard about Hunter.io. I'm not sure if
you've heard about that. It's sort of a database that fetches and collects emails for companies
specifically. So you can go in, you can look up the company name, and you'll see the email and the
email syntax. The email syntax is very important. We'll get back to that later. You also have the
de-hashed service. Now, de-hashed is a breach database lookup service, and all of these services
sort of live in a weird gray area. And de-hashed has been stable for years. Sometimes,
they get taken down legal-wise. I mean, if an attacker can get to it, I want to know that
information as well. So I consider that gray area fine to use in general. So de-hashed is great.
You look up the client domain name, and you'll be prompted with a bunch of emails that has been
obtained from semi-publicly breached databases. Then you have Google, right? Simple as that.
Biggest search engine on the planet. You use something called Google Dorks in order to find
files and other information related to the company.
If you scrape meta information from those files again, you'll have information about names and
possible accounts linked within the company as well. And I think the biggest one out there,
LinkedIn, right? And this goes back to the email syntax. If you have the email syntax of a company,
if you know that the company uses first name, dot, last name for their email accounts,
then you know that JMJMachine over at LinkedIn is going to have JM.JMachine as an email account,
right? So if you put that together, you're able to come up with sort of a bigger list of possible
email accounts within a tenant. So then you go over to the actual spraying phase where you pick
out a shitty password like summer 2022 exclamation mark, which everybody still uses even though it's
2022. And you pick out a service you want to hit that with. So, you know, typical ones are
Microsoft Office and the actual cloud tenant, Office 365. Then you have some customers that
still expose AD FS. They have some sort of on-prem application, so they expose AD FS. You have the
clients exposing the application, the exchange externally as well. And then you have the third
party identity access management and SSO providers like Okta who sort of take over the federation of
the users and then you can connect other services and apps into that. So you pick a target and you
spray, right? And then hopefully you hit a user with a bad password and you get access to
something. You get access to some sort of service on the inside that has some kind of data and you
perform some sort of post-exploitation activity, typically exfiltration.
So this is what you do and this is what I did. And what I did in the story, I got a user with a bad
password and I tried to log in everywhere. And I was prompted with MFA, right? I couldn't get in.
No matter what service, no matter what application, just got prompted with MFA. Except for
one. Microsoft Teams. So when I logged into the Microsoft Teams desktop app, I was not prompted
with MFA. And I initially thought this must be a bug. It must be something weird going on. But I
tested it against that client. And multiple other things happened. I was not prompted with MFA. I
tested it against another client. And for some reason, they just had a major gap when it comes
to the Microsoft Teams desktop client. And this fell through because of conditional access. So
conditional access is a service that Microsoft offers for its users in its tenants that allow
you to define certain conditional that will give you access or not. Hence, conditional access.
So say you try to log in from Europe. You won't get in because you're logging in from Europe and
the company knows that we don't have any employees in Europe. So there's no reason to give you that
access. Or if you log in from a trusted subnet internally, maybe they don't prompt you for MFA
because why would you? You're on the internal network, right? You're already past the physical
boundary. So sure, let's just skip MFA as well. So in the case I'm talking about, they
misconfigured their conditional access policy so that the Microsoft Teams client could just get in
without MFA. My hypothesis about this is that in the actual user interface where you define
conditional access, there was some sort of user experience mixup where they couldn't find the
Teams client checkbox or whatever because I found this on multiple clients within like a four-month
span and then it just suddenly go away. So I don't know if that's happened or not. Just throwing
it out there. Anyway, I got into Teams. At the time, I didn't understand that this was due to
conditional access. So I started just digging into Teams. I started reversing the API calls I've
made and I started looking at the network traffic that it generated.
How it interacts with the Microsoft resources online. And I don't know if you can see the
actual text, but this is somehow what that looks like. So if you're ever planning to dive into the
network flow of Teams, there's two other processes that you got to know about.
And those are Microsoft ADD broker plugin and background task host. If you do not capture the
network traffic from these processes, you'll have access tokens appearing out of thin air and you
will use hair.
I can just tell you that because nothing makes sense. But if you start capturing the network
traffic from these processes, including Teams, you'll start to get sort of the full flow on how
Teams work and how it authenticates and what APIs it uses. So it starts off by authenticating
you as a user towards the login.microsoftonline.com endpoint federated by Microsoft.
And then you get the access token back in what's called a v1 formatted token JSON blob. And it's
basically a JSON blob. It's your access token, your refresh token, your expiration time and
information related to your access. That access token gets put in two places. So it gets put in
the SSO off cookie and it gets put into a header called authorization with the prefix of bearer,
which is very typical and follows the OAuth standard. And then something weird happens.
You guys know Skype, right? Which was supposed to die in like July 31, 2021 or something? Skype it
is alive, it just won't die.
And Teams knows this because it fetches a token
called Skype token and reaches out to the
teams.microsoft.com endpoint, gets the Skype token,
puts that in a cookie and a header,
and then keeps talking to the Teams API endpoint.
So my best guess would be that the Skype API is alive
and that is just wrapped behind the new modern Teams API.
So that's rather interesting.
But this is the basic functionality that Teams would need.
Once it got the access token and the Skype token,
it could just access the basic Teams resources, right?
One thing I want to mention is that
during this first authentication attempt,
Teams specifies a client ID,
and it will become very important,
but a client ID is basically a grid string
that defines the application talking to the endpoint.
So you have one default client ID
supplied by Microsoft for Teams,
and then you have other client IDs
for different other applications.
And again, I'll come back to this later,
it's very important.
So yeah, so in preparation for this talk,
I did this, right?
And I tried to replicate what I did back in November 2020,
but the results were different.
Microsoft had changed something, who wouldn't know, right?
So when you do the initial access,
you no longer get a JWT token in response
in the classical V1 formatted JSON structure.
You get an encrypted string in return
that turns out to be a JWE string,
which is a JSON web-encrypted string or plain text.
And inside that encrypted plain text
is the actual V1 formatted token, which we want, right?
And if you actually decode the first X or so length
of that string, you can actually,
basically before they code that,
then you can find the encryption algorithm that's used
to be able to encrypt and decrypt it.
But I don't want to deal with that.
That's just too much of a pain, so.
Again, Microsoft changed something.
They didn't break anything for me.
The old method still works.
This is sort of just going into a bit of a side quest here
about why they would change this.
So they changed their default authentication flow
that was used before into something called
an on-behalf-of flow, which is just different
than uses the JWE.
And if you read their documentation about this,
they state that, do not attempt to validate or read tokens
for any API you don't own.
Tokens for Microsoft services can use a special format
that will not validate as a JWT.
That sounds awfully similar to what we just found, right?
So threat, challenge, I don't know, sounds like a challenge.
That's what it sounds like.
So if you take a look at the documentation again,
we can see examples of the V1 formatted token.
This is what it's supposed to look like.
This is what it looked like before.
And notice the V1, the 1.0, and then we go back
to the request that is now changed, and we see this.
2.0, 1.0, 2.0.
Yeah, if you change that back, you're good to go again.
So if you take the initial request and you just downgrade,
you just change the parameter from 2.0 to 1.0,
you will get the good old V1 formatted token back,
and you can actually understand what's happening,
which is quite fun.
Sadly, we don't have time for this.
This isn't what we're going to talk about.
It's just sort of a side quest explaining that,
I was preparing for this talk, and they changed stuff
right before the talk, and it's still silly, but.
Okay, back to the main story.
So we logged into Teams, right?
Teams got two access tokens,
so they can now do basic functionality.
This is set basic functionality.
So you have the chat module,
and you have the Teams chat module, which is Teams,
both reaching out to API endpoints,
ending in Microsoft.com.
And then you have two other modules, right?
You have the calendar, and you have the files.
And files, that's OneDrive.
And calendar, that's Outlook.
So how does Teams access this without me logging in
or accepting a redirect or anything like that?
It just has access to it,
which at the time was really interesting.
So if you take a look at the network traffic,
you can actually see that it sets the grunt type
in the parameter as refresh token,
and it supplies the refresh token from the old resource,
specifies a new resource,
and then you're able to go into that resource
or get a new access token that can access that resource
without doing an interactive sign-in again.
And that's actually, so according to the,
so Microsoft is bending the OAuth 2.0 specification
pretty hard here.
They're just saying, nah, we don't want to do it like this.
Specification isn't there for a reason,
and they're bending it pretty hard.
Because if you look at the scope there,
that list of permissions is huge.
And this is directly tied to the client,
the client ID that we talked about with Teams.
Every time the Teams client accesses other resources
using this technique,
using the refresh token grunt type request,
they just get a metric ton of scopes and permissions
for that resource.
The Teams client can send emails on your behalf.
The Teams client can read and write emails on your behalf
from your Outlook instance, which is very interesting.
And that refresh token request or that,
we'll get back to it, which is a non-interactive sign-on,
looks something like this.
So what happens is that the Teams client
takes the access token that it originally required
when you logged in, typed in your password,
you get an access token.
And then it sends that back up, that actual access token,
using the grunt type refresh token,
and it just gets a new access token for a new resource.
It's magic, it's absolutely magic.
And this is a non-interactive login.
So there's two type of logins in Microsoft.
You have the interactive logins,
and then you have the non-interactive logins.
If you go to the Azure portal,
the AAD section of the Azure portal,
and you go into users and sign-ins,
you can see two type of sign-ins.
Again, non-interactive sign-ins and non-interactive sign-ins.
Interactive sign-ins are when users log in using password
and username or some other form of authentication.
Non-interactive sign-ins are when an application
accesses other resources just like Teams does.
And this is what that looks like.
So you can see that the Microsoft Teams application
is getting access to Microsoft Graph on behalf of that user.
And this is all very interesting.
Just recently, at Troopers this year,
some awesome individuals over at SecureWorks
released a research called Family Refresh Tokens.
I gotta give huge shout-outs to Ryan from SecureWorks,
that's detect.dev at Twitter,
who helped me validate some of this,
and really, his research put words on what I saw at that time.
And I know many other internal researchers
also looked at this previously.
So what Family Refresh Tokens describes
is not only that a refresh token for one application
from different client IDs can refresh into other resources,
but that you can also change the client ID
and get even more resources for other applications.
And I won't go into it, but I'll just...
take a look at this, read it 10 times, ingest it, right?
It's one of those things you have to ingest multiple times.
It's awesome, absolutely amazing research.
I can't wait to see what others will
and what I probably will integrate into this toolkit
as a result of this research as well.
So, I know I'm going probably way too fast,
so just to recap here, so we'll, we dived through Teams,
we understood the network traffic, we got the access tokens,
we understand how Teams refreshes using its access token
into all the resources using non-interactive sign-ins.
How can we abuse this?
What could possibly go wrong, right?
So, initially, I started creating something called
Azure Active Directory Authentication Library,
Aval, or Sharp Aval, because Aval already exists.
And it would be, in the mindset,
it would be a C-sharp library that simply
takes a username, a password, or a session
and just dumps everything, just exfiltrates all the data.
And in its initial infancy, it only did one drive.
So, you would give a username and password to the application,
it would just dump the, as in, actually download
the entire OneDrive directory of the user, right?
And it was designed for initial access,
you could download files, and you could take a look at them
and possibly gain further access
based on the contents of those files, right?
But I didn't think it was good enough.
I didn't think it was, I wanted it to be more
of a wholesome toolkit that you could actually use
from start to finish than just the data exfiltration part.
And that's when I think Audroir helped me
came up with the name Teamfiltration.
And that's the actual toolkit that's been released today
and I will push to get up once this talk is over.
So, Teamfiltration is a C-sharp application
that is cross-compiled so it could be ran natively
on Linux, Mac, and Windows that streamlines
the whole enumeration, spraying, exfiltration,
post-exploitation activities when you're performing attacks
against the Microsoft Office 365 Cloud.
And I'll talk, we're gonna talk way more about it,
but some of the key features, and I know this text
is probably way too small, but key features
is that Teamfiltration is strictly database-oriented.
This means that you will not end up with 25 text files
with different emails and different passwords
and different combinations on your desktop
when you're done using it.
It's all stored in a localized database,
similar to CrapMap Exec and various other tools, right?
And the plan with this was to automate
and make the tools smart.
So when you do initial enumeration,
the tool knows what accounts was valid
from that initial enumeration attempt
and will store those in the database.
So once you go over to spraying,
it already knows which accounts are valid
and you can spray those.
You don't need to provide a new set of list of usernames,
it's all stored in the database.
We'll talk more about it in the next slide.
It also has FireProx integration,
so still the only viable sort of effective alternative
against Azure Smart Lockout is just rotating IPs,
which FireProx does quite brilliantly.
So it has built-in FireProx integrations
to make sure that every spraying attempt
originates from a different IP.
It has built-in DHast integration,
so that once you do the initial enumeration,
it can simply just pull the records from DHast
to give it an API key,
and it can add it to the database as valid emails.
It has push-over integration,
so you can get alerts and notifications
when you compromise an account
or when multiple accounts are locked out.
It has automagic password generation and user enumeration.
We'll get more into that, but again,
at least for me, I don't know about you guys,
but every time you do an external spray,
you have 40 or 50 passwords that you always go through,
and they are almost, oh, wow, I have a switch,
and they are always the most common ones.
The summer, the months, the typical password month and fees,
it's all the common stuff, right?
So there's no point of having you generate that every time,
depending on what time of the year it is.
It can just do that for you.
The same goes for user enumeration,
and we'll talk more about that,
but it's basically just using
brute-forcing users by using statistically likely usernames,
right, which is a very common technique.
And then, sort of the bread and butter of team filtration,
again, is the exfiltration capabilities.
So once you compromise a user with team filtration,
this is the data you can actually pull from that user.
You can pull all the Teams chat logs and attachments,
as well as contacts lists.
So every chat, every message your user or your target
has ever sent on Teams, you can pull down,
and you can easily grab through locally
on your machine.
Same goes for OneDrive.
Every file the user has in its OneDrive,
that includes both files it has added
and files it has been shared or given access to.
But in OneDrive, you can pull down and take a look at.
Same goes for Outlook.
Every email, as well as their attachments,
can be downloaded and take a look at.
And then you have support, too, to pull data
from the Graph API, which is basically domain information,
users, groups, and some basic tenant information.
And there's one module that I'm particularly excited to talk
about, and that's the backdoor CLI, which we'll
talk about in our demo at the end, which is really cool.
Technically, I don't want to claim MFI bypass or whatever,
but team filtration has the capabilities
to enumerate the conditional access policy applied.
Basically, it brute forces using a bunch of client IDs
and resources.
And once it gets on the inside, it
could try to refresh out again.
So you only need one gap in your conditional access policy.
Once you get in, you could refresh out
on the inside using non-interactive sign-ins.
And then, yeah.
I just heavily abuse this refresh tokens.
So this is sort of a simple explanation of how it works.
So team filtration has a centralized database
that is stored on disk.
It uses LightDB.
Once you start using the enumeration module,
every time you find a valid email account,
that data is stored in the database.
So team filtration is aware of how many valid accounts
you have enumerated.
Once you go into the spraying module,
team filtration will automatically
pull the valid accounts from the database, and you spray them.
It will keep track of.
When you sprayed, what password you sprayed,
what the response was.
If you have false positives during the enumeration phase,
and team filtration finds this during the spraying phase,
it will correct for that.
There's honestly so much logic in here.
I don't keep track of it anymore,
but there's a lot of fun logic in here that really helps
and sort of, I feel, makes this attack more modern
than it usually is.
Again, you don't have to mess around with all these text
files.
And then once you get access, hopefully, team filtration
will store the access token in the database.
It will keep track of multiple access tokens
for different resources so that once you're ready
to exfiltrate, you won't sign in again.
It will just use the access tokens you got
when you successfully sprayed it and logged in the first time.
So again, a bunch of logic in here
that makes this automated and easy.
Let's take a look at the enumeration module,
what that looks like.
So this is a picture of the help menu from team filtration.
It's rather massive.
Within the enumeration module, you have different options.
You specify.
The non-optional ones are the dash dash domain one.
And then you have to choose some sort of validation
technique.
So you specify a domain.
Let's say trussellsec.com if you want to attack them.
And then you choose a validation method.
So out of the box, team filtration has three validation
methods, validation methods being methods of validating
that the email accounts are actually valid.
Some of them are passive.
One of them are active.
Active meaning that they actually show up
at the client's end point.
So if we take a look at validation methods,
validate login, that will just simply attempt to log in.
And that will obviously show up in the tenant sign in logs.
But that is the most accurate way of determining
if the account is real.
Just attempting to log in, taking a look at a response,
it's real or is it not.
And then you have the validate MSO which is the,
which has been heavily abused for years now.
It's the get a credential type post method
that everybody, like most tools uses basically.
And it is heavily rate limited and heavily, it starts to give
out heavy amounts of false positives.
And then there's validate teams.
Now this is something that we've been using internally
for quite a while.
And I think somebody, I think I saw it becoming public
or whatever, like half a year ago, eight months ago.
And basically what the validate teams method does
is that given a sacrificial O365 account,
it will log in, authenticate to teams,
and then use the search function in teams
to look up users across tenants.
Again, that depends on the tenant's configuration,
but this is still extremely important.
It's extremely overpowered.
You could easily do 300 lookups a second
without getting rate limited
or be giving massive amounts of false positives.
And then again, this is, yeah,
that's sort of the main bread and butter
for the integration module,
being able to use validate teams.
And then you can pull domains from the hash.
You can supply your own list of usernames
if you've done manual all since, right?
I don't wanna make it hard.
I just wanna make it a bit easier.
In action, using statistically likely usernames.
So there's this awesome GitHub repo.
I think I'll link it in the description.
It's right at the bottom.
That's called statistically likely usernames.
And it contains multiple text files
of common first names and last names in the US.
So instead of doing the hard labor
of finding targets online, you just brute force it.
So team filtration, given a domain,
and given a syntax, will pull down,
it will generate possible emails,
and it will brute force those emails.
Again, just the validity of them,
not logging in using the validate teams method.
And this has proven to be extremely effective.
And that's just what that looks like.
Then you have the spraying module.
So I'm not gonna go through all of the options,
but the spraying module does spraying,
and you have a bunch of different options to set it.
So if you wanna generate passwords only for seasons,
only for months, or if you only wanna use the common stuff,
you can specify that, and it will generate specifically.
If you wanna supply your own password list,
you can do that.
If you wanna, so I don't think I've seen this anywhere else,
but if you wanna hit the,
call it the US Cloud.
I'm unfamiliar with the exact name of it,
but some Microsoft tenants are under the .us domain,
mostly, most likely because they're government.
And if you wanna brute force that,
you have to hit the .us domain.
So there's also support for that.
As well as the AAD technique that Cureworks found
that doesn't show up in logs.
And then you can define sleep, sleep min, sleep max, delay.
You can get push notifications.
You can force spraying,
even though you get locked accounts in return.
Yeah, it's, I think the spraying module
is pretty standard with everything else.
So this is what it looks like.
You do dash dash spray.
If you don't give it any parameters,
it will set a default sleeping time.
It will generate passwords automatically,
and it will start spraying.
Then the exfiltration module.
Now this is, again, the bread and butter of teamfiltrations.
And there's multiple ways to get,
just use the exfiltration module.
So you have three options.
One, you could use the account that you compromised
that should be in the database.
Use that.
And it will just run it with no options,
and it will allow you to pick what compromised account
in the database you want to exfiltrate data from.
You could supply your own username and password
if you gained it from some other source.
And then you could also provide the cookie.
So I'll have a demo later where I'll demonstrate using that
sort of in a red team scenario
where you already compromised the host,
and you want to just pull the cookies.
You could give teamfiltration the cookie,
and it will use that to pull all the data,
which is super handy.
And then you can specify what sort of data you want to pull.
You don't have to pull all the data at once.
You could pull,
if you just want to pull AAD,
or if you just want to pull OneDrive.
And then you can also dump out the tokens
if you want to use the tokens with other tools,
because there are a bunch of other cool tools
that you could use to access AAD.
That's what that looks like.
So in this example, I said I want to exfiltrate emails,
and I want to exfiltrate OneDrive,
and it dumped 28 emails from this test account,
and it also dumped out the OneDrive directory
and stored that to disk.
Again, so it's really easy to grab through it and find it.
And then, I'm going to show you a little bit more
about the database module.
There is another module that isn't included.
That's called the database module.
The database module is simply a way to make it easy for you
when it comes to reporting.
So the database module allows you to export information
from the database that might be relevant.
So you could get a full summary of when you started spraying,
when you stopped spraying, what password you used
when you did that spray, what user you target,
what combination of user and password you used.
All that fun stuff that a client might ask about.
You can just pull that,
and you can put it out to JSON or CVS,
or you could just show it in the terminal.
Okay, I am way ahead of time.
So let's do the demo one external testing.
So this demo is just sort of a use case where you,
basically my first use case.
You're an external attacker.
You want to password spray and gain loot
from attacking Microsoft Office Cloud.
Let's see if I have that.
Okay, let's see.
So this is a startup, so hopefully you can see
the top portion there.
So that's infiltration.
I'm giving it an output path where I want the potential data
that I gained from this stored,
as well as where the database will be stored.
I'm giving it a configuration file.
Every instance, every time you run to infiltration,
you will need to give it a configuration file
with standard files.
Can't see the top portion?
Oh wow, okay, interesting.
Two screens then, right?
Hmm.
Okay, let's.
Try to get that over to the other screen.
We can try shutting down power play, but I don't want to do that for you.
I'll probably break your setup, but why not?
How about now?
Awesome.
Okay.
Cool.
Okay.
So, yeah.
So, again, we're starting up the infiltration.
You guys can see the command line at the top, right?
You can see the actual command.
Cool.
Okay.
So you have the output path, which is where you want to store all the data you potentially
get from the exfiltration attack, and also where the database is stored.
You have to provide it a JSON configuration file with some values that the infiltration
needs to run.
Stuff like the fire proxy URLs you want to use.
The dhash API key you want to use and stuff like that.
I'm telling you to go into the integration module and that to take the usernames from
my own text file that I found using OSINT, right?
And then I'm telling you I want to validate these accounts using the validate login method,
which is technically just attempting to log in.
Spraying, basically, right in the integration module.
So we'll do that.
And we'll find a bunch of other accounts.
And then, so can you see the bottom one?
And then I'll try to go straight into the spraying module.
So, and now something is going to happen.
It won't work.
So I go spray and I type enter.
And why doesn't it work?
Because the enumeration method we just used attempted to log in.
So I want to make sure that you know that you are now attempting a second round of login
attempts and I'm stopping you unless you give it the dash dash force parameter.
Again, this is logic that is possible because we have the database.
I know when your last login attempt was.
So I don't want to risk you starting to log out accounts.
I'm letting you know, hey, sorry, you have to wait if you want to keep spraying.
So that's what's happening here.
It says sleeping the remaining 98 minutes since the last spray.
And if I want to get around that, I have to use the dash dash force parameter.
And that's what I'll do.
That's on point.
There we go.
And then it does the spray.
And then hopefully we'll have a compromised account.
So there we go.
So we have an account.
It is the one and only Biff Tan who has the password of January 2022.
And he doesn't have MFA.
So we'll move on.
Now I can, I mean, once you compromise the account, then sort of the easy part starts.
Now we can just do dash dash exfil.
It's kind of annoying that we can't see the bottom line.
Okay, I'll skip.
So I did dash dash exfil.
Dash dash exfil.
And then dash dash owa.
So AAD to pull the domain information from the graph API as well as the users and groups.
And to be clear, that's all the users in the AAD tenant I can pull once I got that access, right?
And then dash dash owa to pull the emails.
And now something interesting happens.
What happens is that TeamFiltration knows that you are pulling the AAD and he knows that those users, we might want to spray them.
So it takes the users from the AAD exfil and it puts them back into the database.
So if you want to go back spraying, you can do that.
So you now have all the users in the tenant automatically added to your database and you can start spraying them.
Again, sort of quality of life improvements.
So it got, you can see it here, it got 134 AAD users, appending those to the database as solid users.
And if we go into the directory, we can see that we should have a bunch of emails as well.
All right.
So emails that you exfil using TeamFiltration are stored as HTML to sort of preserve the format.
And then the attachments are stored in a separate directory as well as you have a pure JSON file that's called all emails.
That will just have all the information as well if you want to play with it, right?
And that's the external penetration portion of TeamFiltration.
Oh, thank you.
Thank you very much.
Thank you.
But that's so boring.
We want to do red teaming, right?
Everybody wants to do red teaming.
So let's show an example of red teaming.
So this is the red team example.
Please show up.
Here we go.
And in this example, you have already compromised the host through phishing or whatever.
And then you're on the host and you want to exfiltrate all the information without doing unnecessary stuff, right?
So you dump the cookies through some method.
In this example, I'm just using the same method.
C sharp tool sharp Chrome to dump out all the cookies from Edge.
So I'm just showing that I got an active session with Bruce Wayne and that I'm logged into Teams and I'm logged into his Outlook in the browser, right?
I know he is Batman.
And then I'll dump the cookies.
I'll type it out just to show that we have a JSON file of cookies.
That was a bit quick.
But basically I'm just giving TeamFiltration that cookie dump, that text file full of cookies.
I'm telling it to exfiltrate all the loot.
And then it should be able to take that cookie file and do exactly that.
So it starts refreshing into different resources and then it's dumping all the information, right?
And now you get to see what the team chat looks like.
So once it's done dumping, got some zip files.
I probably canceled this, right?
No, I just leave it.
So I go into the directory of the output.
And then this is the information.
This is what it looks like when it's dumped.
So you can see.
You can see attachments, contacts, conversations, email attachments, emails, one drive, one drive shared, tokens, all that good stuff.
I go into conversations.
And this is the text files containing the raw JSON output from the team's chat logs.
So I can go into them and I can be trying to find the file.
And I can see the conversation.
I can see that Bruce Wayne started talking to Udvar at some point and said, hi, Udvar.
Told him he was Batman.
And now Udvar knows that no, you're Batman.
And this is great.
Because you wouldn't believe how many passwords people put in teams.
And it's so much easier to grip it out this way than to scroll through the thing forever.
Quality of life improvement for sure.
Cool.
And then emails, one drive, the files downloaded from the OneDrive directory.
It keeps the same structure.
Yep.
Cool stuff.
And that's the red team demo.
And then I have one final surprise demo for you guys.
It's the backdoor demo.
Thank you very much.
And the backdoor demo is really interesting.
So one of the things that is sort of a red team wet dream is that once you get initial access externally, you would like to move onto a host, right?
You would like to vertically move onto a host, right?
And how do you do that?
Well, so we have control over OneDrive, right?
OneDrive has a bunch of files.
OneDrive files are usually synced to the computer of the individual, right?
I don't know about you guys, but how many here have seen the desktop folder been synced to OneDrive?
Okay.
It's not just me.
That's a good thing.
Well, what is in the desktop folder?
A bunch of shortcuts.
So I created this sort of CLI interface for OneDrive that allows you to modify and replace files within their OneDrive remotely.
So you can backdoor their files on the desktop or in the documents folder.
So, okay, this is a bit longer demo, so what you're seeing right here is the perspective of the victim, right?
He has his desktop and he has this Microsoft document that is his daily notes.
He uses it every day to keep track of notes from his meetings or whatever else, right?
So he has that synced in his OneDrive.
And then this is the attacker's perspective.
So in this example, we already compromised the account of that individual through, you know, whatever means.
And we run the backdoor module.
The backdoor module will prompt you, hey, what do you want to target?
Because you might have multiple users, if you're lucky, right, that you can target.
We'll pick out Biff.
And then GFultration will access OneDrive and it will list out the files and folders in the root directory.
And it will sort of give you a semi-interactive CLI that you could use to navigate these files and folders, pick out the files and folders that you want to download.
And replace them.
So I see that, you know, he, the individual here has a daily notes file and that it was very recently modified.
In my mind, that's a saying that, oh, he might open this tomorrow as well or he might open it the coming weeks, right?
So just typing the help command to get some help.
And then I'll type replace.
The file index and then the file I want to replace it with.
So in this scenario, I have created a malicious macro document that I would like to replace this original Word document with.
I'll use the replace command.
I'll use the replace command to do that.
Index 5.
Copy as path.
And then go.
And then GFultration will delete the file, give it a few seconds, and upload it again.
Now, you would be amazed how effective this is and you would also be amazed that there is no notification from OneDrive's perspective when you do it like this.
So just look here.
I'll zoom in and then suddenly it's a macro document.
That's it.
There's no notification in the bottom right corner.
There's no sound.
It's just, oh, this is a macro document now.
And the next time he opens it, it's now, in fact, a macro document.
Yeah.
And that's basically it.
I think I ran through it way too quick.
The project will be online on GitHub as soon as I get off the stage and get a coffee.
And then I have to give a major shout out to detective.dev from SecureWorks validating a lot of the stuff I found, making sure I wasn't insane.
Making sure I didn't end up saying weird stuff.
And I have to thank the entire Jurassic team who has been helping me polish this tool for well over a year now and make it streamlined.
So thank you very much and enjoy the last day of Tescon, guys.
And I think I'm way ahead of time, so I might just do questions here, right?
Yeah.
Oh, okay.
Questions on the side.
Thank you very much.
Thank you.