Appendix G: Detection-Rule Listings

This appendix records the experimental detection rules developed from the backend and operator-side reconstruction. It is a publication snapshot, not a claim that the rules are production-ready and not a complete detector for HackingTeam products. The authoritative working files remain under research/hackingteam-rcs/detections/; the copies below let a reader review the exact logic without having to infer it from prose in Chapter 12.

The rules cover the RCS database, service installation, collector-facing traffic, licence files, launchers, and certificate-generation source. They do not attempt to identify implants or exploit packages. No implant, exploit, collector, anonymizer, or injector was executed to create this rule set.

Publication snapshot

The following SHA-256 values identify the working files represented here:

These hashes are provenance aids, not signatures for detecting RCS. A rule file can change during review, and adversarial infrastructure will not contain the research files themselves. Recompute the hashes from the authoritative files before treating a later book build as the same revision.

Validation status

Validation was deliberately separated into syntax, positive, and negative tests. A rule that parses can still miss the intended artifact. A rule that matches one expected sample can still be far too broad for operational use.

The expanded YARA set is still local and Linux-heavy rather than statistical enterprise false-positive evidence. Sigma conversion and the portable fixture evaluator do not reproduce a SIEM’s ingestion-time field mapping. Suricata’s negative corpus is deliberately narrow. All ten rules therefore remain experimental even though their mechanical and synthetic-fixture gates pass. The exact tools, hashes, PCAP boundaries, corrections, and limitations are in research/hackingteam-rcs/detections/VALIDATION.md.

Deployment and interpretation

Sensor position is part of each rule’s meaning. The login rule requires a decrypted or TLS-terminated HTTP view; it cannot inspect JSON fields through the original encrypted listener. The private frontend header applies to the source’s cleartext backend-to-collector path. The certificate rule sees an unmodified default certificate, while a deployment with replacement certificates evades it. Windows Sigma rules require telemetry that preserves full paths, command lines, registry data, or service-install events. YARA is suited to acquired server files or approved file scanning, not a network sensor.

None of the following should be treated as an RCS signature by itself:

• TCP 80, 443, 444, 442, 4499, or MongoDB ports;
• an nginx banner or status 444;
• Ruby, MongoDB, GridFS, YAML, or long-lived certificates;
• the strings ACME Corp or Root Certification Authority separately; or
• an HTTP login route with ordinary username and password fields.

An analyst should seek agreement across layers: for example, an exact Windows service name and RCS install root, followed by the distinctive licence schema and target-scoped MongoDB collections. The highest-value detections describe a combination, not a familiar technology. The IOC catalogue in Appendix F gives the supporting combinations and triage order.

Local deployment also requires ordinary engineering work: choose an approved SID range; tune address variables and traffic direction; confirm the Suricata version’s sticky-buffer behavior; map Sigma fields to the endpoint product; scope YARA paths and file-size limits; suppress authorized defensive reconstructions; and preserve the alert’s underlying telemetry for review.

Suricata listing

The four local research SIDs occupy 9904101 through 9904104. They are not registered SIDs. Confidence and deployment constraints are carried in rule metadata where practical.

# HackingTeam RCS backend research rules
# Status: experimental. See ../README.md for provenance and validation limits.
# SIDs 9904101-9904199 are local research identifiers, not registered SIDs.

# Default RCS-generated database leaf certificates are issued by the
# self-generated "Root Certification Authority" / "ACME Corp" CA.
alert tls any any -> any any (msg:"RESEARCH HackingTeam RCS default database certificate issuer"; flow:established; tls.cert_issuer; content:"Root Certification Authority"; nocase; content:"ACME Corp"; nocase; classtype:trojan-activity; reference:url,github.com/hackedteam; metadata:confidence high, provenance source, deployment Default_RCS_CA_only; sid:9904101; rev:1;)

# rcs-db sends the deployment-wide server signature to collectors in this
# private header over cleartext HTTP. The name is considerably more specific
# than the port or nginx response banner.
alert http any any -> any 80 (msg:"RESEARCH HackingTeam RCS frontend authentication header"; flow:established,to_server; http.header_names; content:"|0d 0a|X-Auth-Frontend|0d 0a|"; nocase; classtype:trojan-activity; reference:url,github.com/hackedteam; metadata:confidence high, provenance source, deployment Cleartext_frontend_path; sid:9904102; rev:1;)

# The collector deliberately uses nginx's non-standard 444 status for invalid
# requests. This is a triage signal only because ordinary nginx deployments
# can use the same code.
alert http any 80 -> any any (msg:"RESEARCH Possible HackingTeam RCS collector decoy response"; flow:established,to_client; http.stat_code; content:"444"; startswith; endswith; classtype:misc-activity; reference:url,github.com/hackedteam; metadata:confidence low, provenance source, deployment Collector_cleartext_HTTP; sid:9904103; rev:1;)

