Hello, everybody. Welcome to today's Black Hills information security webcast. My name is Jason Blanchard, and I'm the content community director here at Black Hills. And I have the privilege of introducing you to Troy Wojewoda. So if you've been wondering how to pronounce that last name, it's Wojewoda.

And Troy's gonna talk about the curious case of the Comburglar. And so this is based on research that that Troy did. There's a blog that was written for back in December. We're gonna post a link for that blog into the Zoom chat so that way you can follow-up with us you know, or follow-up and read more thoroughly with that. But Troy is gonna, like, dive into what happened.

So, you know, what we do is we ask all of our testers. We ask all the technical team, what would you like to share? And Troy's like, oh, I gotta talk about this. Right? And so what we're always looking for is the excitement factor in the person who wants to present.

And Troy is like, yes. This is something I'm excited to talk about. And so you're gonna learn something interesting today, and, potentially, it could help you protect your organization. But, also, I think Troy is gonna give you, like, some framework and, like, meant meant, like, mindsets for how to find these things. So as Troy goes through, definitely learn as much as you can today.

Thank you so much for joining us. We do this pretty much every single week. So so if this is your first time here, come back next week and join the Discord server so that you can stay in this community. And with that, Troy, I'm turning it over to you.

Thank you, Jason, and welcome. So today, I'm gonna be talking about a breach assessment that I did towards the end of the year last year and what what we what we discovered during that breach assessment. It was an interesting thing for for a number of reasons, and Jason kinda hit on it. One of one of those is that some of the techniques that we observed were were pretty novel, at least, from the specific techniques that were being observed. And then the activity was was rather stealthy.

So I'll jump right into to this to this more of like a a story. The blog, as Jason alluded to, has already been posted. We posted it December 18. We're gonna be posting a link to that blog, in this in this Zoom as well as, there's gonna be a link at the end of the slide deck as well. So I coined this term the or the the the threat actor, the Comburglar.

You'll you'll find out, as we go through this why it is so. And this engagement kinda started as a as a breach assessment, and I'll I'll talk a little bit about what that breach assessment what that service is, how we offer it at BHIS, the idea behind the breach assessment, you know, service as it is, and then go into the the actual engagement where we discovered this activity. Like like I mentioned, a rather novel approach and pretty stealthy. And some of the act some of the artifacts that are related to this activity are still rather, I would say, undetectable, but but there's there's a little there's little activity associated with some of these indicators. So I'll talk about that when I get more into the details of this actual case.

And so, like I said, let's start off as a breach assessment. And what is a breach assessment and what what is that? How does that differ from some of the other services that that we may offer? So the idea with this is essentially looking at you know, we all we all handle risk and and and evaluate risk as either consultants or security practitioners that are hired at organizations that are hired to do what we do. And at the end of the day, we're we're there to help identify, evaluate, and and evaluate and and measure risk.

And BHIS is is notoriously known as a penetration testing company. And what does that mean? Well, from the risk picture, we're we're there to identify we're we we come into organizations to help identify those vulnerabilities, those weaknesses before they can be taken advantage of by threat actors. But the other part of that equation for risk is is the threat activity itself. Right?

So the idea with the breach assessment is essentially hunting. Right? Threat hunting, being proactive, looking for threat activity that is either not being detected in real time monitoring or hasn't been detected at all, and kinda going through and doing a proactive hunt, if you will, for threat activity or the presence of threat activity that may have been been missed. And so the the idea here is not not really too much of a secret, right, of threat hunting. We all hear about threat hunting.

Essentially, what we're gonna learn today in this presentation is the the fact that when I was going through this breach assessment engagement, I identified some somewhat of a a novel technique that was being leveraged by this threat actor. But then there's another component as well, what I what I refer to as premature eradication, and that is we go through IR engagements. When we identify something, we do our best in our due diligence to try to identify the full scope or breadth of the intrusion. We quickly go to containment and eradication, or at least containment is one of the things that is at the heart of an IR life cycle, and we all kinda know that. And ransomware and those other types of activities kind of prioritize on that containment effort because time is of the essence of a matter of sometimes at this point, not even hours, but minutes, if you're not responding, it could be too late.

But what happens a lot of times in these engagements as well is that the entire scope or breadth of the intrusion doesn't get detected or doesn't get identified. And and what we try to do as d DFIR practitioners is identify initial access as best as possible. Right? If we don't have full confidence of how the threat actor gained access to the environment, we then don't have a 100 confidence knowing that the threat actor has been totally eradicated. And that's important for the story that I'm gonna share today, but also it's it's it's one of the things and one of the components that make the bre breach assessment something attractive as a as a service.

Right? IR, typically, when IRs happen, you identify something. There's the smoking gun. There's something to kinda to pivot around. And then breach assessment, when we come into an engagement, depending again on what triggered the the demand or the or or for that service for us to come in, there could be very little to no indicators of anything.

Right? It's just we wanna identify, we wanna do a proactive threat hunt, and there could be a number of reasons why that that may be. And I'll just hit up a few of them. Just a couple real quick ones here is state for mergers and acquisitions perspective. If your company a is acquiring company b, and they wanna bring company b's IT assets, services, whether a traditional network, cloud assets, cloud services, what have you, they wanna bring some portion or all of that into the merger of the the company a's purview.

That that company may may very well wanna know are there weaknesses, are there vulnerabilities in that environment or through those services. But what's more more important is that company may wanna know is there breach activity or is there a threat activity that is already happening in those environments? Right? Is there something laying low maybe or even active c two or or an active intrusion that may not have been detected? And if that company brings on the assets and services of company b, then they could be bringing on potential already compromised assets and services.

So that would not be a good thing. So so from from that perspective, it makes sense that a merger and acquisition may be interested in identifying not just those vulnerabilities and weaknesses, but is there any evidence of threat activity that has been occurred through those systems and services that we're about to acquire and bring on under our purview? Another area of concern for for organizations may be they they identified an incident, they had incidents an incident or a number of incidents. They've kinda gone through the phases of that incident response, but they don't have a 100% confidence that they may have detected everything. And there there could be a number of reasons for that.

It could also just be that they have very good high confidence, but they they want a third party to come in and and assess as well from a different perspective. Right? An unbiased perspective. And that's and that third party unbiased perspective is important, not just for breach assessments, but also for for penetration tests as well. As as we as we know, we're all biased in how we approach things, and we do stuff in organization.

Organizations should be continually penetration going through penetration tests, whether they're have internal dedicated teams doing it. But hiring third parties brings in the aspect of the you eliminate the that area of concern or or the issues of a a biasness. Right? So you're bringing in an independent third party to kinda look at things from a different perspective. Same thing for for for breach assessments.

Right? The IR team may have done a really good job. They just want a second set of eyes, an unbiased look. Maybe there's some desire or or an effort to to bring in other tooling and technology and expertise that that team doesn't have either. Right?

They feel like that that that things have been contained and possibly eradicated, but they're just not sure, and they wanna bring another team in. So it's kind of on the IR edge of things, and it it it definitely falls in the the area of of deeper services, but it also could be something an organization is looking for to do to to to kinda make sure that they're crossing all their t's and dotting all their i's when it comes to IR activity. Then the third one is a proactive approach. Right? Which just as the idea of of threat hunting is not a new concept, has been around for a while now.

