At a logistics hub, fileless malware is running inside a script host whose file hash matches the vendor signed binary. Which endpoint approach can still see that activity?
Select an answer to reveal the explanation.
Short Explanation
Judging a borrowed pen by the logo on the barrel misses what the pen just wrote. At your logistics hub, fileless code inside a vendor-signed script host still shows up when behavior or host rules watch that process. A clean hash, a web category, or a copy session you never started will not.
Full Explanation
Fileless malware borrows a trusted script host. The file on disk is the vendor binary, so its hash matches the vendor hash and a known-bad file list stays quiet. What changes is what that process does: the command line, the parent, the children, or the connections. Endpoint detection that watches those actions can still see it. Behavior or host intrusion rules on what the script host does, rather than the signed binary hash alone. Trusting the hash is the miss. A hash match against the signed script host, treated as clean whenever the only hash present is the vendor hash is exactly the check the malware is designed to pass. A URL label does not watch the process. A web-category decision that classifies one URL and does not inspect the script-host process itself might describe a site the host contacted later, and it is not an endpoint view of the script actions. A copy that was never taken cannot help either. A SPAN session that was not started, leaving the hub with no saved copy of the related traffic collected nothing, and a traffic copy would still not be the endpoint approach the question asks for. Exam caveat: a vendor hash on a signed script host is normal. Detection has to key off behavior of that trusted process, and a quiet hash is not a clean bill of health. Operational check: read the script host command line and parent process in the endpoint telemetry even though the binary hash matches the vendor.