# Intended for a decrypted or TLS-terminated sensor position. This identifies
# the RCS login route and expected JSON field combination, not encrypted wire
# traffic on the original database listener.
alert http any any -> any any (msg:"RESEARCH Possible HackingTeam RCS operator login"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/auth/login"; startswith; endswith; http.request_body; content:"\"user\""; nocase; content:"\"pass\""; nocase; content:"\"version\""; nocase; classtype:misc-activity; reference:url,github.com/hackedteam; metadata:confidence medium, provenance source_and_lab, inspection decrypted_HTTP_required; sid:9904104; rev:1;)

SID 9904101 requires both issuer strings but is still restricted to the default CA. SID 9904102 has the most specific network token, yet it sees only the relevant internal path and its presence should never justify recording the credential value. SID 9904103 is explicitly low confidence. SID 9904104 is a contextual rule for a decrypted sensor and is not evidence that an arbitrary HTTPS session contains those fields.

Suricata 7.0.3 now parses the complete file and the four controlled positive flows alert as intended. Before deployment, repeat the check on the intended sensor version and replay a representative benign corpus. The published fixtures validate rule mechanics, not production performance or uniqueness.

Sigma listings

Sigma describes portable detection intent; it does not eliminate differences among event sources and SIEM backends. The Image, CommandLine, TargetObject, Details, EventID, ServiceName, and ImagePath fields must be mapped to the selected telemetry product. Command-line visibility and registry auditing are not universal defaults.

MongoDB service command line

title: HackingTeam RCS MongoDB Service Command Line
id: c81dd9ca-dd86-443a-aec3-3e154115c0f8
status: experimental
description: Detects creation of the MongoDB services using the exact RCS service-name arguments.
author: HackingTeam RCS reconstruction project
date: 2026-09-12
references:
  - data/HackingTeam/unpacked/hackedteam/rcs-db/nsis/RCS.nsi:505-516
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith:
      - '\mongod.exe'
      - '\mongos.exe'
  selection_root:
    CommandLine|contains: '\RCS\DB\'
  selection_service:
    CommandLine|contains:
      - '--serviceName RCSMasterConfig'
      - '--serviceName RCSMasterRouter'
      - '--serviceName RCSShard'
  condition: selection_image and selection_root and selection_service
falsepositives:
  - A defensive reconstruction or forensic replay using the original directory and service names
level: high
tags:
  - attack.persistence
  - attack.t1543.003

This rule combines executable basename, install root, and one of three exact service-name arguments. The combination is more useful than monitoring for mongod.exe or mongos.exe alone. Validate quoting, case handling, and command-line normalization in the chosen backend.

Ruby NX compatibility registry value

title: HackingTeam RCS Ruby NX Compatibility Registry Value
id: 2b157273-91da-4ab5-a3d8-e52c75067dd5
status: experimental
description: Detects the exact AppCompatFlags value written by the original RCS Windows installer for its bundled Ruby runtime.
author: HackingTeam RCS reconstruction project
date: 2026-09-12
references:
  - data/HackingTeam/unpacked/hackedteam/rcs-db/nsis/RCS.nsi:296
logsource:
  category: registry_set
  product: windows
detection:
  selection:
    TargetObject|endswith: '\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\C:\RCS\Ruby\bin\ruby.exe'
    Details: 'DisableNXShowUI'
  condition: selection
falsepositives:
  - A deliberate compatibility entry for an unrelated application installed into the exact historical RCS path
level: high

The signal is the exact compatibility value, executable path, and data. An acquired registry hive can support the same hypothesis even where historical event telemetry is unavailable. Registry path representation differs among products, so test the converted rule rather than assuming the portable field will survive unchanged.

MongoDB service installation

title: HackingTeam RCS MongoDB Service Installation
id: 96d82f69-5403-43e6-b988-d3f08313fd0d
status: experimental
description: Detects the MongoDB Windows service names and descriptions installed by the original RCS database installer.
author: HackingTeam RCS reconstruction project
date: 2026-09-12
references:
  - data/HackingTeam/unpacked/hackedteam/rcs-db/nsis/RCS.nsi:505-516
logsource:
  product: windows
  service: system
detection:
  selection_event:
    EventID: 7045
  selection_name:
    ServiceName:
      - RCSMasterConfig
      - RCSMasterRouter
      - RCSShard
  selection_path:
    ImagePath|contains:
      - '\RCS\DB\mongodb\win\mongod.exe'
      - '\RCS\DB\mongodb\win\mongos.exe'
  condition: selection_event and selection_name and selection_path
falsepositives:
  - A test environment intentionally recreating the leaked RCS installer layout
level: high
tags:
  - attack.persistence
  - attack.t1543.003

The service-install and process-creation rules overlap intentionally: one looks for the persistence event, the other for the command that creates or starts the role. An environment can have one telemetry source and not the other. Correlating the two with acquired service configuration increases confidence.

YARA listing

These rules search for distinctive combinations within small backend files. They avoid sample-specific file hashes and do not reproduce embedded licence keys or authentication values. They are appropriate for authorized file scanning and forensic collections. They are not malware-family coverage for client implants.

