Google Cloud's VM Threat Detection + Exciting New VMTD Previews

[andras]

Cloud security threats are always evolving. While many focus on the network layer, insidious threats like cryptocurrency miners, rootkits, and sophisticated malware target the heart of your virtual machines (VMs). Google Cloud's Security Command Center (SCC) offers a powerful solution: VM Threat Detection.

VM Threat Detection findings are high-severity threats that we recommend you fix immediately

What is VM Threat Detection?

• VM Threat Detection is a built-in service within SCC Premium. It goes beyond traditional endpoint agents by working at the hypervisor level of your Google Cloud infrastructure.
• This means it scans your VM memory and disks for malicious applications, even if those threats try to hide themselves.
• Key targets include cryptocurrency mining software, kernel-mode rootkits, and other advanced malware.

How VM Threat Detection Works

• Under the Hood: VM Threat Detection is embedded in Google Cloud's secure hypervisor, ensuring deep visibility into VMs without installing agents.
• Scanning: It regularly scans Compute Engine projects and VM instances for signs of malicious activity.
• Analysis: Data from VM guest memory is analyzed, and findings are reported directly to your Security Command Center dashboard.

How cryptocurrency mining detection works

Powered by Google Cloud's threat detection rules, VM Threat Detection analyzes information about software running on VMs, including a list of application names, per-process CPU usage, hashes of memory pages, CPU hardware performance counters, and information about executed machine code to determine whether any application matches known cryptocurrency mining signatures. When possible, VM Threat Detection then determines the running process associated with the detected signature matches and includes information about that process in the finding.

New Preview Features: Rootkits and Malware on Disk

The power of VM Threat Detection is expanding! Now in preview, it can detect kernel-mode rootkits and scan your VM’s persistent disk for malware.

Kernel-mode rootkit detection

VM Threat Detection infers the type of operating system running on the VM and uses that information to determine the kernel code, read-only data regions, and other kernel data structures in memory. VM Threat Detection applies various techniques to determine if those regions are tampered with, by comparing them to precomputed hashes that are expected for the kernel image and verifying the integrity of important kernel data structures.

Malware detection on disk

VM Threat Detection takes short-lived clones of your VM's persistent disk, without disrupting your workloads, and scans the disk clones. This service analyzes executable files on the VM to determine whether any files match known malware signatures. The generated finding contains information about the file and the malware signatures detected.

Benefits of VM Threat Detection

• Agentless = Hassle-Free: No software to install or manage on VMs, reducing deployment time and complexity.
• Invisible to Attackers: Working at the hypervisor level makes it difficult for malware to detect and evade.
• Seamless with SCC: Findings and insights integrate directly into your central security monitoring and workflow.

If you activate the Premium tier of Security Command Center, VM Threat Detection scans are automatically enabled. If needed, you can disable the service and/or enable the service at the project level.

https://cloud.google.com/security-command-center/docs/concepts-vm-threat-detection-overview

Are you using VM Threat Detection? Share your experiences in the comments!

Remember, this exciting rootkit and disk scanning feature is in preview. Your feedback is valuable to make VM Threat Detection even better!

[thelinux]

We've recently encountered a concerning trend of "Defense Evasion: Unexpected kernel code modification" alerts in Google Cloud Security Command Center (SCC). Unfortunately, these alerts lack detailed descriptions, hindering our ability to efficiently triage potential security incidents.

While we understand the importance of security, we're concerned about the following aspects:

• Limited Information: The lack of details in the alert messages makes it difficult to distinguish between actual threats and potential false positives. This alert is currently in preview, which statistically increases the possibility of false positives.
• Unexpected Activation: It's unclear why SCC automatically activated this preview service without an explicit opt-in from our end. We believe customers should have control over enabling preview features.

These issues create significant challenges, as we're receiving numerous alerts with minimal information, making it time-consuming and difficult to prioritize potential security risks.

Possible Solutions:

• Enhanced Alert Descriptions: We kindly request Google Cloud to provide more detailed descriptions within SCC alerts for "Defense Evasion: Unexpected kernel code modification," particularly when the feature is still in preview. This would significantly improve our ability to differentiate between legitimate threats and false positives.
• Opt-in for Preview Features: We recommend implementing a system where customers can explicitly choose to activate preview features like this one. This ensures we have full control over potentially less-stable features that could generate false positives.
• False Positive Guidance: It would be beneficial to receive more comprehensive guidance on troubleshooting potential false positives related to "Defense Evasion: Unexpected kernel code modification." This could involve documentation on common causes or troubleshooting steps.

We appreciate Google Cloud's commitment to security, but the current situation with these alerts is creating unnecessary workload and making it difficult to effectively manage security risks. We believe the proposed solutions would significantly improve our ability to effectively utilize SCC and address security concerns within our environment.

[andras]

Thanks for your comments and apologies for the slight delay on my side on this topic, i've been away from my standard access for a few weeks. 

Preview offerings are frequently made public, but they are not always feature-complete as we see on this one as well with some of the limited information on remediation and such.

In regards to this specific alert memory forensics techniques are used by VMTD to analyze the contents of the VM's memory and identify any changes made by the suspect application. Examining memory regions that are normally inaccessible to user-mode processes, such as the kernel stack or kernel data structures, can be part of this. VMTD is alerting because it has detected a change in the kernel code loaded in the VM memory. It currently lacks the ability to specify which application changed the code or provide additional information about the change. This feature planned to be added in the future.

In this current and similar situations my best course of recommendations would be to raise these issues as a support ticket to provide additional visibility and tracking for the issue. They may also be able to supply additional guidance or documentation if such is available.

If you have access to, i would also recommend highlighting this issue with your Customer Success Manager, Technology Solutions Consultant or Security Advisor. They are working with our users to identify and help with such feedback back to engineering and product management.

The feedback provided here on our community forums are also greatly valuable for us as it gives additional visibility from the user community. We frequently monitor these channels and I will reflect the information supplied here to our customer success and product management teams. 

Thank you for your time and updates on this topic!