~ / foobarto.me / htb-machines
--:--:-- UTC
~ / htb-machines / bastion.md

bastion

Windows · Easy · released 2019-04-20 · retired 2019-10-19

Summary

This writeup is reconstructed from public walkthroughs (see Source attribution below). I have not personally rooted this box. Bastion is an Easy Windows machine whose attack surface is built almost entirely out of misuse of legitimate Windows administration features: the SMB file-sharing service, Windows Server Backup writing whole-disk VHD images, and the mRemoteNG connection manager. There is no web application, no exotic exploit, and no Active Directory — just a stand-alone Windows host with too much trust placed in anonymous network shares.

The intended path begins by listing SMB shares on the target with no credentials, finding a Backups share that is readable to anonymous users, and discovering that someone has parked a full Windows Server Backup inside it. Mounting the share over CIFS from Linux and then using guestmount to mount one of the .vhd files exposes the entire NTFS volume of the backed-up workstation, including the registry hives. Lifting SAM and SYSTEM off-line and running secretsdump produces NTLM hashes for the local accounts. The L4mpje account’s hash falls quickly to rockyou under hashcat -m 1000, and because the box runs OpenSSH for Windows on TCP/22, the cracked password is enough to log in for the user flag.

Privilege escalation pivots on a credential left behind by the user’s tooling. L4mpje has mRemoteNG installed and has saved at least one connection profile in confCons.xml. Old versions of mRemoteNG fall back to a hardcoded master password when the user has not configured one, which means the AES-encrypted credential blob in the XML can be decrypted offline by any attacker who can read the file. A short Python script reverses the encryption and yields Administrator’s plaintext password, which is reused for SSH and produces the root flag. The lessons are about defense in depth around backups, hash strength, and the fragility of “encrypted” credential vaults that hold a hardcoded key.

Source attribution

This guide is reconstructed primarily from the following public sources. They were used to verify port numbers, share names, file paths, and tool invocations. Read them directly for the original screenshots and full command output.

I have not personally executed any of the commands in this guide against the live box. Treat it as a study aid: the conceptual flow and the underlying primitives (anonymous SMB, offline SAM extraction, mRemoteNG decrypt) are the load-bearing parts, not the precise command syntax.

Recon

A standard nmap -sC -sV -p- <TARGET> returns a small but unusual surface for a Windows machine: TCP/22 with OpenSSH for Windows 7.9, plus the classic SMB triplet of TCP/135 (RPC endpoint mapper), TCP/139 (NetBIOS session), and TCP/445 (SMB-over-TCP). Scripts identify the host as Windows Server 2016 Standard 14393. There is no HTTP, no LDAP, no Kerberos, no RDP — and crucially, the SMB stack does not advertise a domain. This is a stand-alone server, not a domain controller and not a member of Active Directory. Treat that fact as load-bearing: every credential you recover is local-only, every “Administrator” you see is <host>\Administrator rather than DOMAIN\Administrator, and password reuse across machines is the only way credentials propagate.

The presence of OpenSSH on a Windows host is itself worth pausing over. Microsoft shipped the Win32 OpenSSH port as an optional Windows feature beginning with Windows Server 2019 and backports, and on this machine it is the only “interactive” service exposed. That changes the foothold model: instead of looking for an SMB write that would let you drop a payload, or for a CVE-style remote code execution, you should mentally bookmark “find any valid Windows credential and you have a real shell” — because ssh user@<TARGET> will give you a full cmd.exe once you do. It also changes the loot model later: instead of needing evil-winrm or psexec.py to operate as Administrator, you can simply re-authenticate over SSH with the recovered password.

The other interesting thing about the recon is what is missing. There is no SMB signing weirdness to abuse, no relay target nearby, no Kerberos to roast, no SPN to coerce, no ADCS to misconfigure. Anonymous SMB enumeration is the only lead. With smbclient -L //<TARGET> -N or smbmap -H <TARGET> -u guest -p '' (or the empty-string null session), the server returns its share list. Among the usual ADMIN$, C$, and IPC$ administrative shares — which are listed but not readable without credentials — there is a custom share called Backups. Anonymous users can list and read its contents. That single misconfiguration is the entire foothold.

