Detects .NET red/black-team tools via typelibguid

Hunt Hypothesis

This hunt hypothesis targets adversaries leveraging custom or known .NET-based red and black team tools that can be uniquely identified by their specific TypeLibGUID signatures within process execution logs. Proactively hunting for these indicators in Azure Sentinel is essential to distinguish legitimate security tooling from malicious .NET payloads, thereby reducing false positives while uncovering stealthy reconnaissance activities that may evade standard signature-based detections.

YARA Rule

rule HKTL_NET_GUID_NashaVM {
    meta:
        description = "Detects .NET red/black-team tools via typelibguid"
        reference = "https://github.com/Mrakovic-ORG/NashaVM"
        author = "Arnim Rupp"
        date = "2021-01-21"
    strings:
        $typelibguid0 = "f9e63498-6e92-4afd-8c13-4f63a3d964c3" ascii nocase wide
    condition:
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and any of them
}

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://github.com/Mrakovic-ORG/NashaVM
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the rule “Detects .NET red/black-team tools via typelibguid,” along with suggested filters or exclusions:

• Scenario: Automated Backup and Reporting Services

  • Context: Enterprise backup solutions like Veeam Backup & Replication or reporting engines like Power BI Report Server often utilize .NET assemblies that register specific TypeLibGUIDs during their scheduled nightly maintenance jobs. These tools frequently instantiate COM objects for data extraction, mimicking the behavior of red-team reconnaissance tools.
  • Filter/Exclusion: Create an exclusion rule based on ProcessName (e.g., Veeam.Backup.Service.exe, MsMgmtService.exe) and restrict detection to non-standard user accounts (exclude SYSTEM or specific service accounts like BackupSvc).

• Scenario: Endpoint Detection and Response (EDR) Scanning

  • Context: Native EDR agents such as CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne perform continuous .NET process monitoring. Their internal scanning engines often load .NET libraries with TypeLibGUIDs that overlap with known red-team frameworks (like SharpUp or BloodHound) to analyze memory and registry states.
  • Filter/Exclusion: Exclude processes running under the EDR vendor’s specific service account (e.g., CrowdStrikeService, WdNisSvc) and filter by CommandLine containing keywords like “scan”, “update”, or “healthcheck”.

• Scenario: Office 365 / Microsoft Teams Update Mechanisms

  • Context: The Microsoft Office Click-to-Run Service and Teams Background Tasks frequently execute .NET-based update logic that registers TypeLibGUIDs to manage add-ins and plugin architectures. These legitimate background processes can trigger the rule when they initialize