rule HT_RCS_Server_License_YAML
{
    meta:
        description = "Detects the distinctive RCS 9 backend license schema"
        author = "HackingTeam RCS reconstruction project"
        date = "2026-09-12"
        confidence = "high"
        provenance = "original rcs-db config/rcs.lic"

    strings:
        $yaml = "---" ascii
        $serial = ":serial:" ascii
        $maintenance = ":maintenance:" ascii
        $hostname_sync = ":hostname_sync:" ascii
        $collectors = ":collectors:" ascii
        $anonymizers = ":anonymizers:" ascii
        $integrity = ":integrity:" ascii
        $platform_1 = ":blackberry:" ascii
        $platform_2 = ":symbian:" ascii
        $platform_3 = ":winphone:" ascii
        $feature_1 = ":correlation:" ascii
        $feature_2 = ":deletion:" ascii

    condition:
        filesize < 256KB and
        $yaml at 0 and
        all of ($serial, $maintenance, $hostname_sync, $collectors, $anonymizers, $integrity) and
        2 of ($platform_*) and
        all of ($feature_*)
}

rule HT_RCS_Server_Windows_Launcher
{
    meta:
        description = "Detects RCS database Windows batch launchers"
        author = "HackingTeam RCS reconstruction project"
        date = "2026-09-12"
        confidence = "high"
        provenance = "original rcs-db bin batch files"

    strings:
        $root = "cd /D C:\\RCS\\DB" ascii nocase
        $db = "ruby bin\\rcs-db-" ascii nocase
        $worker = "ruby bin\\rcs-worker-" ascii nocase

    condition:
        filesize < 64KB and $root and 1 of ($db, $worker)
}

rule HT_RCS_Server_Certificate_Generator_Source
{
    meta:
        description = "Detects the original RCS backend certificate-generation source"
        author = "HackingTeam RCS reconstruction project"
        date = "2026-09-12"
        confidence = "high"
        provenance = "original rcs-db lib/rcs-db/config.rb"

    strings:
        $ca_cn = "Root Certification Authority" ascii
        $ca_org = "ACME Corp" ascii
        $db_cert = "rcs-db.crt" ascii
        $collector_cert = "rcs-collector.crt" ascii
        $collector_cn = "/CN=collector" ascii
        $anon_ca = "rcs-anon-ca.crt" ascii

    condition:
        filesize < 1MB and all of them
}

The licence rule depends on the schema rather than one issued licence. The launcher rule combines the historical root with database or worker launch commands. The certificate-generator rule is source-artifact detection: it should not be interpreted as proof that a host actively served an RCS certificate. Acquired files need contextual review for timestamps, paths, ownership, adjacent artifacts, and signs of a research copy.

Reproduction commands

The working detection README records the exact validation environment. A reviewer can reproduce the safe checks without starting RCS components. The following examples scan only static files and a tiny system-text corpus:

yara research/hackingteam-rcs/detections/yara/rcs_backend_artifacts.yar \
  data/HackingTeam/unpacked/hackedteam/rcs-db/config/rcs.lic

yara research/hackingteam-rcs/detections/yara/rcs_backend_artifacts.yar \
  data/HackingTeam/unpacked/hackedteam/rcs-db/bin/rcs-db-demo.bat

yara research/hackingteam-rcs/detections/yara/rcs_backend_artifacts.yar \
  data/HackingTeam/unpacked/hackedteam/rcs-db/lib/rcs-db/config.rb

yara research/hackingteam-rcs/detections/yara/rcs_backend_artifacts.yar \
  /etc/hosts /etc/passwd /etc/services

Paths assume the project layout used by the reconstruction. The positive files are original read-only leak material; the commands do not alter or run them. Sigma conversion and Suricata replay are intentionally omitted because they have not yet passed in this environment. Publishing hypothetical success commands would blur the distinction between a proposed test and a completed one.

What an alert establishes

A match establishes that the observed bytes or event fields satisfy that rule’s conditions. It does not, by itself, establish who operated the system, whether it was used against a person, whether a server was reachable from the Internet, or whether the platform was compromised. A defensive lab, historical archive, forensic workstation, or malware-analysis repository can legitimately contain the same source artifacts.

For incident response, retain the original event, packet, certificate, or file and record sensor position and collection time. Then correlate against the Appendix F catalogue, the preservation sequence in Chapter 13, and the architecture in Chapter 2. Treat rule confidence as the specificity of the combination under stated assumptions—not as an attribution score.

Sources and evidence

• SOURCE: original database installer, certificate generator, REST authentication controller, frontend client, and collector source cited in the rule metadata and in docker-lab/IOCs.md.
• LAB: previously recorded backend protocol observations described in the project IOC record; no new edge-component traffic was generated for this appendix.
• VALIDATION: research/hackingteam-rcs/detections/README.md and the rule hashes above; detections/VALIDATION.md records Suricata 7.0.3 PCAP replay, Sigma CLI/pySigma check, conversion and event fixtures, and YARA 4.5.0 positive plus expanded local-negative tests.
• LIMIT: target sensor/SIEM mappings, representative benign network and Windows enterprise corpora, and performance remain deployment gates.