Category Archives: Security

Office 365’s MFA is vulnerable to EvilGinx2

According to the latest Microsoft Security Intelligence Report, spear phishing remains the preferred attack method used by hackers. Microsoft detected a 250% increase in phishing messages between January and December 2018.

Figure 1 Page 21 of the Microsoft Security Intelligence Report Volume 24

Many organizations have deployed 2FA as a layer of defense to guard against phishing, so that if the user gives away the username and password, the attacker shouldn’t be able to logon to the user account. The purpose of this blog post is to raise awareness that Office 365 in particular is now vulnerable to “network session hijacking proxy theft” which allows an attacker to sign in regardless of the MFA solution (MSFT, Duo, RSA, SMS, etc). The authentication token is captured after the victim is tricked to going to a credential stealing website where they perform MFA through a proxy server. The token is then re-played by the attacker who can sign in as the user.

To see a demonstration of this, watch this Youtube video, https://www.youtube.com/watch?v=k4bq5A-icBw (Credit to @thehappydinoa)

Prior to this video, I haven’t been able to find any evidence of blog posts or videos demonstrating a successful bypass against Office 365’s 2FA capabilities. It’s worth noting that Office 365 is not unique – the same man-in-the-middle attack works against Google, LinkedIN, and other platforms as first demonstrated by Kevin Mitnick (KnowBe4) in May 2018 (original blog post (here). Since then other phishlets have been developed for Amazon, Github, Protonmail, Citrix, OKTA, Twitter, Instagram, Facebook, reddit, and consumer Outlook.com, and now Office 365.

The reason why this is important is because much of the security industry emphasizes MFA without raising awareness of this man-in-the-middle threat. For example, in my opinion one of the best presentations at the 2018 RSA conference was given by Booz | Allen | Hamilton which gave overwhelming evidence that 2FA would have stopped or reduced the impact of every one of the 159,700 total cyber incidents reported by the Online Threat Alliance in 2017. (Page 6, reference here). Now, the caveat has to be added that MFA would have stopped cyber incidents as long as victims were not tricked to going to proxy websites.

We have taken for granted that the very best anti-spam/anti-phish security solutions will not block 100% of the threats, and it is now time we accept the reality that MFA will not always prevent unauthorized authentication (much like how the SMS version of 2FA is no longer recommended or sufficient).

Roger Grimes of KnowBe4 gave a wildly popular presentation at the 2019 RSA Security Conference (requiring overflow seating) which listed 12 methods to bypass MFA (PDF download here). Some of these techniques require the attacker to invest a lot of time and sometimes money and risk (sim swapping) or be adept at social engineering (phone number porting). However, this all changed when Kuba Gretzky (@mrgretzky) released EvilGinx in 2017. Kuba showed how attackers can reduce their risk, cost, and effort through “network session hijacking proxy theft.” Grimes mentioned this technique among the 12 MFA bypass methods in his RSA presentation, and included a video showing how Kuba’s updated EvilGinx2, successfully bypasses the 2FA of Gmail and LinkedIN. At that time, there was no Office 365 phishlet available, but it was later added by @JamesCullum. 

In January at a Microsoft event, I asked Microsoft if Office 365 defended or detected network session hijacking proxy theft, specifically EvilGinx2. They stated that Office 365 would prevent this technique.

Enter Aidan Holland (@thehappydinoa), who recently verified that EvilGinx2 can successfully bypass Office 365’s 2FA. Aidan also solved a vexing problem for Troy Hunt, who was trying to get a list of the Fortune 500 for his security research. Read about his solution to solve that problem here.

Aidan’s video is the first showing a successful bypass of Office 365 MFA:

https://www.youtube.com/watch?v=k4bq5A-icBw

(Credit to @thehappydinoa)

It’s worth noting that the phishing link generated by EvilGinx2 is not blocked by MSFT EOP, Office ATP, Microsoft Defender ATP, or Windows Defender SmartScreen.

In the next blog post, I will discuss ways to protect against EvilGinx2.

Analysis of DNS Recon of the Fortune 500 (Part 1 of 3)

In this three-part blog series, I will be writing about interesting trends amongst the Fortune 500 using public DNS reconnaissance posted in open source github repositories. This first post is focused on the email security providers used by the Fortune 500. The other posts will analyze adoption trends in DMARC and IdP Federation.

One of the favorite people I follow on twitter is Daniel Streefkerk (@dstreefkerk) from Sydney, Australia. Daniel tweeted on February 11th about a script he published to github (here) that performs DNS reconnaissance He posted a graph (here) of which email security providers were used by the top 250 Australian Companies.

 

Then a few days later he posted (here) how he updated the script to check for federation information (ex: Does the domain federate with OKTA, ADFS, Ping, OneLogin, etc?) and other interesting things like whether Office 365 was detected, the tenant name discovered (typically it is publicly listed in the DKIM DNS record).

I was curious how his findings in Australia compared to companies in the United States, but I couldn’t think of a simple way of finding the fortune 500 email domain names. Turns out, I was not alone. One of Daniel’s fellow Auzzies, Troy Hunt, a Microsoft Regional Director (a title similar to an MVP) recently asked a similar question (here) on March 31st:

Everyone seemed to have ideas but Troy seemed frustrated at one point that there wasn’t a simple list available somewhere. That’s when Aidan Holland (@thehappydinoa) came to the rescue and wrote an elegant 152-line python script (here) to gather about 455 of the 500 from a JSON query against hifld data. He then took that data and queried virus total, threat crowd, crt.sh, and finally validated it was a valid DNS domain for email by querying the MX record in DNS. All in 152 lines of Python. Impressive.

His JSON query the initial data set came from ARCGIS.COM with this code:

FORTUNE_500_JSON
=
“https://opendata.arcgis.com/datasets/a4d813c396934fc09d0b801a0c491852_0.geojson”


Aidan published the resulting list of 455 domain names (here). Then using PowerShell, we can pipe that into Daniel’s DNS recon script, to produce a report showing the email filtering systems used by the Fortune 500.

Get-Content fortune_455_emails.txt | .\Invoke-EmailRecon.ps1 | Export-Csv 455.csv


Raw Table Results:

Email Security Vendor

Count

Proofpoint

141

Self-Hosted

91

Microsoft Exchange Online Protection (EOP)

83

Other/Undetermined

59

Symantec.Cloud

36

Cisco Email Security (Formerly IronPort Cloud)

27

Google

11

Forcepoint (Formerly Websense)

4

Trend Micro

2

FireEye Email Security Cloud

1

 

The results indicate that most are using ProofPoint, Exchange Online Protection, or they are self-hosting their own service of some type.

Comparing the results to Australia, we can see that the US Market is consolidated to a few big players, whereas Australia is reasonably diversified. The significance of this is that malware should theoretically spread slower in Australia, because malware authors would have to work significantly harder to find vulnerabilities across multiple email security solutions if they wanted to infect the majority of the top 250 companies in Australia, whereas in the USA the malware authors just need to find a flaw in ProofPoint and Exchange Online Protection to infect 50% of America’s Fortune 500.

What surprised me was to see ProofPoint has a 6% penetration into the Australian market, compared to 28% in the United States (no surprise since ProofPoint HQ is in the USA).

These results could also be helpful for smaller or mid-size businesses who sometimes look at the decisions made by members of the Fortune 500 as a standard, ex: “good enough for them, good enough for me.”

Universities, think tanks, and research firms like Gartner and Forrester can now take periodic snapshots of this data to determine trends of email security vendors (or IdP federation vendors). Companies could use this data to find out which markets to expand into. And unfortunately Malware authors have most likely already figured out that targeting flaws in ProofPoint and Exchange Online will net them 50% of the Fortune 500.

In the next blog post, I will examine DMARC and IdP adoption trends.

Passwordless phone sign-in with the Microsoft Authenticator app – not compatible with conditional access require approved client app

This blog post details the effort to enable passwordless phone sign-in to Azure Active Directory using the Microsoft Authenticator App. Last week Microsoft announced this capability on September 26th at the Ignite Conference.

In my environment, I had to first install the Azure AD PowerShell preview module:

Install-Module -Name AzureADPreview -RequiredVersion 2.0.0.114

The first error I got reminded me that I had to run it in an elevated PowerShell window.

The second error I received informed me that there were already existing commands available:

“PackageManagement\Install-Package : The following commands are already available on this system: [Insert a TON of commands] followed by “This module ‘AzureADPreview’ may override the existing commands. If you still want to install this module ‘AzureADPreview’,use -AllowClobber parameter.”

In my case, it errored out because I had previously installed the production Azure AD PowerShell module, so I added the -AllowClobber to the end like this:

Install-Module -Name AzureADPreview -RequiredVersion 2.0.0.114 -AllowClobber

The next thing to do is to connect to Azure AD:

Connect-AzureAD

Then run this command:

New-AzureADPolicy -Type AuthenticatorAppSignInPolicy -Definition ‘{“AuthenticatorAppSignInPolicy”:{“Enabled”:true}}’ -isOrganizationDefault $true -DisplayName AuthenticatorAppSignIn

You can now run a get-AzureADPolicy to see the same information above. This would be a way to check to see if another tenant admin already beat you to the task =)

 