It is also worth running enum4linux-ng <TARGET> and rpcclient -U "" -N <TARGET> early. They confirm null-session capability and frequently surface the local user list, the password policy, and the share ACLs. On Bastion the password policy is loose enough that short Dutch dictionary words are valid, which becomes relevant when you reach the cracking step. Recon is not just about discovering services; it is about gathering the constraints you will hand to your cracking tool later.

Foothold — Anonymous SMB → mounted VHD backup

The first concept to internalize is what a Windows Server Backup actually is. When an administrator runs wbadmin or the Server Backup MMC and chooses a network share as the destination, Windows writes a directory tree like WindowsImageBackup\<hostname>\Backup <timestamp>\ containing one or more .vhd files plus an XML manifest.

Each VHD is a flat virtual hard disk image: byte-for-byte, the entire NTFS volume of the source machine, including Windows\System32\config\SAM, SYSTEM, SECURITY, the registry hives, every user profile, and any plaintext data sitting on disk. There is no encryption layer unless the administrator explicitly configures BitLocker on the destination. So the moment an anonymous reader can see those VHD files, they can read the entire source filesystem off-line.

Listing the share over an anonymous connection — for example with smbclient //<TARGET>/Backups -N — confirms the layout. There is a small note.txt at the root and a WindowsImageBackup directory beneath it.

The note, written by a sysadmin to a colleague, explains that the backup is large and that pulling it across a slow VPN is impractical. That is a hint, not a stopper: you do not need to copy the VHD to disk to read it. Mount the share locally with CIFS so the file is accessible as a regular path:

sudo mkdir -p /mnt/bastion
sudo mount -t cifs //<TARGET>/Backups /mnt/bastion -o user=guest,password=,vers=2.0

With /mnt/bastion populated, descend into /mnt/bastion/WindowsImageBackup/L4mpje-PC/Backup <timestamp>/ and you will see two .vhd files. The smaller is the System Reserved partition (BitLocker recovery, boot loader); the larger is the Windows volume itself. Either can be inspected, but the larger is the one you want.

To read the contents of the VHD without converting or copying, use libguestfs’s guestmount, which can attach a virtual disk image and mount any partition on it through FUSE:

sudo mkdir -p /mnt/vhd
sudo guestmount --add '/mnt/bastion/WindowsImageBackup/L4mpje-PC/Backup .../9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd' \
                --inspector --ro /mnt/vhd

The --inspector flag tells libguestfs to auto-detect the partition layout and mount the OS volume; --ro forces read-only. Because the VHD is being read through guestmount from a CIFS mount, you are effectively reading bytes out of the SMB share on demand — there is no full local copy.

Browse /mnt/vhd and you will see a complete Windows install: Users\L4mpje, Program Files, Program Files (x86), and Windows\System32. This is the second host’s filesystem, not the live target’s, but the two share at least one local user account: L4mpje.

The two specific files you want from this filesystem are Windows\System32\config\SAM (the local Security Account Manager, holding NTLM hashes for local accounts) and Windows\System32\config\SYSTEM (the SYSTEM hive, which contains the boot key needed to decrypt the SAM). Many writeups also grab SECURITY, which holds LSA secrets and cached domain credentials.

Copy them out to your working directory:

cp /mnt/vhd/Windows/System32/config/SAM   ./SAM
cp /mnt/vhd/Windows/System32/config/SYSTEM ./SYSTEM
cp /mnt/vhd/Windows/System32/config/SECURITY ./SECURITY

Now run impacket’s secretsdump.py in LOCAL mode against the offline hives:

impacket-secretsdump -sam SAM -system SYSTEM -security SECURITY LOCAL

It prints NTLM hashes for Administrator, Guest, DefaultAccount, and L4mpje. There is one important caveat to flag right now, because it trips up beginners. The Administrator hash you just dumped is the local Administrator hash of the backed-up workstation — not necessarily of the live bastion host. Local SAM hashes are per-machine. The fact that you “have Administrator’s hash” does not mean you can pass-the-hash to the live target’s Administrator account, because their underlying passwords may differ. In practice on this box, L4mpje is a regular local user whose password was reused on the live host, which is why the next step works at all.

