Microsoft Teams Chat: the rising phishing threat and how to stop it

Introduction

Around mid-September, our Security Operations Centre (SOC) received a high number of alerts via two of the Endpoint Detection and Response (EDR) solutions we monitor within our Managed Detection and Response (MDR) service, CrowdStrike and Defender forEndpoint. Initial analysis showed malware was being distributed, but it wasn’t via email nor lateral movement. It was from a rather unusual source: Microsoft Teams Chat.

We expect Microsoft Teams Chat to be abused more often in the future, so we want to share our learnings with you in this blog. Topics include: how the attack worked, why Microsoft Teams Chat is becoming more popular for criminal groups for phishing, how to respond to and mitigate these attacks and how your IT team can prevent similar attacks from happening in the future.

NB: Not everything described in this blog may apply to your environment. If you need help, or want to add additional knowledge to this blog, feel free to reach out to our team using the form on this page. For emergencies or anything urgent, please see the incident response page.

Microsoft Teams as phishing vector

Phishing via Microsoft Teams is a relatively new threat. It’s a topic that TrueSec recently published research on, and was also reported on by Bleeping Computer. Previously, a traditional way to spread malware was via email phishing, but malicious actors found a new way to deliver their malware through the use of Microsoft Teams. They most likely use publicly available tools, such as TeamsPhisher.

The threat actor first compromises a legitimate .onmicrosoft.com domain, which is the mailing domain used for a Microsoft 365 environment for companies without their own custom domain. The actor may also register a completely new tenant. They then change a user account to match the name of a user within the targeted company, usually the CEO. It’s via this account that they send automated messages through Teams. The victims will see that someone is trying to chat with them, as shown in Figure 1.

Figure 1: External account trying to chat in Teams

Once the victims clicks to accept, an automated message will be returned and the attacker account will feature an (External) mark besides the name. We’ve seen incidents where the message was about a structural reorganisation within the company, indicating that some employees would be fired. An example of such a message can be found in Figure 2. This is of course designed to create fear amongst potential victims, increasing the likelihood that they will open the attached link.

Figure 2: External account trying to chat in Teams

In some cases we’ve seen, the message is sent to hundreds of employees and includes a link to a Sharepoint site hosting a malicious zip-file. Luckily, both EDR solutions blocked the execution of the malware. We obtained a copy of the malware and did a quick analysis to identify any indicators. We obtained the IP address of the C2 server and recommended the client block it in their firewall for an additional layer of security.

The zip-file contained malicious software (Darkgate Loader). When the victim downloads the zip and opens it, they will see several files masquerading as a PDF. In reality, these files are LNK files which execute code. A LNK file, or "Link file," is a Windows shortcut that provides quick access to files, folders or programs by storing their location with an associated icon. Once the user has opened the malicious file, a download of additional malicious software is triggered via the built-in curl.exe command. A legitimate (signed) AutoIt 3 executable is downloaded to the system, along with a malicious AutoIt (au3) script file, which is then executed. The malware will then copy itself to a randomly named directory in C:\ProgramData and add a shortcut with a random name to the Startup folder, to ensure the malware is started every time the user logs in. Figure 3 displays the infection chain of the DarkGate Loader.

Figure 3: Infection chain DarkGate Loader

Response and mitigation

We managed to mitigate such attacks for our customers, however such an attack can still be daunting, especially if hundreds of users are targeted at the same time. If you are faced with a similar threat, we recommend you take the following actions:

1. Communication and end-user awareness

In parallel to the technical measures described below, please make sure to communicate to employees that they have received the malicious Teams External Invite or Teams Chat Message. Share identifiable material, like the impersonated name, email address and screenshots of the attack. Ask employees to delete the chat in the Teams application while IT is handling the response operation.

Ask end-users who clicked or accepted the invite, to report the event to IT allowing them to investigate employee systems. In the cases we have seen, IT had already deployed EDR on all systems in advance. This allowed us to perform mass threat hunts and scans for indicators of compromise, where end-user feedback only served as confirmation.

2. Use eDiscovery to revoke malicious invites in Purview

Microsoft’s eDiscovery dashboard, part of Microsoft Purview (Compliance Centre), allows you to search, investigate and purge (delete) Teams messages. Depending on the license, IT can try to retract the malicious invite and/or message via eDiscovery. Detailed instructions on how to delete Teams Chats can be found in the documentation provided by Microsoft here.

Please note that you need a Premium eDiscovery license to perform this action. There are no other methods we know of for removing Teams chats from users. Unfortunately, this feature is not included in the Standard Microsoft eDiscovery license. One of our clients had a Premium eDiscovery subscription.

3. Report domain(s) in Security Centre

Microsoft Security Centre dashboard provides a Report Submission page, where in some cases we’ve seen, only URLs, email bodies and email attachments can be submitted for analysis. We reported the malicious “REDACTED-my.sharepoint.com” and “REDACTED.onmicrosoft.com” URL’s. Reporting allows Microsoft Security to assess the domains and centrally block them.

Figure 4

