(untitled)

Are CTFs just a meme compared to real-life engagements? I do feel like I’ve learnt quite a bit, but most CTFs are rather unrealistic, and I get the feeling that I’m really just solving puzzles when playing them.

>Are CTFs just a meme yes >compared to real-life engagements? real life is not ghost in the shell. you don't connect to the mainframe, jump through a few hoops and then break in. the real world is messy and chaotic, and when you get pwned it's either random undirected attacks to specific vulnerabilities, or an attacker who can physically interfere with your system.

>>28276 why do you feel compelled to comment on stuff that you know nothing about, is it dunning kruger or what

>>28275 very open ended question, what's below is just an opinion, sorry if it comes off as rambling unironically, what ctfs fail to train you in is what's most critical to your success in real life engagements in this context by ctfs I'm talking about normal day to day machines (vulnhub, htb, thm), "popping boxes" they mostly boil down to: >getting a little understanding of the tech stack you're attacking (very good if you're looking to explore new tech stacks, have you ever fuarrrked with apache tomcat before? maybe spring boot? maybe whatever's even more obscure?) >using already public ndays with POCs already in github >or manually beating the soykaf out of a custom web app >whatever subtle/obvious misconfig This is absolutely not the case IRL unless you are a junior pentester asked to run a compliance sweep for unpatched GLPI instances or perform an active directory audit. in a more realistic engagement you *may* find a vulnerable service, the CVE is right there, but there are no POCs, or the POCs only exist for a certain setup/architecture. congratulations, now you have to man up and actually begin learning reverse engineering an exploit development for real, to write or rewrite an exploit based on CVE details and , and possibly, if you're sexy enough, begin working towards popping 0days, this is mostly books, videos, and a soykaf ton of practice, not dumb boxes. then comes real malware development against live targets (which boxes will never have), most post exploitation and C2 shenanigans in boxes constitute you throwing meterpreter, cobalt or sliver at it, because of course it's either a Linux box without AV or a windows box with defender turned off. this is not the case in real life, one of the most frustrating aspects of a real engagement is how to bypass AV and/or EDR, maybe even designing your own implants. and then you have to tackle another issue with malware development, sure, your implants can bypass AV, but are your implants actually good? are they reliable as a *product* ? in other words, are you actually a decent programmer? so to recap, they are useful for: >introducing you to services you've never seen before >web app practice (if you're actually doing quality boxes) not so useful for: >reverse engineering, exploit dev, malware dev, phishing, AKA the that will get soykaf done my most inflammatory opinion is that pentesters who aren't able to write exploits and decent malware are just glorified sysops. whether they are a waste of time is up to your evaluation based on what i said, i think they're fun.

>>28275 I've never encountered a CTF with a python executor baked into the frontend of a server, but I have encountered such things in real life. Random credentials and account details scattered across globally accessible files. CTFs in my experience are far more technical and educational.

>>28278 a very solid answer to the OPs question >my most inflammatory opinion is that pentesters who aren't able to write exploits and decent malware are just glorified sysops The notion of "you can be successful in cybersecurity without knowing how to code" is just flat out wrong if you want to do more than just basic bitch work.

>>28275 The problem is that AI can now hack a lot of things on its own, and this makes people feel discouraged that hacking will no longer be needed except by a couple of schizophrenics with bachelors in mathematics who will write special AI for hacking. P.S Im not in /sec/. I want to start myself but because of AI I'm a big pessimist.

>>28287 >Im not in /sec/. I want to start myself but because of AI I'm a big pessimist. Before AI you would have been saying why bother when there will always be people who are better than you. Just do it, or forget about it.

ctf can be very close to the real thing. just look at encrochat hack. hacking is always messy and opportunistic >Revealed: Cyber spies used malware from GitHub to hack EncroChat cryptophone network >Computer Weekly reveals for the first time how French cyber spies hacked EncroChat phones used by organised crime groups

I won't go into it too deep, but as a professional with experience in practically all of the components mentioned in the thread, here's the lowdown: it's a miracle the average idiot webdev is able to produce secure services only by merit of their frameworks saving them, and they still find ways of making them insecure services are often not kept up to date, thus not secure a lot of hacking is low-hanging fruit and social engineering ai is extremely capable and at the same time completely useless, it struggles with long-horizon tasks and needs a human in the loop to steer it a human with a broad understanding of web/sec and access to ai is now able to do serious pentesting