End User Steps

 

End-users need to enable sign-in on their Microsoft Authenticator App as described here: https://docs.microsoft.com/en-us/azure/active-directory/user-help/microsoft-authenticator-app-phone-signin-faq

 

I immediately hit a roadblock where the Authenticator App was ironically blocked by our Conditional Access Policy which requires only approved client apps.

 

Very strange that Microsoft’s own Authenticator app is not an approved client app.

Another tell-tale sign that something was wrong was I had an exclamation point next to the account inside the Authenticator app.

So I then excluded myself from that policy and continued setup. I had to select an option in the Authenticator app to update phone sign-in.

 

This worked and then I was able to test the passwordless sign-in successfully. The web page will give you a number, and then you go back into the authenticator app and you select the number from three options.

If you are wondering why 77 is not in the list of three options below, it’s because I didn’t time the screen shot correctly =)

Therefore, I think Microsoft should update the known issues list to include this problem that existing Conditional Access Policies may block the passwordless sign in from working properly.

I also added a UserVoice request to have Microsoft Authenticator added to the list of approved client apps. Kind of funny that this isn’t approved already, but hey, please vote!

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/35605771-add-microsoft-authenticator-to-approved-client-app

So unfortunately, because our organization relies upon the ‘require approved client app’ to block unsavory apps, we needed to roll back this change.

Rollback Tenant

Get-AzureADPolicy | Remove-AzureADPolicy

Rollback all enrolled Authenticator apps

I discovered that rolling back the tenant was not enough. I also had to remove my O365 account from inside the Authenticator app on my mobile device. I assume when my account was upgraded to Phone sign-in, it must have altered it beyond repair. So I went into the Authenticator App accounts and removed the account, and then re-enrolled it by going to http://aka.ms/MFASetup. Finally, I was able to get back in.

