Detections and Evasions for Configuration Manager Attack Paths

Josh talking about detections and evasions. Josh, please take it away. >> All right. Hey, good afternoon everybody. Um, so there is Josh Prager. Let me get this working. Um, so I I know it says principal consultant up there. Um, but I actually recently transitioned to a managing consultant. So now I'm delegating instead of doing all the things. Um, but when I wrote this, I was a principal consultant uh with Spectre Ops. Um, uh, I got my start in the US Navy doing IT help desk, worked my way up information assurance and eventually landed my way into the US Navy's red team. Um, where I did operations for a little while there and then I did a

complete career shift and went over to threat hunting. Um, they called me a reformed redteamer. I don't really like that term. Kind of makes me sound like, you know, a bad guy. Um, but I my my offensive background did help me in the detection engineering space and the threat hunting space. It kind of gave me a a unique perspective on the different techniques um that we can abuse against client environments. Um I'm also a NYU alumni. Oops. I'm also NYU alumni and this just got messed up. Uh oh. Give me a second.

I don't know which one to unplug because I don't want to break stuff.

>> Yeah, I bumped it real quick.

I quit the power. >> Okay.

>> All right. I gota be really careful. Okay. It's very delicate up here. Um yeah, so uh NYU alumni um got a masters in cyber security. Um, I'm a contributor to this project called Misconfiguration Manager, which is kind of like the the majority of this talk. Okay, so show of hands. Who has SECM in their environment? Or who has at least heard of SECM before? Few hands. Good deal. Okay, cool. Um, so too long didn't read. SECM is kind of the way Microsoft prefers uh well, it used to be the way that Microsoft preferred you manage your endpoints in your environment. Um, now Microsoft documentation suggests you use Intune. It's a bit more secure. Um but a

lot of organizations, a lot of clients still very much use SECM or or also known as uh configuration manager. Um and you know it was established back in like 1998. A lot of the best practices are significantly out of date. Um and so some of the things that Spectre Ops has been working on recently is uh abusing SECM and configuration manager in client environments. um that would enable us to essentially use SECM as our own command and control infrastructure. Um so a a story that I tell is I was on a red team op um about a year ago. Uh Garrett Foster was on this op with me as the red team lead. Um and he's also one of like

the um the more well-known researchers uh for configuration manager abuse. Um he made a tool called SECM Hunter. And essentially what we had done very quickly within that op was complete site takeover, which I'll talk a little bit about what that means in a little bit. Um, but we could basically do anything we wanted to any endpoint in the entire domain that was part of the SECM site that we had compromised. Um, and so we were at the end of this red team engagement and the client was like, "Hey, the blue team still hasn't caught you. Can you make some noise? Can you be like a little bit not so evasive just so they can like have some breadcrumbs to

follow?" and we're like sure. So I took that one for action and I tried to do these like real default cobalt strike methods of lateral movement just to give them something to look for, right? And um Gary didn't know that that was the goal was to be loud and non-invasive. And so he's like, "Hey, I saw you trying to laterally move this host over here. You want me to just cut you a beacon?" And I'm like, "What do you mean cut me a beacon?" Because we had site takeover, we could essentially, just like you can push patches to an endpoint, you can push payloads to an endpoint as well. So we simply told the endpoint, hey, reach

out to this file uh this file server, grab this payload that we're hosting and execute that payload all within the context of SECM and then magically my beacon appears, right? Um it almost felt like cheating. It was it was a little unfair. um I did feel like it was kind of unfair and so when they came out with this this misisconfiguration manager project um I opted to do the detection uh and defensive resources for it um because I I do primarily work in the detection space with threat hunting and detection engineering and I felt like I should like do my best to kind of even the playing field a little bit. So that's what this uh talk is going to be

about. I'm going to kind of give you a high level of some of the um the abuse paths that we talk about in our misconfiguration manager project and I'm also going to talk about the defensive guidance the detection guidance that I developed um most recently. Okay. Um so when it comes to configuration manager because it has been around for a really really long time and because best practices for it are quite outdated um there is quite a few different attack paths that exist. everything from enumerating credentials within pre-boot execution stores um to conducting reconnaissance across the infrastructure um all with LDAP queries to actually just taking over the entire primary site server right which if the primary site

