The CrowdStrike Settings That Actually Stop Us | Ep 191

Two pen testers have spent thousands of hours inside client networks, and the most common failure they see isn't a missing security product — it's an EDR nobody ever tuned.

In this episode, Spencer and Tyler open up the CrowdStrike Falcon console and walk through the specific settings that decide whether your team catches an attack or never sees it. They start with the story that kicked the whole thing off: Tyler running a pen test where every AMSI bypass gets blocked and detections fire left and right, while Spencer runs nearly identical tooling against the same product at another client and the SOC sees nothing all week. Same CrowdStrike. Same version. Different checkboxes.

From there it's a tactical walkthrough of Endpoint Security → Prevention Policies and the settings worth your attention: Enhanced Exploitation Visibility, which unlocks command-line and PowerShell telemetry that Microsoft disables by default; Enhanced DLL Load Visibility for side-loading attacks; WSL2 Visibility, which closes a sandbox threat actors have been using to run Kali tooling under the radar; memory scanning for in-memory C# tradecraft; Office malicious macro removal; file system containment for ransomware over SMB; vulnerable driver protection, the direct mitigation for BYOVD attacks and EDR killers; and cloud-based anomalous process execution for living-off-the-land binaries.

They also cover custom IOA rule groups for blocking unauthorized RMM tools, centralized firewall policy management, device policies for USB control, and a warning on exclusions — especially wildcard paths, which Tyler calls a threat actor's best dream.

The takeaway is simple: you're paying real money for EDR, and default configurations aren't giving you what you paid for. Open your console, work through the settings, test them against an IT pilot group, and enable what fits your environment.

TOPICS COVERED

- Why EDR vendors ship deficient defaults on purpose
- Enhanced Exploitation Visibility and the telemetry gap in PowerShell attacks
- DLL side-loading, WSL2 abuse, and vulnerable driver attacks
- Memory scanning and in-memory tooling detection
- Blocking RMM tools with custom IOA rule groups
- Exclusion hygiene and the wildcard path problem
- Device policies, USB blocking, and insider threat

Sentinel One and Defender for Endpoint are next — let us know what else you want covered.

Blog: https://offsec.blog
Work with us on an internal pen test: https://securit360.com

Blog: https://offsec.blog/
Youtube: https://www.youtube.com/@cyberthreatpov
Twitter: https://x.com/cyberthreatpov

Follow Spencer on social ⬇
Spencer's Links: https://spenceralessi.com

Work with Us: https://securit360.com | Find vulnerabilities that matter, learn about how we do internal pentesting here.

Transcript

Spencer: 0:06

Tyler and I have done 1000s of hours of internal pen tests over the last couple years. I mean, combined, you know, just me alone in 2025, I have 1000. Tyler, you have probably close to that as well. So over the last five years or so are doing this. Tyler and I have pen tested hundreds of organizations and 1000s of hours of internal pen tests. We have seen clients across all different industries: financial services, manufacturing, healthcare, universities, municipalities, like you name it, and of all sizes, and one of the most common failures we see is lack of detections or just poor security monitoring threat detection. So in this episode, we're going to talk about CrowdStrike specifically and some of the very critical, crucial settings that we think need to be enabled, that directly have impact on your ability to detect malicious stuff, suspicious stuff on your endpoints. But they're also really important for the telemetry that you gather and are able to get once you turn those settings on. So I think it makes sense to start out with stories, story time on this because we're going to talk about EDR and threat detection and evasion and all these kinds of things in this episode. But we see this all the time, so it makes make sense to share some stories of why why this came about and why we're so passionate about it. So Tyler, why don't you share a little bit of background story on that, and then I'll fill in any blanks.

Tyler: 1:42

Yeah, to kind of open Spencer and I, anytime we do engagements, we have a section within a platform that we use for note taking called Nucleo, and we'll keep notes on what's detected, what's not detected by an EDR that we're going against. And week after week, that makes it easier for us to check our notes and see. Okay, this technique still working, or this one needs to be improved. But we also collaborate in messages, and there'll be some weeks I'm doing a pen test, and I am getting zero headway. I'm getting blocked everywhere. Every Amzy bypass is getting blocked. None of the tooling I have is working. There are detections left, right, and center for me. And then Spencer is also running against CrowdStrike, and he'll be like,"My client hasn't seen anything this week so far. And so that kind of got us thinking: Why are there so many differences even within the same product?