So now that I have tasted how cool passwordless sign-in, I would really like to use it, but will need to wait until it is compatible with the ‘require approved app’ conditional access feature.

References:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-phone-sign-in

 

Azure Conditional Access and Azure AD Connect Service Account

If you deploy an Azure Conditional Access policy to require all Windows PC’s to be domain joined, you may find that Azure AD Connect no longer synchronizes.

And during an upgrade to the latest version of Azure AD Connect, you may be prompted with the error message “System.InvalidOperationException: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation.”

To resolve this, modify the conditional access policy to exclude the Azure AD Connect Service Account, which can be found by searching for “On-premises directory synchronization service account”

Then create a second conditional access policy that is targeted this same on-prem account with a condition exclusion for all trusted locations, and a block rule for all other access. This effectively creates an IP-Fence that prevents this service account from logging in from anything other than the trusted location.

In Preview: Privileged Access Management for Office 365

Privileged Access Management (PAM) for O365 is a way to restrict access to Office 365 administrative functions by requiring a separate person such as a manager (or someone designated the approver role) to grant access to administrative functions.

PAM is currently a PowerShell-only feature (no graphical user interface… yet) and is limited to Exchange Online at this time. Other workloads such as SharePoint Online are planned in the future. Therefore, it is more or less a proof of concept at this time, because PowerShell is not a skill that most entry-level helpdesk have acquired.

It’s a step in the right direction for sure, as it provides more fine-grained access management than Azure Privileged Identity Management (AzPIM), which gives access to an entire role for a period of time.

Where PAM differs, is that it grants access to perform certain commands only, rather than opening up the entire privileged role to someone.

It’s a nice compliment to AzPIM, but to avoid confusion I feel this should really be part of AzPIM as opposed to a separate O365 E5 feature. Microsoft should be cautious to avoid the appearance of having EMS E5 products compete against O365 E5 products. Case in point, it’s challenging for customers to understand the difference between O365 E5 Cloud App Security versus EMS E5 Cloud App Security. The same product is sold with different feature sets, but why add this confusion? In my opinion, all security elements should be bundled in EMS, and make O365 a pure productivity package. 

The other challenge with O365 PAM, and Azure PIM, is that they do not integrate with the on-premises Windows Server 2016 PAM. So effectively, a customer would have to implement three separate solutions that don’t integrate with each other. This may be a product of Agile software development than anything else. If Microsoft is consistent with what they have done with other products, we should expect to see “Microsoft PAM” which will integrate or replace all three O365 PAM, Azure PIM, and Windows PAM. At that point it will be able to compete strongly against Lieberman (now Bomgar) and/or CyberArk.

Try Office 365 PAM out here: https://docs.microsoft.com/en-us/Office365/Enterprise/privileged-access-management-in-office-365

 

Protecting Smartphones from Ransomware

At the 2018 RSA Conference I attended a session by Kevin McNamee (Director of Nokia’s Threat Intelligence Lab) and learned some valuable things that I would like to share with my blog followers.

From the ransomware samples that Kevin shared, most ransomware targeting Android can be uninstalled by booting the device to safe mode and removing Device Admin priv then uninstalling the app.

In summary the lessons I learned for protecting Android smartphones from Ransomware:

1. Don’t download apps from third party app stores.

2.Make sure “verify apps” is turned on.

3. Keep regular backups of your phone.

4. Consider 3rd party AV for your Android.

Side note: One of the other conference attendees asked Kevin what to do in their situation, where their employees in China are unable to access the Google Play Store, so they have no choice but to use 3rd party app stores. Kevin suggested that they rely upon 3rd party AV and employee security awareness training.

What about Apple iOS?

According to Kevin, AV is not necessary for iPhones because Apple doesn’t give AV vendors an API to do much good. He felt that the level of isolation in iOS is sufficient.

Not completely satisfied with this, I approached Kevin in the hallway and asked him about Pegasus Spyware –commercially available spyware sold by a startup company called the NSO Group, targeting iPhones (and Google/Blackberry) that was sold to governments. LookOut software participated in the discovery of this software which used three zero day exploits dubbed Trident (since then it has been patched in iOS 9.3.5). I asked Kevin, “Isn’t Trident an example of why we should advocate for 3rd party smartphone security software, such as LookOut?” My concern is that there could be more zero day exploits? The point I tried to make is that if you had LookOut software (or software like it), then wouldn’t you be better off? Kevin was skeptical that these vendors are actually doing much good.

For what it is worth, Lookout is still the only software that can detect Trident (according to Trident). Here is more about their discovery and how their software protected against it: https://www.lookout.com/trident-pegasus-enterprise-discovery

 

My recommendations:

If you are the one responsible for purchasing decisions of “company-owned smartphones” for your company, my recommendation is to avoid purchasing Android and purchase iPhones instead, unless you can mandate good AV installed on the Android. This is because attackers have a higher cost to find zero-day exploits like Trident. Kevin also mentioned that an attacker’s could also target iOS with social engineering techniques to get into the target’s iCloud account, and then perhaps remotely locking the phone until the ransom is paid. Kevin said even in that scenario you may be able to work with Apple to get into the account.

Microsoft has improved their Intune Mobile Device Management to support 3rd party connectors that can provide conditional access, so that only clean devices can access corporate resources such as Office 365 Exchange and SharePoint.

“Intune Mobile Threat Defense connectors allow you to leverage your chosen Mobile Threat Defense vendor as a source of information for your compliance policies and conditional access rules. This allows IT administrators to add a layer of protection to their corporate resources such as Exchange and Sharepoint, specifically from compromised mobile devices.”