It's the the idea that we know that it's not a it's not guaranteed that you're gonna detect everything, that we need to basically threat hunt. It should be built into everybody's security operation centers, methodologies, and approaches, and that this is nothing new. We've talked about this for a while. We have a summit coming up later in the summer to talk about, threat hunting as well. But it's that proactive approach to looking for threat activity in an environment.

So regardless of whether the effort would be started based off of a merger and acquisition or post IR, it could just be as general as we want a proactive threat hunt in our environment, and we wanna bring a third party in to kinda do that. One thing I wanna I wanna bring I wanna mention before I I kinda move on is the idea of what what we what we do when we kinda go through and the idea of how we approach the breach assessment in general. We work with the customers, and we'll talk a little bit about this after this presentation. But we engage with the customers that are that are looking for doing these kinds of assessments. And we we we sometimes their special specific need may not be.

It may be just in a specific area of one of these different five pillars that I'm about to discuss. But, essentially, the way we boil things down is we look at it from the perspective of these five different points of perspective or telemetry sources. We call them the pillars of of the telemetry that we generally work with when we deal with things, whether it's a whether it's a security operation center that's consuming this data in real time and running through detection capability, threat detection alert detections against the telemetry in real time. We're hunting against that data in in in proactively during threat hunting engagements. Or it could be when we come in and do IR engagements.

Right? So the idea with the breach assessment is taking the concept of what we what we do operationally in the SOC as well as what we've observed when we do IR engagements. So we've seen threat actors do x, y, and z. And, essentially, not so much their IOCs because IOCs come and go. Right?

IOCs are the ingredients that the threat actor is using to to essentially perform their engagement or their their attack against you, but those IOCs change. Like, they they come and go. It's really the TTPs that we see that survive longer over time. And if we go back to that pyramid of pain, we learn that the TTPs are at the top, like the behavioral aspects of how threat actors do what they do. We learn from those as we go through IR engagement.

So we take from what we've learned from the IR engagements, whether they're threat intelligence based off of IOCs or or or more specifically or or more pointedly for us, the behavioral aspects in the t t in the forms of TTPs, as well as what we do in the SOC on a continual basis. And we leverage those economies of scale to come in and do a breach assessment for an engagement for a customer depending on their respective telemetry sources. So say if the customer doesn't have any cloud resources, obviously, cloud telemetry is not gonna be applicable here, but we kinda break it down until we look at it through your attack surface. Like, what is your attack surface? What is your exposure to the Internet?

And not just traditionally, like your edge devices for a traditional network, but what's an OSINT? Like, what's in the dark web? What are, you know, threat actors chatting about if applicable to your organization sharing in the in the dark web? And then also the the perimeter edge itself, like, what does that look like? So that's that's all kinda wrapped up in the attack surface of of that of that pillar.

The the next one would be cloud. Right? Whether it's Google Cloud or AWS or Azure three sixty five, we've seen compromises in all of those environments. So learning those TTPs and how threat actors kinda move around in those, and that's what we we leverage when we look at for for the cloud telemetry. Directory services in IAM, so you think active directory, but it's not just active directory.

Right? Any type of authentication sources, authentication type telemetry sources, things that think like Okta and other things as well that kinda come into what's the what are the telemetry sources around the the user, the account, the the authentication that's that we know that gets compromised, and the threat actors kinda move around as compromised credentials, if you will. And then our two real traditional data sources from a threat hunting perspective are the host based telemetry and the network based telemetry. So when we come in from a from an engagement perspective, we have network sensors that we deploy for our customers and strategic choke points on the network. And, again, we work with the customer on what those strategic choke points look like.

And then and then the EDR telemetry. We leverage as much as possible our approach at at monitoring those endpoints. Because let's let's be real. If we're coming in and doing a threat hunt and your current EDR stack is not detecting something, from a third party perspective, not just a human analysis perspective, but even a tooling and the way that we use that tooling is is really important for how we we can go through that that customer environment and and do our hunts. And what's more importantly in that perspective is we already have our tooling in place.

So if we find something, we can quickly move from a a a hunt for threat activity to actual incident response, and we're already positioned for rapid containment and eradication if something were to were to pop up. And that's basically what happened in this engagement. The the the story of the Comburglar that I'm gonna share in very and and and that's exactly what we did. We had the telemetry. We had the EDR telemetry in place, and the network sensors in place from when we detected it, and we were able to help the customer quickly contain and eradicate that threat as we were identifying additional compromised assets.

So let's get into the actual, like, juice of this talk. Right? The actual hunt itself. So as we were kinda positioning and and working with this customer, now there was a little bit of communication to say that they had some incidents that occurred in this this the summer before we got before we were engaged with them. So So we didn't get engaged with this customer until later in the fall.

They were working with their sock. They had things that had come up, and they just really didn't have a good warm and fuzzy for how things were were handling were being handled. They didn't have any indicators at the time of our engagement that if anything was bad, just that they they did tell us that there there was there was activity a few months ago, and and that was one of the reasons why they wanted to kinda have us come in and and do our thing. And so while we were actually in deploying and and setting up our telemetry sources, the SOC itself, the the customer SOC, not not the BHI SOC, but the the customer SOC did get an alert on a hash of a file that was observed in some suspicious activity that was happening earlier in the in in that summer, somewhere, like, in the I think it was, like, August or September time frame. And and and at that time, their their dance move at the time was alerting on a known bad hash.

And we'll talk about that and the file hashes and how that's could be important, but also how it it it from our perspective here, is not as valuable as some of these other indicators that we could pivot on. So once that was once that was detected, we quickly the breach assessment team, myself and and and our team, we we had some something that was interesting, looked like on a host. We did a little bit of deeper dive, triad collected a triage package, looked around. We got some pivots on some interesting looking GUID values that was related to the hash that alerted. And that kind of unfolded the the whole engagement into what was happening was it was it was kind of all pointing to schedule tasks and specifically this user feed synchronization schedule task.

So if you're if you're if you're wondering what this user feed synchronization schedule task looks like, it's under c windows system 32 slash tasks with all your traditional tasks are. It it starts off as user underscore feed underscore synchronization dash, and then these curly braces, and there's a GUID value. And this is a valid this is a valid scheduled task. In fact, on on a lot of machines, it's normal to see more than one of these scheduled tasks with a different GUID value. But it's a legacy scheduled task or it's a scheduled task based off of a legacy holdover from the Windows seven days and and on.

And, you know, it's it's a pretty common thing in Windows where things legacy items kinda get carried on. Right? And even though we're in Windows 11 at the time, some of these assets were Windows 10. But in Windows 11, these scheduled tasks still exist, and and they're normal. And and so if you if you go and start looking for user feed synchronization schedule tasks and you see them, don't freak out.

