Tyler Casey - From Intelligence to Triage: A Guided Threat Hunting Safari

All right. Hey everybody. Um, >> just about two, so I'm just going to go ahead and start. Um, so yeah, today we're going to go on a safari, a threat hunting safari. So if you don't know, um, a guided threat hunt is called a safari. It's not a term that I made up. It's the real term for it. Um, so that's what we'll be going on today. This is not going to talk about AI at all. Um it also I am a big fan of technical talks. That's what I like. So this is going to be a technical talk. We are going to um have I have already done this but going to have an adversarial emulation of

ABT33 and then I'm going to show you how to thread hunt through that. Um so yeah with that let's get started. If anybody's got questions at any time feel free to interrupt, put your hands up. Um, we'll see how we do on time. With that, I am Tyler Casey. Um, I am the lead detection engineer over at Scythe, which is an adversary emulation platform, um, and the deputy of Scythe Labs doing defensive security operations, which is TCO, um, for a little over 10 years now. Before I came to Scythe, I was on a cyber protection team just like the gentleman that was here before me. Um, a different one as an active duty marine and then as a

federal civilian. I did that for about 10 years. Uh what a CBT does is they do targeted and threat hunting throughout the throughout the world. Um worst place I've ever been, Dakota, Africa. Don't ever go. So with that, our road map for today, what is threat hunting? We wanted to learn about our prey a little bit. And yes, I'm calling them prey. While they are predators in this sense, we are hunting them. They are the prey. Um from there, we'll get into the hunt process a little bit, then the actual safari itself. So, a little bit of not technical stuff, a little bit of kind of talking around it, and then we'll get into the into the actual hunt, and then

last, we'll kind of redo the the uh the kill chain. Couple takeaways and pieces like that. Sure, I didn't miss anything. I think that's it. Okay. Uh so, what is threat hunting? Is anyone here a threat hunter or perform some kind of threat hunt? 1 2 3 4 5 6 Oh, a thousand. Oh my god, we have so many people here. Um man, this room's huge. already up top too. Tight. Um, yeah. So, threat hunting at its core is hunting for the threat, right? Pretty self-explanatory. Um, there's two ways to do it. Proactive and reactive. Obviously, a proactive threat hunt, which is what we're going to be talking about, is going to be better because

you're going to look for things before you are alerted to them. On the other side, you have a reactive threat hunt, which is when you're going to actually react to something, right? You got an alert, a user has something uh something's on fire, something like that. There's three different kind of methodologies, I guess you could call them, into threat hunting. Intelligence base, which is what we're going to be doing today, which is where you take some some intelligence, either you gathered or maybe you have an intelligence team that's given it given it to you. That would be great. Probably don't have that. So, it's probably on you as thread hunter to go ahead and find it on your own. The next up is

behavioralbased. that is where you are looking for things that are different. So, anomalies, pieces like that there, it's a little more of a broad scope. Um, but that's a secondary kind of threat hunt. And then a third is an entity based, which is really based purely around an entity of some of an entity of some sort. Typically, that's going to be like your crown jewels or something like that, right? It's going to be your domain controller, your your CEO's box, whatever is most important that you're monitoring all the time and doing a thread hunt just on that. Um, like I said, today we want to be focused on intelligence based, but it'll kind of naturally kind of blend into the other

methodologies as well.

You guys ever seen Brooklyn 999 where Terry Cruz is talking about if you can take a sip of water and everyone's looking at you, you doing all right? So that was a little test in case everybody It's a good show. Check it out. Um, so the threat hunting process, there's essentially five steps into doing a threat hunt. While different pieces of your threat hunt are going to essentially restart you over again, that's okay. But it's still going to be essentially the same same five steps for all the threat hunts that you're doing regardless of which uh methodology you're doing, intelligence or behavior or um entity based. So the first step is your hypothesis. Your thread hunt should

start with a question, something you are trying to prove or disprove. A theory of what you think is happening. And we'll do we're going to do exactly this here here in a little bit. So I won't talk too much on that. But you want to prove or disprove some activity that is happening in your environment. That's where it starts. You want it to start with a with a hypothesis, with a question, with a theory. So that way you know, is this question answered? Yes or no. You can aimlessly threat hunt forever, right? You can you can thread hunt all the time. The only way you're going to be able to tell if your questions are answered is if you have

one. Next up is collect data, right? So you have a question, something that you think is happening, a theory of of some sort, you need to go and collect the data and then obviously go ahead and analyze that data, see if there's anything in there. That data is going to be your your logs, your pcap, um, you know, different pieces like that. And then the analysis is going to be just looking for anomalies. Most things that are anomalous can be explained, will be explained. Um, any good admin script looks like malware, right? Right? It's B 64 encoded. It's running at weird times. It's got admin creds. It's got variables. All kinds of stuff. That's the that's the analyze part. Most of

that you're going to be able to explain away, right? But let's say you're in there, you find something that can't be explained away. It needs some further investigation. That'll take you into step four, which then you're going to do a real deep dive in the into the investigative, excuse me, investigative piece and really kind of see what's going on. Is this just an anomalous behavior? Can we explain this? Is it is something communicating to somebody? Are processes being spawned? You really need to do a deep dive. This would be the part step four is probably where you would maybe bring in uh some of your team members or pieces like that and be able to really do a full investigation

