Archive for the ‘MFA’ Category

Evolved phishing: Device registration trick adds to phishers’ toolbox for victims without MFA

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’s 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.

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.

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.

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.

Diagram showing the multi-phase phishing attack chain
Figure 1. Multi-phase phishing attack chain

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 “shadow IT” or unmanaged apps, services, devices, and other infrastructure operating outside standard policies.

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.

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 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’ next steps, namely device registration and the subsequent phishing campaign.

Screenshot of Microsoft 365 Defender alert for Suspicious device registration following phishing
Figure 2. Microsoft 365 Defender alert “Suspicious device registration following phishing”

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 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.

Screenshot of Microsoft Defender for Endpoint device discovery page
Figure 3. Microsoft Defender for Endpoint device discovery

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’s lack of MFA protocols to register the attackers’ unmanaged device and propagate the malicious messages via lateral, internal, and outbound spam.

First wave and rule creation

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’s initial compromise vector to be a phishing campaign. Our analysis found that the recipients received a DocuSign-branded phishing email, displayed below:

Screenshot of a sample email used in the first stage of the attack
Figure 4. First-stage phishing email spoofing DocuSign

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:

UrlDomain matches regex @”^[a-z]{5}\.ar[a-z]{4,5}\.xyz”

The phishing link was uniquely generated for each email, with the victim’s 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’s username and prompted them to enter their password. This technique increased the likelihood that the victim viewed the website as being legitimate and trustworthy.

Screenshot of the phishing page showing the username prepopulated
Figure 5. Phishing page with username prepopulated

Next, we detected that the victim’s 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 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’ suspicions by deleting non-delivery reports and IT notification emails that might have been sent to the compromised user.

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:

Mailbox rule name Condition Action
Spam Filter SubjectOrBodyContainsWords: “junk;spam;phishing;hacked;password;with you”   DeleteMessage, MarkAsRead

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’s 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.

Device registration and second wave phishing

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

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’s Azure AD, possibly by simply accepting Outlook’s 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 and the command Join-AADIntDeviceToAzureAD, can be used to achieve similar results in the presence of a stolen token and lack of strong MFA policies.

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 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.

The creation of the inbox rule on the targeted account coupled with the attackers’ 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.

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.

To launch the second wave, the attackers leveraged the targeted user’s 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 “Payment.pdf” file being shared was legitimate.

Screenshot of a sample email used in the second stage of the phishing campaign
Figure 6. Second-stage phishing email spoofing SharePoint

Like the first stage of the campaign, we found that the URL used in the second wave phishing emails matched the first’s 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’s first stage of attack.

Generally, the vast majority of organizations enabled MFA and were protected from the attackers’ 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. 

Remediating device persistence: when resetting your password is not enough

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’ passwords may ensure that the user is no longer compromised, but it will not be enough to eliminate ulterior persistence mechanisms in place.

Careful defenders operating in hybrid networks need to also consider the following steps:

If these additional remediation steps are not taken, the attacker could still have valuable network access even after successfully resetting the password of the compromised account. An in-depth understanding of this attack is necessary to properly mitigate and defend against this new type of threat.

Defending against multi-staged phishing campaigns

The latest Microsoft Digital Defense Report detailed that phishing poses a major threat to both enterprises and individuals, while credential phishing was leveraged in many of the most damaging attacks in the last year. Attackers targeting employee credentials, particularly employees with high privileges, typically use the stolen data to sign into other devices and move laterally inside the network. The phishing campaign we discussed in this blog exemplifies the increasing sophistication of these attacks.

In order to disrupt attackers before they reach their target, good credential hygiene, network segmentation, and similar best practices increase the “cost” to attackers trying to propagate through the network. These best practices can limit an attacker’s ability to move laterally and compromise assets after initial intrusion and should be complemented with advanced security solutions that provide visibility across domains and coordinate threat data across protection components.

Organizations 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. Microsoft 365 global admins can also disable Exchange Online PowerShell for individual or multiple end users via a list of specific users or filterable attributes, assuming that the target accounts all share a unique filterable attribute such as Title or Department. For additional security, customers can enforce our new Conditional Access (CA) control requiring MFA to register devices, which can be combined with other CA conditions like device platform or trusted networks.

