<?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>DMZ on Miguel Lameiro | Cybersecurity Blog &amp; Security Writeups</title><link>https://blog.lameiro0x.com/tags/dmz/</link><description>Recent content in DMZ on Miguel Lameiro | Cybersecurity Blog &amp; Security Writeups</description><generator>Hugo -- 0.161.1</generator><language>en-us</language><lastBuildDate>Fri, 01 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.lameiro0x.com/tags/dmz/index.xml" rel="self" type="application/rss+xml"/><item><title>Attacking Enterprise Networks</title><link>https://blog.lameiro0x.com/notes/exploitation/attacking-enterprise-networks/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://blog.lameiro0x.com/notes/exploitation/attacking-enterprise-networks/</guid><description>&lt;h1 id="introduction"&gt;Introduction&lt;/h1&gt;
&lt;h2 id="scope-assumptions-and-recon-strategy"&gt;Scope, Assumptions, and Recon Strategy&lt;/h2&gt;
&lt;p&gt;An enterprise network assessment usually starts with far less certainty than a lab writeup suggests. In this scenario, the client wanted to know what an anonymous internet user could reach from the DMZ and whether that access could eventually lead to internal compromise, including Active Directory impact. No VPN, web application, or domain credentials were provided, so the attack path had to begin with discovery, validation, and careful prioritization. That is important because an external penetration test is not the same thing as a full web application assessment: the goal is to find realistic footholds and high-impact attack paths, not spend the entire week cataloging every missing security header.&lt;/p&gt;</description></item></channel></rss>