Stories from the Trenches: Initial Access to Exfiltration... by Tristan Luikey & Jonny Elrod

Thank you, Pat. [Applause] So, yeah. Uh, my name is Johnny. Um, like Pat said, we're from Eliaquest. I'm joined by my colleague Tristan. Uh we're excited to show you guys uh a real world uh intrusion that we went through uh where uh the Finn 7 thread actor group used uh tactics popularized by Blackbasta to gain initial access. So uh just to walk you through like the structure of what the slides are going to look like. Um, we are going to go through the attack chain and we're going to show you uh what the threat actor did and we're going to show you how we kind of keep a hold of the like a threat hunter mindset even when we're going

through intrusions and like ways that we can try to pivot around and find additional threat actor activity. Uh, and then show you like potential mitigations uh ways that you can um sort of limit or completely stop a uh each phase of the attack chain. So, I'm going to hand it off to my colleague Tristan to get us started with the attack chain. Yep. So start over here. So typically with this attack chain, it starts off with the thread actors identifying the targets they wish to go after and then they will start beginning email bombing. So they'll send them thousands of emails throughout about one day to one week before the actual attack starts. And the

goal of this is to fill up their inbox almost making it unusable, making it think that well there might be an actual uh you know issue with their mail services or inbox and it's used for preex later in the entire thing. And you know that's kind of interesting too because like uh setting up initial access like that um you know where if you're looking at it from the like miter killchain perspective you have like the left side which is more towards initial access and then what the thread actor is actually doing right now to start us off is uh more towards the impact because they're doing like a subscription bomb attack. They're like like a denial of

service to uh block out this inbox. So, it's kind of interesting looking at it from that perspective that they're they're starting off kind of uh way over here on the right of the kill chain to kind of set up the pre-texting to get themselves way over here on the left to initial access. Yep. So, then this brings us to the actual social media engineering account. So, with 300 million active users, Microsoft Teams is one of the most popular corporate messaging applications that's used that can facilitate messaging between internal and also external communications. By default, it can support external communications including calls and messages. And this is where the opportunity begins for the attackers. So from here, they'll identify the

targets that they want to call, send them with emails, and then they'll begin to call them about a week or so after they become the spams. They'll typically pose as help desk or IT support, try to gain trust of the user, and then they will move on to attempting to get initial access from here. Yeah. And to be fair to Microsoft like it's on like by default it lets um external domains communicate with internal users but they do at least like give like we've got pictures here like what it looks like. It's a warning. It kind of tries to tell the user like hey you know this person's not in your organization like do you

want to let them talk to you? Um you know but you know in reality like is a real is popups for an end user to go through like a real security mitigation? Not necessarily. Uh it's kind of easy for the thread actor to kind of get around that. Uh here in this image, we've got an example. I don't know if you can read it. It's kind of dim, but uh they've like named their domain like help desk or their username like help desk to try to like get past the uh initial concerns that maybe this is external and the user maybe already kind of expecting help from help desk because of the inbox problems they're having. Um

thread actors do other things too to try to kind of alleviate the concerns of the user. Sometimes they'll like throw the word internal somewhere even though like it clearly says that this is an external chat. uh thread actors more recently have been doing things like using uh askkey check marks in their name to like I guess be like verified or something like that. Uh and these are like ways that have been very successful at getting the user to just click accept and then they immediately get a phone call. So how do we threat hunt for this? Well during the response process, it's important to keep a proactive threat hunting mind. Um what if they were to

switch the domains that they utilize? How would we catch it? How do we know that they're calling additional users? Well, during this testing, we found like I mentioned that they use help desk internal IP support and they also love to on microsoft.com domain which you can get for free through Microsoft development licenses. It helps persuade the user that they're you know coming from help desk and maybe internal and so they want to favor these words. So, you know, without focusing on, you know, maybe the exact domain that the product would be calling the users from, you want to focus on one of their DPs and actual, you know, wording that they'll utilize. So, in this case,

