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

Slack ist für viele Unternehmen unverzichtbar geworden, da es alles von der internen bis zur externen Kommunikation bis hin zu Projekt-Workflows unterstützt. Aber mit der zunehmenden Akzeptanz steigt auch das Risiko. Hacker haben es zunehmend auf Slack abgesehen, da es oft geistiges Eigentum, Zugangsdaten und wertvolle Aufklärungsinformationen 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

Schauen wir uns die Electronic Arts (EA)-Sicherheitsverletzung als Beispiel an. Bei der Datenpanne kauften Angreifer einen gestohlenen Slack-Cookie für 10 Dollar. Durch diesen Kauf erhielten sie 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 780 GB an Daten, darunter den 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 Slack-Audit-Protokolle sind Anomalie-Ereignisse, die automatisch erzeugt werden, wenn Slack anomale Aktionen oder Verhaltensweisen feststellt. Nicht alle Anomalien erfordern Maßnahmen, und verschiedene Anomalien haben unterschiedliche Konfidenzniveaus. Wenn ein anomales Ereignis ausgelöst wird, müssen Sie wahrscheinlich weitere Untersuchungen durchführen, um es einzuordnen und zu entscheiden, ob Maßnahmen nötig sind.

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 Anomaly-Event-Response-Funktion gibt auch einen Hinweis darauf, welche Anomalie-Ereignisse Slack als hochgradig zuverlässig einstuft. Die Funktion beendet automatisch Benutzersitzungen, wenn ihnen bestimmte Anomalie-Ereignisse zugeschrieben werden. Die beiden standardmäßig ausgewählten Ereignisse sind „Accessing Slack from a Tor exit node“ und „Data scraping“, was darauf hindeutet, dass Slack Engineering diese beiden Funde als hochgradig zuverlässig einstuft.

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 Slack-Anomalie-Ereignisse vollständig. Diese Ereignisse werden als Threat Alerts normalisiert und lösen eine Regel namens „Normalized Security Signal“ (MATCH-S00402) aus. Das bedeutet, dass anomale Ereignisse jetzt zum Aktivitätsscore eines Unternehmens 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 es die Dinge allerdings erschweren. Wenn Sie nicht genau wissen, warum ein Alarm ausgelöst wurde, werden Sie wahrscheinlich mehr Zeit damit verbringen, Abfragen zu formulieren, um die Audit-Protokolle abzurufen, die das anomale Ereignis ausgelöst haben. Die Abstimmung der Analyse und die Bewertung auf falsch-negative Ergebnisse ist aus ähnlichen Gründen ebenfalls schwieriger und ist möglicherweise ein Ratespiel.

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 der EA-Panne zurück, bei dem die Angreifer ein gestohlenes Cookie verwendet haben, um auf interne Systeme zuzugreifen. Welche Slack-Anomalieereignisse würden wir bei der Wiederverwendung eines gestohlenen Cookies erwarten? Wenn Anomalien 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 generiert. Diese Sitzung bleibt in Form eines Cookies auf dem Gerät gespeichert. Wir erwarten, dass jede Sitzungs-ID einem einzigen Gerät zugeordnet ist. Wenn ein Cookie gestohlen und auf einem anderen Gerät verwendet wird, sehen Sie wahrscheinlich Variationen in Artefakten wie:

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

Diese Signale können dabei helfen, eine verdächtige Wiederverwendung zu identifizieren. Beachten Sie jedoch, dass die Audit-Protokolle von Slack nur für interaktive Aktionen erstellt werden. Passiver Zugriff (wie das Lesen von Nachrichten ohne Klicken oder Herunterladen) löst möglicherweise keine Protokolleinträge aus, so dass die Erkennung der Wiederverwendung von Cookies 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_Adresse
• 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-Anomalien in unserer Umgebung in den letzten zwei Wochen. Die folgende Suche gibt alle Slack-Anomalie-Ereignisse 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 Dinge 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 unexpected_user_agent|user_agent Anomalie-Ereignis

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 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 mit den Aktionen verbundenen User Agent:

(_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 Auftreten der Anomalie wechselte der User Agent vom Tiny Speck (Slack)-Agent zu AppleCoreMedia. Und warum? Möglicherweise, weil der Dateityp, der in den file_downloaded-Aktionen involviert ist, Streaming erfordert. Wir fügen das Feld file_mimetype zur Anzeige unserer Suchergebnisse hinzu, indem wir den Feldnamen aus dem Abschnitt für ausgeblendete 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 werden, und Tiny Speck, wenn eine JPG-Datei herunterladen wird:

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

In diesem Fall hat das Slack-Anomaly-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 und damit ein begehrtes Ziel für Hacker. Die Überwachung von Slack-Auditprotokollen, einschließlich anomaler Ereignisse, ist entscheidend für die frühzeitige Erkennung einer Kompromittierung. 

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.