That's a it's a normal thing. I will show you what you should freak out about if you do see certain configuration settings within those scheduled tasks, and that's what we identified on this in this breach assessment. If you see in this third item here, a normal scheduled task of user feed synchronization invokes the executable MS feed sync dot EXE. And this is synchronizing, like, RSS feeds, right, in how Internet Explorer traditionally tracked RSS feeds that a user was subscribed to, maybe unknowingly was subscribed to. But within Internet Explorer and other types of Microsoft services, utilize the scheduled task to synchronize feeds, RSS feeds and and and the like.

And so it's a normal scheduled task that exists. What's not normal is the fact that this scheduled task was found to be executing a comm handler and a comm handler object. And we'll talk about what that actually means and what that is and and how that kinda differentiated and kinda moved this thing and and actually made it a little bit more difficult from from a traditional detection perspective of of trying to uncover and follow these things. I will share some YARA rules and some other things, but the blog that we published in December has all these details and kinda goes through that and tells the story as well. Just taking this time to to tell the story in person and kinda also mention some tips and and and tricks along the way and some other kind of interesting artifacts that came out about this.

And so you may be asking yourself, what is a what is a comm object, or what what is a what is a what's a comm? Right? And so this is a normal thing that happens is, again, goes back to legacy days within Windows and and things that that that execute via these com handlers or com objects. What what we saw here and what's happening in this in this in this instance isn't necessarily an evil thing in some of scheduled tasks. So there's a lot of there is a a good number of scheduled tasks that do utilize com handlers.

User feed synchronization, it just isn't one of them. And so the threat actor picked on user feed synchronization, but the the the really, the the the the end story should be and we'll talk about this as we get kinda closer to the end is, you know, what other scheduled tasks could exist in the environment that a that a threat actor could be abusing? Lots of times, from a from a pen from a pen testing or even an attacker perspective, hijackingcom objects is something that is definitely a tactic. It's not a novel tactic, if if you will. And so the idea there is finding not only not only scheduled tasks that invoke com handlers, but other things that invoke com handlers.

The way that you identify how a com handler is executing code is you have to identify first the GUID value of the com handler, which is a value in the curly braces, which is kind of interesting as we look at the user feed synchronization schedule task because its normal naming convention has the curly braces with the with the GUID value. It has nothing to do with the actual com handler piece. However, the com handler utilizes a GUID value, and that's exactly what gets registered in scheduled tasks that normally use com handlers, and those that do it in nefarious ways as well. And when you look at that schedule task, all you see is this reference to this GUID. You don't see anything else.

You don't see an executable file. You don't see anywhere on disk where that com object exists. To find that com object, you actually have to go look in the registry with that GUID value specifically, and then I have I have mentioned here where in the Wounders registry you go under the CLSID value key, and then you then essentially go look for that GUID value. There's going to be crap tons of them. And then specifically, you wanna look for the you wanna look for the class ID that's registering the that that that that com object, which is the DLL.

And in the registry, it tells you where the DLL on disk is. And so what happens is when that com object gets loaded, it references that the registry, it looks up the registry as, like think of the registry in this case from a com object perspective as just a a pointer to where on disk the DLL resides. And then what happens is then the the host process, DLL host, which is also known as the comm surrogate process, and for for the reasons of it, essentially hosts the process of or it hosts the the DLL execution of the com object. And and so if you didn't know this, DLLs themselves are executable content, but they don't execute on their own. You can't just run a DLL on on the command line or or or just double click a DLL to run.

It needs a host process to run within the context of. And so you'll see this with, like, run DLL thirty two dot EXE, which will load in a DLL or or or more than one. And and other types of host processes reference DLLs essentially host the executable content for that DLL. And that's exactly what DLL host does, is it's hosting it's the host process of the DLL that's registered in the registry as a com object. And so we see here what we have is from the user feed synchronization perspective, a normal scheduled task configuration points to MS feed sync dot e x e.

Just because you see MS sync.exe doesn't necessarily mean that's good as well. Right? You have to reference that full path on disk. In this case, we see c windows system 32 MS feed sync dot e x e. And so, again, a threat actor, if they had system level administration level access to the endpoint, they could replace this executable right inside system 32.

That's something that could be done as well. But we can hash that. We can look up that hash. We can see if it's been signed. We can do all the things and and and analyze that MSFeedSync dot EXE file.

And it's in the scheduled task. It's it's itself. Right? It's in that scheduled task configuration. So so so that's there.

It's pretty clear. However, when you go and look at scheduled tasks that are using com handlers, you don't see an executable at all. You just see that GUID value. And I'll show you later in the presentation deck what that GUID value looks like and the comparison between a normal user feed synchronization schedule task and one that had been modified by the threat actor to utilize the the the surrogate DLL. And so in order for you to detect something like this, well, obviously, you can write detections to go look for modifications to the user feed synchronization task, which, oh, by the way, gets modified quite frequently.

But if you have the right event IDs, you could see what's actually getting modified. And so the user feed synchronization schedule task utilizes this msv dot EXE. It uses it uses a we'll just call it direct executable. And so if you see that, it may be modifying the the way that that scheduled task is configured, like it's it's scheduled task configuration of when to run. But as long as that half of that EXE is not changing, it's probably safe to assume that that's a that's a normal modification of the scheduled task.

What what you wanna be looking for from from the perspective of a nefarious schedule task being modified specifically user feed synchronization is if it's being modified with that with that com object. And then that's obviously a technique you're gonna use for detections going forward. But if you come into an environment or say you haven't been doing it before and you wanna start, every good detect should start with a really good hunt. Right? So you're about to go put this threat detect in and say, I wanna go start threat detect or I wanna start detecting on this threat activity.

That's great. That's awesome. That's what we should be aiming for. But what's also just as important is looking back through our historical datasets and also doing hunts through our our our endpoints and other telemetry to say, is it already in place? Has it already been modified?

Because if it was already modified, say, last week or a month ago or two years ago, and you're putting in a detect to look for it now, you're not gonna see it. Right? So the idea is you threat hunt. And then, oh, by the way, doing that threat hunting for anything for that matter when it comes to threat detection is you're gonna get a good idea of how how well your detect is from a fidelity perspective. And what I mean by that is if it's high fidelity, it means it's prone to less and less false positives.

And when you get a hit, it's high confidence that it's a true positive. That equates to high fidelity. If it's something that you go do a threat hunt on, and in a week's worth of data, you get back 13,000 hits, it's probably not a very good fidelity indicator, and then that means you need to do some tuning before you go and make that detect live. So that kinda gets into the threat detection life cycle, but threat hunting is a part of that. In at least my opinion, they go hand in hand, and a lot of the the the models that I've seen kinda kinda allude to that as well.

And and, again, this threat actor was leveraging that user feed synchronization, and it it kinda makes sense of why they they kinda picked up on that as well. As you'll see, that user's feed synchronization has that GUID value that's looks exactly like a GUID value that you would see from a com handler perspective. And and that's exactly what the threat actor was doing in in the case that when we identified it, the GUID value was the actual name also of the DLL. So we'll see here from a from a chain attack chain perspective, the mod the scheduled tasks were modified way before we got engaged into this into this effort. And then pretty much close within the timeline, as that scheduled text is modified, the com objects are registered in the registry.