we'd like to hunt on the words help desk internal and then utilize this on Microsoft.com domains. And this is also important because during your intrusion response process, let's say we think that we've kicked the product actor out and they begin starting to call additional users, that could be an indicator that maybe they were actually successful environment. Yeah. Uh when we're going through an incident, um we try to keep our threat hunter mindset uh ongoing. So, you know, there's the needful that you have to do. We have to pivot on all the artifacts that are involved. like if there's a compromised user or compromised host, we're obviously going to do like pivot searches on there to see uh what

everything that's going on. But we want to try to keep a broad approach as well uh to try to pivot on not just like these artifacts that are involved, but also uh like the TTPs that the thread actor is using that helps us uh expand our scope and like discover potentially additional assets that are also involved. Um, but it also during the intrusion will will set these up so that we can try to get um like as close to a one to one like 100% true positive kind of a detection for current thread actor activity. Uh, and what that does, we can kind of set ourselves up later when we're building these up. So that uh when

we get to the stage we're like we've done XYZ now we think the thread actors kicked out of the environment they don't have access anymore. Uh we should have like silence from all of these special rules that we've made for the thread actor activity. And if we don't have silence, then potentially the threat actor are still in. Maybe we've, you know, our remediation efforts earlier have helped, but now they're kind of revealing themselves uh and the other ways that they have access to the environment and we can maybe proceed to kick them out further. Um but yeah, we have found that um keeping the threat hunter mindset throughout an engagement is very helpful um for those reasons as

well. So in terms of mitigations for this, the best thing to do is just turn off that default configuration and block all external communications. However, lots of organizations actually utilize the external team chat function. So, if you do, it's recommended to compile a block list or an allow list, sorry, and you can set that up so that only allow and approved domains are able to communicate from external domains. Yeah, it's it's for most organizations like potentially very easy to mitigate like this exact um like abuse of teams because you don't have to allow external uh organizations to communicate with your users. Uh some organizations do use that feature heavily. We've had customers that have like hundreds of allowed domains that

they need to communicate with and like there's just no chance that they like personally know that all these domains are safe uh cuz there's just so many. So they've got this like very um you know like kind of loose giant allow list uh and they've still basically got this vector. It's better than nothing to have like the allow list because uh unknown domains that the attacker like spins up like this very easily, they won't be affected by that. Um, but there are cases where thread actors do compromise domains and they do use them for like teams calls and things like that. So, it's still possible. So, you still want to do like we talked about like the

monitoring and things like that because it's still a vector and you want to make sure your users are aware like fishing is possible through like things like teams and not just emails. Uh, and then if you are like experiencing an active engagement like where thread actors are actually targeting your users, maybe consider turning it off anyway temporarily uh and just blocking that outright and then turning it on later. Yep. So this is where we get to the initial access tester. Um so you would traditionally think that it's pretty difficult to go from a phone call you know onto access to an endpoint. However software which is remote monitoring and management software. Windows has a builtin remote management feature called

quick assist that actually has a hotkey and it's control windows key plus Q. It'll pop up a prompt. From there the thread actors will you know be on the call with the user pretending to be help desk support. And this might be, you know, a pretty normal process for users in an environment having help desks connect to their computer and actually troubleshoot issues. So it may seem normal, especially with all the pretext of the email bombing and claiming their internal help desk support. This, you know, is a pretty successful attack chain. So from there, they will then, you know, provide their information to connect back to their computer and they will then gain remote access onto the

system. Uh yeah, this this isn't like a new setup even like the idea of the thread actor like being on the phone with the user and like hey let me in like that's not new that that's actually kind of old. Um in the past it's been more common to see this through like scareware ads which are like advertisements that you see in your browser that say hey you know your machine is seized by the FBI or like you have malware something like that. Uh internally we call these mouse jigglers, but it's the idea to get the user to passively kind of call them and opportunistically say, "Hey, uh you know, you've called me. I know you have

malware on your machine. I need to remove it. You need to let me in right now." Uh and then they get in. And usually they, you know, do like some hocus pocus on the machine to get the user to think that some service has been rendered. You know, maybe they run like SFC scan now or like they defrag the disc or something. They remove some mau uh and they try to get them to like pay for that. Um, same idea, but the novel thing here is the use of like a Microsoft Teams service to to take it from an opportunistic like I'm waiting for users to call me to a targeted approach where I say, "Hey, I want this