There are currently four vendors supported to integrate with Intune:

Lookout

Skycure

Check Point SandBlast Mobile

Zimperium

When I looked at them, they looked very similar to me. I have not formally evaluated them but I will be speaking with each vendor since they are here at #RSAC 2018

Attack Simulator for Office 365

Microsoft has released Attack Simulator [See full GA Announcement 4/27/2018 here] to allow Office 365 Global Administrators to simulate phishing campaigns and other attack simulations.

The obvious value is finding out which users are most susceptible to phishing attacks so that you can educate them before an actual attacker exploits them.

Prerequisites

  • Your organization’s email is hosted in Exchange Online (Attack simulator is not available for on-premises email servers)
  • You have an E5 license, or have signed up for an E5 trial license (here), or an Office 365 Threat Intelligence Trial (here)
  • You have the security administrator role or Global Administrator role assigned to you
  • You have multi-factor authentication enabled (make sure to first read the MFA prerequisites here, such as enabling oAuth via powershell)

Getting Started

To access Attack Simulator, in the Security & Compliance Center, choose Threat management > Attack simulator. Or you can browse to it directly here:

https://protection.office.com/#/attacksimulator

There are currently three attacks offered by Attack Simulator:

  1. Display name spear-phishing attack
  2. Brute Force password attack
  3. Password spray attack

In this blog post we will quickly cover the first simulation. Feel free to click on the documentation link in the reference table below to read about the other two attack simultaneous.

Display name spear-phishing attack

One of the more common and successful phishing methods is to spoof the Display Name field in Outlook. This is very effective because Sender Policy Framework (SPF) only protects the RFC 5321.Mail From field, and does not protect against spoofing of the Display Name. Only Domain-based Message Authentication, Reporting & Conformance (“DMARC” – RFC 7489) protects against the Display Name field (RFC 5322.From Field). However, since very few organizations have implemented DMARC, then this simulated phishing attack is very effective.

Carrying out the phishing simulation is a straight-forward wizard in the documentation found (here). Basically you enter the email address that you want to spoof and the targeted users that you want to send the fake email to. You can pick from a few pre-built templates, then you can do some customization of the email that would be sent out. After running the campaign, you can monitor to see which users clicked on the link, and which users went a step further and gave away their credentials.

Behind the scenes

Penetration testers may be tempted to try Attack Simulator against other tenants, but Microsoft has thought of that and restricts Attack Simulator to only attack its own tenant.

