<?xml version="1.0" encoding="UTF-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel><title>Niclas Heinz</title><description>Personal Website of Niclas Heinz</description><link>https://nheinz.eu/</link><atom:link href="https://nheinz.eu/feed_rss_updated.xml" rel="self" type="application/rss+xml" /><language>en</language> <pubDate>Sat, 05 Sep 2026 09:47:10 -0000</pubDate> <lastBuildDate>Sat, 05 Sep 2026 09:47:10 -0000</lastBuildDate> <ttl>1440</ttl> <generator>MkDocs RSS plugin - v1.17.3</generator> <image> <url>None</url> <title>Niclas Heinz</title><link>https://nheinz.eu/</link> </image> <item> <title>47 Networks, 68 Seconds</title> <author>Niclas Heinz</author> <category>campaigns</category> <category>honeypot</category> <category>infrastructure</category> <category>scanning</category> <category>threat-intel</category> <description>&lt;h1&gt;47 Networks, 68 Seconds&lt;/h1&gt;&lt;p&gt;47 different chunks of the internet, each a full /24 block of up to 256 addresses, started scanning my infrastructure within 68 seconds of each other. 47 entire networks, most of them belonging to a single hosting provider. 6 months of logs turned up more than a dozen of these synchronized waves, and at least 3 of them weren&#39;t one-time events. The same operators came back days later and ran the exact same target list again, like clockwork.&lt;/p&gt;</description><link>https://nheinz.eu/blog/2026/09/47-networks-68-seconds/</link> <pubDate>Sat, 05 Sep 2026 09:34:58 +0000</pubDate><source url="https://nheinz.eu/feed_rss_updated.xml">Niclas Heinz</source><guid isPermaLink="true">https://nheinz.eu/blog/2026/09/47-networks-68-seconds/</guid> </item> <item> <title>Switching from nheinz.dev to nheinz.eu</title> <author>Niclas Heinz</author> <category>Meta</category> <category>Website</category> <description>&lt;h1&gt;Switching from nheinz.dev to nheinz.eu&lt;/h1&gt;&lt;p&gt;I recently switched my provider and bought a new domain for my website and hoppy projects: &lt;code&gt;nheinz.eu&lt;/code&gt;. For now, a redirect from my old website is in place, but in some couple of months &lt;code&gt;nheinz.dev&lt;/code&gt; will be gone.&lt;/p&gt;</description><link>https://nheinz.eu/blog/2026/08/switching-from-nheinzdev-to-nheinzeu/</link> <pubDate>Fri, 04 Sep 2026 21:50:43 +0000</pubDate><source url="https://nheinz.eu/feed_rss_updated.xml">Niclas Heinz</source><guid isPermaLink="true">https://nheinz.eu/blog/2026/08/switching-from-nheinzdev-to-nheinzeu/</guid> </item> <item> <title>MDRFCKR - a (almost) decade old botnet</title> <author>Niclas Heinz</author> <category>Honeypots</category> <category>Security</category> <category>Threat Intelligence</category> <description>&lt;h1&gt;MDRFCKR - a (almost) decade old botnet&lt;/h1&gt;&lt;p&gt;Between &lt;strong&gt;May 3 and June 3, 2026&lt;/strong&gt;, a threat actor operating under the handle &lt;strong&gt;&#34;mdrfckr&#34;&lt;/strong&gt; conducted a sustained SSH credential-stuffing campaign against my internet-facing SSH honeypots. The campaign deployed &lt;strong&gt;3,929 successful authentication events&lt;/strong&gt; from &lt;strong&gt;1,702 unique source IPs&lt;/strong&gt; across 32+ countries. Upon gaining access, the attacker deployed a persistent SSH public key bearing the &#34;mdrfckr&#34; comment - a classic botnet recruitment / persistence mechanism.&lt;/p&gt;</description><link>https://nheinz.eu/blog/2026/06/mdrfckr---a-almost-decade-old-botnet/</link> <pubDate>Fri, 04 Sep 2026 21:47:25 +0000</pubDate><source url="https://nheinz.eu/feed_rss_updated.xml">Niclas Heinz</source><guid isPermaLink="true">https://nheinz.eu/blog/2026/06/mdrfckr---a-almost-decade-old-botnet/</guid> </item> <item> <title>Redtail&#39;s Long Runner</title> <author>Niclas Heinz</author> <category>Honeypots</category> <category>Security</category> <category>Threat Intelligence</category> <description>&lt;h1&gt;Redtail&#39;s Long Runner&lt;/h1&gt;&lt;p&gt;Since May, malware hosts have shown up in my honeypot logs, gotten hit once, and disappeared. One host broke that pattern: &lt;code&gt;217[.]60[.]195[.]113&lt;/code&gt;, tied to the Redtail cryptomining botnet, kept getting hit by infected bots for 22.5 days.&lt;/p&gt;</description><link>https://nheinz.eu/blog/2026/08/redtails-long-runner/</link> <pubDate>Fri, 04 Sep 2026 21:47:25 +0000</pubDate><source url="https://nheinz.eu/feed_rss_updated.xml">Niclas Heinz</source><guid isPermaLink="true">https://nheinz.eu/blog/2026/08/redtails-long-runner/</guid> </item> <item> <title>Deploy Your Material for MkDocs Site on GitLab Pages without unique domains</title> <author>Niclas Heinz</author> <category>GitLab</category> <category>Material for MkDocs</category> <description>&lt;h1&gt;Deploy Your Material for MkDocs Site on GitLab Pages without unique domains&lt;/h1&gt;&lt;p&gt;GitLab Pages is an excellent solution for hosting static websites. Since &lt;strong&gt;GitLab 17.4&lt;/strong&gt;[^1], &lt;strong&gt;unique domains&lt;/strong&gt; are enabled by default for Pages deployments. These domains look like this:&lt;br&gt;&lt;code&gt;https://website-762e3.gitlab.io/&lt;/code&gt;[^2]&lt;/p&gt;&lt;p&gt;However, if you prefer a cleaner URL structure, such as &lt;code&gt;&amp;lt;username&amp;gt;.gitlab.io/&amp;lt;repository&amp;gt;&lt;/code&gt;, you need to adjust your configuration.&lt;/p&gt;</description><link>https://nheinz.eu/blog/2024/12/deploy-your-material-for-mkdocs-site-on-gitlab-pages-without-unique-domains/</link> <pubDate>Fri, 27 Jun 2025 12:57:54 +0000</pubDate><source url="https://nheinz.eu/feed_rss_updated.xml">Niclas Heinz</source><guid isPermaLink="true">https://nheinz.eu/blog/2024/12/deploy-your-material-for-mkdocs-site-on-gitlab-pages-without-unique-domains/</guid> </item> </channel></rss>