Sichern Sie Ihre Slack-Umgebung mit Sumo Logic Cloud-SIEM

Slack ist aus vielen Unternehmen nicht mehr wegzudenken und unterstützt alles – von der internen und externen Kommunikation bis hin zu Projekt-Workflows. Doch mit der zunehmenden Nutzung steigt auch das Risiko. Hacker nehmen Slack immer häufiger ins Visier, da die Plattform oft geistiges Eigentum, Zugangsdaten und wertvolle Informationen für die Ausspähung enthält.

Sumo Logic Cloud-SIEM schützt jetzt Ihre Slack-Nutzung vor Bedrohungen durch Insider und Dritte, indem es Audit-Protokolle auf verdächtige Aktivitäten überwacht, um Ihr Unternehmen und seine Daten zu schützen.

Wie ein gestohlener Slack-Cookie im Wert von 10 Dollar zu einem großen Datenraub führte

Nehmen Sie die Datenpanne bei Electronic Arts (EA) als Beispiel. Bei dem Datenschutzverstoß kauften Angreifer einen gestohlenen Slack-Cookie für 10 Dollar. Dieser Kauf verschaffte ihnen Zugang zu einem internen Slack-Kanal, den sie dann nutzten, um das IT-Team von EA dazu zu bringen, ihnen einen Zugangstoken zum internen Netzwerk von EA zu geben. Die Angreifer stahlen daraufhin 780 GB an Daten, darunter Quellcode für das Spiel FIFA 21 und proprietäre Software-Entwicklungskits. 

EA ist damit nicht allein. Hochkarätige Unternehmen wie Disney, Rockstar, Uber und Twitter haben Angriffe erlebt, bei denen Slack eine wichtige Rolle für den Erfolg der Attacke spielte. 

Es ist nicht schwer zu verstehen, warum Slack entweder als wichtiger Dreh- und Angelpunkt oder als Endziel für Angreifer ins Visier genommen wird, da es ein ideales Terrain ist, um verschiedene Taktiken wie Initial Access, Discovery, Diebstahl von Zugangsdaten und Exfiltration durchzuführen. 

Warum die Audit-Protokolle von Slack der Schlüssel für mehr Sicherheit sind

Da Slack ein so attraktives Ziel ist, sollte Ihre Slack-Umgebung kontinuierlich auf bösartiges Verhalten überwacht werden.

Eine Möglichkeit, mit der Überwachung zu beginnen, sind Protokolle. Slack bietet mehrere verschiedene Arten von Protokollen, von Audit-Protokollen bis hin zu Zugriffsprotokollen und mehr. In diesem Blog konzentrieren wir uns auf Audit-Protokolle, die Slack erstellt, „um eine kontinuierliche Compliance zu gewährleisten, sich vor unangemessenen Systemzugriffen zu schützen und Ihnen zu ermöglichen, verdächtiges Verhalten innerhalb Ihres Unternehmens zu überprüfen.“

Diese Audit-Protokolle und die Möglichkeit, über eine API auf sie zuzugreifen, sind für eine SIEM-Lösung wie Sumo Logic zur Sicherheitsüberwachung und Integration essentiell. 

Verwenden Sie Audit-Protokolle von Slack, um Bedrohungen zu erkennen

Eine wertvolle Funktion der Audit-Protokolle von Slack sind Anomalie-Ereignisse, die automatisch erzeugt werden, wenn Slack anomale Aktionen oder Verhaltensweisen entdeckt. Nicht alle Anomalie-Ereignisse erfordern eine Aktion, und verschiedene Anomalie-Ereignisse haben unterschiedliche Vertrauensstufen. Wenn ein Anomalie-Ereignis ausgelöst wird, müssen Sie es wahrscheinlich weiter untersuchen, um es zu qualifizieren und zu entscheiden, ob Sie darauf reagieren müssen.

