I only recently joined and have been focusing on working through the Starting Point lab myself. Something I’ve noticed as a common thread in the walkthroughs is that they seem very rushed and make a lot of assumptions, often skipping steps or, conversely, sending you down rabbitholes that you don’t need to go down. I think it’s assumed that you’ll search around to find whatever you’re missing, or that you’re able to troubleshoot linux package issues independently when something doesn’t work, or that you know enough to know when they’re misleading you or making you work too hard. That’s… definitely not the case for everyone doing Starting Point, which is supposed to be (imo) an introduction to cyber security to help you get your feet wet.
Personally, I can mostly muddle through, but it’s also frustrating to have to fight against your tools instead of being able to learn, so in the interest of accessibility, I have some general tips for Starting Point. Just gonna post this here but #4 in particular will be of interest to you I think.
- This isn’t really made explicit, but the machines are intended to be done in order from top to bottom. First archetype, then oopsie, vaccine, shield, and finally pathfinder. If you try to do what I did at first and target all the Windows machines first, you’re in for a bad time and will need to brute force stuff and do other more advanced techniques and you’ll probably get nowhere if you’re like me (inexperienced).
- Keep good notes as you go, and save the outputs of your scans etc. This is just good practice for pentesting in general. Make a folder for each new machine and throw everything in there. I use CherryTree because it lets me do a tree structure and easily copy in screenshots I take as I go. Helps you stay organized and remember things you find, like credentials for instance. For SP in particular, it seems they want you to do a chain of hacks where you get credentials for the next machine from the previous one.
- There is a set of credentials you’ll find on a particular machine that have an IP paired with them that is incorrect. Ignore it. The creds you find there are intended to be used on the next machine down, though the IP doesn’t match. I think they just never updated this.
- Make sure that your machine is using python 3, with pip3 installed. Something I keep running into as I try to learn infosec in general is that everything is in python 2. Very frustrating. If you see someone just calling “python” rather than “python3” in a video for instance, that’s python 2, the code isn’t going to work anymore. Anyway, on the kali repos, pip3 is “python3-pip”. Once you have pip3, use that to install any modules you see missing when you run python scripts. This is probably the solution to your problem. Try using pip3 to install whatever “digestmod” is (syntax: sudo pip3 install digestmod) and take a look at the output. In general, this is a good path to try to get something working on linux. You’ll often have missing dependencies or, especially in a pentesting context, missing modules or libraries from whatever code you’re trying to run, and you gotta just go track that stuff down one by one. In the case of Python, pip3 is your friend here, as that’s what makes sure Python can actually access and use code library modules properly (I think). Don’t just go cloning githubs and trying to compile them willy nilly, you’ll probably break stuff lol.
- Be on the lookout for unnecessary instructions. This one is going to be tougher for a raw beginner to spot. But for instance, on ARCHETYPE, after setting up your nc listener, the walkthrough tells you to “use ufw” to make a new rule in your firewall to allow the connect-back (though it doesn’t tell you that’s what you’re doing with that line). You absolutely do not need to do this. Also you probably don’t even have ufw installed; it’s the Ubuntu firewall tool lol. The SP walkthroughs have more stuff like this in them, so if you’re following along and you see shit that doesn’t make sense, stop and take a closer look. Google / duckduckgo what they’re talking about, see if you can understand the theory. Find the packages they reference. A lot of times they’ll point you to using some specific tool when you don’t need to, for instance gobuster. You can easily use ANY spidering tool there, like dirb, dirbuster, or even spidering with zap or burpsuite. Don’t fixate on the particular tool you’re pointed to so much as the end goal you’re aiming at. Especially since you can tell from a lot of the screenshots of code that whoever wrote the walkthroughs was on a Mac. So the commands they run are going to be different. Like them just being able to type “mssqlclient.py” instead of having to invoke python3 first, for instance. If you know of a tool already that will help you do what they’re trying to get you to do, don’t get lost down the hole of trying to install and get a new package working. Instead, use what you already have that you know is installed and configured properly already. Installing stuff on linux is non-trivial, haha. It can easily consume your day and frustrate the hell out of you if it’s something obscure or you run into problems with dependencies. It’s for this reason that I just use out-of-the-box Kali for HTB.
- Finally, something I’ve found incredibly helpful is to do each SP machine multiple times. Your first time through, you’ll have to muddle around and the solutions will seem contrived or even random to you. “How did they know to check THERE?” you’ll ask yourself (the answer being basically, you just figure out where to look for stuff based on experience, I think). But what you’ll want to do is let the machine rest for a day or two so you mostly forget stuff about it, then go back in from scratch and try it blind again. Keep an eye out for contextual clues and try to arrive at the reasoning required to get to the next step. For instance, if you’re internal on the host and you know you got in via web exploitation on HTTP, think “okay, where are the website’s files here locally?” Maybe there’s something juicy there. If you get in on a particular user, find out their privileges, see what they have access to and go poke it. This is another thing where keeping notes will help you, as will trying to make little write-ups for yourself after that summarize what you did and in what order and what you found using which vulnerabilities etc. Just be mindful of spoiler policies on the site, keep these for yourself.
So yeah. Good luck! By the time you get through SP, you’ll have a lot more confidence and knowledge, but it may take a couple weeks if you’re starting from only a general linux background like I am.