The Blind Spot My Training Gave Me
After the eJPT I went straight to Hack The Box. The first machine I did was Lame, which is retired since long and has writeups everywhere, so I can talk about it.
It went fine. But one thing from that evening keeps me thinking, and it is not about the box at all.
What I did
Normal start. Port scan, service detection, write down every service with its version. The box gives you a nice list: FTP with vsftpd 2.3.4, SSH with OpenSSH 4.7p1, SMB with Samba 3.0.20, and distcc.
Then my methodology says: for every service, check if this version has a known vulnerability. So that is what I did, and I did it properly. vsftpd 2.3.4, OpenSSH 4.7p1, distcc. For each one I went through the known vulnerabilities of that version and worked them off. They were either patched or they simply did not work here. Not one thing I skipped in that group.
Then I was stuck. Not out of ideas in a panic way, more that my list was finished and it had produced nothing. So I made a decision: read the official writeup, take the smallest hint that points a direction, close it again.
The hint was Samba 3.0.20, CVE-2007-2447. A username map script that runs shell commands. Public since 2007, module in every framework, and it was sitting on my own service list the whole evening.
I never checked it. Not “checked it and missed it”. I never looked.
The rest after that hint was easy. That is the part that annoys me. It was not a hard box, and I was not sloppy. I was systematic on everything I saw. I just did not see all of it.
Why exactly that one
This is the interesting question. I worked through the other services completely. Why was Samba not part of the work at all, when my methodology says check every service?
I think it comes from the two months before. In the eJPT material, SMB shows up a lot, but almost never as a service with a vulnerable version. It was the thing you enumerate. You list shares, you find files, you get users, you spray credentials. Samba was a source of information for me, not a target.
So I built a mental model without noticing: SMB is for enumeration, other services are for exploits. Nobody told me this. The material never says it. I learned it from the distribution of examples I saw.
And a mental model like this does not feel like a rule. It feels like nothing. There was no moment where I decided to skip Samba. My eyes just went past it, because in my head that line was already handled.
This is why discipline alone did not save me. Discipline works on the list you have. The filter runs earlier, when the list is built. By the time I was carefully working off my three services, the mistake was already made, and everything after that felt correct, because it was correct. Just not complete.
The actual lesson
Your training material teaches you two things. The content, which you notice, and what is normal, which you do not.
The second one is stronger. It becomes the filter you look through, and a filter is invisible by definition. You do not see what it removes.
This is not only a pentest problem, it happens everywhere:
- The developer who never writes a test for the error path, because in every tutorial the request succeeds.
- The ops person who checks CPU and memory when something is slow, because that was the problem the last five times.
- The reviewer who reads the new code carefully and never the deleted lines.
In all three cases the person is not lazy. They are pattern matching on a set of examples that was not complete. And it works most of the time, which is exactly why it survives.
For me the uncomfortable part is: I can not trust my own feeling of “this one is not interesting”. That feeling is not analysis. It is statistics from my last two months.
What I changed
Nothing clever, just more boring.
The list is a checklist, not a note. Every service from the scan gets an explicit mark: checked for known vulnerabilities, yes or no, with what I found. Before I try the next idea, no service is allowed to have an empty mark. Writing “nothing found” is fine. Writing nothing is not.
Version check is mechanical, not by interest. I do it for every version string, in the order of the scan, also for the services I “know”. The moment I select which ones deserve a look, my blind spot is selecting, not me.
“I am out of ideas” means read the list again first. That was the real moment. My list looked finished to me, so being stuck felt like a dead end instead of a signal. Now the first reaction is to compare the checklist against the raw scan output line by line, before I look anywhere outside.
Reading a hint is fine, but note what it costs. I do not think taking a small hint from the official writeup was wrong, it is a lab and I was stuck. But this hint bought me something I already had. That is the expensive kind, and it only shows up if you write down afterwards where the answer actually was.
Small honest note
I do not think the eJPT did something wrong here. It is beginner material and it has to simplify. Every course, every lab platform, every certification shows you a selection. That is what makes it teachable.
But a selection is a bias. So the question after finishing any training is not only “what did I learn”. It is also: what did this material show me so rarely that I stopped looking at it?
I do not have a full answer for my own case yet. Samba was one. There are probably more, and I will find them the same way, by walking past something obvious and feeling stupid afterwards.
That is fine. Better here than on a real engagement.
Next up is HTB Academy’s Linux Fundamentals module, which is much deeper than what I did until now. I am pretty sure it will show me a few more of these. At least it already contained some bits and pieces that were new to me.