server is where you're sending out patches updating software managing your endpoint compliance you could think that it could also be used for pushing out scripts um executing payloads all the malicious things Right. So because it was uh a bit difficult to come up with hierarchy takeover via NLM coercion related to MSSQL in a remote site database uh we came up with this project called misisconfiguration manager. Um and it essentially uses like a very similar taxonomy to MITER attack. Um we have five different areas of attack techniques that we're typically looking at. Reconnaissance, credential, elevation, takeover, and execution. Um, and then we also have defensive guidance within that project as well. You can just go to misconfigurationmanager.com.

It'll take you to our GitHub page. It's all just an open source project anybody can look at. Um, the defensive techniques, we have preventive guidance in there. So like mitigation guidance that can stop these attacks from being applicable in the first place. Um, I've also written a lot of the detection guidance um, about how to write your own custom detections that focus on the abuse of SECM. And then we also talk about some deception techniques in there as well. Okay, so the original misconfiguration manager project was created by uh three of my co-workers at Spectre Ops. Uh Dwayne Michael, Chris Thompson, and Garrett Foster. Um I just simply attributed to the defensive portion of the project. Um

like I said, it kind of uses the similar concepts to uh the attack miter matrix and it also contains step-by-step guidance. So, if you are in here um and you are an offensive practitioner and you want to know how do I abuse SSCM in my client environments, there is step-by-step guidance um how to validate that these techniques can be executed um as well as step-by-step guidance for the defensive portion as well. We've mapped out quite a few techniques and we're always constantly coming up with new ones. Um uh we're actually usually coming up with more techniques um than we have time to actually jam into the database. Um but we are uh constantly working on this

project. It's a really really fun project and it's a it's uh a representative of the current and latest tradecraftraft that we use. Um we're using uh SECM abuse um almost on every engagement uh where the client has SECM or configuration manager implemented and we're very successful at it. Um I have I had someone else ask me earlier today, have I found any threat intelligence documentation showing that like adversaries are using this? Um, I haven't found any threat intelligence uh indicating that adversaries are currently using um configuration manager SSM abuse, but that just might mean that they're able to achieve their objectives prior to needing to abuse SSM. But abusing SSM in most cases is what I

would consider trivial. It's not um it doesn't take some kind of complex, you know, vulnerability that exists out there. It's like things that are native to your environment that enable your environment to work successfully like basic NLM authentication, things like that. Um that we we as Spectros specialize in abuse instead of exploitation. And what I mean by that is we're often using what the client has configured in their environment against them instead of throwing some endday or zero day at some as some you know exploit code out there. Um we're we're we're pretty successful at just abu abusing what's already been implemented successfully. So um why do I care about this? Right? Um configuration manager

attack paths often lead to uh the management of critical assets. Um I've seen I've not yet run into a client that does not manage their tier zero infrastructure with SSM. Um so that means if I can run a script on someone's workstation, I can also run a script on someone's domain controller, right? Um additionally SSM typically uh like the client binary itself called CCM Exec.exe exe um has the ability to run and execute at local admin privilege. So essentially they can elevate to system privilege. Um and with that integrity you can you can dump credentials, you can generate new local admins, you can do whatever you want. There's there's really not nothing stopping you there

and that's necessary, right? Uh uh that that binary has to execute with local admins to be able to install patches, execute updates, you know, you name it, right? Um, additionally, the reason that we target configuration manager is that we frequently find misconfigurations. Um, uh, one of the one of the folks, uh, Chris Thompson gave a talk at a configuration manager Microsoft focused conference about these techniques and he was really surprised that like the audience at the end of the talk was like, "Yeah, that's cool, but like my goal is to make sure it works. I don't really care about, you know, defending it or or stopping its abuse." And it's like, yeah, I mean, I get that. your

