0

we are downsizing our organization and closing several stores. This may sound malicious but actually involves complete remote data destruction for company equipment. My team has been tasked with remote destruction of all data, including the windows 7 operating systems so nothing at all is recoverable. I have full administrative access throughout the infrastructure. There are hundreds of remote registers across many geographical locations, site visits, degaussing, and remote hands are not feasible solutions. It must be a remote deployment, remote scripting is fine. The legal department wants all data destroyed including the windows 7 operating systems before having 3rd parties send the computers back to HQ. I don't want to simply delete data or the operating system (removing windows .dll's or databases) as that data is still recoverable. I don't want to lockout the computer as the drive can be removed and added to a working computer to recover data as well. I need to brick this equipment. We can certainly pay for tools but would rather use some remote fdisk or maybe powershell. Afterwards I can script the removal of leaf objects from active directory.

Daniel
  • 6,940
  • 6
  • 33
  • 64
Eric Goldenberg
  • 1
  • Tricky. Do you have SCCM or another similar deployment solution? Might be possible to put something together that way. In principle all you would need is the Microsoft Deployment Toolkit (in order to build a Windows PE image you can boot from to do the disk wipe) but if you don't already have experience it is likely to be an uphill battle. – Harry Johnston Aug 13 '19 at 21:21
  • Thanks for that. SCCM does seem very robust and would be a great tool and I'll keep that in mind for future endeavors, however, we don't have the time right now to deploy. Looking for something down and dirty as stores are closing this week. Thanks again. – Eric Goldenberg Aug 14 '19 at 16:12
  • 1
    You need to start your hardware from PXE, if you want to do it remotely. There is no other way to clean your hard drive, if the processes are running from the very same disk. – Daniel Aug 14 '19 at 21:32
  • I'd almost tell you to add your favorite ransomware EXE to your preferred auto-start mechanism (legacy Run, Startup program group, GPO Startup Script, etc) and let 'er rip, but it would leave the OS unscathed. I suppose somebody could pay the ransom, too. There's something romantic about the idea of using filth like that for an actual useful purpose, though. – Evan Anderson Aug 14 '19 at 22:11
  • I don't understand the reason for wanting the OS destroyed, but that's more difficult and less sensitive data, how about doing one pass with a normal script which finds and erases the main data with something like [eraser](https://eraser.heidi.ie/download/), then if the OS wipe goes wrong at least your most important data will be scrubbed. Consider if there's enough free space to erase empty space, shrink disk partition a GB or two, put a small OS there to boot to and use that to remote into and erase the original partition. No USB or PXE, and a chance for a second try if it isn't right. – TessellatingHeckler Aug 14 '19 at 23:11
  • I do not have physical access to change the BIOS or attach a USB. I can however create an OU, move the leaf objects over, then apply a policy but I believe the issue is I can't find any tools that will destroy the boot partition while it is active and running. – Eric Goldenberg Aug 15 '19 at 15:30
  • You need a "professional" eraser (specially if you have SSD drives) booted from PXE from every location. i.e. you can use Serva as PXE Server and Blancco Eraser – Pat Aug 30 '19 at 15:30

2 Answers2

1

Short than PXE booting or using USB with a special Linux distribution to destroy the data on the drives, the best option that comes to my mind would be encrypting all the drives with BitLocker or another Full Disk encryption tool and then discard the keys used to unlock those drives.

Andre de Miranda
  • 332
  • 2
  • 8
  • Bitlocker isn't available without Windows 7 Ultimate or Enterprise. It's unlikely these machines would have either of those licenses being used in the capacity the OP describes. – Evan Anderson Aug 14 '19 at 21:54
  • I believe PXE boot requires onsite BIOS access and USB also requires onsite access. These locations are now closed but the registers are online. I was able to drop the DB's with sqlcmd and psexec to remove customer information. Thank you. – Eric Goldenberg Aug 15 '19 at 15:25
  • TBH, it depends on the settings of your machines. If machines boot sequence is configured to HDD, USB, CDROM, Network, then you can launch PXE via DHCP. Without an environment to validate the environment your action to drop the DB may be the best choice. Make sure you clean the empty space of your drives using a secure erasing tool. Windows ships one out of the box `cipher /w:C` (where C is the drive you are cleaning – Andre de Miranda Aug 17 '19 at 12:13
1

This actually sounds like "hella fun" to put together (and I'd almost offer to do it for you), but it's really not a good idea. Remotely verifying that the wipe actually worked is tenuous, at best. Without physical custody of the equipment you're taking chances. It would be better to hire a local computer recycler who will give you a contractual guarantee that the drives have been wiped, or ship the drives back to you.

Having said that let's get to the fun.

PXE or USB-booting the machines, as others have suggested, would make it simpler, but it's not impossible to do otherwise. All you need to do is remotely install another operating system. That's easier w/ something like SCCM, but you can do it yourself w/ scripting too.

I'd start by building a customized hard drive-based installation of the SystemRescueCD Linux distro. It already has the nwipe disk eraser included. You just need to script it to fire-up and run automatically when SystemRescueCD boots.

I'd also add some bits to "phone home" to a central server to upload a post-wipe report containing the computer's serial number, hard disk serial number, MAC address, etc, and the output of the "nwipe" command. It probably makes sense to check-in with the server first and, if it's unreachable, boot back into the stock Windows environment. That way you're not wiping machines w/o producing some record. It would also make sense to check for a "Hey, don't start wiping yet" flag on the central server that causes the machines to "phone home" but boot back into Windows normally. This way you could verify successful deployments before "pressing the button".

All that's left after that is copious testing and scripting the installation as a Startup Script to assign via Group Policy or run remotely via something like PSExec. I'd take the Startup Script route, personally. Put the PC in the right OU or AD group and it gets a virtual shotgun strapped to its forehead!

A lot of this is, admittedly, left as an exercise to the reader. Nobody should actually build this thing. It would be a lot of fun to make this scary "network self destruct system", but you can imagine all kinds of awful malicious uses for this thing. Replace "nwipe" with an encryption tool and you've got ransomware. It's probably not a good idea to make a "Playschool's My First Destroy an Entire Enterprise's Desktop PC Infrastructure" tool.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331