{
	"id": "8c1dc455-310a-47f2-9f48-8a69f3ba3a3c",
	"created_at": "2026-04-06T00:12:31.824209Z",
	"updated_at": "2026-04-10T03:19:59.02425Z",
	"deleted_at": null,
	"sha1_hash": "b0250e10fd21cdd5d16a61416a948fef701a5032",
	"title": "Evolved phishing: Device registration trick adds to phishers’ toolbox for victims without MFA | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 702908,
	"plain_text": "Evolved phishing: Device registration trick adds to phishers’\r\ntoolbox for victims without MFA | Microsoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2022-01-26 · Archived: 2026-04-05 16:43:25 UTC\r\nWe have recently uncovered a large-scale, multi-phase campaign that adds a novel technique to traditional\r\nphishing tactics by joining an attacker-operated device to an organization’s network to further propagate the\r\ncampaign. We observed that the second stage of the campaign was successful against victims that did not\r\nimplement multifactor authentication (MFA), an essential pillar of identity security. Without additional protective\r\nmeasures such as MFA, the attack takes advantage of the concept of bring-your-own-device (BYOD) via the\r\nability to register a device using freshly stolen credentials.\r\nThe first campaign phase involved stealing credentials in target organizations located predominantly in Australia,\r\nSingapore, Indonesia, and Thailand. Stolen credentials were then leveraged in the second phase, in which\r\nattackers used compromised accounts to expand their foothold within the organization via lateral phishing as well\r\nas beyond the network via outbound spam.\r\nConnecting an attacker-controlled device to the network allowed the attackers to covertly propagate the attack and\r\nmove laterally throughout the targeted network. While in this case device registration was used for further\r\nphishing attacks, leveraging device registration is on the rise as other use cases have been observed. Moreover, the\r\nimmediate availability of pen testing tools, designed to facilitate this technique, will only expand its usage across\r\nother actors in the future.\r\nMFA, which prevents attackers from being able to use stolen credentials to gain access to devices or networks,\r\nfoiled the campaign for most targets. For organizations that did not have MFA enabled, however, the attack\r\nprogressed.\r\nFigure 1. Multi-phase phishing attack chain\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 1 of 10\n\nPhishing continues to be the most dominant means for attacking enterprises to gain initial entry. This campaign\r\nshows that the continuous improvement of visibility and protections on managed devices has forced attackers to\r\nexplore alternative avenues. The potential attack surface is further broadened by the increase in employees who\r\nwork-from-home which shifts the boundaries between internal and external corporate networks. Attackers deploy\r\nvarious tactics to target organizational issues inherent with hybrid work, human error, and “shadow IT” or\r\nunmanaged apps, services, devices, and other infrastructure operating outside standard policies.\r\nThese unmanaged devices are often ignored or missed by security teams at join time, making them lucrative\r\ntargets for compromising, quietly performing lateral movements, jumping network boundaries, and achieving\r\npersistence for the sake of launching broader attacks. Even more concerning, as our researchers uncovered in this\r\ncase, is when attackers manage to successfully connect a device that they fully operate and is in their complete\r\ncontrol.\r\nTo fend off the increasing sophistication of attacks as exemplified by this attack, organizations need solutions that\r\ndeliver and correlate threat data from email, identities, cloud, and endpoints. Microsoft 365 Defender coordinates\r\nprotection across these domains, automatically finding links between signals to provide comprehensive defense.\r\nThrough this cross-domain visibility, we were able to uncover this campaign. We detected the anomalous creation\r\nof inbox rules, traced it back to an initial wave of phishing campaign, and correlated data to expose the attackers’\r\nnext steps, namely device registration and the subsequent phishing campaign.\r\nFigure 2. Microsoft 365 Defender alert “Suspicious device registration following phishing”\r\nThis attack shows the impact of an attacker-controlled unmanaged device that may become part of a network\r\nwhen credentials are stolen and Zero Trust policies are not in place. Microsoft Defender for Endpoint provides a\r\ndevice discovery capability that helps organizations to find certain unmanaged devices operated by attackers\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 2 of 10\n\nwhenever they start having network interactions with servers and other managed devices. Once discovered and\r\nonboarded, these devices can then be remediated and protected.\r\nFigure 3. Microsoft Defender for Endpoint device discovery\r\nIn this blog post, we share the technical aspects of a large-scale, multi-phase phishing campaign. We detail how\r\nattackers used the first attack wave to compromise multiple mailboxes throughout various organizations and\r\nimplement an inbox rule to evade detection. This was then followed by a second attack wave that abused one\r\norganization’s lack of MFA protocols to register the attackers’ unmanaged device and propagate the malicious\r\nmessages via lateral, internal, and outbound spam.\r\nFirst wave and rule creation\r\nThe campaign leveraged multiple components and techniques to quietly compromise accounts and propagate the\r\nattack. Using Microsoft 365 Defender threat data, we found the attack’s initial compromise vector to be a phishing\r\ncampaign. Our analysis found that the recipients received a DocuSign-branded phishing email, displayed below:\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 3 of 10\n\nFigure 4. First-stage phishing email spoofing DocuSign\r\nThe attacker used a set of phishing domains registered under .xyz top-level domain. The URL domain can be\r\ndescribed with the following regular expression syntax:\r\nUrlDomain matches regex @”^[a-z]{5}\\.ar[a-z]{4,5}\\.xyz”\r\nThe phishing link was uniquely generated for each email, with the victim’s email address encoded in the query\r\nparameter 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\r\nwith the targeted victim’s username and prompted them to enter their password. This technique increased the\r\nlikelihood that the victim viewed the website as being legitimate and trustworthy.\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 4 of 10\n\nFigure 5. Phishing page with username prepopulated\r\nNext, we detected that the victim’s stolen credentials were immediately used to establish a connection with\r\nExchange Online PowerShell, most likely using an automated script as part of a phishing kit. Leveraging the\r\nRemote PowerShell connection, the attacker implemented an inbox rule via the New-InboxRule cmdlet that\r\ndeleted certain messages based on keywords in the subject or body of the email message. The inbox rule allowed\r\nthe attackers to avoid arousing the compromised users’ suspicions by deleting non-delivery reports and IT\r\nnotification emails that might have been sent to the compromised user.\r\nDuring our investigation of the first stage of this campaign, we saw over one hundred compromised mailboxes in\r\nmultiple organizations with inbox rules consistently fitting the pattern below:\r\nMailbox\r\nrule name\r\nCondition Action\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 5 of 10\n\nSpam\r\nFilter\r\nSubjectOrBodyContainsWords:\r\n“junk;spam;phishing;hacked;password;with you”  \r\nDeleteMessage,\r\nMarkAsRead\r\nWhile multiple users within various organizations were compromised in the first wave, the attack did not progress\r\npast this stage for the majority of targets as they had MFA enabled. The attack’s propagation heavily relied on a\r\nlack of MFA protocols. Enabling MFA for Office 365 applications or while registering new devices could have\r\ndisrupted the second stage of the attack chain.\r\nDevice registration and second wave phishing\r\nOne account belonging to an organization without MFA enabled was further abused to expand the attackers’\r\nfoothold and propagate the campaign. More specifically, the attack abused the organization’s lack of MFA\r\nenforcement to join a device to its Azure Active Directory (Azure AD) instance, or possibly to enroll into a\r\nmanagement provider like Intune to enforce the organization’s policies based on compliant devices.\r\nIn this instance, the attackers first installed Outlook onto their own Windows 10 machine. This attacker-owned\r\ndevice was then successfully connected to the victim organization’s Azure AD, possibly by simply accepting\r\nOutlook’s first launch experience prompt to register the device by using the stolen credentials. An Azure AD MFA\r\npolicy would have halted the attack chain at this stage. Though for the sake of comprehensiveness, it should be\r\nnoted that some common red team tools, such as AADInternals and the command Join-AADIntDeviceToAzureAD,\r\ncan be used to achieve similar results in the presence of a stolen token and lack of strong MFA policies.\r\nAzure AD evaluates and triggers an activity timestamp when a device attempts to authenticate, which can be\r\nreviewed to discover freshly registered devices. In our case, this includes a Windows 10 device either Azure AD\r\njoined or hybrid Azure AD joined and active on the network. The activity timestamp can be found by either using\r\nthe Get-AzureADDevice cmdlet or the Activity column on the devices page in the Azure portal. Once a timeframe\r\nis defined and a potential rogue device is identified, the device can be deleted from Azure AD, preventing access\r\nto resources using the device to sign in.\r\nThe creation of the inbox rule on the targeted account coupled with the attackers’ newly registered device meant\r\nthat they were now prepared to launch the second wave of the campaign. This second wave appeared to be aimed\r\nat compromising additional accounts by sending lateral, internal, and outbound phishing messages.\r\nBy using a device now recognized as part of the domain coupled with a mail client configured exactly like any\r\nregular user, the attacker gained the ability to send intra-organizational emails that were missing many of the\r\ntypical suspect identifiers. By removing enough of these suspicious message elements, the attacker thereby\r\nsignificantly expanded the success of the phishing campaign.\r\nTo launch the second wave, the attackers leveraged the targeted user’s compromised mailbox to send malicious\r\nmessages to over 8,500 users, both in and outside of the victim organization. The emails used a SharePoint sharing\r\ninvitation lure as the message body in an attempt to convince recipients that the “Payment.pdf” file being shared\r\nwas legitimate.\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 6 of 10\n\nFigure 6. Second-stage phishing email spoofing SharePoint\r\nLike the first stage of the campaign, we found that the URL used in the second wave phishing emails matched the\r\nfirst’s wave structure and also redirected to the newdoc-lnpye[.]ondigitalocean[.]app phishing website imitating\r\nthe Office 365 login page. Victims that entered their credentials on the second stage phishing site were similarly\r\nconnected with Exchange Online PowerShell, and almost immediately had a rule created to delete emails in their\r\nrespective inboxes. The rule had identical characteristics to the one created during the campaign’s first stage of\r\nattack.\r\nGenerally, the vast majority of organizations enabled MFA and were protected from the attackers’ abilities to\r\npropagate the attack and expand their network foothold. Nonetheless, those that do not have MFA enabled could\r\nopen themselves up to being victimized in potential future attack waves. \r\nAnalysis of this novel attack chain and the additional techniques used in this campaign indicates that the\r\ntraditional phishing remediation playbook will not be sufficient here. Simply resetting compromised accounts’\r\npasswords may ensure that the user is no longer compromised, but it will not be enough to eliminate ulterior\r\npersistence mechanisms in place.\r\nCareful defenders operating in hybrid networks need to also consider the following steps:\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 7 of 10\n\nRevocation of active sessions and any token associated with the compromised accounts\r\nDeletion of any mailbox rules eventually created by the actor\r\nDisable and removal of any rogue device joined to Azure AD by the actor\r\nIf these additional remediation steps are not taken, the attacker could still have valuable network access even after\r\nsuccessfully resetting the password of the compromised account. An in-depth understanding of this attack is\r\nnecessary to properly mitigate and defend against this new type of threat.\r\nDefending against multi-staged phishing campaigns\r\nThe latest Microsoft Digital Defense Report detailed that phishing poses a major threat to both enterprises and\r\nindividuals, while credential phishing was leveraged in many of the most damaging attacks in the last year.\r\nAttackers targeting employee credentials, particularly employees with high privileges, typically use the stolen data\r\nto sign into other devices and move laterally inside the network. The phishing campaign we discussed in this blog\r\nexemplifies the increasing sophistication of these attacks.\r\nIn order to disrupt attackers before they reach their target, good credential hygiene, network segmentation, and\r\nsimilar best practices increase the “cost” to attackers trying to propagate through the network. These best practices\r\ncan limit an attacker’s ability to move laterally and compromise assets after initial intrusion and should be\r\ncomplemented with advanced security solutions that provide visibility across domains and coordinate threat data\r\nacross protection components.\r\nOrganizations can further reduce their attack surface by disabling the use of basic authentication, enabling multi-factor authentication for all users, and requiring multi-factor authentication when joining devices to Azure AD.\r\nMicrosoft 365 global admins can also disable Exchange Online PowerShell for individual or multiple end users\r\nvia a list of specific users or filterable attributes, assuming that the target accounts all share a unique filterable\r\nattribute such as Title or Department. For additional security, customers can enforce our new Conditional Access\r\ncontrol requiring MFA to register devices, which can be combined with other CA conditions like device platform\r\nor trusted networks.\r\nMicrosoft 365 Defender correlates the alerts and signals related to initial phishing generated by suspicious inbox\r\nrule creation as well as suspicious device registration into a single easy to comprehend Incident.\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 8 of 10\n\nFigure 7. Microsoft 365 Defender incident with suspicious device registration and inbox rule\r\nMicrosoft Defender for Office 365 protects against email threats using its multi-layered email filtering stack,\r\nwhich includes edge protection, sender intelligence, content filtering, and post-delivery protection, in addition to\r\nincluding outbound spam filter policies to configure and control automatic email forwarding to external recipients.\r\nMoreover, Microsoft Defender for Office 365 uses Safe Links feature to proactively protect users from malicious\r\nURLs in internal messages or in an Office document at time of click. Safe Links feature to proactively protect\r\nusers from malicious URLs in internal messages or in an Office document at time of click.\r\nAdvanced hunting queries\r\nHunting for emails with phishing URL\r\nlet startTime = ago(7d);\r\nlet endTime = now();\r\nEmailUrlInfo\r\n| where Timestamp between (startTime..endTime)\r\n| where UrlDomain matches regex @\"^[a-z]{5}\\.ar[a-z]{4,5}\\.xyz\"\r\n| project NetworkMessageId,Url\r\n| join (EmailEvents\r\n| where Timestamp between (startTime..endTime))\r\non NetworkMessageId\r\nHunting for suspicious Inbox Ruleslet startTime = ago(7d);\r\n// Hunting for suspicious Inbox Rules\r\nlet startTime = ago(7d);\r\nlet endTime = now();\r\nCloudAppEvents\r\n| where Timestamp between(startTime .. endTime)\r\n| where ActionType == \"New-InboxRule\"\r\n| where RawEventData contains \"Spam Filter\"\r\n| where RawEventData has_any(\"junk\",\"spam\",\"phishing\",\"hacked\",\"password\",\"with you\")\r\n| where RawEventData contains \"DeleteMessage\"\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 9 of 10\n\n| project Timestamp, AccountDisplayName, AccountObjectId, IPAddress\r\nHunting for rogue device registrations\r\n// Hunting for rogue device registrations\r\nlet startTime = ago(7d);\r\nlet endTime = now();\r\nCloudAppEvents\r\n| where Timestamp between(startTime .. endTime)\r\n| where ActionType == \"Add registered owner to device.\"\r\n| where RawEventData contains \"notorius\"\r\n| where AccountDisplayName == \"Device Registration Service\"\r\n| where isnotempty(RawEventData.ObjectId) and isnotempty(RawEventData.ModifiedProperties[0].NewValue)\r\nand isnotempty(RawEventData.Target[1].ID) and isnotempty(RawEventData.ModifiedProperties[1].NewValue)\r\n| extend AccountUpn = tostring(RawEventData.ObjectId)\r\n| extend AccountObjectId = tostring(RawEventData.Target[1].ID)\r\n| extend DeviceObjectId = tostring(RawEventData.ModifiedProperties[0].NewValue)\r\n| extend DeviceDisplayName = tostring(RawEventData.ModifiedProperties[1].NewValue)\r\n| project Timestamp,ReportId,AccountUpn,AccountObjectId,DeviceObjectId,DeviceDisplayName\r\nSource: https://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nhttps://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.microsoft.com/security/blog/2022/01/26/evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa"
	],
	"report_names": [
		"evolved-phishing-device-registration-trick-adds-to-phishers-toolbox-for-victims-without-mfa"
	],
	"threat_actors": [],
	"ts_created_at": 1775434351,
	"ts_updated_at": 1775791199,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b0250e10fd21cdd5d16a61416a948fef701a5032.pdf",
		"text": "https://archive.orkl.eu/b0250e10fd21cdd5d16a61416a948fef701a5032.txt",
		"img": "https://archive.orkl.eu/b0250e10fd21cdd5d16a61416a948fef701a5032.jpg"
	}
}