average security engineer is just really concerned about does configuration manager work today as compared to yesterday versus like can it be used as a C2 framework. So I mentioned site takeover. So site takeover is a pretty um it's pretty advantageous to red teamers and to attackers. Um the reason for that is a lot of times what we find is multiple sites under one centralized site server. Um, and a lot of times each of those sites will represent maybe one to many domains. So, for example, you might have the New York site, you might have the California site, and you might have the Midwest site. Each one of these sites has like 10 to 20 domains within that

site, right? Um, site takeover is a really, really dangerous attack path because it essentially replicates the database of the site server to every other primary site server database. So if I make a change in New York, I also make that change in California. I also make that change in the Midwest sites as well. Um it also enables me uh to push whatever I want to any of those clients. Um so it's a it's a it's a very powerful domain compromise scenario if done successfully. Um site takeover essentially leverages NLM coercion and relay. Um there's been a lot of talk about coercion and relay recently. Um the the a lot of the a lot of the more mature red teams are using

coercion and relay pretty frequently. Um essentially the way it works is you coersse you trigger authentication from a particular server or particular uh endpoint and you take that that triggered authentication and you just pass it on to something else. Um what we found in Spectre Ops is there's a lot of uh implementations where the um there is this implicit trust between two or more endpoints. A perfect example of that would be in configuration manager where configuration manager is essentially like a front-end site server and a backend database server and these two implicitly trust each other. So much so that if I have rights to make a change on the database, I also have rights to

change something on the site server. If I have rights to change something on the site server, I often have rights to change things on the database. What we can do with coercion and relay is I can coersse the database's credentials and shoot those over to the site server. And now the site server is implicitly trusting that authentication. And I can tell that site server to do whatever I want such as add a new SECM admin or add a user to arbback admins, things like that. Okay. Um, another reason that uh, takeover is so dangerous as well is um, typically it's it's going to be able to run in the context of local admin on on

just about every system within that site. Okay. Now, if you've never looked into SSM before and this is all brand new to you, that's absolutely okay. When I was doing help desk, I remember like my team lead was like, "Hey, this is the SSM admin password. Make sure you protect that with your life because it could be really bad if someone messes it up. And I was like, "All right, sure." But like I didn't really understand the context of it. I mean, fast forward 15 years and now our red teams are just now getting into the point where we're abusing SECM and we're seeing the impact of being able to distribute payloads at scale across multiple domains and trust

boundaries all at the same time. So um if if this is all new to you, I'm going to do my best to kind of like explain it in a in a digestible way so you can understand the impact and then also talk about the defensive guidance. Okay. Um all right. So what this talk is going to talk about I'm going to mention uh I'm going to talk about the new updates that I've made to the detent the detection portion of our project. So um I've written detections for monitoring application deployment monitoring group membership changes uh monitoring uh group membership changes within the database server itself. Um we'll also talk about enumeration of the SMS temp

folder. um monitoring the wind regge namepipe connections and then monitoring local SSM files that are found on every single SSM client in your site. What we're not going to talk about is every offensive technique that is in the misconfiguration manager project. I'm not going to talk about specific preventive controls. Um and then I I just don't have time to go into like super comprehensive for every part of this, but I will have time at the end for questions. So please definitely ask me questions. All right, so let's start off with monitoring application deployments. Remember I mentioned that you can push out patches, you can push out applications. Um, if I want to and I and

I'm an SSM admin, I can push calc.exe to every host if I want to. Um, you can also do a lot of other things with it too. You can also refer to other payloads or binaries that are stored in other locations of the network. So perfect for example um if I have completed site takeover and I'm able to push out patches via SSCM I can essentially tell a endpoint such as a domain controller hey I have a binary that's hosted in this UNC path go and grab that binary and execute it right I can also do the same thing with scripts but typically the operational flow for the way this works is you have to create

a collection um that collection is going to have a a scope of devices you're going to create an an application that matches that scope. So that's where you would say like, hey, push beacon.exe. Um, you're going to have to create a deployment and you initiate that deployment. Okay, we can use each one of these bullets to essentially write a detection. So we'll start off with kind of the defensive piece of this. Um, there is a log within SSM called the status message Q. Status message Q logs um are typically not ingested by most of my clients. out of all my clients, I've only found one that actually ingests these logs, and they were surprised that they