into it. It's really easy to sound the alarm. If you sound the alarm and you don't have the evidence or you don't you didn't do an investigation, you're gonna look like a fool, right? You need to make sure you do a thorough investigation into it. And then the last step, everyone's favorite, the refine, the documentation, the documentation, drawing up gaps, what went good, what went bad, doing a hot wash, lessons learned, pieces like that. Everyone's favorite piece is documentation, right? Everybody loves that. I guess maybe this will be about AI. You can use AI to do your your documentation, but the documentation is really, I think, very overlooked and hated. Without proper documentation, no sustainable change is going to

happen. Right? If you do this whole hunt, you find all this malicious behavior, all this adversary activity, and you didn't document what happened, how it happened, how you can stop it or find it in the future, it's just going to happen again, right? Documentation is so important. Um, please don't overlook that. Okay, the abstract. So, now we're going to get to know our prey. Again, we're going to be hunting for ABT33. Goes by multiple different names. Peach Sandstorm, elfin refined kitten. The other one, um, you know, everyone's got their own different different things to call it. It is an Iranian statebased or state sponsored state based essentially the same thing, right? Um, APT, advanced persistent threat, also known as the

IRGC, which is the intelligence arm of the Iranian government. They've been active since at least 2013. And their primary mission, as you could probably imagine, is intelligence gathering and espionage, right? A lot of ABTs, state sponsored um actors, they want to break into other governments and other pieces. See all the different target sectors that they um that they attempt to break into over there that their targets are. They want to steal your information. One thing that is a little different about ABT33 that you don't see with a lot of um ABTs or really kind of state sponsored uh threat actors is that they will be disruptive. They will utilize some m wiper malware. They will clear systems

um like the gentleman before was talking about they will target OT environments and burn that sucker down. That is not typical adversary behavior. Um which is extremely dangerous, right? essentially you're you're performing acts of war um on another nation from a nation. Um so that is something that definitely does kind of take them um a little bit of a distinction from them with some of the other ABTs out there. That's yeah very very interesting. Um very interesting that they do that while China, Russia, places like that. No one else really does that to America. Could be because of stuckset but that's a different problem. Um so in that that's kind of the background. So let's get into the

actual Safari itself. So with this, we're going to start from a single CTI report. From that report, we're going to pivot off of the artifacts that we see in there and then kind of go through the whole the whole kill chain that way. Um, in this before I get started all of the resources and the detections and signal rules and all the stuff like that, I I have available I have a link at the at the end the last slide. Um, but feel free if you want to take pictures or do whatever, um, feel free to do that as well. So, the specific campaign we're going to hunt today is the Tinkler malware uh campaign. This was reported

by Microsoft in 2024. So, a little bit older, but if you guys have done any kind of um intelligence gathering, you see that TTPs often kind of stay the same throughout um throughout any kind of period of time. So, 2 years old, while it is a little bit older, is not really too old to be able to go through this kind of threat hunt. Um, in that campaign, the tickler, uh, which is the real name, which is funny, but it is the real name. Uh, tickler is used as a multi-stage backdoor. Uh, it drops a decoy PDF while executing a secondary staged uh, DL called sold.dll. From there, the initial payload utilizes a file called um, whatever. PDF.exe

to disguise the executable as PDF. So, doing some file masquerading with a double file extension. And then it it'll run some persistence where it'll run a batch script to set the run key to a to the value of SharePoint to attempt to blend in. And then from there going to harvest some credentials using lasagna enumerate active directory with ad explorer. Deploy any desk which is a remote management tool to that to that victim machine to that endpoint. compress the um all of that data that it that it gathered and then Xfill it out. Um and then piece here that I wanted to point out each of these procedures we have on here are essentially what we're

going to hunt through, right? We're going to hunt through all of these and kind of prove or disprove if that activity happened. Um one piece I want to hit on is that we are not saying things like we're hunting for credential gathering or hunting for lateral movement or we're hunting for ingress tool transfer, pieces like that. We're hunting for double file extensions, registry, run key persistence, pieces like that. You need to be specific in what you're looking for. That's what differentiates between looking around and and and hunting for something, right? We we're going to hunt this. We're not going to take a stroll through the forest on our safari. We're hunting for this activity. You have a question,

sir. >> Not to be semantic about it, but it sounds like a difference between a verb and a noun. Like you're looking for an object. >> Yeah. Yeah. looking for the kind of reason why I I say that is because these are often generalized into looking for TTPs or or tactics, you know, something like like a like a miter tag and bingo or something like that where it's like, oh, we're hunting for 1059, which is, you know, like process creation uh with like PowerShell command prompt bash pieces like that. It's great to hunt for these kind of generalized tactics or techniques. I always forget which one is the bigger one. But you really want to hunt for this for an

intelligence based hunt, you really want to hunt for the specific activity that the intelligence is telling you, right? >> All right. So from Z from the CTI, which is uh cyber threat intelligence, which is the Microsoft report we have down here at the bottom. You can just Google peak sandstorm Microsoft and it'll come up. Don't type this whole thing out. Um but from there from our CTI to our hypothesis our hypothesis is going to be that the um if a33 has operated in our environment we should find a binary with a double file extension pdf.exe written to disk. That's what we're going to look for. Right. That's going to be our f Oh, sorry. Skipped a bunch of slides there

on

Sorry, I had to scroll down on my notes. So, with that, we're going to look for a um gun. Sorry, everybody. I didn't realize that the slide moved. There we go. So, our hypothesis is that we're going to hunt for that that double file um that double extension file name. That's going to be the first thread that we're going to pull, right? And that hypothesis is going to give us a testable claim. if the threat actor was there, this telemetry should exist, right? And then from there, we'll further expand our hunt out um in an attempt to identify some further um adversary activity on our endpoint. So, our detection approach is going to be a

