The SATRA lab ran on 2025-10-23 on a Dell OptiPlex 7060 running Kali GNU/Linux Rolling 2024.2 (kernel 6.8.11-amd64). The task was structured as a real assessment: map the network, enumerate services, identify vulnerabilities, qualify risk, and produce findings that would be useful to someone responsible for the infrastructure rather than just a list of tool output.
The lab had two network segments. The red network was 192.168.142.0/24, accessed through eth1 with a DHCP-assigned address of 192.168.142.79. The blue network was 152.77.84.0/25, reached by reconfiguring eth1 later in the session. The gateway on the red network was 192.168.142.1 (im2ag-fw-to-im2ag-tp-secu.u-ga.fr). No direct internet access was available from either segment — curl ifconfig.me and outbound pings both timed out on the red network.
Passive reconnaissance phase
Before touching the lab network, the exercise began with open-source intelligence gathering. Maltego Community Edition was used for the “Social Engineering Bingo” exercise: mapping publicly available information about a chosen target and about oneself, running transforms to discover associated email addresses, phone numbers, social media profiles, websites, and documents. The goal is not to find exploitable information but to calibrate intuition about how much a public digital presence reveals, and where gaps in operational security show up in graph form.
Google dorks extended this. The exploit-db Google Hacking Database was the reference. Queries like site:target.com filetype:pdf, site:target.com intitle:"index of", and site:target.com inurl:login characterize what a target organization has indexed and exposed. Running the same queries against oneself is instructive — it surfaces CVs, GitHub contributions, university affiliations, and whatever else links a name to a publicly reachable resource.
OSINT tools used included whatsmyname.app (username across platforms), epieos.com (email-to-account correlations), and Have I Been Pwned (breach exposure). These are passive — they do not contact the target.
Shodan was the intended bridge between passive and active. The tasks required searching for Moodle and Chamilo instances, checking the lab’s public IP exposure, finding Telnet and SSH servers in France, and locating Palo Alto NGFWs vulnerable to PAN-SA-2024-0010. The queries and syntax were ready. The result was a 403 Forbidden with 0 query credits on the API key provided. Every Shodan search returned Error: Access denied. The passive phase for Shodan ended there.
Starting with what you can see without scanning
Before running any active tools, the first step was understanding the workstation’s own configuration. ip -4 addr show showed three interfaces: eth0 (192.168.5.1/24, the point-to-point management link, left alone per instructions), eth1 (the lab interface), and docker0 (172.17.0.1/16, the local Docker bridge). ip route show confirmed the default gateway. /etc/resolv.conf showed DNS at 193.85.24.30 and 152.77.1.22, with search domains u-ga.fr and univ-grenoble-alpes.fr.
Running ps aux | grep -E 'snort|suricata|fail2ban' found nothing. UFW was enabled (systemctl status ufw showed it had started on 2024-06-11), but sudo iptables -L -n -v showed ACCEPT defaults on INPUT and OUTPUT with only Docker isolation chains active — no meaningful host-level filtering beyond what Docker sets up automatically. The workstation was not hardened. Any service running on it would be reachable.
sudo nft list ruleset confirmed the same picture. Kali also uses journald rather than traditional syslog, so commands like sudo journalctl -n 50 would capture audit activity rather than /var/log/auth.log.
Red network enumeration
A host discovery sweep (nmap -sn 192.168.142.0/24) found four responding hosts:
192.168.142.2—ima-crypto.u-ga.fr192.168.142.4—clone-dhcp-reseau.u-ga.fr192.168.142.5—im2ag-crypto-czilla.u-ga.fr192.168.142.79— the scanning workstation
ARP cache inspection (arp -a) showed additional MAC entries at .39, .46, .66, and .96 — hosts that did not respond to ICMP but were present on the segment. Silent hosts are not the same as absent hosts.
SSH was running on all discovered hosts. Version scanning produced:
.2: OpenSSH 7.4p1 Debian 10+deb9u7.4: OpenSSH 9.2p1 Debian 2+deb12u7.5: OpenSSH 8.4p1 Debian 5+deb11u4
Web services
HTTP on port 80 was open on .2, .4, .5, and .96. The responses were different for each.
192.168.142.2 returned the eXtplorer web file manager. The HTTP header showed Apache/2.4.25 (Debian). Running nmap --script http-enum on port 80 exposed /README.txt, /config/, /crypto/, /images/, /include/, /libraries/, /scripts/, and /style/ as browsable paths. Fetching /README.txt directly with curl returned the eXtplorer 2.1 deployment notes, including a warning that if the admin password had not been changed from the default, credentials were admin/admin. The /crypto/ directory was also browsable and contained an install.ipxe file that documented PXE boot options with references to external resources including the LTSP server at 129.88.208.102.
192.168.142.4 and .5 returned 403 Forbidden from nginx 1.22.1 and 1.18.0 respectively. Neither would serve content without authentication or a known path.
192.168.142.96 returned 404 page not found. Service probing with nmap -sV -p 80 identified Gophish httpd — the open-source phishing simulation platform. The root path returning 404 is typical of Gophish, which serves its admin interface at /login rather than /. The /robots.txt on that host contained Disallow: /, suggesting intentional concealment of the interface path.
NFS and RPC services
Full TCP port scans (nmap -sV -p- --min-rate 1000 -T4) against .2, .4, and .5 revealed extensive NFS infrastructure:
All three hosts ran rpcbind on port 111 and NFS on port 2049. showmount -e against each returned:
.2:/srv/VM,/srv/images,/srv/tftp/boot/images— accessible to192.168.142.0/24.4:/var/lib/drbl,/tftpboot,/Summer/Images_TP,/opt,/home,/usr, and per-node directories — shared broadly, consistent with DRBL (Diskless Remote Boot in Linux) and Clonezilla imaging infrastructure.5:/srv/tftp/boot/gparted,/srv/tftp/boot/clonezilla— restricted to152.77.84.0/25
rpcinfo -p 192.168.142.4 additionally showed NIS/YP services: ypserv, ypbind, yppasswdd, and fypxfrd. NIS is a centralized account directory service, common in older academic Linux lab setups. It means user accounts and credentials for the diskless workstations are likely served from .4.
Port .4 also exposed 6461/tcp with no identifiable banner — nc and nmap --script banner both returned nothing. The unknown port was noted but not probed further without additional scope confirmation.
Blue network enumeration
After switching to the blue network (152.77.84.0/25, assigned .69), host discovery produced:
152.77.84.121—test1-uefi.u-ga.fr152.77.84.122—master-uefi.u-ga.fr(also the DHCP server, with short lease times of ~4 minutes)152.77.84.124—im2ag-gt-cmserver.u-ga.fr- Several classroom nodes at
.66-.68and.81-.83responding to ARP but with no TCP services open
Both UEFI master nodes ran OpenSSH 9.2p1 and nginx 1.22.1 (403 Forbidden). showmount -e against both returned the same extensive DRBL/Clonezilla share structure as .4 on the red network — /var/lib/drbl, /tftpboot, /home, /usr, /var/mail, /opt, /Summer/Images_TP, and per-node directories — accessible to the full /25 range. The RPC inventory (rpcinfo -p) showed active NIS services on both: ypserv, yppasswdd, ypbind.
152.77.84.124 ran Apache 2.4.56 on port 80 and OpenSSH 8.4p1. The Apache instance served the default landing page. server-status returned 403. No NFS exports were registered on .124.
Vulnerability findings
nmap --script vulners against the discovered services produced the significant findings when run with sudo on the blue network hosts:
CVE-2024-6387 (regreSSHion): OpenSSH 9.2p1 on 192.168.142.4, 152.77.84.121, and 152.77.84.122. This is a race condition in the loginGraceTime handler that allows unauthenticated remote code execution. It affects OpenSSH versions before 9.8p1. The CVSS score is critical. The lab infrastructure had three exposed instances.
CVE-2023-38408: Also affecting OpenSSH 9.2p1. This is a remote code execution vulnerability in the OpenSSH agent via the PKCS#11 feature.
CVE-2024-38474 and CVE-2024-38476: Apache 2.4.56 on 152.77.84.124. Both are high-severity. CVE-2024-38474 is an HTTP substitution encoding vulnerability allowing source code disclosure and execution. CVE-2024-38476 is related to HTTP/2 handling and can enable execution with mod_cgi.
The Vulners NSE script did not flag CVEs for OpenSSH 7.4p1 on .2 or Apache 2.4.25 on .2 during the scan, though both versions are significantly past end-of-life and have historical vulnerabilities. The absence of Vulners results does not mean the absence of vulnerabilities — it reflects the state of the Vulners database snapshot at the time of the scan.
What the Shodan step revealed
Shodan was supposed to be part of the lab. The instruction was to search for Moodle/Chamilo instances, check external exposure of the lab’s public IP, and look for France-based Telnet/SSH services and Palo Alto NGFW CVEs. The Shodan CLI was installed and initialized with the provided API key. The result: shodan info showed 0 query credits, and every query returned Error: Access denied (403 Forbidden).
This is worth documenting rather than omitting. A required step in the lab was blocked by an infrastructure issue (zero-credit API key) rather than by anything the attacker could have done differently. The correct reporting of this is: the search was attempted, the obstacle was documented, the result is “pending — requires functional API credentials.” Not “no findings.”
Translating findings to risk
Raw scan output is not a finding. The CVE-2024-6387 finding needs to be stated as: unauthenticated remote code execution is possible on three infrastructure servers that are accessible from the lab network. Two of them (152.77.84.121/122) are the DHCP and imaging masters for the classroom PCs. Compromise of either would give an attacker the ability to modify disk images delivered during PXE boot, affecting every workstation that reimages from them.
The eXtplorer finding needs to be stated as: a web-based file manager with a documented default credential (admin/admin) is exposed on port 80 of the network server that hosts VM images and PXE boot content. If the default credential is unchanged, an attacker with access to the lab network can read and write files on that server without authentication.
The NIS/NFS exposure needs to be stated as: centralized account management via NIS on a host accessible to the full subnet means that user credentials are being served over an unauthenticated protocol. NIS has no encryption and minimal access controls. Combined with the broad NFS exports (including /home and /opt), the infrastructure has essentially no network-level isolation between the imaging servers and the rest of the segment.
What changes between a scan and an audit
A scan produces a list of open ports and matching CVEs. An audit connects those findings to impact, to the specific infrastructure at risk, and to realistic remediation. For these findings:
OpenSSH: Patch to 9.8p1 or later. If patching cannot happen immediately, restrict LoginGraceTime and rate-limit SSH connections at the firewall. Document that .2 is running 7.4p1, which is end-of-life and should be upgraded regardless of specific CVEs.
Apache 2.4.56: Patch to 2.4.62 or later. While .124 is an imaging/management host rather than a public-facing server, CVE-2024-38474 source disclosure is still a meaningful risk if any configuration files or scripts are accessible via HTTP.
eXtplorer: Verify whether default credentials are in use. If yes, change them immediately. Consider whether a web file manager is necessary on a PXE/VM server at all, or whether SSH-only access would be sufficient.
NIS/NFS: These are harder because they are the infrastructure, not incidental services. The realistic recommendation for a lab environment is network segmentation: restrict NIS and NFS access to the specific hosts that need it rather than the entire subnet. This requires VLAN configuration that was outside the scope of this assessment, but should be flagged for the network administrator.
The precision that matters in audit work is not in tool syntax. It is in the step from “service X is running version Y with CVE Z” to “this is what that means for this environment and this is what would fix it.”