This detection identifies active reconnaissance efforts by the Fierce2 domain scanner, signaling an adversary’s initial phase of mapping network boundaries and identifying live hosts within the Azure Sentinel environment. Proactive hunting for this signature is critical to uncover early-stage threat intelligence gathering that often precedes more aggressive exploitation attempts, allowing the SOC team to prioritize defensive measures before attackers establish a foothold.
rule Fierce2
{
meta:
author = "Florian Roth"
description = "This signature detects the Fierce2 domain scanner"
date = "07/2014"
score = 60
strings:
$s1 = "$tt_xml->process( 'end_domainscan.tt', $end_domainscan_vars,"
condition:
1 of them
}
This YARA rule can be deployed in the following contexts:
This rule contains 1 string patterns in its detection logic.
Here are 5 specific false positive scenarios for the Fierce2 Domain Scanner detection rule, including suggested filters and exclusions:
Scenario: Internal Security Team performing quarterly DNS zone enumeration using a dedicated Fierce2 instance on the SEC-OPS server.
10.50.10.0/24) or filter by the specific hostname SEC-OPS-FIERCE.Scenario: Automated scheduled job running nightly DNS health checks via a Python script that invokes Fierce2 against internal subdomains to verify record propagation.
python.exe or taskeng.exe) and the execution time falls within the maintenance window of 01:00–04:00 UTC daily.Scenario: Third-party cloud migration consultant running a pre-migration assessment tool that bundles Fierce2 to map existing DNS infrastructure before moving workloads to Azure/AWS.
VENDOR-MIGRATION-SVC) and limit the scope to the project duration dates defined in the change management ticket.Scenario: DevOps pipeline executing a CI/CD stage that validates DNS configuration changes immediately after code deployment, utilizing Fierce2 as part of the integration test suite.
192.168.50.15) where the destination ports are restricted to standard DNS query ports (UDP 53