user in this organization's endpoint. I will just call them and jump onto their machine." It should be extremely difficult to do that, but uh these different applications that the thread actors are able to use like quick assist, they make it like seamless. So, you can very quickly make that happen. Right. So in terms of thread hunting on applications like quick assist in particular hunting on something like quick assist.exe is not viable. As you mentioned it's a native Windows binary. So if you were to run that you would get a ton of results. Um so with some quick Googling we found that the um domain RDP relay v3 support.microsoft.com actually indicates an active session. So it means that the user was connected to

a a real quick assist session at one point. So hunting on the network traffic and using network telemetry um we'll be able to reveal users who have actually had active connections and may be able to find additional targeted users who had had remote access. So in terms of mitigations just blocking quick assist you can do not allowing it to access and be utilized blocking the domain we mentioned earlier will not allow the network traffic to go across the wire. therefore you know disallowing the sessions from being able to take place and additionally a very important thing we found that thus will attempt to pivot to different RMN solutions throughout the attack. So say one doesn't work

they'll try another one so the best thing to do there is to just only utilize one RMM solution for your organization and block list all the other ones it's the name of the game is making it more difficult for the thread actors to get in. We found that you know they might try a couple and if it doesn't work they will give up and move on to the next target therefore you know stopping the organization from actually being compromised. So whilst the user has that active quick assist session they can see everything that the thread actor is doing. So if they were to download you know impact it on the system and try to use it they

would see what they're doing and obviously that's not you know fixing their email. they might question what's going on and then try to disconnect the session. So the name of the game with the factor is getting off of the RMM session as quickly as possible. And there's two cases in this attack trying to walk through. In the first one, they went from the phone call onto the endpoint with persistence in 4 minutes. And the second one, it was 7 minutes. Personally, the shortest I've seen is 2 minutes to 30 seconds. So this brings us into the malware that they used. um in particular they use something called DL site loading or search order hijacking and this is when

software engineers do not specify the exact path of DLS that are being loaded into the binary when it's executed. So this gives an opportunity when Windows does not know where a DL is, it will check its local file first. So you're able to include that DL into the process path that it's actually executing in. It will then load that DL if it's name the same thing. So in this case they use a well-known one called one drive standalone copy which they included in a file called pack.zip. They copied the zip file onto the endpoint via the RMM session. They then unzipped it and then executed the file which automatically set persistence via the registry key and

then executed the payload via the DL. So in terms of um search hijacking here, you know, it's very awkward thing that's going on. you know, if they were to just run something and disappear, the user might not think that something had been fixed, and it might tip them off with being something that was suspicious. In this case, you can see here when they execute the payload, it actually says, "Hi, I am okay." So, this was done to almost trick the user into thinking, oh, you know, my computer's all right now. Everything's okay. My computer's telling me that I'm okay. And and then, oh, miraculously, the spam has stopped and my inbox works. Oh, okay. It support

must have fixed my computer. But in actuality, they're just have sitting consequences. So initial access doesn't work. Let's say you get onto an endpoint, you do establish that persistence, but then you start doing some recon and you find out that you don't really have the permissions that you like. Well, what are they going to do? They're just going to go back and try again. In this case, they did a total of two users. The first one they got, they did not like the access that they had. So then they moved on to the next endpoint where they fished an admin user who had remote PowerShell rights. Once they figured it out, they said, "Oh, this is comparable

for our lateral movement techniques and they began their lateral movement." Yeah. Uh we found that the attack chain uh for these is they're not completely uh linear. It's usually like there's a big loop here at the beginning where they keep teams fishing users and eventually they they kind of decide it's time to move on and they move laterally into the environment. Um, anecdotally, uh, most of the users that go through this process of getting fished like this seem to, uh, get suspicious right after they hang up the phone. I don't know, it's like a quirk of human behavior or something. Just keep accepting what's going on until there's no one watching. Um, but most commonly like teams start

to get engaged around this point when a threat actor has already kind of like let into the door of the environment. Um, so here is a quick um attack timeline that we put together of the the two fishing attempts that were u here. And you can see like they pretty quickly in this one get to fishing and then actually trying to break out of the endpoint. And that's where they like not only do they compromise it, but they start looking at other hosts in the environment and saying, "Hey, how can I hop?" Um, and then in the second case, they kind of just like landed on an admin and so they they were very uh able

