The external scope came back clean. Every port that had been open on the last engagement was closed now, the client had rolled out MFA across every account that mattered, and the web application had already been through two rounds of remediation since the previous report. Three days into a five day assessment, the team had a login page, a patched CMS, and nothing to show for it.
The foothold that finally landed didn't come from a scanner. It came from a phone call to the helpdesk, and it worked because MFA was never really the thing standing between an attacker and an account: it's a rule that a tired helpdesk technician enforces, and rules enforced by a person under time pressure are the actual attack surface once the technical one is locked down.
Getting there took three stages, and all three are things you can actually learn and get better at, not something that either "clicks" for a personality type or doesn't.
The first is reconnaissance that most pentesters skip past on the way to the technical scope. Job postings tell you what VPN client and ticketing software a company runs before you ever touch their network, because whoever wrote the req wanted the on-call engineer's next employer to already know their stack. LinkedIn tells you who has the authority to approve a password reset and who just processes the queue, and that distinction matters because the pretext you build has to target the second person, not the first: the queue processor has volume and time pressure working for you, the approver has judgment working against you.
The second is pretext construction, and the mistake beginners make is writing a pretext that's interesting instead of one that's boring. A boring pretext, something the target has already half-expected to hear because it matches something actually happening at the company that week, a VPN migration, a forced password rotation, a new ticketing system rollout, gets less scrutiny than a dramatic one. The ask inside it matters more than the story around it: never ask for a password directly, that's the one thing every security awareness training in the last decade has actually managed to stick. Ask for something adjacent instead, a reset link sent to an address you control, or an MFA push approved because "IT is verifying the account after the migration." The technical control holds exactly as long as the human enforcing it doesn't have a plausible reason to set it aside for thirty seconds.
The third is knowing what to do the moment it works, because a foothold that goes nowhere is just an anecdote for the report's appendix. This is where most social engineering write-ups stop, and where most social engineering training stops too, at "here's how you get in," with nothing on what a real engagement does next: privilege paths, persistence that survives the reset that inevitably follows, and documenting the finding in a way that gets the helpdesk process fixed instead of just making one technician feel bad about a call.
None of this is a personality trait. It's a lifecycle you can actually walk through and get better at with repetition, same as any other technical skill, and it deserves the same rigor most people only apply to the exploit development side of the job. Codelivly's Red Team Operator bundle is built around exactly that arc: the psychology and pretext-building volume for stages one and two, then the L1 and L2 material for what a real operator does with the foothold once it lands.