Reporting of Teams is only allowed if you explicitly enable this setting first, which allows Teams message reporting by end-users and admins. Our advice is to enable it, if not already enabled. Because changes to this policy takes hours to be rolled-out in your tenant, if the setting is disabled, it will limit your ability to ask end-users to report the Teams messages - a scenario we have recently experienced.

Figure 5

4. Block malicious domain(s) in Teams Admin Centre

During an attack, you can block malicious domains in the Teams Admin Center (link), preventing incoming messages. To add blocked domains, go to Users -> External Access, as shown in Figure 6.

You have several options: allowlist external domains, denylist external domains, denylist all external domains, or allowlist all external domains, as displayed in Figure 7. Please be aware that changing these settings could impact your business by prohibiting legitimate external users from contacting you via Teams.

While blocking certain domains can be useful, it also means that adversaries could acquire another legitimate .onmicrosoft.com domain and initiate a new attack. Allowing specific external domains might be a better approach to prevent future attacks. However, it would require implementing a process for IT to add trusted domains.

NB: In one case, blocking external access after or during the incident did not purge the invite and/or message that was already sent by a threat actor. It only mitigated the risk of a new invite, new message or next attack with different IoC’s.

Figure 6

Figure 7

Figure 8

Figure 9

4. Report malicious domain(s) to Microsoft

It is possible to report malicious domains to Microsoft through their MSTC portal, accessible here. The portal is illustrated in Figures 8.

Figure 8

Prevention

There are ways for companies to protect themselves against attacks like this. Below are a few measures they could take.

1. Change Teams policy to block external domains in teams or whitelist

Setting up a Microsoft Teams policy to allowlisting or denylisting all external communication is a viable measure. If your company relies on external communication, it's advisable to establish an allowlist policy for only trusted domains to send messages to you. However, it's crucial to have a process in place for adding external domains, like the IT support ticketing system used internally.

Tip: eDiscovery Premium can be used to draft a list of benign external domains that are regularly used by the business. This allows you to draft an initial whitelist as a starting point.

2. User awareness/simulation

Since end-users may not yet be familiar with such attacks via Teams or other ‘trusted’ internal communication channels, it is critical for companies to raise awareness about this new method.

In addition to awareness campaigns, it's also advisable to simulate such attacks to better prepare your staff. Tools like TeamPhisher can be employed for this purpose. Simulating these attacks allows employees to recognise the signs of phishing and helps you strengthen your security measures.

3. Strong EDR configuration and 24/7 follow up

It is important for companies to have a well-configured EDR solution, such as CrowdStrike Falcon or Defender for Endpoint (P2/Business), and take action when alerts are generated. We’ve seen EDR tools block malicious actions, but follow-up by a human cyber expert is also necessary. If you leave the alert ‘as is’ just because it was blocked, the threat may still exist.

Companies should respond to alerts even if the execution was blocked. It is important to investigate what happened, how it occurred, how to prevent it and how to remove any remnants of the action/infection. In the cases we’ve seen, the LNK file was executed, but the execution of CMD.exe was blocked on most devices. All devices which have generated an alert were also isolated while we investigated how far the infection had spread.

Indicators of compromise

The following list of indicators can be used to prepare your detection systems for a similar attack. Please note that these indicators will change over time, relatively quickly. To copy hash values for all elements listed below, you can use this link.

Sample HTTP network traffic of DarkGate:

1  POST / HTTP/1.0
2  Host: 5.188.87.58:2351
3  Keep-Alive: 300 
4  Connection: keep-alive
User-Agent: Mozilla/4.0 (compatible; Synapse)
5  Content-Type: application/x-www-form-urlencoded
6  Content-Length: 221
8
9  id=REDACTED&data=REDACTED&act=1000 
10
11 HTTP/1.1 200 OK
12 Connection: close
13 Content-Type: text/html; charset=ISO-8859-1
14 Content-Length: 2
15 Date: Tue, 12 Sep 2023 17:30:58 GMT
16
17 ok

Hunting

Our sample of DarkGate left traces at the following locations:

1 let Hashes = pack_array('237d1bca6e056df5bb16a1216a434634109478f882d3b1d58344c801d184f95d','6aca36077144a2c44a86feba159c5557aae4129f32b9784e9c294bec462b5610','317063a3c83ac853e1dcb17d516445faf9798ad0150b3ac3f3f27f6830b3afb7','4037103e3da62794fba6a060bf654a536fe7d4eaf2d14bec69941f86f2bf54df','11edca0a0529daddf1689e7c02dd4a0aa29c2bb29faad2a5b582a9664ab74b8e','3c470fc007a3c5d59f1c3c483510c60eeb07852905a58d01601bcd0bd2db1245','31fdcaa7f8fc8293b0b2c95098721dc61cbfab4ef863fa224dee81e30d964139','c24ee7d0f3f68687d5390968ec23c9dd7bc68c61817d4c0f355a992591539e41');
2 DeviceFileEvents
3 where SHA256 in (Hashes)

1 DeviceNetworkEvents | where RemoteUrl contains "REDACTED-my.sharepoint.com"

main event_simpleName=DnsRequest DomainName="REDACTED-my.sharepoint.com"
2 | dedup DomainName, ComputerName
3 | table DomainName, ComputerName