Before unmounting, it is worth poking around the rest of the VHD as a habit-building exercise. Users\L4mpje\AppData\Roaming\ and \Local\ often contain saved sessions, browser data, and configuration files for installed applications. On Bastion specifically you will see traces of mRemoteNG already inside the backup — the confCons.xml file lives in the same place inside the VHD as it does on the live host, so a careful operator could in fact pull the privilege-escalation primitive at the same time as the user hash and skip the SSH-as-L4mpje step entirely. The intended path keeps them separate so the box teaches both primitives, but in a real engagement you would never artificially limit yourself.

User flag — Crack L4mpje NTLM from offline SAM/SYSTEM

L4mpje’s NTLM hash needs to be cracked, not relayed. NTLM is unsalted MD4 over UTF-16LE of the plaintext, so for any short, dictionary-derived password it is trivially crackable on commodity GPUs and even on CPU.

Hashcat’s mode 1000 is exactly NTLM:

hashcat -m 1000 -a 0 L4mpje.hash /usr/share/wordlists/rockyou.txt

The hash falls to a Dutch-flavored password (bureaulampje, “little desk lamp”) within seconds. The key conceptual point is not “rockyou cracked it”; it is that NTLM has no work factor. There is no PBKDF2, bcrypt, scrypt, or Argon2 wrapped around it — the hash function is fast by design so that interactive logon stays fast. Anything short, common, or themed will fall, which is why local SAM exfiltration is so dangerous even when the target account is “non-privileged.”

With a plaintext password in hand, the live host accepts SSH directly:

ssh L4mpje@<TARGET>

OpenSSH for Windows hands you a cmd.exe shell as L4mpje. (You can powershell from there if you prefer.) The user flag lives at the conventional Desktop path:

type C:\Users\L4mpje\Desktop\user.txt

A small but worthwhile exercise here is to confirm what the live host actually looks like compared to the backup. whoami /priv, whoami /groups, and net user L4mpje will show that this is just a regular local interactive user with no SeImpersonatePrivilege, no SeBackupPrivilege, no SeDebugPrivilege — no obvious token-impersonation route to SYSTEM. That nudges you toward looking at what software the user has installed and what data is on their disk, rather than at kernel exploits or token games.

Run a quick PowerShell-flavored enumeration even from cmd.exe: dir "C:\Program Files" and dir "C:\Program Files (x86)" give you the installed-software inventory, wmic qfe list brief gives you patches, and walking C:\Users\L4mpje\AppData\Roaming and \Local shows you which applications have actually been used (the registry would tell you the same story, but the file system is faster to skim). The shape of these directories is what points you at mRemoteNG, which is in (x86) because the application is 32-bit. Building this habit — “always characterize the user’s installed apps before reaching for kernel exploits” — pays off across many Windows boxes.

Privilege escalation — mRemoteNG confCons.xml decrypt

A walk through C:\Program Files and C:\Program Files (x86) quickly reveals an installation of mRemoteNG, an open-source multi-protocol remote connection manager that supports RDP, SSH, VNC, Telnet, and others. It is the kind of utility a sysadmin installs on a jump host so they can keep all their saved RDP/SSH connections in one place.

mRemoteNG stores its configuration in an XML file under the user’s roaming AppData:

C:\Users\L4mpje\AppData\Roaming\mRemoteNG\confCons.xml

Open that file (type it in the SSH session, or scp it back to your attacker box). Each saved connection appears as a <Node ...> element with attributes for Hostname, Username, Domain, and a base64-looking Password blob. There is a saved connection for Administrator against the local host (or a sibling host) with an encrypted password attribute that looks something like V22XaC5eW4epRxRgXEM5RjuQe2UNrHaZSGMUenOvA1Cit/z3v1fUfZmGMglsiaICSus+bOwJQ/4AnYAt2AeE8g==.

This is where the conceptual bug lives. mRemoteNG encrypts saved passwords with AES, deriving the key from a master password using SHA-1 (or PBKDF2 in newer versions, with a default low iteration count). The encrypted blob is base64-encoded and includes the IV and a small auth tag.

If the user sets a master password, the file’s contents are tied to a secret only they know. But if the user does not set one — which is the default — mRemoteNG uses a hardcoded fallback master password (the literal string mR3m) baked into the application source. That means anyone who can read the XML file can derive the AES key, decrypt the password blob, and recover the plaintext.