SQL rule that looks for file creation events where the target file name ends with patterns like PDF.exe, doc.exe, JPEG.exe. We're not looking for the file names to be the same because file names can be changed very trivally, right? Trivially, right? It's very very simple to do. I mean it it's yeah it's very simple to do. Whereas that that double file that double file name extension um is going to be a little more concrete, right? That's their kind of TTP that they're utilizing to do it. So that's what we we want to hunt on. Hunting for file names is not a good detection again because they can be changed really with no effort at all, right?

still good maybe to kind of have it have your automated tools will kind of feed that to you, but from like a detection standpoint, not a not a high fidelity alert. Maybe I should have used the clicker. All right, so this is where our hunt is going to start. And so we're looking at event code 11, which is file creation in in Sysmon. Most of this lab is going to use Sysmon. Um, all free native tooling is what we're you or not not native, all free tooling is what we're going to be utilizing on this on this hunt. Right? So, we're going to be looking at event code 11, which is file, and we're going

to be looking for the target file name to contain multiple double file extensions. That CTI report, like I said, it says that it should be PDF.ex, you know, something PDF.exe. Um, but you could maybe modify that a little bit to be JPEG.exe or something.exe. So, that's why we have some of the other ones in here. start a little a little bit broad, but still kind of focused in on that double file extension. Um, either way, we have a hit on this and we see that we have an executable with a double double file extension. So, our hypothesis is confirmed. So, we'll make a note of the image that spawned, which is A1.exe. Image um image and parent image are the

same as process or parent process. That's just the vernacular that's utilized in the logs. It's called an image. Um, so now A1.exe exe is what spawned it. That'll be something we want to kind of pin to the wall that's going to go on the whiteboard, right? We're going to have that. We know the host name of this of this victim machine, supposed victim machine, because we're still uh doing our our analysis. Nothing is confirmed yet, right? Nothing is confirmed. We just have a double file extension, which is anomalous and is pretty strange, but we're not setting off any any red flares or anything like that. And then we know the file name. Um, so we'll take those bits of

information and we're going to use that to further our hunt. So all the slides are going to kind of go like this where I have a Splunk screenshot of the actual query and then some actual information like this because the screenshots are probably kind of hard to see, right? So um so we'll break the search down a little bit. The file extension itself matches on that Microsoft report on that CTI that we saw. So we see that it is a binary disguised as a PDF again using that double file extension. Um, a couple pieces of here. Couple pieces of here. A few pieces here to point out that I I think are are worth it. Um, is that see this full path? It

says ABT33, right? It could say anything. It doesn't matter what it says. It it can say anything. But the point here to look at is that it's in the downloads directory which can um which ob I'm not sure what the experience of everybody here is. So, excuse me if I'm overexlaining something, but you will often find that tools or binaries or different pieces like that are staged in downloads, temp program data, app data, local app data, pieces like that because they're universally writable, right? If you're if you're writing something inside of system 32 or something like that, you need to have administrative privileges to do that. So oftent times if you see something in a universally writable

directory that is something that maybe you should take a look at because it it's there for a reason. Um also in downloads it could be in downloads because somebody clicked a link and their default file location for downloads is downloads, right? That's pretty common. That's a pretty normal thing. Um so the file location is pretty interesting. Um it being inside of downloads. Obviously the ABT33 piece of it kind of gives it away, but this is from an an emulation right? Um, let's see what else. Sure, I didn't miss anything on this one. Yeah. So, from this one, we see a couple of anchors on here. See the file, the host, and the path and the path. Our

next move is not to keep running some queries on on this file, right? Right. We need to now widen the aperture out now that we have something that we that we can anchor on. Now we can spread it out using this as kind of our genesis event to then expand out and see what else what else is happening. Right? So with that going to go to the next one and then we're going to scope out the activity. Right? So what I mean by scope out of that activity is before we had that single query that's looking just for those double uh double file name extensions. You guys are talk a lot. Get the burps. Um, so we want to we want to spread it

out a little bit so we can see what else is happening on this machine at that time. So in Splunk, it's pretty easy. Um, you can click on the on the time and it'll give you like a plus or minus. So this is plus or minus 5 minutes. So 10 minutes in total around that file name um that file file being written to the endpoint. Right? I've also specified on here the the the victim host name. again to we want it to be a little broad but we want to stay we want to use the facts that we that we learn and that we that we gather as a basis of the hunt right so if you were to not have a host name

on this and just give it source uh the source of sysmon and look at all of your machines you're not going to find anything you're just not so it's while we're kind of broad broadening it out you don't want to go too big too fast right um so like I said this is going to be a 10-minute uh time frame around when that file was written. We want to see what other events happened and um think of these other events or event codes as as spokes, right? So each of these spokes were or you know spokes or threads or however however you you want to phrase it with with that genesis with that hub being that double file name. So all of

these are surrounding that event. Um you have it in here. So now you know where where do logs exist and what can I look for next? Um, some of these are going to be a little more urgent than others. Of those, I think process process creation, which is going to tell us what was ran, right? The file create just like we saw with with the file being written to disk. That's a good one. Network connections to see who it's talking to, internal and external, as well as some registry values. Setting registry values probably means that something was installed. Um, it's a very very common form of persistence. Um those are probably the top probably the top event

