The Cyber Threat Perspective

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.

Most cryptographic findings on your vulnerability report will never be exploited by a real attacker. So why do they keep showing up — and why should you still fix them?

In this episode of the Cyber Threat Perspective, Brad Causey and Jordan Natter break down OWASP Top 10 A04: Cryptographic Failures — the entry they openly call their least favorite on the list. They explain why SWEET32, BEAST, and the other scary-sounding named TLS vulnerabilities almost never translate into real-world compromise, why platforms like Security Scorecard and BitSight inflate their severity anyway, and where genuine cryptographic risk actually lives.

Jordan also walks through a real penetration test finding: a JSON Web Token signed with HS256, an exposed configuration backup sitting on the web server, and the signing secret that turned a standard user into an administrator.

In this episode:

- Why A04 dropped on the OWASP Top 10 without becoming less important
- The difference between exploitable risk, hygiene risk, and brand reputational risk
- An honest take on Security Scorecard and BitSight scores — what they measure, what they miss, and why a perfect score can coexist with a weak password policy and no MFA
- The two halves of A04: data in transit (TLS/HTTPS, integrity, tampering) and data at rest (secure storage of credentials, PII, and payment data)
- What a JWT actually is, and why pen testers love pulling them apart
- Real pen test story: exposed config backup → leaked JWT secret → signature tampering → privilege escalation to admin
- Broken server-side signature validation and other improperly implemented cryptography
- Why MD5 and SHA-1 still show up for password storage 20 years too late — and what to use instead (Argon2, scrypt, bcrypt)
- HSTS, secure renegotiation, and certificate expiration as A04 subcategories
- The coffee shop scenario: the full chain of conditions required to exploit SWEET32 — including roughly 250 GB of captured traffic — and why no one has ever documented it happening in the wild
- Why a decade-plus-old vulnerability in your environment says more about your vulnerability management program than about your crypto
- Quantum computing: how today's theoretical attacks may not stay theoretical

The takeaway: classify your data, choose modern algorithms, retire deprecated protocols, and keep a functioning vulnerability management program. Not because a threat actor is sitting in your local coffee shop waiting to derive your session key — but because leaving decade-old findings in place is a signal about everything else you might be missing.

Next up: OWASP A05, which Brad promises is way cooler than A04.

Blog: https://securit360.com/blog/
Podcast: https://securit360.buzzsprout.com/
YouTube: https://www.youtube.com/@SecurIT360
Contact: https://securit360.com/contact/

Have a topic you want us to cover? Send it our way.
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.

Almost no one writes an application from scratch anymore, and that's exactly the problem. In Part 3 of our OWASP Top 10 series, Brad Causey and Jordan Natter break down A03: Software Supply Chain Failures, the category that climbed to #3 and topped OWASP's own community survey as the vulnerability organizations worry about most. If your team pulls in third-party libraries, buys SaaS, or lets anyone "vibe code" a project, this episode is for you.
Brad and Jordan cover both sides of supply chain risk: the trusted third-party applications you deploy (SolarWinds being the case that put this category on the map) and the open-source components you pull into your own code without always knowing what's inside. They explain why AI and vibe coding are accelerating the problem, why jQuery is the modern-day Flash, and why "just upgrade the package" is rarely that simple.
From there it gets practical:
What a Software Bill of Materials (SBOM) is and why you need one
Transitive dependencies — the packages hiding beneath your packages
Building security checks into your CI/CD pipeline and shifting left
Why a flaw caught in static analysis can cost ~$200, while the same flaw found in a pen test can cost $20,000+
Why a pen test should validate your controls, not be your first line of defense
How SecurIT360's Project Lantern and ChainGarde automate SBOM analysis against known and actively-exploited vulnerabilities
A playbook for vetting vendors, writing accountability into contracts, and holding third parties responsible for actually fixing findings
The takeaway: whether you're writing software or buying it, you need a way to inventory your components, check them against known vulnerabilities, and hold your vendors accountable — and most of it you can do with tools and teams you already have.
Part 1 — Broken Access Control, IDOR & CORS: https://youtu.be/BwYJ-kZ3XaY
Part 2 — Security Misconfigurations: https://youtu.be/Po8H140BijE
Need a web app pen test? SecurIT360 | Cybersecurity From Every Angle 
More content: https://offsec.blog
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.

In this episode, Spencer and Tyler discuss why deception is one of the best ways to catch threat actors.
Resources
Spencer's Cyber Deception Webinar
Spencer's X posts on the topic of cyber deception
https://thinkst.com/, https://canary.tools/
@_subtee on X, @haroonmeer on X
https://tracebit.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.

Need a pentest or vCISO? Work with us! https://www.securit360.com/

A major leadership failure in Cybersecurity is l buying tools first then figuring out where they fit and how to use them. That’s super backwards. Here’s what I would do instead. Plan first, buy & implement second. I’m going to cover just the planning part this week. Next week we will talk about buying and implementing. Because honestly, implementation is where a lot of security teams go wrong. 
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.