So when a scheduled task runs, it can reference the registry, look to see where that DLL resides on disk, and then with DLL host dot e x e, it runs the as the surrogate process runs the surrogate DLL. So the the the important part that I wanna kinda highlight here is this middle part is the surrogate DLL dropping to disc. So what's interesting is and I've done some some deeper dive threat hunts through various environments after this engagement as well as the engagement that I was on. And what was interesting is the scheduled tasks that used valid that were that were valid, benign, normal, if you will, scheduled tasks using com objects and com handler invoking com handlers via this process, all of those DLLs pretty much all either ex existed in Windows, c Windows system 32. In our case here, these DLLs that were being dropped were being dropped outside of that protected directory placement.

So all but one case, they were these DLLs were dropped in program data Microsoft Windows, which was definitely as as I kind of, like, step back and look at it from a bird's eye view and looked at all these other normal comm handler scheduled tasks, that was not a thing. All these comm handlers that that were being invoked via the traditional scheduled tasks that were using comm handlers referenced their DLLs in Windows system 32. The other interesting part was the DLL itself was named with the curly braces, the GUID value dot DLL, which was another kind of anomaly. All those other reference DLLs were just normal looking or just file names dot DLL. They didn't have any funky GUID value or anything like that.

Obviously, we were involved in this breach assessment. We identified one system. When I went through and when we we basically searched the entire environment for these these different indicators of compromise and TTPs specifically, we we found several other hosts that were affected in the environment. And so when we were working with our with the organization, they had one of the admins log on to the server to to to help clean it up. Well, that triggered a scheduled task, and then we saw active beaconing that was attempted to be beaconing.

Thankfully, the organization had a good sound egress policy in place, and the the IP address was blocked outbound. So that was a that was a good thing for them. And and the reason is that that IP address was identified by them previously, and so they had blocked that as a as an egress control outbound. What they didn't block was the domain itself, which if the threat actor had reregistered that domain or sorry, changed the IP address to what that domain resolved to, then that communication could have been successful. So, thankfully, they had the IP address blocked, but just kind of a lessons learned that when you have identified malicious indicators such as domains and IPs, it's best to kind of look at it from both perspectives.

Right? Block the IP if it's known bad, but also if the threat actor has access and control of that domain, they can re they can reassign an IP to for a new IP address and just, you know, reestablish c two if the only thing blocking was the IP address and not the actual domain resolution. So I wanna talk a little bit about import table hashing. So if you haven't heard about what import table hashing is, it's commonly referred to as imp hash. It's a value that can be discovered in a number of ways.

Sysmon, if you have Sysmon in your environment, there's a couple of Sysmon events that actually captures the impash for executable. So, like, the process, if you have that turned on in your configuration of Sysmon, process execution events, so event one. And then also event 29, which is a fairly newer event ID for Sysmon, captures when a new executable file gets created on disk. It also captures the import table hash. But what is this import table hash, and why why do we need to know about it?

Why is it important? Well, couple things. It mileage varies with this thing. So sometimes import table hashing is very valuable. And in our case, for this breach assessment, it was extremely valuable.

In fact, it is one of the most valuable IOCs in this entire in the from this entire engagement. It it it had a a high fidelity, a true positive, and there was no other false false positives associated with this import table hash. And it also allowed us to discover additional artifacts in the wild by just pivoting on this import table hash. So the idea with the import table hash is just something that Mandiant actually blogged about, like, twelve years ago. It was in, like, 2014.

They wrote a blog about this. So if you just Google Mandiant and import table hashing or whatever, you'll see the initial blog. I think now it's been carried over to a Google owned page because Google owns Mandiant. But I will give them the credit because they were the ones that kinda first, at least from a public dissemination perspective, kinda came out with this concept and topic. And the idea is to look at the import table the import table functions that that a portable executable file calls, and not specifically look at all the details of the code, but just the the actual structure or the skeleton of that import table, and it hashes it.

And and and and by doing that, the the the the concept here is that as long as the threat actor is not changing the import table itself or the the structure of the import table, the hash it's the import table hash stays the same. So if you just take a file, any file, it could be a Windows executable file, but doesn't really matter. From a file hash perspective, like an MD5 SHA one, SHA23D6 that we're used to operationalizing when it comes to indicators of compromise, those hashes are are are unique for the exact bit for bit copy of the content that you're hashing. You change one single one or zero, one single bit, that entire hash changes. Right?

So the threat actor doesn't really need to do much. Right? And then we can reference back to the pyramid of pain that I mentioned earlier, that hashes are at the very bottom because they're the most trivial or easiest for a threat actor to change. They just change, again, one bit, and the entire hash changes. However, the import table hash, you need to make modifications to the code in order to get a new import table hash.

So, again, this could be a valuable thing for us as long as that import table hash is pretty unique to the malware or at least the the the the files that we're looking at. One thing that I will mention, if you just blindly take import table hashes and assume, oh, okay. I have a bad malicious file. Virus total says 56 out of 60. It's bad.

Let me take that import table hash and go find all the other import table hashes and call those bad. Don't do that. Don't do that at least blindly because what happens a lot of times is there's executable content or files that are, say, wrapper executables or shells. So think, like, for example, a notorious one would be pyinstaller or py. Exe or any of these other utilities that can take, like, say, a Python script and turn it into an executable file.

What it does is it essentially creates a wrapper around the like, an executable shell, if you will, around the Python code, and then and then brings in the compiled components required for it to run as a Windows executable file. Well, that shell operation, that that shell that outer shell of the EXE will have the import table hash the same no matter what content you you use PyInstaller to to perform that Python to EXE. And there's other countless examples, self extracting executables. Dot net binaries are very notorious for having the same import table hash across very varying files that have nothing to do with themselves. So so they do carry that kind of artifact to where, don't fall victim to saying, oh, I have an import table hash.

It's bad. I need to find all these associated ones. It's it's sometimes it's hit or miss. For this for this instance, it was it was a very high fidelity indicator, and the only files that we found in the wild were all related to this activity with this import table hash. And what it what it did was it allowed us to discover several other compromised assets in this breach assessment engagement as well as other artifacts in the wild that we're able to pivot and kinda connect the dots and put things together.

So very high very valuable thing. It's it's in some telemetry sources. It could be very valuable from, from certain perspectives depending on how that executable file is put together. But, also, some executable files don't don't have the the same fidelity characteristics that that that that we saw, like, for example, in this in this engagement. So moving on.

From a timeline perspective. As we're as we were engaged with this customer, we kinda came along around the October into November time phrases when we were actually doing this engagement with the customer. They had some stuff that happened, like I said, in September and act in August, but but there really wasn't anything else that they that they they really knew about. What we were when we kind of started widening our net and doing the hunt on this activity, we discovered in the environment that the breach went back to as early as March 19. And that's when we saw the earliest evidence of scheduled tasks being modified and DLL is dropping to disc.

And so that gave us the confidence that knowing that that's when the threat actor established this technique. However, unfortunately, for for us and our and our and our customer, we could not identify the initial true intrusion of how the threat actor gained access initially. From from all of the telemetry sources we looked at and all the every everything that we did look at, it it looked like for the most part, at least everything that we were able to analyze and inspect that the threat actor had gotten kicked out, and that was due to the the egress controls of blocking the IP. But really, they they kinda dodged a bullet because if the threat actor changed that IP address, they could have had beaconing back and they may not even have known it. So so we didn't see any other activity, but we did identify several other hosts that had this persistence artifact, and we were able to help them kinda clean things up.