The community-maintained mremoteng-decrypt.py (haseebT on GitHub) implements exactly this.

Pass the encrypted attribute and it returns the cleartext:

python3 mremoteng_decrypt.py -s 'V22XaC5eW4epRxRgXEM5RjuQe2UNrHaZSGMUenOvA1Cit/z3v1fUfZmGMglsiaICSus+bOwJQ/4AnYAt2AeE8g=='

Out comes Administrator:<password>.

SSH back in as Administrator on the live host:

ssh Administrator@<TARGET>
type C:\Users\Administrator\Desktop\root.txt

whoami /priv will now show the full administrative privilege set, and the root flag is accessible. It is worth noting that on a real engagement you would also dump the live SAM and LSA secrets at this point — reg save HKLM\SAM, reg save HKLM\SYSTEM, reg save HKLM\SECURITY, and re-run secretsdump LOCAL — to compare the live Administrator NT hash with the one from the backup VHD and confirm or refute password reuse across the two hosts. That comparison is one of the small forensic loops worth practicing, because it is exactly the artifact you would want as a defender writing the post-incident report.

A second exercise is to grep the entire C:\Users\ tree for additional confCons.xml instances and for other credential-store file types (*.kdbx, *.rdg, *.sdf, Sticky Notes, browser Login Data SQLite files). Operators often leave more than one trail behind, and the post-foothold hour is the right time to harvest. On Bastion specifically the lesson is narrower — there is exactly one mRemoteNG profile and one juicy credential — but the pattern of “after compromising a host, sweep for credential vaults” is the genuine takeaway.

A more pedantic note about the decryption: the algorithm in confCons.xml for older mRemoteNG versions is AES-128 in CBC mode with the key derived from the master password via SHA-1, and an HMAC tag appended for integrity. The IV is prepended to the ciphertext in the base64-encoded blob, which is why mremoteng-decrypt.py does not need any side information beyond the blob itself and the (defaulted) master password. Newer mRemoteNG releases switched to PBKDF2 with a configurable iteration count, but the iteration count is also stored in the XML, so a fast offline cracker can still attempt master-password guesses without rate limit. The only durable fix is a strong, user-set master password — and ideally not storing privileged credentials in mRemoteNG at all.

If, for some reason, the script does not produce sensible output, the usual reason is that the XML contains a per-connection password override or that the user did configure a non-default master password. In those cases you fall back to dictionary-attacking the master password against the encrypted blob (the script supports a -p argument) or you abandon mRemoteNG and look for credentials elsewhere on the host. On Bastion the default master password works, which is the canonical “Easy” outcome.

Why each step worked

Anonymous SMB on the Backups share worked because the share’s NTFS ACL or SMB share permissions allowed Everyone (or ANONYMOUS LOGON, depending on the policy) to read.

There is nothing inherently wrong with serving backups over SMB; the failure is treating the backup destination like ordinary file storage rather than as a high-sensitivity asset that should be locked to backup operators only. The principle generalizes: any file share whose contents are sensitive should be ACL-restricted to the smallest possible group, and “Authenticated Users” is almost never the right answer for a credential-bearing share.

Reading the VHD worked because Windows Server Backup writes raw VHD files with no encryption by default. A VHD is a thin container around a normal partition; libguestfs and Microsoft’s own Mount-VHD cmdlet (or even qemu-nbd) can attach it. Once attached, the on-disk filesystem is just NTFS — readable by anyone with the bytes. There is no equivalent of “bring the encryption key” because there is no encryption to defeat.

It is worth pausing on why guestmount is the right tool rather than a more obvious choice. qemu-nbd plus mount -t ntfs works, but it requires loading the nbd kernel module, attaching the device, partprobing, and mounting — four steps where one will do. losetup plus kpartx is similarly clunky. Microsoft’s Mount-VHD cmdlet would work on a Windows attacker box but pulls the file in over SMB more eagerly. guestmount reads only the bytes it needs, supports --inspector for partition auto-detection, and gives you a normal directory tree under FUSE. The conceptual skill being built is “for any disk-image format, know one good mount path you can produce from memory.”