Another temptation would be to use Attack Simulator to test the effectiveness of your anti-spam technologies (ATP or EOP). However, Attack Simulator is designed to bypass EOP and ATP, which you can confirm by looking at the Message Trace in Exchange Online control panel (http://outlook.com/ecp), as you won’t find any traces of Attack Simulator in the message trace, and therefore it is apparent that it bypasses all EOP and ATP protection rules. You wouldn’t want EOP or ATP blocking your attempt to phish your users, right? Perhaps in the future Microsoft could add a toggle that allows the simulated phishing campaign to be filtered by EOP/ATP to verify that those technologies are able to successfully block the phishing campaign.

How does this compare to other Phishing Simulators?

Other phishing simulators such as KnowBe4 or PhishMe have been around a lot longer, obviously, but Attack Simulator is great for customers who maybe already own the E5 license and want to phish their users at no added cost. If you only have E3 then you could purchase “Threat Intelligence” as an add-on license on top of E3 in order to get the Attack Simulator feature. However, there is another recently added feature included in the Advanced Threat Protection (ATP) license called ATP Anti-Phishing Policies which you would also get in the E5 license and therefore I feel the best value is to get the E5 rather than trying to purchase separate add-ons. I wrote a little bit about the new Anti-Phishing solution in my recent post where I wrote about the top 15 things to do before and after a phishing attack in Office 365. Basically, the new Anti-Phishing Policy can send items to quarantine if any part of the email address has been modified to bypass DMARC. For example, while DMARC protects the exact spelling of an impersonated CEO, it does not protect against a slight variation of a CEO’s address. Like Joe.Ceo@Contoso.com spelled with a zero instead of an alphabetic O, like Joe.Ceo@C0ntoso.com. In those cases, the new Anti-phishing policy can be configured to send those emails to quarantine, or redirect them to a security team, or other actions.

Need help?

Patriot Consulting provides assistance with deploying Microsoft Security solutions. We start with a free consultation to help you understand your current Microsoft licensing level, and we help you deploy the security solutions that you may already own inside your Microsoft licenses. Then we can help you pilot additional security solutions from Microsoft.

Why Patriot?

We are a Microsoft Gold Enterprise Mobility + Security Partner and have helped hundreds of companies deploy Microsoft security solutions. We focus 100% exclusively on Microsoft Cloud technologies and believe in “do one thing and do it well.” We participate in the Microsoft Partner Seller Program, and we are a Managed Microsoft Partner, which gives us access to the latest training and roadmap. As a member of the Microsoft Security Council, we have direct access to the Microsoft Product Group that develops the software.

References:

20 Things to do before and after a phishing event in Office 365

Statistics indicate that 20% of corporate users will give away their username and password when asked to do so by a social engineer (for example through a phishing email).

50% of corporate users admit to recycling their password across multiple websites. Then when these websites are hacked, the passwords can be put into credential stuffing tools like SNIPR to see what websites those passwords can be used on.

Some of the more clever and convincing phishing emails originate from a trusted person such as the CEO, HR Department, IT Department, or even Microsoft. The HR Department example might say “you have received an encrypted message from HR” and if you click on the link to view the message, it steals your O365 password. The attacker then logs into your account, forwards your email to them, and then send emails out to your customers or other colleagues to continue to propagate.

Here are a few tips on how to prepare for when this happens to you.

  1. Be prepared to Reset the affected user’s password right away. Note that if you reset the password on-premises, it can take a few minutes before that password change is synced to Office 365 (if you are using Password Hash Sync, it can take 3 to 4 minutes). If you are using ADFS then there is no delay.
  2. Document the steps to immediately revoke an active user’s session in Office 365, forcing them to try to logon with the new password. There are three supported methods
    “The first option is found in the Office 365 Admin Center under Home > Active Users. Select a user and expand the OneDrive Settings section for that user. Select “Initiate” to perform a one-time sign-out for that user that revokes active sessions across Office 365 services including Exchange Online.
    The second option to force logoff during an active user session in Office 365 to use Revoke-SPOUserSession cmdlet from the SharePoint Online PowerShell Module. This method is helpful for automating security incident response flows or when there is a need to revoke multiple users’ sessions.
    The third option to force a user sign-out extends beyond Office 365 services to all active user sessions in any Azure AD application. The Revoke-AzureADUserAllRefreshToken cmdlet is available in the AzureAD V2 PowerShell Module and expires a user’s refresh token by modifying the user’s token validity period”
    Reference: https://blogs.technet.microsoft.com/educloud/2017/06/14/how-to-kill-an-active-user-session-in-office-365/
  3. Deploy Multi Factor Authentication on targeted users, privileged users, and users who access sensitive information. Many people do not know that O365 includes free MFA without the need for additional licenses.. it comes built into all O365 plans.
  4. Check to see if mailbox forwarding was enabled, and if so to who (document the external addresses to verify the validity).
    Here is a great one-liner to run in Exchange Online Powershell:
    get-mailbox -resultsize unlimited |where {$_.ForwardingSmtpAddress -ne $null} | select displayname,forwardingsmtpaddress
  5. Check message trace logs in Exchange Online Admin center (http://outlook.com/ecp) to see what items were sent to suspected unauthorized external accounts.
  6. Disable forwarding via Transport Rule, and create an alert in Security and Compliance Center when someone tries to create a forwarding inbox rule (Indicator of Compromise)

    Reference: https://blogs.technet.microsoft.com/exovoice/2017/12/07/disable-automatic-forwarding-in-office-365-and-exchange-server-to-prevent-information-leakage/
  7. As of 2/1/2019 Mailbox Auditing is now enabled by default in Exchange Online. However if you have previously customized Mailbox Auditing, you may need to manually enable auditing of the MailItemsAccessed event, which tells you which emails the owner, delegate or administrator may have accessed.
  8. Review Azure Reports on a frequent basis
    1. Risky Sign-Ins
      1. Sign-ins from anonymous IP addresses
      2. Impossible travels to atypical locations
      3. Sign-ins from infected devices
    2. Users flagged for risk
    3. Azure Sign In Logs at portal.azure.com
    4. Office 365 Audit Logs at protection.office.com or soon to be security.microsoft.com

    Note: These reports are pretty basic but if you own Azure AD Premium P1, then you can drill into ‘why’ a user was flagged as a risk.

  9. Use Message Trace to see who received emails from the attacker’s email address.
  10. Use ATP URL Trace to view who clicked on the hyperlink sent from the attacker.
  11. Purge the email with powershell for any user who has not yet clicked on the email sent from the attacker.
  12. Cloud App Security is valuable for many reasons, but it extends the auditing to 180 days whereas the built-in audit logs in the Office 365 Security and Compliance Center only go back 90 days.
    Licensing: CAS is available in two forms, O365 E5 or EMS E5… the former protects mostly O365 and 750 other SaaS apps, whereas the later protects 15,000 SaaS apps and supports automatic log uploads from your on-premises firewalls.
  13. Office 365 Threat Intelligence (an E5 feature) can identify who your top targeted users are and alert you when there are active email campaigns going on so that you can alert your users of the threat.
  14. Consider Disabling User Consent to 3rd party applications in Azure Active Directory. This prevents users from granting consent to 3rd party apps that may be the next wave of ransomware, that encrypts mailboxes. A proof of concept was recently demonstrated on the internet. Review existing oAuth grants.
  15. Deploy ATP Anti-Phishing (added 2/5/2018). For more details: https://support.office.com/en-us/article/Set-up-Office-365-ATP-anti-phishing-policies-5a6f2d7f-d998-4f31-b4f5-f7cbf6f38578
  16. Disable Legacy Authentication
    #You can do this in Exchange Online with all license levels using the new-clientaccessrule command
    #Or You can do this for all O365 apps using Azure Conditional Access P1 or higher at portal.azure.com
  17. Disable POP/IMAP for future mailboxes and current mailboxes
    Examples:
    #All Future Mailboxes
    Get-CASMailboxPlan | set-CASMailboxPlan -ImapEnabled $false -PopEnabled $false
    #All Existing Mailboxes:
    get-casmailbox | set-casmailbox -imapenabled $false -PopEnabled $false
  18. Disable SMTP Auth at the global level or mailbox level. This prevents users from using this as a brute force vector.
    #Global Level
    Set-TransportConfig -SmtpClientAuthenticationDisabled $true
    #Mailbox Level
    Get-casmailbox -resultsize unlimited | Set-CASMailbox -SmtpClientAuthenticationDisabled $true
  19. Disable user’s powershell access in Exchange Online, ex:
    get-user | set-user -RemotePowerShellEnabled $false
    #Did you know if you run this, it won’t disable powershell on the admin account you are running it on? Its smart enough not to lock yourself out!
  20. Check Inbox rules in Exchange Online. For example, get-inboxrule -mailbox hackeduser@acme.org
    Look for rules that are forwarding content to the RSS Subscriptions folder or other obscure folders. Note: Microsoft’s Cloud App Security has a rule to detect for malicious inbox rules like this.

Tips:

  • Deploying MFA should be the first priority because if a user gives away their credentials, then the attacker cannot access the mailbox to do further damage.
  • Many people ask me how to view reports of who has or who has not been enabled for MFA. There are not GUI reports available for this in O365, so I wrote some powershell scripts at the bottom of this blog post to help you enumerate those scenarios.
    Hint: It is highly recommended to enable oAuth first (via PowerShell) so that users are not prompted to use ‘MFA App Passwords)
    oAuth is off by default in Exchange Online and Skype for Business Online. It is ON by default in SharePoint and OneDrive. For more info see:
    https://social.technet.microsoft.com/wiki/contents/articles/32711.exchange-online-how-to-enable-your-tenant-for-modern-authentication.aspx

    And
    https://social.technet.microsoft.com/wiki/contents/articles/34339.skype-for-business-online-enable-your-tenant-for-modern-authentication.aspx

  • Disabling mailbox forwarding is important because in the most recent incidents, the attacker will forward the mailbox to an outside email address and monitor for a while before initiating emails to customers or other employees.
  • Enabling auditing in Exchange Online is important, because by default auditing mailbox activity is disabled. But enabling it is not as easy as you would think – you have to be specific on what actions you want to audit, so I have included examples below.
  • Reviewing the Azure reports is important because they will indicate whether a user’s mailbox is being accessed by an unusual or distant IP address. This is often how you will find out that an account has been compromised.

Exchange Online Mailbox Auditing 101

get-mailbox | group-object AuditEnabled

This command will give you a quick and high level picture of how many accounts have Auditing enabled.

get-mailbox -resultsize unlimited | set-mailbox -AuditEnabled $true -AuditLogAgeLimit 180

This command will enable mailbox auditing on all accounts and increase the default audit level from 90 to 180

The following commands will show you the default auditing settings on a single mailbox user “Joe”

get-mailbox joe | select -ExpandProperty auditadmin

get-mailbox joe | select -ExpandProperty auditowner

get-mailbox joe | select -ExpandProperty auditdelegate

Prior to 2/1/2019, The Mailbox Owner auditing only logs a single event by default: MailboxLogin. After 2/1/2019, additional events are logged unless this has been customized.

Therefore, to enable the maximum level of auditing that you can for a mailbox owner, here is the command:

get-mailbox -ResultSize unlimited | set-mailbox -AuditOwner @{Add=”create”,”HardDelete”,”MailboxLogin”,”Move”,”MoveToDeletedItems”,”SoftDelete”,”Update”,”UpdateFolderPermissions”}

Similar commands can be run for AuditDelegate and AuditAdmin.

References:

https://support.office.com/en-us/article/enable-mailbox-auditing-in-office-365-aaca8987-5b62-458b-9882-c28476a66918#ID0EABAAA=Mailbox_auditing_actions

MFA Reporting

The MFA reporting in Office 365 is almost non-existent. You need to go to powershell to audit who has been enforced, enabled or is not yet enabled.

  1. Enabled (Means the user has been enabled but they have not yet completed MFA registration)

Get-MsolUser -All | where {$_.StrongAuthenticationRequirements.state -eq ‘Enabled’ } | Select-Object -Property UserPrincipalName,whencreated,islicensed,BlockCredential | export-csv enabled.csv -noTypeInformation

  1. Enforced (The user has completed MFA registration, so their account is not protected by MFA)

Get-MsolUser -All | where {$_.StrongAuthenticationRequirements.state -eq ‘Enforced’ } | Select-Object -Property UserPrincipalName,whencreated,islicensed,BlockCredential | export-csv enforced.csv -noTypeInformation

  1. Not Yet Enabled (These users have not yet been enabled for MFA)

Get-MsolUser -All | where {$_.StrongAuthenticationMethods.Count -eq 0 -and $_.UserType -ne ‘Guest’} | Select-Object -Property UserPrincipalName | export-csv non-enabled.csv -noTypeInformation

Need Help?

Patriot consulting offers many security services for Office 365 including deploying any of the security solutions you read about in this article. We can also do a full audit of your Office 365 environment and make recommendations to harden the security. We also offer incident response services after you get phished. Contact us at hello@patriotconsultingtech.com

How to block legacy authentication in Azure AD Premium Conditional Access

[Update 5/25/2018] Per this forum post [here] it looks like blocking legacy authentication is now possible with Conditional Access!.

Azure AD Premium’s Conditional Access feature requires Modern Authentication to function properly. This has led some to believe that legacy clients (ex: Outlook 2010 and older, or Activesync) can bypass Conditional Access Policies.

Based on my testing, this is only half true, as it depends upon the policy that you select. If you select a ‘Grant’ policy then the legacy clients will not be able to bypass your conditional access policy. However, if you select a Block policy, then the legacy clients will bypass it and connect to the service that you want to block.

So the most conservative thing to do is to use a Grant Policy, not a Block policy.

Azure AD Premium Conditional Access for Domain Joined Machines

This article is an attempt at discovering what the minimum steps are to get the Conditional Access feature which checks for Domain Join status for both Windows 10 and Windows 7 operating systems.

Conditional Access is a feature of the “Azure AD Premium P1 License” which can be purchased ala carte for $6/user/month, or as part of the “Enterprise Mobility + Security license” for $8.75/user/month, or the new Microsoft 365 SKU announced at the 2017 Inspire conference.

This is what the feature looks like when configuring a Conditional Access Policy in the Azure Portal to only permit domain joined devices:

For more information about Conditional Access, read about it here.

I had the following questions:

  • What does the conditional policy mean by “Domain Join” – is it on-premises or is it Azure AD Domain Join, both, or something else? (Answer: on-prem domain join with an account that has been synced by Azure AD Connect to the cloud… with a software deployment required for Windows 7, and a GPO required for Windows 10).
  • Is it necessary to deploy the Workplace Join v2.1 client to Windows 7 Machines? (Answer: Yes)
  • Does Azure AD Connect require configuration, and if so, what is the minimum version of Azure AD Connect required? (Yes, you must create a service connection point in Active Directory per this article).
  • What role does Azure AD Seamless Single Sign-On Play (also referred to as “Desktop SSO” in the Azure AD Connect documentation) Answer: (It provides a similar SSO experience to ADFS, but only when connected to the corporate network. And it is REQUIRED for Windows 7 machines that wish to have Workplace Join work without an ADFS server).
  • Is ADFS required? (Answer: No)
  • Is there any configuration necessary in Azure AD? (Answer: Not unless you changed the default settings)
  • Is it necessary to deploy a Group Policy change? If so, what are those changes? (Answer: For Windows 10, Yes, see below. For Windows 7, you’ll need to push out some Intranet Site to Zone mappings for the Azure Seamless SSO to work)
  • Is it necessary to create any DNS records? (Answer: Yes, see below)

Domain Join vs Azure AD Domain Join vs Azure AD Registration

If you configure a Conditional Access Policy and select the “require domain joined device” checkbox, what is it checking?

To find out, I created 6 virtual machines to see exactly what works and what does not work.

Computer Name Operating System Configuration Test Results Notes
Win10DomainJoin Windows 10.0.15063 (Creators)
  1. On-Prem Domain Joined
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
Success
Win10DJandReg Windows 10.0.15063 (Creators)
  1. On-Prem Domain Joined
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. GPO Applied “Register domain-joined computers as devices”
Success  
Win10DJandAADJ Windows 10.0.15063 (Creators)
  1. On-Prem Domain Joined
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. Azure AD Domain Joined (aka ‘Workplace Joined’)
  5. GPO *NOT* Applied “Register domain-joined computers as devices”
Success
Win10AADJoined Windows 10.0.15063 (Creators)
  1. Azure AD Joined Only
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. GPO *NOT* Applied “Register domain-joined computers as devices”
Fail – Got a block page (see block page example below) Wasn’t entirely expecting this to work since the screen tip that is in-band of the configuration says that this checkbox does *not* apply to Azure AD joined machines.

Win7DomainJoin Windows 7 SP1
  1. Azure AD Joined Only
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
Fail – Got a block page (see block page example below) Wasn’t expecting this to work – just testing to create a baseline before the Workplace Join client was installed. With no ADFS in the environment – just Azure AD Connect with Desktop SSO and Password Hash Sync.
Win7DJwithWPJ Windows 7 SP1
  1. Azure AD Joined Only
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. Workplace Join v2.1 client installed
SUCCESS I was starting to lose hope after all these failed tests, but we now have a successful test!

The common denominator for the successful test was the DeviceTrustLevel changed to “Managed”

Block Page Example

This is the end-user example of what it looks like when you try to open an application protected by a Conditional Access Policy that requires Domain Join.

DNS Records

According to the documentation, is necessary to register the following DNS CNAME record in both internal and external DNS (if using split-zone / split-brain DNS):

DNS Entry Type DNS Value (Address)
enterpriseregistration.contoso.com CNAME enterpriseregistration.windows.net

Workplace Join v2.1

For Windows 7 and Windows 8.1 devices, the documentation states that it is necessary to deploy the Workplace Join client (MSI Package) from here. This is not required for Windows 10 systems, which can register to Azure AD via group policy, although in my lab that does not appear to be working, as that does not produce any records when I run get-msoldevice. Perhaps it requires ADFS for Windows 10 machines to work with Domain Join conditional access.

Workplace join Version 2.1 (Released June 2017) added support for Azure Active Directory Seamless Single Sign On (https://aka.ms/hybrid/sso).

Ready for some kludge? The installer creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows. The task silently registers the device with Azure AD with the user credentials after authenticating using Integrated Windows Authentication. To see the scheduled task, in the device, go to Microsoft > Workplace Join, and then go to the Task Scheduler library.

The two main benefits of this tool in my opinion is that it registers a Windows 7 machine in Azure AD, and, the version 2.1 client makes it so that you don’t have to use ADFS (simplifying the configuration).

Azure AD Seamless Single Sign-On

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) is required for Windows 7 machines if you are not using ADFS. Instead, users will sign in and register to Azure Device Registration Services.

When enabled, users don’t need to type in their passwords to sign in to Azure AD, and usually, even type in their usernames. This feature provides your users easy access to your cloud-based applications without needing any additional on-premises components.

If you have ADFS, you do not need this feature as ADFS already provides “seamless SSO” (assuming you also deployed the ADFS STS web page to your Local Intranet zone in Internet Explorer).

*Note: The ‘Edge’ web browser is not yet supported. Currently IE, Chrome and Firefox are supported. Firefox requires custom configuration to make it work.

To deploy seamless SSO, you turn it on in Azure AD Connect, then you deploy it through Group Policy.

Azure AD Connect

You must be using version 1.1.484.0 or later of Azure AD Connect. Note: In the screen shot below, Pass-through auth is selected but ‘Password Synchronization’ could have been chosen as well.

If you already have an installation of Azure AD Connect, choose “Change user sign-in page” on Azure AD Connect and click “Next”. Then check the “Enable single sign on” option

Completing that step will create a new computer object in Active Directory “AZUREADSSOACC” – if this object is accidentally deleted, users can still logon, but it will just be the standard logon just like prior to seamless SSO being enabled (so it ‘fails open’ so to speak). For more information see the technical deep dive here.

Group Policy

You can add the Azure AD device authentication end-point to the local Intranet zones to avoid certificate prompts when authenticating the device. This works for both IE and Chrome which both share the same setting. For other browsers see the references section.

To roll this out in a group policy object, here are the steps:

  1. Open the Group Policy Management tool on a domain controller, ex: start > run > gpmc.msc
  2. Edit the Group Policy that is applied to some or all your users.
  3. Navigate to User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List

    Enable the policy, and enter the following values (1 indicates Intranet zone) in the dialog box.

    https://device.login.microsoftonline.com

    https://autologon.microsoftazuread-sso.com

    https://aadg.windows.net.nsatc.net

    Note: One of the references only listed the first URL, whereas another reference listed the bottom two. Since the documentation was not consistent, I’m including all three to be safe.

    Note: Rollout the above GPO at your own risk… It will add these and lock out/remove any other intranet site zones your users may have manually configured. My personal preference is to deploy these as group policy preferences instead.

    ADFS

    ADFS is not required as long as you deploy the Workplace Join v2.1 client to your Windows 7 systems, and you deploy Azure AD Seamless SSO.
    Reference: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq#i-want-to-register-non-windows-10-devices-with-azure-ad-without-using-ad-fs-can-i-use-seamless-sso-instead

    Azure AD Configuration

    By default, Azure AD enables users to register devices. So unless someone in your organization changed this setting, you should not have to change this. This is found in http://portal.azure.com then find Azure Active Directory > Users and groups > Device settings. The policy “Users may register their devices with Azure AD” must be set to “All” (which is the default setting).

    Windows 10

    All domain-joined devices running Windows 10 Anniversary Update and Windows Server 2016 automatically register with Azure AD at device restart or user sign-in. However, Windows 10 November 2015 Update automatically registers with Azure AD only if the rollout Group Policy object is set. So the best thing to do is configure a Group Policy object to control the rollout of automatic registration of Windows 10 and Windows Server 2016 domain-joined computers.

    Go to Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration. Right-click Register domain-joined computers as devices, and then select Edit. Select Enabled, and then select Apply.

  • Older GPMC Consoles may see: Computer Configuration > Policies > Administrative Templates > Windows Components > Workplace Join > Automatically workplace join client computers. Select Enabled, and then select Apply.


Testing

You can check successful registered devices in your organization by using the Get-MsolDevice cmdlet in the Azure Active Directory PowerShell module.+

The output of this cmdlet shows devices registered in Azure AD. To get all devices, use the -All parameter, and then filter them using the deviceTrustType property. Domain joined devices have a value of Domain Joined. In my testing, the only combination that seemed to work with conditional access is when the DeviceTrustType was Domain Joined, and the DeviceTrustLevel was Managed.


To test the scenario where the user enters only the username, but not the password:

Troubleshooting

  1. Check to make sure the computer account is syncing to the cloud by running get-msoldevice. If it does not show up there, then make sure the OU or container containing the computer objects is being synced. If it shows up there, it must have DeviceTrustType = ‘Domain Joined’ and DeviceTrustLevel = ‘Managed’
  2. For Windows 10 only, Check to see if the computer object contains a value in the userCertificate attribute. If not, this means that the computer is unable to read the value of the SCP object in Active Directory. Check to make sure that the Authenticated Users group is not missing from the “Device Registration Configuration” object.  To see if it can query the SCP, run this command:
    $config = [ADSI] “LDAP://CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=YourDomain,DC=com”;$config
  3. On Windows 10, Run the dsregcmd /status and make sure ‘AzureAdJoined’ is Yes and ‘IsUserAzureAD’ is Yes
    Under User State, verify that WamDefaultSet is Yes, WamDefaultAuthority is organizations, WamDefaultId is https://login.microsoft.com, AzureAdPrt is Yes, and WamDefaultGUID contains a value.
  4. For Windows 7 only, run autoWorkplaceJoin.exe /i to find out the current status of the device, this will also provide helpful error messages as well.
  5. Enable Debug and Analytic logs in Event Viewer. Click the View menu. Select Show Analytic and Debug Logs to make these logs visible. Enable logs under Applications and Services Logs > Microsoft > Windows > User Device Registration, and then export the logs for Admin and Analytic folders about five minutes after you have rebooted (or signed-out/in)
  6. Check the troubleshooting article https://docs.microsoft.com/en-us/azure/active-directory/device-management-troubleshoot-hybrid-join-windows-current
  7. When pushing out the Workplace Join Client, users may get a pop-up “To continue, this application needs to create a key.”

    To suppress this, you can push out a group policy object to not require user input for storing certificates.