The attack surface of a cloud tenant should get a lot of consideration. It is important to understand that some legacy protocols, like SMTP, are not capable of accommodating multifactor authentication; and, although they are largely being deprecated, we may still see them in use. Attackers are particularly fond of these legacy protocols, as they can be used to bypass a tenant’s MFA requirements.
Microsoft has recently forced tenants to implement their “Security Defaults” (https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults). These include blocking legacy authentication. I have found that Security Defaults will block authentication attempts generated with SMTP, but this does not keep them from occurring altogether. And so, they will clutter sign-in logs.
To keep this method of malicious authentication attempts from being able to be generated altogether, we can use Microsoft’s guidance at https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission to disable SMTP AUTH in Exchange Online. To do this, first install the ExchangeOnlineManagement module from the PowerShell Gallery. Then, authenticate to your tenant by using the Connect-ExchangeOnline cmdlet. Once you are authenticated and a connection has been established, you can view whether you have SMTP AUTH disabled with this one-liner:
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabledIf SMTP AUTH is not already disabled, use the following to disable it:
Set-TransportConfig -SmtpClientAuthenticationDisabled $trueNow, on the client-side, SMTP authentication attempts will return the following:
These attempts do not even generate an entry in the Sign-In logs, because they are stopped from occurring in the first place. But, what happens if -SmtpClientAuthenticationDisabled is $false?
What does it look like to emulate one of these attacks? To do so, we’re going to want to establish a TLS session with the Office 365 TLS server. We can use OpenSSL to do so. There is a Chocolatey OpenSSL package that makes this easy. So, first, if you do not have the Chocolatey package manager installed, you can do so using the following:
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))Then, install OpenSSL using Chocolatey like so:
choco install opensslNow, lets use OpenSSL to establish a TLS session with smtp.office365.com via TCP port 587:
openssl s_client -connect smtp.office365.com:587 -starttls smtp You should be able to see “Post-Handshake New Session Ticket arrived:” along with information about this connection. Now, we can pose “EHLO” to initiate the SMTP conversation, and the SMTP server will return its supported commands. You should receive response code 250.
Here, we are looking for the authentication methods. Here we can see that LOGIN and XOAUTH2 types are supported. We want basic authentication, so we are going to use the LOGIN method. Enter “AUTH LOGIN”, and the server will return “Username:”, but it is encoded using UTF-8 base64. We need to respond with our desired username, which is really our O365 email address, encoded using UTF-8 base64. Then, the server will request “Password:” in the same way, and you can return your desired password encoded using UTF-8 base64. The following PowerShell script is a way to encode/decode your plaintext in this way, but it is important to note that this is not a secure method to do so.
# clear variables for repeatability
Get-Variable -Exclude PWD,*Preference | Remove-Variable -EA 0
# set encoding type
$encodingType = "UTF8"
# string input
$plaintext = "<INSERT PLAINTEXT>"
# encode plaintext and print to console in red
$bytes = [System.Text.Encoding]::$encodingType.GetBytes($plaintext)
$ciphertext = [Convert]::ToBase64String($bytes)
Write-Host -ForegroundColor Red $ciphertext
# decode plaintext and print to console in green
$deciphered = [System.Text.Encoding]::$encodingType.GetString([System.Convert]::FromBase64String($ciphertext))
Write-Host -ForegroundColor Green $deciphered
If you have Security Defaults enabled, you will get this response, but you will still see these attempts in your Sign-In Logs.
And, without Security Defaults enabled?
Bingo. This is why Microsoft has enforced these policies- legacy protocols were simply not built with cloud authentication in mind, and thus, pose serious vulnerability to your cloud tenant. You should ensure that you have Security Defaults enabled, and to keep these malicious authentication attempts from even being able to be generated, thus keeping them from flooding your sign-in logs, you should ensure that you have SMTP AUTH disabled in Exchange.