codes that you can look at. Uh typically I like to start with process creation, right? If I think of network activity as a hypothesis and the host activity as fact, right? I'm going to tell you what really happened on the endpoint um and all of the events that are surrounding the different uh processes and binaries. Excuse me. And then one other one, honorable mention, uh, process access, which is going to tell us what interacted with a running process. 5 minutes. There's no way. My talk is 50 minutes. >> My bad. Like, brother, come on. >> I was like, all right, guys. Uh, we did it. >> So, in there. Yeah. >> There we There we go. Uh, yeah. So, the

process access is going to be really important if if you can see it and we'll really talk about it here in I guess less than 5 minutes. Um, but here in a couple minutes to really kind of show why it's so important. Um, have here as a note, this might seem kind of trivial to do something like this, right? You're like, oh yeah, of course you want to see what all of your events are or pieces like that. Has anyone done like an incident response or like a real threat hunt? It talk about stress. It is absolutely stressful especially if you like I said before um I worked at Scythe. I I I was a Marine. We did um

engagements, incident response on government networks all over the world on some really really important stuff. All that they want to know is are we safe? Did you find them? Why didn't you find them yet? Having this to kind of refer back to is really going to be a a game changer, right? It is incredibly stressful. Um, and it can take days or weeks or months or even Yeah. but this will be there for you. Um, and that way you'll be able to refer back to it and follow those folks. Follow that thread. Write everything down as soon as you see it. Even if it's just a a a screenshot. So, hunt one, I think we have five five

quick hunts that we're going to do on this. So, hunt one is going to be that process creation. So, again, we have it set in our time range. In a real engagement, adversaries have dwell time, right? So that's g, you know, this is an emulation. This is a guided hunt. Your times are going to be different. It's not going to be as clean cut as it is up here on the screen. But anyway, um, you want to see the surrounding events. Yeah, the surrounding events around that suspected adversary behavior. So the behaviors um that I'm talking about are going to be the image that spawned our smoking gun. It's going to be A1.exe. On the other

side, that was the parent image that spawned tickler.pdf. PDF.exe and then the smoking gun itself which is which which is tickler PDF.exe. Um for that we'll set those two artifacts as our as our um as our image or our parent image. You can see here. So if that was the image or the parent image meaning it was spawned from something or it spawned something you want to know about it, right? We know that these are our two adversarial behaviors. These are the only facts that we have right now. We need to kind of dig down and see what else is happening with them. Um I like to use the stats uh the stats command helps you group all these

together. So we can see the parent image image and the command line arguments that was spawned or um or subprocess of that A1 or that tickler PDF.exe. So obviously that whole query isn't going to fit on the slide. So have it like this just trust me all of this this is this is what it says. Um so this process tree that we reconstructed from that query we see that A1.exe exe seem to be pretty much the root of everything, right? That's the initial intrusion. Maybe that's a fishing email, maybe somebody downloaded something in inside a thread, whatever it is. Um, we don't really get too much into that initial access point. I'm I'm concerned about what's happening on the endpoint

after that initial access. Right? So, you see every branch that we have here traces back to that A1.exe. Again, more and more likely that it is malicious. Um, something that definitely needs to be further investigated. So I broke it down into a couple groups like logical groups of how of how it's working, right? So the first one's up is all um um is all kind of initial recon and discovery that a adversary would typically do on an endpoint that you can see, right? Who am I seeing? What isn't? What files are inside directories or pieces like that. Um you know, typical kind of you're on the box who am I, what am I, what do you

have pieces like that. There's only two people that run who am I through uh command prompt and that's nerds and adversaries, right? That's not not something a typical user does, right? I shut my computer off by doing shutdown/p cuz I'm a nerd. Um but those are the only two those are the only two groups of people that do that, right? So that that in itself people joke on who am I? But it's actually a pretty good detection because it is uncommon. Uh the next one up we can see that tickler.pdf has its own kind of subprocesses on there, right? Um this is the the let's call it the malware right that we that we ascertained from that CTI report and

we can see that it's uh that it spawned cmd which then runs shareepoint.bat on that which in turn runs a regge ad to run uh to set the registry key to SharePoint. Again, more confirmation using this and that CTI report to kind of be like, yes, this is following that same train. This is following the same flow of what has been reported and observed uh by Microsoft or by whatever you know, whatever whoever wrote the uh CTI. So, we can see in that that this reg um is more than likely the persistence chain, right? That's probably going to be the the persistence, but we don't know that for sure. So, we're still we still have to

prove it. Um, and then we kind of go back up to A1.exe lasagna spawns and under it reg saves commands to dump some different uh uh registry hives. That's probably credential dumping. Again, we're going to have to investigate and figure that out. Uh, then anyes which is a very popular RMM tool. Um, see a lot of adversaries use it, whether it's any or draw a blank, but there's a bunch, right? There's a bunch on there. It's essentially RDP. um that's utilized often for backup C C2 in case the initial um C2 the command and control to the adversary gets shut down. It could also be used for lateral movement inside of the environment. Um which is which is

pretty neat. I could we'll see how much time we have at the end. Um and then AD Explorer runs which is Active Directory reconnaissance. It is a legitimate Microsoft signed tool but in this instance I think it's probably pretty safe to say um that's not being used for a legitimate reason. And then finally at the bottom we have probably the worst one that we can see here from just this process tree being created which is the net use command with explicit credentials. They're not explicit on this slide. They're they're explicit in the they're explicit in the in the in Splunk and we'll see we'll see that here in in a few slides. So this net use