secretsdump LOCAL worked because the SAM hive is encrypted with a per-system key (the “SysKey”) that is itself stored in the SYSTEM hive. Any code (or off-line tool) that has both hives can derive the SysKey and decrypt the password hashes.

Microsoft’s design assumption was that an attacker with both hives has already won, which is fine on a running, well-secured machine — and a disastrous assumption when the hives can be lifted from a backup blob over an anonymous file share. This is a recurring shape of Windows security failures: a control that is sound at runtime turns into nothing once the data leaves the runtime context. Domain controller backups (ntds.dit plus the SYSTEM hive) follow exactly the same pattern.

Cracking L4mpje’s NT hash worked because NT is fast-MD4 with no salt and no iteration count, and bureaulampje is in any reasonable wordlist either directly or via simple mangling rules. The structural problem is NT’s age: it predates modern password storage hygiene by two decades. Microsoft cannot replace it without breaking SMB, NTLM auth, and a long tail of legacy Windows tooling, so it survives.

The lack of salt deserves a side note. Because NT hashes are unsalted, two users with the same password have the same hash. That makes precomputed-dictionary attacks (rainbow tables) and bulk hash-versus-hash comparisons trivial. It also means that once you crack one NT hash, you should run the cracked plaintext against every other NT hash in your possession before resuming a slower wordlist attack — the password-reuse hit rate inside a single environment is high enough that this is almost always worth it. On Bastion you only have one user-account hash worth cracking, but the habit generalizes.

The mRemoteNG path worked because the application’s threat model assumed the saved-credentials file would only be readable by the user (Windows file ACLs), not that the AES key would protect the file’s contents from someone who already had the bytes. With a hardcoded fallback master password, the encryption is purely obfuscation. Any user who sees the XML can decrypt it. mRemoteNG-Decrypt is a five-minute Python script.

There is a fifth, more subtle reason this path worked end-to-end: trust transitivity. The administrator who saved the Administrator credential into mRemoteNG implicitly trusted (a) every account on the host, (b) the disk where mRemoteNG stored its profile, and (c) any backup of that disk. The chain on Bastion is “anonymous SMB reader” → “backup reader” → “VHD reader” → “L4mpje password” → “L4mpje SSH” → “mRemoteNG XML reader” → “Administrator”. Each individual link is a small trust assumption that is defensible in isolation, but composed together they yield a remote unauthenticated takeover. Most real-world Windows compromises look like this: not one catastrophic vulnerability, but a chain of small, mostly-fine choices.

Counterfactuals

If the Backups share had required authenticated access — even just any-domain-user-can-read — the entire foothold disappears. Restricting backup destinations to a dedicated BackupOperators group, or better, writing them to a destination that the production network cannot reach at all (a separate backup VLAN, an immutable object store with WORM semantics), is the canonical control.

If the backup itself had been encrypted — Windows Server Backup supports BitLocker on the destination volume, and many third-party backup tools encrypt at write time — exfiltrating the VHD would yield ciphertext, and the SAM/SYSTEM extraction step does not work without decrypting first. The cost is that you must store and protect the encryption key somewhere else, ideally a hardware-protected vault.

If anonymous SMB had been disabled at the SMB-server level — RestrictNullSessAccess=1 and the related share-restriction policies — the share would not enumerate to an anonymous lister, and you would need a credential to even see Backups in the share list. That is not a perfect mitigation (any low-privilege domain account would still see it on a domain-joined host), but on a stand-alone Windows Server it raises the bar from “anyone on the network” to “someone who already has at least one valid local account.”

If L4mpje’s password had been something not in any wordlist (a passphrase of three to five random words, or a 16-character random string), the NT hash would resist offline cracking long enough to make the attack uneconomical. The host still leaks the hash, but pass-the-hash to OpenSSH does not work — SSH wants a plaintext password — so a strong password materially changes the outcome here.

If L4mpje had set a master password in mRemoteNG, the confCons.xml blob becomes useless to a reader who does not also know that master password. Better still: do not store privileged credentials in a tool that uses a fast hash and a known-or-default master key. KeePass with a strong KDF (Argon2id, high iteration count) and a key file stored separately, or a centralized secret manager (HashiCorp Vault, CyberArk, Azure Key Vault) with short-lived credentials, both substantially raise the bar. On the application-vendor side, modern mRemoteNG releases (1.76+) support PBKDF2 and force the user to set a master password on first run — those defaults are the right fix, but they only help if users keep their installs current.

