Dethroning Samba, the file share king, with a CVE from 2017

Second attack against the Homelab, and a harder one on purpose. The nmap scan showed network monitoring catching something host monitoring structurally can’t see. This one asks a different question. What happens when the attack does complete a real session, writes a real file, and runs real code, all things a host sensor could in theory observe?

Building 2017 software on a 2024 machine

Ubuntu 24.04’s own Samba package is already patched against CVE-2017-7494, so the vulnerable version, 4.6.3, had to be compiled from source. That meant running 2017-era build tooling against a modern 2024 toolchain, which turned out to be most of the actual work.

The build itself was most of the fight. Samba’s build tool, waf, is Python 2 only, so I had to build Python 2.7.18 from source just to run it, then fix a link-order bug that only showed up once the build tried to statically link against it. A missing libldap2-dev and a naming collision in nsswitch/nsstest.c with newer glibc typedefs were the last two fixes before it compiled clean. But in the end, I got it set up.

Then came the actual vulnerable configuration, a [public] share, guest ok = yes, read only = no, map to guest = Bad User, anonymous unauthenticated write access, exactly what CVE-2017-7494 needs to work.

Two attempts, one crash, no obvious cause

My first run of Metasploit’s exploit/linux/samba/is_known_pipename crashed before it even reached the trigger. I thought it was due to a stale package, but that wasn’t it. After trying to update the metasploit-framework, I found out it’s already the latest version. This was probably due to the fact that it’s been substantially rewritten since 2017 so this specific old module hasn’t fully kept pace.

Rather than patch Metasploit’s internals or switch to a standalone Python PoC with its own dependency chain, I just re-ran the identical module with identical options. It worked the second time.

I uploaded the payload to the share, loaded it via the classic two-stage path-traversal trick, then the bare filesystem path succeeded, and I landed in the interactive shell as root, smbd’s default run-as user.

What fired

Three separate Suricata signatures, zero target-specific tuning required for any of them:

• ET EXPLOIT Samba Arbitrary Module Loading Vulnerability (NT Create AndX .so) (CVE-2017-7494), sid 2024336, severity critical, tagged CISA_KEV, fired at the exact moment of the path-traversal trigger.
• ET INFO Executable and linking format (ELF) file download, sid 2000418, fired separately when the payload .so itself crossed the wire during upload.
• GPL ATTACK_RESPONSE id check returned root, fired when I ran whoami/id inside the new shell. The payload sends commands and reads output back in plaintext over the same SMB channel, and this signature matches on strings like uid=0(root) in any TCP stream, “HTTP server” in its name is just stale from when it was written for web shells.

Wazuh logged none of it. The only host-layer events in that window were my own SSH/PAM/sudo sessions from checking logs, coincidental, not detection.

Why the network layer caught it and the host layer didn’t

This is where it stops being the same story as the nmap scan. That scan was structurally invisible, nothing to log no matter how the host was configured. This exploit is different. It completes a legitimate-looking SMB session, writes a real file under /srv/samba/public, and causes smbd to load and run attacker code as root, all through an unexpected child process and an unusual RPC request, BUT it was something a host sensor could definitely catch.

Wazuh saw none of it not because it physically can’t, but because nothing was pointed at those signals. No FIM watch on the share directory. No ingestion of smbd’s own logs. No process-execution auditing. smbd -d 2 debug logging on the target was, in fact, capturing plenty of forensic detail about the exploit the whole time, file opens, the connecting workstation, pipe registration failures, it just wasn’t sending it anywhere.

What I took away

A well-known, official Metasploit module for an eight-year-old CVE can still be less reliable than the vulnerability it’s exploiting. The path to root was solid the entire time, Metasploit’s own SMB client tooling was the weird part. And “the host layer missed it” turned out not to be one flat kind of failure, this is a different failure than the scan, a gap in what I was watching rather than a gap in what could be seen at all. Worth telling apart every time rather than filing both under the same headline.

Limits

This is one CVE against one deliberately misconfigured share, not a general claim that host-based detection can’t cover file-write or process-spawn attacks, it’s a claim that this particular lab wasn’t configured to catch it. A real deployment would need FIM on shared directories, smbd log ingestion, and process auditing before this class of attack shows up on the host side at all. This only worked because I didn’t patch it on this machine.