Hacktool Detected on Endpoint [CHK-3031]

Rationale

The defining characteristic of this category is that the tools are genuinely dual-use. The same port scanner that a penetration tester runs during an authorised assessment is the one an attacker runs after gaining a foothold. Unlike ransomware or a web shell, the presence of the tool does not by itself establish intent.

What makes it worth reporting is context. These tools are not installed by accident and are rarely part of a standard workstation build. Their presence means someone deliberately put them there, and the question is who, and why. A member of your IT team testing something is an entirely different situation from the same tool appearing on a finance workstation at three in the morning.

Attackers favour this category precisely because of its ambiguity. Tooling that a defender might plausibly have installed generates hesitation, and hesitation buys time. The account, the device and the timing are what resolve it.

Follow-up

Follow these steps to adequately address this detection:

1. Identify the tool and who put it there. The ticket names the tool Defender recognised. Establish which account installed or ran it, on which device, and when.
2. Establish whether the use is sanctioned. Ask the account owner directly, and check for any authorised assessment, IT project or troubleshooting activity covering that window.
   • If no (not sanctioned): Treat the account and device as compromised:
     1. Isolate the device in Microsoft Defender and preserve it for investigation.
     2. Reset the password and revoke sessions for the account involved, and for other accounts that signed in to the device.
     3. Determine what the tool is capable of and investigate accordingly: a credential tool means rotating credentials, a scanner means checking what it reached, an exploitation framework means looking for a successful compromise elsewhere.
     4. Review activity from that device before and after the detection, looking for lateral movement, privilege escalation and outbound transfers.
     5. Escalate to IR if the device is a server, the account is privileged, or you find evidence the tool was used rather than merely present.
   • If yes (sanctioned): Confirm and reduce the ambiguity for next time:
     1. Verify the person, purpose, scope and time window.
     2. Move the activity onto dedicated equipment. Offensive tooling belongs on a designated testing machine with a named account, not on a general-purpose workstation. This makes future detections meaningful instead of routine.
     3. Record the confirmation on the ticket, and tell Attic if the tool will be used regularly so the expected pattern is known.
3. Consider whether the tool should have been installable at all. Repeated detections in this category on ordinary workstations point to an application control gap. Restricting what can execute removes the ambiguity at the source.

More information

• Microsoft Learn: Investigate incidents in Microsoft Defender XDR
• Microsoft Learn: Application Control for Windows
• Microsoft Learn: Attack surface reduction rules reference
• MITRE ATT&CK: T1588.002 - Obtain Capabilities: Tool
• MITRE ATT&CK: T1046 - Network Service Discovery