Spencer: 2:40

Yeah, and it's funny because there's a couple reasons for that, right? And one reason is that the client doesn't know where to go in the EDR to see those alerts and to see the activity that's happening, and that's very common. That's something that we see in purple team engagements all the time. Is we'll start going through the you know the techniques, and the client won't necessarily know where to go to look, and it's part of that engagement is an education training process for them to learn where to go and what to look for. But the other side of the coin is the telemetry is just not there, and that's a very real possibility. And we run into this a lot of times where I will run an AMZ bypass that we know is getting detected by CrowdStrike, and I will run it on an engagement, and it'll work fine, and no alerts, and especially for a client that knows where to go, they have a soc, you know, they they know where to see the alerts and where to get the telemetry, no alerts, and then Tyler will run the same exact AMZ bypass, and it'll get alerted. Same CrowdStrike, you know, very similar versions, but the difference is the settings that are enabled in the CrowdStrike console, and so that's what we're going to talk about now. Is the settings that are out of the box from these EDR vendors are many times not ideal, and many times they're they're deficient. Like they they're terrible at detecting what should be detected or what what somebody would expect to be detected on an endpoint. So Tyler, I don't know if you want to pick one or start one, but I think this is a really important conversation, and this is going to be like a really tactical episode for you guys. So, if you have CrowdStrike, you know, make notes or refer to the show notes and go check this stuff in your console to see if this stuff is turned on. Because if not, you are essentially not able to detect quite a bit of stuff.

Tyler: 4:40

Yeah, and for everybody out there, the section that we're going to start with is prevention policies. If you're in your CrowdStrike console, hit the hamburger button, go to Endpoint Security, and then there's a subsection called prevention policies. That's what we're going to be discussing first. And to kind of build on what you were saying earlier, EEO. Requires tuning both to the environment and the devices that it's being placed on. CrowdStrike has a few sections that you'll notice. It supports Mac, Linux, and Windows configurations. You'll notice other sections are just Mac and Windows, so you can create custom detections. You can create custom exclusions based off devices. So it's really, really meant to be tuned, and that's why out of the box it is kind of deficient. Is because they want to allow that tuning for your environment and not tune it for you.

Spencer: 5:30

Yeah, 100% out of the box configurations for EDR are not good enough, and if you're not tuning it, if your SOC or MSP is not tuning it, you are falling behind, and you will miss stuff because of it.

Tyler: 5:44

Yeah. So, kind of the first setting that I want to talk about that I think provides a lot of benefit and doesn't have any performance impact. In fact, this is a setting that will just give you extra telemetry, just because it's called enhanced exploitation visibility. If you're looking within CrowdStrike prevention policies, it is a checkbox setting. Now, for any of these settings, if you guys want more information, you want CrowdStrike recommendations, click the policy that we're discussing. You can see CrowdStrike's description. We're obviously not going to go as in depth, but we're going to give a high-level overview of some of these settings, so enhanced exploitation visibility. Specifically, the reason Spencer and I like it is it is enabling extra telemetry that is disabled by default by Microsoft, and this telemetry includes productivity apps such as Adobe Acrobat, Microsoft Word. But the thing we love the most is extra telemetry from command prompt, PowerShell, PowerShell IAC. So your command line interfaces, you are going to get more out of. Yeah,

Spencer: 6:49

and the reason we like this is because when we do Prpl team engagements, and we see that the client is detecting or has visibility telemetry for all of the PowerShell stuff that all the PowerShell techniques that we are running, they have everything, and what that tells us is CrowdStrike is able to capture it, right? CrowdStrike is able to capture it, so there must be some settings that enable this or allow CrowdStrike to capture this telemetry, which is not enabled by default because of the reason we just said. Like a lot of times, a lot of our our post exploitation stuff goes unnoticed. So this is really really important because threat actors are still using PowerShell. They're using PowerShell for like click grab or the fake capture stuff where they trick you and say like you know control you know press Windows key R and press Control V and then it's like a long PowerShell encoded command or something.

Tyler: 7:45

If

Spencer: 7:45

you don't have this setting enabled, you might miss that telemetry, which means alerts can't be created off of

Tyler: 7:53