Auch wenn Slack bei anomalen Ereignissen keine Konfidenzniveaus angibt, hat das Unternehmen deutlich gemacht, dass manche Ereignisse als hochgradig zuverlässige Indikatoren für eine Kompromittierung gelten. 

Die Anomalie-Ereignis-Reaktionsfunktion liefert zudem einen Hinweis darauf, welche Anomalie-Ereignisse von Slack als hochgradig vertrauenswürdig eingestuft werden. Die Funktion beendet automatisch Benutzersitzungen, wenn ihnen bestimmte Anomalie-Ereignisse zugeordnet werden. Die beiden standardmäßig ausgewählten Ereignisse sind der Zugriff auf Slack über einen Tor-Exit-Node sowie Data Scraping. Dies deutet darauf hin, dass das Slack-Engineering diese beiden Erkennungen als High-Confidence-Signale betrachtet.

Slack-Anomalie-Ereignisse sind für Sicherheitsteams besonders nützlich, da sie in einem SIEM aufgenommen und analysiert werden können. Sumo Logic Cloud-SIEM unterstützt anomale Slack-Ereignisse vollständig. Diese Ereignisse werden als Bedrohungswarnungen normalisiert und lösen eine Regel namens „Normalized Security Signal“ (MATCH-S00402) aus. Das bedeutet, dass anomale Ereignisse jetzt zum Aktivitätsscore einer Entität beitragen können und Analysten helfen, Benutzer oder Systeme, die verdächtiges Verhalten zeigen, schnell zu identifizieren.

Anomalie-Ereignisse bei Slack werden als Sumo Cloud-SIEM-Signale weitergeleitet

Standardeinstellungen für die Reaktion auf Slack-Anomalie-Ereignisse

Wie man Slack-Audit-Protokolle mit Sumo Logic erfasst und einliest

Das Erfassen von Slack-Audit-Protokollen mit Sumo Logic ist eine unkomplizierte Aufgabe. Diese ausführliche Anleitung zeigt, wie man Protokolle von Slack erfasst, aber hier geben wir Ihnen einen kurzen Überblick über die Schritte:

1. Bestätigen Sie, dass Sie ein Slack Enterprise Grid-Konto haben. Ohne ein Enterprise Grid-Konto können Sie keine Audit-Protokolle von Slack erfassen.
2. Erstellen Sie eine Slack-Anwendung, die die Berechtigung auditlogs:read hat.
3. Installieren Sie die Anwendung auf dem Enterprise Grid.
4. Installieren und konfigurieren Sie den Sumo Logic Slack Cloud-to-Cloud Connector.
5. WICHTIGER HINWEIS: Stellen Sie sicher, dass die Slack-Protokollquelle so konfiguriert ist, dass sie Protokolle an das SIEM weiterleitet, indem Sie das Kontrollkästchen „Forward to SIEM“ aktivieren.  

Wie Sicherheitsanalysten Slack-Protokolle für Threat Detetion, Investigation and Response nutzen können 

Slack bietet seinen Kunden einen wertvollen Service, indem es anomales Verhalten erkennt und Anomalie-Ereignisse generiert, da es in einer einzigartigen Position ist, um zu verstehen, welche Arten von Verhalten auf seiner Plattform als anomal betrachtet werden sollten.

Slack Engineering gibt jedoch nicht öffentlich bekannt, welche Erkennungskriterien sie zur Generierung von Anomalie-Ereignissen verwenden. Der Grund liegt auf der Hand – wenn die Kriterien öffentlich bekannt wären, hätten es Angreifer leichter, Techniken zur Umgehung der Verteidigung zu entwickeln.

Für Sicherheitsanalysten kann dies jedoch die Arbeit erschweren. Ohne genau zu wissen, warum ein Alarm ausgelöst wurde, verbringen Sie wahrscheinlich mehr Zeit damit, Abfragen zu formulieren, um genau die Audit-Protokolle abzurufen, die das Anomalie-Ereignis verursacht haben. Auch die Feinabstimmung der Analysen und die Bewertung auf falsch-negative Ergebnisse ist aus ähnlichen Gründen schwieriger und erfordert unter Umständen Spekulationen.