to very easily successfully move into other hosts in the environment. Um, so go ahead and switch Yeah. So, mitigating something like a thread actor getting admin almost immediately uh it's it can be kind of difficult. It requires uh more of a broad architectural approach. So, uh it brings to mind something a term called tier zero architecture which is a term uh kind of made by Spectre Ops uh the people who made Blood Hound which is a tool that kind of helps you map your network and define like attack paths. So, it's the idea that you have your tier 2 layer which is the least secure devices in your environment. things like workstations, uh things that

can provide initial access to a thread actor. Um so anything that can be like fished would be like a tier two. And then you have like your critical assets, things like domain controllers primarily being the example. That would be tier zero. And those would be like the most uh secure portion of your environment. The idea is there should be no path between a lower security tier and a higher security tier uh that could let an attacker um kind of pivot and there should be like birectionally really no access. Uh the common example is like RDP um user caching. So like if someone's a domain administrator and for whatever reason they decide to help someone out and do like help desk or

something and so they log on to a user's workstation. That's the idea of a tier zero account logging into a tier 2 device. So they log off and then maybe a week later thread actor compromises that tier 2 workstation. They can see that the domain control or the domain admin was like logged in at some point and potentially even get their credentials just cuz they touched that tier two device. So that's an example where like you want that separation uh because you know it makes it that much harder for the thread actor to actually um successfully like move laterally and get anything out of even gaining initial access. So this is what it looked like when they

started to break out the thread actor you know they already had admin so they kind of pivoted a couple layers deep into the environment and they decided on this one host that is they kind of chose as their primary pivot point. uh and they took that host and they kind of just started aiming uh remote scheduled tasks at these other hosts. So they were creating two scheduled tasks on each of these computers and one scheduled task was to uh get a batch script that was kind of preparing the one drive standalone updater on these hosts and then the second one was creating a new service that would kind of run and sideloadad the one drive updator. So you

have now a bunch of beacons on all these hosts. Uh the interesting thing here is uh they're all the same beacon. So um if some of you are familiar with the idea of like C2, command and control, um it's the idea of like an agent that's running on an endpoint that can reach out to an attacker controlled server and kind of ask, hey, what's my next command? What's my next command? And it doesn't over and over until there's a command. So the idea of an egress beacon is uh that's the beacon that's going and actually directly reaching out to the command and control server. um thread actors for like opsec reasons, they want to hide

the C2 server. They don't actually want the defenders to be able to find it uh for a couple reasons. For one, you can block it, but you also can identify other hosts that have beacons. So, it's more common for thread actors to use like peer-to-peer beacons as much as possible. And that's the idea of routing the C2 commands between the different computers um all the way up to the the few egress beacons that are in the environment and those handle the direct communications with the C2 server. They didn't do that at all. In this case, it's they didn't really seem to care about OBSC. They were all reaching out. Um, so just interesting. They weren't

like interested in establishing long-term persistence. They just wanted a quick beach head so that they could access data and and move on. Um, so some things we could thread on in this area. Uh, I said they were doing scheduled tasks. So, um, I said we want like 100% 90% TP rate for like these ad hoc kind of threat hunting rules we're making during an incident. Um so the the one we kind of came up with here um if any of you have heard of uh reax regular expressions it's like a pattern matching kind of language. Um the thread actor in this case used like basically the same kind of a name for their scheduled tasks. They had like they called them

all one presumably to be like one drive or something with a couple of numbers and a letter. Um so you could like find all the thread actor scheduled tasks um through that method and it's like that's that's pretty narrow. Um, you might even say that that's like an artifact pivot. Um, some layer in between thread hunting and artifact. Um, but you know, still a good idea to kind of throw out that feeler to see if they're making any any more scheduled tasks. Um, some more like broad ways to thread hunt on scheduled tasks, uh, is like the idea of they're using they're running batch scripts through a scheduled task. Depending on your environment, you might do that a