it. It's also very very important for DFIR. If you're missing command line that's ran that wasn't tied to a detection, or wasn't included in your alert, you're missing a lot of crucial information. If the only thing, I guess, the best example I have is clients in the past have shown me alerts, and the only thing I see in the alert panel is Miami bypass. That's the only command line that was captured, but that is step one of an attack chain that I am now going on. So, if you're missing, let's say, Power View being loaded, and then share enumeration, etc. etc. you're missing all this crucial information that will paint a picture of how a threat actor moved in your environment and what they abused in your environment. The next policy that we'll talk about is called enhanced DLL load visibility. For any of these settings, by the way, when you click on them, CrowdStrike will recommend based off phase one, two, and three deployments. Phase one deployment being your fastest deployment for devices with AV that you don't want a lot of extra work in creating exclusions for and things of that nature, but enhanced DLL load visibility collects additional information on DLLs that are loaded into a process. This will prevent malicious DLLs from being side loaded into applications. So this is a great setting just at a base level to give you that extra visibility into some common attacks that are abused.

Spencer: 9:24

Yeah, DLL side loading is a very common technique for threat actors to use to get their payloads running. This is you know not anything novel or new. And to excuse me, to have settings like this not enabled just reduces the visibility you have so much because DLL manipulation and DLL loading and hijacking and all that stuff is very very common for malware and for like initial stage zero type. Of work that threat actors do, so this is again another really important one that when you have disabled just means you're not seeing as much as you should, which means you can't create alerts on

Tyler: 10:12

it. And you'll notice for quite a few of these settings, all they're doing is giving you extra visibility into X, Y, or Z. The next one we're going to talk about is WSL two visibility. Is the name of the setting. Once again, this may not apply to every environment. So, if your environment doesn't leverage WSL 2, maybe you don't have any developers that are leveraging that, any IT staff that are leveraging that, you may not need this setting. If you do, I would recommend this setting being enabled only on the devices that it needs to be enabled on, and then you can leave it off your regular Windows workstations. But WSL two visibility again will give you visibility into the Windows subset system for Linux and give you additional telemetry and logs regarding WSL two.

Spencer: 11:00

Yeah, and this again, a known threat actor technique is to use WCL two, just like an isolated sandboxed environment, to run their payloads and malicious tools. You know, like if you have WCL two, you can install Cali, and you can install Impacket and NetExec and you know Metasploit and all that stuff, and potentially CrowdStrike wouldn't even see it without these settings enabled. So again, this is something that made the rounds. I don't know, like a year or two ago, it was like it made headlines. It's like you can use WL2 to avoid detection from CrowdStrike, and it's like there it is. There's the setting. Like go enable it.

Tyler: 11:40

Fantastic. Yep. Another thing, something threateners

commonly do: 11:43

load C sharp C utilities into PowerShell. When they click Run, those will load it into memory. CrowdStrike has a setting for that. It's called memory scanning with GPU or memory scanning with CPU. Now, this will I recommend enabling both settings on laptops that you don't have an integrated GPU, it will be CPU bound. But I think it prefers GPU just for performance considerations. If you have devices that don't have a lot of resources, I would consider that before enabling this setting. Again, CrowdStrike. If you click on the setting, if there are any performance considerations, they will be at the very bottom of the setting description. So go check those out if you guys have any concerns. But this will allow scanning and scraping of anything that gets loaded inside of memory. Specific techniques and tactics that Spencer and I do, such as loading, you know, obfuscated tools that are written in C sharp or C into PowerShell and then loading those, that will then get loaded into memory and then will get scanned and then we'll get detected. So I think this setting is great for just additional protections around even command line interfaces that are commonly used.

Spencer: 12:56

Yeah, and if you remember, you know when mal or when fileless malware became a thing, right? When Amzi was created, or just before AMZ was created, this this memory resident malware, if you will, or offensive tooling, things like that, was very popular. And the part of the solution to that was to read memory and look for malicious strings, or you know, strings of known nefarious intent. Like looking for even researcher names will trigger it sometimes. Like if you run a script with some of the creators of you know like Power Review or Bloodhound or Certified and things like that, sometimes even that would trigger detections, so the a lot can be done to look for suspicious strings in memory, and again, and just another one that it's like layers, right? Like not any one of these is going to be perfect, but you add all this together, and now all of a sudden you have much more telemetry to go off of and to work from than you originally had, which just makes the chance to detect threats higher, and that's the goal, right? Is like we want the best opportunity possible to detect threats, and we want to use our investment as much as possible. Like you're paying a lot of money for EDR, you might as well turn on all the possible features that you can enable that are safe and you know that support your environment. Like you obviously don't want to crush all of your machines and nuke them, like so they can't operate anymore. But if it were me, I'd want to use all the features I had available to me.

