skip to content

Taking the Option Away

1 roadmap13 questions

Standing rights, permitted interpreters and protocols nobody retired are the options an intruder spends. Interviewers ask which move removes each, because the obvious move usually does not.

on this pageshow

explore

questions

13

What is the difference between disabling SMBv1 with a policy setting and uninstalling the feature?

level: juniorimportance: must knowfreq 65%

answer

  1. state versus capability
  2. the code is still on disk
  3. who is allowed to write that value
  4. one write versus reinstalling software
  5. some packages cannot be uninstalled

basics

~20 s

Disabling writes a configuration value while the SMBv1 code stays installed, so one administrative write turns it back on. Uninstalling removes the component itself, so there is nothing to re-enable until someone installs software again.

solid answer

~50 s

Disabling is a change of *state*: the optional feature is still installed, the service-manager entry is still there with a start type of disabled, the dialect is still implemented, and a single write by anyone holding administrative rights restores it. Uninstalling is a change of *capability*: the component is gone, so the same write does nothing and the machine has to have software installed again before the protocol can be spoken. That is why the two are not interchangeable in a hardening argument. Disabling is still worth doing - it takes the option away from every position below administrator, which is most of what reaches a host - but it is a revocable configuration, and against someone who already holds that privilege it buys very little. Some things cannot be removed at all: NTLM ships as a security package you can refuse by policy but not uninstall, so there the revocable state is the only option available.

go deeper

for a junior

Be ready to say plainly that disabling leaves the software installed and removal does not, and that re-enabling a disabled feature is a single configuration change.

for a middle

Explain what is actually left behind - the service-manager entry with a disabled start type, the binaries, the dialect still implemented - and who is allowed to write the setting back.

for a senior

Show that you classify the two differently when hardening: removal takes a capability out of reach of a single write, and you know which protocols offer no removal option at all.

for a principal

Own the consequence for standards: a hardening item written as a setting is a promise about configuration, and configuration is revocable by every administrator, every vendor engineer and every future policy edit.

## The distinction in one line Disabling changes **how the machine is configured**. Removing changes **what the machine can do**. Everything else follows from that. ## What 'disabled' actually leaves behind Take SMBv1 on a Windows host. Turning it off through a policy setting or a configuration value does all of this and no more: - the optional feature that provides SMBv1 is **still installed** - the driver and the server-side responder are on disk; - the service-manager entry is **still present**, with a start type set to disabled rather than absent; - the dialect is **still implemented** by the code that is running the rest of the file-sharing stack; - the setting itself is a value that the administrator role is allowed to write. So the honest description of a disabled protocol is: *the capability exists and is currently declined*. That is a real and useful state - but it is a state, and states are reversible by whoever owns the write. ## What 'removed' means Uninstalling the optional feature takes the responder and its supporting code off the host. Now the same configuration write that would have re-enabled it has nothing to act on. Restoring the capability is no longer a value change; it is a software installation, which needs the package, usually needs a reboot, and is a different kind of act from flipping a setting. That is the whole security value of removal: it moves the capability out of the set of things a single write can restore. ## Why interviewers ask this The wrong answer they are listening for is *'the group policy disables it, so it is gone from the estate.'* It is a comfortable answer because the reporting looks identical - the protocol is not in use either way. But the two states behave completely differently under pressure: | | Disabled | Removed | |---|---|---| | Component on disk | present | absent | | Restore cost for an administrator | one value write | install software, usually reboot | | Survives someone with delegated administration | no | not without a deliberate install | | Survives a badly scoped policy change | no | yes | | Available for every protocol | yes | **no** | That last row matters. Removal is not always on the menu. NTLM is the standard counter-example: it is a security package that ships with the operating system and cannot be uninstalled. You can restrict it, refuse it, and force the negotiation to prefer something else, but the package stays installed. Where removal is unavailable, the revocable configuration *is* the control, and the people who can rewrite it become part of the control's boundary. ## Do not over-swing Candidates who have just learned this distinction often go too far and say disabling is worthless. It is not. A disabled dialect is unavailable to every unauthenticated party on the segment, to every user without administrative rights, and to any process that has not already won that privilege. That covers most of the ways a host is approached. The correct framing is narrower and more useful: **a configuration setting is not a control against a position that already holds the privilege the setting lives inside.** There is also a non-malicious version of the same failure, and it is more common than the malicious one. A vendor's field engineer with delegated administration on a print or scanning fleet finds a device that stopped working, turns the legacy dialect back on because that is what makes the device work, and moves on. Nothing about that act is an attack, and mechanically it is the same act. Removal survives it; a setting does not. ## What a good answer sounds like Name the three things: the component is still installed, the setting is a writable state, and the write is inside the administrator's envelope. Then say what removal changes - the restore is now an installation, not a value. Then add the honest caveat that some capabilities cannot be removed, only refused, and that for those the question becomes who holds the privilege that can undo the refusal.

  • So is disabling pointless?
    No. A disabled dialect is unavailable to every unauthenticated party on the segment and to every account without administrative rights, which is most of what reaches a host. The narrower claim is the true one: a setting is not a control against a position that already holds the privilege the setting lives inside.
  • Name a case where removal is simply not available.
    NTLM. It is a security package that ships with Windows and cannot be uninstalled; you can restrict or refuse it by policy, but the package stays installed and the refusal is a writable state. Where that is the situation, the population holding administrative rights is part of the control, not an afterthought.
  • What does a disabled service look like on the host itself?
    The service-manager entry is present with a start type of disabled, and the executable or driver it points at is still on disk. Absent is a different thing: no entry at all and no file behind it. An answer that treats those two as the same state has missed the question.

