Browser-Erweiterungen in Wazuh sichtbar machen und riskante Extensions per Active Response entfernen

Einleitung

Browser-Erweiterungen sind ein oft unterschätzter Teil der Angriffsfläche. Gerade in Unternehmensumgebungen können unscheinbare Add-ons Daten abgreifen, den Browser manipulieren, unerwünschte Werbung einschleusen oder als Persistenzmechanismus dienen. Mit den erweiterten Inventory-Funktionen von Wazuh lassen sich Browser-Erweiterungen zentral erfassen, im Dashboard sichtbar machen und über benutzerdefinierte Regeln gegen eine Negativliste prüfen. Wazuh speichert Browser-Extension-Inventardaten in eigenen globalen State-Indizes und stellt sie im Bereich IT Hygiene des Dashboards dar.

Ausgangslage / Problemstellung

In der Praxis taucht häufig dieselbe Anforderung auf: Für einen bestimmten Agenten soll nachvollziehbar sein, welche Browser-Erweiterungen installiert sind, idealerweise direkt im Dashboard. Darüber hinaus besteht oft der Wunsch, als gefährlich eingestufte Erweiterungen automatisiert zu erkennen und auf dem Endpoint zu entfernen.

Die Herausforderung dabei: Die Inventardaten der Browser-Erweiterungen sind zwar im Wazuh-Stack vorhanden, sie erzeugen aber nicht automatisch verwertbare Security-Alerts für individuelle Blacklists. Sichtbarkeit und Reaktion sind also zwei getrennte Themen. Die reine Bestandsaufnahme erfolgt über das System Inventory beziehungsweise IT Hygiene. Die Erkennung unerwünschter Erweiterungen erfordert zusätzlich eine eigene Log-Pipeline mit Regeln und optional Active Response.

Technische Analyse

Die Grundlage ist die Browser-Extension-Inventarisierung von Wazuh. Browser-Erweiterungen werden in den globalen Indizes wazuh-states-inventory-browser-extensions-* gespeichert. Diese enthalten unter anderem Informationen zu Erweiterungsnamen, Versionen, Browsertyp und Quelle. Die Daten lassen sich im Dashboard unter IT Hygiene visualisieren oder über globale Queries bzw. den Indexer API-Zugriff auswerten.

Für den im Thread beschriebenen Use Case wurde ein pragmatischer Weg gewählt:

Ein Skript exportiert Browser-Extension-Daten aus dem Index wazuh-states-inventory-browser-extensions-* in eine JSON-Datei auf dem Manager.
Diese JSON-Datei wird über <localfile> erneut von Wazuh eingelesen.
Custom Rules prüfen die JSON-Felder gegen eine CDB-Liste.
Ein Active-Response-Kommando auf dem Windows-Agent entfernt die erkannte Erweiterung.

Architektonisch ist das kein nativer Inventory-to-Response-Pfad, sondern eine nachgelagerte Detektionsstrecke. Genau das ist wichtig zu verstehen: Das Dashboard-Inventar zeigt vorhandene Extensions an, aber die automatische Entfernung basiert nicht direkt auf dem Inventarindex, sondern auf den vom Skript erzeugten JSON-Logs, die durch den Wazuh-Manager erneut analysiert werden. Wazuh unterstützt benutzerdefinierte Regeln, CDB-Listen für Lookup-basierte Erkennung sowie Active Response für automatisierte Gegenmaßnahmen.

Ein typischer Stolperstein aus dem Thread war die Verwechslung von Inventaransicht und Alert-Ansicht. Die installierten Browser-Erweiterungen werden im Dashboard unter IT Hygiene → Software → Browser extensions sichtbar. Die über die Custom Rules erzeugten Treffer erscheinen dagegen als Alerts, typischerweise im Discover-Bereich oder in den Alert-Ansichten anhand der verwendeten rule.id. Diese beiden Sichten erfüllen unterschiedliche Zwecke: Inventar für Transparenz, Alerts für Erkennung und Reaktion.

Ein weiterer wichtiger Punkt ist das Datenfeld für den CDB-Abgleich. Im diskutierten Ansatz wird auf extension.name geprüft. Damit muss die CDB-Liste auf den angezeigten Erweiterungsnamen matchen, nicht auf eine Browser-spezifische Extension-ID. Wazuh-CDB-Listen unterstützen Einträge im Format key: oder key:value; bei lookup="match_key" ist der Schlüssel entscheidend. Wenn also die Regel auf extension.name referenziert, muss als Schlüssel der Name der Erweiterung hinterlegt werden.

Lösung / Best Practices

Die stabile Umsetzung besteht aus vier sauber getrennten Bausteinen: Datenerfassung, Re-Ingestion, Erkennung und Reaktion.

