This hunt hypothesis identifies the execution of known .NET-based Red and Black team security tools by monitoring process names that match established tool signatures. Proactively hunting for these artifacts in Azure Sentinel is essential to distinguish legitimate security testing activities from potential adversary use of similar .NET frameworks, thereby reducing false positives and ensuring accurate threat visibility.
rule HKTL_NET_NAME_HTTPSBeaconShell {
meta:
description = "Detects .NET red/black-team tools via name"
reference = "https://github.com/limbenjamin/HTTPSBeaconShell"
author = "Arnim Rupp"
date = "2021-01-22"
strings:
$name = "HTTPSBeaconShell" ascii wide
$compile = "AssemblyTitle" ascii wide
condition:
(uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and all of them
}
This YARA rule can be deployed in the following contexts:
This rule contains 2 string patterns in its detection logic.
Here are 5 specific false positive scenarios for the rule “Detects .NET red/red-black-team tools via name,” along with suggested filters or exclusions:
Scenario: Automated Backup and Maintenance Scripts
Veeam.Backup.RedTeamAgent.exe might be flagged because “RedTeam” appears in the filename.--backup, --maintenance) or restrict detection to exclude known backup service accounts (e.g., DOMAIN\BackupSvc).Scenario: Internal DevOps and CI/CD Pipelines
DevOps.RedTool.Scanner.exe during a nightly compilation window could trigger an alert, mistaking the internal scanner for an external red-team engagement.Scenario: Endpoint Detection and Response (EDR) Self-Protection
Defender.RedTeam.Sentinel.exe might be part of the security suite itself rather than an external tool being detected by it