Tyler: 14:37

Yeah, I think that's a good note. And all of these settings, Spencer and I have kind of discussed previously, and a lot of these impact our personal pen tester processes that we use in environments. And if that's true for us, it's also going to be true for threat actors because that's who we're emulating. So it's going to give us a bigger headache, which means inherently it's going to give threat actors a bigger headache, meaning your environment's harder to attack. You're more secure as a. The next setting is Microsoft Office malicious macro removal. I don't think this is necessary to have on every machine. I don't think this is necessary for every market vertical. If you're not regularly handling documents that will contain macros, you may not need this setting. Now you can just have it check boxed if you want the extra security. I think that's fine. I think this is important for people like accounting folks that are commonly dealing with documents going in and out, downloading documents, and then law firms are a market vertical. I also think this would be important for another vertical that is just handling documents all the time, but this will allow CrowdStrike to analyze and quarantine any office file that it finds malicious macros inside of. This was a trend. I don't know when was malicious macros probably a year ago. It was really popular before Market the Web was implemented on documents that were downloaded from the internet. A lot more popular than, however, I still think this has benefit if you are handling a lot of documents that are Office related. Removing those macros prior to execution of them just completely saves a machine and a headache. You know, re-provisioning a machine that's now being compromised as a result of those macros.

Spencer: 16:23

Yeah, I think macros for initial access has definitely gone down quite a bit, especially in favor of like click the click grab capture type of scams and you know like what what do they call it adversary in the middle or browser in the middle, kind of thing, where it's like you know, threat actors are trying to do credential theft to steal your Office 365 or Microsoft 365 tokens and session keys and stuff like that. Like that's more common from an initial access standpoint now than macros because of what Tyler said, mark of the web because of ASR rules and like EDR is getting good at at identifying processes spawned from Office applications. Like if you spawn PowerShell from Word, like CrowdStrike is going to see it. You know, like it's just very obvious. But this is one of the things that helps prevent macro-born threats. So there's really no downside to turn this on, other than potential performance impacts. But you have to, you know, try it for yourself and weigh those, you know, the the cost benefit of that.

Tyler: 17:36

The next one I feel like is very important across the board. It's called file system containment, and this enables your CrowdStrike sensor to respond to malicious remote file system system activity. The example that CrowdStrike gives is ransomware attacks over SMB. That is what this setting is going to help prevent. It is going to isolate the account in question that is performing the activity, the endpoint is also going to be impacted, and it's going to stop these attack chains before they get to the point of no return. This is a setting. Anywhere I see the word ransomware, I know that's what a lot of organizations are concerned about. This is a setting I would go read up on and see the full implications of enabling it. If your main concern is ransomware, CrowdStrike gave an example that include includes ransomware as a protection for this setting. So, I definitely think this one is worth enabling. If this is a major concern of yours, I definitely think this one is worth reading more into as well.

Spencer: 18:39

Yeah, and part of this is like, like I said, it's it's layers of controls and it's layers of visibility that the EDR gives you, and these are again just a reminder. All of these are things that potentially are not currently enabled in a default deployment of CrowdStrike EDR, right? Depending on if you self-manage or you have an MDR provider, a lot of these settings might not be turned on. So you might have a contract with an MDR provider, and you might not have these settings enabled. So again, just a reminder: go check these settings, or ask your vendor to check that these settings are enabled, or what the status is of these.

Tyler: 19:20