command what it's doing is it is attempting to create a share using a um using a specific user and password. This is lateral movement 101, right? This is the first thing they teach you at bad guy school, right? Um, but it's still being used. Just because it's simple doesn't mean that adversaries aren't using it. And you'll see that throughout this presentation. Um, so almost every phase of the kill chain is already in this kind of um already inside of this of this process tree, right? Process creation logs are extremely powerful. They they can tell a really great story. Not everything is going to be logged though um by the process creation and we'll talk more about why um and some

different examples of that and it was like that. So we can't stop at the process creation because again not everything is logged by your process creation. If something is ran in memory or via an API call or not all processes that run have command line arguments, right? open Slack on your computer, you're not seeing 50,000 command line arguments being ran because it's all inside of the executable, right? So, you're not going to be able to see everything from inside of the process creation. But that's fine cuz we have other logs, right? That's why we looked not just at uh at the process creation log, but why we took a step back and saw what other events exist

around this time. So, in this one, we're looking at at the file creation. Um, this one is great. It is what I refer to, this will be the first time I refer to it and this I guess as a um as a state-based change. A state-based change is different than um than like a a keyword search or something like that. So, we'll see here that we'll look for like different images being ran or different file names or something like that. Those can be modified and changed by an adversary. So, they're not as high of a fidelity alert. Whereas, this event code 11, this file is written to disk. There is no way you can put a file to

disk and it not be logged by this. This is a statebased change. This is really what you want to put most of the fidelity into for your hunt because an adversary has to do it no matter what. Um, so in here we see a couple of files that we didn't see. Excuse me. A couple files we didn't see from that process tree, right? We see a results.txt is pretty or results.zip is pretty interesting. We see another PDF. We see sold.dll. That's pretty interesting, too. I know in the CTI report it had mentioned that there was some kind of DL of some sort. Um, so if we just stopped at that process creation, we wouldn't have seen any of those, right? They

weren't created by a process. They were likely ingress tool transferred by C2 or something like that. So, kind of the full list what we found. Again, you can't fit it on the slide, so they'll kind of be like this going back and forth. Full list of what we found and kind of what it's doing for for some of these. I got a little ahead of of myself and kind of already told you what it's doing, but I think for the point of this it'll be all right. Um, so in here we see initially up top peaches.zip. We're not going to dig into this too much in this one, but how the tickler campaign works is they have that initial

execution, which in our our case is at A1.exe. From there, they download all of these different all these different files, these files of interest, all get downloaded as a zip file. Not results.zip or these two. Those three. Those three don't. But all the other ones get downloaded um ingress ingress tool transferred from this the C from the C2 um into this speeches.zip file which is really what it's called. Um and from there they're going to expand that archive and then they have all the tools that they need to utilize in the in the campaign. Next up is the tickler PDF.exe. Again, that's a primary back door. We see that's done a bunch of bad stuff. We kind of already saw that soul.

DLL and SharePoint.bat. Those are pretty juicy, right? You got a bat script in there. You got a DL in there. Those weren't downloaded for no reason, right? That that's probably some pretty juicy stuff in there. Uh so we'll need to investigate those further and see. And then lasagna.exe is an open- source credential harvester. Not custom malware, not something super sexy I ran, right? You can just go to GitHub and download it, right? You see that all the time in adversaries um adversarial campaigns. Not not everything is as crazy as you think it is, right? These are just people, right? just like us doing doing our jobs. These are just people that have a job to do. And if a

tool exists already that's trusted, they're just going to use it. Um, and then anyes.exe. Again, I already kind of talked about it. Um, we'll talk about it more in a little bit. We'll get super into it. Adexplorer.exe. Again, legitimate signed tool from Microsoft. Downloading this is not going to trigger an alert, right? you're not going to have that that reactive piece of it or that in or that that behavioralbased threat hunt from this because it's a known good tool, right? It's signed by Microsoft. What could be better? Bill Gates himself said it's great. So, I mean, what else do you need? And then there we see a couple. So, those right, these these these kind of top ones,

those were all inside of the peaches. file. These ones at the bottom though were likely created by something, right? Results.txt uh or results.zip, If I mean the lasagna results.txt and that domain var uh snapshot.dat file, we can probably guess that this was spawned from lasagna, right? And we could probably guess that the domain.dat file is spawned by adher.exe. I would guess that results.zip is is probably all this, right? Maybe some other stuff, too, but we're going to we're going to figure it out, right? Have your hypothesis and then be able to go off that, right? Ask yourself questions and answer them. That's how you really get a thorough hunt. All right, so we confirmed the toolkit

is on the disk. Need to verify that tickler PDF.exe executed completely. We saw it had some execution, but we just because a command line argument is ran doesn't mean that it worked, right? Just like that net use example, if you have net use and you give it bad credentials, it's not going to do anything, right? It's just an artifact on the on the disk. So you need to to verify that it really happened. it being on the endpoint on disk is bad. Sure. It running um and setting persistence is really bad, right? So, you need to verify what actually happened. Again, don't make assumptions until you have to uh really really use the use the use the

data and use use the fact to drive your story, right? Don't fill in the gaps until the end when you really have to and then it's it's it's okay because you're not going to be able to see everything. >> Um so, in here we're looking for persistence. So from the CTI and seeing earlier that the registry values were were modified looking at the persistence mechanisms themselves. Right? So the top one it's going to show our process creation logs with regge.exe as the image. We see that the uh the run key or we see that it was used uh cmd I I didn't switch the order on this but the parent image cmd.exe spawns reg.exe which then does this stuff right? We can