ingested them. They weren't they didn't even know they had these logs. Um, but most of my clients do not ingest these logs. Uh, these status message Q logs have message IDs that correspond to a collection being created, an operation being started, a push being initiated. The way that the message log works is it's essentially two different pieces of a puzzle. You have this file called the SMS prov.log. It lives on the site server. Remember I told you the site server has this implicit trust to the database server. So if you were just to go and win log forward the SMS prov.log file, right? You're going to see things where it says like user and you'll see

an SQL query initiated deployment of SQL query to devices SQL query because the SMS prov.log is only half of the equation. Those SQL queries have to then go to the database server and actually correspond and answer those queries and then together SSCM puts that all into the status message Q log. Okay, there are ways to ingest the the full auditing messages. Um I know Splunk has a blog about it that's a bit old out there. Um but it's not easy. Every time I've played around with it, I've had a hard time doing it. Um the message IDs that can be captured to identify this. So this is a what we call a detection data model. Um, so our goal here is to kind

of just show all the different sources of telemetry and we can pick which ones are the most operational depending on what we're ingesting in our environment. Um, but we have these uh 300 messages. So a user created a collection, a user created an application, um, a user created a deployment and then there's this four uh this 40,000 message uh 4800 where it actually shows the user initiated that deployment. Okay. Um, one thing that I have seen for this is um, a lot of the a lot of the tooling that we write that abuses this technique um, we we basically jam in gooids for these deployment names and we do that on purpose. That way if an adversary goes

and tries to just download our tool, doesn't modify it whatsoever, doesn't check the code and just runs this um you can you can try to identify these goo just like a GID name task name showing up with an SSM deployment log and that would be a big indicator a big signature um related to our tooling. But if they do something like push out a beacon.exe exe file um and they do it and they name it like team server update, you would you would ingest the logs, but really the only indicator of something nefarious going on would be like the the user that's actually doing it. If you have a user that has never previously been part of SSM admins

pushing out deployments, that would stand out as suspicious and you'd really only be able to identify that with these message IDs. All right, this talk does talk about evasion as well. Um so some of the ways that adversaries could evade this um instead of pushing out applications like beacon.exe exe uh adversaries can push out scripts. All right, scripts have different message ids. Um, and the way it gets executed is there is this binary on every SSM client called CCM Exc.exe and it's going to initiate PowerShell.exe to execute that script. It generates significantly less or at least half of the message IDs the other one did. Um, you have 52500 with script created and you have 52501 script

executed. Um, there is this script approval that can be enabled. I know I said I wouldn't talk about preventative guidance. Um, who here has heard of the term twoperson integrity, right? Few people. Okay. So, you can actually turn on twoerson integrity within SSCM so that you can't just have one person shoving out scripts whenever they feel like it. Um, you turn on this twoerson integrity feature within SSM and one person will have to upload a script and the other person will have to approve the execution of that script. However, it is like a um it is a optional feature. So, uh if the adversary is elevated enough, they could just turn it off. All right, here's what it looks like. I

know you can't see that from back there. So, um I'm going to show you another slide or another screen in just a second that'll show it a little bit closer, but this is what it looks like when it's executing. Um so, the parent image is going to come from CCM Exec.exe. Um the actual image that's executing is PowerShell.exe. And then if you notice here, the way that CCM Exec will execute any script in the environment is by doing this PowerShell non-interactive execution policy remote signed. And then it'll do like an invoke command. Um, and if you notice there's like a GOID in there, that SMS TCM script store and then that GID that's just like kind of a

a SSM ism. So if you're seeing that in your environment, it doesn't mean someone is maliciously pushing out scripts, but it could mean that. um the way that SSCM executes scripts whether legitimate or malicious and it always assigns these gooids to these script files in the script store. It's very frustrating from a threat hunting perspective. Okay, so moving on to group membership changes. Um so there are these two groups that are pretty important. Uh remember I told you that the site server and the database server. They have these implicit trusts with one another. So you have this local security group on the site server called SMS admins. Okay. Um when you add a user to SMS admins local