Microsoft 365 Defender correlates the alerts and signals related to initial phishing generated by suspicious inbox rule creation as well as suspicious device registration into a single easy to comprehend Incident.

Screenshot of Microsoft 365 Defender incident view showing suspicious device registration and inbox rule
Figure 7. Microsoft 365 Defender incident with suspicious device registration and inbox rule

Microsoft Defender for Office 365 protects against email threats using its multi-layered email filtering stack, which includes edge protection, sender intelligence, content filtering, and post-delivery protection, in addition to including outbound spam filter policies to configure and control automatic email forwarding to external recipients. Moreover, Microsoft Defender for Office 365 uses Safe Links feature to proactively protect users from malicious URLs in internal messages or in an Office document at time of click. Safe Links feature to proactively protect users from malicious URLs in internal messages or in an Office document at time of click.

Advanced hunting queries

Hunting for emails with phishing URL

let startTime = ago(7d);
let endTime = now();
| where Timestamp between (startTime..endTime)
| where UrlDomain matches regex @"^[a-z]{5}\.ar[a-z]{4,5}\.xyz"
| project NetworkMessageId,Url
| join (EmailEvents 
| where Timestamp between (startTime..endTime))
on NetworkMessageId

Hunting for suspicious Inbox Ruleslet startTime = ago(7d);

// Hunting for suspicious Inbox Rules
let startTime = ago(7d);
let endTime = now();
| where Timestamp between(startTime .. endTime)
| where ActionType == "New-InboxRule"
| where RawEventData contains "Spam Filter"
| where RawEventData has_any("junk","spam","phishing","hacked","password","with you") 
| where RawEventData contains "DeleteMessage" 
| project Timestamp, AccountDisplayName, AccountObjectId, IPAddress

Hunting for rogue device registrations

// Hunting for rogue device registrations
let startTime = ago(7d);
let endTime = now();
| where Timestamp between(startTime .. endTime)
| where ActionType == "Add registered owner to device." 
| where RawEventData contains "notorius"
| where AccountDisplayName == "Device Registration Service"
| where isnotempty(RawEventData.ObjectId) and isnotempty(RawEventData.ModifiedProperties[0].NewValue) and isnotempty(RawEventData.Target[1].ID) and isnotempty(RawEventData.ModifiedProperties[1].NewValue)
| extend AccountUpn = tostring(RawEventData.ObjectId)
| extend AccountObjectId = tostring(RawEventData.Target[1].ID)
| extend DeviceObjectId = tostring(RawEventData.ModifiedProperties[0].NewValue)
| extend DeviceDisplayName = tostring(RawEventData.ModifiedProperties[1].NewValue)
| project Timestamp,ReportId,AccountUpn,AccountObjectId,DeviceObjectId,DeviceDisplayName

The post Evolved phishing: Device registration trick adds to phishers’ toolbox for victims without MFA appeared first on Microsoft Security Blog.

Protect your business from email phishing with multi-factor authentication

April 5th, 2021 No comments

Cybersecurity has been in the news far more often in the past 12 months than in previous years, as cybercriminals escalated their activity during the COVID-19 pandemic quarantine. The seismic shift of hundreds of millions of people connecting and working from home every day presented cybercriminals with greater opportunities to attack and new threat vectors to exploit, as was detailed in the Microsoft 2020 Digital Defense Report.

Cybercrime is a large and flourishing enterprise, unfortunately. Like in any business, innovation fuels success and profit.

Business email compromise is on the rise

Even the oldest tricks of cybercriminals are constantly evolving in techniques to bring more revenue from nefarious customers. Email phishing—when individuals or organizations receive a fraudulent email encouraging them to click on a link, giving the cybercriminal access to a device or personal information—has become a dominant vector to attack enterprise digital estates. Known as business email compromise (BEC), cybercriminals have responded to technical advancements in detection by developing fast-moving phishing scams that can victimize even the savviest professionals.

