<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Persistence on Fuchsbau</title><link>https://this-is-fine.io/tags/persistence/</link><description>Recent content in Persistence on Fuchsbau</description><generator>Hugo</generator><language>de-DE</language><lastBuildDate>Thu, 02 Jul 2026 17:30:00 +0200</lastBuildDate><atom:link href="https://this-is-fine.io/tags/persistence/index.xml" rel="self" type="application/rss+xml"/><item><title>Die gut getarnte Reverse Shell beim Systemstart — oder: warum moderne Persistenz aussieht wie ein Admin, der zur Arbeit kommt</title><link>https://this-is-fine.io/posts/20260702-autostart-persistenz/</link><pubDate>Thu, 02 Jul 2026 17:30:00 +0200</pubDate><guid>https://this-is-fine.io/posts/20260702-autostart-persistenz/</guid><description>&lt;p&gt;Im vorigen Beitrag über &lt;a href="https://this-is-fine.io/posts/20260702-rootkits/"&gt;Rootkits&lt;/a&gt;
 lief alles auf eine These hinaus: das moderne Rootkit sieht nicht mehr wie ein Rootkit aus, sondern wie legitime Admin-Infrastruktur — ein signierter Treiber, ein eBPF-Programm, ein Scheduled Task. Wer in der Forensik nach den alten Mustern sucht, findet nichts. Dieser Beitrag nimmt die andere Hälfte desselben Phänomens in den Blick: die &lt;strong&gt;Persistenz&lt;/strong&gt;. Denn die Frage „wie bringt man eine Reverse Shell gut getarnt beim Systemstart zum Laufen?&amp;quot; ist im Grunde die Fortsetzung desselben Gedankens — nur eine Schicht weiter oben, im Userspace, und mit einem Artefakt-Set, das man in der Forensik &lt;em&gt;wirklich&lt;/em&gt; täglich findet.&lt;/p&gt;
&lt;p&gt;Wieder die gleiche Regel wie vorher: Das hier ist konzeptionell, nicht operational. Keine Schrittfolgen, keine Payloads. Wer forensisch arbeitet, muss ahnen, wie die Werkzeuge gedacht sind, ohne sie gebaut zu haben.&lt;/p&gt;</description></item></channel></rss>