Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› How can security teams detect DealersChoice activity?
Threats, Abuse & Incident Response

How can security teams detect DealersChoice activity?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Detect DealersChoice by correlating suspicious endpoint behaviour with command-and-control traffic and identity misuse, rather than relying on one detection rule. Look for unusual process chains, persistence, script or loader execution and repeated external connections, then expand the search to other systems for the same operator tools, accounts or staging pattern.

How to spot DealersChoice across endpoint and network signals

DealersChoice is easier to catch when you look at it as a campaign pattern rather than a single event. The strongest signal is a cluster of suspicious endpoint activity that lines up with outbound command-and-control, especially when the same host also shows new persistence, script or loader execution, and unusual follow-on connections that repeat over time.

That means a single alert rarely proves much on its own. A script launch, a strange parent-child process chain, or a beaconing connection may be benign in isolation, but the combination becomes meaningful when the timing, process lineage, DNS or proxy telemetry, and the destination pattern all point to the same operator workflow.

Teams should also treat lateral repetition as part of detection. If one system shows the pattern, search for the same tooling, the same staging behaviour, the same account activity, or the same external destinations elsewhere in the environment, because operator tradecraft often leaves a reusable footprint across multiple hosts.

Why correlation matters more than a single rule

Detection works best when endpoint, identity, and network telemetry are correlated into one view. DealersChoice-style activity can blend into routine administration if teams only look for one indicator, such as a suspicious process name or an obvious malware hash, because the operator may change tooling while preserving the same execution path and communication pattern.

Look for combinations that are hard to fake accidentally: a loader or script engine spawning from an unusual parent, persistence appearing shortly after first execution, repeated outbound contact to the same remote infrastructure, and the use of accounts or tokens that do not fit the host’s normal role. That correlation is what separates a noisy anomaly from a workable incident hypothesis.

It also helps to define what is normal for each environment segment. A development box, jump host, and workstation will not produce the same baseline, so detections should compare behaviour against peer groups instead of using one threshold for the entire estate. That reduces false positives while making outliers stand out faster.

What to search for once you see a lead

Once a host looks suspicious, broaden the hunt from one machine to the surrounding footprint. Review nearby systems for the same process tree, the same script content or command line structure, the same persistence mechanism, and the same external destinations, then pivot to the user and service accounts involved to see whether the activity followed a credential path rather than a pure host compromise.

  • New or rare process chains, especially those that launch scripts, shells, loaders, or LOLBin-style execution paths.
  • Persistence created soon after first execution, such as startup mechanisms, scheduled tasks, services, or registry-based autorun behaviour.
  • Repeated external connections with similar timing, destination structure, or user-agent and protocol patterns.
  • Shared operator tooling, staging artefacts, or account use across multiple endpoints.

The most useful hunt queries are usually the ones that combine these elements, because they show whether the activity is isolated noise or a repeatable operator pattern. When the same account or same toolset appears across multiple hosts, the investigation should shift from endpoint cleanup to campaign scoping.

Risk and Threat Considerations

DealersChoice activity is risky because it can be mistaken for ordinary administration until the operator has already established persistence and repeated access. If teams separate endpoint alerts from network and identity signals, they may miss the fact that the same actor is moving through multiple systems with small variations in tooling.

Failure mechanism: The operator reuses a stable workflow, process lineage, and outbound communication pattern while rotating specific tools or hosts, which lets the activity evade single-rule detections and remain visible only when telemetry is correlated.

Impact: Missed correlation can delay containment, allow the operator to expand to additional systems, and leave related accounts, loaders, or staging infrastructure active long enough to support follow-on access or re-entry.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
MITRE ATT&CKT1059 — Command and Scripting InterpreterDealersChoice hunting depends on script and loader execution patterns.
T1053 — Scheduled Task/JobPersistence is a key part of the activity pattern described in the answer.
Recommendation — Map suspicious script execution to T1059 and expand hunting across related process chains. Check for scheduled-task persistence and correlate it with first-seen execution activity.
NIST CSF 2.0DE.CM-01 — Network MonitoringThe answer relies on correlating endpoint behaviour with command-and-control traffic.
DE.AE-03 — Anomalies and Events Are AnalyzedThe core detection method is analysis of correlated anomalies across telemetry sources.
ID.AM-01 — Physical Devices and Systems Are InventoriedCampaign scoping requires identifying where the same pattern appears across systems.
Recommendation — Continuously monitor network flows for repeated external connections tied to suspicious endpoints. Analyze correlated endpoint, network, and identity anomalies before declaring an incident. Maintain an accurate asset inventory so you can pivot from one host to similar systems fast.

Practitioner Guidance

What to prioritise: Build detections around behaviour clusters, not one-off indicators. A useful rule set should combine endpoint lineage, persistence, and repeated external connectivity, then pivot from the first alert to adjacent hosts and accounts that share the same pattern.

What to verify: Confirm whether the suspicious account, process tree, or connection pattern is normal for that host class. If it is not, check whether the same operator tools or staging artefacts appear elsewhere before deciding the activity is contained.

Practitioner takeaway: The best DealersChoice detections are correlation-led and hunt-led, not signature-led, because campaign consistency is often more reliable than any single malicious artefact.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org