SlackPirate Set Sails Again! Or: How to Send the Entire “Bee Movie” Script to Your Friends in Slack – Source: securityboulevard.com

TLDR: SlackPirate has been defunct for a few years due to a breaking change in how the Slack client interacts with the Slack API. It has a new PR by yours truly to let you loot Slack again out of the box, and a BOF exists to get you all the credential material you need to do it. I recommend you let Nemesis do the heavy lifting of finding interesting data in what you pull back.

Slack Cookies BOF PR

SlackPirate PR

The BOF

This all started because I noticed that my brilliant colleague Matt Creel had added a new BOF to TrustedSec’s CS-Remote-OPs-BOF collection that pulled Slack cookies from the memory of either a browser or Slack client process. This would allow an operator to then utilize the stolen cookies to proxy browser traffic through a compromised machine and access the target organization’s Slack instance. He released a great blog about it if you want to learn more.

Slack is awesome, and full of valuable data about an organization. There’s the obvious stuff like people being lax and pasting credentials, but don’t forget that is also a comprehensive directory of who works there, and probably more valuable than their internal documentation (when was the last time you actually searched Confluence? Exactly.)

I was stoked to start using Matt’s BOF, since there hasn’t been an assessment where I got access to Slack where it didn’t prove useful. That said, something was nagging at me… This is the age of Nemesis! We don’t need to read anymore, reading is for squares! We have computers to do that for us while we watch short-form videos of animals with funny things on their heads (see below). Reading Slack was no exception.

A classic.

So I set out to find a good Slack looter. I quickly stumbled upon SlackPirate, created by Mikail Tunç, which seemed to be the defacto choice. And for good reason! It is simple, fairly comprehensive, and also quite modular; you can change what is being searched for with relative ease. By default though it does a lot, such as:

• Scraping all messages for private keys, passwords, and cloud provider credentials
• Grabbing a list of all Slack users
• Downloading hosted files en-masse
• Pulling important Slack-specific data, such as pinned messages

Great! I plugged in my cookie and… no dice. I was unable to authenticate to any of the API endpoints I should be able to. I knew the Slack cookie I had was valid, so it was time to investigate.

Troubleshooting

Figuring out what was the matter was pretty breezy! Slack is an Electron app, so you can still access the Chrome dev tools. Slack used to allow this by exporting a particular environment variable:

SET SLACK_DEVELOPER_MENU=TRUE && start C:UsersAppDataLocalslackslack.exe

You could then access the developer tools by pressing ctrl + alt + i. This no longer works for me, so I instead opted to use Chrome remote debugging, which was successful.

(NOTE: If you’re reading this blog, there’s a good chance your security team will have an alert in place for Chrome remote debugging to prevent cookie crimes. You may want to check with them before doing this on a work computer.)

C:UsersAppDataLocalslackslack.exe --args --remote-debugging-port=9222

Then when you browse to chrome://inspect/ you will be able to see Slack as with option to inspect:

By pressing “inspect” you get your dev tools, plus a neat window of the Electron app you are debugging! I have never tried to use this to screen-peek on an Electron app over a proxy, but wouldn’t that be neat.

My strategy at this point was to record network traffic while performing actions that seemed like they would have to be hitting a defined API endpoint from the client and seeing what the network traffic looked like. For example, going to the “users” page and finding what endpoint got hit to retrieve them. That’s what I am doing in the screenshot above for the BloodHoundGang slack (which you should join if you haven’t).

This allowed me to compare the requests with what was being performed in SlackPirate and determine what had changed to break it.

Turns out, not much! The APIs ended up being the same as before, the only piece that was missing what that now requests were made with a token included in the request payload itself, in addition to the cookie in the headers we already knew about.

As you can see, this token is also in a nice searchable format, starting with “xoxc”, so the same technique used by Matt’s BOF to pull the cookie from memory can be used for the token. Now the BOF pulls both, and can be used not only get the credential material needed to browse a target organization’s Slack via a proxy, but also interact with it programmatically.

With these two pieces of information, you can hit the Slack API just as if you were the client when a user clicks around and types. You can even make your own janky Slack bots that post out of your account… which of course I did. But you already knew that from the title. So here’s screenshots of my fellow Specters suffering while I posted the entire Bee Movie into our group chat, each line as its own message. We all know it’s what you’re here for.

Quick aside — you may be thinking: Why go through all the trouble of doing this with the Electron client? Why not just open Slack in a web browser and inspect that traffic?

Anecdotally, I see people using the client way more often, so I wanted to make sure whatever I looked at would be representative of that. Also developers seem to trust dedicated clients more, so the tokens and cookies you snoop from them last much longer. For instance my buddy Jesko got tired of having to reauth to Slack, so he snagged a token from his phone’s client that never expires. My janky Slack bots haven’t had to reauth yet either.

SlackPirate Updates

So with our new programmatic access, it is time to loot! For the most part all of my changes to SlackPirate were updating the script to utilize the new token in addition to a cookie. There are a few other changes I threw in though that you may want to be aware of:

• There was an “interactive mode” that let you interact with multiple workspaces. This functionality has been removed and you will always need to provide the appropriate token and cookie for the individual workspace you want to target as arguments to the script
• The list of what files and strings are searched for by default is more focused on finding credential material, especially in file formats that are easy for Nemesis to parse
• Various functions targeting AWS data have been changed to also look for Azure data

And there you have it. With these new updates, you are ready to get back to a nice easy life of not reading and letting Nemesis read your target’s whole Slack for you. So kick back and let your reading comprehension regress to a third-grade level with another classic animal-with-thing-on-head video from the cellar. It is a fine vintage.

SlackPirate Set Sails Again! Or: How to Send the Entire “Bee Movie” Script to Your Friends in Slack was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from Posts By SpecterOps Team Members – Medium authored by Daniel Mayer. Read the original post at: https://posts.specterops.io/slackpirate-set-sails-again-or-how-to-send-the-entire-bee-movie-script-to-your-friends-in-slack-d9c691ae33f5?source=rss—-f05f8696e3cc—4