Secure your Slack environment with Sumo Logic Cloud SIEM

Slack has become integral for many organizations, powering everything from internal to external communication and project workflows. But as adoption grows, so does risk. Hackers are increasingly targeting Slack as it often contains intellectual property, credentials, and valuable reconnaissance information.

Sumo Logic Cloud SIEM now secures your Slack usage against insider and third-party threats by monitoring audit logs for suspicious activity to keep your company and its data protected.

How a $10 stolen Slack cookie led to a major breach

Take the Electronic Arts (EA) breach as an example. In the data breach, attackers bought a stolen Slack cookie for $10. That purchase gave them access to an internal Slack channel, which they then used to socially engineer EA’s IT team into giving them an access token to EA’s internal network. Attackers then stole 780GB of data, including source code for the game FIFA 21 and proprietary software development kits. 

EA isn’t alone. High-profile companies such as Disney, Rockstar, Uber, and Twitter have suffered attacks where Slack has played a major role in the attack’s success. 

It’s not hard to understand why Slack is targeted as either an important pivot point or the final objective for an attacker, as it is ripe ground for attackers as they execute various tactics such as initial access, discovery, credential theft, and exfiltration. 

Why Slack’s audit logs are key for better security

With Slack being such a highly appealing target, your Slack environment should be continuously monitored for malicious behavior.

One way to begin monitoring is through logs. Slack provides several different types of logs, from audit logs to access logs and more. For the purpose of this blog, we’ll focus on audit logs, which Slack generates “to ensure continued compliance, to safeguard against any inappropriate system access, and to allow you to audit suspicious behavior within your enterprise.”

These audit logs and the ability to access them via API are integral for a SIEM solution like Sumo Logic to perform security monitoring and integration. 

Use Slack’s audit logs to perform threat detection

A valuable feature of the Slack audit logs is anomaly events, which are automatically generated when Slack detects anomalous actions or behavior. Not all anomaly events require action, and different anomaly events have different confidence levels. If an anomaly event is triggered, you’ll likely need to investigate further to qualify it and decide whether to act on it.

Although Slack doesn’t provide confidence levels along with their anomaly events, they’ve made it clear that some events are considered high-confidence indicators of compromise. 

The Anomaly event response feature also provides a clue as to which anomaly events Slack considers high-confidence. The feature automatically ends user sessions if certain anomaly events are attributed to them. The two events chosen by default are “Accessing Slack from a Tor exit node” and “Data scraping,” suggesting that Slack Engineering considers these two detections high-confidence.

Slack anomaly events are especially useful for security teams because they can be ingested and analyzed in a SIEM. Sumo Logic Cloud SIEM fully supports Slack anomaly events. These events are normalized as threat alerts and trigger a rule named “Normalized Security Signal” (MATCH-S00402). This means anomaly events can now contribute to an entity’s activity score, helping analysts quickly identify users or systems exhibiting suspicious behavior.

Slack anomaly events are passed through as Sumo Cloud SIEM Signals

Slack Anomaly event response default settings

How to collect and ingest Slack audit logs with Sumo Logic

Collecting Slack audit logs with Sumo Logic is a straightforward task. This thorough guide shows how to collect logs from Slack, but here’s an overview of the steps:

1. Confirm that you have a Slack Enterprise Grid account. Without an Enterprise Grid account, you won’t be able to collect Slack audit logs.
2. Create a Slack app that has auditlogs:read permission.
3. Install the app on Enterprise Grid.
4. Install and configure the Sumo Logic Slack Cloud-to-Cloud Connector.
5. IMPORTANT NOTE: Ensure that the Slack log source is configured to forward logs to the SIEM by selecting the “Forward to SIEM” checkbox.  

How security analysts can use Slack logs for threat detection, investigation, and response 

Slack is providing a valuable service to its customers by detecting anomalous behavior and generating anomaly events, as they’re uniquely positioned to understand what types of behavior should be considered anomalous on their platform.

However, Slack Engineering doesn’t publicly share the detection criteria they use to generate anomaly events. It’s not hard to understand why — if the criteria were public knowledge, attackers would have an easier time formulating defense evasion techniques.

For security analysts, though, this can make things difficult. Without knowing exactly why an alert was triggered, you’ll likely spend more time formulating queries to retrieve the audit logs that triggered the anomaly event. Tuning the analytics and assessing it for false negatives is also more challenging for similar reasons and may require guesswork.

Some anomaly event reasons provide more clarity than others about what triggered the event. Others, such as “excessive_downloads,” are murkier, requiring you to search for download activity leading up to the event, review either what was downloaded, or assess whether the download volume is “normal” for the user compared to prior time periods. 

Now, let’s dive into how to investigate some of these anomaly events in practice. 

Investigating potential cookie theft in Slack 

Let’s return to the EA breach example, where attackers used a stolen cookie to access internal systems. Which Slack anomaly events would we expect to see from the reuse of a stolen cookie? If anomaly events are logged, how can we investigate them?

Understanding Slack session IDs

Each time a user logs into Slack, a session ID is generated. That session persists as a cookie on the device. Our expectation is that each session ID should map to a single device. If a cookie is stolen and used on a different device, you’ll likely see variations in artifacts like:

• User agent string
• IP address and location
• TLS handshake (ja3 fingerprint) 

