10

I need to remotely perform a kill-switch on a Windows 7 Enterprise computer connected to an AD. Specifically, I need to

  • remotely access the machine without visible user interaction (I have a domain account which is administrator on the machine)
  • make it so that the machine is not usable (crashes/reboots and does not boot back)
  • preserve the contents of the machine (be able to document what was changed)

The machine must be damaged enough that basic+ troubleshooting fails and requires it to be brought to a company help desk.

In order to anticipate comments: I understand that this sounds shady but this action is required, authorized and legal - within a corporate environment.

Coming from a Unix background, I do not know what is feasible remotely on a Windows machine. Ideally (and again, with a unix background in mind) I would be looking at actions like

  • erasing the MBR and forcing a reboot
  • removing key .dlls which would not be automatically recovered during a safe boot

EDIT following comments: this is a very specific forensics case which needs to be handled via this convoluted way.

  • 4
    While I haven't downvoted, this look a bit shady. Wouldn't it be easier to just go there and grab the computer? – MichelZ Nov 27 '15 at 9:13
  • 3
    You didn't describe the circumstances that led you to try something like this, which may have led to your downvote. I can imagine a few things which could justify somehting like this, but if you actually describe the situation, you may get better answers. – Michael Hampton Nov 27 '15 at 9:24
  • 6
    If this is a forensics case, I strongly advise you against doing anything different than physically going there and picking up the machine. Everything else is bound to invalidate any legal proof that could came from it. – Massimo Nov 27 '15 at 12:13
  • 2
    @frupfrup: nobody is freaking out here; but I honestly think that, even if you really want to go "let's make the system unusable", trying to delete C:\Windows is only going to make a mess, possibly without even reaching the stated goal; blocking the boot manager is much safer, it's undoable, and will leave the actual O.S. untouched (thus allowing forensics analysis). – Massimo Nov 27 '15 at 14:58
  • 2
11

You don't need to actually destroy the machine; just force it to shut down and lock out the user.

  • Run shutdown /m <machinename> /f /t 0 to force a computer shutdown.
  • Disable the Active Directory user account for the user.
  • Disable the Active Directory user account for the computer.

Just make sure to shut down the computer before disabling its account, otherwise you will be locked out from remote management because it will no longer be able to authenticate anyone against the domain, including yourself.

If the user also has a local user account on the target computer, you can disable it before performing the above steps; you can do so by starting the Computer Management MMC on any other computer as a domain administrator and connecting it remotely to the computer you want to manage; from there, you can also take any other necessary steps to make sure nobody can log in to the machine using local user accounts (such as disabling them or changing their passwords).


Side note: if this is for legal/compliance issues, this is a very strong reason to not change or delete anything on the machine; otherwise the user could later say (perhaps correctly) the machine has been tampered with; also, if you delete anything on the filesystem, you could lose valuable data (who can tell if the user has stored personal files or applications in system folders?).

  • That is totally correct and a much better way. But the OP said, that the user should take no notice... if he could not log in any more he would take notice... Most users would then call the helpdesk and tell them to unlock their account... – frupfrup Nov 27 '15 at 9:52
  • 1
    If the machine abruptly crashes, the user is definitely going to notice anyway... – Massimo Nov 27 '15 at 9:53
  • Can it prevent e.g. the user boot from USB and add a local administrator account? (I know nothing about Active Directory) – jingyu9575 Nov 27 '15 at 15:27
  • 2
    @jingyu9575 If the user is tech-savvy enough to edit an offline user database, he'd probably reinstall Windows on his own instead of taking the machine to the help desk. What exactly are we trying to accomplish here?!? – Massimo Nov 27 '15 at 15:55
  • These changes don't actually do it. All they have to do is boot w/o plugging in the network cable. – joshudson Nov 27 '15 at 17:46
4

As I already said several times, if this is a forensics case I strongly advise you against doing anything different than physically going there and picking up the machine; tampering with it in any way is bound to invalidate any legal proof that could come from it.


That said, there are several ways to render a machine unbootable while damaging it as little as possible, depending on how the system is actually installed (the main differences being if the system is BIOS- or UEFI-based and if a boot partition is used vs. the boot files being stored on the system partition); here are some options:

  • Delete the contents of the boot partition and/or UEFI partition (usually hidden but you can mount it); or delete the boot files from the system partition, if no boot partition is in use.
  • Delete the file C:\bootmgr.
  • Alter the boot manager configuration using bcdedit.exe.
  • Alter the partition table to not have an active partition.

And so on; messing with the boot manager is usually the best way to render a system unbootable, while not actually damaging it. But since modern Windows systems have several possible boot pathways, there isn't an universal approach (f.e. a UEFI system doesn't rely on the MBR at all and just doesn't care about the active partition, if any).

If you limit your intervention to boot files, the actual system will be untouched, and you will be able to recover all its contents (and even to boot it again if you undo the damage).

3

A few questions:

  • Is there any reason you need to go a destructive route?

If yes, go with @frupfrup's answer.

  • Does the user only have a domain logon, or do they have a local login as well?
  • How quick does this need to take effect?

Another thing you could do is cause a generic active directory login error. First disable cached logins on that machine, then disable or delete the computer account in active directory. To make it look like the computer had a fit, you could do a simple get-process | stop-process -force in a remote powershell session. Or even taskkill /im csrss.exe /f in a remote command prompt, using psexec or similar.

When it "crashes" then reboots and the user tries to log in, he should get a somewhat generic "This computer could not be authenticated against the domain" type of error, IIRC. I would test all of this on something first; The authentication problem may not take effect right away, or windows may be smart enough to prevent you from running those commands.

1

There are a great many deal of things you can do to prevent the user from using the computer.

However, none of them will go unnoticed by the user since all of them will cause him to call the Help Desk. Whether that is making the device non-bootable, disabling his account, disabling the Computer Account in the AD or all of the above.

We have similar issues when remote users fail to comply and return a laptop which was replaced but they continue to use it (out of laziness). However, in our case it's very simple since we are not trying to do any forensics. Remote into the computer, delete the Local User's account, remove from Domain and Delete the Computer from AD. Viola the user can no longer user and we haven't totally made the laptop useless.

I honestly do not know of a way of making a computer useless to a user without them knowing and/or having them call the Help Desk to get it operational, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.