And as a note, we are still in the prevention policies page, so we have not moved on yet. There are just this many settings, and again, this isn't every setting in the prevention policies page. We've pulled out a handful that we think are beneficial, or prevent some common attacks, or will just give you extra telemetry. The next one, this would prevent local privilege escalation attacks, just as a note. But vulnerable driver protection. This the entire point of the setting is to prevent bring your own vulnerable driver based attacks. This is common in attacks such as Print Nightmare abuses BYO. Or local privilege escalation. This is a setting I think you should just have enabled. I don't know why you wouldn't have this setting enabled. This is using indicators of attacks and IOCs associated with malicious drivers. Implementing them, if those drivers are seen, it is then going to quarantine them and pop an alert for you. So, if your local Prevask is prevented, that gives attackers a lot less leeway on an endpoint and makes their job substantially harder of getting off of that endpoint.

Spencer: 20:33

Yeah, and if you've heard of, if you guys are listening and you've heard of EDR killers and things like that, like Terminator, all these EDR killers, they rely on these vulnerable drivers. So what they'll do is they'll use a vulnerable kernel driver, and they will run their malware in the kernel and kill the driver or kill the EDR processes and the DL DLLs and things like that related to the EDR. This helps mitigate that. Like this is a direct control or mitigation to help prevent those vulnerable driver attacks. This is very very prevalent with you know more sophisticated, I would say, threat actors. We see a lot of vulnerable driver abuse, but ran smart groups are using EDR killers too. So, just a good thing to have enabled.

Tyler: 21:30

And all of the settings that we've gone over so far are checkbox settings. The next setting we're about to discuss is at the very bottom of prevention policies as of the recording of this video. That may change in the future. However, it's called cloud-based anomalous process execution. The name, when I read it, was very, very misleading. This is why reading the description for these prevention policies is very important. Cloud-based anomalous process execution enables the CS sensor to identify malicious activity in living off the land binaries. Not very in tune with the name, I will say, but I think identifying malicious activity in living off the land binaries is superb. This uses AI-powered indicators of attacks to identify malicious activity within those binaries, then you're going to get alerts from that. At a base level, this setting is just going to give you more detections for command line processes. Maybe you're worried about HTA execution. That's another LOL bin. So there's quite a few Microsoft Windows-based processes that this will cover, and it already has a list of AI-powered indicators of attacks that it's using to identify these malicious behaviors.

Spencer: 22:52

Yeah, these lol bins, lol bins, can be used for a lot of different things. They can be used for code execution, so like the HTA example Tyler just mentioned, they can be used to execute code, which can run malware to like run a stage zero or an implant, something like that. They can be used to download additional tools, so like CertUtil actually can be used to download files. You can do a lot of interesting things with this. You can use MS Build to run C sharp tools, so a lot of interesting kind of abuses to LOL bins, and what's great is they're built into Windows, right? So they're inherently a little bit more trusted. Many of them are signed by Microsoft, so they're just a trusted utility in Windows. So again, another thing to have visibility on because a trend over the years has been threat actors are using more and more known, good, trusted tools, LOL bins, RMMs, etc. and they're using less and less malware. So this is a good one again to have enabled,

Tyler: 24:02

and this is a setting that you can set disabled, cautious, moderate, aggressive, extra aggressive. Click on the setting, read CrowdStrike recommendations, see how you want it applied to your environment. Create a test group would be my biggest recommendation, and have it ran against your IT staff. Run all the settings that we've discussed in a task group. See how they perform in your environment. See if you're getting a ton of extra alerts. The goal is not for alert fatigue for analysts or anybody that's viewing these alerts. It's just for more detections and more granular telemetry from your environment, so that is the benefit you should be getting. Not oh, we got 100 extra false positives in the console now.

Spencer: 24:49

Yeah. So we're gonna we're gonna move on the next section, but quick call to action. We're gonna talk about additional EDR products. I think I think we have Sentinel One on. Docket two to talk about. There's going to be other ones. So if you like this type of episode where we're talking through the different console settings and like what you need to turn on to detect us and detect threat actors and malicious activity, let us know in the comments or send us a message and let us know one if you like this kind of thing and two what other EDR products or security tools you want to see us talk about next? Because we'd be more than happy to do a deep dive into that and show you, I think, what works from our perspective. So let us know in the comments. So, Tyler, next section,

Tyler: 25:36

hamburger button, endpoint security, custom IOA rule groups. Now, if you're sitting today and you're like, we're not blocking RMM tools, we're not blocking X, we're not blocking Y, we're not blocking Z. This is where you can go to create custom rule groups to block applications. If you want to block RMM tools. I know there's websites out there that already have a list of all the common RMMs. I don't know it off the top of my head.