security group SSM will automatically transfer that user's account over to this table in SQL called arbback admins. And they essentially mean the same thing the ability to read write um to a particular SMSWI provider. It allows users to execute API calls against SSCM. Okay, this is a very juicy target to adversaries. If you don't have auditing for this local security group turned on, I highly suggest you do because it would indicate if a user was removed or added to this group. If you add a user to this group, they would have full SSM administrative control of your entire site, which remember I said the databases replicate to one another. So if you add it to one site, it replicates

to all the other sites in that in that primary site servers domain. All right. So talking about defensive innovation, we'll start with detection. So like I said, you can audit the addition to that local security group. There's an event ID 4732 which shows a new member added to a local security group. Um, additionally you can set up custom SQL auditing on the SQL database server itself and indicate anytime there's an insert into that arbback admins or arbback extended permissions uh table. Um the the custom SQL auditing is super easy to set up. Um it it was quite trivial. If you go to the misconfiguration manager project and you go to that detect six description in

there, it actually gives you an example that you can just copy and paste into your uh your SQL database server and it'll essentially audit those particular groups um anytime there is an insert. So in this case we see the object name arbback admins as being the table. We see an insert into arbback admins and we see that this test subject one was the insert. All right, everything I just said in a data model, so we're not going to go over that one again. Um, so how do we how do how do adversaries evade? How if you are a red teamer, how would you evade this? Right. Um, so it's kind of difficult. Uh, there's there's not a way to truly evade

um generating that local security group auditing if they are if they are actually auditing it. if it makes you feel any better from an offensive perspective. I have yet to actually see a client audit that local security group, though they definitely should. Um, but typically what I see in those local security groups for the SMS admins uh local security group is that it is actually referring to nested groups and with an active directory. So, I usually don't see like Josh Prager is an SSCM admin and the SMS admins local security group. I'll see local security group SMS admins with a nested group of SECM tech admins which relates to active directory and distributes who those members are

that way. Um, so you're kind of it's not really an evasion. You're just kind of trading one technique for another, but you could go after those nested security groups if you're privileged enough instead of actually trying to manipulate that that local security group. Additionally, there is a way you can just do a direct insert into the arbback admins table, but like I said, it's trivial to turn on auditing for that and it's very clear when someone manipulates it. All right, moving on. Uh, so this is kind of moving off of like site takeover techniques and moving onstead how to identify credentials within the SSM environment. So, uh, show of hands, who works for a client or has worked for

clients that use Pixie Boot? Okay, few hands. Cool. Um, Pixie Boot's been around for a long time. I just worked a red team where they were like, "Pixie Boot is deprecated." And I'm like, "All right, well, it's still there." Um, but, uh, the way you can essentially abuse Pixie Boot is, if you think about it, right, Pixie Boot enables us to just to plug in a bunch of computers and automatically have up-to-date operating systems running on those computers. you probably need some kind of domain cred or some kind of highly privileged credential to be able to just automatically get everything on the domain up to date in the correct gold image operating system, right? So, a lot

of times those credentials are actually stored in these things, these likevar files. And the way that they're stored is they're stored in this distribution points um SMB folder called rim inst or remote install. Um, when you configure an operating system or when you configure an endpoint to use Pixie Boot and you plug it into the environment, if it's configured to use Pixie Boot, it's pre-programmed to basically look for a distribution point and look for this rim inst. Um, attackers have a lot of tools out there uh that will abuse this. There's a tool called Pixie Thief. There's also Pixie. Um, and essentially what they'll do is they will mimic that same behavior. They will scan for

distribution points. they will scan for the rim inst share path and then once they access the rim in share path they're going to spider that that uh share path and look for these var files and then they'll do a couple of parsing and conversions to figure out what the actual credential is. Um once adversaries have that credential they can then propagate in the environment. Okay. All right. So for a detection data model, we have a couple different sources of telemetry that we can use. If this anomalous process is making a connection to a distribution point, we can definitely identify that with sysmon event ID 3. Um, and then you're going to hear me say this maybe once or twice,

