Hacker

The real work looks very little like the usual picture. Most of the time is spent reading: documentation, code, server responses, configuration. The job is to rebuild how somebody thought the system worked and then find the place where that model and reality part company. That is where the flaw is, nearly always, and not in a tool.

That is why the techniques are organised into phases rather than tricks. First comes gathering information about the target, which is reconnaissance, and a good deal of that information is public, which is OSINT. Then comes finding a way in, obtaining more permission than you started with, which is privilege escalation, and moving from one machine to the next, which is lateral movement.

And a large part of it is not technical at all. Persuading a person to open something or approve a request is social engineering, and it remains the most cost-effective way in that exists, because it does not depend on the software having any flaw whatsoever.

The convention is to sort them by colour. The white hat works with permission and hands what they find to the people who can fix it. The black hat gets in without permission and uses what they find for their own benefit. The grey hat is the uncomfortable category: in without permission, but telling you afterwards, so the intent can be good while the access is still unlawful.

The classification is useful for explaining, not for deciding. In an actual case what settles the matter is not the colour of the hat, it is a document: if there is prior signed authorisation from whoever owns the system, with the scope written down, there is a piece of work; if there is not, there is unauthorised access, however well meant the resulting report.

Spanish-language press tends to write “pirata informático”, which is how a lot of people search. It is imprecise and it gets in the way: it puts the person who researches with permission and the person committing an offence into the same word, which is exactly the distinction that needs making.

People looking to hire a hacker usually want one of two very different things, and separating them before asking for a quote saves everybody time. One is finding out whether their systems hold up under attack, and that can be bought: it is a penetration test or a red team exercise. The other is recovering access to somebody else’s account, reading somebody’s phone, or getting into a system that is not theirs, and that cannot be bought: it is a crime, and whoever offers it is running a scam, committing one, or both.

A legitimate engagement is recognisable by what it asks for before starting. It asks for authorisation signed by somebody entitled to give it, for the scope in writing with what is in and what is out, for a time window, and for a contact route to stop the work if something breaks. Together those are the rules of engagement, and without them the work does not begin.

And it ends in a report you can act on: every finding with the steps to reproduce it, the impact it carries and what has to change, plus a retest once the team has fixed it. A hired hacker who delivers unverified tool output has not done the job.

The same chain, seen from outside, goes by other names. Some people specialise purely in obtaining the way in and selling it on, which is the initial access broker, and others buy that access to monetise it. That specialisation is what turned attack into a market, and it is also why the interval between the way in and the damage is now measured in days.

Not all of it comes from outside, either. Somebody with legitimate access who misuses it is an insider threat, and they need none of the techniques above because they are already in. It is the case perimeter controls cover worst.

The practical conclusion is the one that gives this entry its point. Hiring an ethical hacker is not hiring someone dangerous and putting them on a lead: it is paying for somebody to do, with permission and with a report, exactly what the other one would do without warning. Technique does not separate the two. Permission does.