Spencer: 26:07

Lolrmm.io.

Tyler: 26:10

There we go. You can go there, pull the executables that run from those. You can pull the hashes that run for those. You can add those into your custom I/OA rule groups, you can have alerts fire if installations are seen, and I'm pretty sure you can also just outright block those from executing on the endpoint as well. So this is a great section to go and get additional tuning into maybe things CrowdStrike's not seeing that's important to you, or maybe things that CrowdStrike will see, but you just want extra alerting or protections around that. So custom I/OA rule groups again. You can go and create custom blocks, even for Windows-based applications. This gives you what Spencer and I call app control-a little bit of app control within your environment and allows you to block certain things on certain machines.

Spencer: 27:05

Yeah, this is great. And lolrmm.io has like a CSV, has a JSON. You can just download the rules or all the RMM tools and throw it into a rule and block all the RMMs that you that are in that list, other than the ones you use. And I mean that's that's so great. It's easy to do. It's like very little impact to your environment, and it's just it's just a why not? Why wouldn't you spend the 10 minutes to do it kind of thing?

Tyler: 27:33

And again, within this section, it's policy based, meaning this doesn't apply to every machine in your environment. You can create policies for your RMN blocks. Then you can apply that policy to XYZ host group. So this doesn't have to be blanket blocks across the environment. Again, these are policies that can be applied to specific host groups within your CrossTrike console. Now, if you want to get more central control around your firewall, I think endpoint security firewall then policies. This allows enforcement of firewall policies from a CrowdStrike level on Windows. This will disable the Windows firewall. It is the same on Mac and Linux. This setting can be applied across Mac, Linux, and Windows. So if you're looking for an easy central command to manage your firewall rules across all your devices, this is a place to do it. It will enable the firewall within CrowdStrike, and this will give you more granular control that you can spit out to your environment a lot easier,

Spencer: 28:45

and people a lot of people underestimate the power of the built-in Windows firewall. Just for everybody listening, if your firewall, if your built-in Windows firewall is disabled, then everything is allowed. We're talking WinRM, SMB, all the all different types of like TCP connections. You can ping host by default. And what's what's really important is that by default in Windows, you need to be a local administrator to modify the Windows firewall, meaning disable it or enable it or create or update rules. You need to be a local administrator, and if I'm an attacker on an endpoint and the built-in Windows firewall is disabled, that means I can just create a secondary c2 channel. I don't have to open up the Windows firewall at all. As long as I can get out to the internet, then I'm I'm golden. Like I don't have to create any additional firewall rules or or do any other manipulation of of that host. So having the local the built-in Windows firewall enabled is really really important. It's just a misconfiguration we see often.

Tyler: 29:56

And something I forgot to mention was endpoint security. Then exclusions. If there are specific exclusions you want to set in your environment, if there's a specific binary that you're getting alert fatigue on, you're seeing constantly it's not providing any benefit. You know it's a known good tool or process within your environment. You can go set exclusions. These can be path based. These can be certificate based. These can be hash based. So go check that out if you're trying to get rid of some common detections that happen in your environment that you know are known good. Just be careful with exclusions and be careful where you apply these because these could make you miss malicious activity in the future. So I would just be careful when setting exclusions.

Spencer: 30:44

Yeah, 100% This is not something you can see from the endpoint, but having a bunch of exclusions set is is can be very dangerous depending on what they are. So I would definitely echo that. Make sure you review them on a periodic basis. You know, if you have something that's going to be there long term, just make sure you review it. Make sure that that exclusion is still needed, because a lot of times what happens is you know people will set up an exclusion to test certain things, and then they'll forget about it, and it just stays out there, and then it comes back to bite them in the future. You definitely don't want that to happen,

Tyler: 31:22

