SCCM RecentlyUsedApps: Ausführungsnachweise in WMI
CCM_RecentlyUsedApps aus dem WMI-Repository lesen: welche Programme jeder Benutzer wann zuletzt und wie oft startete, inklusive älterer Kopien aus OBJECTS.DATA.
Kurz gesagt. Auf Rechnern mit dem Configuration-Manager-Client (SCCM / ConfigMgr) enthält das WMI-Repository CCM_RecentlyUsedApps: einen Datensatz pro ausführbarer Datei und Benutzer, mit vollständigem Pfad, den Versionsinformationen der Datei, dem letzten Benutzer, LastUsedTime und einem LaunchCount. Das ist ein Ausführungsnachweis, der das Löschen der Binärdatei überdauert. Er liegt in derselben OBJECTS.DATA, die Sie ohnehin für WMI-Persistenz sichern, und ältere Kopien jedes Datensatzes lassen sich aus freiem Speicher carven.
Woher die Daten kommen
Die Software-Metering-Komponente des ConfigMgr-Clients beobachtet Programmstarts und hält eine Zusammenfassung in WMI fest, im Namespace root\ccm\SoftwareMeteringAgent, Klasse CCM_RecentlyUsedApps. Configuration Manager nutzt sie für seine Berichte zur Softwarenutzung; für Ermittler ist es ein Protokoll pro Benutzer darüber, was lief. Ohne ConfigMgr-Client keine Daten — prüfen Sie also zuerst:
Get-Service CcmExec -ErrorAction SilentlyContinue
Get-CimInstance -Namespace root/ccm/SoftwareMeteringAgent -ClassName CCM_RecentlyUsedApps |
Sort-Object LastUsedTime -Descending |
Select-Object LastUsedTime, LastUserName, FolderPath, ExplorerFileName, LaunchCount, CompanyName
Diese Abfrage zeigt nur aktive Datensätze, über WMI selbst. Für die Untersuchung sichern Sie den ganzen Repository-Ordner: Für SCCM ist nichts weiter nötig, die Klasse liegt in denselben Dateien.
Die wichtigen Felder
| Eigenschaft | Was sie aussagt |
|---|---|
FolderPath, ExplorerFileName | Von wo die Datei gestartet wurde und ihr Name auf dem Datenträger |
LastUserName | Das Konto, das sie gestartet hat (ein Datensatz pro Benutzer) |
LastUsedTime | Der letzte Start dieser Datei durch diesen Benutzer |
LaunchCount | Die vom Client gezählten Starts |
CompanyName, ProductName, FileDescription, FileVersion, ProductVersion, OriginalFileName | Die Versionsinformationen der Datei |
FileSize, FilePropertiesHash, SoftwarePropertiesHash | Größe und die clienteigenen Hashes der Datei- und Produkteigenschaften |
msiDisplayName, msiPublisher, msiVersion, ProductCode | Das installierte MSI-Produkt, zu dem die Datei gehört, falls vorhanden |
OriginalFileName und die Versionsfelder stammen aus der Datei selbst: Ein umbenanntes Tool behält dort seinen ursprünglichen Namen, und ein Tool ganz ohne Versionsinformationen fällt neben signierter Herstellersoftware auf.
LastUsedTime richtig lesen
LastUsedTime ist eine CIM-DATETIME-Zeichenkette: jjjjmmttHHMMSS.mmmmmm, dann ein Vorzeichen und drei Ziffern Versatz zu UTC in Minuten. 20260914100914.000000+000 ist 10:09:14 UTC. Ein Wert, der auf +120 endet, wäre zwei Stunden vor UTC geschrieben; seine UTC-Zeit liegt also zwei Stunden früher. Rechnen Sie mit dem Versatz um, der im Wert steht, statt eine Zeitzone anzunehmen, und notieren Sie die Rohzeichenkette.
Zwei Grenzen sollten Sie kennen:
- Es ist der letzte Start durch diesen Benutzer, nicht der erste und nicht jeder. Den ersten Start datieren Prefetch oder Amcache meist besser.
LaunchCountzählt kumulativ, seit der Client die Datei verfolgt. Eine 1 ist ein einziger Lauf; eine 2 mit aktuellemLastUsedTimebedeutet mindestens einen früheren Lauf.
Ältere Kopien in OBJECTS.DATA
Jede Aktualisierung schreibt den Datensatz neu. Wie bei gelöschten WMI-Subscriptions wird die vorige Version nicht gelöscht: Sie bleibt in einer nicht zugeordneten Seite oder im Page Slack, bis WMI den Platz wiederverwendet. Carving nach dem Datensatz-Header (dem Hash des Klassennamens) holt diese Kopien mit ihrem eigenen LastUsedTime und LaunchCount zurück. Eine freigegebene Kopie mit Anzahl 1 und früherer Zeit neben einer aktiven Kopie mit Anzahl 2 datiert auch den ersten Lauf.
Denselben Ansatz verfolgt David Panys CCM_RUA_Finder.py (WMI_Forensics); python-cim liest die aktiven Datensätze über den Index.
Worauf Sie achten sollten
- Benutzerbeschreibbare Ordner:
C:\Users\Public\,AppData,Downloads,C:\ProgramData\,C:\Windows\Temp\. Von Administratoren installierte Software liegt inProgram FilesoderWindows. - Keine Versionsinformationen (leerer
CompanyName) bei einer ausführbaren Datei außerhalb der üblichen Ordner. - LaunchCount = 1 bei einem Tool: Staging, Exfiltration oder Aufräumen laufen oft nur einmal.
- Seltene Einträge: das einzige Programm aus seinem Ordner, oder nur auf einem Rechner der Umgebung gesehen.
- Zeitlicher Bezug: letzte Starts im Vorfallszeitraum oder nahe der Erstellung einer WMI-Subscription auf demselben Host.
Keines dieser Merkmale ist für sich ein Beweis. Identifizieren Sie die Datei (Hash vom Datenträger oder aus Backups, Hersteller, Installationsquelle), bevor Sie Schlüsse ziehen.
Ein durchgespieltes Beispiel
Das Beispiel-Repository im Tool (fiktiver Host FIN-WKS-07) enthält m64.exe in C:\ProgramData\Intel\, gestartet von FIN\svc_backup um 10:09 UTC mit Anzahl 2 und ohne Versionsinformationen, sowie rclone.exe in C:\Users\Public\, einmal gestartet um 10:47. Eine freigegebene Kopie des m64.exe-Datensatzes zeigt einen ersten Start um 10:02 mit Anzahl 1. Unter den WMI-Subscriptions desselben Repositorys startet ein Consumer, dessen Datensatz-Header-Zeit 10:31 ist, genau dieses m64.exe wenige Minuten nach jedem Systemstart. Öffnen Sie das Tool, laden Sie das Beispiel und wechseln Sie zu Ausführungsnachweise (SCCM), um alles mit dem Zeitraum nachzuvollziehen.