1. Browser-Extension-Daten aus dem Inventory exportieren

Das Exportskript liest die Browser-Extension-Daten aus dem Indexer und schreibt sie als JSON-Datei, etwa extension.json, auf den Manager. Dieser Schritt kann manuell zum Testen erfolgen und anschließend per Cron automatisiert werden. Für den Produktivbetrieb ist eine feste Ausführungsfrequenz sinnvoll, damit neue oder entfernte Erweiterungen zeitnah erfasst werden.

Wichtig ist dabei: Dieser Export ist technisch kein einmaliger Vorgang, wenn eine kontinuierliche Erkennung gewünscht ist. Ein einmaliger Lauf eignet sich nur für den Funktionstest. Für den laufenden Betrieb muss die Datei regelmäßig neu erzeugt werden.

2. JSON-Datei korrekt als Logquelle einlesen

Die erzeugte Datei wird im Manager per <localfile> eingebunden. Entscheidend ist hier das Format:

<localfile>
  <location>/pfad/zur/extension.json</location>
  <log_format>json</log_format>
</localfile>

Gerade dieser Punkt war im Thread relevant: Wird irrtümlich syslog statt json verwendet, kann Wazuh die Felder nicht korrekt als JSON-Daten analysieren. Da Wazuh JSON-Logs nativ verarbeiten kann, ist in diesem Fall kein klassischer Custom Decoder nötig, solange die Datei tatsächlich sauber strukturierte JSON-Events enthält. Regeln können dann direkt mit <decoded_as>json</decoded_as> arbeiten.

3. CDB-Liste für unerwünschte Erweiterungen aufbauen

Die CDB-Liste liegt typischerweise unter /var/ossec/etc/lists/. Für das hier gezeigte Vorgehen sollte sie Erweiterungsnamen als Schlüssel enthalten, beispielsweise:

Ali Quick - AliExpress Dropship Tool:
ClearURLs:
Fire Shield Secure:

Das im Thread diskutierte Format mit einer Browser- oder Store-ID wie

odccobbfnngplckpongkahajfjpnbcck:Fire Shield Secure

ist nur dann korrekt, wenn die Regel genau diese ID in einem passenden Feld prüft. Im gezeigten Ansatz wird jedoch extension.name abgefragt. Deshalb muss die CDB-Liste den Namen enthalten, wie er im Inventory erscheint. Wazuh-CDB-Listen unterstützen Schlüssel allein oder Schlüssel-Wert-Paare; für einen schlichten Blacklist-Match genügt key:.

Datei und Berechtigungen sollten konsistent gesetzt werden:

sudo chown wazuh:wazuh /var/ossec/etc/lists/extension
sudo chmod 660 /var/ossec/etc/lists/extension

4. Regeln zur Erkennung definieren

Die Custom Rules können in einer separaten Datei unter /var/ossec/etc/rules/ abgelegt werden, etwa browser_extension.xml. Das ist sauberer als die lokale Standarddatei zu überladen und erleichtert Wartung und Versionskontrolle. Wazuh unterstützt benutzerdefinierte Regeln in separaten XML-Dateien.

Ein funktionaler Aufbau sieht so aus:

<group name="browser_extensions,">  <rule id="100500" level="3">
    <decoded_as>json</decoded_as>
    <field name="agent.id">\d+</field>
    <description>Browser extension inventory event: $(extension.name)</description>
  </rule>  <rule id="100501" level="8">
    <if_sid>100500</if_sid>
    <list field="extension.name" lookup="match_key">etc/lists/extension</list>
    <description>Dangerous browser extension detected: $(extension.name)</description>
    <group>browser_extension_blacklist,</group>
  </rule></group>

Gegenüber der Thread-Version ist die Nutzung von <field> robuster als ein grober Regex-Match auf den kompletten JSON-String. Das verbessert Lesbarkeit und reduziert Fehlmatches. Außerdem ist ein höheres Rule-Level für echte Blacklist-Treffer sinnvoll, damit die Alerts im Betrieb nicht untergehen. Wazuh dokumentiert sowohl die Rule-Syntax als auch die Klassifizierung der Alert-Level.

5. Active Response für die Entfernung auf Windows konfigurieren

Wenn beim Treffer automatisch reagiert werden soll, wird auf dem Manager ein Kommando definiert und an die betroffenen Agents verteilt:

<command>
  <name>extension</name>
  <executable>extension.exe</executable>
  <timeout_allowed>yes</timeout_allowed>
</command><active-response>
  <disabled>no</disabled>
  <command>extension</command>
  <location>all</location>
  <rules_id>100501</rules_id>
  <timeout>30</timeout>
