Detects .NET red/black-team tools via name

Hunt Hypothesis

This rule identifies the execution of known .NET-based Red and Black team security tools by analyzing process names to distinguish legitimate testing activities from potential adversary use of similar frameworks for stealthy operations. Proactively hunting for these signals in Azure Sentinel allows the SOC team to validate authorized tool usage, reduce false positives during security exercises, and detect unauthorized deployments that may indicate an attacker leveraging .NET environments to establish a foothold or evade detection.

YARA Rule

rule HKTL_NET_NAME_SharpHose {
    meta:
        description = "Detects .NET red/black-team tools via name"
        reference = "https://github.com/ustayready/SharpHose"
        author = "Arnim Rupp"
        date = "2021-01-22"
    strings:
        $name = "SharpHose" 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/ustayready/SharpHose
• Source Rule

False Positive Guidance

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

• Scenario: Automated Backup Jobs using PowerShell Modules

  • Context: Enterprise backup solutions (e.g., Veeam, Commvault) often utilize custom .NET scripts or modules named Veeam.Backup.Service.exe or similar to manage data snapshots. These processes frequently match the naming patterns of Red/Blue team tools like Veeam.NET or generic .NET tool names.
  • Filter/Exclusion: Exclude processes running under the specific service account (e.g., DOMAIN\BackupSvc) and restrict detection to paths outside standard backup directories (e.g., exclude C:\Program Files\Veeam Backup & Replication\).

• Scenario: Endpoint Protection Scanning Engines

  • Context: Modern EDR agents (such as CrowdStrike Falcon or SentinelOne) employ .NET-based scanning engines that may be named FalconSensor.exe or SentinelOneAgent.dll. These often invoke internal .NET tools for real-time heuristic analysis, which can mimic the naming convention of security testing frameworks like Cobalt Strike Beacon or Mimikatz.
  • Filter/Exclusion: Whitelist known EDR vendor processes by exact file path and digital signature. Add a condition to exclude events where the parent process is the primary EDR service (e.g., falcon.sys or s1agent.exe).

• Scenario: Scheduled CI/CD Pipeline Agents

  • Context: DevOps pipelines running on build servers often execute .NET-based deployment agents. Tools like Jenkins, Azure DevOps, or GitHub Actions runners frequently spawn processes with names resembling security tools (e.g., AzureDevOps.Agent.exe or Jenkins.BuildTool.dll) to compile and