see here plain as day that it sets that run key value to SharePoint and it sets it to spawn shareepoint.ex exe. Uh, we also see some other registries be being saved which don't look like persistence to me. Um, oh, sorry, sorry, screen. Uh, but you can see that it's saving out the SAM security and the system registry hives. So, that's interesting, too. So, even though we're doing the hunt looking for persistence, other things are going to pop up, right? So, that's another great little note you could have. Put a pin in it, write it on the board, investigate it as you go on, write it down as it happens or you will forget. I promise you will forget. You think

you're going to remember an IP address in a month? No. No, you're not. Um, and then down below, we see essentially the same thing, but looking at it in a different way, right? So, up top, again, this is that that those state based changes that I'm talking about that I want you guys to really kind of change change your mindset on how you're hunting for things, right? So, up top, we're literally just looking for an image of regge.exe. if they used a custom tool um or a different binary or just copied regge.exe to notrege.exe, we wouldn't get any of this, right? It's it's it's that it's that simple. What they can't do is change what's here down

below. So, what we're looking for here down below are registry values being modified. Right? That's what a vendode 13 is. Uh it's like 12 13 and 14 for creation, modification, and deletion, something like that. Um so in there you cannot modify a registry value with this log not being set. It is not possible. So you can see here that while we're doing essentially the same thing twice. The reason for that is because this is easily evaded. This is not. Um and here we see a a little more detail. We see that uh ranch was called it sets this registry value here the run key same what we're seeing up there called sharepoint.exe and was done by scythe

administrator. Right. So probably an administrator account is now breached. Not great. Another thing we can kind of take note of and further in further investigate. Um yeah, we looked at that. We looked at the process tree from before. We saw tickler PDF exe uh spawn command prompt to run shareepoint.bat. We saw soul.dll was written to disk but not really seeing what it's doing. So here we have to break out from from just our system on logs that we're that we're using and look at some PowerShell event logs, some PowerShell operational logs. We can see here the breakdown of kind of what's what's happening, right? So we can see that expanded path over there. We see it calling the DLL. We see it

launching a secondary kind of decoy PDF up there. And then we see see it all over here adding registry. It goes on. It got cut off, but it tells you exactly what it's doing over there. And you can see that that DL is then being executed. Kind of putting all that together. You can see really a full a full chain of how the persistence is done, right? That it starts up top with a1.exe spawning tickler.pdf that then loads soul.dll soul.dll runs runs at um SharePoint.bat file. The SharePoint.bat file we can see then goes in and does this registry ad here of the SharePoint.exe which is going to be their persistence. The run key is going

to start that every time the computer turns on. And then we double verified that again by looking at the at the registry modification logs um and then seeing that that exists at that point. So all this was done again we're not on the endpoint at all. This is all all in the logs all in Splunk outside of the logs. We're not touching this victim machine essentially now confirmed victim machine on the endpoint or messing with it. This is all just from the telemetry that we gather. That's why step two, collect data and verify that that data exists is so is so important. Oh, one piece that I didn't say before um all of these so I use uh sigma rules

to do all like most of these. So I have the sigma rules down here at the bottom. I have um I have a link to them at the at the end. All right. So from persistence now we're going to pivot to credential access. Um for that we have two different queries here that are going to answer a different a different question right. So the first one uh filters for process creation for lasagna. This tells us lasagna was executed and gives us the full command line lasagna.exe all for the command line argument meaning that it ran against every credential category that it has. Right? So lasagna is going to try to dump creds from browsers windows credential manager wireless

networks get repos going to crawl database files all kinds of stuff. super super loud tool. Um, but it's going to dig through essentially everything. And then what it's going to do down there at the end, I think we see it in the logs here, is run those registry dumps. Here it is. Here it is right over here. So, we see that these registry dumps we saw a few slides ago. Um, we can see here now we have it confirmed that it was ran from lasagna, right? So, we know that it's not some admin that's in there doing something. We know that it's from this adversarial toolkit confirmed both by the file location and the tool

itself. Um, so again, more and more like a red flag. I mean, this would already trigger an investigation, right? We'd be we'd be in full crisis mode. But let's pretend we're doing like we're really getting into it. We really want to make sure we don't want to look silly. We've already already done this once. We don't want to do it again uh to our boss. So, we want to really make sure that we that we've got it all. The second query we have down there at the bottom filters for uh process access where the image is Elsas.exe. Elsas.exe exe is what has the credentials for that current logged on user. Right? If you open up Task Manager

on a Windows machine, once you log in, it's got Elsass on it. Elsas runs in the in the UR who you say you are. So in there, uh, we see some pretty interesting stuff. This is probably the most damning bit of of all of it, right? So in here, we're looking at event code 10, which is that process process access. Again looking at Elsas we see granted access one that means all access that means your admin got rights you have complete access to Elsas and we see that that came from lasagna again excuse me in that in that file path running lasagna that we've already kind of verified is bad now has full access to Elsass so

essentially they have your credentials for that loon user which we saw from before maybe it's even on this one that the the registry value um was set through scythe/administrator which you could ascertain is probably the uh the domain admin account right if it's administrator on a domain probably the domain admin account so essentially now you've ascertained that they have um full credential access they know username password they know everything about you for this admin account um after lasagna ran uh we see that it was that it let me back up. So we saw that it had that compressed file from before, right? Um that zip file results.zip. Here we prove what how that was written, right? So we have to again

