 Our next speaker is the first time at DEF CON. Michael Lanvig 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 that Tyler will 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 Lanvig. I go by the alias Flanvig online. 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 an 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 a 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 UMC fail projects. Maybe some of you heard about it. Maybe not. I also have some other projects that I've added to the GitHub over time. We're going to go through this as a story. I'm releasing a toolkit. I'm going to talk you through what got me started into the developing process of that toolkit and have it all began. It began back in mid-2020. I was doing an external penetration test against the customer. One of the things we do when we do external testing is that we perform a password spraying attack. Customers today typically have markers of office, so I was going to do a password spraying attack against markers of 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 I.O. I'm guessing a lot of people 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 DHASH service. Now, DHASH is a breach database lookup service, and all of these services sort of live in a weird gray area. And DHASH 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 can see that gray area fine to use in general. So DHASH is great. You look up the client domain name, and you'll be prompted with a bunch of emails that has been obtained from a semi-publicly breach databases. Then you have Google, right? Simple as that. Biggest search engine on the planet. You can 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 the same J machine over at LinkedIn is going to have J and dot J machine 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 shady 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 the actual cloud tenant, Office 365. Then you have some customers that still expose ADFS. They have some sort of on-premise indications, so they expose ADFS. You have clients exposing the outlook of application, the exchange, externally as well. And then you have the third-party identity access management and SSO providers like Akta, who sort of take over the federation of the users, and then you can connect other services and apps into that. So you'll 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 clients. 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 fiscal boundary, so sure, let's just skip MFA as well. So in the case I'm talking about, they misconfigure their conditional access policy so that the Microsoft Teams client could just get in without MFA. And my hypothesis about this is that in the actual user interface where you define conditional access, there was some sort of user experience mixed up 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 it made and I started looking at the network traffic that it generated and 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 AADD broker plugin and Bracker and Taskhost. 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 actually 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 of how it authenticates and what APIs it uses. So it starts off by authenticating you as a user towards the login.markstuffonline.com endpoint federated by Microsoft. Yeah. So it does that 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 with 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 off standard, right? And then it's something where it happens. So you guys know Skype, right? Which was supposed to die in like July 31st, 2021 or something. Skype 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.markstuff.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 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 VVON format that 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 VVON formatted token, which we want, right? And if you actually decode the first X or so length of that string, you can actually base 64 decode that and 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. Again, Microsoft changed something. They didn't break anything from 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 used as 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 from Microsoft Services can use a special format that will not validate as the 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 VVON formatted token. This is what it's supposed to look like. This is what it looked like before. And notice the VVON, 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 VVON 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 said basic functionality. So you have the chat module and you have the Teams chat module, which is Teams, you have the PowerPoints 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 one drive. 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 ground 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 Microsoft is bending the OAuth 2.0 specification pretty hard here. Like they're just saying, no, we don't want to do it like this. We'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 ID that we talked about with Teams. Every time the Teams client accesses other resources using this technique, using the refresh token ground type request, they just get a metric ton of scopes and permissions for that resource. The Teams client can send emails on your behalf. They can read and write emails on your behalf from your Outlook instance, which is very interesting. And that refresh token request or that, which we'll get back to, 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 ground 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 AAD, right? 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 interactive sign-ins. Interactive sign-ins are when users login 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 already interesting. And just recently at Troopers this year, some individuals over at SecureWorks released a research called Family Refresh Tokens. I got to give a huge shout-out to Ryan from SecureWorks that's detect.dev at Twitter who helped me validate some of this and really his research sort of put words on what I saw at that time. And I know many other internal researchers also looked at this previously, right? So what Family Refresh Tokens describes is certainly 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. I won't go into it, but I just take a look at this read it ten 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 get into this toolkit as a result of this research as well. So, no one's going to probably wait too fast. So just to recap here we dived through teams, we understood the network traffic, we got the access tokens, we understand how teams refreshes using its access token into other 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 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 and password or a session and just dumps everything just exfiltrates all the data and its initial infancy it only did one drive. So you would give a username and password to the application and it would just dump, actually download the entire one drive directory of the user, right? And it was 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 a wholesome toolkit that you could actually use from start to finish than just the data exfiltration part. And that's when I think Alvar helped me came up with the name team filtration. And that's the actual toolkit that's been released today and I will push it up once this talk is over. So team filtration is a C sharp application that is cross compiled so it can be ran natively on Linux, Mac and Windows that streamlines the whole animation spraying exfiltration post-exploitation activities when you're performing a tax against the Microsoft Office 365 cloud. And I'll talk I will 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 filtration 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 and 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 animation, the tool knows what the counts was valid from that initial animation attempt and it will store those files. 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 Firefox integration so still the only viable sort of effective alternative against Azure smart lockout is just rotating IPs which Firefox does quite a brilliant thing. So it has built-in Firefox integrations to make sure that every spraying attempt IP, it has built-in dhast integration so that once you do the initial animation, 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 pusher integrations so you can get alerts and notifications when you compromise an account or when multiple accounts are locked out. It has auto magic password generation and user generation. 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 way, you have 40 or 50 passwords that you always go through and there are almost, oh wow, I have a search. And there are always the most common ones. The summer, the months, the typical password one to three is like 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 integration and we'll talk more about that but it's basically just using brute forcing users by using statistically likely user names, right? Which is a very common technique. And then sort of the bread and butter of team filtration again is the extra filtration 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 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 through 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 excited to talk about, that's the backdoor CLI which we'll talk about 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 can try to refresh out again. So you only need one gap in your conditional access policy. Once you get in it can try to refresh your account. And then yeah it just heavily abuses 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 light DB. Once you start using the enumeration module every time you find the 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 enumeration 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 need 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 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 within the enumeration module we have different options. You specify I think the non-optional ones are the dash dash domain one. And then you have to choose some sort of validation techniques. So you specify domain. Let's say trust us at dot com if you want to attack them. And then you choose the validation method. So out of the box team filtration has three validation methods. Validation methods being methods of validating passive. One of them are active meaning that they actually show up at the client's end point. So if we take a look at validate login that will just simply attempt to log in and that will obviously show up in the tenant sign in logs. 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 has been heavily abused for years since the get a credential type post method that everybody like most tool uses basically. And it is heavily rate limited and heavily 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 0365 account it will log in, attempt to get to teams and then use the search function in teams to look up users cross tenants. Again that depends on the tenants configuration but this is still extremely overpowered. You could easily do 300 lookups a second without getting rate limited or by giving massive amounts of false positives. And then again this is that's sort of the main bread and butter for the innovation module. Being able to use validate teams. And then you can pull domains from the hash. You can just apply your own list of usernames if you don't manual all since. I don't want to make it hard. I just want to make it a bit easier. In action using statistically likely usernames. So there's this awesome GitHub repo. I think I'll link it 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 not going to go through all of the options but the spraying module does spraying and you have a bunch of different options to use. So if you want to generate passwords only for seasons, only for months or if you only want to use the common stuff you can specify that and it will generate specifically. If you want to supply your own password list you can do that. I don't think I've seen this anywhere else but if you want to hit the I call it the US cloud. I'm unfamiliar with the exact name of it but some Microsoft tenants are under the .us domain mostly because they're government and if you want to brute force some support for that. As well as the AAD technique that Secureworks found that doesn't show up in logs. And then you can define sleep. Sleep means sleep marks delay. You can get push notifications. You can force spraying even though you get locked account in return. I think the spraying module is pretty standard with everything else. So this is what it looks like. You do dash or spray. If you don't give it any parameters it will set a default sleeping time. And it will start spraying. Then the exfiltration module. Now this is again the bread and butter of the infiltrations. 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 up 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 and 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 can give team filtration 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 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 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 can 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 have asked about. You can just pull that and you can put it out to Jason or CVS or you can just show it in the terminal. Okay, I am way ahead of time. Let's do the demo one external testing. So this demo is just sort of a use case, 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. So this is a start-up, 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 is. Every time you run infiltration you will need to give the configuration file with standard value. Can't see the top portion? Oh wow, okay, interesting. Two screens then, right? I'll probably break your setup. How about now? Awesome. Okay, cool. Okay, 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. The output path which is where you want to store all the data you potentially get from the infiltration attack or 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 or else you want to use, the D hashed API key you want to use and stuff like that. I'm telling you to go into the iteration module and that to take the user names from my own text file that I found using OSIN, right? I want to validate these accounts using the validate login method which is technically just attempting to log in, spraying basically right in the iteration module. So we'll do that. We'll find a bunch of valid accounts and then so can you see the bottom one? And then I'll try to go straight into the spraying module. So 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 route 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 of account so I'm letting you know hey, sorry you can't, you have to wait if you want to keep spraying. So that's what's happening here. 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 at some 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 BIFTAN who has the password of January 2022 and he doesn't have an MFA. So we'll move on. Now I can, I mean once you compromise an account then it's sort of the easy part. So now we can just do dash dash X fill. Kind of annoying that we can't see the bottom line. So I did dash dash X fill dash dash AAD and dash dash OWA. So AAD to pull the domain information from the graph API as well as users and groups. And to be clear that's all the users in the AAD tenant. I can pull once I got that access. And then dash dash OWA to pull the emails. And now something interesting happens. What happens is that a team infiltration 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 X fill and it puts them back into the database so if you want to go back spraying you can do that. So you know how all the users in the tenant automatically add it to your database and you can start spraying them. Again, some quality of life improvements. So it got, you can see it here, it got 134 AAD users appending those to the database of solid users. And if we go into the directory, we can see that we should have a bunch of emails as well. So emails that you expelled using team infiltration 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. And that's the external penetration portion of the infiltration. Thank you. Thank you very much. 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 dumped the cookies through some method. In this example I'm just using the 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 outlock in the browser, right? I know I'm bad. 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 leaving team filtration that cookie dump, that text file full of cookies. I'm telling you to exfiltrate all the loot and then you 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 cancelled 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 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 outputs from the teams 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 Odvar and said hi Odvar. Told him he was Batman and now Odvar knows I know 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 grab it out this way than to scroll through the thing forever. Quality of life improvements for sure. Cool. And then emails, one drive that files downloaded from the one directory. It keeps the same structure. Yeah, 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 on to a host, right? You would like to vertically move on to a host, right? And how do you do that? Well, so we have control over one drive, right? One drive has a bunch of files. One drive 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 one drive? Okay. 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 one drive that allows you to modify and replace files within their one drive 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 to his one drive and then this is the attacker's perspective. So in this example we already compromised the account of that individual through whatever means. And we run the backdoor module. The backdoor module will prompt you, hey, what you used to do on the target because you might have multiple users if you're lucky, right? That you can target. We'll pick out BIF and then the infiltration will access one drive 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 use to navigate that. You know, the individual here has a daily notes file in that it was very recently modified. In my mind that's the 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 add, index 5, copy as path and then go. And then infiltration will delete the file, give it a few seconds and upload it again. Now, you would be amazed how effective this is and you will also be amazed that there is no notification from Wanderer'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 and the next time he opens it, it's now an effective 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 Rust exec team who has been helping me polish this tool for well over a year so thank you very much and enjoy the last day of TestCon guys. I think I'm way ahead of time so I might just do questions here right? Questions on the side. Questions on the side. Thank you very much. Thank you.