and please do not set wildcard path exclusions. Please do not set those. Those are a threat actor's, you know, best dream right there. Because then, if they find that every tool, every process spawned from that file path, you're not going to have any alerts, no detections on. So be very very careful in setting these exclusions. The last section that we're going to talk about that's CrowdStrike related is endpoint security, and then device policies. As a note, this can only be applied on Mac and Windows. I did not see support for Linux as of this recording. That may change in the future. This allows policies to be set at a device level. The best example I can give is a policy can be created that blocks all USB devices that are plugged into a machine. Those USB devices will not register on the machine. If there's anything on those USB devices, it's not allowed to be read. They would require manual review and allow somebody with access to the CrowdStrike console to approve that USB to then be allowed on a machine. So policies at the device level can be set here again for both your Mac and Windows devices. And another note: these policies can be set to monitor only, or you can set them to monitor and enforce. So, if you want to create device-based policies and not get any alerts or enforcement, you can do that. Just set it to monitor-only mode. You'll still get the telemetry from that, so you can review it and see if there is any exclusions or modifications you need to make to that policy, and then set it to enforce.

Spencer: 33:02

Yeah, and this is one of those things that is maybe not directly obvious. The reason for it, one of the reasons is just you know data exfil, right? If you have, if you're worried about insider threat, somebody plugging in a hard drive or a thumb drive and like siphoning out all the data, this is one way to to help mitigate that. The other reason is there are devices that can resemble like a keyboard, and when you plug them in, they will they can execute code. If you're familiar with rubber duckies, that's like the concept behind behind rubber duckies. You can plug it in, and it automatically will run code that's on the rubber ducky that's been programmed to do all sorts of fun stuff. So there's that implication as well, and this is primarily for folks who travel a lot. If you're at a home office and you're not worried about like insider threaten things, like USBs, you know, control probably not high up on your list, but if you have traveling folks who are commonly like in public places, things like that, maybe this is a good one that you want to pay attention to and take a look at.

Tyler: 34:12

And there are other policies that can be set within the device policy section. So I would recommend going to your CrowdStrike console if you have somebody that's managing it for you. Get the information from them, but I review the different policies and see if there's any that CrowdStrike offer that would provide you benefit in your environment. I think that's the number one takeaway we want everybody to have from this

episode: 34:32

is tune your EDR and go review the settings that we've mentioned and even some that we haven't. The settings that are going to provide the most benefit are all going to be within the endpoint security section of CrowdStrike. That is where you can do tuning for prevention policies, your firewall device policies. So, tuning your EDR comes from that endpoint security section. I would recommend going through all the different subsections of endpoint. Security and just reviewing them, taking some time to just review those. And again, for the prevention policies, we didn't mention every setting that could be enabled. So I'd recommend clicking through the settings, just reading through them based off your environment. Will they provide value? Check that box.

Spencer: 35:18

Yeah. So final thoughts here for me is these settings meaningfully make our lives more difficult as threat actors. These settings will provide you more telemetry. They'll give you more visibility. They will allow for you to have more alerts on things that actually matter, like suspicious PowerShell, suspicious macros, and malicious macros, and WSL two type stuff, DLL hijacking, and and DLL abuse, all vulnerable drivers, a lot of different things. These will make a meaningful difference in your ability to detect and prevent threat actors and kick them out of your environment. So I encourage you to take this one seriously and review all the settings that we mentioned and check them in your environment. Because, like I said, these are things that are typically not enabled by default. These are things that oftentimes you have to go in and make sure that they're enabled. And if you're not familiar with EDR, your specific EDR, or familiar with the console, you might not even know where to go to find a lot of the stuff. So hopefully, this episode has provided you kind of a roadmap of what you should enable to detect more threats. So Tyler, final thoughts. If

Tyler: 36:39

there's other EDRs you guys are using that you'd like to see. Let us know. I think the other two that we're planning to review off the top of my head are Sentinel One and Defender for Endpoint. So if there's any outside of that, shoot us a message. Let us know.

Spencer: 36:53

Yeah, absolutely. So that's all the time we got for today. If you enjoyed this episode, make sure you leave us a comment and let us know what EDR you want to see next? If you like this episode, if you just want to troll us, meme whatever, like super appreciate it. We read every single comment. We may not reply to everyone, but we do read every single one. You can find all of our content on Offsec blog, and if you want to work with us on a pen test, particularly internal pen testing, because that's you know Tyler and I's bread and butter and external for Tyler a bit more. Check us out at secureit360.com, and depending on when this episode goes live, I'll be at DefCon here leaving tomorrow. So today's the fifth. I'm going out tomorrow. So if you're going to be at Def Con, if you hear this episode while DefCon is happening, I'll be at Red Team Village. So come check me out. Other than that, we'll see you guys in the next episode.