Disabling is closing a tap you left plumbed in; removal is taking the pipe out of the wall. Both stop the water today, but only one of them survives someone arriving with a wrench.

saying these in an interview costs you the question

  • Says a group policy setting removes the protocol from the estate
  • Treats a disabled service as absent from the host
  • Thinks an uninstalled feature can be brought back by a setting
  • Claims disabling is worthless because an administrator can undo it
  • Assumes every protocol can be uninstalled if you try hard enough

context

resolving links…

open as a page

What does an application-control rule naming a path, publisher or hash actually evaluate?

level: juniorimportance: must knowfreq 62%

basics

~20 s

It evaluates the identity of a file at the moment something tries to load and run it: where the file sits, who signed it, or its exact bytes. It says nothing about what an already-permitted program is later handed.

open as a page

One local administrator password is identical on 4,000 laptops - what does that hand an intruder?

level: juniorimportance: must knowfreq 70%

basics

~20 s

One shared password turns a single compromised laptop into administrator on all 4,000: code already running as admin on one host reuses that secret to authenticate everywhere else. No exploit, nothing for a patch to fix.

open as a page

Why won't publisher or hash rules stop a script run by an already-allowlisted signed script host?

level: middleimportance: must knowfreq 58%

basics

~20 s

No new file is presented, so no rule is consulted. Path, publisher and hash rules all answer one question - may this file run - and the script host is an approved, correctly signed file. The script is just an argument.

open as a page

After removing local administrator rights from all users, which standing privileges still let an intruder move?

level: middleimportance: must knowfreq 58%

basics

~20 s

Three untouched preconditions: the built-in administrator secret that every host in the fleet still accepts, privileged accounts that sign in to low-trust machines, and privileged group memberships held permanently rather than on request. Removing user-level admin addresses none of them.

open as a page

NTLM is refused by policy: what has that taken from an intruder who already holds local administrator?

level: middleimportance: should knowfreq 50%

basics

~20 s

Almost nothing durable. The refusal is a configuration value that the administrator role is allowed to write, and the security package is still installed, so the capability sits inside the privilege the intruder already holds.

open as a page

What does time-bound, approval-gated elevation actually remove from an intruder's options?

level: middleimportance: should knowfreq 44%

basics

~20 s

Time-bound elevation removes permanent membership as a target: an account compromised at a random moment holds no active privilege, and using it needs a request and an approver. It does not touch privilege already active, and bounds when, not where.

open as a page

An SMBv1 session fails against every host you try - does that prove the feature is removed?

level: seniorimportance: should knowfreq 42%

basics

~10 s

No. A refused negotiation shows the dialect was declined by the hosts you reached, at that moment. Disabled and removed look identical from the client side, so the failure cannot tell them apart.

open as a page

Why is 'application control blocked it' the wrong reading when a foothold under publisher rules never progressed?

level: seniorimportance: should knowfreq 45%

basics

~20 s

A deny only happens when a new file is presented. If the operator's next move was handing text to a permitted interpreter, the rule set was never consulted, so nothing was blocked. The foothold more likely stopped for economic reasons.

open as a page

A domain administrator signs in to a user's laptop to fix a ticket - why does tiering forbid it?

level: seniorimportance: should knowfreq 52%

basics

~20 s

The laptop's administrator sits inside the boundary of that logon - the machine must be able to act for the account, so an intruder who already owns the laptop gains whatever that credential reaches. Tiering is a direction rule.

open as a page

The service-desk manager says per-host admin passwords will wreck handle time - how do you land the change?

level: principalimportance: should knowfreq 34%

basics

~20 s

Treat the objection as a cost to fund, not a blocker to overrule. Pay for password retrieval inside the console his engineers already use, sequence the invisible removals first, and commit to a measured handle-time threshold with a real rollback.

open as a page

On a Linux jump host that only executes signed files, why does a user-shell foothold barely feel it?

level: middleimportance: nice to knowfreq 32%

basics

~20 s

Because the permitted interpreter is the shell itself. Signature enforcement judges files at execution; a shell script is text the already-approved shell reads, so the payload never becomes a file that is checked. The generality stays.

open as a page

One scanner fleet keeps SMBv1 alive for 600 hosts - how do you actually retire the protocol?

level: principalimportance: nice to knowfreq 33%

basics

~20 s

Treat it as a capital replacement, not a security change. Find the one remaining consumer, upgrade or replace it against the budget that owns the device, attach an owner and a date, and scope the exception to that device meanwhile.

open as a page