How can security teams detect TDTESS?

What TDTESS detection looks like in telemetry

The most reliable detections come from correlating process behaviour, file activity, and network activity instead of looking for a single indicator. Trusted applications that inject into other processes, load unexpected DLLs, or spawn odd child processes often provide the earliest signal. That is especially true when the sequence begins with execution from temporary paths or a user profile and is followed by persistence or outbound connections.

A useful analyst pattern is to start with endpoint telemetry that preserves parent-child process trees, module loads, and file-write context. Then look for combinations that are unusual for the host, such as a signed or normal business application suddenly creating autoruns, writing to startup locations, or launching scripting and living-off-the-land binaries. Those patterns are more actionable than isolated alerts because they show behaviour, not just presence.

When that behaviour shows up repeatedly, it is worth comparing it against a known-good baseline for the same host role. Baselines help separate legitimate administrative tooling from abuse, especially when an attacker tries to blend in by using a common application as the launch point. For broader malware detection tradecraft, the Malware Guide is a useful reference for loaders, evasion, and analysis patterns that map well to this sort of investigation.

Which behaviours most often expose the infection chain

The most important clue is sequence. A dropper or loader may write files to a temporary or user-writable location, execute them, then immediately create a process injection event or spawn a child process that does not fit the parent application’s normal behaviour. If the next step is persistence, such as a new autorun entry or scheduled task, you are usually looking at a more mature intrusion rather than a one-off crash or installer artifact.

Unusual DLL loading is especially valuable when the DLL is loaded from an unexpected path, has an odd name, or appears only after a trusted application starts. That can indicate side-loading, search-order abuse, or a loader chain that uses legitimate software as the execution vehicle. Network connections that start soon after execution, especially to new external endpoints or rare destinations for that asset, strengthen the case that the activity is malicious and not routine software behaviour.

Endpoint and network logs should be reviewed together because one source of telemetry is often ambiguous on its own. A process tree may show only a benign application name, while module loads and connections reveal the actual payload delivery or command-and-control stage. Detection quality improves when analysts can connect the first execution, the first write, the first suspicious child process, and the first post-execution network beacon in one timeline.

How to separate suspicious activity from normal administration

The practical test is whether the observed behaviour is normal for that host, user, and application version. If a business application regularly launches child processes, loads plugins, or touches startup locations, those actions may be benign. If the same pattern appears on a workstation that never uses that software in that way, the burden of proof shifts to the defender to explain it as expected behaviour.

Use allowlists and baselines carefully. They are most effective when they are scoped to known software, known paths, and known parent-child relationships rather than broad process names alone. Otherwise, an attacker can hide inside a legitimate executable name or a familiar vendor process while still using malicious child processes, injected memory, or alternate DLL paths. That is why detection should key on the full execution context, not just on reputation.

Reviewing privilege changes during the same time window is also important. If the suspected activity is accompanied by new service creation, token abuse, or attempts to elevate rights, treat the case as more than simple malware execution. Those follow-on actions often reveal whether the actor was trying to persist, move laterally, or widen access after initial execution.

Risk and Threat Considerations

TDTESS-style activity is risky because it often uses trusted processes to hide malicious execution, which can delay detection and let the payload survive long enough to establish persistence or expand access. The same technique can also reduce the value of signature-only monitoring if defenders never connect the injected process, the suspicious DLL, and the follow-on child process into one event chain.

Failure mechanism: The attacker abuses a legitimate process as the launch point, then uses injection, side-loaded libraries, or anomalous child processes to shift execution into a less visible path. If the environment does not correlate process, module, file, and network telemetry, the intrusion can look like ordinary application behaviour.

Impact: Missed detection can leave the operator with persistent access, credential exposure, and broader opportunity for privilege escalation or lateral movement. The longer that trusted software continues to host the malicious activity, the harder it becomes to distinguish compromise from normal operations.

Practitioner Guidance

What to verify: Confirm whether the suspicious process tree, DLL path, and child-process pattern are expected for that exact host role and software build. If the behaviour is new, rare, or path-dependent, treat it as higher priority than a lone alert on the parent executable.

Decision rule: If you can tie the event to temporary-path execution plus persistence or outbound beaconing, escalate to incident handling rather than treating it as routine malware triage. If only one signal exists, keep investigating, but do not overstate confidence until the full chain is visible.

Practitioner takeaway: The best detections come from stitching together execution, module loading, persistence, and network timing, because trusted-process abuse is rarely obvious in any single log source.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?