This techdataservice.us was the domain. There's been since this has been other several other subdomains of that root domain and this IP address, which still resolves to the I g IP address actually at this time. It's kind of still unclear what this campaign was and how broad this campaign was. So it's kinda interesting to see. Over time, I'm just kinda gonna go on a limb that I suspect other vendors are gonna come out with other stories from their own investigations and their own environments that they've that they've investigated.

And so maybe we'll get more behind this. For for us, this is all we really we have right now on this threat actor. And so you could see most of the DLLs except for one was dropped in program data Microsoft Windows, but with that same that naming convention of the curly brace GUID value dot d l l. And then one of them was dropped in app data. So as we were kind of pivoting around, especially pivoting on that import table hash, we found additional artifacts, some artifacts that were identified communicating to that root domain going back to the previous year of 2024.

And then and then really the earliest time frame that we have that that we have in in the wild is going back to as early as as January 2024. Now the reg the domain itself was registered in September, and we saw that there was several files, several dot EXE files that came shortly after within just a a week or two of of the domain being registered, which, oh, by the way, is something that as detection, you know, engineers, as threat hunters, as as as as DIFR consultants or DIFR analysts. One thing that we see over and over and over again, threat actors typically use when they register a domain, they they use it pretty pretty frequently or pretty pretty much within the the days or weeks from their domain being registered. So that's one of the things to kinda look for in your environment. You're seeing domains being communicated to, be having the ability to understand how new that domain is and and and seeing that in your environment.

KB could be an indicator of something that maybe even just a possible threat to start kinda threat hunting against. We see the domain was registered September 5. By the September, there's been files uploaded to VirusTotal suggesting that that there's communication to those domains. So some interesting things there. Now those files were not found anywhere in the breach assessment engagement.

So the fact that this could be just files for other victim environments, other other areas, other other victim networks and and and such. But, really, from a confidence perspective, I would say this is all related to the same, at least, threat actor campaign. So the other interesting thing is as we kind of pivoted from there, we were looking at compile dates of the files as well as when they when they showed up in in VirusTotal. And so there was some interesting things, and these are more detailed in the blog itself. But the compile time timestamps of these files look like they were modified.

They kind of indicated from the perspective of, like, when it comes down to, like, the seconds, how they were just zero zero for seconds. And some of the timestamps matched exactly the DLL time stamp the compiled DLL time stamps that we've identified in the victim environment as well as some of this other stuff that was being found in in the environment. So that kinda gave us some high confidence that the threat actor was modifying the time stamps, the KAPALA time stamps to kinda make it look like the files were a little bit earlier than, say, the the domain being published. But then there was other artifacts being actually submitted to VirusTotal, which are VirusTotal's time stamps. So when it first saw it, that indicated that the threat actor was doing something and may even been the threat actor testing their their artifacts out.

That's kinda hard to say from our vantage point whether or not when a file gets uploaded to VirsTotal, whether it was a victim or or an analyst doing some work or it was a threat actor just trying to test out their code and see if it was detectable. Right? So this is when we get into the actual threat hunting. Now I mentioned IOCs, and we have IOCs. And and, traditionally, that doesn't really just looking for IOCs isn't really a an an extensive threat hunt, if you will.

It's still retroactive detection if you haven't detected in real time. So it kinda follows within the realm of it, and you're going back and looking through it. So it falls within it, and these are these are low hanging fruit things that we can we can leverage. And most of us in our environment should be able to leverage day day zero. Right?

Right away, we grab IPs. We start looking for them. You may need to kinda look at your telemetry sources to whether or not you can search for some of these IOC types, specifically the AMP hash hunting. Right? You're only gonna see that for this instance, you're only gonna see that in event ID 29 when the DLLs actually get created.

And that's because even though the impasse could be exist in process execution events, well, it's a DLL. So a DLL is not gonna is not gonna show up as a executable process in type one or in in in event one Sysmon events. Right? You're gonna see the DLL host dot e x e referencing a GUID value, and you're not even gonna see the DLL itself being referenced. So the only opportunity you have from a creation perspective from this import table hash hunting would be to look in your event 29 event ID 29, which is process or executable content being created does have that value.

You could definitely look at that blog where we have the list of all the IOCs and hashes. The hashes itself aren't gonna carry as much weight. In our environment, every victim computer that we found had a different file hash for the for the associated DLL. So but the import table hash was all the same. So that's gonna carry the most weight.

Also in that block, I show how you can detect the the malicious modification of the scheduled task via Yara via Yara rule, as well as if you don't have Yara in the environment or can't leverage Yara for whatever reason, I I also show how you can do it with PowerShell. And so a PowerShell script to kinda do the same thing or the same effort that you can do with Yara. So two different two different approaches to kinda get the same end result. From a behavioral perspective, again, looking for your user fee synchronization GUID schedule tasks, making sure that they're not modified or they're they they don't that the configuration of those schedule tasks don't contain a com handler object. That is something that is a 100% I've I've we've I I I use these TTPs to hunt through our entire SOC telemetry, our entire SOC datasets with numerous amount of SOC customers.

There was not a single false positive that was ever found. And and so that was a that was a big indicator that this scheduled task obviously does not use a comm handler. But more importantly, I was able to kind of look and do a little bit more research and find and try to do some baselining in the environments of what scheduled tasks do normally use comp handlers. It's a pretty extensive list. I don't have the the resources here.

Something we'll we'll probably update with a post to kinda show. But but, again, mileage is gonna vary there. Right? Because because there's gonna be a lot of scheduled tasks in your in your environment that are that may be related to specific applications that get installed in the environment, not specific to just Windows. So the the effort there was kind of to to look at it from a baseline perspective, like a new Windows install and those kinds of things to see.

But I will say, every single test schedule task that had a com handler and that had that registry that that that registry lookup, that red that the the lookup for the GUID value in the CLSID registry, all of those DLLs were either were were in a system directory protect protected by the system. So c system 32 or c window system 32. None of those DLLs were associated to areas outside of the system protected directories. So that is one thing that even just going through your registry looking for palm handlers that are scheduled tasks and fall outside of c window system 32 or whatever your volume is could be something. And that's kinda like the the point I'm trying to hit there.

The other one is a little bit more of a a rudimentary or kind of a general approach is I doing a hunt for a GUID value dot DLL. So curly braze GUID value dot DLL. No no false positives were found in any of the hunting I did either in that customer environment for the breach assessment nor our sock. So we were able to kind of look at that as that was that was an an interesting artifact. Now that's just the file name.

But, again, we'll take what we can. Right? We're we're not you when when it comes to hunting, any little artifact could could really kind of unfold the whole thing. So so I don't ignore anything. Some things definitely have more weight and and have a lot more mileage, but but we'll take what we what what we have there.

And then just kinda reiterating that that import table hash is definitely one of those high fidelity indicators for this threat activity. That and the fact that user feed synchronization schedule task does not use a comp handler itself. So what does it actually look like? So if you go and look at your do you wanna go just navigate yourself and go look at your schedule task in your environment? This is what they're all gonna look like.

