[erganemic]

I've had a background interest in getting involved in CTFs for a while now, but haven't yet made it a point to overcome the activation energy to do anything beyond Overthewire's Bandit. I'd be interested in hearing how other people coming from a pure software engineering background (+ associated Linux knowledge) got started. I run into a dependency graph where I'd like to join a team and learn from others, but I need some baseline skill to do that, which requires either a top-down approach of what feels like memorizing tricks that may-or-may-not apply to a given box, or a bottom-up approach of spending a ton of time learning about the fundamentals of networking and file systems (which is often nontrivial to convert into techniques that can be used in CTFs). I know for stuff like this the key is to just get started, and the understanding will follow, but I'm curious if anyone has any recommendations for how to do that.

[asciii]

I think you might like to watch this YouTube Video on "How The Best Hackers Learn Their Craft"(https://www.youtube.com/watch?v=6vj96QetfTg). David Brumley speaks about his experience with getting students integrated but the skill grid he shows might be what you're looking for.

At some points, it is just getting to the answer no matter the method (algorithm, memory, quick trick etc.) At the end of the day, it's still just problem solving and learning existing tools better.

[kriro]

For pentesting (not bounties) I can recommend HackTheBox + IppSec on youtube. Watch a couple of his videos of retired machines to get an idea of the typical workflow (scanning, what to look for etc.). Focus on one type of easy machine (Linux) and then start working on the machines. Set a target to get all easy machines at first and go from there.

I set up a Kali VM to do all my HTB stuff from and keep a notebook of my typical flow so the process is pretty simular for each box I attack. The easy boxes usually require you to somehow identify a waekness and use a ready made exploit for it (or some easily reproducable steps). Privesc is usually also pretty straightforward. However they are not supereasy by any means if you've never done this.

[fiveg]

I'm in a very similar position. Right now I'm working on tryhackme.com's junior pentester learning path. It's OK, but I think I'd be more excited to find a project or goal to focus on instead of a shallow overview of lots of topics (even though the context feels valuable). I'll finish the course, but I think I'll be done with tryhackme after that and go back to looking for something more specific the dive in to.

[EddySchauHai]

It’s a little expensive but have you checked out the OSCP cert? It’s the only certificate in tech that I think is almost unanimously accepted as a decent one as it’s so practical. That might help give you a goal to keep learning? I’m going through it myself at the moment.

[fiveg]

I have thought about this actually. It sounds really interesting but at $1500 for 90 days of access I'll need to make sure to find a time when I don't have much on my plate for 90 days. How much time per week do you feel you need to dedicate to it? Are you enjoying the process?

[EddySchauHai]

They’ve changed this recently actually, its $799 for 12 months of lab access and some entry level certs. I signed up for this and will pay the extra for the OSCP once I’m ready!

[kdbg]

This is a bit of a common trap, the idea that to do anything you must know everything. When you read writeups you see people just going from some bug to exploit and incorporating obscure bits of knowledge to make it happen. It feels like they must know everything. The reality is they probably spend hours or days banging their head against a wall having an intuition that _something_ is wrong but no idea how to abuse it or that there must be something. Spending hours researching until they can connect the dots. Those hours of frustration are not captured very well in most writeups.

> I know for stuff like this the key is to just get started, and the understanding will follow, but I'm curious if anyone has any recommendations for how to do that.

The single tip I give anyone getting started is:

Follow all the rabbit holes.

Seriously, all of them. Any time you have some random question come up, "Would doing X be vulnerable", "Could I exploit Y feature", "Why didn't this writeup author do Z", "How does A work", "Why send B this way instead of this way" ... all of them. When you have the question, just go spend the time to figure it out. Every rabbit hole you go down, even if it ends up being a dead end, is adding bits and pieces to your knowledge. Over time you build up an immense library of random bits of knowledge that you can draw from in the future.

I have a blog post about getting started with manual vulnerability auditing: https://dayzerosec.com/blog/2021/05/21/from-ctfs-to-real-vul...

While I wrote that with an eye towards doing binary-level exploit development against modern targets, the advice for doing manual auditing is pretty universal. It's like how to learn to program you actually have to write code, reading about writing code isn't enough. Practice against anything can be useful.

I'll also leave you my favorite vuln research quote:

"Frustration is a key part of exploit research and you must embrace it accordingly"

[_8j50]

I am fighting this battle myself, absorbing and retaining raw knowledge is easy for me but I am not that good at CTFs because I don't practice RE and pentesting enough.

One of my big regrets is spending too much time in chatrooms and forums in my 20s instead of practicing. Now I have less capacity to do that because I do this stuff (and love it) as part of my job, I need a break afterwards.

In CTFs either I get distracted or I follow red herrings because of curiosity and waste time.

One thing that helped me before and I am recently considering is getting rid of TV/netflix/prime and social media (maybe exempt HN? Lol) to help with time.