Detects .NET red/black-team tools via name

Hunt Hypothesis

This hunt hypothesis identifies the execution of known .NET-based red and black team tools within the Azure environment by leveraging filename pattern matching to distinguish legitimate security activities from potential adversary use of similar frameworks. Proactively hunting for these specific tool signatures allows the SOC team to validate authorized testing operations while rapidly isolating any anomalous instances that could indicate an attacker mimicking trusted utilities to establish persistence or evade detection.

YARA Rule

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

False Positive Guidance

Here are 5 specific false positive scenarios for the HKTL_NET_NAME_K8tools detection rule, along with suggested filters and exclusions:

• Kubernetes Dashboard Deployment in Production

  • Scenario: The enterprise deploys the official k8s-dashboard or kube-dashboard application within the production namespace. As a .NET-based tool often used by operations teams for monitoring, its executable name matches the rule’s signature, triggering an alert despite being a standard infrastructure component rather than a red/black team engagement.
  • Filter/Exclusion: Exclude processes running under the kube-system or dashboard namespace where the parent process is kube-apiserver or kubelet. Additionally, add a whitelist for specific known dashboard image hashes (e.g., kubernetesui/dashboard:latest).

• Internal CI/CD Pipeline Agent Execution

  • Scenario: During nightly build cycles, internal Jenkins or GitLab runners execute .NET-based Kubernetes CLI tools (such as kubectl wrappers or custom admission controllers) to validate manifests. These agents often run with filenames containing “K8” in their naming convention, mimicking the red-team tool signature.
  • Filter/Exclusion: Create an exclusion for processes initiated by known CI/CD service accounts (e.g., svc-jenkins-runner or gitlab-agent) and restrict detection to non-build-time windows (e.g., exclude alerts occurring between 02:00–04:00 UTC when pipelines are active).

• Scheduled Health Check Jobs

  • Scenario: A scheduled Windows Task or Cron job named “K8-Health-Probe” runs every hour to verify cluster node connectivity. This .NET executable is part of the standard observability stack but triggers the rule due to its filename matching the K8 tool pattern.
  • **Filter/Ex