Why step-up MFA is the wrong response to credential-theft tools in a privileged session

Most session-control products respond to a risky command the same way: pause, ask for another MFA prompt, continue if the user passes.

For many commands that is reasonable. A destructive command in the wrong directory is usually a mistake by someone who is allowed to be there. A second factor confirms the person, and the person can explain.

For credential-theft tooling it is the wrong control. The question is not "is this really you?". It is "why is a credential-dumping tool being used in a production session at all?". A valid second factor does not answer that. It confirms that the right person, or the right person's stolen session, is about to dump credentials.

What changed in zenxPAM

Command analysis now recognises known credential-theft tooling and treats it as a hard session block. The session is disconnected. It does not get a step-up prompt, and it does not just raise an alert for someone to read later.

The order of checks is the point:

command in session
      │
      ▼
 hard-block check ── known credential-theft tooling ──► terminate session
      │ no match
      ▼
 risk scoring ──► step-up MFA / alert / allow

The hard-block check runs before the step-up MFA gate, so a credential-theft tool never reaches a prompt that a stolen session could pass. The threat response is chosen from the reason for the decision: a hard block maps to ending the session, rather than to the alert-the-security-team or step-up responses used for ordinary risk. Further commands from a session that has already been terminated are refused as well, so a blocked session cannot keep sending input in the gap before the disconnect lands.

An operator who understands what happened

When a session ends because of a policy block, the viewer shows Session Blocked, not the generic "terminated by an administrator" message. It sounds minor. An operator who sees "terminated by an administrator" phones the admin. One who sees "Session Blocked" with the policy reason knows what happened, and the audit record says the same thing.

A deliberate trade-off

Some administrative tools have legitimate uses, and a hard block will occasionally end a session that was doing honest work. That is a deliberate choice for a privileged-access product. The expectation is that the approved request scope already covers what the operator needs. If a team's work genuinely requires such a tool, the answer is a narrower, explicit approved scope for that task, not a softer default for everyone.

Why this is the right default

Every control in a PAM system is a statement about what you believe an approved session is for. If an approval says "restart the billing service", credential-theft tooling is outside that statement under any identity. Treating it as a question to be answered with another MFA tap invites the wrong conclusion, that the only problem is whether the person is who they say they are.

It also sits alongside, not instead of, the other layers: intent-scoped access, approved-application controls on the session host, and endpoint protection on the target.

If you run privileged sessions through a gateway, ask one question of your platform: what happens when a session uses credential-theft tooling? A prompt is a policy decision. A shrug is a gap.

See how zenxPAM enforces intent-scoped, just-in-time privileged sessions: https://zenxsys.com