BEC criminals know that email is today’s de facto method of communication. People have been encouraged to “go paperless” by companies, and most feel confident they can spot a spam email. But they also inherently trust those they work with and are more likely to respond to requests from their company’s executives, as well as their trusted suppliers and business partners. A real but compromised account anywhere in the communication stream can lead to disastrous results.

Cybercriminals bank, quite literally, on these human, socially reinforced patterns. And it’s not surprising that cybercriminals succeed with schemes that appear, at least in retrospect, unbelievably primitive and transparent. In fact, one quite well-known BEC scam that used keylogger malware to fine-tune email access—and operated without detection for six months in 2015—redirected invoice payments totaling $75 million to cybercriminal bank accounts. In hindsight, one might expect that someone would notice, given the vast amount of money involved. But no one did.

As severe as the consequences of BEC can be, they are unfortunately also quite frequent. Since 2009, 17 percent of the cyber incidents reported to Chubb have stemmed from social engineering. And the risk is only increasing—the scale and threat of email phishing attacks are growing.

Take action: Reduce email phishing attacks with MFA

Enabling multi-factor authentication (MFA) can be one of the quickest and most impactful ways to protect user identities, and an effective means to reduce the threat and potential impact of BEC. MFA has been available for all Microsoft Office 365 users since 2014, yet many small- to mid-sized business system administrators have not enabled it for their users.

In a joint white paper co-written by Microsoft and Chubb, the world’s largest publicly traded insurance provider, we explain how multi-factor authentication foils fraud, and how implementing MFA may be much easier and painless for your users than you may think. It’s a simple yet effective means to reduce the threat and potential impact of BEC.

The paper is available for download on Chubb’s website.

Embrace Zero Trust to protect your complex digital estate

Beyond the benefits of multi-factor authentication, the move toward Zero Trust security can enable and secure your remote workforce, increase the speed of threat detection and remediation, mitigate the impact of potential breaches, and make it harder for cybercriminals to make money.

The business of cybercrime will continue to grow. However, by increasing the complexity and cost of perpetrating that crime, businesses can disincentivize the criminals to the point where they move on toward easier targets.

Learn more

To learn more about email phishing and how to protect your organization, read these blogs:

To learn more about Microsoft Security solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Protect your business from email phishing with multi-factor authentication appeared first on Microsoft Security.

How to implement Multi-Factor Authentication (MFA)

January 15th, 2020 No comments

Another day, another data breach. If the regular drumbeat of leaked and phished accounts hasn’t persuaded you to switch to Multi-Factor Authentication (MFA) already, maybe the usual January rush of ‘back to work’ password reset requests is making you reconsider. When such an effective option for protecting accounts is available, why wouldn’t you deploy it straight away?

The problem is that deploying MFA at scale is not always straightforward. There are technical issues that may hold you up, but the people side is where you have to start. The eventual goal of an MFA implementation is to enable it for all your users on all of your systems all of the time, but you won’t be able to do that on day one.

To successfully roll out MFA, start by being clear about what you’re going to protect, decide what MFA technology you’re going to use, and understand what the impact on employees is going to be. Otherwise, your MFA deployment might grind to a halt amid complaints from users who run into problems while trying to get their job done.

Before you start on the technical side, remember that delivering MFA across a business is a job for the entire organization, from the security team to business stakeholders to IT departments to HR and to corporate communications and beyond, because it has to support all the business applications, systems, networks and processes without affecting workflow.

Campaign and train

Treat the transition to MFA like a marketing campaign where you need to sell employees on the idea—as well as provide training opportunities along the way. It’s important for staff to understand that MFA is there to support them and protect their accounts and all the their data, because that may not be their first thought when met with changes to the way they sign in to the tools they use every day. If you run an effective internal communications campaign that makes it clear to users what they need to do and, more importantly, why they need to do it, you’ll avoid them seeing MFA as a nuisance or misunderstanding it as ‘big brother’ company tracking.

The key is focusing on awareness: in addition to sending emails—put up posters in the elevator, hang banner ads in your buildings, all explaining why you’re making the transition to MFA. Focus on informing your users, explaining why you’re making this change—making it very clear what they will need to do and where they can find instructions, documentation, and support.

