Detects RayInitiator GRUB bootkit stage 2 code that identifies the Linux kernel syscall table.

Hunt Hypothesis

This hunt detects the presence of a sophisticated GRUB bootkit in its second stage, specifically targeting adversaries that manipulate the Linux kernel’s system call table to establish persistent root-level access and evade traditional detection mechanisms. A SOC team should proactively hunt for this behavior within Azure Sentinel because identifying these early-stage modifications allows for immediate remediation before the adversary can fully embed itself into the operating system’s core execution flow.

YARA Rule

rule MAL_Cisco_RayInitiator_Stage_2 {
   meta:
      author = "NCSC"
      description = "Detects RayInitiator GRUB bootkit stage 2 code that identifies the Linux kernel syscall table."
      date = "2025-09-25"
      reference = "https://www.ncsc.gov.uk/static-assets/documents/malware-analysis-reports/RayInitiator-LINE-VIPER/ncsc-mar-rayinitiator-line-viper.pdf"
      score = 85
      license = "https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/"
      id = "c49bdbe7-eba6-562c-8388-5e638887b405"
   strings:
      $xc1 = {
         49 89 E0 48 83 F8 30 0F 84 70 00 00 00 49 01 C0 49 8B
         10 48 83 C0 08 66 85 D2 75 E4 BF ?? ?? 60 00 48 8B 3C 17 48 BE 6E
         6D 69 5F 6D 61 78 5F
      }
   condition:
      $xc1
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 1 string patterns in its detection logic.

References

• https://www.ncsc.gov.uk/static-assets/documents/malware-analysis-reports/RayInitiator-LINE-VIPER/ncsc-mar-rayinitiator-line-viper.pdf
• Source Rule

False Positive Guidance

Here are specific false positive scenarios for the “RayInitiator GRUB bootkit stage 2” detection rule, including suggested filters and exclusions:

• Scenario: Automated OS Patching via Ansible or Puppet

  • Context: During scheduled maintenance windows, configuration management tools like Ansible (using systemd playbooks) or Puppet agents execute tasks to update the GRUB bootloader (grub2-mkconfig) and modify kernel parameters. These operations often trigger low-level reads of the syscall table as part of the boot configuration regeneration process.
  • Filter/Exclusion: Exclude events where the parent process is ansible-runner, puppet-agent, or salt-minion running under a known service account (e.g., svc-automation) during defined maintenance hours (e.g., 02:00–04:00 UTC).

• Scenario: Cloud Image Provisioning and Golden Image Updates

  • Context: In environments using Terraform or Cloud-init, the provisioning of new VM instances involves initializing the GRUB stage 2 code to map the kernel syscall table before the OS fully mounts. This is a standard part of the “bootstrapping” phase for new infrastructure, not an intrusion attempt.
  • Filter/Exclusion: Filter out alerts originating from hosts with a host_age < 48 hours or where the event source matches cloud-init scripts (cloud-localds, cloud-init) on specific image families (e.g., AWS EC2 amzn2-hvm or Azure CBL-Mariner).

• Scenario: Forensic Data Collection by Security Agents

  • Context: Endpoint Detection and Response (EDR) agents like CrowdStrike Falcon, SentinelOne, or Wazuh perform periodic integrity checks. These