but my favorite event ID of all time is event ID 5145. That is detailed fileshare auditing. You can use it for namepipe events. You can use it for um share path events. You can use it for configuration manager detections. You can use it for a lot of different types of reconnaissance detections. It's a very very powerful event ID that unfortunately a lot of clients do not enable. Um but you can use this detailed file share auditing to see a process connecting to this rim inst um share path. Uh we actually had a client that had removed pixie uh configurations from their environment. Um, and I actually suggested I was like maybe stick a few out there as a canary. Um, and then set

up auditing for that event ID 5145. And if you ever see anything trying to connect to your rim in share path, you have a pretty clear indicator that someone is trying to abuse pixie creds in your environment or maybe someone misconfigured their operating system to use pixie boot. That could be the other false positive there. But other than those two scenarios, it's it's pretty obvious when someone is trying to enumerate u pixie credentials. Um, additionally, it's not only going to stop at that rim instar path, it's also going to find a folder called SMS temp. Within SMS TIP is thesevar files. And so, if you see a process accessing thesevar files, that would be a pretty

clear indicator of looking for credentials in these variable files. All right. So, how do we evade this from a red team perspective? All right. So um one of the things that I've noticed is that a lot of LDAP searches or a lot of these offensive tools that are searching um for these rim inst share paths will first have to figure out what the distribution points are because these are only hosted on the distribution points and the way that they go about identifying what the distribution points is they typically are just using LDAP queries. Now I have only had one client actually log LDAP queries in their environment. uh actually two two clients and they both

did it in kind of funky unique ways. Um most of my clients are not uh logging LDAP filters. So you can run Blood Hound all you want. You can run these distribution point reconnaissance tools all you want and they'd have no idea because they're just simply making LDAP queries. Um, but of the really tough clients of the of the really good defensive clients that are ingesting um, LDAP telemetry, whenever a um, a tool is looking for the LDAP filter of object class remote install, it's pretty clear that they're looking for this remote install share path. Um, some alternatives, some some offensive alternatives to just straight up LDAP querying the L out of your client environment. You could do a port scan.

Uh, there are specific ports that are related to SSCM Pixie credentials. uh or or Pixie boot configuration. Um so port 67, 68, 69, 40, 11, and 547. These are all ports that are typically open and listening on distribution points specifically. Um so that would be a pretty clear indicator that there is a distribution point and that it may or may not have Pixie enabled. to identify if it has pixie enabled, you can just simply run a remote registry query command um where you're going to query the HQM software Microsoft SMS distribution point uh value and you can look for the is Pixie or Pixie responder enabled or Pixie installed value. If it's set to true, you know that they're

using uh Pixie and then go about targeting them. Okay so there are other ways that we can identify SSM infrastructure. So part of red teaming configuration manager is it's pretty easy to figure out what the site server is. Um it's actually relatively trivial to figure out what the site server is distribution points and management points are in an SSM environment. What is really darn hard is figuring out what the database server is. And remember I told you um the way that we do site takeover is with this implic implicit trust abuse, right? Site server trust the database, database trust the site server. I need to find the database server to make this work, right? Um and it and it it's hard to

find it. Um there's nothing really hanging out there or dangling out there that really indicates it. Um but from a local perspective, um you can identify what the database server is pretty quickly. Um so on every SSM controlled client, so you're it's a client endpoint that is part of a SSCM site. It's going to have these folders called C Windows CCM. Um within C window CCM you're going to have all these logs um SMSTS logs, CCM cache logs, CCM setup logs. All of these will contain um different points of infrastructure DNS names for the different points of SSCM infrastructure. So starting off with remote enumeration um we can use a lot of the similar data

models that we used uh when we're looking for that rim inst. We can use a network connection over SMB. Um, we can look for a n a namepipe connection over win regge. Uh, if you're if you're doing a remote registry query to enumerate details about SSM infrastructure. Um, typically you're going to do that over the winred regge namepipe. It doesn't happen too often. I've looked in client environments. I'm like, how often is Winred namepipe used? And it seems pretty pretty rare um that it's natively used. There was one client that had a bunch of like really legacy applications out there and they used Winred name ppipe pretty frequently, but that was kind of an edge case. Um, additionally,