If OpenSSH had not been exposed on TCP/22, the foothold step is harder but not impossible: with a cracked password you can move to evil-winrm if 5985 is open, psexec.py against ADMIN$ if SMB write is allowed, or wmiexec.py over RPC. The presence of OpenSSH simply makes the post-credential step trivial. Closing TCP/22 to the internet and routing administrative SSH access through a jump host with MFA would have meaningfully raised the cost of the whole chain.

If the Administrator account had been protected by Windows LAPS — generating a unique, rotated random password per host — then even successful decryption of confCons.xml would yield a credential that is either obsolete (rotated since the profile was saved) or scoped only to a single host. LAPS is the canonical mitigation for the “Administrator password reused across hosts” failure mode, and it is free with Active Directory. Bastion is stand-alone so LAPS is not directly applicable, but the same idea — never embed long-lived privileged credentials in tooling — generalizes.

Key Takeaways

Treat backup repositories as crown-jewel data. A backup of a workstation is, from an attacker’s perspective, that workstation — minus the OS-enforced runtime protections. Anything readable in that backup is readable to the attacker, including hives, registry secrets, browser stores, and saved credentials. The implicit “but they would need to be Administrator on the live host to read those” protection is gone the moment the bytes are sitting in a network share.

Offline SAM/SYSTEM extraction is a stable forensic primitive worth memorizing. secretsdump LOCAL -sam ... -system ... -security ... is the same incantation whether you got the hives from a backup VHD, a forensic image, an ntdsutil snapshot of a domain controller, or a raw memory grab. Pair it with hashcat -m 1000 for NT and -m 1800 for sha512crypt, and you can convert most “I have the disk” wins into credentials.

mRemoteNG’s confCons.xml decryption is a one-script primitive. Any time you find an mRemoteNG, Remote Desktop Connection Manager, FileZilla, or similar profile file on a compromised host, check for offline-decryptable credentials before you bother with kernel exploits. Windows privilege escalation is often a credential hunt, not a vulnerability hunt. The same logic applies to PuTTY saved sessions in the registry, WinSCP WinSCP.ini, and Notepad++ session files: any client that “remembers” a password is a target.

OpenSSH on Windows changes the rules of post-exploitation in a small but real way. A cracked password is a real interactive shell, with no need for psexec, wmiexec, or evil-winrm. That makes Windows hosts that expose SSH essentially behave like Unix hosts from a credential-reuse standpoint, and it should also remind defenders that Windows password-strength policies matter for SSH too. From a detection standpoint, defenders should ensure that Windows OpenSSH events end up in the same Sysmon/Event Log pipeline as logon events 4624/4625; otherwise a successful SSH login can be invisible to the SOC.

Separate the existence of a backup from the blast radius of a backup. The backup on Bastion exists for a defensible reason — disaster recovery for L4mpje-PC. The mistake is the destination’s permissions. Good backup hygiene is not “do you have backups,” it is “who can read them, where do they live, and how are they encrypted at rest.”

Finally, internalize the chain pattern. None of the steps here is an exotic exploit; each is a basic operational primitive (anonymous SMB read, VHD mount, secretsdump, hashcat NTLM, mRemoteNG decrypt). The skill the box rewards is recognition — being able to say “I have these bytes, therefore I can do these things” quickly enough that the chain feels obvious. Build that recognition by practicing each primitive on its own, against artificial inputs, until it becomes muscle memory. Then boxes like Bastion read as a series of obvious moves rather than as a puzzle.

Two practical exercises to do alongside this writeup. First, set up a Windows VM, run wbadmin start backup to a local SMB share, and walk yourself through the full mount-and-extract chain end to end so the guestmount and secretsdump steps stop feeling magical. Second, install mRemoteNG (an old 1.75 release) on a throwaway VM, save a fake credential, and run mremoteng-decrypt.py against the resulting XML; then upgrade to 1.76+, set a master password, and confirm the script no longer decrypts without it. Hands-on experience with both the offense and the mitigation is what converts “I read a writeup” into “I understand the bug class.”

References

← all htb machines hackthebox.com ↗