Detects .NET red/black-team tools via name

Hunt Hypothesis

This hunt hypothesis targets adversaries leveraging custom or known .NET-based offensive and defensive utilities to establish persistence or conduct reconnaissance within Azure Sentinel environments. Proactively hunting for these specific tool names allows the SOC team to distinguish legitimate administrative activity from potential red-team exercises or stealthy attacker movements that might otherwise be obscured by standard low-severity alerts.

YARA Rule

rule HKTL_NET_NAME_Infrastructure_Assessment {
    meta:
        description = "Detects .NET red/black-team tools via name"
        reference = "https://github.com/NyaMeeEain/Infrastructure-Assessment"
        author = "Arnim Rupp"
        date = "2021-01-22"
    strings:
        $name = "Infrastructure-Assessment" ascii wide
        $compile = "AssemblyTitle" ascii wide
    condition:
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and all 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 2 string patterns in its detection logic.

References

• https://github.com/NyaMeeEain/Infrastructure-Assessment
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the rule “Detects .NET red/blue-team tools via name,” including suggested filters and exclusions:

• Scenario: Automated Vulnerability Scanning by Admin

  • Context: A security administrator runs a scheduled scan using Microsoft Security Compliance Toolkit (SCT) or Nessus Agent on the domain controller. These tools often execute .NET binaries with names like MSTest.exe or SecurityComplianceScanner.dll that match the rule’s naming pattern for red-team tools.
  • Filter/Exclusion: Create a whitelist exclusion based on the Process Name (MSTest.exe, NessusAgent.exe) combined with the Parent Process being TaskScheduler.exe or a specific admin service account (e.g., DOMAIN\svc-scanner).

• Scenario: CI/CD Pipeline Build Artifacts

  • Context: The DevOps team utilizes Jenkins, Azure DevOps, or GitHub Actions runners to build .NET applications. During the build phase, these agents spawn temporary processes like dotnet.exe, MSBuild.exe, or custom tooling named RedTeamSimulator.dll which mimics the naming convention of red-team simulation tools.
  • Filter/Exclusion: Exclude events where the Source Host is a known CI/CD server (e.g., build-server-01) and the User Account belongs to the service group (e.g., DOMAIN\svc-cicd-build).

• Scenario: Enterprise Endpoint Management Updates

  • Context: Microsoft Intune or System Center Configuration Manager (SCCM) pushes a .NET-based update agent or compliance check. The client process often registers as IntuneManagementExtension.exe or similar, which may contain substrings triggering the rule if the