#patience being tested today working with new pentesters. young, dumb and full of... they get on a box for like 3 seconds and start spraying every exploit known to man at it. seriously might take away their Kali instances and make them use Gentoo or Debian vanilla tomorrow. teach them that enumeration is more important than jackhammering a box like your junior prom date.
@tinker made them all install deb9 and install gobuster. no other tools. spun up a network and had them enumerate. amazingly, still tried to exploit. exploit-db was constantly pulled up. not sure how to reign this in. I told them "no exploiting" but they wouldn't listen. any tips?
@tnkr I am not qualified to answer this question, but explain scope to them? This is your job. These are your tools. Working out of scope is a failure and potentially a crime if it is someone else's network. Give the task a hard failure state and attach stakes to it.
In this case, the job is enumeration and the scope explicitly disallows exploits. If they move out of scope then it is a hard fail. Start over.
Plenty of times where we can only run recon. No exploitation attempts or we (best case) lose a client and (worst case) get sued or go to jail.
So I’d start with a specific objective (enumerate network, hosts, services) with specific scope (no exploitation or brute force). Don’t constrain tools, but limit actions.
Have them learn what you need them to learn, then role play the next step. Fingers off keyboard.
Ask them, “okay. What do we know so far? Alright. What’s our goal again? Okay. How do we get there? What would you or you do?”
Then go through a guided discussion where you teach, discuss ethics, scope, etc.
Once happy, fingers back on keyboards and go.
The instinct is to rush in without a plan and try to use the most complex components of 3ds max assuming that's how the best do it on a whim.
While good to learn those tools on the side, it's not best when there's an actual objective or client design to build.
The professor would have us draw out a model by hand each step of the way so we understood what we actually needed to do.
@tinker @tnkr @malachiteOS maybe have them submit a written plan with various steps/approaches for a set objective prior to getting behind the keyboard. Then they can/should only execute those actions or hard fail. It might also give you prior insight on their thought process.
From a blue perspective, it's a change request or project plan prior to action that my people need to submit for anything.
Alternative if you want to burn a day to hammer it home:
Let them run metasploit like mad against a basic hardened system, let them learn the hard way that it's going to be a long, painful waste of time to rely on metasploit and exploitation.
In a similar position to hypothetical Mentees, learned this the hard way while working on internal machines (with authorisation) that even a basic config will typically beat standard metasploit.
@tnkr If failures persist or they seem frustrated, ask them what their plan is. Why are they still using these tools that are out of scope? Do they know what tools they should be using?
No need to hammer on them unless they become indignant. Nudge them in the right direction. Once they know why they are failing then they will have to dig for their success.
A Mastodon instance for info/cyber security-minded people.