These signals can help identify suspicious reuse, though it’s important to note that Slack audit logs are only generated for interactive actions. Passive access (like reading messages without clicking or downloading) may not trigger log entries, so detecting cookie reuse depends on the nature of user activity.

These differences will appear in the logs associated with that same session ID.

Example Slack session ID as seen in a Sumo Logic Cloud SIEM record

Anomaly events that could signal cookie theft

In reviewing the list of Slack anomaly events that would be triggered by cookie theft, there are several candidates: 

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

Hunt for potential cookie theft using Sumo Logic

With the above knowledge, we’ll begin by casting a wide net and searching for all recent Slack anomaly events in our environment for the last two weeks. The following search will return all Slack anomaly events and group them by reason:

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

Figure 4: Slack anomaly events grouped by reason

In our case, the search returned 323 results. Two items of note:

• More than one reason can be assigned to an anomaly, as made evident by results such as asn|ip_address and unexpected_user_agent|user_agent.
• The highest-volume anomaly reason is asn|ip_address. These events can be tuned by adding trusted autonomous system numbers (ASNs) and IP address ranges to an exclusion list via API.

Our hunt for stolen cookies will continue by focusing on the events with the reasons unexpected_user_agent and user_agent. We retrieve those events and their session IDs via the following query:

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

Session IDs of unexpected_user_agent anomaly events

Now that we have anomalies to research, let’s drill into a few of them:

Reviewing the details of the anomaly event provides some context about why the event was triggered:

Details of the unexpected_user_agent|user_agent anomaly event

Analyzing the anomaly event

The details metadata of the anomaly event provides the reason for the event triggering: the IP address and user agent have changed. 

The IP address change:

• The current IP address: 172.59.222.55
• The previous IP address: 204.16.138.54

Does the IP address change indicate that the device changed, perhaps from the user’s to the attacker’s? It’s possible, but considering that it’s a mobile device, and the geoIP information places both addresses in the Charlotte, North Carolina area, we don’t suspect a change in devices.

The user agent change:

• The current user agent: “AppleCoreMedia/1.0.0.21F90 (iPhone; U; CPU OS 17_5_1 like Mac OS X; en_us)”
• The previous user agent: “com.tinyspeck.chatlyio/25.04.10 (iPhone; iOS 17.5.1; Scale/3.00)“

Does the user agent change indicate that the device changed?

• Assuming that the user agent strings weren’t spoofed, an iPhone with OS version 18.4. 
• Tiny Speck is the original name of the company that developed Slack. The user agent string com.tinyspeck.chatlyio/25.04.10 likely corresponds to the Slack iOS client.
  AppleCoreMedia is a framework used by iOS for handling streaming and media playback.
• Based on this, it’s plausible that the AppleCoreMedia user agent appears when media files (such as videos) are streamed from within Slack, while the Tiny Speck agent reflects typical Slack usage. While we can’t confirm this behavior from public documentation, our log analysis supports this interpretation.
• AppleCoreMedia is used by iOS for streaming media.

So perhaps the Tiny Speck user agent is for normal Slack usage, and the AppleCoreMedia user agent is for streaming media from Slack?

We can test this theory by reviewing the individual logs contributing to the anomaly event. We’ll start by searching for the session ID and examining the user agent associated with the actions:

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

Remember, sessions can last a long time, and you should be generous when setting the time range for the search. The session investigated in this discussion lasted over 90 days.

Audited Slack actions and their associated user agent strings

We’ll focus on the days preceding the anomaly event on April 9, 2025. In the hour leading up to the anomaly event, the user agent changed from the Tiny Speck (Slack) agent to AppleCoreMedia. Why? Possibly because the file type involved in the file_downloaded actions required streaming. We’ll add the file_mimetype field to the display of our search results by selecting the field name from the hidden fields section of the field list:

Field 8: Adding the file_mimeType field to the display of search results

With the file_mimeType displayed, we can see plainly that the user agent is AppleCoreMedia when downloading MP4 files and Tiny Speck when downloading a JPG file:

Figure 9: Analysis of user agent strings associated with downloaded file types

In this case, the Slack Anomaly event didn’t uncover malicious behavior. There was a session in which the user agent changed, but it was not because more than one device was using the same session cookie. 

Using Slack anomaly event types for custom analytic content

Slack doesn’t reveal the exact logic behind their anomaly detection, which makes sense from a security standpoint. But the anomaly event types themselves serve as inspiration for dashboards, hunts, and our own custom analytics. 

You can use them to monitor for:

• Administrative actions outside of the norm, with a First Seen rule
• Spikes in the volume of downloads, file shares or message deletions, with Outlier Rules 

Going back to the topic of cookie theft, how can we hunt for Slack sessions that involve more than one user agent string? We can use the count_distinct operator:

(_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

Count of distinct user agent strings per sessionId

Then, when we find sessions of interest, we can return all its logs via a query such as:

(_index=sec_record_notification OR _index=sec_record_audit) metadata_vendor="Slack" sessionId=[insert session ID here]
| count by http_userAgent

Stay ahead of Slack-based threats

Slack is a rich source of company information, making it a desirable target for hackers. Monitoring Slack audit logs, including anomaly events, is crucial for detecting a compromise early. 

Sumo Logic makes it easy to collect, analyze, and act on these logs, so your team can stay one step ahead of threats. 

To learn more about Sumo Logic Cloud SIEM, view our interactive Cloud SIEM demo.