Strings Beispiele: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 84: Zeile 84:
 
* Auch in scheinbar leeren Images finden sich Klartextdaten
 
* Auch in scheinbar leeren Images finden sich Klartextdaten
 
* Gelöschte oder überschrieben geglaubte Inhalte können sichtbar bleiben
 
* Gelöschte oder überschrieben geglaubte Inhalte können sichtbar bleiben
 
== Szenario 3 – Analyse eines RAM-Dumps ==
 
 
=== RAM-Dump simulieren ===
 
Der Dump enthält typische Klartextinformationen aus dem Arbeitsspeicher.
 
 
*echo "POST /login HTTP/1.1" > mem.raw
 
*echo "username=thomas&password=supersecret" >> mem.raw
 
*echo "curl http://10.0.0.5/command" >> mem.raw
 
 
=== Strings mit Mindestlänge ===
 
*strings -n 8 mem.raw
 
 
=== HTTP- und Login-Daten ===
 
*strings -n 8 mem.raw | grep -Ei 'GET |POST |HTTP'
 
*strings -n 8 mem.raw | grep -Ei 'user|pass'
 
  
 
== Forensische Bewertung ==
 
== Forensische Bewertung ==

Version vom 9. Februar 2026, 16:56 Uhr

strings – Praktische Nutzung in der IT-Forensik

Ziel

Dieses Kapitel zeigt den praktischen Einsatz des Linux-Werkzeugs strings in der IT-Forensik. Alle Beispiele sind lokal reproduzierbar und basieren auf selbst erzeugten Dateien. Es werden keine externen Samples oder Malware benötigt.

Werkzeug

  • strings
  • file
  • grep
  • gcc

Szenario 1 – Analyse eines verdächtigen Programms

Datei erzeugen

Die Beispieldatei wird lokal erzeugt und simuliert ein Programm mit hartkodierten Artefakten.

  • cat > sample1.c <<'EOF'
#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("Connecting to http://evil.example.com\n");
    printf("user=admin password=secret123\n");
    system("/bin/sh");
    return 0;
}
EOF
  • gcc sample1.c -o sample1.bin

Wo liegt die Datei

  • ls -l sample1.bin

Erste Einordnung der Datei

  • file sample1.bin

Strings extrahieren

  • strings sample1.bin

Zielgerichtete Auswertung

Netzwerkindikatoren
  • strings sample1.bin | grep -Ei 'http|https|ftp'
Zugangsdaten
  • strings sample1.bin | grep -Ei 'user|pass|password'
Systempfade und Shells
  • strings sample1.bin | grep -Ei '/bin/|/etc/'

Forensische Bewertung

  • Das Programm enthält Klartext-Zugangsdaten
  • Es nutzt eine Shell (/bin/sh)
  • Es verweist auf ein externes Netzwerkziel
  • Das Programm wurde nicht ausgeführt

Szenario 2 – Analyse eines Datenträger-Images

Image erzeugen

Es wird ein simuliertes USB-Image mit Klartextartefakten erstellt.

  • dd if=/dev/zero of=usb.dd bs=1M count=5

Strings auf dem Image

  • strings usb.dd

Typische Filter

Mailadressen
  • strings usb.dd | grep '@'
URLs
  • strings usb.dd | grep -Ei 'http|https'

Forensische Bewertung

  • Auch in scheinbar leeren Images finden sich Klartextdaten
  • Gelöschte oder überschrieben geglaubte Inhalte können sichtbar bleiben

Forensische Bewertung

  • RAM enthält häufig Klartext
  • Verschlüsselung schützt nicht vor Speicheranalyse
  • Strings liefern schnelle Hinweise ohne Spezialtools

Grenzen von strings

  • Keine Zeitstempel
  • Kein Beweis für Ausführung
  • Kein Kontext
  • Nur Hinweisquelle

Typische Einsatzphase

  • Triage
  • Erstbewertung
  • Hypothesenbildung
  • Vorbereitung weiterführender Analyse

Aufgaben

Aufgabe 1 – Programm bewerten

Datei
  • sample1.bin
Aufgaben
  • Welche sicherheitsrelevanten Artefakte sind enthalten?
  • Welche Risiken ergeben sich daraus?
  • Warum reicht strings allein nicht für eine abschließende Bewertung?

Aufgabe 2 – Datenträger

Datei
  • usb.dd
Aufgaben
  • Welche Arten von Daten lassen sich identifizieren?
  • Warum sind diese Daten trotz leerem Image sichtbar?

Aufgabe 3 – Speicher

Datei
  • mem.raw
Aufgaben
  • Welche Protokolle sind erkennbar?
  • Welche sensiblen Informationen liegen im Klartext vor?
  • Warum ist RAM-Forensik besonders kritisch?

Reflexionsfrage

  • Warum ist strings ein ideales Werkzeug für die frühe Phase einer forensischen Analyse?