break out of the um we have to break out of the uh sysmon logs. We get into some PowerShell logs which are extremely I said PowerShell logs are extremely powerful and great. kind of hard to dig through and they make a lot of noise, but they are really they've got a lot of really good stuff in it. Um, but anyway, you can see in there again that the PowerShell operational log compressing an archive of lasagna results.txt and then that it's putting it into that results.zip file down there. Why did they zip up just a txt file? I don't know. Who knows why? Uh why they didn't zip up those registry hives that they gathered to? I don't know. Who knows?

Maybe they made a mistake. Maybe maybe it's Maybelline. Maybe they think that the zip file is going to get past some this not password protected zip file is going to get past a DLP control or something. I don't know. I don't know why they did it, but that's what they did. >> So then from from those queries, um so we ran those three queries, we're able to see what they were doing, but what again kind of summarize it. What exactly does that mean? We see that A1 again spawned that lasagna. It ran lasagna all to gather all of the credentials under the hood. Lasagna also did all these all these registry saves which are essentially registry dumps. You can take

these offline and run them through some some uh password cracking tools or pieces like that. Get some more information. We can see again probably the worst probably the worst part is is um having full access to Elsas. That is bad people. That is so bad. Um, and then we see what I assume is going to be a staging for exfiltration, right? You don't take a file and make it a zip file if you're not going to xfill it. So, likely that's what it's doing. We haven't we haven't proved that. I don't think that we do. Um, but that's likely what it's doing. Sure. I didn't miss anything. Yeah. So, during hunt the hunt two, which was

that file um that file hunt seeing what was on there, we found any desk ad explorer and that net use command in the process tree. So in this part, we're going to dig into each of those a little bit more. So we know they're stage on disk. We want to know exactly what they were doing. This slide is essentially the framework we're going to be using for those three different binaries um or or executables during this hunt, right? I want to see what image was ran, what command line arguments it ran, and who it who it talked to. So in there, we've got three different event IDs uh 1, 3, and 22. One is process creation, three

is network connection, 22 is DNS requests. Um and then we have them just kind of tabled out here. So we see any.exe exe on there. We see exactly what it ran, so it started started as a local service. Uh we see the destination IPs. We have two IP addresses. Now we have some indicators of compromise. We can then kind of pass on. Excuse me. Then we have two different uh queries that are reached out to as well. Any desk is super neat um because it connects um like it connects over HTTPS out but it essentially stands up its own kind of like outofband network of sorts. That's what this query is over here. This any this the relay whatever.net

anyes.com it essentially stands up an outofband network connection. So the the pieces the adversary is doing inside of that any desk connection could be very difficult to see depending on what they're on what they're doing. Um very very neat and it goes for any of the kind of RM tools or tools whatever you want to call them any desk so many others I can't think of any of team viewer that's another one there we go I did it uh in there. So in that we've proved that the parent image A1 or excuse me we can prove um that A1.exe exe again started any desk. We can see it ran. We see those network connections out meaning that it did start

successfully. It's not just the command line argument of it trying to run that it did actually start. It stood up. It reached out to some external sites and pieces like that. Why is it suspicious? Again, the the file location is weird, right? If you use any desk, like this is a portable version of any desk, I'm sure, because it's not installed in program files. So things running outside of standard file locations like program files, program files, x86, system 32, things like that. If your environment uses those and they're not running where they should be, that's a red flag, right? So that they're running a portable version of any desk is in there. It's in that directory, which we

already have all the other stage pieces of the adversary adversarial uh toolkit in there. It was launched by the C2 implant. That's a big one. It was launched by A1.exe, exe by tyler.kc or anything like that. It was launched from this already red flagged uh binary that we have right and then we see our network connections over there which again is established if it's well is likely established. I guess we need to do a little bit more. Hunting really say that, but for all intents and and purposes, it ran. It reached out. The adversary now has a full gooey hands-on keyboard access to your endpoint with your credentials and everything else. Um, not not good.

Next up, AD Explorer. Essentially the same thing, right? We're going to be looking for the same thing. What did it do? Who did it talk to? Where did it go? So, AD Explorer, see that it ran a bunch of times. We see the arguments down there at the bottom. We should be able to see here. Yep. We see here the domain var snapshot.dat file which is what you know we assumed was it was created by ad explore but now we know for sure that's what created it. And then we also see the uh destination IPs and the query names. What's different about this as opposed to the anyesk one is these are I believe 172 IP addresses which are

internal IP addresses. Right. And then we see over here that EC2 something some something JFO CH EQ. That's the domain controller, right? I know that because it's our lab environment, but that's the domain controller. So now you have a tool that's running spawned by that A1.exe from the bad guy that is connected to your domain controller. They now know what your domain controller is. Um they have this whole exported.dat file which has tons of information in it, right? It's got I think I hope I hope I wrote it down. It's got a ton of stuff in there. >> Yeah, I did write down every user account, every group membership, every computer object, all of your schema and

active directory information is stored in that file. Not good. And then next up, we're looking at at net. So while net is not a I won't say it like that, net is a living off the land binary, right? Net.exe exists inside of system 32. um living off the land. Binaries are when adversaries use things that are already installed on the system to do different things. Uh we see that utilized I think probably more than anything because it's they don't have to bring anything in. It's quieter. It's more normal. They're signed by Microsoft probably or something. You know, they're signed by something and it's a known good quote unquote. So in here we see that the net