Also, provide FAQs and training videos, along with optional training sessions or opportunities to opt in to an early pilot group (especially if you can offer them early access to a new software version that will give them features they need). Recognize that MFA is more work for them than just using a password, and that they will very likely be inconvenienced. Unless you are able to use biometrics on every device they will have to get used to carrying a security key or a device with an authenticator app with them all the time, so you need them to understand why MFA is so important.

It’s not surprising that users can be concerned about a move to MFA. After all, MFA has sometimes been done badly in the consumer space. They’ll have seen stories about social networks abusing phone numbers entered for security purposes for marketing or of users locked out of their accounts if they’re travelling and unable to get a text message. You’ll need to reassure users who have had bad experiences with consumer MFA and be open to feedback from employees about the impact of MFA policies. Like all tech rollouts, this is a process.

If you’re part of an international business you have more to do, as you need to account for global operations. That needs wider buy-in and a bigger budget, including language support if you must translate training and support documentation. If you don’t know where to start, Microsoft provides communication templates and user documentation you can customize for your organization.

Start with admin accounts

At a minimum, you want to use MFA for all your admins, so start with privileged users. Administrative accounts are your highest value targets and the most urgent to secure, but you can also treat them as a proof of concept for wider adoption. Review who these users are and what privileges they have—there are probably more accounts than you expect with far more privileges than are really needed.

At the same time, look at key business roles where losing access to email—or having unauthorized emails sent—will have a major security impact. Your CEO, CFO, and other senior leaders need to move to MFA to protect business communications.

Use what you’ve learned to roll out MFA to high value groups to plan a pilot deployment—which includes employees from across the business who require different levels of security access—so your final MFA deployment is optimized for mainstream employees without hampering the productivity of those working with more sensitive information, whether that’s the finance team handling payroll or developers with commit rights. Consider how you will cover contractors and partners who need access as well.

Plan for wider deployment

Start by looking at what systems you have that users need to sign in to that you can secure with MFA. Remember that includes on-premises systems—you can incorporate MFA into your existing remote access options, using Active Directory Federation Services (AD FS), or Network Policy Server and use Azure Active Directory (Azure AD) Application Proxy to publish applications for cloud access.

Concentrate on finding any networks or systems where deploying MFA will take more work (for example, if SAML authentication is used) and especially on discovering vulnerable apps that don’t support anything except passwords because they use legacy or basic authentication. This includes older email systems using MAPI, EWS, IMAP4, POP3, SMTP, internal line of business applications, and elderly client applications. Upgrade or update these to support modern authentication and MFA where you can. Where this isn’t possible, you’ll need to restrict them to use on the corporate network until you can replace them, because critical systems that use legacy authentication will block your MFA deployment.

Be prepared to choose which applications to prioritize. As well as an inventory of applications and networks (including remote access options), look at processes like employee onboarding and approval of new applications. Test how applications work with MFA, even when you expect the impact to be minimal. Create a new user without admin access, use that account to sign in with MFA and go through the process of configuring and using the standard set of applications staff will use to see if there are issues. Look at how users will register for MFA and choose which methods and factors to use, and how you will track and audit registrations. You may be able to combine MFA registration with self-service password reset (SSPR) in a ‘one stop shop,’ but it’s important to get users to register quickly so that attackers can’t take over their account by registering for MFA, especially if it’s for a high-value application they don’t use frequently. For new employees, you should make MFA registration part of the onboarding process.

Make MFA easier on employees

MFA is always going to be an extra step, but you can choose MFA options with less friction, like using biometrics in devices or FIDO2 compliant factors such as Feitan or Yubico security keys. Avoid using SMS if possible. Phone-based authentication apps like the Microsoft Authenticator App are an option, and they don’t require a user to hand over control of their personal device. But if you have employees who travel to locations where they may not have connectivity, choose OATH verification codes, which are automatically generated rather than push notifications that are usually convenient but require the user to be online. You can even use automated voice calls: letting users press a button on the phone keypad is less intrusive than giving them a passcode to type in on screen.

Offer a choice of alternative factors so people can pick the one that best suits them. Biometrics are extremely convenient, but some employees may be uncomfortable using their fingerprint or face for corporate sign-ins and may prefer receiving an automated voice call.