On the left side, you will see a normal benign setting. So this is what it typically should look like where it's referencing that MS feed sync.exe. But on the right is we see the same schedule task for user feed synchronization modified with a class ID reference, which is a com handler obviously referencing that class ID. In order to know what DLL is being invoked here, we have to go to the registry, look up in that class ID, look up, find that GUID value, and then in that registry, you'll see in that registry key, you'll see where the where the DLL resides to on disc. And then our, you know, our takeaways here is, obviously, this you know, coming into the breach assessment, you know, going back to the fact that, you know, there was some kind of things that were going on before our involvement.

I'd try and identify, you know, all the different pieces that that kind of we we go back through, like, the cyclical approach of doing IR and doing our best efforts to understand when the initial access obtained and all the threat actor attributes that were related to the activity is is highly important. We don't really understand what this campaign or threat actor is or what they're really after, how long they really were out of the environment, and how long they were actually there. We do know by pivoting on some artifacts in the wild that the threat actor was at least utilizing this type of campaign and some of these artifacts related to this campaign going back to the 2024. So so there are there was, I think, one other OSINT article that was in in it was a Rising article. I wish I actually had the link here.

Rising AV, which is a Chinese antivirus vendor that blogged about some of the activity related to detect dataservice.us domain. Nothing to do with the scheduled tasks, but the domain and infrastructure. If you actually Google that, you'll find that. Other than that, in our blog article, there's really nothing out there in OSINT about what this activity is. Just to show you, just two days ago well, actually three days ago now, depending on where you are, the UTC time.

I think this was kind of like technically, it was the the tenth of of March. But really, just a couple days ago, there's one of the DLLs that are associated with this compromise still only has two AV hits. Right? So still very, very when I was doing this engagement, there was zero. Some of these artifacts were in virus total with zero AV hits.

So that's maybe just another lesson to take home is that just because the zero AV hits come back when the virus total, when you go do a lookup on on a on a file, doesn't necessarily mean it's bad. It just means that no AV vendors identify it as bad. So, again, this was just a couple days ago and still not really much being identified there. And then that's the end of the presentation. We'll we have a few minutes, as we get to the we're at actually, almost at the top of the hour, so we're gonna probably bring in our, our wonderful and better looking staff.

Woah. That's Yeah. Mean,

come on. Come on. Say say more.

I'm trying to be nice to you, Marylander. Marylanders. It's snowing outside.

Oh, it's

snowing. I feel yeah. So I'm I'm really just being empathetic really for you. Yeah. But it's probably gonna start snowing here as well.

It will. Mhmm. I do wanna mention that I the SOC summit is coming up in just, like, what? Like, two weeks? Two weeks?

Two weeks? It's coming right up. I will be doing a talk on getting started. It's it's a it's a it's a speed talk. Right?

I think twenty five minutes twenty, twenty five minutes on getting started with Yara. And and and probably one of the things I should do is know how to spell Yara because that's misspelled right there on the slide. Oh, no. Yar. It's Yara, so I apologize for that.

But it is really Yara with an a, two a's. And the Yara rules are actually in that blog article. You can go read and look at and see that Yara rule. Yara spelled correctly. Yara.

Yara. Yara. And then and then the the week after that, I will be teaching my network forensics and response class March. So with that, I will pause and hand it back over to Jason.

So yeah. Thank you, Troy. Thanks for sharing your knowledge. Someone was like, I'm digging this one. I think they just loved how you were, like, diving into the nitty gritty of all the things that happened.

So a couple of things. If you haven't checked in yet for Hackett, if you have no idea what I'm talking about, it's where we give you credit for showing up to our webcast. If you show up for ten, twenty, thirty, forty, 50, and 100, we send you rewards to anywhere in the world. And we it's our way of saying thank you for coming. This is in Discord while live.

So if you're watching the recording, join us live. And you're like, but I have a job. It's like, get it. And so you can have it on in the background. Put Discord on your phone.

Alright. So, Troy, Keith is gonna take a look, see if there's any questions. If you have questions now, it's a great time to ask them

in Mhmm.

Inside Zoom or inside Discord. So Keith is gonna look for those. I do have, like Troy said, Sock Summit's coming up in two weeks. Join us for that. And then if you wanna stick around after we're done with the the q and a section, Logan Bender is here to tell you what it's like to do business with Black Hills.

So if you're, like, listening to this and you're like, maybe we could use a Breach Assessment, Then Logan's gonna talk about what it's like to do business with black hills. Alright. Keith, seen any questions so far? Yeah. I do have a couple.

And by the way,

I I must say, Troy, that was excellent. Thank you.

Thank you.

And and it was definitely well titled because it is a very curious case.

Yeah. And But the the image was all me. I I just didn't know really what to, like, call it at the beginning, and I had, like, the Hamburglar in my head for some reason.

And I

was like, well, let's see if we can create a a cool little looking image here. But Yeah. That's that's really, like yeah.

Yeah. Well, thank you for going through all that. And and the way you broke it down too is very enlightening of the whole situation, but it is a very curious case. So I do have looks like just a couple of questions. First of which is from Jay Cox.

He's asking, or he or she. I'm sorry. Do you normally include GUIDs in your threat hunts?

So for this for this specific thing, no. I didn't before. When when that kinda came up, the the the threat hunts for the GUID so I'm I'm I've taken it in probably the GUID dot DLL is probably where that where that kinda comes from. So so, essentially, the reason why that GUID was was first identified was it was the name of the DLL where there was a hash associated with it that kinda triggered. And so and that's all we pretty much had.

And it was kind of nice that the threat actor used the same GUID value of the DLL name that they that was the actual the the GUID value of the scheduled task. So the fact that when we did our triage of the endpoint, I just basically did a search for show me everything in this triage package that has that good value, and a scheduled task popped up. And I was like, what is this? And then that just pulled another thread. And that's typically how a lot these threat hunting engagements engagements go.

Right? Anybody that's done threat hunting, you probably realize you fell into a hole, and you're now an Alice in Wonderland, and you're like, where the hell am I? Right? You have to, every once in a while, pick yourself up and say, okay. I gotta come up for air.

Like, where am I? I've I went down this rabbit hole, and, I mean, that's why we call it a rabbit hole. Isn't it not? Right? And so things can you can go down rabbit holes within rabbit holes, but you gotta kinda pick yourself up.

In this case, it was nice that the threat actor conveniently used the same good value for the DLL name as they did for the scheduled task. Once that was happening and, it was a pivot, pivot, pivot, and then boom, we were like, okay. We have something on our hands.

Alright. I'm gonna wrap up real quick for the official webcast, and then we'll stick around and see if there's any more q and a. So, Troy, right, I'm gonna ask you to put all your final thoughts together as one, like you know, if you could sum up everything in one final thought, what would it be? But before that, in the Zoom chat so if you're on Zoom right now, if you're watching recording, sorry. In the Zoom chat, there is a link to get the incident response version of our survival guide.

If you're willing to go to a website called Spearfish and then put in your contact information, we will mail it to you for free in The United States. If not, then get the the digital version. Alright. Troy, final thoughts. Yeah.

