Dead Drop
Every dead drop points inward. Chain your findings, pivot through the gaps, and follow the trail until nothing is out of reach. - by empanadaL0ver
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
DeadDrop Ltd's file-sharing application is your starting point. Everything you need to reach the domain controller can be discovered through careful enumeration and exploitation. Each question below marks a milestone in the attack chain.
Summary
Summary
In Dead Drop, we begin with limited network visibility, having access only to the DeadDrop Ltd file-sharing host at 192.168.11.200, while two additional hosts (.51 and .100) remain unreachable behind it. Initial enumeration with rustscan reveals SSH and a web application, and the login portal is bypassed using a simple SQL injection (admin' AND 1=1 -- -) to authenticate as admin, granting access to the dashboard where a captured NetNTLMv2 hash belonging to svc-drop is exposed.
Cracking the hash with hashcat and the rockyou wordlist yields valid credentials, which we reuse to obtain an SSH foothold as svc-drop on the target. Within the home directory, a backup folder contains deaddrop-mobile.apk, which we exfiltrate to our attacker machine using netcat and decompile with jadx. A grep through the decompiled Java source surfaces hardcoded credentials inside Config.java, revealing the domain account of j.harris.
To reach the internal network from our attacker host, we establish a Ligolo-ng tunnel pivoting through .200, creating a dedicated dead-drop interface and adding /32 routes to both internal hosts to avoid loopbacks. With routing in place, we probe the domain controller at 192.168.11.100, validate the j.harris credentials against SMB using NetExec, generate a hosts file entry for DEADDROP-DC.deaddrop.loc, and run BloodHound-CE to enumerate the domain.
BloodHound analysis exposes that j.harris holds the AddMember permission over the ITSupport-Admins group, which is itself nested inside Domain Admins, creating a direct escalation path. Using bloodyAD, we add j.harris to ITSupport-Admins, instantly inheriting Domain Admin rights. A final NetExec check confirms administrative access, and we connect to the DC over WinRM with evil-winrm to fully compromise the domain and retrieve the final flag from the Administrator's Desktop.
Recon
We have three hosts available on the network, of which only 192.168.11.200 is accessible to us. We may need to use this as a jump host in order to access the hosts 192.168.11.51 and 192.168.11.100.
We use rustscan -b 500 -a 192.168.11.200 --top -- -sC -sV -Pn to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.
A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.

On the target, we have SSH available on port 22 and a web server on port 80.

Access as admin
We visit the index page at 192.168.11.200 and are redirected to /login. We are now looking at the login page.

We can bypass the login using a simple SQL injection. We'll start by trying a less dangerous version using AND and guessing the username. Why? Take a look here:
Unfortunately, the room for this is no longer available.
We are able to log in as admin.

At the time of this write-up, the network had already been compromised, and the initial part is missing. In this portal, we would now find a NetNTLMv2 belonging to user svc-drop.

Access as svc-drop
We try to crack the hash using hashcat with rockyou.txt and are successful.

We test the credentials and try to log in to the web server via SSH and are successful. In the home directory, we find a backup directory.

Access as j.harris
This backup directory contains a deaddrop-mobile.apk file.
An .apk (s the file format used to distribute and install applications on Android devices. It is essentially a ZIP archive bundling the app's compiled code, resources, assets, and manifest. To inspect deaddrop-mobile.apk, we can use jadx, a decompiler that converts the Dalvik bytecode back into readable Java source code, making it possible to analyze the app's logic, hardcoded secrets, and API endpoints.
Extracting Credentials
But first, we need to get the APK to our machine, we are using netcat...

We run the following command on our receiving end - our attacker machine.
Next, we run the follwing on the target. After a short duration we have the APK available on our machine.

Now we can decompile the apk using jadx.

We look for credentials and find some.

The Config.java file contains a password.

On a closer look it reveals the credentials of j.harris.

Ligolo-ng Setup
Next, we want to test the credentials. They seem to be domain credentials. But we need to be able to reach out .100 and .51. We set up Ligolo.
So to reach the machines from our attacker machine we setup a Ligolo-ng tunnel that tunnels the traffic through .200. The following guide is detailed and highly recommended. It showcasses multi-pivoting, which we also need to use here, and refers to tests on this blog.
First, we run a proxy.

Inside that proxy we create an interface called dead-drop.
Now, we add each of the identified hosts as routes in CIDR notation. We can't add the entire network like 192.168.11.0/24 cause we are already part of the network and would result into loops,

Next, we upload an agent and connect to our proxy.


After the connection has been made we should see in our proxy that an agent has joined.

We can list and interact with the session by calling session and then chosing the session. The following screenshot illustrates the steps taken.
After chosing the session, we can start the tunnel.

To confirm our tunnel and routes we can issue the following commands:

Credential Test
Now we try to reach out to the DC and probe the ports. We are successful.

We test the credentials using NetExec by trying to authenticate against the SMB service of the DC. We successfully authenticated. If you see that you are admin, the network has probably been already pwned.

Next, we are using NetExec to generate a proper /etc/hosts entry.

We add the following entry to our /etc/hosts file.
BloodHound Enumeration
With valid domain credentials we try to enumerate the domain using BloodHound.

This part was resconstructed by removing the users from the group IT-SUPPORTADMINS and DOMAIN ADMINS since in both cases initally tackling the challenge and for the write-up the user has already been added.
Based on the questions from the room, I conclude that the user should be added to the IT-SUPPORTADMINS. The specified permission that allows to escalate is the Add Member permission. The following screenshot shows the result in Bloodhound after I removed the user from the Domain Admins and IT-SUPPORTADMINS groups, trying to reconstruct the intended path.

We see that the user has the AddMember permissions to the ITSUPPORT-ADMINS group which is member of the DOMAIN ADMINS. By Adding the user itself to the ITSUPPORT-ADMINS group the user becomes a DOMAIN ADMIN which allows us to compromise the entire domain.

Shell as Administrastor
We add the user to the ITSupport-Admins group...

... and test the credentials again. We see now we are admin.

Now, we can connect to the DC...

... and reach out to the Administrator Desktop containing the final flag.

Last updated