you can set a sackle on this HKM software Microsoft SMS distribution point um, key and you can baseline what's what's generating that sackle event. If you can figure out what are the things that typically enumerate this versus what would be anomalous, it's pretty easy to baseline. Um, and then if you have LDAP ingested and LDAP queries ingested, um, which like I said, most clients don't, you can use this event ID 1644 and it'll show you anytime someone tries to enumerate that SSCM infrastructure. The LDAP queries that most tools use will literally be like LDAP filter query star SSM star or star MECM star. So it it stands out pretty clearly from a defensive perspective. to avoid that um I have seen a client

pick us up doing SSM SSM infrastructure enumeration by catching us doing mass LDAP queries um in a short time frame. Um so what they were doing was they were cataloging every LDAP query that every user made and they had a threshold if a this is what we baselined and if anybody goes above that threshold for this amount of LDAP queries made in the environment initiate an alert. Um that actually caught us one time. We had a deconliction for that. Um so one offensive um evasion technique would just to be simply um be careful of how many LDAP queries you're making in a single point. Maybe wait a little bit, space it out a little bit. Um don't just

try to mass scan the environment with LDAP uh LDAP queries. Um, additionally we like I talked about we can use uh the C Windows CCM and look at those logs that are local to that CCM uh the SECM client controlled endpoint instead. Right. From a defensive capacity we can detect anomalous um anomalous uh read of those files. Um so you can set a sackle on the C windows CCM folder. Um, and then it's it's typically what I've seen is only system is the one ever querying or doing any sort of reads in these log files. If all of a sudden a domain user starts cracking open these log files, that would be kind of nefarious looking,

right? All right. So, this is all the resources that I have on there. Um, that takes me to the talk. So, questions. Uh, who's got questions? What's up? I'm on my way. I'll ask you just say your first name and your question, please. >> Hi, I'm Matthew. I was wondering what kind of network protocols is SECM going to be using? Is it just SMB or is it going to be using a variety? >> Um, so typically it's communicating over HTTPS um between the endpoints and the actual distribution points. Um there is some SMB that occurs um but it's typically going between um like really weird edge cases um between the site server and the database server. Uh

it's communicating over these like WI SMS providers. So there's there's different WI uh providers that can be called. Um the site server is communicating to the database server, the backend database server over uh these WI providers. It's called the SMS provider specifically. Anybody else got questions? >> There's got to be more questions. For those that haven't asked, we've we've asked to have the temperature turned up in this room because we weren't refrigerating lunch in here. No other questions on this. >> All right. Um, absolutely fine. So the way I like to write my slides is I like to write them in a way where you can just download them, take them home and if you are ever in a scenario where your

boss is like, "Hey dude, threat hunt for SSM abuse or hey I need you to write custom detections on SSM or you find out you you're a pen tester and you find out the client has SSM in the environment and you're trying to remember how to do all this. I write my slides in a way to be kind of like just pulled up so you can quickly look at them as notes. Um you can use them as data models. you can do whatever you need with them. Um, so I think Bside San Antonio does this thing where if you look it up on the site, like the Bside site in the different talks, I think it's in like the

resources section where you can download the presentation. Um, I'm a big fan of the um, the Zeronites security conference. Um, and I always liked how I could just use any of their slides and just pull them up and if I have to do some particular type of threat hunting engagement where I need to query things that are trying to access LSAs or whatever, I can just look up those slides. Um, that's the way I wrote my slides as well. Um, so definitely download them. You if you find yourself in a configuration manager, offensive or defensive situation, definitely take a look at them and also take a look at the misconfiguration manager project. Um, because we're constantly updating it.

When I have time, I try to update the detection stuff to, like I said, even the playing field. Right. Thank you all so much. Right, Josh? Thank you very much. And please accept this little token of our appreciation. And then thank you very much. Job well done. It is a cold room. I know it's a tough room, but but thank you very much. Well done. And by the way, if you didn't know, these sessions are being recorded as well. I just want to make the announcement. Um, the locking rout is doing right now.