What are they?

When you're in IR, try to identify as as much as possible the entire intrusion. Right? The, the as early as signs of threat activity. Containment is great, and we need containment, but don't forget to go back and rinse and repeat to go through that kind of stuff. And and, really, sometimes that interesting art interesting artifacts can lead to some to nothing, but sometimes they lead to a lot of stuff.

So just stay curious yourself. Right? So it's this case is curious, but as the threat hunter, when you're finding something that doesn't kinda look right, it's kinda like, okay. What is this? You you utilize the resources, Google, AI, to say, is this normal?

But also kinda, you know, go through. And the other thing that I wanna mention is utilizing other telemetry, like taking a step back, not just looking at the one asset that you're investigating, but look at the whole environment. Is this stuff happening across the whole environment as well? Because if you have a thousand endpoints and it's happening on 80 something percent of them, it's probably not bad. It's likely that it's a an artifact that exists normally in that environment.

So utilize those tips, I would say, and be proactive and and, you know, hunt and and try to find those those the presence of threat actors kinda laying low.

Alright. Well, thanks, Troy. This ends the official webcast. Alright. It is over.

So we're in, like, post show banter. Keith, was there any other questions? And then if you wanna stick around and know what it's like to potentially get a breach assessment from Black Hills or what it's like to do business with Black Hills, Logan's here. Troy can answer some questions. Keith can potentially talk about active countermeasures and the new AC hunter that's coming, that's being worked on by the team.

That's a threat hunting solution that we have developed through Black Hills and active countermeasures. Alright. So, Keith, any other questions? Yeah. I do have a a couple.

This one from, Joseph AW. This may be a little deep, but maybe a little beyond the scope, but I'll throw this out here anyways. He's asking she yeah. He's asking, have you looked at the binaries, and how does hash values change while keeping functionality? And how do you employ impash, which would need to compare old binary behavior to new binary behavior?

So so I'm not quite sure what the the the last part kinda alludes to, but I'll just say we did some level of analysis of the DLLs themselves. They did look like they were they they were pretty lightweight as far as from a functionality perspective. And and really from our without actually having a established c two, we didn't we didn't kinda know what the what the ultimate picture was, but but our assessment was that this functionality was essentially allow allowing the threat actor to establish a connection back down. So a reverse kind of a reverse shell or reverse connection back, into the environment to maintain persistent c two.

Okay. Great. Thank you. And I do have a couple of more. This one is from Kutisphile Modis asking, just for clarity, is it normal to see command some name dot EXE command tag?

What was abnormal about this that it was referring a good dot DLL? And to see the contents, you need to look in the registry, question mark?

Yeah. Yeah. So that's what makes this very difficult to kind of to to to identify and then go hunt for. Right? Because you can't just go and say, okay.

Let me go search through all my scheduled tasks. You can do that with a PowerShell script. Say, go go show me all my scheduled tasks that use a comp handler and look for that comp handler right in that right? If we go look right here and you go and see in the in the scheduled tasks of all your configured scheduled tasks, If you see this comm handler tag and a class ID with a GUID value, it's it's being invoked via a comm handler. You then have to then take that GUID value and then go look it up in the registry to find out what the actual DLL that's being that's that's being hosted by DLL host is.

So it's not so it's not a one action or a one step move. You have to do multiple steps to kind of go from this identifying where those DLLs are. So that's what made it a little bit more stealthy and trickier to to identify.

Excellent. Thank you. And this and this last one is is probably a little more fun, but Oscar Katana is asking, Troy, is that a confiscated AT AT behind you? At at

Yeah. So, I mean, I don't know if you can see the Millennium Falcon has it hogtied. Mhmm. So there's actually there's the Millennium Falcon is actually has the has the AT AT down and captured. And this is my my view of blue team versus red team.

Right? Or really not really blue team versus red team. I don't wanna steal the bear versus bear kinda thing, but but really defender and attacker. Right? So we are the rebel forces.

We're trying to eliminate the the imperial you know, evil imperial empire. I look at that as, like like, even though I work for a penetration testing company, my career has always been in in in response and and tracking adversaries and trying to eradicate adversaries out of customer environments. And so I I like that kind of that that's my that's my view of good versus evil.

Awesome. Thank you. And I I'm sorry, but I do have one more that popped in from Cheddar. And it's asking, what was the initial detection? As in how did the client know they were breached?

Yeah. So so they didn't share with me all the details. I don't think their SOC actually shared with them all their details. I'm I'm not sure of those and can't but they had identified a DLL with a with a bad hash and some other activity that was going on. I believe there was brute forcing and password spraying and some other activity that they had identified, and then they traced it back to to that IP address and then a hash.

And so they blocked the IP address, and they had an alert on the hash. But, again, that hash was only really unique per system. I think this hash actually luckily, the threat actor used the same hashed file in a couple different places, but all the subsequent systems that we found all had different hashes. So so, really, this was there was a little bit of a smoking gun, and it was from a prior incident before our involvement. And and when that happened, we did the triage package, and then we helped the customer kind of go through the entire environment and find all the, all the compromised assets.

Awesome. Thank you. And and as you were speaking, there's one more coming in from a DAT robot who's asking is, when you come across threat actor infrastructure, do you ever perform takedown or abuse requests to have the servers and domains taken down?

Yeah. I mean, I I have before. I don't sometimes I don't get involved in that. Sometimes it comes to infrastructure that's anonymous, so it really it really depends. I know, like, previously for me in organizations, it usually comes down to, like, the squatting stuff or the doppelganging stuff, the the things that are kinda like domain registrations and things that are, like, trying to do that emulate or look like a brand or a certain company, but they're obviously a a a different domain.

So I've worked with different firms to kinda say, hey. This is kinda squatting on on on a domain that we're that that that we own kind of thing. Right? So so so in that case, yeah. But but not but not at all all instances.

Cool. Thank you.

Alright. Thanks, Keith. Thanks, Troy. So what we're gonna do now is transition into a time of, like, hey, Black Hills, we've heard good things. I think it's time for us to to to work together to improve our security.

Logan's here to talk about that. I always give these, like, softball questions to Logan, but today, it's gonna be nothing but a 100 mile an hour fastballs. So, Logan, why Black Hills? Why should someone pick us?

I would say it'd be because of our our team members here, and we bring a wealth of knowledge to to all things cybersecurity. So, like, Troy himself. Right? He was in our SOC and our MDR. He was in incident response.

He's been on the pen testing side of the house. We have specialists in all areas of security, and our teams work very closely and collaboratively together. So we certainly have some industry leaders, that you get to engage with when you engage with Black Hills information security.

K. Are we the cheapest slogan?

Well, it depends on, pricing and budget, but, we're we're very customized in our statements of work. We've we can customize it to the client needs, their budget. We're pretty flexible, but we're not the cheapest. We're not the most expensive, but we know you're gonna get really good value out of the engagement with us.

Can someone work, like, can they hire us today and start the engagement tomorrow?

It depends on the solution. I know, different team members have different schedules here. Some people focus like Troy on breach assessments. He's he's a little bit more flexible. He can sometimes get started in a few weeks.