lot, so that might not be a great indicator. uh the idea of uh creating Windows services for a scheduled task or more interestingly the idea of uh creating scheduled tasks on a remote system through literal remote PowerShell not through like a group policy which would be like more common. Um some of these like might be more noisy like that last one might be actually harder to find in the moment. You don't want to be like during an incident like spending a lot of time like researching how would I do that? Um so you know you you need to be spending your time wisely. Um but just some interesting threads to pull on. you want to have as many as possible

that could potentially have good outcomes for you. So, uh the thread actor after they kind of established their beach head, they started using RDP. Uh for those of you not familiar, remote desktop protocol, that's the built-in way to uh basically have mouse and keyboard and screen for a remote computer. Thread actors, they love RDP. Um there's like the stereotypical idea of like a hacker that's like very, you know, terminal like keyboard warrior. Like that's often not the case. We found they they love like the tactile regular control of computers just like we do. Uh and that was the case here. Um they just like started pointing at machines and saying hey login let me see what's here.

Let me see what's here. So you know it's kind of the same idea for like mitigating this. Um so when you're talking about thread hunting uh it's interesting here because they actually proxied all of their traffic into the network through the one drive beacons. So like the C2 things that they've set up, they were sending like RDP traffic through the one drive beacon onto these remote hosts, not directly like normally on the host. So that actually looks like in like an EDR or something like that. Like you can actually see one drive sending 3389 which is like the port for for RDP uh that traffic. So like very suspicious traffic. Um you know, we found actually it's kind of surprising

if you put in like how many processes are like sending me port 3389 traffic. It's actually a lot and like you have to like kind of explain why each one is doing it. Um so like for a threat hunting um area you can like look at potentially the idea of weird processes that are sending like lateral movement traffic. Should one drive be sending me SSH traffic which is what they did in this case as well as like RDP or like remote PowerShell. Pretty weird. Um and you can do like you could take it a step further. You could be like what what if I can like get not just traffic but like confirmed lateral movement. If there's

lateral movement, I'll see an authentication log on the remote system, right? If it's a remote PowerShell, I should see like a type three log on on that remote machine, right? Or if it's like an RDP, I might see a type three, I might see a type 10. So I could correlate those backwards and say, hey, what's the source IP? What's the process that's doing that? What are all the processes that are making basically pivoting in my environment? Um, that would be a way basically of discovering if the thread actor had not used only the one drive beacon, but had other beacons in play. Uh, in this case, they didn't though. So, um, you know, we kind

of harp back to, um, like this tier zero, um, idea for mitigations. So, it's actually pretty hard to see. It's kind of dim. Um, but this is like expanded view of that tier, uh, tiered infrastructure. So, you have over here your tier 2, like your least secure devices, so like your workstations and things like that. uh your tier two, tier one would be like um your you know servers but not necessarily ones that like can actually modify the environment. So like maybe data plane not control plane but then up here you have your tier zero your critical assets and then what you can see here is like there's these red lines that kind of draw uh access between the two layers or

the three layers where you have like a full attack path from tier 2 to tier zero and that's like that's how the thread actors are going to completely own your environment. Um, so a couple of ideas here like the thread actor kind of started off with domain admin. So like you're kind of caught on your back foot u so to speak. Some ways though you can kind of mitigate lateral movement um are like uh you know getting as much human interaction as possible. So like should they be able to just RDP into a host maybe but maybe not if it's a critical host? Can we put like MFA in front of it? That way if someone's RDPing the

actual account owner will get like a ping on their phone. Hey allow this RDP. Hm. That's not me. Right. So um some other ways are like reducing attack surface. Do all the hosts in my environment need uh like remote RPC to be on or like WinRM or like remote PowerShell Wii. There's a lot of ways to uh move laterally to a machine and uh you know a lot of in many cases like you know your network administrator may like New York say of course remote PowerShell we need that. Um but like is there another way to do what they're doing? like can we use something more official like group policy or in tune that's not

as like direct and we can kind of reduce uh even that interface being an option and that's a way like that a thread actor can like have administrative priv privileges but not necessarily be able to just pivot onto any host that's there just because it is there. Um, so yeah, in the next stage of the attack, they're kind of already peeing around and then they get to like their hands-on objectives where they decide to download uh a file transfer tool and point it at their infrastructure and literally take some files and like basically drag and drop them out of the environment. So, and they like they do this interactively. they they like go to the

