Slack Audit Logs and Anomalies
Like many Software as a Service (SaaS) offerings, Slack provides audit logs to Enterprise Grid customers that record when entities take an action on the platform. For example, when a user logs in, when a user updates their profile, when an app downloads a file, etc. The actual list of actions that are captured in the audit logs is quite extensive and it is worth perusing periodically for any new additions. The documentation also presents an example audit log and discusses the fields in detail. We suggest reviewing this documentation before proceeding further, and we’ve included an aesthetically pleasing example audit log that you can use to test your newfound audit log expertise:
Where are Slack Audit Logs Available?
Slack audit logs are available to Org Admins, Owners, and those with the Audit Logs Admin role via the Audit Log Dashboard by clicking Tools and Settings → Manage Audit Logs . We will go over a more detailed example of using the UI to interact with audit logs in a subsequent section. The audit logs are also available via an API, and many vendors have connectors available to ingest the audit logs into their platforms. A few examples include:
The Audit Log API allows for filtering by attributes like when the logs were generated, the action (up to 30 actions may be specified), actor, and entity. For example, if an enterprise was only interested in consuming the user login events from the audit logs, they could specify user_login for the action parameter when calling the API. Please see the API documentation for more detail.
Anomaly Events
What are Anomalies?
Included in the stream of audit logs are anomaly events (events with an action of anomaly). These differ from other audit logs events because, instead of recording an action that an entity performed on the platform, they indicate that Slack’s analysis pipelines have detected an entity performing an anomalous action (or set of actions) or the circumstances under which an entity performed an action are anomalous. Anomalies serve as indicators of unusual or potentially suspicious activity within your Slack workspace. For a comprehensive list of currently deployed anomalies and guidance on how to interpret them, please refer to our documentation. We strongly recommend reviewing this resource to gain a deeper understanding of available anomalies before proceeding further.
How to use Anomalies?
As with any new event source that an organization onboards, Slack anomalies require some investigation, experimentation, and analysis before they can be operationalized by a Detection and Response team.
In general, anomalies are not something that an organization would want to directly raise as an incident. They indicate that something unexpected occurred and further investigation may be warranted. The importance of an anomaly varies depending on each organization’s policies and permitted activities. For instance, if a user_agent anomaly is detected with a new User Agent like Go-http-client/2.0, it might indicate someone is using an automated tool to interact with Slack, rather than accessing it through the Slack app or website. For some organizations, using unsanctioned Slack clients may not be allowed by policy, so the security team would want to follow up with this user. Other organizations may allow their users more latitude, so this anomaly would be less interesting to them.
Allowlisting CIDR Ranges and ASNs
If an organization knows that certain IP addresses or network ranges are associated with legitimate activities, Slack provides a way for customers to allowlist these sources. These API endpoints allow one to add trusted CIDR ranges and ASNs, providing flexible options to fine-tune anomaly detection and reduce anomaly volume.
Correlating Anomalies
Correlating multiple anomalies can provide valuable insights into potential security concerns. For instance, consider a scenario where a user_agent anomaly occurs near an excessive_downloads anomaly. This combination could suggest a scraping tool is being used (note there is also a newly released, high fidelity unexpected_scraping anomaly for certain scraping scenarios). The significance of this activity will depend on your organization’s policies. However, the situation becomes more critical if an ip_address or session_fingerprint anomaly accompanies the previously mentioned anomalies. This combination could indicate that an external party has obtained a user’s cookie and is using it to scrape data. In such cases, most organizations would likely prioritize a thorough investigation.
Aggregating Anomalies
Finally, we can aggregate some anomalies to surface scenarios we are interested in. For example, an organization might observe multiple users generating excessive_downloads anomalies each day, but the anomalies may not represent malicious activity (benign outliers). Examining how many excessive_downloads anomalies a user generated over some period of time and comparing the total to historical norms could help uncover situations where a user is performing unwanted activity like scraping large amounts of data. For example, if an organization has never seen one of their users generate more than three excessive_downloads events in a day, they could look for cases where four or more excessive_downloads anomalies occur for a user and investigate those more closely.
Context from Audit Log Events
Anomaly logs have substantially lower volume than audit logs, typically by at least two orders of magnitude, so if an organization is interested in remaining aware of anomaly logs but cannot handle the full volume of their audit logs, they can filter for just anomalies using the method outlined earlier. That said, we highly recommend consuming the entirety of your audit logs whenever possible so you have the most amount of surrounding context possible when investigating anomaly logs. For example, the surrounding file_downloaded audit logs events provide additional context when a user triggers an excessive_downloads anomaly, allowing you to confirm which files were actually downloaded. Furthermore, in an Incident Response scenario, having the audit logs available locally in a easily queryable form can save time and stress.
Audit Log UI Example
If you would like to review your Slack audit logs without an external service, Slack provides a UI that can be reached from Tools and Settings → Manage Audit Logs. To demonstrate how to use the UI, we can walk through some activity from a salesperson, Matt, who is leaving the fictional company, Acme Corp. First we’ll load the main Audit logs tab:
Then, we’ll switch to the Security Detections tab to see any anomalies that Matt has generated:
We see that Matt generated several anomalies. By clicking on the ••• menu and then View Full Log Details, we can find out more information about an anomaly. The first one is a twofer and has the reasons unexpected_scraping and user_agent. The former indicates that scraping was detected from Matt, and the latter indicates that Matt’s user agent changed – in this case to Scrapers Inc_._ Scrapers Inc is not a user agent associated with any sanctioned Slack client and therefore we would not expect user activity from it. Note: if an unexpected_scraping anomaly appeared by itself, the User Agent would still be included, so strictly speaking we did not need the user_agent anomaly to determine that Matt is using an unexpected client.
The other anomaly that Matt generated is excessive_downloads, and it is further evidence that Matt is scraping data from the Slack workspace. Again, we can see that the activity is coming from a client with user agent Scrapers Inc.
Since Matt is leaving the company, we would like to know what sort of files he is downloading, so we flip back to the Audit Logs tab and filter for file_downloaded events:
Then, we examine one of the files by clicking the ••• menu and then View Full Log Details. The file is named Glengarry-Leads.xlsx which is probably not something Acme Corp would want a salesperson to be retrieving as they depart.
Terminating a User’s Active Sessions
If you identify suspicious activity associated with a user’s account and would like to take immediate action, it’s possible to terminate a user’s active sessions directly from the Audit Logs dashboard. To do this, navigate to the specific anomaly log entry belonging to the user in question, click the ••• menu, and select Sign Out Of Slack. This action immediately invalidates all active sessions for the user, forcing them to re-authenticate before regaining access to their account on any of their devices. (Alternatively, you can selectively terminate the user’s active sessions by device type, such as mobile or desktop only, if you require more granular control over how and where the user is impacted).
Other Detection Thoughts
An ip_address anomaly was not generated for Matt’s activity in this situation, but, if it were, an analyst would want to determine if the triggering IP is one that they would expect Matt to be accessing Slack from (has he used it historically when accessing company systems, is it a VPN endpoint, is it known to be malicious, etc.). If the IP is not one that Matt is expected to use, then this activity could indicate that a malicious actor has obtained access to Matt’s account and is scraping data. In general, we recommend checking the IP address included in anomalies under investigation regardless of whether an ip_address anomaly was generated for the user.
Similarly, if a session_fingerprint anomaly were generated for Matt around the time of these anomalies, it might indicate that Matt’s session cookie was exfiltrated and is being used by a malicious actor to scrape data. Again, we recommend investigating the IP address contained in the anomaly, and using other sources of telemetry like logs from agents running on Matt’s endpoint to ensure that he is responsible for the activity.
As we discussed earlier, the user agent associated with anomalies like excessive_downloads, user_agent and ip_address can be a good signal that scraping or other unwanted activity is occurring. We can operationalize this insight by surfacing anomalies with an unexpected user agent. Rather than attempting to enumerate all possible unexpected user agents, it’s much easier to look for cases where the user agent is not in a set of expected values for an organization (think allowlist vs blocklist).