<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>secderr</title><link>https://secderr.tech/</link><description>Field notes on incident response, compliance, and hardening real-world systems.</description><image><title>secderr</title><url>https://secderr.tech/images/og-default.png</url><link>https://secderr.tech/images/og-default.png</link></image><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 11 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://secderr.tech/index.xml" rel="self" type="application/rss+xml"/><item><title>The Client's Website Got Blocklisted, Then ZAP Came for Their Inbox</title><link>https://secderr.tech/posts/zap-quarantine-mass-release/</link><pubDate>Sat, 10 Oct 2026 00:00:00 +0000</pubDate><guid>https://secderr.tech/posts/zap-quarantine-mass-release/</guid><description>A URL reputation hit turned ZAP against a client&amp;#39;s own mail. How we proved it, beat the quarantine expiry clock, and released 1,600 messages safely.</description></item><item><title>The Fake Microsoft Login Page That Registered a Device</title><link>https://secderr.tech/posts/fake-microsoft-login-aitm-device-registration/</link><pubDate>Fri, 09 Oct 2026 00:00:00 +0000</pubDate><guid>https://secderr.tech/posts/fake-microsoft-login-aitm-device-registration/</guid><description>An AiTM phishing page proxied a real Microsoft 365 sign-in and registered an attacker device. Covers triage, containment, and the controls that stop it.</description></item><item><title>The Vendor Was the Phish: Responding to an AiTM Compromise in Microsoft 365</title><link>https://secderr.tech/posts/aitm-vendor-phish-microsoft-365/</link><pubDate>Thu, 08 Oct 2026 00:00:00 +0000</pubDate><guid>https://secderr.tech/posts/aitm-vendor-phish-microsoft-365/</guid><description>A trusted vendor&amp;#39;s share link led to AiTM token theft and a phishing run from our user&amp;#39;s mailbox. How we scoped it, cleaned it up and what stops it.</description></item><item><title>Killing Sweet32 on Windows with PowerShell</title><link>https://secderr.tech/posts/disabling-sweet32-cipher-suites-powershell/</link><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><guid>https://secderr.tech/posts/disabling-sweet32-cipher-suites-powershell/</guid><description>Sweet32 (CVE-2016-2183) is one of the most common scan findings on Windows. Here&amp;#39;s how to find and kill 3DES suites with built-in PowerShell cmdlets.</description></item><item><title>Shutting Down Direct Send in Microsoft 365 (Without Breaking Your Printers)</title><link>https://secderr.tech/posts/blocking-direct-send/</link><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><guid>https://secderr.tech/posts/blocking-direct-send/</guid><description>Block unauthenticated Direct Send spoofing in M365 without breaking legacy apps and printers. Find your legitimate senders, create inbound connectors, and flip RejectDirectSend.</description></item><item><title>The NetBIOS Finding That Wasn't About NetBIOS</title><link>https://secderr.tech/posts/netbios-finding-that-wasnt/</link><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><guid>https://secderr.tech/posts/netbios-finding-that-wasnt/</guid><description>A null session finding pointed at NetBIOS. NetBIOS was already off. The real gap was a named pipe exception list our hardening never touched.</description></item></channel></rss>