<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hardening on CuraSec</title><link>https://curasec.metacog.co.kr/tags/hardening/</link><description>Recent content in Hardening on CuraSec</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 23 Aug 2026 11:32:55 +0000</lastBuildDate><atom:link href="https://curasec.metacog.co.kr/tags/hardening/index.xml" rel="self" type="application/rss+xml"/><item><title>Windows Named Pipe Abuse: Access Control Hardening Guidance</title><link>https://curasec.metacog.co.kr/insights/2026-08-23-named-pipes-under-attack-securing-windows-interprocess-commu/</link><pubDate>Sun, 23 Aug 2026 11:32:55 +0000</pubDate><guid>https://curasec.metacog.co.kr/insights/2026-08-23-named-pipes-under-attack-securing-windows-interprocess-commu/</guid><description>&lt;ul>
&lt;li>&lt;strong>Engineer — Learn:&lt;/strong> Good conceptual reminder that named-pipe ACLs are an exploitable surface in Windows services, but no CVE, no KEV, and no exploitation signal means no immediate patching or configuration change is required — file this as design guidance for future Windows service work.&lt;/li>
&lt;li>&lt;strong>SOC/IR — Learn:&lt;/strong> Named-pipe abuse for lateral movement and C2 tunneling is already a documented ATT&amp;amp;CK technique (T1559.001); this article adds no new IOCs, campaigns, or detection angles beyond what existing Sigma rules and EDR behavioral detections already cover.&lt;/li>
&lt;li>&lt;strong>Leader — Skip&lt;/strong>&lt;/li>
&lt;/ul></description></item><item><title>Obsidian KB for enterprise Windows Server hardening</title><link>https://curasec.metacog.co.kr/insights/2026-07-24-armourinfosec-enterprise-windows-infrastructure-security-65/</link><pubDate>Fri, 24 Jul 2026 12:43:46 +0000</pubDate><guid>https://curasec.metacog.co.kr/insights/2026-07-24-armourinfosec-enterprise-windows-infrastructure-security-65/</guid><description>&lt;ul>
&lt;li>&lt;strong>Engineer — Learn:&lt;/strong> A reference collection for Windows Server defensive hardening; worth bookmarking if you need structured guidance on configuration baselines, but no immediate action required.&lt;/li>
&lt;li>&lt;strong>SOC/IR — Skip&lt;/strong>&lt;/li>
&lt;li>&lt;strong>Leader — Skip&lt;/strong>&lt;/li>
&lt;/ul></description></item><item><title>Mandiant: Hardening Publicly Exposed Serverless Cloud Functions</title><link>https://curasec.metacog.co.kr/insights/2026-07-16-the-risk-of-exposed-cloud-functions-and-how-to-harden/</link><pubDate>Thu, 16 Jul 2026 12:18:39 +0000</pubDate><guid>https://curasec.metacog.co.kr/insights/2026-07-16-the-risk-of-exposed-cloud-functions-and-how-to-harden/</guid><description>&lt;ul>
&lt;li>&lt;strong>Engineer — Plan:&lt;/strong> Mandiant assessments routinely find unauthenticated Cloud Run/Functions exposed to the internet; audit your serverless inventory for missing auth controls and apply the hardening patterns (least-privilege service accounts, input validation, network egress restrictions) this quarter. No active exploitation signals elevate this to Act.&lt;/li>
&lt;li>&lt;strong>SOC/IR — Learn:&lt;/strong> The LFI/RFI and command-injection paths described could inform detection logic for serverless workloads, but there are no IOCs, no named campaign, and no novel TTPs here — no immediate hunt or rule-writing required.&lt;/li>
&lt;li>&lt;strong>Leader — Skip&lt;/strong>&lt;/li>
&lt;/ul></description></item></channel></rss>