was ran attempting to map a network share out to our domain controller which we just saw on that last slide, right? So, we see that it's reaching out to the domain controller. It's got a it's got a password on there and it's got that site administrator account. >> Where did they find those credentials at? >> Elsas or from the um Sorry, I didn't mean to breathe it to the mic. Either from Elsass or they got it from those registry hives that they somehow pulled out. Maybe haven't been able to prove that, but they probably if they created if they dumped those registry hives, they probably pulled it out somehow, right? They took those offline. They

cracked the passwords. Now they're attempting to stand up a network share on your domain controller with an admin account, right? Bad news bears. That is not that not good. Um yeah, so with this this is the first time we really see another machine being utilized in our in our hunt, right? So before we were just on I don't remember what the host name was. We're just on that initial victim machine. Now we see an attempted uh mapped network share to our domain controller. So now we need to take how I was saying it's iterative before and that hunting is going to lead to more hunting to lead to more hunting. You essentially now need to do this on

your domain controller and confirm or prove or disprove that this activity happened over there as well. Right? You need to see where all of the machines that are affected by this in your environment. If you don't clean them off of everything, they're they're still in there. And the domain controller for obvious reasons is priority number one, right? I mean that's your crown jewels. That's your entity based hunt. You now need to switch it. I don't want to say abandon this this machine but the domain controller really is going to take precedence right um yeah so kind of to summarize those two see ad explorer uh was ran through um see the snapshot we see the file it

created we see that it attempted to connect to the domain controller um this is all all that all that it captures they can take that offline and now they have essentially a full schema of what your active directory environment is right what machines you have what user users you have. They could find high high priority targets, plan uh plan future operations against your environment, pieces like that. Realistically, this is going to be done over a long long period of time with tons of dwell time in the middle. So, they're going to have this and then from this information they gathered from AD Explorer. They're going to take it back, they're going to run it through AI

probably and then and then they're going to get back on the machine via either that persistence that we already set or A1.exe if it still exists or any desk. So essentially three different forms of a C2 that they have um on the box and then go in and then use this information that they have to then do further stuff, right? Um we also see our first real attempt at lateral movement which again is that net use command. This is I don't know if you guys have ever taken any red team courses, this is lat move 101. And even though it's lab move 101, that's what people are using, right? Just because it's simple doesn't mean that

it's not what's being used. Um and then yeah, like I said, we saw those actual credentials listed in there. Thanks, sir. Uh we see those actual credentials listed in there, which we could probably guess was gathered from Elsas or any of the other other means that we had talked about. >> Um let's put it Oh, one more. So, the last one, we already kind of talked about the network connections that we have. Um this is really just kind of put them all in one spot so it's easier easier to see. So all of the artifacts that we've that we've identified, probably going to put them in there to see who they talk to, right? So we should have A1, any

desk, AD Explorer, excuse me, should have used uh should I had tickler PDF in here? I should add some other ones in here. Um see, I added in PowerShell and CMD. I always do that because if PowerShell or CMD is reaching out to the internet, I want to know about it, right? That's something I always include. Um I mean, yeah, that's just that's just bad, right? then probably probably shouldn't be happening or if it is it probably should just be reaching over to Microsoft to do updates or something like that. So I always just include that even though that's not part of like our you know intelligence driven hunt. Um we found internal external DNS

connections. This is it again just listed out by those different images some key DNS queries that we have. What you do with this information is twofold, right? One you send it to your edge protection team to see does this exist anywhere else? If so, you need to investigate those machines that are initiating these connections out. Uh secondly, um I forgot the first one I said. Uh one is you can block them. Two, you can investigate them. I don't remember which one I said, but those are the two things that you can do with these. Um don't block them by default cuz sometimes there's some CTI in there depending on what your business is. Um so the full

kill chain reconstructed um really just from that single point from that CTI from that hypothesis we're able to reconstruct the entire killchain right we're able to see what happened going through you know we get that initial hunt then we take a step back see where else those logs exist and then you know go through them list by list it might not be sexy to have a have a checklist but without it going to have you're going to have a hard time I mean it's as simple as that you need to go through and really run everything down. Write everything down. We'll write everything down once it happens. Um, and just continue kind of pull that thread all

the way through. These are the signal rules I use. Like I said, I'll have them list here in a second. Uh, key takeaways. Start with one, expand out, pull all the threads, uh, state based changes, signal rules, uh, and then start your own. So to do this, you just need some adversarial behavior and a little lab and enable your logging, pick a report and start hunting through it. Or if you work on a sock or you are a threat hunter, find an adversary that targets your organization or you think targets your organization. Pull up some pull up some reporting and start trying to find them, right? Prove or disprove that they're there. And don't be discouraged. I'll just put less

on. Don't be discouraged if when you do hunt, you don't find anything. Most of the time, you're not going to. There is still a ton of value in hunting and not finding the bad guy, right? By hunting even without finding the bad guy, you're going to be able to then um know your environment more. If you have a 100,000 users, and that's probably low for a lot of or organizations, 100,000 users, 100,000 devices, if the first time you're looking at it is during a uh an incident, you're going to have a hard time. I mean, you're just going to have a hard time. Know your environment. Hunt as often as you can. It's the best job

in the world. It's so much fun. Just do it. Um, I am Tyler Casey. This is All the slides and stuff are in that QR code. Here's my stuff. Thanks, everybody.