{"id":25664,"date":"2025-05-20T05:00:00","date_gmt":"2025-05-20T13:00:00","guid":{"rendered":"https:\/\/www.sumologic.com\/?post_type=blog&p=25664"},"modified":"2026-02-17T11:12:58","modified_gmt":"2026-02-17T19:12:58","slug":"monitor-slack-audit-logs-cloud-siem","status":"publish","type":"blog","link":"https:\/\/www.sumologic.com\/blog\/monitor-slack-audit-logs-cloud-siem","title":{"rendered":"Secure your Slack environment with Sumo Logic Cloud SIEM"},"content":{"rendered":"\n
\n
\n
\n
\n
\"Sumo<\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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

Why Slack\u2019s audit logs are key for better security<\/h2>\n\n\n\n

With Slack being such a highly appealing target, your Slack environment should be continuously monitored for malicious behavior.<\/p>\n\n\n\n

One way to begin monitoring is through logs. Slack provides several different types of logs<\/a>, from audit logs to access logs and more. For the purpose of this blog, we\u2019ll focus on audit logs<\/a>, which Slack generates \u201cto ensure continued compliance, to safeguard against any inappropriate system access, and to allow you to audit suspicious behavior within your enterprise.\u201d<\/p>\n\n\n\n

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

Use Slack\u2019s audit logs to perform threat detection<\/h3>\n\n\n\n

A valuable feature of the Slack audit logs<\/a> 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\u2019ll likely need to investigate further to qualify it and decide whether to act on it.<\/p>\n\n\n\n

Although Slack doesn\u2019t provide confidence levels along with their anomaly events, they\u2019ve made it clear that some events are considered high-confidence indicators of compromise. <\/p>\n\n\n\n

The Anomaly event response feature<\/a> 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 \u201cAccessing Slack from a Tor exit node\u201d and \u201cData scraping,\u201d suggesting that Slack Engineering considers these two detections high-confidence.<\/p>\n\n\n\n

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<\/a> and trigger a rule named \u201cNormalized Security Signal\u201d (MATCH-S00402). This means anomaly events can now contribute to an entity\u2019s activity score<\/a>, helping analysts quickly identify users or systems exhibiting suspicious behavior.<\/p>\n\n\n\n

\"blog<\/p>\n\n\n\n

Slack anomaly events are passed through as Sumo Cloud SIEM Signals<\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

\"blog<\/p>\n\n\n\n

Slack Anomaly event response default settings<\/em><\/p>\n\n\n\n

How to collect and ingest Slack audit logs with Sumo Logic<\/h2>\n\n\n\n

Collecting Slack audit logs with Sumo Logic is a straightforward task. This thorough guide<\/a> shows how to collect logs from Slack, but here\u2019s an overview of the steps:<\/p>\n\n\n\n

    \n
  1. Confirm that you have a Slack Enterprise Grid account. Without an Enterprise Grid account, you won\u2019t be able to collect Slack audit logs.<\/li>\n\n\n\n
  2. Create a Slack app that has auditlogs:read<\/code> permission.<\/li>\n\n\n\n
  3. Install the app on Enterprise Grid.<\/li>\n\n\n\n
  4. Install and configure the Sumo Logic Slack Cloud-to-Cloud Connector.<\/li>\n\n\n\n
  5. IMPORTANT NOTE: Ensure that the Slack log source is configured to forward logs to the SIEM by selecting the \u201cForward to SIEM\u201d checkbox.  <\/li>\n<\/ol>\n\n\n\n

    \"blog<\/p>\n\n\n\n

    How security analysts can use Slack logs for threat detection, investigation, and response <\/h2>\n\n\n\n

    Slack is providing a valuable service to its customers by detecting anomalous behavior and generating anomaly events, as they\u2019re uniquely positioned to understand what types of behavior should be considered anomalous on their platform.<\/p>\n\n\n\n

    However, Slack Engineering doesn\u2019t publicly share the detection criteria they use to generate anomaly events. It\u2019s not hard to understand why \u2014 if the criteria were public knowledge, attackers would have an easier time formulating defense evasion techniques.<\/p>\n\n\n\n

    For security analysts, though, this can make things difficult. Without knowing exactly why an alert was triggered, you\u2019ll 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.<\/p>\n\n\n\n

    Some anomaly event reasons provide more clarity than others about what triggered the event. Others, such as \u201cexcessive_downloads,\u201d 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 \u201cnormal\u201d for the user compared to prior time periods. <\/p>\n\n\n\n

    Now, let\u2019s dive into how to investigate some of these anomaly events in practice. <\/p>\n\n\n\n

    Understanding Slack session IDs<\/h3>\n\n\n\n

    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\u2019ll likely see variations in artifacts like:<\/p>\n\n\n\n