Users have taken to Microsoft Office 365’s tools, but many are unaware of free features that come with their accounts — features that would keep them safe.
Organizations have quickly adopted the full-featured set of productivity and collaboration tools offered by Office 365 (O365), which was moved under the Microsoft 365 umbrella this spring. They’re leveraging Microsoft Teams, SharePoint, OneDrive, and other file storage systems to store and collaborate on sensitive documents and data. However, with the exponential increase of usage in the last few months, the platform has become an enticing and fruitful target for attackers of all types.
In 2019, 85% of all incident response investigations conducted by the Kudelski Security Incident Response team started with a compromised Office 365 account. While reviewing the results of those investigations, one thing quickly became apparent: Attackers know the productivity suite better than most IT administrators and defenders.
How Attackers Are Attacking
This year, we saw attackers leverage a multitude of attack techniques, most of which could have been easily prevented by turning on features included with most Office 365 Enterprise plans. As organizations strategize for 2021, it is paramount to know and understand how malicious actors are capitalizing on their knowledge of these environments to compromise, persist in, and exfiltrate data.
Here are the three most common ways attackers are leveraging Microsoft’s platform:
1. Brute Force and Password Stuffing
Credential stuffing is still one of the leading causes of account compromise. Attackers take advantage of the fact that most organizations don’t enable multifactor authentication (MFA), a free feature offered to all Microsoft 365 tenants, which, according to Microsoft, could have prevented 99.9% of account compromises it saw across users’ environments.
The vast majority of “password stuffing” attacks aren’t targeted. Attackers get a hold of a password dump from a third-party source and attempt to “stuff” these passwords into Microsoft 365 login prompts. Such attacks rely heavily on users reusing passwords across software-as-a-service providers and websites, including their corporate accounts.
Another challenge is the “legacy protocol” support. Through this, attackers can brute force MFA-protected accounts by attempting to authenticate via protocols that don’t support MFA, such as SMTP, IMAP, and POP3. These provide an avenue to freely brute-force account passwords without having to deal with further verification prompts. Today, there are at least four different open source tools that abuse these legacy protocols, including LyncSniper (targets Skype for Business), SensePost Ruler (targets Exchange Server), MailSniper (targets Outlook Web Access/Exchange Web Services), and SprayingToolkit (targets Lync/Outlook Web Access).
This problem is compounded by organizations allowing users to reset MFA devices or applications simply through a confirmation link sent to the compromised email accounts. Attackers reset MFA tokens and leverage these newly registered applications to log in to others that rely on Microsoft 365 Single Sign-On, potentially gaining access to more sensitive data.
Organizations should work to limit the usage of legacy protocols with Azure Active Directory conditional access as well as take advantage of the MFA feature to add another layer of security for users.
2. OAuth Consent Grants
Attackers are also phishing users with links to OAuth consent grant screens designed to trick users into granting access to their Microsoft 365 accounts to malicious applications. Those consent screens are real, hosted by Microsoft, and request that users provide access to their email inboxes and other data. Once malicious applications are granted access, attackers have unrestricted access to the accounts without the need for passwords or MFA. Because OAuth 2.0 grants don’t expire, attackers will retain that access until that specific grant is revoked. Even changing a user’s password won’t revoke these tokens automatically.
There are several open source tools that enable attackers to easily create fake applications that need to be considered, including MdSec Office 365 Attack ToolKit and FireEye PwnAuth.
We have seen an uptick in the abuse of OAuth grants. To prevent these attacks, organizations can require that only specific preapproved applications be allowed to leverage OAuth 2.0 or leverage publisher verification, or administrators can choose to limit access to “sensitive” OAuth 2.0 grants.
3. eDiscovery and Microsoft Flow Abuse
Attackers know that the eDiscovery features included in the platform’s security and compliance center can be leveraged to easily identify documents of interest across applications, including Microsoft Teams, SharePoint, OneDrive, and Exchange email servers. They also know that most organizations haven’t even taken the time to turn on audit logging (turned off by default) or aren’t monitoring their Azure Active Directory environments. These organizations won’t be able to detect attackers granting themselves the permissions necessary to leverage eDiscovery tooling.
The productivity suite also grants users access to Microsoft Flow, a workflow automation tool that enables users to automate tasks based on certain triggers. Malicious actors take advantage of the fact that once they gain access to eDiscovery, they can leverage Microsoft Flow and completely automate sensitive document discovery and exfiltration.
Attackers know this platform better than most defenders and have become very effective at compromising tenants easily without having to bypass the multitude of Microsoft-offered security capabilities. Part of the issue is that organizations aren’t taking full advantage of the free features included with their subscriptions. In fact, attackers are abusing Microsoft features that IT administrators aren’t even aware exist.
IT and security teams must know what they have available already and enable all the features that will help them close the door to potential threats.
This article was originally featured in Dark Reading.
The Microsoft Office 365 productivity suite counts around 200 million active users per month, making it an incredibly attractive target for cybercriminals. In fact, 85% of security incidents investigated by the Kudelski Security Incident Response team in 2019 can be attributed to an Office 365 email compromise.
Of course, email isn’t the only asset at risk. The Office 365 suite hosts critical documents and information for the entire organization in tools like Sharepoint, Teams, and OneDrive. In many cases, it’s a single source of truth, especially with Office 365’s reliance on Azure Active Directory and the integrated SSO capabilities for 2,800+ SaaS applications.
This interconnectivity creates a high-risk environment where a compromise of a user’s “email account” can result in widespread access to sensitive data and systems. Increasing the costs (either in terms of financially or in terms of effort) required to attack office 365 tenants is critical. We’ve compiled five actionable steps that security teams can take to prevent Office 365 attacks across the (abridged) kill chain—reconnaissance, compromise, persistence, and action on objectives.
Note: Conducting reconnaissance against an Office 365 tenant is fairly easy. Through DNS and TLS certificate transparency logs, you should assume that an attacker will be able to find out whether or not your organization uses Office 365. Additionally, there are several tools that enable attackers to enumerate valid user accounts ever attempting to authenticate (via timing attacks). Therefore, instead of looking for signs of potential recon, we recommend organizations focus on identifying signs of compromise and/or post-exploitation activity.
Turn on audit logging for your Office 365 tenant as soon as possible.
This may come as a surprise, but detailed audit logging is not turned on by default in Office 365 tenants. It’s an incredibly valuable source of information that can help you identify Office 365 attacks. If possible, send the logs to a SIEM, so you can start to build detection capabilities around it.
Turn off / restrict access to legacy protocols.
Legacy protocols (POP3, SMTP, etc.) allow attackers to perform brute-force attacks without being prompted for multi-factor authentication. This is by design. Legacy protocols exist for devices like office printers, legacy chat applications like Lync and Skype for Business, or older versions of Outlook that do not support the latest communication protocols that can prompt users for MFA.
There are a couple of options to disable legacy protocols for your Office 365 tenant. By using Azure Active Directory, you can set up conditional access rules to limit which IP addresses or accounts can authenticate, leveraging legacy protocols for devices that don’t support more modern protocols. We recommend that organizations create a set of service accounts that are used exclusively to send email from devices that don’t support modern email protocols and closely monitor those accounts.
Pre-approve applications that can request OAuth grants.
OAuth is the protocol that powers the “sign in with Facebook/Google” capabilities as well as other SSO and Active Directory integrations. These requests specify the type of access you want to grant an application—e.g. your email address and account name. However, attackers have started creating fake applications that request email read and write access without a user ever providing a password and it allows attackers to retain access even if account credentials are changed. This is especially problematic if a global admin is the target of an attack. Without knowing it, the admin could grant access to the entire Office 365 tenant (including all files, applications, etc).
Microsoft Office 365 has built-in tools that enable organizations to look for these fake applications used to generate Illicit OAuth grants. Additionally, as an admin, you can create a pre-approved list of applications that are able to request OAuth access to avoid illicit grants.
Clear outlook mail rules immediately if an attack is suspected or identified.
Attackers use email forwarding (and other) rules to persist in an environment even after an attack has been detected and “mitigated”. An attacker can create rules that could automatically forward emails to a third party or auto-delete “red flag” emails or replies. For example, if a user notices a suspicious email and emails the owner of the account, the rule could automatically delete that email, leaving the account owner none the wiser.
Complicating matters, there are tools that can abuse exchange message APIs to hide email rules from admins and users. This is why in addition to changing email passwords, it’s important to also clear all email rules after an account has been compromised.
Closely monitor access to eDiscovery and set up alerts that trigger every time the tool is used.
eDiscovery allows users to search for data across all applications in the Office 365 tenant using keywords or a specific set of criteria. This access, coupled with a tool like Microsoft Flow, which enables the automatic download and upload of eDiscovery results, can allow attackers to automate the discovery and exfiltration of sensitive data.
By default, global admins do not have access to the eDiscovery tool. You must request to be added to the user group that has access. Once you have access, monitor every addition to that tool. A new addition to user groups used to grant access to eDiscovery should be investigated as it’s possible an attacker is attempting to abuse the tool to find sensitive data. The easiest way to do this is to set up alerts that trigger every time eDiscovery is used. Over time, you can tune the alerts to specific scenarios.
Last, but not least, it’s safe to assume that attackers know more about Office 365 than you. They know about all the capabilities, the legacy protocols, eDiscovery, and other above and below board services that can be leveraged to enumerate users and automate data exfiltration
Updated on March 12th, 2020: to reflect that Microsoft has now made a patch for the vulnerability available. As such, we’ve updated the advisory reflects updated mitigations.
On March 10th, a critical Remote Code Execution (RCE) vulnerability in the Microsoft Server Message Block (SMBv3) protocol was inadvertently disclosed. The vulnerability, known as CVE-2020-0796, is caused by how newer Windows operating systems handle certain requests, specifically compressed SMBv3 packets. Microsoft intended to release a patch for this vulnerability as part of March’s “Patch Tuesday”, however, the patch appears to have been pulled at the last minute. This led to the inadvertent disclosure of the issue before a patch is available. The flaw, considered critical, and could allow attackers to execute arbitrary code without user interaction and without authentication.
This critical vulnerability is considered “wormable” as it leads to pre-authenticated remote code execution of the Windows server implementation of SMBv3. To exploit the vulnerability on a Windows machine acting as an “SMB server”, unauthenticated attackers can simply send a maliciously crafted packet to a targeted SMBv3 Server. Once an attacker has successfully compromised one system, they can attempt to automatically exploit other reachable SMB servers. However, to exploit an SMB Client, an unauthenticated attacker would need to configure a malicious SMBv3 server and convince a user to connect to it.
The Windows implementation of the SMB protocol was recently exploited by WannaCry, NotPetya and other recent attacks, enabled by a leak of reliable equation group exploits in 2017. However, Due to the difficulty in successfully and reliably exploiting such vulnerabilities, the Cyber Fusion Center does not expect to see immediate mass exploitation attempts. There are currently no publicly available exploits targeting this vulnerability and there are several Microsoft Windows exploit mitigations that make building a successful and reliable exploit very difficult.
While they are no current public exploits, the Cyber Fusion Center strongly recommends mitigating the vulnerability as soon as possible.
Note: On March 12, 2020, Microsoft released an out-of-band patch for this vulnerability. The Cyber Fusion Center strongly recommends that organizations apply the patch as soon as possible, especially on SMB servers such as Active Directory domain controllers and file shares. If it’s not possible to patch in the very near future, the Cyber Fusion Center recommends disabling compression for the SMBv3 protocol with the commands in the “Temporary Mitigations” section of this advisory.
- Microsoft Windows 10 Version 1903 (May 2019 update)
- Microsoft Windows 10 Version 1909 (v1909)
- Microsoft Windows Server Version 1903 (Server Core Installation)
- Microsoft Windows Server Version 1909 (Server Core Installation)
Attackers who successfully exploit this vulnerability can execute arbitrary code within the context of the SMBv3 process. The vulnerability is considered “wormable” as it allows for pre-authenticated remote code execution without any user interaction.
On March 12th, 2020 (one day after “Patch Tuesday”) Microsoft released out-of-band patches for this severe vulnerability in Window’s implementation of SMBv3 compression. The Cyber Fusion Center strongly recommends organizations apply this patch rather than use the temporary mitigations outlined below.
The patch is available via the traditional Microsoft Update delivery process and on the Microsoft Security Response Centers website.
While there is no patch for this vulnerability yet, it’s possible to mitigate the issue on SMB servers by disabling support for compression on the SMBv3 protocol.
Windows administrators can disable compression to prevent unauthenticated attackers from exploiting the vulnerability on SMBv3 Servers by using the PowerShell command below.
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” DisableCompression -Type DWORD -Value 1 -Force
- No reboot Is required after making this change
- This workaround does not prevent exploitation of SMB clients
If necessary, you can rollback this change with the Powershell command bellow:
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” DisableCompression -Type DWORD -Value 0 -Force
The Cyber Fusion Center also strongly recommends that organizations mitigate the potential of an attack on a Windows 10 client by blocking all outbound SMB (TCP port 445) on corporate firewalls.
Additionally, Microsoft has published guidelines for preventing lateral SMB connections and preventing SMB traffic from entering or leaving the corporate network provides details on how to mitigate this vulnerability and other attackers in the future:
Kudelski Security’s Francisco Donoso, Director – Global Security Strategy, provides a brief webcast overview of CurveBall, the Microsoft Windows cryptographic API vulnerability.
Today, we’ll be talking about CurveBall, a Microsoft Windows cryptographic API vulnerability. We’ll give you a brief overview of Curveball as the vulnerability is called, talk a little bit about the potential impact and what you can do to remediate and detect.
First things first CurveBall impacts, Windows 10, Windows Server 2016 and Windows Server 2019. The reason that these operating systems are impacted is because they support new versions of Elliptic Curve Cryptography. ECC, as it’s called, is just another signature algorithm similar to RSA that’s faster and more efficient than RSA. With ECC you can have smaller key sizes that are effectively as secure as larger RSA keys and thus they’re really valuable for fast, speedy encrypted communication.
The vulnerability exists because Microsoft now supports what are called non-standard curves, which allow attackers to spoof certificates that Microsoft Windows would consider valid even though they are not. Because of this, Curveball can allow attackers to spoof HTTPS certificates. That means that an attacker in a privileged network position who can capture your client’s traffic could potentially spoof a certificate using one of these non-standard curves and intercept that traffic, potentially modifies it and potentially introduce other traffic into that supposedly secure stream. Additionally, this allows attackers to spoof what are called code signing certificates, which are intended to protect machines by application whitelisting. Several application whitelisting solutions allow organizations to prevent non-signed binaries or code from running on their machines. Additionally, there are several cryptographic protections that Microsoft Windows requires for security purposes to be signed either by Microsoft itself or a trusted developer.
Leveraging this vulnerability, an attacker could potentially run malicious code on a system that should not have been run. Now Kudelski Security and our research team have released a proof of concept exploit. Here you can see that we’ve been able to spoof a certificate that’s considered valid for GitHub.com, even though this is hosted on a Kudelski Security site. This is a real-world example of the potential impact of the CurveBall vulnerability.
So again, this exists because Windows fails to properly validate elliptic curve cryptography certificates, allows an attacker to spoof those certificates to intercept HTTPS or TLS traffic or potentially run malicious code on a system that requires binaries to be run. Kudelski Security has released a proof of concept exploit and published a detailed blog on the topic, for those of you who are interested.
Now talking a little bit about detection and response, Microsoft, in coordination with the U.S. National Security Agency, released a patch for this vulnerability on January 14, 2020. Everyone should apply that patch as soon as possible. From a detection perspective, the new patch actually introduces a new application event logged by Windows computers with a source of Microsoft Windows Audit CVE. For those of you who are looking to detect potential exploitation of this vulnerability, once a system has been patched, you’ll be able to centrally collect these potential logs and identify an attempt to exploit this vulnerability. Just a quick note that this event will only be written once the patch has been applied to the impacted computer. Finally, it’s also possible to detect potential tampering or TLS certificates spoofing by monitoring TLS handshakes using a system like an intrusion detection system or other network monitoring solutions. There are several signatures that vendors have released and if you’re interested, our blog posts also cover some more additional details.
Finally, I just want to remind everyone that while this vulnerability is highly impactful, it’s not the end of the world. Windows updates, which are used to deliver secure code and patches to all of these windows machines are not impacted. They actually use a separate algorithm, RSA, and Microsoft has embedded the full certificate chain in Windows to validate that they’ve been properly signed by Microsoft. That limits the potential impact. Additionally, Microsoft released several critical severity vulnerabilities in remote desktop gateways that we recommend clients prioritize. Since those are much more likely to be exploited by unsophisticated attackers in the next few days.
Read the proof of concept here: https://research.kudelskisecurity.com/2020/01/15/cve-2020-0601-the-chainoffools-attack-explained-with-poc/
Read the security advisory here: https://modernciso.com/2020/01/16/security-advisory-multiple-critical-vulnerabilities-on-windows-systems/
On January 14th, 2020 (Patch Tuesday), Microsoft released patches for a severe vulnerability Window’s cryptographic subsystems and critical vulnerabilities in Windows Server Remote Desktop (RDP) Gateway. These Microsoft vulnerabilities are considered critical and the Cyber Fusion Center strongly recommends applying these patches as soon as possible. Kudelski Security expects active exploitation in the near future.
The U.S National Security Agency released an advisory regarding a vulnerability in a cryptographic library (Crypt32.dll) used in Microsoft Windows 10, Windows Server 2016, and Windows Server 2019 (CVE-2020-0601). This issue impacts the verification of elliptic curve cryptography (ECC) signatures in security certificates. The verification of such certificates has been discovered to be defective and may allow an attacker to incorrectly validate a forged certificate. Successful exploitation of this issue has been shown to allow for interception, modification, and decryption of TLS / HTTP(s) traffic by attackers in privileged network positions. Additionally, this may allow attackers to successfully bypass code-signing requirements on Windows systems or bypass Device Guard application whitelisting solutions.
Kudelski Security’s research team has been able to successfully exploit this vulnerability to issue spoofed HTTPs certificates considered valid by Windows 10, Windows Server 2016, and Windows Server 2019:
Additionally, Kudelski Security has released a public POC available on our Github page:
This “Patch Tuesday” also included patches for multiple critical vulnerabilities in Windows Remote Desktop (RDP) Gateways. These critical vulnerabilities lead to unauthenticated Remote Code Execution (RCE) with SYSTEM privileges. Such vulnerabilities could be leveraged by attackers to remotely compromise systems without authentication or user interaction. Remote Desktop Gateways allow organizations to centralize Remote Desktop services and provide remote access to Windows endpoints and servers without a VPN, provide web-based RDP user experiences, and more.
Microsoft released patches for a severe vulnerability Window’s cryptographic subsystems and critical vulnerabilities in Windows Server Remote Desktop (RDP) Gateway. Kudelski Security expects active exploitation in the near future. As such, the Cyber Fusion Center strongly recommends mitigating these issues as soon as possible.
The Microsoft Windows cryptographic subsystem vulnerability was publicly disclosed jointly by Microsoft and the U.S National Security Agency (NSA) after being successfully patched by Microsoft. Microsoft and the NSA have publicly stated that that they’ve not observed any exploitation of this vulnerability. Additionally, Kudelski Security has been able to leverage this vulnerability to successfully to issue spoofed HTTPs certificates considered valid by Windows 10, Windows Server 2016, and Windows Server 2019 and has released public Proof Of Concept code (POC) on our github page. Please review the sources linked in this document for our blog post and links to the POC code.
The vulnerability is in a cryptographic library (Crypt32.dll) used in Microsoft Windows 10, Windows Server 2016, and Windows Server 2019 (CVE-2020-0601). This issue impacts the verification of elliptic curve cryptography (ECC) signatures in security certificates. The verification of such certificates has been discovered to be defective and may allow an attacker to incorrectly validate a forged certificate. Successful exploitation of this issue has been shown to allow for interception, modification, and decryption of TLS / HTTP(s) traffic by attackers in privileged network positions. Additionally, this may allow attackers to successfully bypass code-signing requirements on Windows systems or bypass Windows Device Guard or other application whitelisting solutions.
Additionally, Microsoft has released patches for multiple critical vulnerabilities in Windows Remote Desktop (RDP) Gateways. These critical vulnerabilities may lead to unauthenticated Remote Code Execution (RCE) with SYSTEM privileges. These vulnerabilities could be leveraged by attackers to remotely compromise systems without requiring to validate credentials or user interaction. Remote Desktop Gateways allow organizations to centralize Remote Desktop services and provide remote access to Windows endpoints and servers without a VPN, provide web-based RDP user experiences, and more.
It’s important to note that Remote Desktop (RD) Gateway is a separate application rather traditional Remote Desktop Protocol. Organizations looking to identify any potentially exposed RD gateways should look for systems exposing UDP port 3391 (not the traditional RDP Port on TCP 3389) along with Remote Desktop Web Services on HTTPs (TCP/443).
Kudelski Security expects to see attackers leveraging these Remote Desktop Gateway vulnerabilities to compromise unpatched systems in the near future due to the prevalence of the technology and the ability to compromise critical systems without authentication or user interaction. As such, we strongly recommend that clients apply these patches as quickly as possible.
Microsoft Windows Crypto Subsystem issue
Organizations who do not currently have Kudelski Security Cyber Fusion Center’s Threat Monitoring and Hunting services may want to ensure Windows Application Logs are being centrally collected and monitored. Microsoft has introduced a new Windows Event source named “Microsoft-Windows-Audit-CVE”. Microsoft Windows will now write events to the local Windows application logs with this source if there are attempts to exploit this vulnerability. Note that the Windows Event source will only be available after the latest patches have been applied.
Additionally, it’s possible to detect potentially invalid TLS certificates being used to exploit this vulnerability by intercepting TLS packets and checking certificate signature for uncommon elliptic curve parameters. By analyzing TLS traffic, the “ServerHello/Certificate/ServerHelloDone” packet contains the certificate which should be checked for possible forgery.
Additionally, the Cyber Fusion Center is actively working with our vendor partners to ensure we can actively detect attempted exploitation of this vulnerability. For customers with the Cyber Fusion Center’s Endpoint Detection and Response service will be proactive notified if potential exploitation is detected.
Microsoft Remote Desktop Gateway issues
Organizations who do not currently have Kudelski Security Cyber Fusion Center’s Threat Monitoring and Hunting services or our vulnerability scanning services may want to identify exposed versions of Web Services for remote desktop or systems that respond to UDP port 3391. Several vendors have released IDS or IPS detection signatures.
Additionally, the Cyber Fusion Center is actively working with our vendor partners to ensure we can actively detect attempted exploitation of these vulnerabilities. For customers with the Cyber Fusion Center’s Endpoint Detection and Response service will be proactive notified if potential exploitation is detected.
Mitigation and Response
The Cyber Fusion Center is actively working with our vendor partners to ensure we can actively detect attempted exploitation of these vulnerabilities. For customers with the Cyber Fusion Center’s Endpoint Detection and Response or Threat Monitoring services will be proactive notified if potential exploitation is detected.
For customers with the Cyber Fusion Center’s vulnerability scanning service will be proactively notified if any vulnerable Remote Desktop gateway systems are detected.