Haxoris Wiki

Unencrypted Data At Rest And Backups

How Unencrypted Data At Rest And Backups works

Disks, volumes, VM images and backup media hold data with no encryption, so physical or storage-level access reads everything without an account. In a typical estate the gaps are uneven rather than total: laptops are encrypted because a project mandated it, while server system and data volumes are not, on the argument that the rack is in a locked room. NAS volumes holding finance and HR shares are plaintext, virtual machine disks sit on a datastore with no encryption, snapshots and exports accumulate on a staging volume, and the backup repository - the one place holding a copy of every other system - is written unencrypted so that restores stay fast.

The attacker does not need a session. A removed drive, a decommissioned server on a pallet, a stolen laptop, a copied VMDK or a tape in a courier bag yields filesystems, databases, credential stores and configuration files intact, with no authentication and no logging on the source system. It is easy to miss because encryption at rest is asserted rather than measured: the policy says full-disk encryption, the build image enables it, and nobody runs the report that shows the twelve servers where it was suspended for a firmware update and never resumed. Who can reach the backup console and the hypervisor in the first place belongs to the Backup And Hypervisor Administrative Access page, and share permissions on the plaintext volumes belong to the Overly Permissive File Shares page.

Unencrypted Data At Rest And Backups in practice

Report encryption state on Windows endpoints and servers

Assertions are not evidence. Produce a per-volume state table for the whole estate, including which protector is in use and whether a recovery key is escrowed.

# local view: every fixed volume, its protection state and protector types
Get-BitLockerVolume | Select-Object MountPoint, VolumeType, ProtectionStatus,
  EncryptionMethod, EncryptionPercentage,
  @{n='Protectors';e={ ($_.KeyProtector.KeyProtectorType) -join ',' }}

# estate view, read-only, from a management host
$targets = Get-Content C:\audit\hosts.txt    # srv01.lab.internal, wks14.lab.internal ...
Invoke-Command -ComputerName $targets -ScriptBlock {
  Get-BitLockerVolume | Select-Object @{n='Host';e={$env:COMPUTERNAME}}, MountPoint,
    ProtectionStatus, EncryptionMethod,
    @{n='Protectors';e={ ($_.KeyProtector.KeyProtectorType) -join ',' }}
} | Export-Csv C:\audit\bitlocker-state.csv -NoTypeInformation

# is a recovery password actually present to escrow?
manage-bde -protectors -get C: -type RecoveryPassword

ProtectionStatus 0, EncryptionMethod None, or a volume in a suspended state are findings. TpmPin as the only protector on a laptop is stronger than Tpm alone; note the difference rather than passing both.

Check Linux, macOS and NAS volumes

The same question, asked of everything the Windows agent does not see. Keep it to read-only status queries.

# Linux: which block devices are backed by dm-crypt, and which are not
lsblk -o NAME,FSTYPE,TYPE,SIZE,MOUNTPOINT
sudo cryptsetup status /dev/mapper/vg0-root 2>/dev/null \
  || echo "no LUKS mapping for vg0-root - plaintext volume"
sudo cryptsetup luksDump /dev/sda3 2>/dev/null | grep -E 'Version|Cipher|PBKDF'

# macOS: FileVault state and who can unlock the volume
fdesetup status
fdesetup list

# NAS or appliance: mounted filesystems and any crypto layer, read-only over SSH
ssh audit@nas01.lab.internal "df -hT; mount | grep -Ei 'crypt|ecryptfs' || echo 'no crypto layer'"

An FSTYPE of crypto_LUKS is protection. An ext4 or xfs volume mounted straight from the partition is not.

Prove the exposure by reading a volume offline

One demonstration is enough to settle the argument with an asset owner. Do it on lab hardware, never by imaging a production laptop.

Handling rule: the state report from the previous steps is already the
finding. Imaging a production disk to prove it creates a second
unencrypted copy of the same data, so run this on a lab host with a
disk you own and destroy the media afterwards.

1. Boot the lab host from live media with networking disabled.
2. lsblk -f
     sda1  vfat                    EFI
     sda2  ext4        root        no crypto_LUKS type present
3. sudo mount -o ro /dev/sda2 /mnt
4. ls /mnt/etc/shadow /mnt/root/.ssh /mnt/var/lib/                readable

Decision table:
  crypto_LUKS or BitLocker signature present   mount refused, key prompt
  filesystem type present, mount succeeds      plaintext at rest, finding

The same test applied to a disk pulled from the disposal cage is the
Insecure Media Disposal And Decommissioning page, not this one.

Audit backup repositories, datastores and media

The backup repository concentrates every other system’s data, so it is the highest-value instance of this weakness and usually the least examined.

# what the backup share exposes, read-only listing with an audit account
smbclient -L //backup01.lab.internal -U 'LAB\audit'
smbclient //backup01.lab.internal/repo -U 'LAB\audit' -c 'ls; q'

# is repository content encrypted, or readable as it sits?
file /mnt/repo/*.vbk /mnt/repo/*.vmdk /mnt/repo/*.tar
strings -n 12 /mnt/repo/fileserver-full.vbk | head -40

# hypervisor: datastore contents and whether disks are encrypted
ssh root@esx01.lab.internal 'esxcli storage filesystem list; vim-cmd vmsvc/getallvms'

Hostnames, user names, share paths or document text appearing in the strings output means the repository is plaintext. Pair that with the offsite media inventory: any tape or rotation disk leaving the site unencrypted is the same finding with a courier added.

How to fix and prevent Unencrypted Data At Rest And Backups

  1. Encrypt every endpoint and server system volume, then measure it
    • BitLocker with TPM plus PIN or network unlock, LUKS2, FileVault, enabled by the build image and reported daily rather than assumed.
    • TPM-only protects a removed drive; it does not protect a machine an attacker can boot, so treat pre-boot authentication as the target state for portable devices.
  2. Escrow the recovery keys and test a restore of one
    • Keys in the directory, MDM or a key management service, with an owner. An encrypted volume whose key exists only on the machine is a future outage, not a control.
  3. Encrypt data volumes and virtual machine storage
    • Array, datastore or NAS volume encryption for shares, databases and VM disks.
    • Partial control: it protects removed drives and copied images, not a live host with the volume mounted, which is why access management still carries the rest of the risk.
  4. Encrypt backups with keys held outside the backup platform
    • So a compromised backup server or a stolen tape is not a full-estate disclosure, and rotate the keys on the same schedule as the credentials that reach the repository.
  5. Gate retirement on the encryption state you just measured
    • Record each asset’s protection status against its asset ID while it is still live, because once it is powered off this report can no longer be produced. What the disposal process then owes that record is set out on the Insecure Media Disposal And Decommissioning page.

Last updated

References