</active-response>

Wazuh dokumentiert die Konfiguration von Active Response in ossec.conf sowie den Aufbau eigener Active-Response-Skripte. Gerade bei Custom Actions ist wichtig, dass Eingabe- und Rückgabeverhalten des Skripts sauber implementiert sind, da sonst Ausführung oder Rückmeldung fehlschlagen können.

Auf Windows muss die ausführbare Datei im Agent-Verzeichnis für Active Response liegen, typischerweise unter:

C:\Program Files (x86)\ossec-agent\active-response\bin

Die tatsächliche Entfernung einer Erweiterung ist jedoch browser- und profilabhängig. Bei Chrome und Edge kann das Entfernen funktionieren, wenn die Erweiterung benutzerspezifisch installiert wurde und der Prozess ausreichende Rechte hat. In VDI- oder Citrix-Umgebungen muss zusätzlich berücksichtigt werden, dass Benutzerprofile roaming-basiert, non-persistent oder per Policy gesteuert sein können. Dann entfernt Active Response zwar lokal Artefakte, aber die Erweiterung wird beim nächsten Profil-Refresh oder Login unter Umständen erneut bereitgestellt. Deshalb sollte die technische Entfernung immer mit Browser- oder GPO-basierten Allow-/Deny-Policies kombiniert werden.

6. Ergebnisse korrekt im Dashboard prüfen

Für die Inventarsicht der installierten Erweiterungen ist der richtige Ort:

IT Hygiene → Software → Browser extensions

Für die Erkennungssicht auf verdächtige Erweiterungen sollten die erzeugten Alerts über die rule.id gefiltert werden, etwa im Discover-Bereich. So lässt sich sauber unterscheiden, ob die Inventarisierung funktioniert und ob die Blacklist-Regeln tatsächlich auslösen. Wazuh beschreibt die Visualisierung zentralisierter Inventardaten im Dashboard sowie globale Abfragen auf State-Daten.

Lessons Learned / Best Practices

Der wichtigste Lerneffekt aus diesem Fall ist die saubere Trennung zwischen Sichtbarkeit, Detektion und Remediation. Nur weil Browser-Erweiterungen im Inventory auftauchen, existiert noch keine betriebsfähige Erkennungslogik.

Ebenso entscheidend ist die Feldkonsistenz. Wenn die Regel auf extension.name prüft, muss die CDB-Liste genau diesen Wert enthalten. Wer stattdessen Extension-IDs verwenden möchte, muss sicherstellen, dass das Exportskript diese IDs als eigenes JSON-Feld schreibt und die Regel auf genau dieses Feld referenziert. Wazuh-CDB-Matches sind zuverlässig, aber nur dann, wenn Datenmodell und Lookup-Schlüssel wirklich zusammenpassen.

Für den Betrieb empfiehlt sich außerdem:

Exportskript regelmäßig per Cron ausführen, nicht nur einmalig testen.
JSON-Datei klein und konsistent halten, damit Re-Ingestion und Regelmatching performant bleiben.
Separate Rule-Datei für Browser-Extension-Use-Cases pflegen.
Erst Alerting validieren, dann Active Response aktivieren.
Entfernung gefährlicher Erweiterungen nicht allein auf Endpoint-Skripte stützen, sondern zusätzlich durch Browser-Policies oder Endpoint-Management absichern.
In Citrix- und VDI-Umgebungen persistenten und nicht-persistenten Profilbetrieb gesondert testen.

Nicht zuletzt sollte man die Qualität der Blacklist pflegen. Einträge wie Werbe- oder Search-Hijacker-Erweiterungen können als interne Negativliste geführt werden, aber Wazuh selbst liefert dafür keine kuratierte Liste gefährlicher Browser-Erweiterungen out of the box. Die Organisation muss also definieren, welche Add-ons unerwünscht oder riskant sind.

Fazit

Mit Wazuh lässt sich die Erfassung von Browser-Erweiterungen sauber im Dashboard abbilden, und über einen zusätzlichen Export-, Regel- und Active-Response-Pfad ist auch die automatisierte Erkennung und Entfernung unerwünschter Extensions möglich. Der entscheidende Architekturpunkt ist dabei, dass das native Inventory allein noch keine Reaktion auslöst. Erst die Kombination aus JSON-Re-Ingestion, CDB-Lookup, Custom Rules und Active Response macht aus Inventardaten einen steuerbaren Security-Use-Case. Wer dabei Feldmapping, CDB-Format und Dashboard-Sichten sauber trennt, erhält eine praxistaugliche Lösung für Chrome-, Edge- und vergleichbare Windows-basierte Browser-Umgebungen.

Quellenverweis