Einige Gründe für Anomalien bieten mehr Klarheit über den Auslöser des Ereignisses als andere. Andere, wie z. B. „excessive_downloads“, sind undurchsichtiger und erfordern, dass Sie nach Download-Aktivitäten vor dem Ereignis suchen, entweder überprüfen, was heruntergeladen wurde, oder beurteilen, ob das Download-Volumen im Vergleich zu früheren Zeiträumen „normal“ für den Benutzer ist. 

Nun wollen wir uns ansehen, wie Sie einige dieser Anomalien in der Praxis untersuchen können. 

Untersuchung eines möglichen Cookie-Diebstahls in Slack 

Kehren wir zu dem Beispiel des EA-Einbruchs zurück, bei dem die Angreifer ein gestohlenes Cookie verwendet haben, um auf interne Systeme zuzugreifen. Welche Slack-Anomalie-Ereignisse würden wir bei der Wiederverwendung eines gestohlenen Cookies erwarten? Wenn Anomalie-Ereignisse protokolliert werden, wie können wir sie untersuchen?

Slack Sitzungs-IDs verstehen

Jedes Mal, wenn sich ein Benutzer bei Slack anmeldet, wird eine Sitzungs-ID erzeugt. Diese Sitzung bleibt als Cookie auf dem Gerät erhalten. Wir erwarten, dass jede Sitzungs-ID einem einzigen Gerät zugeordnet ist. Wenn ein Cookie gestohlen und auf einem anderen Gerät verwendet wird, werden Sie wahrscheinlich Variationen in Artefakten wie diesen sehen:

• User-Agent-String
• IP-Adresse und Standort
• TLS Handshake (ja3 fingerpringt) 

Diese Signale können dabei helfen, eine verdächtige Wiederverwendung zu identifizieren. Es ist jedoch wichtig zu beachten, dass Slack-Audit-Protokolle nur für interaktive Aktionen erstellt werden. Passiver Zugriff (wie das Lesen von Nachrichten ohne Klicken oder Herunterladen) löst unter Umständen keine Protokolleinträge aus, weshalb die Erkennung von Cookie-Wiederverwendung stark von der Art der Benutzeraktivität abhängt..

Diese Unterschiede erscheinen in den Protokollen, die mit der gleichen Sitzungs-ID verbunden sind.

Beispiel einer Slack-Sitzungs-ID, wie sie in einem Sumo Logic Cloud-SIEM-Datensatz zu sehen ist

Anomale Ereignisse, die auf einen Cookie-Diebstahl hindeuten könnten

Bei der Durchsicht der Liste der Slack-Anomalie-Ereignisse, die durch einen Cookie-Diebstahl ausgelöst werden könnten, gibt es mehrere Kandidaten: 

• asn
• ip_address
• session_fingerprint
• tor
• unexpected_client
• unexpected_user_agent
• user_agent

Machen Sie mit Sumo Logic Jagd auf potenziellen Cookie-Diebstahl

Mit dem obigen Wissen werfen wir zunächst ein weites Netz aus und suchen nach allen jüngsten Slack-Anomalie-Ereignissen der letzten zwei Wochen in unserer Umgebung. Die folgende Suche gibt alle Slack-Anomalien zurück und gruppiert sie nach Grund:

_index=sec_record_notification metadata_vendor="Slack" metadata_deviceEventId="anomaly"
| count by threat_signalName

Abbildung 4: Slack-Anomalie-Ereignisse gruppiert nach Grund

In unserem Fall ergab die Suche 323 Ergebnisse. Zwei Punkte sind erwähnenswert:

• Einer Anomalie kann mehr als ein Grund zugeordnet werden, was durch Ergebnisse wie asn|ip_address und unexpected_user_agent|user_agent deutlich wird.
• Der häufigste Grund für eine Anomalie ist asn|ip_address. Diese Ereignisse können abgestimmt werden, indem vertrauenswürdige autonome Systemnummern (ASNs) und IP-Adressbereiche über die API zu einer Ausschlussliste hinzugefügt werden.

Unsere Jagd nach gestohlenen Cookies wird fortgesetzt, indem wir uns auf die Ereignisse mit den Gründen unexpected_user_agent und user_agent konzentrieren. Wir rufen diese Ereignisse und ihre Sitzungs-IDs mit der folgenden Abfrage ab:

_index=sec_record_notification metadata_vendor="Slack" metadata_deviceEventId="anomaly"
| where threat_signalName = "Anomaly Event : unexpected_user_agent|user_agent"
| count by sessionId

Sitzungs-IDs von unexpected_user_agent Anomalie-Ereignissen

Da wir nun Anomalien haben, die wir erforschen können, wollen wir ein paar von ihnen genauer untersuchen:

Die Überprüfung der Details des Anomalie-Ereignisses liefert einen gewissen Kontext darüber, warum das Ereignis ausgelöst wurde:

Details zum Anomalie-Ereignis unexpected_user_agent|user_agent

Analyse des Anomalie-Ereignisses

Die Details der Metadaten des Anomalie-Ereignisses liefern den Grund für die Auslösung des Ereignisses: Die IP-Adresse und der User Agent haben sich geändert. 

Die IP-Adressen-Änderung:

• Die aktuelle IP-Adresse: 172.59.222.55
• Die vorherige IP-Adresse: 204.16.138.54

Deutet die Änderung der IP-Adresse darauf hin, dass das Gerät gewechselt hat, vielleicht vom Gerät des Benutzers zum Gerät des Angreifers? Es ist möglich, aber wenn man bedenkt, dass es sich um ein mobiles Gerät handelt und die GeoIP-Informationen beide Adressen in der Gegend von Charlotte, North Carolina, lokalisieren, vermuten wir keinen Wechsel der Geräte.

Die User-Agent-Änderung:

• Der aktuelle User Agent: „AppleCoreMedia/1.0.0.21F90 (iPhone; U; CPU OS 17_5_1 like Mac OS X; en_us)“
• Der vorherige User Agent: „com.tinyspeck.chatlyio/25.04.10 (iPhone; iOS 17.5.1; Scale/3.00)“

Zeigt die Änderung des User Agent an, dass sich das Gerät geändert hat?

• Unter der Annahme, dass die User-Agent-Zeichenfolgen nicht gefälscht wurden, handelt es sich um ein iPhone mit OS-Version 18.4. 
• Tiny Speck ist der ursprüngliche Name des Unternehmens, das Slack entwickelt hat. Der User Agent String com.tinyspeck.chatlyio/25.04.10 entspricht wahrscheinlich dem Slack iOS-Client.
  AppleCoreMedia ist ein von iOS verwendetes Framework für die Handhabung von Streaming und Medienwiedergabe.
• Auf dieser Grundlage ist es plausibel, dass der AppleCoreMedia-User-Agent erscheint, wenn Mediendateien (z. B. Videos) von Slack aus gestreamt werden, während der Tiny Speck-Agent die typische Slack-Nutzung widerspiegelt. Wir können dieses Verhalten zwar nicht aus der öffentlichen Dokumentation bestätigen, aber unsere Log-Analyse unterstützt diese Interpretation.
• AppleCoreMedia wird von iOS für das Streaming von Medien verwendet.

Vielleicht ist der Tiny Speck-User Agent also für die normale Slack-Nutzung und der AppleCoreMedia-User Agent für das Streaming von Medien aus Slack gedacht?

Wir können diese Theorie testen, indem wir die einzelnen Protokolle überprüfen, die zu dem Anomalie-Ereignis beitragen. Wir beginnen mit der Suche nach der Sitzungs-ID und untersuchen den User Agent, der mit den Aktionen verbunden ist:

(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" sessionId=8475310491012
| fields action, http_userAgent

Man bedenke, dass Sitzungen sehr lange dauern können, und man sollte bei der Festlegung des Zeitraums für die Suche großzügig sein. Die in diesem Beitrag untersuchte Sitzung dauerte über 90 Tage.

Geprüfte Slack-Aktionen und ihre zugehörigen User-Agent-Strings

Wir konzentrieren uns auf die Tage vor dem Anomalie-Ereignis am 9. April 2025. In der Stunde vor dem Anomalie-Ereignis wechselte der Benutzer-Agent vom Tiny Speck (Slack) Agent zu AppleCoreMedia. Und warum? Möglicherweise weil der Dateityp, der in den file_downloaded-Aktionen involviert war, Streaming erforderte. Wir fügen das Feld file_mimetype zur Anzeige unserer Suchergebnisse hinzu, indem wir den Feldnamen aus dem Abschnitt für versteckte Felder in der Feldliste auswählen:

Abbildung 8: Hinzufügen des Feldes file_mimeType zur Anzeige der Suchergebnisse

Anhand des angezeigten file_mimeType können wir deutlich sehen, dass der User Agent AppleCoreMedia ist, wenn MP4-Dateien heruntergeladen wurden, und Tiny Speck, wenn eine JPG-Datei herunterladen wurde:

Abbildung 9: Analyse von User-Agent-Strings im Zusammenhang mit heruntergeladenen Dateitypen

In diesem Fall hat das Slack-Anomalie-Ereignis kein bösartiges Verhalten aufgedeckt. Es gab eine Sitzung, in der sich der User Agent geändert hat, aber nicht, weil mehr als ein Gerät denselben Sitzungs-Cookie verwendet hat. 

Verwendung von Slack-Anomalie-Ereignistypen für benutzerdefinierte analytische Inhalte

Slack gibt die genaue Logik hinter der Erkennung von Anomalien nicht preis, was vom Standpunkt der Sicherheit aus gesehen Sinn macht. Aber die Anomalie-Ereignistypen selbst dienen als Inspiration für Dashboards, Jagden und unsere eigenen benutzerdefinierten Analysen.

Sie können mit ihnen folgendes überwachen:

• Administrative Aktivitäten außerhalb der Norm, mit einer First-seen-Regel
• Spitzen im Volumen von Downloads, Dateifreigaben oder Nachrichtenlöschungen, mit Ausreißer-Regeln 

Um auf das Thema Cookie-Diebstahl zurückzukommen: Wie können wir Slack-Sitzungen aufspüren, die mehr als einen User-Agent-String enthalten? Wir können den Operator count_distinct:verwenden.

(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" metadata_product="Slack" 
| count_distinct(http_userAgent) by sessionId
| sort by _count_distinct

Anzahl der eindeutigen User-Agent-Strings pro sessionId

Wenn wir dann Sitzungen von Interesse finden, können wir alle Protokolle über eine Abfrage wie die folgende zurückgeben:

(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" sessionId=[hier Sitzungs-ID einfügen]
| count by http_userAgent

Bleiben Sie den Slack-basierten Bedrohungen voraus

Slack ist eine reichhaltige Quelle für Unternehmensinformationen, die es zu einem begehrten Ziel für Hacker macht. Die Überwachung von Slack-Auditprotokollen, einschließlich Anomalie-Ereignisse, ist entscheidend für die frühzeitige Erkennung eines Angriffs. 

Sumo Logic macht es einfach, diese Protokolle zu erfassen, zu analysieren und darauf zu reagieren, so dass Ihr Team den Bedrohungen immer einen Schritt voraus sein kann. 

Wenn Sie mehr über Sumo Logic Cloud-SIEM erfahren möchten, sehen Sie sich unsere interaktive Cloud-SIEM-Demo an.