For IR purposes, sometimes it might be nice to have a completely known-not-compromised collaboration environment for OOB communications with the rest of the IR team. I've been reading some alerts lately (https://us-cert.cisa.gov/ncas/alerts/aa20-283a) where the bad actors have been able to overrun the 365 / on-prem environments and the remediation is essentially a bare-metal recreation of the compromised forest with a tedious migration procedure. From the most recent alert:
If there is an observation of CVE-2020-1472 Netlogon activity or other indications of valid credential abuse detected, it should be assumed the APT actors have compromised AD administrative accounts, the AD forest should not be fully trusted, and, therefore, a new forest should be deployed. Existing hosts from the old compromised forest cannot be migrated in without being rebuilt and rejoined to the new domain, but migration may be done through “creative destruction,” wherein as endpoints in the legacy forest are decommissioned, new ones can be built in the new forest. This will need to be completed on on-premise as well as Azure-hosted AD instances.
Note that fully resetting an AD forest is difficult and complex; it is best done with the assistance of personnel who have successfully completed the task previously.
It is critical to perform a full password reset on all user and computer accounts in the AD forest. Use the following steps as a guide.
Kinda goes w/o saying that if they pwn your AD and internal assets, your collab platforms (most likely Teams / SharePoint) are potentially being monitored by the bad actors.
So this is where the idea came from... Come in with an offline USB drive with built-in drive encryption and launch a VHD from any machine you may have with Internet access and change your unrelated, uncompromised domain's external DNS records to point to the new collaboration server. (This can also be done through a Dynamic DNS service but I kinda like hand-touching the zone files for the location update.) Once online, utilize one of many open source clients to be able to communicate / collaborate securely w/in the compromised environment.
Elements of the OOB solution
Hardware: For this proof-of-concept, I picked up an IoDD Mini from Amazon. The main requirements were that it supported AES256 drive encryption and VHD support. (Yes, at this point, I'm trusting the Korean company didn't backdoor the encryption implementation somehow. So far, snooping the USB bus and watching pcaps, I haven't identified any weird traffic coming from the firmware but I reinstalled it when I received it just for fun.) There are other USB drive implementations out there but I liked the built-in VHD support and being able to flexibly access a virtual DVD iso and storage through the same USB connection / session.
Software:
Linux server: I decided to use a minimal Alpine Linux distribution and installed the Docker package from their community repository.
Collaboration server: I've had previous experience spinning up plain-jane XMPP servers like Jabber in the past but the collaboration and security features were usually either housed in the clients that were being used (e.g. - OTR encryption, peer-to-peer client communications) or contained in rarely implemented XEPs. So this time around I decided to try something different and picked Matrix.org's Synapse project. (https://github.com/matrix-org/synapse)
To create a VHD for the eventual server, I used VirtualBox and created a new Linux VM with VHD as the drive format and created that on the encrypted USB drive. (If you create a standard VDI instead of a VHD, that's not a problem since you can convert the VDI by using the command:
VBoxManage clonehd source.vdi target.vhd --format vhdClients: There are lots of options here but I've been using the web version from Element.io's web client. You can use others of your liking but the point being you can find a client to fit your needs. (Or roll your own...)
Procedure:
Plug in your USB drive, launch Virtualbox and create a new VM.
This will get the basic system installed in the VHD. The next installment will walk through the configuration of the Synapse server, testing clients, finalizing system configuration, and testing the VHD on an Internet-connected machine.