The attacker is attempting to get a shell running as the DavidGilmour user. Based on their explorations, the decision is to try to exploit a vulnerability in the shineon binary because that binary is setuid to DavidGilmour:
$ ls -lah /usr/local/bin/shineon
-rwsr-s--- 1 DavidGilmour RichardWright 7.3K Oct 25 07:58 /usr/local/bin/shineon
Notice the s in the permissions. That indicates that when shineon is run, it will run as DavidGilmour. But as shineon is a program of limited functionality, it doesn't have a start shell command. Instead, the attacker looks at the functionality the shell provides:
1. Calendar
2. Who
3. Check Internet
4. Check Mail
5. Exit
and then looks at the strings inside the binary. The relevant strings are:
/usr/bin/cal
/usr/bin/who
/sbin/ping -c 3 www.google.com
mail
The attacker guesses that those are the command strings used to execute the functionality of the application: Calendar corresponds to /usr/bin/cal, etc... The attacker cleverly notices that mail doesn't have a full path. This means that the script will run the first mail command it finds in the PATH. So the attacker creates a command named mail in some random directory. They chose /tmp, but that choice is unimportant. The command is a symbolic link to /bin/sh. A symbolic link creates an alias between two files. In this case, when the operating system executes /tmp/mail, it will actually execute /bin/sh. They could have copied /bin/sh to /tmp/mail as well, but why bother. Copying takes time and uses disk space. Symbolic linking is equally effective and faster.
The final step is to set the PATH environment variable to begin with /tmp so that when the OS goes to execute the mail command, it will find /tmp/mail. And, being that this is just a symbolic link to /bin/sh, it will execute /bin/sh as DavidGilmour (remember that the program is setuid so it always runs as DavidGilmour).
Goal achieved!
