I’ve always been curious about how systems behave once they’re actually in use. Not in ideal lab setups, but in real environments where defaults linger, documentation is only half-read, and small decisions quietly compound over time.
That curiosity gradually pulled me towards security, and towards looking at Windows and cloud environments from an attacker’s point of view. I tend to focus on the details that are easy to overlook: legacy behaviour, identity-related quirks, remote access technologies, and the traces systems leave behind long after an action has taken place.
In my day-to-day work as a penetration tester, I run into these kinds of issues on a regular basis. Many of them aren’t exotic or new; they’re patterns that keep showing up across different environments. This blog is a place to write about those recurring findings: why they exist, how they’re commonly abused, and what actually helps to mitigate them in practice.
Some posts focus on concrete attack techniques, others on defensive blind spots or mitigations that don’t behave the way people expect them to. The common thread is understanding why something works the way it does, rather than just documenting a single isolated issue.
There isn’t a large archive here yet, but the plan is to keep adding write-ups over time. If you’re interested in Windows or Azure security, practical attack paths, and real-world observations that show up again and again, you’ll probably find something useful here.
LLMNR, NBT-NS and mDNS: Legacy Name Resolution Protocols That Open the Door to Credential Exposure
Windows environments rely on several name resolution mechanisms to locate resources when DNS queries fail or when systems operate in mixed or unmanaged networks. Among these mechanisms are LLMNR (Link-Local Multicast Name Resolution), NBT-NS (NetBIOS Name Service) and mDNS (Multicast DNS). Although created to support small or misconfigured networks, these protocols continue to operate silently in many modern enterprise environments.
Their design introduces predictable weaknesses. All three protocols accept responses from any device on the local network segment. This behaviour creates conditions for credential interception when a system requests a name that cannot be resolved through DNS. For this reason, the protocols have long been associated with credential exposure and are frequently observed in security assessments.
...
DHCPv6 Poisoning: An Overlooked Weakness in Windows Networks
Windows networks often operate primarily on IPv4, yet IPv6 remains enabled and active on nearly all Windows systems by default. Even in environments where IPv6 is not intentionally deployed, Windows continues to search for configuration sources that provide IPv6 parameters. This behaviour introduces an attack surface that is frequently underestimated: DHCPv6 poisoning.
This technique has been known in the security community for years and continues to appear in modern assessments. Evidence collected for this blog uses mitm6 to demonstrate how easily Windows clients can be influenced when IPv6 behaviour is not monitored or controlled.
...
RDP - Big Brother is watching
Remote Desktop has been a standard tool for system administrators and anyone who needs to manage a server or workstation from a distance for many years. During a session far more happens behind the scenes than most people realise. Windows quietly stores small fragments of the remote screen, a mechanism known as the RDP Bitmap Cache.
Many users assume that once an RDP session is closed, anything that appeared on the screen disappears as well. In reality a portion of that visual data remains on the local machine. Forensic investigators consider this a valuable source of information, and in security-focused environments it is important to understand what this cache contains, how it works and which risks it introduces.
...
