Detects .NET red/black-team tools via name

Hunt Hypothesis

This detection identifies the execution of known .NET-based red and black team utility names to distinguish legitimate security testing activities from potential adversary use of similar frameworks for reconnaissance or lateral movement. Proactively hunting for these tools in Azure Sentinel allows the SOC team to validate authorized test engagements against unexpected occurrences, ensuring that legitimate operations are not mistaken for malicious activity while uncovering hidden threats leveraging standard .NET binaries.

YARA Rule

rule HKTL_NET_NAME_weevely3 {
    meta:
        description = "Detects .NET red/black-team tools via name"
        reference = "https://github.com/epinna/weevely3"
        author = "Arnim Rupp"
        date = "2021-01-22"
    strings:
        $name = "weevely3" 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/epinna/weevely3
• 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 or exclusions:

• Scenario: Automated Backup and Maintenance Scripts

  • Context: Enterprise backup solutions (e.g., Veeam, Rubrik) often deploy .NET-based agents that execute maintenance tasks using executable names similar to security tools. For instance, a scheduled job named Veeam.Backup.Agent.exe might be running on the file system root, triggering the rule due to its .NET framework signature and naming convention resembling red-team utilities.
  • Filter/Exclusion: Exclude processes where the parent process is a known backup service (e.g., Veeam.Backup.Service) AND the executable path resides within the standard vendor installation directory (e.g., C:\Program Files\Veeam\Backup\).

• Scenario: Internal DevOps and CI/CD Pipeline Agents

  • Context: In a software development environment, internal build agents (such as Jenkins or Azure DevOps agents) frequently utilize .NET tools like dotnet.exe or custom wrappers named BuildRunner.exe to compile code. These agents often run on the same network segment as security monitoring servers and may mimic the behavior of red-team reconnaissance tools by scanning directories or executing scripts.
  • Filter/Exclusion: Create an exclusion for processes running under specific service accounts (e.g., NT SERVICE\Jenkins or DEVOPS-BUILD-AGENT) where the command line arguments contain keywords like “build,” “compile,” or “pipeline” rather than security-specific flags like “recon” or “scan.”

• Scenario: Endpoint Management and Patching Solutions

  • Context: Unified Endpoint Management (UEM) platforms like Microsoft Intune or SCCM utilize .NET executables to push patches and inventory data. A