<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AD on Maximilian Hildebrand</title><link>https://m10x.de/tags/ad/</link><description>Recent content in AD on Maximilian Hildebrand</description><generator>Hugo</generator><language>en</language><copyright>&lt;a href="https://creativecommons.org/licenses/by-nc/4.0/" target="_blank" rel="noopener">CC BY-NC 4.0&lt;/a></copyright><lastBuildDate>Fri, 04 Sep 2026 04:00:56 +0100</lastBuildDate><atom:link href="https://m10x.de/tags/ad/index.xml" rel="self" type="application/rss+xml"/><item><title>Shadow Credentials</title><link>https://m10x.de/posts/2026/09/shadow-credentials/</link><pubDate>Fri, 04 Sep 2026 04:00:56 +0100</pubDate><guid>https://m10x.de/posts/2026/09/shadow-credentials/</guid><description>Since late 2023, when I started conducting internal penetration tests, thanks to Alh4zr3d, &amp;ldquo;Shadow Credentials&amp;rdquo; has been my favorite method for gaining administrative privileges on systems on the network. However, I’ve often run into a quirk that got in the way: A computer account can only set its msDS-KeyCredentialLink attribute if it’s empty. But if, for example, Windows Hello is already enabled on the system and the attribute is therefore already set, Shadow Credentials via relaying fails.</description></item></channel></rss>