Obscurities with MS Teams part 3

Obscurities with MS Teams part 3

·

5 min read

This time we look mostly at the accounts used for phishing.

tl;dr

When phishing via Teams, an attacker controls the source AAD. Therefore, he can set every username he wants. This opens some possibilities.

  • E-Mail as username

  • Suffix the Username to generate some context around warnings from teams (external)

  • Unicode spaces, to break the layout and move things out of sight

  • Unicode emojis to generate trust

  • Unicode characters (Right-To-Left-Override, ...) to break things

Furthermore, when sending a message, we can provide a lot of HTML tags, generating unnormal-looking messages, which might trick users.
Punycode in links is also interpreted, so we can also spoof some URLs with this.

Introduction

After publishing Obscurities with MS Teams part 2 I got some feedback, which motivated me to dig a little bit more into the social engineering possibilities with Teams. And surprise, there are still so many small "features" which can be abused.

Choose a Username

As an attacker controls the attacker AzureAD, it is possible to choose a username as wanted. This provides a lot of interesting possibilities.

If we look at the AAD user management, we see, that there is no real limitation for usernames, besides a maximal length of 256 chars. That's a lot, so let’s start.

AAD character limit of 256

I came up with some test accounts.

Usernames to play with

Let’s dive in.

E-mail as Username

E-mail as Username

We can choose an email as a username, which then is shown to the victim.
NOTE: There are no further warnings or indicators shown besides what is visible in the pictures

Victim view

Not that bad, but still not good.

Suffix the Username to generate some context around warnings from teams (external)

Another possibility is to surround the (external) Warning with a wording, for example, "HelpDesk for (intern) & (external).

Victim view

You might ask, why is the indicator for External users in the same font and size and also inline? I really don't know.

Unicode spaces, to break the layout and move things out of sight

After playing a little bit around, it stood out that it is simply possible to move some stuff out of sight by adding a long username with some Unicode space characters.

Victim view

It is getting better.

🚒 Unicode emojis to generate trust 🚒

Trustworthy Unicode emojis

By using some Unicode emojis we can show for example a verification icon and a lock. And as we all know from HTTPS, a lock is a guarantee for safety! Bad guys never gonna get one.

Victim view

If we look at the "___", which represents a character, in the following picture, we can see, that we can move the "external" indicator out of sight.

Victim view, with hoovering the username showing the long list of Unicode spaces

Almost there.

Unicode characters (Left-To-Right-Override, ...) to break things

There are some additional Unicode characters well known to cause trouble in applications if interpreted. The most famous should be the "Right-to-Left Override" (RLO) character : U+202E

If we add such a character in the username some stuff is breaking.

RLO is between Help and Desk

Tampering of messages by the RLO

Tampering of another message by the RLO

It might be possible to abuse this behavior somehow, but I did not come up with a good vector, as (lanretxE) is not a very senseful word.

Sending a formatted message

If we look at the HTTP Requests for a message, we see that various HTML elements are allowed. This allows crafting of some untypical-looking messages. And if something is special/untypical it must be reserved for administrators!

By adding some HTML tags, we can craft our own layout

In this case by adding three <div> tags, we can craft a table-like layout. The verification Icon is included as base64 data.

Snippet out of the request, showing the edited HTML tags.

Okay, so a secure, "verified" helpdesk@victim.com account, moving some indicators out of view and sending a verified message? Nice.

PS: It might of course be possible to craft an even more plausible scenario and better-looking layout, but TEAMS BLUE was good enough for demonstration.

Chaining it and spicing it up

Verification through another controlled user

So we can send a HTML formatted message to the victim and as we need some group chat anyway to circumvent some warning screen, we can just add another controlled user to verify that the update was working great.

Bonus: Punycode URLs

If we send some Punycode URLs, Teams is not resolving them to the xn spelling.

νictim.com should resolve to xn--ictim-ece.com/update. In the bottom left corner, we can see how the browser resolves the domain.

Victim view

Conclusion

Microsoft made some improvements for Teams, especially in case of security. However it is still not plausible to me, why the remaining attack surface is still so big, and a lot of tampering is possible. I am quite sure, that there are some more ambitious ways to get an even better chain for phishing.

Countermeasures and indicators

  • Turn off the external collaboration for unknown domains/tenants.

  • Hoovering a user account shows the E-Mail / the tenant. But keep in mind, that normal spoofing techniques still apply here. So maybe a new .zip, .eu domain or some Uppercase I replacing an l.

  • Showing Profile Pictures seems to be restricted to one tenant

This article was originally published on BadOption, by a Cyvisory Group member.

Links

Work and inspiration from others: