When I first started diving into offensive Slack access, one of the best public resources I found was a blog post by Cody Thomas from back in 2020 (which I highly recommend giving a read). This follow-up post aims to take a look at changes Slack has implemented since Cody’s post and reexamine avenues to achieving Slack access from ceded access on both macOS and Windows hosts.
What’s Changed Since 2020?
The biggest change Slack has made since Cody’s original post involves cookie encryption (at least on macOS). Back in 2020, the macOS Slack cookies database contained cleartext cookies, which meant an attacker with disk access could steal the database file and place it on another host where the attacker’s local Slack application could replay the cookies.
On macOS, the cookie values are now encrypted with a key named Slack Safe Storage, which is stored in the user’s login Keychain. On Windows, the cookies are encrypted by a data protection API (DPAPI) key.
The SQLite cookies database can be found at:
- %APPDATA%\Slack\Network\Cookies (Windows)
- ~/Library/Application Support/Slack/Default/Cookies (macOS)
Additionally, some of the files containing Slack user metadata have been consolidated into a single file:
- %APPDATA%\Slack\storage\root-state.json (Windows, Figure 1)
- ~/Library/Application Support/Slack/storage/root-state.json (macOS)
This file contains JSON content detailing Slack UI settings, metadata for files downloaded through Slack, and workspaces the user is signed into.
Cookie Theft on Windows Hosts
Since Slack stores its cookies in a SQLite database with the same database schema as Chrome, it shouldn’t be too hard to modify a tool like SharpDPAPI’s SharpChrome to accommodate Slack cookie retrieval (shoutout to Lee Christensen for doubling back and actually implementing Slack support in this
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: