A vademecum is only useful if it has the same shape as the thing it describes. A list of commands is worthless if you do not know in what order to use them and why that step comes before the other one.
What follows has three parts: the order in which you look at a system, the rules that always apply, and the story of those who opened the way.
Everything described here applies to systems and networks on which you have written authorisation. Without a contract it is not research: in Italy it constitutes aggravated unlawful access to a computer system (art. 615-ter c.p.). The vademecum presupposes authorisation, it does not replace it.
Part 1: the order in which you look at a system
The trade has a rule that is not a stylistic preference: you do not touch anything until you know for certain what you are touching. An assessment that leaves the target in an incoherent state is not an assessment, it is a disservice with a report attached.
1. Authorisation, before anything else
It is not a formality, it is the first deliverable. In writing, with:
the exact IP addresses or domains, one by one, not "the client's network";
- the time window, with the time zone;
what is permitted and what is forbidden (DDoS, social engineering, access to real data, persistence);
- the channel for an immediate stop and the name of whoever responds.
The reason is practical before it is legal: if an alarm goes off during the test, the first question they will ask is "was that expected?". Without a document, the answer does not exist and the work ends there. With the document, the answer is "yes, that was expected" and the day goes on.
Keep it for one year after the end of the engagement. It is the defence you need when the client changes their mind about what was "acceptable".
2. Passive reconnaissance before active reconnaissance
Start from what the target says publicly about itself: names, DNS, certificates, headers, what turns up in search engines, public repositories, photos of screenshots with visible versions.
This phase leaves no traces and it is the one that saves you the most precious time of all. In a real assessment, a good part of the decisive information arrives before you touch a machine, and more often than not from a human being.
3. Map, do not attack
At this point you make two separate lists and keep them separate:
- what is there: services, ports, versions, hosts;
- what is vulnerable: only what you have verified, with the evidence.
Confusing the two is the most common and most costly mistake in the trade. A report that presents a scan as a vulnerability assessment is worth nothing in court and is no use to the client.
4. Verify before writing
For every potential problem, before putting it in the report:
- reproduce it yourself, from scratch, with your own tools;
verify that it is genuinely exploitable in the client's context, not in theory;
measure the real impact: what an attacker gains from it, and what they still have to do afterwards.
A vulnerability that cannot be exploited under real conditions is a theoretical potential. You write it down, you label it as such, and you do not inflate it.
5. The type matters, and it must be stated
Not all vulnerabilities carry the same weight. CVSS helps you rank them, but it says nothing about the impact in the client's context:
an RCE on an exposed server, with default credentials: critical, and often the thing the client must fix today;
a SQL injection that returns a table of names: high, and that does not automatically make it critical;
weak TLS configuration on an internal service that cannot be reached from the outside: low, and it should be said why it is low.
The client does not want a score, they want to know what to do on Monday morning. That is your job, not the tool's.
6. Leave no residue
Everything you touch must return to how it was. Files downloaded, accounts created, services started, logs modified. If by mistake you opened a persistent session on a client machine, the first act is to tell them, not to fix it silently.
This is the point where the quality of a professional is really visible, and not the length of the report.
Part 2: the rules that are not negotiated
There are few of them, and they are the ones that apply in every context, even when nobody is watching you.
Off the record, always. The credentials you find belong to the client and are a finding, not a haul. They do not end up in a file, they do not end up in a chat, they do not end up in a repository.
Secrets found must be rotated. A password discovered during a test is no longer a secret: from that moment it is a public vulnerability. Rotating it is part of the job, it is not a favour.
Do not exaggerate the demonstration. You do not need to take possession of a server to prove that you can. The minimum that demonstrates the point is the right amount; the rest is destruction with an excuse.
Do not publish the detail before it is fixed. A working exploit against a site that is still vulnerable is damage, not research.
Do not destroy the evidence. The logs you delete are the evidence of your activity. You will return to that system in a year and you will need to remember what you had touched.
Part 3: those who opened the way, and why
Here is the interesting part. The question "why were they" almost always has the same answer: because the system was new and nobody was looking at it, and because they had access to the machines and the time to look at it.
The model railway group, MIT 1960
Hacker culture was not born in 1980 and was not born with networks. It was born at the Tech Model Railroad Club at MIT, and it moved immediately into the Artificial Intelligence Laboratory of the same institute. The object was model electric trains and computers, but the posture was already the right one: understand how something works in order to use it better.
The two gestures that became legendary were not attacks on anyone: they had a campus police squad car on the roof of the Dome, and the Dome had been turned into R2-D2. The point is that there was no enemy. They were students with legitimate access to their own machines, and the fun was in understanding, not in breaking.
That distinction is still the one that matters. Anyone who at the time acted in a way that got them called a cracker was a different category, and anyone who today uses "hacker" for both is an imprecision worth pointing out when you hear it.
Ken Thompson and Dennis Ritchie, 1969
Bell Labs, after AT&T pulls out of Multics because the project was too complex. They make the small version: a single-user system, which they call Unics — one Multics — and which will become Unix.
The reason they are names for a vademecum is that they chose the path that made the system readable and portable. In 1973 Ritchie rewrites the kernel in C, the language he and Brian Kernighan were building to replace assembly: from there Unix carries itself onto different machines with minimal changes. The idea that everything is a file and that programs are small and combinable is a legacy that Linux, macOS and Android still carry.
They did not "attack" anything. They built better.
Gary Kildall, 1974
CP/M, the first widely adopted operating system for microcomputers, written by a single person for the Intel 8080. From CP/M come the drive letters of Windows, the term BIOS, the three-character extensions, and reserved names like CON and NUL that even today Windows will not let you use as file names.
It is a name for a vademecum for a precise reason: it made software portable onto hardware that did not yet exist. It is the same lesson as Ritchie, ten years earlier.
The phone phreaks and John Draper, 1969-1971
Before personal computers existed there was telephony. The AT&T network signalled the state of the lines with a 2600 Hz tone sent in band, that is inside the same line that carried the voice: whoever emitted that tone at the right moment gained control of the call. No vulnerability was needed: you just had to speak the language of the system.
The general lesson was the moral: do not try to penetrate, try to understand. Draper's group used tape recorders and a Farfisa organ to reproduce the tones, and made free long-distance calls to understand how the network worked.
In 1971 Esquire publishes an article by Ron Rosenbaum, *Secrets of the Little Blue Box*. Here is the point where the culture meets the industry: Steve Wozniak reads the article, finds Draper, and the two of them build the blue box. Jobs and Woz sell it door to door on campus. Jobs would later say that without the blue boxes there would have been no Apple. Draper would end up hired by Apple.
That is the reason the blue boxes are in the history of this trade: not because they were a clever attack, but because they were the most honest way to learn a network.
Richard Stallman, from 1983
Stallman is discussed at length in Open source: why paid software benefits from it and there is the date and the reason. Here another point matters: the definition of hacker he gives, which is not about crime but about curiosity as a working method. A hacker is someone who enjoys exploring the limits of a programmable system, not someone who wants to destroy.
Kevin Mitnick, 1963-2023
The name the media use for "hacker" is also the first great misunderstanding of the trade. Mitnick did not design an attack: he understood how telephony worked, and got there through social engineering more than through technique. In his 1995 testimony to Congress he describes having obtained access to IRS and Social Security Administration systems without ever touching a computer: phone calls to employees, with the right jargon, passing himself off as a colleague in trouble.
Arrested in 1995, five years in prison, a plea bargain in 1999, and release in 2000. He died in 2023.
The two facts to remember are not the prison: they are that his main method was persuading people, and that in the end he became a security consultant. It is the proof that the same ability, used within the rules, produces a professional.
The distinction that holds
All these stories have one element in common, and it is more important than the chronology.
The difference that matters, and that holds up better than white hat / black hat labels, is between those who understand and have not yet decided and those who have decided. Labels are convenient and imprecise; the need to understand is common to everyone, and the decision is what changes.
And this is why the vademecum has this shape. It is not thirty commands to memorise: it is four phases in order and five rules that are not negotiated. Commands change every year, and whoever learns them by heart is defenceless.
The trade does not consist in knowing what can be done. It consists in knowing what is done, and in knowing what is not done — every time, with your signature underneath.
The vademecum in one line
If only one thing remains from all of the above, it is this: look first, touch afterwards, and do not leave the door more open than you found it.