Incident response services can be started as as quickly as next day. Pen testing services can be, usually, that has a little lead time of about forty five to sixty days. SOC MDR services, those you know, we've we've onboarded clients as quickly within a week. So

Yeah. Okay. So, Logan, since you don't work on commission you know, we've talked about this before. Right? Our our client engagement team, business capture team, whatever we're calling it, you don't work on commission.

Why would you pick as a salesperson, Logan? Why would you choose to do this to yourself at a company where you make no commission? Why why did Logan do that?

Well, I think all of our commission checks went to the the future is recca comment. Right? I think that's where our commissions went.

Sure. I mean, dang it. That's kinda not wrong.

Yeah. Our commission goes to to help chase people's dreams. No. What I love about working with Black Hills information security, and, we're never trying to push solutions or services on you. I mean, John our COO, CJ, we've always believed in a crawl, walk, run methodology.

Right? We will never advise or consult you to do a particular service if that's not what you're ready for. So talking people out of doing business with us is a part of my role half the time as well here too. So making a a solution unique to a customer's environment and not trying to upsell, I mean, that that's just a huge win for both the client side and, you know, the our reputation in the industry as well too.

Alright. So I got one more question for you that I'm gonna ask Keith about the active countermeasures because sometimes people don't understand that Black Hills is, active countermeasures, Wobbles Hackenfest, anti siphon training, Black Hills, Record Comics. You know, we there's multiple things that all John Strand. John Strand, is the owner of all of the companies. But so, Logan, what's step one?

If somebody wanted to work with us, what is literal step one for doing it?

Step one would be reaching out on the Black Hills information security web page. We have a contact us form. You can kinda let us know a little bit about, yourself, the company you're reaching out on behalf of, and then what one of the 100 solutions that we have here at Black Hills Information Security or other tribes of business are you interested in discussing? So the contact us page is the, initial starting point.

Yeah. Okay. And then, Keith, tell me about ActiveCounter measures. What is it? What does it do?

How can it help with this whole threat hunting that we talked about here in the webcast today?

Yeah. And and similar to what you just described, we're we're all just a family of companies. Even though we we somewhat operate independently, we're all under the same umbrella. And active countermeasures could be considered the software arm of Black Hills information security where anti siphon is training wireless hackathoses conferences. Active countermeasures is more focused on creating software, specifically threat hunting software, which, we've been doing for many years now.

And I do wanna address actually a question from kill switch x seven in Discord was asking about the latest updates for AC Hunter. AC Hunter is currently going under a major version change. We have been at AC hunter version six, which AC hunter and Rita have been in development for over ten years now. But we're looking at a new major version, which will be AC hunter version seven. I I don't have the exact date when it's gonna be publicly released.

However, I can say that we we are close, so it will be soon. And AC hunter is is in almost completely rebuilt. A lot of the analytics have been tweaked to become current with our current times for threat detection. We've added more features in there, to allow more detections on networks. The the back end database has been completely redone.

The user interface has also been completely redone. A lot of the user settings for version six that used to have to be done on a command line can now be done directly in the interface. So we're really excited and looking forward to releasing this new version. It's much more user friendly, and it's definitely, very good at threat hunting network traffic. So we encourage everybody to to take a look at that.

Now, RIDA, which is our free open source version of this threat hunting software, is available now. And and like I said, it's open source. It's free. And Rita, which is currently at major version five, does have the updated analytics that will be found in AC hunter seven. So if you wanna get a feel of how these analytics work and how it can threat hunt your network, you're welcome to go to activecountermeasures.com.

Under free tools, you'll see RIDA, and you're welcome to download RIDA today or any other time that you wish. Download RIDA, run it, get a feel for the analytics, and and give it a run. So that's kinda what's going on. Awesome.

Thanks, Keith. Alright, Troy. Give me the, like, thirty seconds for why anybody would want to get a breach assessment ever.

Going through a mergers and acquisition, just you've had an IR, and you don't feel you don't feel that warm and fuzzy that you've caught everything and or you just really wanna be proactive and kinda engage in a threat hunt. Really, those are the three main the three main reasons why we see customers come to us for for the for this type of engagement. And, you know, any one of those three or all of them are kind of kind of fit fit that bill.

Yeah. Yeah. Something you just said is, like, you you went through the IR process, but you're like, did I get it all? Yeah. Right?

And and that's not like a scare tactic, but that's like a it keeps me up at night.

It it it it it and really, that's what makes the that's what separates the kind of clock in clock out from the the the proactive approach of doing threat hunting. Right? Is assume you're breached. Right? Assume you're compromised.

And that mentality at least helps you become not become complacent. Right? The last thing you wanna be do is like, oh, no. We're we're verified. We don't have anything wrong with our environment.

Right? Mhmm. The the the worst part of a threat assessment well, the worst part is you find something really bad. But on the other side of it, you might say, well, you didn't find anything bad. You still find things.

Right? You still find maybe misconfigured things, vulnerable things in the environment, opportunities like that there's gaps in the telemetry, you just don't have it. So you there is a byproduct that comes out throughout assessments that or breach assessments that I didn't really talk to or talk of, but those are the other things that that come that come out of it as well.

Yeah. I was gonna say too on top of that, Troy, I think out of our breach assessment discussions that we've had, no two have ever been proposed or or priced the same. Right? These things have been super customizable and flexible towards the client's environment. So whether it's we focus on your cloud environment or your attack surface management, your active directory, identity access management, the the network based telemetry, all of these have been very customizable.

And it's not like we just throw out a proposal and say choose what you want. The conversations are are very much inclusive of Troy and the team members that are actually performing the work. So we wanna make sure your team is totally aware of of what we would be doing as part of the engagement of the breach assessment.

Yeah. Yep.

I'm just gonna wrap up with Logan. How many of our customers do you feel come back? Like, how many of our customers are returning?

Not enough, Jason. But I think we hover around sixty, seventy percent, client return rate, which is amazing considering the industry of penetration testing is, you know, we recommend that you rotate vendors every few years. And, usually, when people get a hands on the report or get to work with our testers, they have such a good experience, they have a hard time not coming back.

Alright. So that's the sales pitch. That was us telling you what it's like to work with us, just being super open and and just letting you know. Like, here's what it is. If you wanna do it, we'd love to work with you.

Absolutely love to work with you. If not, no worries. We'll be here when you're ready. At some point, you might change companies. It could be six, seven, eight years from now.

We'll be here. We'll be here when you're ready. Alright, Deb. Give us your final final dev devism.

Dev. Just thanks for being here. I I say the same thing every time, but we appreciate your time. We appreciate you choosing to listen to us talk for two hours, sometimes two hours. And we love you guys, and just be kind to each other.

It's a lot of crazy stuff going on. So just hug kids, pet a cat or a dog, if you're allergic to cats. Get a cat. Get a dog. Get a plant.

I don't know. Just be kind. Be a kind human.

Here. Here. All set up with you. Yeah. All

set off script. I did. I went rogue.

100%. Alright,

Megan. We're gonna count down. 1098. Thank you, Troy. 20.

7.

Thank you. Awesome.

543. 3.

7.