Make sure that you include mobile devices in your MFA solution, managing them through Mobile Device Management (MDM), so you can use conditional and contextual factors for additional security.

Avoid making MFA onerous; choose when the extra authentication is needed to protect sensitive data and critical systems rather than applying it to every single interaction. Consider using conditional access policies and Azure AD Identity Protection, which allows for triggering two-step verification based on risk detections, as well as pass-through authentication and single-sign-on (SSO).

If MFA means that a user accessing a non-critical file share or calendar on the corporate network from a known device that has all the current OS and antimalware updates sees fewer challenges—and no longer faces the burden of 90-day password resets—then you can actually improve the user experience with MFA.

Have a support plan

Spend some time planning how you will handle failed sign-ins and account lockouts. Even with training, some failed sign-ins will be legitimate users getting it wrong and you need to make it easy for them to get help.

Similarly, have a plan for lost devices. If a security key is lost, the process for reporting that needs to be easy and blame free, so that employees will notify you immediately so you can expire their sessions and block the security key, and audit the behavior of their account (going back to before they notified you of the loss). Security keys that use biometrics may be a little more expensive, but if they’re lost or stolen, an attacker can’t use them. If possible, make it a simple, automated workflow, using your service desk tools.

You also need to quickly get them connected another way so they can get back to work. Automatically enrolling employees with a second factor can help. Make that second factor convenient enough to use that they’re not unable to do their job, but not so convenient that they keep using it and don’t report the loss: one easy option is allowing one-time bypasses. Similarly, make sure you’re set up to automatically deprovision entitlements and factors when employees change roles or leave the organization.

Measure and monitor

As you deploy MFA, monitor the rollout to see what impact it has on both security and productivity and be prepared to make changes to policies or invest in better hardware to make it successful. Track security metrics for failed login attempts, credential phishing that gets blocked and privilege escalations that are denied.

Your MFA marketing campaign also needs to continue during and after deployment, actively reaching out to staff and asking them to take back in polls or feedback sessions. Start that with the pilot group and continue it once everyone is using MFA.

Even when you ask for it, don’t rely on user feedback to tell you about problems. Check helpdesk tickets, logs, and audit options to see if it’s taking users longer to get into systems, or if they’re postponing key tasks because they’re finding MFA difficult, or if security devices are failing or breaking more than expected. New applications and new teams in the business will also mean that MFA deployment needs to be ongoing, and you’ll need to test software updates to see if they break MFA; you have to make it part of the regular IT process.

Continue to educate users about the importance of MFA, including running phishing training and phishing your own employees (with more training for those who are tricked into clicking through to fake links).

MFA isn’t a switch you flip; it’s part of a move to continuous security and assessment that will take time and commitment to implement. But if you approach it in the right way, it’s also the single most effective step you can take to improve security.

About the authors

Ann Johnson is the Corporate Vice President for Cybersecurity Solutions Group for Microsoft. She is a member of the board of advisors for FS-ISAC (The Financial Services Information Sharing and Analysis Center), an advisory board member for EWF (Executive Women’s Forum on Information Security, Risk Management & Privacy), and an advisory board member for HYPR Corp. Ann recently joined the board of advisors for Cybersecurity Ventures

Christina Morillo is a Senior Program Manager on the Azure Identity Engineering Product team at Microsoft. She is an information security and technology professional with a background in cloud technologies, enterprise security, and identity and access. Christina advocates and is passionate about making technology less scary and more approachable for the masses. When she is not at work, or spending time with her family, you can find her co-leading Women in Security and Privacy’s NYC chapter and supporting others as an advisor and mentor. She lives in New York City with her husband and children.

Learn more

To find out more about Microsoft’s Cybersecurity Solutions, visit the Microsoft Security site, or follow Microsoft Security on Twitter at Microsoft Security Twitter or Microsoft WDSecurity Twitter.

To learn more about Microsoft Azure Identity Management solutions, visit this Microsoft overview page and follow our Identity blog. You can also follow us @AzureAD on Twitter.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post How to implement Multi-Factor Authentication (MFA) appeared first on Microsoft Security.