browser, they download Win SCP, which is the tool they use, and it uses like SFTP uh or like secure SCP and just like takes the files out like very low bar here. Um but like if it works, why not just do that? So for uh mitigations, so like there's the obvious mitigations of like should a file transfer protocol be allowed unrestricted outbound? Probably not. Should we be allowing like known file transfer tools? Um, if our like admins don't use them, probably not. Um, but like, you know, there are millions of there's like many many ways that you can excfiltrate data out of an environment. It's impossible to lock the ball down unless you have like an air

gap system. Um, but it doesn't have to be this easy, right? The more that we can do to kind of like get the thread actor off of their playbook because they've got like a list of things that they're going to try. Uh, maybe you block SCP and they're like, "Oh, I don't have SCP. I'll use curl." and like they realize, oh, actually they've blocked the entire protocol. I can't use that. Now I have to, you know, figure out something completely different. So now, you know, they're spending longer in your environment. You're basically building up the attrition for them to be here and they're more likely to make mistakes, uh, trick up trick up like detections and things like that. So

you're making it more expensive basically for them, uh, and more passive for you to just kind of, uh, kick them out of the environment. So after they kind of steal the data, they add their an account that they control into the ESX admins group. So for those of you not familiar, ESX and ESXi, they are hypervisor softwares. Um a similar one is like HyperV. So hypervisor softwares baspin um infrastructure because they virtualize um machines. So the idea is like if you have a domain controller, odds are it's not like directly installed onto that hardware, that server. Uh there's like probably many domain controllers that are being virtualized onto it. So it's like kind of a juicy target, which I'm kind of

hinting at my next slide. But um so this is around the time that the thread actor was kicked out anyway. So we kind of have our assumption about what they were about to do. Um but like they added themselves to that ESX group. Should they be able to add themselves to like such a critical group? Probably not. Um so like how can we mitigate that? So again like they have admin so like there's there you know what can we do? There are some things we can do. So like uh you know hypervisor infrastructure ESX that is definitely like tier zero asset and like so should the group be a tier zero as well. Anything that's

giving access to it is a part of that. So again like human interaction like maybe MFA for adding to certain groups right. Um, and then like the idea of just in time access with like privileged access management. Just because like you know someone has domain admin, does that mean they need to be domain admin all the time? Uh, maybe we can set up something like you know you need to be domain admin for 10 minutes or an hour and then it expires, right? And then you know have MFA involved in that as well. So there are ways that you can kind of put walls up even for like if a thread actor somehow does compromise a domain

admin account doesn't have to be like they now have guaranteed full access. So, uh, we assume that the thread actor was targeting the ESX environment for, uh, ransomware. They were going to lock it up. Uh, if you can't tell, this is just a picture we found online of a point of sale system receipt printing out a ransomware note. Um, so I didn't think you'd be able to read it, but um, yeah. So, you know, we didn't get to see them we didn't see them actually do that because they were kicked out, but that is the assumption because it's like a very juicy target. Uh and the idea is like the victim is like so much more

likely to pay a ransom if you completely get like you know basically what's underpinning all of their infrastructure. So if they had been able to um pivot into the ESI DSXI environment I would say that this is uh something we can mitigate by not having a flat network. So like for mitigations for this um you know it would be like the same idea like that's tier zero should you know any old workstation be able to go straight to ESX. I don't know if that's how they would have done it or where they would have pivoted from, but like the idea is like a privilege access workstation or like some kind of choke point. And a privilege access

workstation is like the idea of a device that you use that is like so reduced attack surface, but that's the only device from where you manage critical assets. So like the idea is like you don't even have like a browser or email on that thing because you can't be fished or like driveby downloaded nothing. like it's very difficult for a thread actor to compromise privilege access workstation and that's the only kind of device that should be touching our critical assets. Um so that's the end of the attack chain. Um thread hunter was kicked out by this point. So uh you should have like some insights into uh kind of the mindset that we keep um when we're going through an incident

and like keep that thread hunter mindset. So thanks all for joining and I hope you enjoyed it. Heat. Heat.