{"id":105645,"date":"2022-01-26T09:00:00","date_gmt":"2022-01-26T17:00:00","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/?p=105645"},"modified":"2023-06-26T15:56:55","modified_gmt":"2023-06-26T22:56:55","slug":"evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2022\/01\/26\/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\/","title":{"rendered":"Evolved phishing: Device registration trick adds to phishers\u2019 toolbox for victims without MFA"},"content":{"rendered":"\n

We have recently uncovered a large-scale, multi-phase campaign that adds a novel technique to traditional phishing tactics by joining an attacker-operated device to an organization\u2019s network to further propagate the campaign. We observed that the second stage of the campaign was successful against victims that did not implement multifactor authentication (MFA), an essential pillar of identity security. Without additional protective measures such as MFA, the attack takes advantage of the concept of bring-your-own-device (BYOD) via the ability to register a device using freshly stolen credentials.<\/p>\n\n\n\n

The first campaign phase involved stealing credentials in target organizations located predominantly in Australia, Singapore, Indonesia, and Thailand. Stolen credentials were then leveraged in the second phase, in which attackers used compromised accounts to expand their foothold within the organization via lateral phishing as well as beyond the network via outbound spam.<\/p>\n\n\n\n

Connecting an attacker-controlled device to the network allowed the attackers to covertly propagate the attack and move laterally throughout the targeted network. While in this case device registration was used for further phishing attacks, leveraging device registration is on the rise as other use cases have been observed. Moreover, the immediate availability of pen testing tools, designed to facilitate this technique, will only expand its usage across other actors in the future. <\/a><\/p>\n\n\n\n

MFA, which prevents attackers from being able to use stolen credentials to gain access to devices or networks, foiled the campaign for most targets. For organizations that did not have MFA enabled, however, the attack progressed.<\/p>\n\n\n\n

\"Diagram
Figure 1. Multi-phase phishing attack chain<\/em> <\/figcaption><\/figure>\n\n\n\n

Phishing continues to be the most dominant means for attacking enterprises to gain initial entry. This campaign shows that the continuous improvement of visibility and protections on managed devices has forced attackers to explore alternative avenues. The potential attack surface is further broadened by the increase in employees who work-from-home which shifts the boundaries between internal and external corporate networks. Attackers deploy various tactics to target organizational issues inherent with hybrid work, human error, and \u201cshadow IT\u201d or unmanaged apps, services, devices, and other infrastructure operating outside standard policies.<\/p>\n\n\n\n

These unmanaged devices are often ignored or missed by security teams at join time, making them lucrative targets for compromising, quietly performing lateral movements, jumping network boundaries, and achieving persistence for the sake of launching broader attacks. Even more concerning, as our researchers uncovered in this case, is when attackers manage to successfully connect a device that they fully operate and is in their complete control.<\/p>\n\n\n\n

To fend off the increasing sophistication of attacks as exemplified by this attack, organizations need solutions that deliver and correlate threat data from email, identities, cloud, and endpoints. Microsoft 365 Defender<\/a> coordinates protection across these domains, automatically finding links between signals to provide comprehensive defense. Through this cross-domain visibility, we were able to uncover this campaign. We detected the anomalous creation of inbox rules, traced it back to an initial wave of phishing campaign, and correlated data to expose the attackers\u2019 next steps, namely device registration and the subsequent phishing campaign.<\/p>\n\n\n\n

\"Screenshot
Figure 2. Microsoft 365 Defender alert “Suspicious device registration following phishing”<\/em> <\/figcaption><\/figure>\n\n\n\n

This attack shows the impact of an attacker-controlled unmanaged device that may become part of a network when credentials are stolen and Zero Trust policies are not in place. Microsoft Defender for Endpoint<\/a> provides a device discovery capability that helps organizations to find certain unmanaged devices operated by attackers whenever they start having network interactions with servers and other managed devices. Once discovered and onboarded, these devices can then be remediated and protected.<\/p>\n\n\n\n

\"Screenshot
Figure 3. Microsoft Defender for Endpoint device discovery<\/em><\/figcaption><\/figure>\n\n\n\n

In this blog post, we share the technical aspects of a large-scale, multi-phase phishing campaign. We detail how attackers used the first attack wave to compromise multiple mailboxes throughout various organizations and implement an inbox rule to evade detection. This was then followed by a second attack wave that abused one organization\u2019s lack of MFA protocols to register the attackers\u2019 unmanaged device and propagate the malicious messages via lateral, internal, and outbound spam.<\/p>\n\n\n\n

First wave and rule creation<\/h2>\n\n\n\n

The campaign leveraged multiple components and techniques to quietly compromise accounts and propagate the attack. Using Microsoft 365 Defender threat data, we found the attack\u2019s initial compromise vector to be a phishing campaign. Our analysis found that the recipients received a DocuSign-branded phishing email, displayed below:<\/p>\n\n\n\n

\"Screenshot
Figure 4. First-stage phishing email spoofing DocuSign<\/em><\/figcaption><\/figure>\n\n\n\n

The attacker used a set of phishing domains registered under .xyz top-level domain. The URL domain can be described with the following regular expression syntax:<\/p>\n\n\n\n

UrlDomain matches regex @\u201d^[a-z]{5}\\.ar[a-z]{4,5}\\.xyz”<\/em><\/p>\n\n\n\n

The phishing link was uniquely generated for each email, with the victim\u2019s email address encoded in the query parameter of the URL. After clicking the link, the victim was redirected to a phishing website at newdoc-lnpye[.]ondigitalocean[.]app, which imitated the login page for Office 365. The fake login page was pre-filled with the targeted victim\u2019s username and prompted them to enter their password. This technique increased the likelihood that the victim viewed the website as being legitimate and trustworthy.<\/p>\n\n\n\n

\"Screenshot
Figure 5. Phishing page with username prepopulated<\/em><\/figcaption><\/figure>\n\n\n\n

Next, we detected that the victim\u2019s stolen credentials were immediately used to establish a connection with Exchange Online PowerShell, most likely using an automated script as part of a phishing kit. Leveraging the Remote PowerShell connection, the attacker implemented an inbox rule via the New-InboxRule<\/em> cmdlet that deleted certain messages based on keywords in the subject or body of the email message. The inbox rule allowed the attackers to avoid arousing the compromised users\u2019 suspicions by deleting non-delivery reports and IT notification emails that might have been sent to the compromised user.<\/p>\n\n\n\n

During our investigation of the first stage of this campaign, we saw over one hundred compromised mailboxes in multiple organizations with inbox rules consistently fitting the pattern below:<\/p>\n\n\n\n

Mailbox rule name<\/strong><\/td>Condition<\/strong><\/td>Action<\/strong><\/td><\/tr>
Spam Filter<\/strong><\/td>SubjectOrBodyContainsWords: “junk;spam;phishing;hacked;password;with you”  <\/td>DeleteMessage, MarkAsRead<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

While multiple users within various organizations were compromised in the first wave, the attack did not progress past this stage for the majority of targets as they had MFA enabled. The attack\u2019s propagation heavily relied on a lack of MFA protocols. Enabling MFA for Office 365 applications or while registering new devices could have disrupted the second stage of the attack chain.<\/p>\n\n\n\n

Device registration and second wave phishing<\/h2>\n\n\n\n

One account belonging to an organization without MFA enabled was further abused to expand the attackers\u2019 foothold and propagate the campaign. More specifically, the attack abused the organization\u2019s lack of MFA enforcement to join a device to its Azure Active Directory (Azure AD<\/a>) instance, or possibly to enroll into a management provider like Intune to enforce the organization’s policies based on compliant devices.<\/p>\n\n\n\n

In this instance, the attackers first installed Outlook onto their own Windows 10 machine. This attacker-owned device was then successfully connected to the victim organization\u2019s Azure AD, possibly by simply accepting Outlook\u2019s first launch experience prompt to register the device by using the stolen credentials. An Azure AD MFA policy would have halted the attack chain at this stage. Though for the sake of comprehensiveness, it should be noted that some common red team tools, such as AADInternals<\/em><\/a> <\/em>and the command Join-AADIntDeviceToAzureAD<\/em>, can be used to achieve similar results in the presence of a stolen token and lack of strong MFA policies.<\/p>\n\n\n\n

Azure AD evaluates and triggers an activity timestamp when a device attempts to authenticate, which can be reviewed to discover freshly registered devices. In our case, this includes a Windows 10 device either Azure AD joined or hybrid Azure AD joined and active on the network. The activity timestamp can be found by either using the Get-AzureADDevice<\/em> cmdlet or the Activity column on the devices page in the Azure portal. Once a timeframe is defined and a potential rogue device is identified, the device can be deleted from Azure AD, preventing access to resources using the device to sign in.<\/p>\n\n\n\n

The creation of the inbox rule on the targeted account coupled with the attackers\u2019 newly registered device meant that they were now prepared to launch the second wave of the campaign. This second wave appeared to be aimed at compromising additional accounts by sending lateral, internal, and outbound phishing messages.<\/p>\n\n\n\n

By using a device now recognized as part of the domain coupled with a mail client configured exactly like any regular user, the attacker gained the ability to send intra-organizational emails that were missing many of the typical suspect identifiers. By removing enough of these suspicious message elements, the attacker thereby significantly expanded the success of the phishing campaign.<\/p>\n\n\n\n

To launch the second wave, the attackers leveraged the targeted user\u2019s compromised mailbox to send malicious messages to over 8,500 users, both in and outside of the victim organization. The emails used a SharePoint sharing invitation lure as the message body in an attempt to convince recipients that the \u201cPayment.pdf\u201d file being shared was legitimate.<\/p>\n\n\n\n

\"Screenshot
Figure 6. Second-stage phishing email spoofing SharePoint<\/em><\/figcaption><\/figure>\n\n\n\n

Like the first stage of the campaign, we found that the URL used in the second wave phishing emails matched the first\u2019s wave structure and also redirected to the newdoc-lnpye[.]ondigitalocean[.]app phishing website imitating the Office 365 login page. Victims that entered their credentials on the second stage phishing site were similarly connected with Exchange Online PowerShell, and almost immediately had a rule created to delete emails in their respective inboxes. The rule had identical characteristics to the one created during the campaign\u2019s first stage of attack.<\/p>\n\n\n\n

Generally, the vast majority of organizations enabled MFA and were protected from the attackers\u2019 abilities to propagate the attack and expand their network foothold. Nonetheless, those that do not have MFA enabled could open themselves up to being victimized in potential future attack waves. <\/p>\n\n\n\n

Remediating device persistence: when resetting your password is not enough<\/h2>\n\n\n\n

Analysis of this novel attack chain and the additional techniques used in this campaign indicates that the traditional phishing remediation playbook will not be sufficient here. Simply resetting compromised accounts\u2019 passwords may ensure that the user is no longer compromised, but it will not be enough to eliminate ulterior persistence mechanisms in place.<\/p>\n\n\n\n

Careful defenders operating in hybrid networks need to also consider the following steps:<\/p>\n\n\n\n