Come join us on a trip with the phishing boat

Internal IT & Security ran a targeted phishing training engagement targeting a small selection of Bouvet employees, mainly management, last week.

This was a simulated insider threat that utilized impersonated accounts on Slack to trick users into giving away both password and MFA tokens. This was a highly targeted attack, which resulted in full access to the AD accounts for multiple users, access to multiple Slack accounts, and the transfer of the Primary Workspace Owner role to the attacker.

We focused on high value targets, and was able to do much more than we dared to hope for. This was a new attack vector, one that most people never expected.

We used a combination of weaknesses in Slack to impersonate other accounts. Two of our accounts impersonated Slackbot, and another our CISO.

Simply asking nicely has proven to be very effective, so that's exactly what we did. We asked our targets to give us their password, or download and execute Excel macros.

The entire exercise went on for about a week, and we constantly adjusted and improved our pretext and tactics. We even had to help the target troubleshoot when the macro didn't work as expected.

Unlike the real Slackbot, our highly manual bot needed both food and sleep. This meant that we sometimes had a rather long delay before the "bot" reacted. Our targets didn't seem to notice that Slackbot was a bit slow and inconsistent at times, maybe it was a good thing for us that executives are busy people.

While Slack is considered to be a trusted channel, it is important to remember that this attack could have been carried out by both a multi-channel guest, or a disgruntled ex-employee. One of the weaknesses we abused could help ex-employees keep their Slack accounts when they quit.

Using Slack, we were able to get both passwords, MFA tokens, and execute code on other people's machines (that is, they ran it for us).

We had two different pretexts we used, but common for both of them were:

• We constructed a problem
• Offered a solution
• It was urgent

Common techniques used in phishing.

The STAR rule applies: Stop, Think, Ask, React / Report

Why did Slackbot ask for password in plain text? And why did Slackbot want the MFA token afterwards? Never enter passwords in clear text. The real Slackbot also has no email address, and a small heart instead of an online dot.

Why was there no conversation history when the CISO made contact? Wasn't his email address a little weird? But perhaps most importantly, why was he so eager for you to disable all security mechanisms to run his macro?

We did this to:

• Uncover weaknesses/vulnerabilities in our primary communication channel
• See how far we can take it, and where we might have to tighten the security
• Test user reporting and incident management
• Teach and train our employees

This entire exercise started with Kristian Nøstdal sending a link to a blog post from Eric Baily. In this blog post, «Spear phishing with Slackbot for fun and profit», he detailed how he should be able to trick users to give him their password by changing his name and profile picture to Slackbot.

Since Slack is a communication platform, it is naturally full of users. And creating new ones are very easy, as long as you have a valid email address (or an alias) in one of the approved domains for the workspace. So this was the first weakness we abused when we created new accounts. We did this to avoid having old conversation history appear when communicating with the impersonated account. Slackbot has a very simple profile, so we simply copied it.

There's a couple minor differences, like the local time and email address, and the green dot instead of the green heart. Setting the Display name and full name required abusing another weakness. Slack is blocking both slackbot and siackbot, but by using homoglyphs we were able to create a Slackbot that looks exactly like the original. It's impossible to see the difference in a conversation:

A bit further into the campaign, we also realized that we can change the email address to whatever we like after the account has been created. We only need the valid domain for initial account creation. So we made a nice email for Slackbot, and used this trick to create another account - a copy of our CISO:

Our primary goal at the start of this exercise was to transfer the Primary Workspace Owner role, so the first message from Slackbot was sent to the previous Primary Owner:

The next part took three days, and we thought our cover was blown several times. The first reply was received within half an hour, but wasn't a password at all.

A simple "bot"-reply resulted in something that looked like a password, but that didn't work. We got nothing but silence after the third attempt. So we sent a reminder the next day.

Still nothing. We started getting a bit impatient now. So on day three we made it appear a bit more critical.

An hour later, we got it! A valid password!

There was a slight problem, though...

Simply asking nicely worked for the password, maybe it will work for the OTP (One-Time-Password) as well?

There's a huge difference between Slackbot and Ѕlackbot, the latter needs lunch. And when we first got the password, it was in the middle of the lunch break. So by the time we had time to test it, the user had left to do some other thing. So every five minutes, we clicked "Resend" in the Slack login to keep triggering the MFA SMS, before sending this message:

20 SMS' later, we got it!

But it had expired, so this time we had to be quick!

And it worked! To not make it too obvious, and to give us more time, we let Slackbot finish the "job":

The primary objective was to become the primary owner, so after logging in there was no point in wasting time. Straight to the admin interface! Finding the transfer button required a google search, but once found it only required a username to transfer to and the password. And we already had the password...

And that was it. The ownership of the entire Bouvet Slack had now been transferred.

As Slack say themselves, this transferred the compete control. No other owners can transfer this back, so the email alert it triggered didn't really matter that much.

Slackbot also sent me this nice notification:

Since this worked, can we do more?

More we did! We tried the exact same on other executives. Several of them replied with something that looked like passwords, but didn't worked. A quick attempt with those passwords in AD revealed that we had in fact received the AD password instead of the Slack password. And even though the MFA token was sent from Microsoft instead of from Slack, it was still sent to us. Every time we managed to get a password, we also got the MFA token.

The fact that all our targets have too much on their schedule, and are very slow to read and respond, helped make this attack possible. In all cases where we got the AD password, Slackbot had first replied with the "invalid password" message, which we later deleted and replaced with the request for the MFA token.

But we had another account as well! Could this be used for something useful?

Of course it could. We have played around with Slack before, and made a Word macro that finds and steals cookies and the authentication token from the Slack app. This was easily converted to a Excel document, to avoid the security policy that blocks macros in .doc-files. We named the file "Sikkerhetshendelser i <name of region>", which means "Security incidents in <region>". To make it even more believable, and because we thought this would mark the file as trusted, it was uploaded to a public SharePoint site.

This required a lot more adaption than the password reminder from Slackbot. So the message we sent was changed a bit between each attempt. We also failed to get what we wanted from a user when we forgot to check if he used Windows or Mac.

We had to give a lot more support than we had anticipated, since the macro didn't want to run at all on the first attempt. The file wasn't trusted at all. To make it worse, when trying to assist the target, a screenshot revealing the real name of the attacker was sent. Luckily simply deleting it did the trick.

On the first attempt, we used a password protected zip file, mainly to force the user to not use the Excel web app. For the next ones we simply told the target to download and unblock the file from the start.

The fact that all of them chose to do this might point to people being used to strange requests from our CISO?

But despite all the issues, we managed to get the following messages published on Slack - without the account posting them knowing:

Not everything is what it seems.

Always verify the information or instructions you receive.

When in doubt, ask! And report.