Ethical Hacking Notes | B.Sc. (Computer Science) Semester 5 | Mumbai University | munotes

What "no viva" means for you

The first-year Computer Science Practical (item 6.5 (R)) reserves six marks for an oral examination. This scheme does not. Item 6.33 (N) prints a mid-term practical, a journal and a two-hour final, and no oral component anywhere. This book therefore ends each chapter with a section called "Test yourself" rather than pretending there are viva marks to win.

That the questions are not for viva marks does not make them optional. The same understanding they build is tested in two places that do carry marks: the journal's concept and defensive-point lines, where you must explain in your own words what a practical demonstrates and how the technique is detected and prevented, and the practical examination itself, where the examiner walking the lab will ask you to explain what you are doing. A student who can answer the end-of-chapter questions can write the journal's understanding lines and can explain their work to the examiner, so the questions feed directly into the parts that are marked, even though there is no separate oral.

The journal, and the house form this book uses

The journal is the record of your practicals, and it is worth marks twice: five of its own, and it is your ticket into the final. An examiner certifies it, so it must be complete and it must be yours.

Every practical in this book is written up in the same shape, and you should copy that shape into your journal:

1. Aim. One line: what the practical demonstrates.
2. Concept. Two or three sentences in your own words on the idea behind it. This is where the marks for understanding are.
3. Tools and setup. What you used, and on whose system. For this subject that is always your own machine, or a lab machine you have been given, or a system you have written permission to test, and never anything else. The next chapters explain why that line is the whole subject.
4. Steps and observations. What you did and what you saw, with the output pasted or described.
5. The defensive point. For every attack technique, one line on how it is detected and one on how it is prevented. In this subject a write-up that shows only the attack is an incomplete write-up.
6. Conclusion. What you learned, in a sentence.

The reason the form is worth following exactly is that it is built to earn the marks the scheme actually awards. The concept line is where the understanding marks live; the tools-and-setup line records the authorisation that makes the practical lawful; and the defensive-point line is what turns an attack write-up into the defensive account this subject expects. A journal of bare steps with no concept and no defensive reading is a weaker journal even when every step is correct, because it omits the two things the subject is marked on.

A worked example of a journal entry

Suppose the practical is "score a published vulnerability with CVSS" (a later chapter). A complete entry reads:

Aim. To turn the characteristics of a published vulnerability into its CVSS v3.1 base score by hand and by program.

Concept. CVSS is a way of turning a vulnerability into a number from 0 to 10 so a team can decide what to fix first. It scores how a flaw can be reached and how much damage it does, not whether anyone has been attacked.

Tools and setup. A calculator and a short program, on my own lab machine; no system belonging to anyone else is touched, because scoring a published vulnerability uses only its public description.

Steps and observations. Wrote the vector describing the vulnerability; computed the sub-scores; obtained the base score; confirmed it with the calculator and against the public vulnerability database, which lists the same score.

The defensive point. A high base score tells a defender to patch this early. It is detected by a vulnerability scanner reading version banners; it is prevented by keeping the software patched.

Conclusion. The score is reproducible, which is the point of a standard.

That is a full entry: an aim, the idea in plain words, the authorised setup, the work, the defensive reading, and a conclusion. Nothing in it is an attack on anyone, which is exactly what the subject asks for.

What beginners get wrong

• Treating this as an end-of-term subject. Fifteen internal marks are decided at a mid-term practical and the journal accumulates all term, so most of the paper is earned before the end; starting late forfeits marks already awarded.
• Neglecting the journal until the deadline. It is worth five marks and is the compulsory ticket into the final, and it must be certified as complete and yours; a journal rushed at the end risks both the marks and eligibility.
• Ignoring the 80 per cent rule. At least sixteen of twenty practicals must be completed to appear at all, and this cannot be made up at the end, so falling behind on practicals can bar you from the examination however well you know the theory.
• Assuming no viva means no explaining. The concept and defensive-point lines in the journal and the examiner's questions in the lab both test the same understanding for marks, so the end-of-chapter questions matter even though there is no separate oral.
• Writing attack-only journal entries. A write-up showing only the attack, with no concept and no detection-and-prevention line, is incomplete in this subject, which is marked on understanding and defence.
• Reading "individual passing" as a total. You must reach the pass mark in the internal and the external separately; a strong internal cannot rescue a failed external or the reverse.

Quick revision

• 50 marks: internal 20 (mid-term practical 15, journal 5), external 30 (a two-hour practical, Q.1 Module 1 for 15, Q.2 Module 2 for 15).
• To appear at all: a certified journal, and at least 16 of 20 practicals done.
• Individual passing: 40 per cent in each of internal and external, separately.
• No viva in this scheme; but the journal's concept and defensive-point lines and the examiner's lab questions test the same understanding for marks.
• Every journal entry: aim, concept, tools and setup (on an authorised system only), steps and observations, the defensive point (detection and prevention), conclusion.

Test yourself

1. How many marks is the final practical examination, how long is it, and how is it divided between the modules?

Thirty marks, two hours, split 15 for a Module 1 question and 15 for a Module 2 question.

1. What two conditions must be met before you are allowed to sit that examination?

A certified journal, and at least 80 per cent (sixteen of twenty) of the practicals completed. Both accumulate over the term and cannot be made up at the end.

1. Does this course carry viva marks, and does that make the end-of-chapter questions unimportant?

No, item 6.33 (N) prints a mid-term practical, a journal and a final practical, with no oral component. The questions remain important because the same understanding they build is what the journal's concept and defensive-point lines and the examiner's lab questions test for marks.

1. What does "individual passing in internal and external" mean?

You must reach the pass mark in each part separately; a strong internal cannot rescue a failed external or the reverse.

1. Why does the examination scheme itself tell you the register this subject expects?

Because it marks the concept and the defensive reading of each practical, not a demonstration of a break-in, and the practical paper asks you to demonstrate and explain rather than to cause harm, so the scheme already states that the subject is about defence and understanding, which is why this book teaches every attack with its detection and defence and writes up every practical defensively.

Read that table and you have read the practical content of this course. Scanning and access fall under (a). Enumeration and data extraction fall under (b). A denial-of-service test falls under (e) and (f). Malware analysis that escapes its sandbox could reach (c).

So what stands between a penetration tester and liability under section 43? Only the opening words: without permission of the owner. Permission is not a nicety or a professional courtesy. It is the entire legal difference between the profession and the crime.

Three things section 43 does not require, and why each matters

This is where students lose marks, and where careless testers lose their liberty. Section 43 does not require:

1. Damage. The section is headed "Penalty and compensation for damage", but clause (a) is satisfied by access alone. You need not have broken anything.
2. Dishonest intent. Curiosity is not a defence. "I only wanted to see if it was possible" describes a state of mind that section 43 does not ask about.
3. Success in the ordinary sense. Securing access to a computer resource is enough; you need not have reached anything valuable.

Put those together and the rule is stark: touching a system you do not have permission to touch is already a civil wrong, whatever you did next and whatever you meant by it. The three sentences students most often offer, "I only looked", "I was going to report it" and "nothing was damaged", are answers to questions the section never asks.

Section 66: when the civil wrong becomes a crime

Section 43 is civil: you pay compensation to the person affected. Section 66 takes the same list of acts and adds a mental element:

If any person, dishonestly or fraudulently, does any act referred to in section 43, he shall be punishable with imprisonment for a term which may extend to three years or with fine which may extend to five lakh rupees or with both.

The Act does not leave those two words to ordinary meaning. Its Explanation borrows them from the Indian Penal Code: "dishonestly" has the meaning in section 24 IPC (doing something with the intention of causing wrongful gain to one person or wrongful loss to another), and "fraudulently" the meaning in section 25 IPC (doing something with intent to defraud).

So the structure to memorise is a ladder, and the examiner asks you to climb it:

An ethical hacker with written authorisation stands on rung 0. Remove the authorisation and they are on rung 1 the moment they touch the system, and a court may place them on rung 2 depending on what it infers about their purpose.

A worked example

Riya is a final-year student. Her college's result portal is at results.college.test. She notices that changing a number in the address shows another student's marksheet.

Case 1: she has written permission. The college's IT head, who is plainly "in charge" of the system, has given her a signed letter authorising her to test that portal during October. She finds the flaw, writes it up, reports it. Rung 0. Section 43 does not apply, because she is not "without permission of the owner". She is doing exactly what this course trains her to do.

Case 2: she has no permission and reports it anyway. She finds the same flaw uninvited, tells nobody else, and emails the IT head. Her motive is good and the college may well thank her. Rung 1 nonetheless. She accessed a computer resource without permission, and section 43 asks nothing about her motive. Whether the college pursues it is their choice, not her right; the law has already been engaged.

Case 3: she has no permission and downloads the marksheets. She saves two hundred students' results. Now clause (b) is engaged as well as (a), and if a court finds she acted dishonestly or fraudulently, rung 2 and section 66 follows, with imprisonment in view.

Case 4: she tells a friend how to do it. Clause (g), providing assistance to facilitate access in contravention of the Act. Passing on the method is itself an act the section names.

The technique in all four cases is identical: change a number in a URL. Only the paperwork and the purpose differ, and they are the whole of the law.

Distinctions that carry marks

The most examinable line in the whole chapter: section 66 does not create new conduct. It re-describes section 43's conduct with a guilty mind attached. A student who says "section 66 is about hacking and section 43 is about damage" has it wrong in both halves.

What beginners get wrong

• "It was insecure, so testing it is fair." The owner's carelessness does not confer permission. Section 43 turns on permission, not on how weak the system was. A door left unlocked is still not an invitation.
• "I reported it, so I am protected." Reporting is good practice and matters to responsible disclosure, but it is not a defence to unauthorised access. The safe route is to obtain permission first, through a bug bounty or a written scope.
• "I only scanned, I did not break in." A scan secures access to information about a system and engages clause (a) on its face. Whether a scan alone would be pursued is a separate, practical question; a professional never relies on the argument, because they never need to.
• "The company is abroad, so Indian law does not apply." Section 75 gives the Act extra-territorial reach where a computer located in India is involved, and the target's own country's law applies as well. Crossing a border multiplies your exposure; it does not remove it.
• "My college project counts as authorisation." It does not, unless the system's owner has said so in writing. An assignment authorises you to learn, not to test somebody else's systems.

Limits, and what the section is criticised for

Two honest observations a good answer can carry.

First, section 43 is very wide. Clause (a) plus "without permission" catches conduct most people would not think criminal, including a security researcher acting in good faith. India has no general "safe harbour" for good-faith research written into the Act, which is why bug bounty programmes (a later chapter) matter so much: they supply, by contract, the permission the statute demands.

Second, the line between clauses is blurred by modern systems. Accessing a cloud service touches computers in several jurisdictions, and "the owner" of a system may be a chain of providers. The professional answer is not to reason about it afterwards but to name the systems in the scope document beforehand.

Quick revision

• Ethical hacking = authorised + scoped + lawful. Remove authorisation and only the legality changes; the technique is the same.
• Section 43: doing any of acts (a) to (j) "without permission of the owner" is a civil wrong; compensation follows. No damage and no dishonest intent are required.
• Acts (a) to (j) cover access, copying data, contaminants, damage, disruption, denial of access, assisting another, charging to another's account, destroying or altering information, and source-code theft.
• Section 66: the same acts done "dishonestly or fraudulently" are criminal: up to three years, or up to five lakh rupees, or both. The words take their meaning from ss.24 and 25 IPC.
• The ladder: permission (lawful), then no permission (s.43, civil), then no permission plus dishonesty (s.66, criminal).
• Good motive, absence of damage and "I only looked" are answers to questions section 43 does not ask.

Test yourself

1. What single thing separates ethical hacking from an offence under the IT Act?

Permission of the owner, in writing and within a defined scope. The techniques are identical on either side of the line; only the authorisation differs.

1. State the relationship between section 43 and section 66.

Section 43 makes a list of acts done "without permission of the owner" a civil wrong attracting compensation, with no need to prove damage or intent. Section 66 takes the same acts and makes them a criminal offence when done dishonestly or fraudulently, punishable with up to three years' imprisonment or up to five lakh rupees or both. Section 66 adds a mental element to section 43's conduct; it does not describe different conduct.

1. A researcher finds a flaw in a stranger's website, takes nothing, damages nothing, and emails the owner. Has any provision been engaged?

Yes. Section 43 is engaged by securing access without permission; it does not require damage or dishonest intent, so neither the absence of harm nor the good motive prevents liability. Section 66 would require dishonesty or fraud, which is absent here.

1. Which clauses of section 43 does a denial-of-service test engage, and why is such testing usually forbidden in an engagement?

Clauses (e) (disrupting a computer, system or network) and (f) (denying access to an authorised person). It is usually forbidden because a genuine disruption causes real harm to real users even when well intentioned, so rules of engagement exclude it.

1. Why is "the system was insecure" not a defence?

Because section 43 turns on the absence of permission, not on the security posture of the target. The owner's failure to secure a system does not amount to permission to access it.

Sections 66B, 66C and 66D: stolen resources, identity and personation

These three are the ones a penetration test can blunder into within an hour of starting.

Section 66B, dishonestly receiving a stolen computer resource. Dishonestly receiving or retaining any stolen computer resource or communication device, knowing or having reason to believe it is stolen: up to three years, or up to one lakh rupees, or both. A tester who is handed a dump of credentials from an unexplained source is in this territory, which is why data used in an engagement comes from the client or from the tester's own lawful collection, never from a breach dump of unknown provenance.

Section 66C, identity theft. Fraudulently or dishonestly making use of the electronic signature, password or any other unique identification feature of any other person: up to three years and a fine up to one lakh rupees. This is the section that governs what you do with a credential you recover during a test. Cracking a password hash in a laboratory you own is one thing; using a real employee's recovered password to log in as them is use of another person's unique identification feature, and it is lawful only because, and only to the extent that, the scope authorises it. A scope that says "you may test the login mechanism" does not automatically say "you may log in as a named human being and read their mail".

Section 66D, cheating by personation using a computer resource. Cheating by personation by means of any communication device or computer resource: up to three years and a fine up to one lakh rupees. This is the phishing section. A social-engineering exercise in which you send a message appearing to come from the client's IT department, to induce staff to do something, is personation by computer resource. Performed inside an authorised social-engineering engagement it is a service; performed on your own initiative it is an offence, and the difference is, once again, the scope.

Section 66F: cyber terrorism

Cyber terrorism is defined by intent and effect: acts done with intent to threaten the unity, integrity, security or sovereignty of India, or to strike terror, by denying access to a computer resource, attempting unauthorised access, or introducing a contaminant, and causing or likely to cause death, injuries, damage to property, or disruption of supplies or services essential to the life of the community, or affecting critical information infrastructure. It is punishable with imprisonment which may extend to imprisonment for life.

No ordinary penetration test approaches this, and the section is included for one reason: it marks how seriously the law treats attacks on infrastructure that people depend on. It is the backdrop to section 70.

Section 70: protected systems, and the ten-year line

(1) The appropriate Government may, by notification in the Official Gazette, declare any computer resource which directly or indirectly affects the facility of Critical Information Infrastructure, to be a protected system.

(3) Any person who secures access or attempts to secure access to a protected system in contravention of the provisions of this section shall be punished with imprisonment of either description for a term which may extend to ten years and shall also be liable to fine.

The Act's own Explanation defines Critical Information Infrastructure as a computer resource whose incapacitation or destruction would have a debilitating impact on national security, economy, public health or safety. Power, banking, telecommunications and transport sit here.

Three things follow for a tester, and they are the practical heart of this chapter:

1. The penalty is ten years, not three. This is the most severe ordinary provision you can stumble into.
2. An attempt is enough. Section 70(3) punishes securing access or attempting to secure access. A scan that fails still attempted.
3. You may not know a system is protected by looking at it. A declaration is made by notification in the Gazette, not by a banner on the login page.

That third point is why scope documents name systems explicitly and exclude everything else, and why a tester who discovers an unexpected system during an engagement stops and asks rather than probing. Authorisation to access a protected system comes from the Government's own written authorisation under s.70(2), not from the system's operator alone.

Section 72: confidentiality, and what goes in your report

Section 72 penalises a person who, having secured access to any electronic record, book, register, correspondence, information, document or other material in pursuance of powers conferred under the Act, discloses it to another person without the consent of the person concerned. (The original two-year term was revised to a monetary penalty by later amendment.)

Its neighbour, section 72A, is the one closer to a tester's life: disclosure of personal information obtained while providing services under a lawful contract, without consent and with intent to cause or knowledge of likely wrongful loss or gain, attracts a substantial penalty.

A penetration tester provides services under a lawful contract and routinely sees personal data. The professional discipline that follows is concrete:

• Do not copy out more data than is needed to prove a finding.
• Redact personal data in the report; prove the flaw with one masked record, not a spreadsheet of customers.
• Store test artefacts encrypted, and destroy them at the engagement's end.
• Never reuse client data in another engagement, a talk or a portfolio.

Section 66A: dead law, still cited

Section 66A once punished sending "grossly offensive" or "menacing" messages by computer. The Supreme Court struck it down in Shreya Singhal v. Union of India (2015) as an unconstitutional restriction on the freedom of speech guaranteed by Article 19(1)(a), being vague and overbroad. The bare Act still prints the text marked Omitted.

Know it for two reasons: examiners ask, and it is still wrongly cited in news reports and even in police practice. A student who can say "66A was struck down in Shreya Singhal and is not law" is demonstrating exactly the currency this subject demands.

Section 75: the Act reaches outside India

Section 75 provides that the Act applies to an offence or contravention committed outside India by any person, if the act involves a computer, computer system or computer network located in India. So a tester in Mumbai who touches a server in Singapore is exposed to Singapore's law, and an attacker abroad who touches a server in India is within reach of this Act. Cross-border work multiplies the legal analysis; it never removes it.

A worked example

Vikram is engaged to test a bank's customer portal. His scope names two web servers and authorises credential testing but says nothing about social engineering or internal systems.

• He recovers a test account's password from a weak hash and uses it to log in to the named portal. Lawful: the scope authorises testing the login mechanism, and the account is a test account provided by the client. Had it been a real customer's credential, s.66C would demand explicit authorisation he does not have.
• He decides to email bank staff a message appearing to be from the IT helpdesk, to see who responds. Not lawful: that is personation by computer resource under s.66D, and social engineering is not in his scope.
• During the test he notices a server belonging to a payment network and probes it. Serious risk: it is outside the scope, so s.43 applies at once, and if it has been notified as a protected system, s.70 applies with its ten-year maximum, and an attempt suffices.
• His report quotes fifty customers' names and account numbers to prove a data-exposure flaw. Wrong practice and a s.72A risk: one masked record proves the flaw; the rest is unnecessary disclosure of personal information obtained under a services contract.

Every error is a scope error. That is the lesson the next chapter builds on.

Distinctions that carry marks

What beginners get wrong

• Treating a recovered password as free to use. Recovering it and using it are different acts; using a real person's credential engages s.66C and needs explicit authorisation.
• Thinking phishing is only unethical, not illegal. It is personation by computer resource under s.66D. Authorised social-engineering testing is a contracted service; unauthorised phishing is an offence.
• Assuming a protected system announces itself. Declaration is by Gazette notification. You find out from the scope and the client, not from the server.
• Citing section 66A. It has been struck down since 2015 and is not law.
• Putting raw personal data in the report to be thorough. It is the opposite of thorough; it creates a fresh disclosure risk under s.72A. Prove the finding with a masked sample.

Quick revision

• s.65 source-code tampering (where the code must be kept by law); s.66B receiving a stolen computer resource; s.66C identity theft (using another's password or unique identifier); s.66D cheating by personation (the phishing section); s.66F cyber terrorism (up to life).
• s.70 protected systems: ten years, and an ATTEMPT is enough. Protected status comes from a Gazette notification, so the scope is how you know.
• s.72 and s.72A: confidentiality. A tester sees personal data; redact it, minimise it, encrypt it, destroy it.
• s.66A is Omitted, struck down in Shreya Singhal v. Union of India (2015). Do not cite it as live law.
• s.75: the Act reaches acts committed outside India involving a computer located in India.

Test yourself

1. Why does section 70 matter more to a tester than its wording suggests?

Because it carries a ten-year maximum, it punishes an attempt to secure access as well as success, and protected status is conferred by Gazette notification rather than being visible on the system, so a tester can only know from the scope and the client.

1. A tester recovers a real employee's password during an engagement. Which section governs what they do next, and what makes the use lawful?

Section 66C, identity theft, which covers fraudulently or dishonestly using another person's password or unique identification feature. Use is lawful only to the extent the client's written scope expressly authorises it.

1. Under which section does a phishing simulation fall, and when is it lawful?

Section 66D, cheating by personation using a computer resource. It is lawful only when the engagement's scope and rules of engagement expressly authorise social-engineering testing.

1. What is the status of section 66A, and why must you know it?

It was struck down by the Supreme Court in Shreya Singhal v. Union of India (2015) as violating Article 19(1)(a), and the Act prints it as Omitted. It must be known because it is still wrongly cited.

1. What obligations does section 72A place on how you write a penetration-test report?

It penalises disclosing personal information obtained while providing services under a lawful contract, without consent. So a report minimises and redacts personal data, proves findings with masked samples, stores artefacts securely and destroys them at the engagement's close.

Note what the specimen does not do: it does not describe techniques (that is the rules of engagement) and it does not list systems (that is the scope). Keeping them separate means the scope can be amended mid-engagement without re-signing the authorisation.

Document 2: the scope

The scope is the most important document of the three, because it is the one that maps directly onto section 43's "without permission". Anything not in scope is a system for which you have no permission.

A scope states, for each target: what it is, how it is identified (domain name, IP address, address range, application name), and any limit on depth. It states exclusions just as explicitly. A teaching specimen:

SCOPE (Annexure A), 3 October 2026

In scope

| Target | Identifier | Depth permitted |

| --- | --- | --- |

| Customer web portal | shop.metro-retail.test | Full testing including authenticated testing with supplied test accounts |

| Portal API | api.metro-retail.test | Full testing |

| Corporate website | www.metro-retail.test | Scanning and unauthenticated testing only |

| External address range | 203.0.113.0/28 | Port scanning and service identification only |

Explicitly out of scope

- Any host not listed above, including any subdomain discovered during testing.

- The payment gateway (operated by a third party) and any host under pay.partner.test.

- Staff, contractors and their personal devices: no social engineering of any kind.

- The corporate wireless network and all internal systems.

- Production customer data: testing uses the supplied test accounts only.

Discovery rule: if a system is found that appears to belong to the Company but is not listed, the Testers will report it and await written confirmation before testing it.

That last rule is the one that saves careers. Reconnaissance routinely turns up a forgotten subdomain, and the instinct is to test it because it obviously belongs to the client. The scope says it does not, until someone writes that it does.

The third-party exclusion matters for the same reason: the client cannot grant permission over a system it does not own. A payment gateway belongs to the gateway, and only the gateway can authorise testing of it.

Document 3: the rules of engagement

The scope says what; the rules of engagement say how, and they exist mainly to prevent the tester from causing harm while doing their job.

RULES OF ENGAGEMENT (Annexure B)

1. Timing. Testing that may degrade performance is permitted only between 00:01 and 05:00 IST. Passive and low-impact testing may occur at any time.

2. Prohibited techniques. No denial-of-service or stress testing. No social engineering. No physical intrusion. No modification or deletion of production data. No use of real customers' credentials.

3. Exploitation. Exploitation is permitted to the minimum depth needed to demonstrate a finding. Proof of access is to be captured and the access relinquished; no persistence mechanism is to be installed.

4. Data handling. Evidence containing personal data is masked before it leaves the Testers' systems, is stored encrypted, and is destroyed within 30 days of the final report.

5. Stop conditions. Testing stops immediately, and the emergency contact is called, if: a system becomes unresponsive; evidence of a prior, real compromise is found; or personal data is encountered beyond what a finding requires.

6. Deconfliction. The Testers will supply their source addresses in advance so the Company can distinguish testing from a real attack, and will log the start and stop time of each test.

7. Reporting. Critical findings are reported within 24 hours of discovery rather than held for the final report.

Rule 5 is worth pausing on. Finding evidence of a real, prior intrusion is the scenario for which a stop condition exists. You are now standing in a potential crime scene; continuing may destroy evidence and may implicate you. You stop and you telephone.

Rule 6, deconfliction, is what stops the client's security team spending a night responding to you as though you were an attacker, and it is also how the client can later separate your activity from anyone else's in the logs.

A worked example: reading a bad authorisation

A student is offered "freelance security testing" by a small company. The email says:

"Hi, we heard you know about hacking. Please check if our site is secure and let us know. Thanks."

Assess it against the three documents:

• Authorisation letter? No. An informal email from an unnamed person, with no statement of who they are or whether they can grant access.
• Scope? No. "Our site" is not an identifier, and nothing says which hosts, whether the API is included, or what is excluded.
• Rules of engagement? No. Nothing about timing, prohibited techniques, data handling or whom to call.

The professional response is not to refuse the work but to supply the missing documents: reply asking for a signed authorisation from someone who can grant it, a list of hosts with exclusions, and agreement on techniques and timing. If the company will not provide them, the answer is no, and the reason is that without them the tester is relying on an email that proves nothing about permission under section 43.

A student who can do this, turn a vague request into a scoped engagement, has learned the most commercially useful thing in this chapter.

What beginners get wrong

• Treating the contract as paperwork to get past. The scope is the legal boundary of everything you are about to do; it is the technical document, not an administrative one.
• Accepting authorisation from someone without authority. A departmental manager may not be competent to authorise testing of a shared corporate system. The letter should state the signatory's authority.
• Assuming a discovered subdomain is in scope. It is not, until someone writes that it is. This is the commonest way a good engagement goes wrong.
• Assuming the client can authorise a third party's systems. They cannot. Cloud providers and payment gateways have their own testing policies that must be checked separately.
• Forgetting to agree stop conditions. Without them, a tester meeting a live intrusion, or a crashing server, has to improvise at the worst moment.
• Not supplying source addresses. The client's team wastes a night on an incident that was you.

Quick revision

• Three documents: authorisation letter (who, what, when, who granted it and on what authority, contact), scope (targets by identifier, depth, and explicit exclusions), rules of engagement (timing, prohibited techniques, exploitation depth, data handling, stop conditions, deconfliction, reporting).
• Keep them separate so the scope can change without re-signing the authorisation.
• Anything not named in the scope is out of scope, including subdomains discovered during the test; a discovery rule requires written confirmation before testing them.
• A client cannot authorise testing of a third party's systems.
• Stop conditions: unresponsive system, evidence of a real prior compromise, unexpected personal data. Stop and telephone.
• Deconfliction (supplying source addresses and times) protects the client's team and separates your traffic from a real attacker's.

Test yourself

1. Name the three documents that constitute authorisation, and say what each governs.

The authorisation letter (who may test, what, when, granted by whom and on what authority), the scope (exactly which systems are in and out, and to what depth), and the rules of engagement (how: timing, permitted and prohibited techniques, exploitation depth, data handling, stop conditions, reporting).

1. During reconnaissance you discover a subdomain that clearly belongs to the client but is not in the scope. What do you do, and why?

Report it and await written confirmation before testing it. It is out of scope, so testing it would be access without permission under section 43; ownership by the client is not the same as authorisation to test.

1. Why must a scope state exclusions explicitly when it already lists what is included?

Because exclusions remove ambiguity in the cases that actually arise: third-party systems the client cannot authorise, staff (social engineering), production data, and anything discovered mid-test. They also record the client's own risk decisions.

1. Give three stop conditions and explain the reason for one of them.

A system becoming unresponsive; discovering evidence of a real prior compromise; encountering personal data beyond what a finding requires. Discovering a prior compromise means you are in a potential crime scene: continuing risks destroying evidence and implicating you, so you stop and call the emergency contact.

1. A client emails "please check if our site is secure". Is that authorisation, and what should you do?

No. It identifies no systems, no signatory with stated authority, no timing and no rules. The professional response is to supply the missing documents: request a signed authorisation, a host list with exclusions, and agreed rules of engagement, and to decline if they are not provided.

Attack surface. The sum of all the points where an attacker could try to get in: every window and door, every open port, every input field, every employee with an email address. Reducing the attack surface (closing unused ports, removing unused features) is one of the cheapest defensive moves there is, because it removes possibilities rather than defending them.

Exploit. The means of turning a vulnerability into entry: climbing through the unlatched window, or the crowbar that forces a locked one. In software an exploit is often a small program or a crafted input. The key relationship: an exploit is specific to a vulnerability. There is no general-purpose exploit, which is why attackers must first find out exactly what you are running.

Payload. What the attacker does once inside, as opposed to how they got in. The burglar's payload is taking the cash; a different burglar might photograph documents instead. In software, the same exploit can deliver different payloads, which is why the severity of an intrusion is not determined by the way in alone.

Attack. A threat actor using an exploit against a vulnerability to harm an asset. Attack is the event; the other words are the ingredients.

Zero-day. A vulnerability the defenders do not yet know about, so no fix exists: they have had "zero days" to address it. The word describes knowledge, not severity. A known, patched flaw can be devastating and is not a zero-day; an unknown trivial flaw is one.

Risk. How much you should care, combining how likely the attack is to succeed with how bad it would be. The shop's risk is high if the takings are large, the window is weak, and burglars are active in the area. Change any one of the three and the risk changes.

Mitigation and control. What you do about risk: fix the latch (remove the vulnerability), bank the takings daily (reduce the impact), install an alarm (detect the attack). A control is any measure that reduces risk.

The relationship, in one sentence and one formula

The sentence to memorise: a threat actor uses an exploit against a vulnerability to compromise an asset, and how much you should care is the risk.

The relationship stated as a rough formula, which examiners like:

Risk = Threat x Vulnerability x Impact

Read it as a set of switches rather than real arithmetic. If any factor is effectively zero, the risk is small:

• A serious vulnerability with no threat actor who cares is low risk. A flaw in software nobody runs harms nobody.
• A determined threat actor facing no vulnerability is low risk. They are trying, and there is nothing to use.
• A likely attack on an asset of no value is low risk. Somebody may deface a page nobody reads.

This is why "we have a critical vulnerability" is not by itself an emergency, and why "we are being targeted" is not by itself a disaster. The examinable point is that risk is never a property of the vulnerability alone.

The distinction that costs the most marks

A test you can apply to any sentence: if it describes something you could fix with a change to your own systems, it is a vulnerability. If it describes somebody or something that might come at you, it is a threat. "Our staff click on links" is a vulnerability (train them, add controls). "Criminals send phishing emails" is a threat (they will keep doing it).

A worked example

An online shop runs a web application. Its checkout page trusts a price value sent by the browser.

• The asset is the shop's revenue and the integrity of its orders.
• The vulnerability is trusting a price supplied by the client rather than looking it up on the server.
• The attack surface includes every input the checkout accepts, of which the price field is one.
• The threat is that people who buy online will try to pay less; the threat actors range from an opportunistic customer to organised fraud.
• The exploit is editing the hidden price field before submitting.
• The payload, in the sense of what the attacker gains, is goods at a price they chose.
• The risk is high: the vulnerability is easy to exploit, the threat actors are numerous and motivated, and the impact scales with every order placed.
• The mitigation is to look the price up on the server and ignore anything the browser says about it, plus alerting on orders below cost as a detective control.

Notice that naming the parts produced the fix. That is what the vocabulary is for: it is not terminology for its own sake, it is a way of decomposing a problem so the answer becomes visible.

What beginners get wrong

• Using threat and vulnerability interchangeably. They are opposite ends of the relationship. Apply the test above: fixable by you means vulnerability.
• Calling every attacker a "hacker" and every hacker a criminal. The word covers the professional this course trains you to be. The next chapters separate the classes properly.
• Treating "zero-day" as a synonym for "very serious". It means unknown to defenders and therefore unpatched. Severity is a separate axis.
• Reporting a vulnerability's severity as if it were the client's risk. Severity is intrinsic; risk adds threat and impact in that organisation's context. A critical flaw in a system they do not run is not their emergency.
• Confusing exploit and payload. The exploit is the way in; the payload is what happens next. The same exploit can carry very different payloads, so the way in does not determine the harm.
• Forgetting the asset. Without naming what is being protected, no statement about risk means anything.

Quick revision

• Asset (what you protect), vulnerability (a weakness in it, yours to fix), threat (a potential cause of harm, out in the world), threat actor (a specific one, with motivation, capability, persistence), attack surface (all the points of possible entry), exploit (the means of using a vulnerability), payload (what is done once in), attack (the event), zero-day (unknown and unpatched, a statement about knowledge), risk (likelihood times impact), control or mitigation (what reduces risk).
• One sentence: a threat actor uses an exploit against a vulnerability to compromise an asset, and how much you should care is the risk.
• Risk = Threat x Vulnerability x Impact, read as switches: if any factor is near zero, risk is low.
• The test: fixable by changing your own systems means vulnerability; something that might come at you means threat.

Test yourself

1. Define vulnerability, threat and exploit, and state the relationship between them in one sentence.

A vulnerability is a weakness in a system that could be taken advantage of; a threat is a potential cause of an unwanted incident; an exploit is the means of taking advantage of a vulnerability. A threat actor uses an exploit against a vulnerability to compromise an asset.

1. Why is a critical vulnerability not automatically a high risk?

Because risk combines the vulnerability with the likelihood of a threat actor exploiting it and the impact if they do. A severe flaw in software the organisation does not run, or in an asset of no value, carries little risk despite its intrinsic severity.

1. Give the test that distinguishes a threat from a vulnerability, and apply it to "our staff click on links in emails".

If it is something you could fix by changing your own systems, processes or people, it is a vulnerability; if it is something that might come at you from outside, it is a threat. Staff clicking links is a vulnerability, addressed by training and technical controls; criminals sending phishing emails is the threat.

1. What does "zero-day" actually describe, and what does it not?

It describes the defenders' state of knowledge: the vulnerability is unknown to them and therefore unpatched. It does not describe severity, so a known and patched flaw may be far more serious than a given zero-day.

1. Distinguish an exploit from a payload.

The exploit is the technique that takes advantage of the vulnerability to gain entry or execution; the payload is what is carried out once that succeeds. The same exploit can deliver different payloads, so the method of entry does not by itself determine the harm.

What protects it: hashes and checksums to detect change, digital signatures and message authentication codes to detect unauthorised change, access controls on writing, input validation, database constraints and transactions, version control, and integrity monitoring on important files.

The characteristic failure: an integrity breach can be invisible. A stolen file is gone; an altered file is still there, looking normal, and every decision made from it afterwards is wrong. That is why detection matters as much as prevention here, and why a system that cannot prove its data is unaltered has an integrity problem even if nobody has attacked it.

Availability

The information and the systems are usable when an authorised person needs them.

What breaks it: a denial-of-service attack, ransomware encrypting the files, deletion of data, hardware failure, a power cut, a misconfiguration that takes a service down, a dependency that disappears, and an overload of perfectly legitimate traffic.

What protects it: redundancy and failover, capacity planning, backups that are tested and stored offline, rate limiting and filtering, upstream scrubbing for volumetric attacks, patching to prevent crashes, and monitoring so an outage is noticed before the customers notice.

The characteristic failure: availability is the property most often broken by accident rather than malice, and it is the property whose loss the business feels within minutes. It is also the one where the defence is least like the others: you cannot encrypt your way to availability, and adding security controls can reduce it, which is the tension in the next section.

The tension between the three

The three pull against one another, and an honest answer says so.

• Encrypt a database and lose the key: confidentiality is perfect and availability is zero.
• Lock an account after three wrong passwords, and you have protected confidentiality at the cost of availability, because an attacker can now lock out legitimate users deliberately.
• Keep many backups for availability, and you have multiplied the places from which confidentiality can be lost.
• Add integrity checks everywhere and the system slows, which at some point is an availability problem.

Security is therefore not "maximise all three" but a set of deliberate trade-offs, made differently for different assets. A hospital's patient records lean hard toward availability (a doctor must read them in an emergency); a country's intelligence files lean hard toward confidentiality. The examinable point: the right balance is a property of the asset, not a universal answer.

Two more properties the triad leaves out

The three-word model has a gap that examiners like to probe, so know the two words that fill it.

Authenticity. That something is genuine and from the claimed source. Integrity says the message was not altered; authenticity says who wrote it. They are different: an attacker can send you a brand-new message, perfectly intact, pretending to be your bank. Integrity is satisfied and you are still deceived. Authenticity is provided by authentication, digital signatures and certificates.

Non-repudiation. That the sender cannot later deny having sent it. This is stronger than authenticity, because it must convince a third party, not just the recipient. A message authentication code gives authenticity between two parties who share a key, but not non-repudiation, because either of them could have produced it; a digital signature, using a private key only one party holds, does give it. Section 3A and the electronic-signature scheme of the IT Act are the Indian legal form of the same idea.

Together these are sometimes called the "five pillars" (with the triad), and a strong answer names them.

A worked example: one system, three failures

A college runs an online examination portal holding question papers, student answers and results.

A confidentiality failure. A student finds that changing a number in the results URL shows another student's marksheet. Nothing was altered and the system stayed up; the property broken is confidentiality alone. The control that failed was authorisation, and the fix is a server-side check that the logged-in user owns the record.

An integrity failure. A student alters their submitted answer after the deadline through a flaw that trusts a timestamp sent by the browser. Nothing was disclosed and the system stayed up; the property broken is integrity. The controls that failed were input trust and write access, and the fix is a server-authoritative timestamp plus an append-only audit record.

An availability failure. On results day the portal is flooded and nobody can log in. Nothing was read and nothing was altered; the property broken is availability. The controls that failed were capacity and rate limiting, and the fix is caching, capacity and filtering.

And one attack that breaks two. An attacker intercepts and modifies a result in transit: confidentiality (they read it) and integrity (they changed it) both go, which is why a man-in-the-middle is treated as more serious than passive sniffing.

Notice how naming the property led straight to the family of control in every case. That is the working method this chapter is teaching.

Mapping the rest of the book

What beginners get wrong

• Thinking security means confidentiality. Availability failures are the ones a business notices first, and integrity failures are the ones that do lasting damage because they are invisible.
• Treating the three as independent. They trade off. A control for one can harm another, and account lockout is the classic example.
• Confusing integrity with authenticity. Integrity says unaltered; authenticity says from whom. A forged message can have perfect integrity.
• Assuming a MAC gives non-repudiation. It does not, because both parties share the key and either could have produced it. A digital signature does.
• Forgetting accidental causes. A failing disk breaks integrity and a power cut breaks availability with no attacker involved. Security controls must handle both.

Quick revision

• Confidentiality: only authorised parties can read it. Broken by sniffing, weak access control, theft. Protected by encryption, access control, least privilege. Cannot be restored once lost.
• Integrity: information is accurate and unaltered by anyone unauthorised. Broken by tampering, injection, malware, and by accident. Protected by hashes, signatures, write controls, validation, monitoring. Failures can be invisible.
• Availability: usable on demand by authorised users. Broken by denial of service, ransomware, deletion, failure, overload. Protected by redundancy, capacity, backups, rate limiting, monitoring.
• The three trade off against each other; the right balance depends on the asset.
• Authenticity (from the claimed source) and non-repudiation (the sender cannot deny it) fill the gap the triad leaves. A MAC gives authenticity, not non-repudiation; a digital signature gives both.
• The working method: when you meet a new attack, ask which property it breaks, and the family of defence follows.

Test yourself

1. Name the three properties of the CIA triad and give one attack that breaks each.

Confidentiality, broken by network sniffing or an access-control flaw that reveals another user's data; integrity, broken by a man-in-the-middle altering a message or an injection that updates a record; availability, broken by a denial-of-service attack or ransomware.

1. Why is an integrity breach often more damaging than a confidentiality breach, despite attracting less attention?

Because it can be invisible: the data is still present and looks normal, so the organisation keeps making decisions from information that is wrong. A disclosure is at least discovered; an undetected alteration keeps causing harm.

1. Give an example of a control that protects one property at the expense of another.

Account lockout after repeated failed logins protects confidentiality by stopping password guessing, but harms availability, because an attacker can deliberately lock legitimate users out. Encryption without reliable key management similarly protects confidentiality while risking total loss of availability.

1. Distinguish integrity from authenticity, and say which of a MAC and a digital signature provides non-repudiation.

Integrity means the information has not been altered; authenticity means it genuinely comes from the claimed source, so a forged but intact message satisfies integrity and fails authenticity. A message authentication code gives authenticity between two parties sharing a key but not non-repudiation, since either could have produced it; a digital signature, made with a private key only the signer holds, provides non-repudiation.

1. A ransomware attack encrypts a hospital's records and the attackers also copy them first. Which properties are broken?

Availability, because the records cannot be used when needed, and confidentiality, because copies have been taken. Integrity is threatened as well if the restored data cannot be proved unaltered.

It is worth being precise about motive, because "for fun" is an outdated picture. Most serious attacks today are economically motivated and organised: ransomware operations, fraud, and the theft and sale of data are businesses with specialisation, tooling and support functions. A defender who imagines a lone teenager will build the wrong defences against an adversary that behaves like an industry.

Grey hat: the one the examiner asks about

A grey hat acts without authorisation but without clear malicious intent. The archetype probes a stranger's website out of curiosity, finds a flaw, takes nothing, and emails the owner to tell them.

This is the class worth thinking about carefully, because students instinctively feel it must be acceptable. It is not, and the reason is precisely the chapter on section 43: liability turns on the absence of permission, and the section does not ask about motive, damage or what you did afterwards. Good intent may matter to whether anyone pursues the matter, and it negates the dishonesty that section 66 requires, but it does not make the access lawful.

There is also a practical trap. A grey hat who reports a flaw has just told an organisation, in writing, that they accessed its systems without permission. Some organisations respond with thanks; some respond with lawyers. The finder has no contract, no scope, and no safe harbour.

The professional route to doing exactly what a grey hat wants to do is the bug bounty or a written scope: permission granted in advance, which converts the same activity into authorised testing. That chapter comes later, and this is the problem it solves.

The other categories worth naming

Script kiddie. Someone who uses tools written by others without understanding them. The term is dismissive about skill, and it should not be dismissive about risk: the tools are genuinely powerful, and an unskilled attacker running a working exploit against an unpatched server succeeds exactly as well as a skilled one. Defences are not improved by the attacker's ignorance.

Hacktivist. Someone who attacks or defaces systems to make a political or social point rather than for money. Common forms are website defacement (an integrity attack), denial of service as protest, and the leaking of documents. Legally there is nothing special about hacktivism: the acts are the same acts under section 43, and a cause does not supply permission. The category matters for a defender because it changes targeting: hacktivists choose targets for visibility and symbolism, so an organisation can become a target for what it represents rather than for what it holds.

Insider. Someone who already has legitimate access and abuses it, or exceeds it. Insiders are dangerous because most defences face outward, and because an insider's activity looks like ordinary work. They divide into the malicious (grievance, money, espionage) and the negligent, who cause harm without meaning to, and the second group is much larger. Controls are least privilege, separation of duties, monitoring of privileged actions, and a good leavers process.

State-sponsored actor (sometimes called an advanced persistent threat). A government-backed group pursuing espionage or strategic disruption. What distinguishes them is not glamour but resources and patience: they can afford unknown vulnerabilities, they can wait months, and they do not give up because a first attempt failed. Most organisations are not their target; those that are cannot expect ordinary controls to suffice.

Suicide hacker. A term found in the CEH literature for an attacker indifferent to being caught, typically ideologically driven. It matters only because deterrence, which assumes the attacker fears consequences, does not work on them.

Types of hacking, by target

The syllabus also says "hacking types", which is usually taught as classification by what is attacked. Know the list, because it maps onto the structure of this book:

• Network hacking: scanning, sniffing, man-in-the-middle, denial of service.
• Web application hacking: injection, broken access control, cross-site scripting, session attacks.
• System hacking: gaining access to a host, privilege escalation, persistence.
• Wireless hacking: attacks on Wi-Fi authentication and encryption, rogue access points.
• Social engineering: attacks on people rather than machines.
• Mobile and cloud: attacks on applications and configurations in those environments.

Each is a later section of this book, and each is bounded by the same authorisation rule.

A worked example: one flaw, four people

A shopping site has a flaw letting any logged-in user read another customer's order by changing a number in the address.

• Anita is engaged under a signed scope naming that site. She finds it, proves it with two test accounts, and reports it with a fix. White hat. Lawful, because she had permission for that system.
• Bala finds it uninvited and quietly orders goods against other people's accounts. Black hat. Section 43 applies at once, and his dishonest purpose brings in section 66.
• Chandni finds it uninvited, looks at two orders to be sure it is real, takes nothing and emails the company. Grey hat. Well meant, still unauthorised: section 43 is engaged by the access, and her good motive is not a defence, though it negates section 66's dishonesty.
• Dev reads about the flaw online and runs a ready-made script against the site without understanding it. Script kiddie, and legally a black hat: no permission, and the lack of skill changes nothing.

Same flaw, same technique, four positions, decided by permission and purpose.

What beginners get wrong

• Classifying by skill. The classes are about authorisation. A highly skilled unauthorised tester is a black hat; a modestly skilled authorised one is a white hat.
• Believing a grey hat is safe because they meant well. Section 43 does not ask about motive. Good intent may negate section 66's dishonesty and may influence whether anyone pursues it, but it does not make the access lawful.
• Thinking hacktivism is a legal category. It describes motive, not lawfulness. The acts are the same offences; the cause supplies no permission.
• Underestimating script kiddies. The tools work. Your unpatched server does not care how well the attacker understands them.
• Defending only against outsiders. Insiders already have access, and the negligent insider is the commonest of all. Least privilege and monitoring exist for them.
• Assuming state actors are everyone's problem. They are not, and building for them while ignoring phishing and patching is a misallocation.

Quick revision

• Classify by permission, not by character: white hat (authorised, scoped, reports to the owner), black hat (unauthorised, criminal purpose), grey hat (unauthorised, not clearly malicious, still liable under s.43).
• Also: script kiddie (others' tools, no understanding, still dangerous), hacktivist (political motive, no legal difference, changes targeting), insider (malicious or, more often, negligent; least privilege and monitoring), state-sponsored (resources and patience).
• Hacking types by target: network, web application, system, wireless, social engineering, mobile and cloud.
• The lawful way to do what a grey hat does is a bug bounty or a written scope: permission in advance.

Test yourself

1. On what basis are hacker classes properly distinguished, and why is skill the wrong basis?

On authorisation: whether the person has the owner's permission. Skill is the wrong basis because it has no bearing on lawfulness; a highly skilled unauthorised tester is a black hat, and section 43 turns on permission, not competence.

1. A grey hat finds a flaw uninvited, takes nothing, and reports it. What is their legal position?

Section 43 is engaged, because they secured access without the owner's permission and the section requires neither damage nor dishonest intent. Their good motive negates the dishonesty section 66 requires and may influence whether the owner pursues the matter, but it does not make the access lawful.

1. Why is hacktivism not a separate legal category, and why does it still matter to a defender?

Because the acts are the same offences under the Act and a political cause supplies no permission. It matters to a defender because it changes targeting: hacktivists select targets for symbolism and visibility, so an organisation may be attacked for what it represents rather than what it holds.

1. Why should a script kiddie not be dismissed?

Because the tools they run were written by capable people and work regardless of the user's understanding. An unpatched system is compromised just as effectively by an unskilled attacker using a working exploit.

1. Which class of attacker do most outward-facing defences miss, and what controls address them?

Insiders, who already hold legitimate access and whose activity resembles ordinary work; the negligent insider is the most common. They are addressed by least privilege, separation of duties, monitoring of privileged actions, and a reliable leavers process.

Grey box. The middle, and the commonest in practice. The tester gets partial information, typically a standard user account and a description of the application, but not the source or the administrative credentials.

What it buys: a realistic simulation of the threat that matters most for many systems, the authenticated user who misbehaves, whether a genuine customer, a low-privileged employee, or an attacker who has already phished one account. Since most serious web findings (broken access control above all) are only visible to someone logged in, starting logged in is often the most productive choice.

The professional's summary: black box measures exposure, white box measures security, grey box is the practical compromise. If a client wants to know how secure their application is, white or grey box finds more. If they want to know what an anonymous internet attacker can reach, black box answers that specific question.

External and internal

A separate axis, and often confused with the one above.

External testing starts from the internet, against the organisation's public-facing systems: websites, mail servers, VPN endpoints, anything reachable from outside. It answers "what can be reached and exploited from the internet?"

Internal testing starts from inside the network, as though the tester were an employee, a visitor who found a network socket, or, most realistically today, an attacker who has already compromised one workstation through phishing. It answers "if somebody gets a foothold, what then?"

Internal testing is the one clients skip and the one that most often produces alarming findings, because many networks are hard on the outside and soft in the middle: flat networks with no segmentation, shared administrative passwords, unpatched internal servers nobody exposed to the internet and therefore nobody worried about. Given that an initial foothold through phishing is realistic, testing only the perimeter measures the wrong thing.

Note that the axes combine: an internal grey-box test (inside the network, with a standard domain account) is a very common and very informative engagement.

Announced or unannounced, and the red team

The third axis is whether the defenders know.

In an announced test the security team knows it is happening, and often knows the tester's source addresses. This is normal, and it is what deconfliction in the rules of engagement is for. The point is to find vulnerabilities efficiently.

In an unannounced exercise, usually called a red team engagement, only a small number of people know. The objective shifts: instead of enumerating as many vulnerabilities as possible, the red team pursues a specific goal ("obtain access to the payroll database") by whatever authorised means, while the blue team (the defenders) responds without knowing it is an exercise. What is being tested is not the systems but the detection and response capability: were they noticed, how quickly, and what did the defenders do?

A purple team exercise runs the two together deliberately, with attackers and defenders sharing information in real time so that each attack technique is immediately checked against whether the defence sees it. It is less dramatic and often more useful, because it improves detection directly.

Audit, vulnerability assessment and penetration test: three different products

MU's row 1 names all three, and they are not synonyms.

The examinable distinction: a vulnerability assessment tells you what might be wrong; a penetration test proves what actually is, and what it would cost you. A scanner reporting "this version has a known flaw" is a hypothesis; a tester demonstrating access is evidence. Both have value, and they are priced very differently for that reason.

A client who asks for a penetration test and is sold an automated scan has been badly served, and a client who wants an inventory of every missing patch does not need a penetration test to get one.

A worked example: choosing the type

A college wants to secure its new student portal and has a limited budget. Work through the choices:

• What worries them most? Students reading or altering each other's results. That is an authenticated-user threat, so a grey-box test with two student accounts targets it directly. A black-box test would spend its budget rediscovering the login page.
• External or internal? The portal is public, so external. But the same conversation should ask whether a compromised staff workstation could reach the results database directly, which is an internal question and may matter more.
• Announced? Yes. The college has no dedicated security team to test, so a red-team exercise would measure a capability that does not exist. Announced testing spends the budget on finding flaws.
• Which product? A penetration test for the portal, because they want to know what is actually exploitable, plus possibly a vulnerability assessment across the wider estate for breadth at low cost.

The reasoning throughout is the same: match the engagement to the threat the client actually faces and the decisions they need to make.

What beginners get wrong

• Assuming black box is the "real" test. It is the most realistic simulation of an anonymous outsider and the least efficient way to find flaws. What it fails to discover, it fails to test.
• Treating white box as cheating. It finds more per rupee and is the only way to catch design and logic flaws. Realism is one objective among several, not the only one.
• Confusing the information axis with the position axis. Black and white box describe what the tester is told; external and internal describe where they start. An internal white-box test is perfectly coherent.
• Buying a red team without a blue team. If nobody is watching, an unannounced exercise measures a detection capability that does not exist, and the money is better spent on finding vulnerabilities.
• Using "vulnerability assessment" and "penetration test" interchangeably. One lists potential weaknesses, largely automatically; the other proves exploitability and impact, manually. The deliverables and the prices differ accordingly.
• Testing only the perimeter. Given that a phishing foothold is realistic, an internal test usually tells the client more than another external scan.

Quick revision

• Information axis: black box (nothing given, realistic, slow, misses what it cannot find), white box (everything given, deepest coverage, finds design flaws), grey box (a user account, the practical middle, targets the authenticated-user threat).
• Position axis: external (from the internet, the perimeter) and internal (from inside, simulating a foothold; usually the more revealing).
• Awareness axis: announced (efficient vulnerability finding) against red team (unannounced, goal-driven, tests detection and response). Purple team runs attack and defence together to improve detection directly.
• Products: vulnerability assessment (broad, automated, what might be wrong), penetration test (deep, manual, proves exploitability), security audit (compliance against a standard).
• Choose the type from the threat the client faces and the decision they need to make.

Test yourself

1. Distinguish black-box, white-box and grey-box testing, and say which gives the most coverage for a fixed budget.

Black box gives the tester no prior information, white box gives full information including documentation and source, and grey box gives partial information such as a standard user account. White box gives the most coverage for a fixed budget, because no time is spent on discovery and design flaws become findable.

1. What is the main weakness of a black-box test?

Anything the tester fails to discover is not tested at all, and the client may wrongly read the silence as evidence of safety. It also spends a large share of the budget on reconnaissance rather than on finding flaws.

1. Why is internal testing often more revealing than external testing?

Because many networks are hardened at the perimeter and weak internally, with flat segmentation, shared administrative credentials and unpatched internal systems. Since an attacker gaining a foothold through phishing is realistic, testing only the perimeter measures the wrong threat.

1. How does a red-team exercise differ in objective from an ordinary penetration test?

An ordinary announced test aims to find as many exploitable vulnerabilities as possible. A red-team exercise is unannounced and goal-driven, and what it tests is the defenders' detection and response capability: whether the activity was noticed, how quickly, and what was done.

1. State the difference between a vulnerability assessment and a penetration test.

A vulnerability assessment is broad and largely automated and reports weaknesses that may exist; a penetration test is deeper and manual and proves which weaknesses are actually exploitable and what impact they would have, with evidence.

The output of this phase is the input to vulnerability analysis: a service and a version is what you look up to find known flaws. "Apache 2.4.x on port 443" is a sentence you can act on; "there is a web server somewhere" is not.

The authorisation note, and it is the important one: scanning plainly touches the target's systems and is an act under section 43. This is the first phase that unambiguously requires written permission, and students routinely believe the line is crossed later, at "gaining access". It is not.

Phase 3: Gaining access

Using a weakness found in scanning to obtain entry: a weak or default credential, an unpatched service with a known flaw, an injection flaw in an application, a misconfiguration.

This is where a risk stops being theoretical. A report that says "this version has a known critical flaw" is a hypothesis; a report that says "we used it to read the configuration file, here is the evidence" is proof, and it is far harder for an organisation to defer.

The discipline for an ethical hacker is least intrusion: gain access to the depth the scope allows, capture the evidence that proves the finding, and stop. The goal is demonstration, not conquest.

Phase 4: Maintaining access

Keeping the foothold, as a real attacker would, to show what a persistent intruder could reach: other systems, more data, higher privilege. Attackers do this with backdoors, additional accounts, scheduled tasks and rootkits.

In an ethical engagement this phase happens only if the scope permits it, everything installed is logged and removed afterwards, and the purpose is to demonstrate impact rather than to establish a presence. Many engagements stop before this phase entirely, and the report simply notes what a real attacker would have attempted next.

Phase 5: Covering tracks

An attacker's fifth phase is concealment: deleting or editing logs, hiding files, clearing command history, using timestamps that blend in. The purpose is to remain undetected so that phases three and four keep paying.

An ethical hacker inverts the spirit of this phase, and this is the single most important distinction in the chapter. They do not destroy the client's logs. They may test whether logging can be evaded, because "our logging did not record this" is a valuable finding, but they preserve the evidence, record precisely what they did and when, and hand it over. Cleaning up, for a tester, means removing the artefacts they introduced, not removing the record that they were there.

Understanding the attacker's version matters defensively, because it tells you what an intruder will attack: the logs are the record of the attack, so the logs are a target. That is the argument for centralised, append-only, off-host logging.

The lifecycle model, as a table you can reproduce

This is what MU asks you to prepare. Learn it in this shape and you can draw it under examination conditions.

The third column is the thread from the law chapters running through every phase. The fourth column is the thread that runs into every later chapter of the book, and it is the subject of the next chapter.

A worked example

Sana is engaged to test one web server. The scope names a single host, permits exploitation to the minimum depth needed to prove a finding, and forbids persistence.

Reconnaissance. She reads the company's public site, notes the technology named in its page headers and a staff email format from a published address, and looks up the domain's DNS records. Nothing she has done touches the company's own systems.

Scanning. With the authorisation in hand she scans the one named host and finds three open ports; version detection shows an out-of-date web server on one of them.

Gaining access. She confirms the outdated version has a known flaw and uses it to read a configuration file. That is enough: the risk is proven. She captures the evidence with the sensitive values masked and goes no further.

Maintaining access. Out of scope, so she does not attempt it. The report records that a real attacker would have tried, and that the credentials in the configuration file would have allowed it.

Covering tracks. She preserves every log, records the exact times of each test so the client can separate her activity from a real attacker's, removes nothing, and hands over the evidence.

Her report then follows the same five headings, which is a second reason to internalise the model: it structures the work and the write-up alike.

What beginners get wrong

• Believing an ethical hacker runs all five phases fully. They run as far as the scope requires to prove risk, often stopping in phase 3, and they never "cover tracks" against the client.
• Skipping reconnaissance because it does not feel like hacking. It is the phase with the highest return, and the one whose omissions silently limit everything after it.
• Thinking the legal line is crossed at phase 3. It is crossed at phase 2, and often in the active half of phase 1. Scanning is an act under section 43.
• Treating the phases as strictly one-way. They loop: access to one system starts fresh reconnaissance and scanning from inside it. The linear order is the teaching model; real work spirals.
• Listing five words as "the model". MU asks for a structured model. Without the authorisation boundary and the defensive control, it is a list, not a model.

Quick revision

• Five phases: (1) reconnaissance, (2) scanning, (3) gaining access, (4) maintaining access, (5) covering tracks.
• Reconnaissance splits into passive (third parties, touches nothing) and active (touches the target, needs permission).
• Scanning is the first phase that plainly needs authorisation under s.43, not gaining access.
• An ethical hacker stops where the scope says, practises least intrusion, and preserves evidence rather than destroying it; cleaning up means removing artefacts introduced, not removing the record.
• The model to reproduce carries four columns: phase, what happens, the authorisation boundary, the defensive control.
• The phases loop; the linear order is a teaching device.

Test yourself

1. Name the five phases of an ethical hacking engagement in order, and say what each produces.

Reconnaissance (a map of the target from public and light-contact sources), scanning (live hosts, open ports, services and versions), gaining access (proven entry through a weakness), maintaining access (demonstrated persistence and reach), covering tracks (concealment by an attacker; preserved and documented evidence by a tester).

1. At which phase is authorisation first clearly required, and why do students get this wrong?

At scanning, because scanning unambiguously touches the target's systems and is an act under section 43 of the IT Act. Students assume the line is crossed only at gaining access, but by then it has been crossed twice, since active reconnaissance can require permission too.

1. How does an ethical hacker's handling of the fifth phase differ from an attacker's, and what does the attacker's version teach a defender?

An attacker deletes or edits logs and hides files to stay undetected. An ethical hacker preserves the client's logs, documents exactly what was done and when, and removes only the artefacts they introduced. The attacker's version teaches that logs are themselves a target, which is the argument for centralised, append-only, off-host logging.

1. What four things should each phase carry in the lifecycle model MU asks you to prepare?

The phase name, what happens in it, the authorisation and scope boundary that applies to it, and the defensive control that detects or prevents it.

1. Why is reconnaissance described as the highest-value phase?

Because it narrows a vast problem to a small one before any suspicious contact: knowing the technologies, people, email format and forgotten hosts determines what every later phase can achieve, and anything missed in reconnaissance silently limits the rest of the engagement.

Preventive. Reduce what is public rather than trying to stop it being read: suppress version numbers in headers and error pages, avoid naming exact software versions in job advertisements, publish role-based email addresses where possible, strip metadata from published documents, and above all inventory every subdomain and retire the forgotten ones, because a forgotten host is an unpatched host.

Detective. Monitor for unusual patterns of queries, watch certificate-transparency logs for certificates issued for your names, and set alerts for your domains and brand appearing in newly registered look-alike domains, which is often the first sign of a phishing campaign being prepared.

Corrective. Take down exposed material; where credentials or keys have leaked publicly, rotate them.

Phase 2: Scanning, mirrored

What the attacker is doing. Enumerating hosts, ports, services and versions.

Preventive. Default-deny at the perimeter, so unsolicited traffic is dropped and ports appear filtered rather than answering; close unused ports and disable unused services, since every listening service is attack surface; suppress banners; segment the network so a scan from one place cannot see everything.

Detective. This is the phase where detection is genuinely good, and it is a point students underrate. A port scan is a distinctive pattern, many connection attempts across many ports from one source in a short time, and it is exactly what an intrusion detection system is tuned for. The "stealthy" half-open scan avoids some connection logs and is loud to a network sensor.

Corrective. Block or rate-limit the source; treat a scan as an indicator and check whether anything it found is exposed.

The honest caveat: scanning is so constant on the public internet that alerting on every scan produces noise. The value is in noticing scanning that is targeted, or that comes from inside the network, which is a serious indicator.

Phase 3: Gaining access, mirrored

What the attacker is doing. Exploiting a weakness: an unpatched service, a weak credential, an injection flaw, a misconfiguration.

Preventive, and this is where the money should go. Patch promptly, prioritised by severity and exposure. Enforce strong authentication and, above all, multi-factor authentication, which defeats the commonest route of all, a stolen or guessed password. Validate input and use parameterised queries. Apply least privilege so that what is reached is limited. Remove default accounts and change default credentials. Harden configurations against a published baseline.

Detective. Failed-login monitoring and impossible-travel alerts; web application firewall alerts; alerts on unexpected process execution; anomalies in application logs such as a spike of errors from one source.

Corrective. Incident response: isolate the host, revoke and rotate the credentials, rebuild from clean media, restore from backup.

Phase 4: Maintaining access, mirrored

What the attacker is doing. Establishing persistence so the foothold survives a reboot, and moving laterally to reach more.

Preventive. Least privilege again, because most persistence mechanisms need elevated rights; application allow-listing so unknown programs cannot run; network segmentation so a foothold in one place cannot reach the rest; separate administrative accounts so a compromised everyday account does not confer administrative power.

Detective, and this is the richest phase for detection. Persistence is noisy if you are looking: new or modified auto-start entries, new services and scheduled tasks, new accounts, new administrative group memberships, unexpected outbound connections at odd hours, and lateral-movement patterns such as one workstation authenticating to many others. Endpoint detection and response exists largely for this phase, and threat hunting means deliberately looking here rather than waiting for an alert.

Corrective. Remove the persistence, rotate every credential the attacker could have reached, and, where a kernel-level compromise is confirmed, rebuild rather than clean.

Phase 5: Covering tracks, mirrored

What the attacker is doing. Deleting or editing logs, clearing history, hiding files, so that phases three and four keep paying.

Preventive, and it is the decisive control. Ship logs off the host, immediately, to a central system the compromised host cannot write to. An attacker who owns a machine can edit anything on it, so any log that stays local is only as trustworthy as the host. Centralised, append-only logging with restricted access defeats the entire phase, because the attacker would have to compromise the logging system as well.

Detective. Alert on the act of covering tracks itself, which is a high-quality signal precisely because it is rare in normal operation: the audit log being cleared, logging being stopped, a large deletion in a log directory, or a gap in a log stream that should be continuous. Time synchronisation across hosts matters here, so events can be correlated.

Corrective. Preserve what remains, treat it as evidence, and involve the people who handle incidents properly.

The mirror, as a table

A worked example, read as a defender

An attacker phishes an employee, gets their password, logs into the VPN, finds an unpatched internal server, gains administrator on it, installs a scheduled task for persistence, and clears the event log.

Now ask where the defence could have broken the chain, and notice that any one of these would have been enough:

• Multi-factor authentication on the VPN would have made the stolen password insufficient (phase 3 preventive).
• Patching the internal server would have removed the escalation route (phase 3 preventive).
• Network segmentation would have stopped the VPN reaching that server at all (phase 4 preventive).
• An alert on the new scheduled task would have caught the persistence (phase 4 detective).
• Off-host logging would have preserved the record the attacker deleted, and the clearing itself would have raised an alert (phase 5 preventive and detective).

Five independent opportunities against one attack. That is the asymmetry this chapter is about, and it is the answer to "there are too many attacks to defend against".

What beginners get wrong

• Thinking defence must stop everything. It must break the chain once. Layers exist so that a single failure is survivable.
• Spending everything on prevention. Prevention eventually fails; without detection you will not know, and without correction you cannot recover. Budget across all three.
• Leaving logs on the host. A local log is only as trustworthy as the machine, and the machine is the thing that was compromised. Off-host logging is the control that defeats phase 5.
• Treating a control as inherently one kind. A log is detective only if somebody reads it. Purpose, not technology, defines the category.
• Alerting on everything. Internet-facing scanning is constant; alerting on all of it produces noise that hides the signal. Tune for targeted and internal activity.
• Forgetting that reconnaissance is mostly unpreventable. The control there is reducing what is public, not trying to stop people reading it.

Quick revision

• The attacker must complete every phase; the defender need break only one. That asymmetry is the kill-chain idea and the basis of defence in depth.
• Controls are preventive (stop it), detective (notice it), corrective (limit and repair), plus deterrent and compensating. The categories describe purpose, not technology.
• Reconnaissance: cannot be prevented, so reduce the public footprint and retire forgotten hosts; watch for look-alike domains.
• Scanning: default deny and drop, close unused ports, segment; detection is strong here, and internal scanning is a serious indicator.
• Gaining access: the phase that deserves the budget. Patch, multi-factor authentication, input validation, least privilege, no defaults.
• Maintaining access: the richest phase for detection. Hunt for new persistence, new accounts, lateral movement.
• Covering tracks: defeated by centralised, append-only, off-host logging; log clearing is itself a high-quality alert.

Test yourself

1. State the asymmetry between attacker and defender in the lifecycle model, and what follows from it.

The attacker must complete every phase successfully, while the defender needs to break only one. It follows that controls should be layered across the phases (defence in depth), so that the failure of any single control does not mean the failure of the defence.

1. Distinguish preventive, detective and corrective controls, and give one of each for the gaining-access phase.

Preventive controls stop the event (patching, multi-factor authentication); detective controls notice it (failed-login and anomaly alerting); corrective controls limit and repair the damage (isolating the host, revoking credentials, restoring from backup).

1. Which single control most directly defeats the covering-tracks phase, and why?

Centralised, append-only, off-host logging. An attacker who controls a host can alter anything stored on it, so only logs shipped immediately to a system the host cannot write to remain trustworthy; the attacker would have to compromise the logging infrastructure as well.

1. Why is reconnaissance the phase least amenable to preventive control, and what is the defensive answer?

Because it largely uses public sources and third parties, which you cannot stop anyone reading, and much of it never touches your systems. The answer is to reduce what is public (suppress versions, strip metadata, retire forgotten subdomains) and to watch for indirect signals such as newly registered look-alike domains.

1. Why is the maintaining-access phase described as the richest for detection?

Because persistence and lateral movement leave distinctive traces that are rare in normal operation: new auto-start entries, services, scheduled tasks and accounts, new administrative group memberships, and one host authenticating to many others. Threat hunting deliberately searches for these rather than waiting for an alert.

A flaw may be discovered independently by more than one party, and this is not a rarity. It is the fact that makes long disclosure delays risky: a vendor who takes a year to fix is not only keeping one researcher waiting, they are gambling that nobody else finds the same thing.

3. Reporting. The finder tells the vendor, through a security contact, a bug-bounty platform, or a coordinating body. The mechanics of doing this well, and the vendor's obligations, are the next chapter.

The quality of the report matters more than beginners expect: a reproducible report with clear steps and an assessment of impact gets triaged and fixed quickly, while a vague one sits in a queue.

4. Triage and remediation. The vendor confirms the flaw, works out how serious it is and what else is affected, and develops a fix. This is the stage that takes longest and the one outsiders understand least. A vendor must often fix the same flaw across several supported versions, test that the fix breaks nothing, and coordinate with downstream parties who ship their software inside other products.

That last point explains delays that look inexcusable from outside: a library flaw is not fixed when the library is fixed, but when every product embedding it has shipped an update, and some of those products are appliances on long release cycles.

5. Disclosure. The existence and usually the detail of the flaw is made public: an advisory is issued, a CVE identifier is assigned, and users are told to update. Ideally the fix and the advisory arrive together, so that the information that lets an attacker act arrives at the same moment as the means to be protected.

6. Patch availability, and then patch adoption. These are two different events and confusing them is a classic error. A fix existing does not protect anybody; a fix installed does. Between them sits testing, change control, maintenance windows, and in many organisations simple neglect. For appliances and embedded devices the gap can be permanent, because nobody ever updates them.

The two clocks

Put an attacker's knowledge and a defender's protection on the same timeline and the shape of the problem appears.

The period between an attacker knowing and a fix existing is the zero-day period: defenders are exposed and cannot patch, so the only defences are the generic ones, segmentation, least privilege, monitoring and, where the vendor offers one, a temporary workaround.

The period between a fix existing and a user installing it is, in aggregate, where most real-world compromise happens. Attacks overwhelmingly exploit known, patched vulnerabilities on unpatched systems, not zero-days. That is the most practically important sentence in this chapter, and it is why patch management is worth a chapter of its own later: the unglamorous discipline of installing fixes prevents more harm than any clever control.

A further consequence: public disclosure raises risk in the short term. Once details are published, the population capable of exploiting the flaw grows from a few to many, and exploitation of newly disclosed flaws typically rises sharply within days. This is not an argument against disclosure, which is what makes defenders able to act at all; it is the argument for having the fix ready first, and for patching quickly once it is.

A worked example

A flaw is introduced into a widely used library in January 2024 by a routine mistake.

• January 2024 to March 2026: nobody knows. The flaw is live in every product embedding the library. Risk in practice is near zero, because no one is using it.
• March 2026: an attacker finds it and uses it against a handful of targets. The window of exposure is now open and defenders do not know. This is a zero-day in use; the only defences are generic.
• April 2026: a researcher independently finds it and reports it to the vendor. The vendor now knows, but there is still no fix.
• May 2026: the vendor releases a fix, publishes an advisory and a CVE is assigned. Protection becomes possible. Exploitation attempts rise sharply in the following week as the details become public.
• May to December 2026: organisations patch, at very different speeds. Each one's window closes when it patches, not when the vendor shipped. Some appliances are never updated and remain exposed indefinitely.

Now read off the lessons: the flaw was live for two years before it mattered; independent discovery is real; the fix existing protected nobody by itself; and the long tail of unpatched systems is where most of the eventual damage occurs.

What beginners get wrong

• Confusing "a patch exists" with "we are protected". These are different events with a gap between them, and the gap is where most compromise happens.
• Believing most attacks use zero-days. The great majority exploit known, patched flaws on systems that were not updated. Zero-days are rare and expensive; unpatched systems are everywhere.
• Thinking a flaw is harmless until disclosed. It is live from introduction. Disclosure changes who can act, not whether the weakness exists.
• Assuming a slow vendor is simply negligent. Fixing across supported versions, testing for regressions and coordinating with downstream vendors takes real time, particularly for a library embedded in other products.
• Treating independent discovery as unlikely. It is common enough that it is the central risk in any long disclosure timeline.
• Forgetting the cheapest point. Preventing introduction through review, analysis and safer languages costs far less than remediating in the field.

Quick revision

• Stages: introduction (an ordinary mistake, live from the moment it ships), discovery (by vendor, researcher, academic or attacker, and possibly by more than one independently), reporting, triage and remediation (slow for good reasons, especially for embedded libraries), disclosure (ideally with the fix), patch availability, and patch adoption.
• Patch availability and patch adoption are different events; the window closes for each user only when that user patches.
• The zero-day period is when an attacker knows and no fix exists; defences are generic (segmentation, least privilege, monitoring, workarounds).
• Most real compromise exploits known, patched flaws on unpatched systems, not zero-days.
• Public disclosure raises short-term risk by widening who can exploit it, which is the argument for having the fix ready first and patching fast.
• Prevention at introduction (review, static analysis, memory-safe languages) is the cheapest intervention.

Test yourself

1. List the stages of the vulnerability lifecycle.

Introduction of the flaw, discovery by some party, reporting to the vendor, triage and remediation, public disclosure with an advisory and identifier, availability of a patch, and adoption of that patch by each user.

1. Why are "a patch is available" and "the window of exposure has closed" not the same event?

Because a fix protects only once installed. Between release and installation sit testing, change control and neglect, so each organisation's window closes when it patches; for devices nobody updates, it may never close.

1. What is the zero-day period, and what defences apply during it?

The interval in which an attacker knows of the flaw and no fix exists, so defenders cannot patch. Only generic controls apply: network segmentation, least privilege, monitoring and detection, and any temporary workaround the vendor publishes.

1. Why does independent discovery matter to disclosure policy?

Because a vendor who delays a fix is not only keeping one researcher waiting but gambling that no one else, including an attacker, finds the same flaw meanwhile. Independent discovery is common, which is the main argument against open-ended timelines.

1. Why does public disclosure raise risk in the short term, and why is it still the right practice?

Because publishing details expands the set of people able to exploit the flaw, and exploitation attempts rise sharply in the following days. It remains right because without disclosure defenders cannot know they are exposed or act at all; the answer is to have the fix available first and to patch quickly.

The key design feature is the fixed deadline. Without it, a vendor can neutralise a report by simply never responding, and the researcher has no lawful lever. With it, the vendor knows the clock is running and the researcher does not have to choose between waiting for ever and publishing recklessly.

Full disclosure, and when it is defensible

Full disclosure publishes everything at once, publicly. Its advocates make two arguments that deserve to be taken seriously rather than dismissed:

• It forces action. Historically, some vendors ignored private reports and fixed the same flaws within days of public exposure. The pressure is real and sometimes it is the only thing that works.
• It respects users' autonomy. Users are exposed whether or not they know. Telling them lets them decide, disable the feature, add a workaround, or switch products, rather than being kept ignorant for the vendor's convenience.

The objection is equally real: publication arms every attacker instantly, and the users least able to respond quickly are the ones harmed. Today the field treats full disclosure as a last resort, justified mainly where a vendor has ignored a good-faith coordinated report, or where the flaw is already being exploited and users need to defend themselves now.

A middle practice worth naming is partial disclosure: announcing that a flaw exists, with its severity and a workaround, while withholding the details that make exploitation easy. It warns without arming, though it is an unstable position, since researchers elsewhere often reconstruct the flaw from the hint.

The vendor's side, which is half the practice

Disclosure is not only something researchers do to organisations. A vulnerability arriving at an unprepared organisation goes badly, and the international standards recognise this by splitting the subject in two: ISO/IEC 29147 covers vulnerability disclosure, how an organisation receives and responds to reports from outside, and ISO/IEC 30111 covers vulnerability handling, the internal process of investigating and fixing.

What a mature vendor does:

• Publishes a way to be reached, and makes sure it reaches security people rather than a general support queue where reports are closed as "not a bug".
• Acknowledges quickly, within a day or two. Silence is the single biggest cause of researchers going public.
• Triages honestly, reproduces the issue, assesses severity and scope, and tells the finder what it concluded.
• Keeps the finder informed of progress and of the intended release date.
• Requests or assigns a CVE and issues an advisory naming affected versions and the fix.
• Credits the finder, unless they prefer anonymity.
• Does not threaten. Responding to a good-faith report with legal threats is the behaviour that pushes the entire field toward full disclosure, and it discourages the next finder from reporting at all.

The last point is worth dwelling on because it is the strategic argument. An organisation's choice is not between hearing about flaws and not having them. It is between hearing about them from a researcher or from an attacker. Everything above is designed to make the first more likely.

Where this leaves the ethical hacker

Two boundaries a student must not blur.

Disclosure policy does not confer permission to test. Coordinated disclosure governs what you do with a flaw you found lawfully. It says nothing about whether you were entitled to look. Finding a flaw in a stranger's system without authorisation is unauthorised access under section 43, and intending to report it is not a defence. The lawful route to finding flaws in someone else's systems is a bug bounty or a written scope.

Within an engagement, disclosure is to the client, not the world. A penetration tester's findings belong to the client under contract. Publishing them, even after the engagement, requires the client's agreement; writing them up as a case study without permission breaches confidentiality and, where personal data is involved, engages section 72A.

A worked example

A student finds, in a widely used open-source library, that a particular input causes it to return data from memory it should not.

Step 1. She checks how she found it. She was testing the library on her own machine, in her own project. That is lawful: it is her own system. Had she found it by probing a stranger's live service, she would have a legal problem before any disclosure question arose.

Step 2. She looks for a security contact and finds a security@ address and a published policy promising acknowledgement in three working days.

Step 3. She reports privately: affected versions, a minimal reproduction, the impact (memory disclosure, potentially including secrets), and her assessment that it is high severity. She does not publish anything.

Step 4. The maintainers acknowledge in two days, confirm it, and say a fix will take six weeks because three supported branches are affected and downstream distributors need lead time. She agrees, and they settle a coordinated publication date.

Step 5. On the agreed date the fix, the advisory and the CVE appear together, crediting her. She then publishes her own write-up, which is now safe because users can already protect themselves.

The variation that changes the answer. If, at step 4, the maintainers had never replied, she would have followed up, then notified a coordinating body, and at the end of her stated deadline published a limited advisory: enough for users to protect themselves, withholding the most directly weaponisable detail. That is the last-resort position, and it is defensible precisely because she exhausted the coordinated route first.

What beginners get wrong

• Thinking responsible disclosure means "tell everyone eventually". It means tell the vendor first and publish only after a fix or a fair deadline.
• Believing a disclosure policy legalises testing. It governs what you do with a flaw, not whether you were permitted to look for it. Authorisation is a separate question with a separate answer.
• Publishing a proof of concept immediately "to help defenders". Before a fix exists, a working exploit helps attackers far more, because defenders cannot patch what has no patch.
• Going public at the first silence. Follow up, escalate to a coordinating body, and give a stated deadline. Publishing in irritation is not full disclosure on principle.
• Treating the vendor as the adversary. Most delays are ordinary engineering and coordination. The adversarial posture is reserved for vendors who ignore or threaten.
• Writing up client findings publicly. Engagement findings are confidential and belong to the client; publishing needs their agreement.

Quick revision

• The dilemma: publishing at once arms attackers before a fix; saying nothing leaves users exposed; telling only the vendor can mean waiting for ever.
• Coordinated (responsible) disclosure: private report, agreed timeline (90 days is a common default, flexible both ways), publish after the fix or the deadline, credit the finder.
• The fixed deadline is the design feature that stops a vendor burying a report by never replying.
• Full disclosure: immediate publication; a last resort, defensible where a vendor has ignored a good-faith report or the flaw is already being exploited. Partial disclosure warns without arming.
• The vendor's half: ISO/IEC 29147 (receiving and disclosing) and ISO/IEC 30111 (internal handling). Publish a contact, acknowledge fast, triage honestly, keep the finder informed, issue an advisory and a CVE, credit, and never threaten.
• Disclosure policy is not permission to test; engagement findings belong to the client.

Test yourself

1. What problem does coordinated disclosure solve, and what is the role of the deadline?

It balances warning users against arming attackers: the vendor is told privately so a fix can exist before details are public. The deadline prevents a vendor neutralising the report by never responding, so that silence is not a permanent option.

1. When is full disclosure defensible?

As a last resort: principally where the vendor has ignored or refused to act on a good-faith coordinated report, or where the flaw is already being actively exploited and users need information to defend themselves immediately.

1. What do ISO/IEC 29147 and ISO/IEC 30111 each address?

29147 addresses vulnerability disclosure, how an organisation receives reports from outside and communicates about them; 30111 addresses vulnerability handling, the internal process of investigating, remediating and coordinating the fix.

1. Why is responding to a good-faith report with legal threats strategically self-defeating?

Because the organisation's real choice is whether it hears about flaws from researchers or from attackers. Threats discourage future reports, push the field toward full disclosure, and leave the organisation learning about its vulnerabilities only when they are exploited.

1. A researcher finds a flaw by probing a company's live website uninvited and then reports it responsibly. Does responsible disclosure make their conduct lawful?

No. Disclosure practice governs what is done with a flaw already found; it does not authorise the access. Probing without permission engages section 43 regardless of the intention to report. The lawful route is a bug bounty or a written scope.

CWE: the class of weakness

A CVE is an instance. CWE names the type of mistake behind it. Where CVE says "this flaw, in this product", CWE says "this is an SQL injection", or "this is an out-of-bounds write".

Examples a student should recognise:

CWE is hierarchical: broad classes contain narrower ones, so a specific weakness can be described at the level of detail that suits the purpose. That structure is what makes it useful for measurement, because you can count at a chosen level.

Why the distinction earns its keep. Suppose a company fixes twelve CVEs in a quarter. Counting CVEs tells them they fixed twelve bugs. Mapping them to CWEs might reveal that nine were CWE-89, SQL injection. That is a different and far more actionable fact: the problem is not twelve bugs, it is one practice, queries built by string concatenation. The fix is not twelve patches but a coding standard, a library, and a check in the build pipeline. CVE counts work; CWE reveals causes.

This is also why OWASP categories (a later chapter) map to CWEs: they are both talking about classes of weakness rather than instances.

The databases and the machinery

MU's topic speaks of vulnerability research, and the identifiers only matter because of what consumes them.

The National Vulnerability Database (NVD), run by the United States' NIST, takes CVE records and enriches them: it adds CVSS severity scores, CWE mappings, and structured data about affected configurations. In practice most tools read NVD rather than the bare CVE list, because the bare list has no severity.

Vendor advisories are the authoritative statement about a vendor's own products: which versions are affected, what the fix is, and any workaround. When a vendor advisory and a third-party description disagree, the vendor's is usually the one to act on.

Exploit and threat intelligence sources answer a different question: not "does this flaw exist?" but "is anyone actually using it?". A catalogue of vulnerabilities known to be exploited in the wild is more useful for prioritisation than severity alone, because a medium-severity flaw under active attack deserves attention before a critical one nobody has ever exploited.

Vulnerability scanners are the tools that tie it together. A scanner identifies the software and version running on a host (the enumeration of a later chapter), looks up which CVEs affect that version, and reports them with severity. Understanding that pipeline explains both the value and the limits of scanners:

• They find known flaws in identified software. They cannot find a flaw that has no CVE, and they cannot find anything in software they failed to identify.
• They infer from version numbers, so they produce false positives when a fix has been back-ported without changing the version string, which is common on Linux distributions, and false negatives when a banner is suppressed or wrong.
• They do not prove exploitability. That is the distinction between a vulnerability assessment and a penetration test from the earlier chapter.

A worked example

A scanner reports on a web server: CVE-2021-44228, CVSS 10.0, Apache Log4j 2.14.1.

Read it properly, piece by piece:

• CVE-2021-44228 is the name. It lets the team match this against the vendor advisory, the news coverage and the patch note, and confirm they are all the same issue.
• CVSS 10.0 is the severity, from NVD, and it is intrinsic, not the organisation's risk.
• Log4j 2.14.1 is the affected component and version, which tells them what to change.
• The CWE mapping (improper input neutralisation leading to injection) tells them the class, which prompts the wider question: where else do we evaluate untrusted input in a context that can execute?

The team then asks the questions the identifiers alone do not answer: is this server internet-facing, does it process untrusted input, is the flaw known to be exploited in the wild (it was, extensively), and do we have a temporary mitigation while we patch? That combination of identifier, severity, exposure and exploitation status is what real prioritisation uses.

What beginners get wrong

• Treating a CVE as a severity. It is a name. Severity is CVSS, and risk is severity plus context.
• Confusing CVE with CWE. CVE identifies one flaw in one product; CWE identifies the class of mistake. "CWE-89" is not a vulnerability, it is a kind of vulnerability.
• Reading "no CVEs" as "secure". It may mean the product is unexamined, or that the vendor fixes silently without requesting identifiers.
• Trusting a scanner's version inference absolutely. Back-ported fixes cause false positives; suppressed or wrong banners cause false negatives. A finding is a hypothesis until confirmed.
• Prioritising by CVSS alone. Exposure and whether the flaw is actually being exploited matter at least as much.
• Assuming the CVE year is the disclosure year. It is the year the identifier was reserved.

Quick revision

• CVE-YEAR-NUMBER uniquely names one vulnerability in one product, assigned by a CNA, coordinated by MITRE. It is a name, not a severity, not a database, and not proof of exploitability.
• CWE names the class of weakness and is hierarchical: CWE-79 cross-site scripting, CWE-89 SQL injection, CWE-787 out-of-bounds write, CWE-22 path traversal, CWE-352 CSRF, CWE-798 hard-coded credentials.
• CVE counts work done; CWE reveals the underlying practice to fix. Nine CVEs mapping to CWE-89 means one bad habit, not nine bugs.
• NVD enriches CVE records with CVSS scores and CWE mappings; vendor advisories are authoritative for their own products; exploited-in-the-wild catalogues answer whether anyone is actually using it.
• Scanners match identified versions to known CVEs: they miss what has no CVE or was not identified, produce false positives on back-ported fixes, and do not prove exploitability.

Test yourself

1. What is the difference between a CVE and a CWE?

A CVE uniquely identifies one specific vulnerability in one product, so that everyone refers to the same flaw. A CWE identifies the class or type of weakness that underlies it, such as SQL injection or out-of-bounds write. One names an instance; the other names the category.

1. Why is mapping findings to CWEs more useful than counting CVEs?

Because CVE counts measure work done while CWE mappings reveal the cause: several CVEs sharing one CWE show a single faulty practice, which can be fixed once through a standard, a library or a pipeline check, rather than patched repeatedly.

1. Why is "this product has no CVEs" weak evidence of security?

Because a lack of identifiers may mean the product is little examined, or that its vendor fixes issues silently without requesting CVEs. A well-scrutinised product may have many CVEs precisely because people are looking at it.

1. How does a vulnerability scanner reach its conclusions, and what are the two characteristic errors?

It identifies the software and version on a host and looks up which CVEs affect that version. It produces false positives when a fix has been back-ported without changing the version string, and false negatives when the version banner is suppressed, altered or misread. It also does not prove exploitability.

1. What does a CVSS score of 10.0 on a CVE tell you, and what does it not?

It tells you the flaw's intrinsic severity is maximal: remotely reachable, easy, requiring no privileges or interaction, with total impact and scope changed. It does not tell you your risk, which depends on whether you run the software, how exposed it is, and whether the flaw is being exploited in the wild.

Attack Complexity (AC): does it work reliably?

The question is reliability. High complexity means the attacker must succeed at something they cannot simply arrange, which genuinely reduces the practical threat. It does not mean "technically difficult": a sophisticated exploit that works every time is Low.

Privileges Required (PR): what must the attacker already have?

The question is what the attacker must start with. Requiring no privileges is worst. Note the curiosity that the Low and High weights are higher when Scope is Changed, because escaping the security boundary from a limited position is a more serious achievement.

User Interaction (UI): must a victim do something?

The question is whether the attack is self-contained. Requiring interaction lowers the score because it adds a dependency the attacker cannot guarantee, though in practice users do click, which is why phishing works and why this metric is sometimes argued to be generous to the defender.

Scope (S): does the damage stay in the box?

Scope is the metric students find hardest and it is the one that most often moves a score from High to Critical, so it repays attention.

The idea is a security authority: the thing that decides what a component may do. Scope is Changed when exploiting the vulnerable component lets the attacker affect resources governed by a different authority. The classic example is a virtual machine escape, where a flaw in the hypervisor's guest handling lets a guest affect the host or other guests: the attack began in one security authority and its effects landed in another.

Another common case is a vulnerable component that acts on the attacker's behalf against other systems, such as a flaw in a web application that causes the server to make requests to internal services. The application was the vulnerable component; the internal service belongs to a different authority.

Scope Changed both raises the Impact calculation and multiplies the final result, so it is worth getting right.

The Impact metrics: how bad if it works?

Confidentiality (C), Integrity (I) and Availability (A) are scored separately, and they are the CIA triad from the earlier chapter used as a measuring instrument.

Two points that examiners probe:

They are scored independently. A flaw that leaks data without altering anything is C:H/I:N/A:N. A flaw that crashes a service without revealing anything is C:N/I:N/A:H. A full system compromise is C:H/I:H/A:H.

If all three are None, the score is zero, regardless of how easy the flaw is to reach. A defect that affects nothing is not a vulnerability. This is the sanity check built into the model, and it is why "trivially exploitable" does not by itself mean "severe".

The severity bands

A worked reading of two vectors

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (this is Heartbleed's). Reachable over the network, works reliably, needs no privileges and no user action: the exploitability half is as bad as it gets. But the impact half is limited to confidentiality; it reads memory and alters nothing, destroys nothing. Scope Unchanged. The result is 7.5, High. The lesson: maximal exploitability with partial impact gives a High, not a Critical.

AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (this is Log4Shell's shape). The same maximal exploitability, but now every impact metric is High and Scope is Changed. The result is 10.0, Critical. The lesson: Scope plus total impact is what reaches the maximum.

Comparing the two vectors side by side is the most efficient way to understand the model, because only the impact half and Scope differ, and the score moves from 7.5 to 10.0.

What beginners get wrong

• Reading Attack Complexity as "technically difficult". It means the attacker depends on conditions outside their control. A sophisticated but reliable exploit is Low complexity.
• Confusing Privileges Required with User Interaction. The first is what the attacker must already have; the second is what a victim must do.
• Ignoring Scope. It is the metric that most often separates High from Critical, and it asks whether the impact escapes the vulnerable component's security authority.
• Assuming easy means severe. If all three impact metrics are None the score is 0.0 however trivial the flaw is to trigger.
• Treating the base score as the organisation's risk. It is intrinsic and deliberately context-free; risk adds exposure and business impact, which is the next chapter.
• Quoting the number without the vector. The vector is the reasoning; without it the score cannot be checked or argued.

Quick revision

• CVSS v3.1 Base gives 0.0 to 10.0 from eight metrics, always published with a vector string that records the reasoning.
• Exploitability: Attack Vector (Network, Adjacent, Local, Physical: how close), Attack Complexity (Low, High: reliability, not difficulty), Privileges Required (None, Low, High: what the attacker starts with), User Interaction (None, Required: must a victim act).
• Scope (Unchanged, Changed): does the impact escape the vulnerable component's security authority? Changed raises impact and multiplies the result.
• Impact: Confidentiality, Integrity, Availability, each High, Low or None, scored independently. All three None gives a score of 0.0.
• Bands: None 0.0; Low 0.1 to 3.9; Medium 4.0 to 6.9; High 7.0 to 8.9; Critical 9.0 to 10.0.

Test yourself

1. Name the eight base metrics and say which group each belongs to.

Exploitability: Attack Vector, Attack Complexity, Privileges Required, User Interaction. Impact: Confidentiality, Integrity, Availability. Scope sits between them, describing whether the impact escapes the vulnerable component's security authority.

1. What does Attack Complexity actually measure, and why is "this exploit is very sophisticated" not the test?

It measures whether exploitation depends on conditions beyond the attacker's control, such as winning a race condition or already knowing a secret. A highly sophisticated exploit that works reliably every time is Low complexity, because nothing outside the attacker's control has to go right.

1. Explain Scope, and give an example of Scope Changed.

Scope records whether exploiting the vulnerable component affects resources governed by a different security authority. A virtual machine escape is the classic example: the flaw is in the hypervisor's handling of a guest, and the impact lands on the host or on other guests, which belong to a different authority.

1. Why can a trivially exploitable flaw score 0.0?

Because if Confidentiality, Integrity and Availability impacts are all None, the flaw affects nothing, and the model returns zero regardless of how reachable or reliable it is. Exploitability without impact is not a vulnerability.

1. Heartbleed scores 7.5 and Log4Shell 10.0 although both are network-reachable, reliable, and need no privileges or interaction. What accounts for the difference?

The impact half and Scope. Heartbleed affects confidentiality only, with integrity and availability None and Scope Unchanged; Log4Shell has all three impacts High and Scope Changed, which both raises the impact calculation and multiplies the final score.

The result. Adding, 3.5952 plus about 3.887 is about 7.482, and the roundup gives 7.5, which is High. That matches the published score in the National Vulnerability Database, which is the check that the method was applied correctly.

Notice which half limited the result. The exploitability half was as large as it can be; the impact half was held down because two of the three impact metrics are None. Heartbleed reads memory and alters nothing, and that is the whole reason it is 7.5 rather than 10.

Working it by program

The same computation as a small program. It is safe and self-contained: arithmetic on a vector string, attacking nothing.

import math

AV = {"N": 0.85, "A": 0.62, "L": 0.55, "P": 0.20}
AC = {"L": 0.77, "H": 0.44}
UI = {"N": 0.85, "R": 0.62}
CIA = {"H": 0.56, "L": 0.22, "N": 0.00}
PR_UNCHANGED = {"N": 0.85, "L": 0.62, "H": 0.27}
PR_CHANGED = {"N": 0.85, "L": 0.68, "H": 0.50}


def roundup(value):
    # The specification's Roundup: the smallest one-decimal number >= value.
    scaled = round(value * 100000)
    if scaled % 10000 == 0:
        return scaled / 100000.0
    return (math.floor(scaled / 10000) + 1) / 10.0


def base_score(av, ac, pr, ui, scope, c, i, a):
    changed = scope == "C"
    pr_weight = (PR_CHANGED if changed else PR_UNCHANGED)[pr]
    exploitability = 8.22 * AV[av] * AC[ac] * pr_weight * UI[ui]
    iss = 1 - (1 - CIA[c]) * (1 - CIA[i]) * (1 - CIA[a])
    if changed:
        impact = 7.52 * (iss - 0.029) - 3.25 * (iss - 0.02) ** 15
    else:
        impact = 6.42 * iss
    if impact <= 0:
        return 0.0
    combined = impact + exploitability
    if changed:
        combined = 1.08 * combined
    return roundup(min(combined, 10))


def score_vector(vector):
    fields = dict(pair.split(":") for pair in vector.split("/")
                  if ":" in pair and not pair.startswith("CVSS"))
    return base_score(fields["AV"], fields["AC"], fields["PR"],
                      fields["UI"], fields["S"], fields["C"],
                      fields["I"], fields["A"])


examples = [
    ("AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N", "Heartbleed: reads memory only"),
    ("AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "Log4Shell shape: total, scope changed"),
    ("AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "local privilege escalation"),
    ("AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N", "stored-XSS shape: needs a click"),
    ("AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N", "reachable but affects nothing"),
]
for vector, description in examples:
    print(f"{score_vector(vector):>5}  {vector}  ({description})")

  7.5  AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  (Heartbleed: reads memory only)
 10.0  AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H  (Log4Shell shape: total, scope changed)
  7.8  AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  (local privilege escalation)
  4.2  AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N  (stored-XSS shape: needs a click)
  0.0  AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N  (reachable but affects nothing)

Read the five lines as a set, because together they teach the model better than any single one.

• 7.5 reproduces the hand calculation and the published figure.
• 10.0 shows what reaches the maximum: total impact plus Scope Changed.
• 7.8 is instructive: the impact is total, exactly as in the 10.0 case, yet the score is lower, because Attack Vector is Local. Reach matters as much as damage.
• 4.2 shows the cost of dependencies: High complexity and a required user action pull a genuine flaw down into Medium.
• 0.0 is the sanity check from the previous chapter, demonstrated: a flaw that is network-reachable, reliable and needs nothing at all scores zero when it affects none of the three properties.

Temporal metrics: what is true today

The base score is deliberately frozen; it describes the flaw itself and never changes. But the practical danger does change, and the Temporal group captures that. It can only ever lower the score from the base, never raise it.

• Exploit Code Maturity. Is there a working exploit? The range runs from Unproven, through Proof-of-Concept and Functional, to High (reliable, widely available, or automated in tooling). A flaw with public reliable exploit code is a different practical problem from one nobody has weaponised.
• Remediation Level. Is there a fix? From Unavailable, through Workaround and Temporary Fix, to Official Fix. A flaw with an official patch is less dangerous in practice, because you can act.
• Report Confidence. How sure are we that this is real and correctly described? From Unknown, through Reasonable, to Confirmed.

The useful insight is that Temporal metrics move in opposite directions over time: as a flaw ages, exploit code tends to mature (raising practical danger) while remediation becomes available (lowering it). Which dominates is exactly the question a triage meeting is arguing about.

Environmental metrics: what is true for you

The Environmental group re-scores the flaw for a specific organisation, and this is where "severity" finally becomes "risk".

• Security Requirements (CR, IR, AR). How much do Confidentiality, Integrity and Availability matter for this asset? Each can be Low, Medium or High. A public marketing site may have Low confidentiality requirement and High availability requirement; a payroll database the reverse. These reweight the impact metrics.
• Modified Base Metrics. Any base metric can be overridden to reflect your deployment. If a flaw is scored Attack Vector Network but in your network the service is reachable only from an internal segment, you set Modified Attack Vector to Adjacent or Local and the score falls accordingly. If you have already applied a compensating control that requires authentication in front of it, Modified Privileges Required rises.

This is the formal answer to the complaint that "CVSS does not know my network". It can, if you supply the information, and mature vulnerability-management programmes do exactly this rather than working from base scores alone.

Prioritising properly

Putting the chapter together, a sound priority order uses three inputs, not one:

1. Base severity, the intrinsic score.
2. Exposure, from the Environmental group: is the affected thing internet-facing, does it hold important data, is it reachable by untrusted users?
3. Exploitation status, from the Temporal group and from threat intelligence: is this being exploited in the wild right now?

The third is the one teams most often omit and the one that most improves decisions. A Medium-severity flaw under active mass exploitation on an internet-facing server outranks a Critical flaw on an isolated internal system that nobody has ever exploited. A scanner sorting purely by base score will get that ordering exactly backwards.

What beginners get wrong

• Treating the base score as risk. It is intrinsic and context-free by design. Risk needs exposure and exploitation status, which the Environmental and Temporal groups supply.
• Expecting Temporal metrics to raise the score. They only lower it from the base.
• Rounding intermediate values and then adding. CVSS keeps full precision until the final roundup; rounding early gives a slightly wrong answer.
• Forgetting that Roundup is always upward. It is not round-to-nearest, so 7.401 becomes 7.5.
• Ignoring Scope in the final step. Scope Changed both alters the Impact formula and multiplies the combined value by 1.08.
• Patching strictly in base-score order. Exposure and active exploitation routinely reorder the list, and ignoring them wastes effort on flaws nobody is using.

Quick revision

• ISS = 1 - (1 - C)(1 - I)(1 - A); impacts compound but saturate.
• Impact = 6.42 x ISS (Scope Unchanged) or a curve (Scope Changed). Exploitability = 8.22 x AV x AC x PR x UI.
• Base = Roundup(min(Impact + Exploitability, 10)), with the sum first multiplied by 1.08 if Scope is Changed. Impact of zero gives 0.0. Roundup is always upward, to one decimal.
• Heartbleed works out to 7.5; total impact with Scope Changed reaches 10.0; the same total impact with Attack Vector Local gives 7.8.
• Temporal (Exploit Code Maturity, Remediation Level, Report Confidence) adjusts for what is true today and can only lower the score.
• Environmental (Security Requirements CR/IR/AR, and Modified Base Metrics) re-scores for your deployment, and is how severity becomes risk.
• Prioritise on three inputs: base severity, exposure, and whether it is being exploited in the wild.

Test yourself

1. State the four steps of the base-score calculation.

Compute the Impact Sub-Score from the three impact metrics as 1 minus the product of their survivals; scale it into Impact according to Scope; compute Exploitability as 8.22 times the four exploitability weights; add Impact and Exploitability, multiply by 1.08 if Scope is Changed, cap at 10 and round up to one decimal.

1. Two flaws both have Confidentiality, Integrity and Availability all High, but one scores 10.0 and the other 7.8. What explains the difference?

The exploitability half. The 10.0 case is network-reachable with Scope Changed; the 7.8 case has Attack Vector Local, so despite identical total impact the attacker must already be on the machine, and no Scope multiplier applies.

1. What do the Temporal metrics capture, and can they increase the base score?

Exploit Code Maturity, Remediation Level and Report Confidence, which describe the current state of the flaw in the world rather than the flaw itself. They can only lower the score relative to the base, never raise it.

1. How do the Environmental metrics turn severity into risk?

By letting an organisation state how much Confidentiality, Integrity and Availability matter for the specific asset (the Security Requirements) and by overriding any base metric to match the actual deployment, for example reducing Attack Vector from Network to Local where the service is only internally reachable.

1. Why can a Medium-severity flaw legitimately be patched before a Critical one?

Because prioritisation combines base severity with exposure and exploitation status. A Medium flaw on an internet-facing system that is being actively exploited presents more real risk than a Critical flaw on an isolated internal system with no known exploitation.

Reward structure. What a valid finding pays, banded by severity, often using CVSS from the previous chapters as the starting point. Programmes vary from recognition only (a "hall of fame"), properly called a vulnerability disclosure programme, to substantial payments for critical findings.

Safe harbour. A written promise that the organisation will not pursue legal action against researchers who act in good faith within the policy, and that it will not ask others to. This is the clause that does the real work: it is the organisation stating that activity under the policy is authorised and will not be treated as an offence. A programme without a safe-harbour statement offers weaker assurance, and experienced researchers check for it before spending time.

Disclosure terms. Whether and when a researcher may publish, usually after a fix and with the organisation's agreement.

How a finding is reported and rewarded

The lifecycle of one bounty finding is the vulnerability lifecycle run quickly:

1. The researcher tests within scope and finds a flaw.
2. They write a report and submit it privately through the programme's platform.
3. The organisation triages: reproduces it, assesses severity, may ask questions, and decides whether it is in scope and novel.
4. If valid, they pay and credit, and fix the flaw.
5. Public disclosure, if any, happens later and by agreement.

What a good report contains, because this is what separates a paid finding from a rejected one:

• A clear title naming the flaw and where it is.
• The affected target, exactly (URL, endpoint, parameter, application version).
• Steps to reproduce, numbered, precise enough that a triager can follow them without guessing, including the accounts used.
• Evidence: request and response, or a screenshot, with sensitive values masked.
• Impact: what an attacker could actually achieve. This is the part researchers skimp and triagers care most about.
• A suggested severity with a CVSS vector, and ideally a remediation suggestion.

"Your site is vulnerable to XSS" earns nothing. "The search parameter on this endpoint reflects input into the page without encoding; steps below; an attacker can run script in a victim's session and read their session token; suggested CVSS vector; fix by contextual output encoding" earns the reward and the fix.

Why reports get rejected, which is worth knowing before you write one:

• Out of scope, the commonest reason by far.
• Duplicate: somebody reported it first. Bounties usually pay only the first reporter, which is why speed matters and why disputes arise.
• Not a vulnerability: accepted behaviour, or a theoretical issue with no demonstrable impact. Missing security headers with no exploitable consequence are the classic example.
• No demonstrated impact: the researcher showed a quirk but not what an attacker gains.
• Scanner output pasted in without verification or analysis, which most programmes explicitly refuse.

A worked example

Priya reads the policy for a shopping company's programme: scope is *.example-shop.test; denial of service and social engineering are forbidden; rewards run from a small sum for Low to a large one for Critical; there is a clear safe-harbour clause; publication requires agreement.

• She tests only subdomains of example-shop.test. She notices an interesting login portal on a different domain the same company owns and does not touch it, because the scope does not name it; instead she asks the programme whether it can be added. That single decision is the difference between a researcher and a defendant.
• She finds that a password-reset link remains valid after use, so an old link found in a forwarded email or a browser history could be replayed to take over an account.
• She writes it up: the endpoint, the exact steps with two of her own test accounts, the masked evidence, the impact (account takeover without the victim's password), a CVSS vector suggesting Medium, and the fix (invalidate the token on first use and on password change).
• The company confirms it, pays the Medium band, credits her, and ships the fix. She publishes nothing until they agree.

Compare this with the grey hat of the earlier chapter, who found a flaw on a stranger's site uninvited: identical skill, identical technique, and an entirely different legal position. The bounty is the difference, and the difference is permission granted in advance.

What beginners get wrong

• Reading a bounty as permission to test anything the company owns. The permission is exactly the published scope and no wider. A system the same company owns but did not list is unauthorised.
• Assuming every programme pays. Many offer only recognition. Read the policy first.
• Breaking the rules of engagement to "prove impact". Running a denial-of-service test inside a bounty that forbids it breaks the policy and the safe harbour, turning authorised testing back into an offence.
• Publishing to get attention. Disclosing before the organisation agrees breaches the terms, forfeits the reward, and damages the trust the whole arrangement depends on.
• Reporting scanner output. Programmes refuse it. A finding needs verification, impact and analysis.
• Omitting impact. Triagers must justify payment internally; a report that does not explain what an attacker gains gives them nothing to justify.
• Testing with real user data. Almost always forbidden, and it engages the confidentiality provisions of the Act. Use the test accounts provided.

Quick revision

• A bug bounty is a standing, public authorisation to test named targets under published rules, rewarding valid findings. It grants permission in advance, which is what makes it lawful.
• Parts: scope (the legal boundary, with exclusions), rules of engagement (usually forbidding denial of service, social engineering, real user data), reward structure (banded by severity, often CVSS-based), safe harbour (no legal action for good-faith work in policy), disclosure terms.
• A vulnerability disclosure programme offers recognition without payment; a bug bounty pays.
• A good report: title, exact target, numbered reproduction steps, masked evidence, impact, suggested severity and fix.
• Rejections: out of scope, duplicate, not a vulnerability, no demonstrated impact, unverified scanner output.
• A bounty complements a penetration test: breadth and continuity against structured, guaranteed coverage.

Test yourself

1. How does a bug bounty make testing lawful when uninvited testing is not?

It is a standing, public grant of permission to anyone who accepts its rules, so testing within its scope is authorised and does not fall under section 43's "without permission of the owner", which uninvited testing does regardless of motive.

1. What is a safe-harbour clause, and why do experienced researchers check for it?

A written undertaking that the organisation will not take legal action against researchers acting in good faith within the policy. Researchers check for it because it is the organisation's explicit assurance that policy-compliant activity is authorised rather than an offence.

1. A researcher on a bounty finds a promising system the company owns but which is not listed in scope. What should they do, and why?

Not test it, and ask for it to be added. Ownership by the company is not authorisation: the permission extends only to the published scope, so testing an unlisted system is unauthorised access.

1. List four things a report must contain to be paid, and give the commonest reasons reports are rejected.

The exact affected target, numbered steps to reproduce, evidence with sensitive values masked, and a statement of impact (plus a suggested severity and fix). Reports are rejected chiefly for being out of scope, duplicates, not actually vulnerabilities, lacking demonstrated impact, or being unverified scanner output.

1. How does a bug bounty differ from a penetration test as a way of finding flaws?

A bounty is continuous, pays per valid finding, and draws on many researchers, giving breadth but no guarantee of coverage. A penetration test is time-boxed and paid for effort, and gives structured, guaranteed coverage of an agreed scope with a report. They complement each other.

A worked example: reading Heartbleed with the module's tools

Which property broke? Confidentiality, and only confidentiality. Nothing was altered, nothing was destroyed, and the service kept running. That single observation predicts the score.

The CVSS vector. AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N:

• Attack Vector Network: any client that could open a TLS connection.
• Attack Complexity Low: it worked reliably every time.
• Privileges Required None: no account, no authentication. The heartbeat could be sent before authentication.
• User Interaction None: no victim had to do anything.
• Scope Unchanged: the damage stayed within the vulnerable component's own security authority.
• C:H, I:N, A:N: total confidentiality loss; no integrity or availability impact.

The score is 7.5. The previous chapter worked it by hand and the calculator reproduced it. The instructive point: the exploitability half was as bad as the model allows, and it still did not reach Critical, because two of three impact metrics were None. A student who can explain why Heartbleed is 7.5 rather than 10.0 has understood CVSS.

The lifecycle. The flaw was introduced in released code in 2012 and disclosed in April 2014, so it was live and unknown for roughly two years. It was found independently by more than one party at about the same time, which is the scenario coordinated disclosure most fears: once two people know, the timeline cannot be leisurely. A fixed version of OpenSSL was released on the day of public disclosure, so the advisory and the patch arrived together, which is the ideal the disclosure chapter described.

What made it worse than the score suggests

Three aggravating features, and they are the parts that generalise.

It left no trace. A heartbeat request is a normal protocol message. Exploiting the flaw did not crash anything, did not create an error, and was not recorded by ordinary server logs. So after disclosure, no organisation could determine whether it had been exploited. The honest position for every affected site was to assume the worst: rotate the private key, obtain a new certificate, revoke the old one, and require users to change passwords. An attack that leaves no evidence forces you to act as though it happened, which is far more expensive than responding to a known incident.

The private key was reachable. Most confidentiality breaches expose data. This one could expose the key that protects all future and, where forward secrecy was not in use, past traffic. Recovery therefore meant re-keying, not merely patching.

Nobody knew where it was installed. Almost no organisation ran "OpenSSL" as a product they had chosen. They ran web servers, load balancers, VPN appliances, mail servers, embedded devices and vendor applications that contained OpenSSL. Patching required first discovering where it was, which many could not do quickly, and for appliances it meant waiting for a vendor update that sometimes never came. This is the supply-chain lesson, and it is why the OWASP list now carries a supply-chain category and why a software bill of materials matters.

The defensive analysis

Ask the four questions a case study should answer.

How was it found? By researchers auditing widely used cryptographic code, which is the argument for funding review of shared infrastructure. The flaw sat in code that vast numbers of systems depended on and very few people were paid to examine.

Which control would have prevented it? At the source, input validation: check the length field against reality. More broadly, memory-safe languages or bounds-checked buffer handling remove this entire class, which is the argument made in the buffer overflow chapters later. Static analysis and fuzzing target exactly this shape of defect.

Which control would have detected it? Essentially none in place at the time, which is the chapter's hardest lesson. Ordinary logging did not record it. Detection would have required inspecting heartbeat requests for a mismatch between claimed and actual length, which no one was doing because no one knew it mattered.

Which control would have limited the damage? Forward secrecy in the TLS configuration, which means that compromising the long-term private key does not let an attacker decrypt previously recorded sessions. Sites using it had a materially smaller problem. Rapid key rotation capability also limited it: organisations that could re-key and reissue certificates quickly recovered in days, and those that could not took months.

Lessons that generalise

• Severity is not the whole story. A 7.5 caused a global emergency, because of ubiquity, invisibility and the reachability of the key. Base score plus context is the real measure.
• Shared components concentrate risk. One mistake in one library affected a large fraction of the secure web at once.
• You cannot respond to what you cannot see. Attacks that leave no evidence force expensive precautionary responses.
• Inventory is a security control. The organisations that recovered fastest were the ones that could answer "where do we run this?" quickly.
• Simple bugs cause the biggest incidents. A missing length check, not a sophisticated cryptographic break.

What beginners get wrong

• Calling it an encryption flaw. TLS and its cryptography were not broken. The flaw was a memory-handling mistake in one implementation of one extension, and it leaked data that happened to be nearby.
• Thinking it let an attacker choose what to read. It returned whatever was adjacent in memory. The attacker repeated it many times and sifted the results; control was statistical, not precise.
• Assuming patching finished the job. Because the private key might have been exposed and there was no way to know, recovery required re-keying, new certificates, revocation, and user password changes.
• Expecting logs to show exploitation. They did not. That is the point, and it is why the response had to be precautionary.
• Treating it as an OpenSSL problem. It was a problem for everyone who shipped or ran anything containing OpenSSL, which was almost everyone.

Quick revision

• CVE-2014-0160, disclosed April 2014, in OpenSSL's TLS heartbeat extension. A buffer over-read (CWE-125): the code trusted the client's length field instead of checking it against the payload received, returning up to 64 KB of adjacent process memory per request.
• Breaks confidentiality only; vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, score 7.5, High. Not 10.0 because integrity and availability are unaffected.
• Live and unknown for about two years; found independently by more than one party; fix and advisory released together, which is coordinated disclosure done right.
• Aggravating factors: no trace in logs (forcing precautionary response), the private key was reachable (forcing re-keying), and it was embedded in countless products (the supply-chain problem).
• Defences: validate the length (the direct fix), memory-safe or bounds-checked handling (the class fix), forward secrecy to limit the damage of key compromise, and an inventory so you can find where you run it.

Test yourself

1. Explain the Heartbleed mechanism in two sentences.

The TLS heartbeat message carries a payload and a length field, and OpenSSL copied back the number of bytes the client claimed rather than the number actually received. A client claiming a large length with a tiny payload therefore received up to 64 kilobytes of whatever lay adjacent in the server's process memory.

1. Why does Heartbleed score 7.5 rather than 10.0 when it is remotely exploitable, reliable, and needs no privileges or interaction?

Because the impact half is limited: it affects confidentiality only, with integrity and availability both None and Scope Unchanged. Maximal exploitability with partial impact yields a High rather than a Critical.

1. Why was patching alone an inadequate response?

Because the server's private key might have been disclosed and exploitation left no trace, so no organisation could prove it had not happened. Recovery therefore required generating new keys, obtaining and deploying new certificates, revoking the old ones, and having users change passwords.

1. What made Heartbleed a supply-chain problem, and which control most helped organisations respond?

Almost nobody ran OpenSSL as a chosen product; it was embedded in web servers, appliances, VPNs and vendor applications, so organisations first had to discover where it was. An accurate inventory of software components was what let the fastest responders act, and for appliances they depended on vendor updates.

1. Which configuration choice limited the damage for sites that had made it, and why?

Forward secrecy, because it ensures that compromise of the long-term private key does not permit decryption of previously recorded sessions. Sites using it faced a smaller retrospective exposure than those where the key alone would unlock past traffic.

No authentication was needed, because applications log requests before and regardless of authentication. No user interaction was needed. And the attacker did not need to find a vulnerable input field in the usual sense, because any logged field would do, which made it nearly impossible to defend by filtering one place.

In the classification vocabulary, the root weakness is improper neutralisation of attacker-controlled input leading to code execution, with an element of unsafe deserialisation or remote class loading through JNDI.

A worked example: reading Log4Shell with the module's tools

Which properties broke? All three. The attacker could read data (confidentiality), alter it (integrity) and destroy or disable the service (availability), because running arbitrary code on a host gives all of it. Contrast Heartbleed, which broke only confidentiality, and the difference in score follows immediately.

The CVSS vector. AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H:

• Attack Vector Network: any request reaching the application.
• Attack Complexity Low: reliable, and the trigger string was short.
• Privileges Required None: no account needed, because logging happens before authentication.
• User Interaction None: no victim action required.
• Scope Changed: this is the metric worth dwelling on. The vulnerable component was a logging library, whose security authority is, notionally, logging. Exploiting it gave control of the entire host process and whatever that process could reach, which is a different security authority altogether. That is exactly what Scope Changed is defined to capture, and it is why this flaw illustrates the metric better than any other.
• C:H, I:H, A:H: total impact on all three.

The score is 10.0. The calculator in the CVSS chapter reproduced it. Nothing scores higher, and the combination that gets there is total impact plus scope change plus maximal exploitability.

What made it exceptionally hard to handle

Nobody knew where it was. Log4j is a dependency of a dependency of a dependency. Organisations ran Java applications, vendor appliances, cloud services and internal tools that contained it several layers down, often without the vendor knowing either. The first and hardest task was not patching; it was discovery. Teams spent days answering "do we even run this?" before they could begin to fix anything. This is the supply-chain lesson in its purest form, and the direct argument for a software bill of materials, a machine-readable inventory of every component in a product, which turns that multi-day question into a query.

The attack surface was everything. Because any logged string could carry the trigger, and applications log headers, usernames, search terms and error messages, there was no single input to validate. Attempts to block the pattern by filtering failed repeatedly, because the string could be obfuscated in many ways using the library's own nested-lookup capability. This is a general lesson: filtering a dangerous pattern is a weak control when the attacker controls the encoding.

Exploitation began immediately and at scale. Because the flaw was trivial to trigger and the details public, mass internet-wide scanning for it started within hours of disclosure. The window between disclosure and exploitation was not days, it was hours, which is the practical demonstration of the point in the disclosure chapter about public disclosure raising short-term risk.

Fixes arrived in stages. The first mitigation turned out to be incomplete, and further advisories and versions followed as related issues were found. Organisations that patched once and stopped were not fully protected, which is a lesson in itself: for a flaw of this shape, track the advisory rather than applying one update.

The defensive analysis

Which control would have prevented it? At the library, not performing lookups on message content, which is what the fix did (the behaviour was disabled by default in later versions). At the application, nothing reasonable: the developers did nothing wrong by logging user input, which is precisely why this case is disturbing.

Which control would have limited it? Egress filtering, and this is the most transferable lesson in the chapter. The exploit required the victim server to make an outbound connection to the attacker's machine to fetch the class. A server that is not permitted to open arbitrary outbound connections to the internet could be triggered but could not complete the attack. Most organisations allow unrestricted outbound traffic from servers because it is convenient; those that did not were substantially protected by a control they had put in place for unrelated reasons.

Two others: least privilege, so that the code ran with limited rights and reached less; and network segmentation, so the compromised host could not reach everything else.

Which control would have detected it? Outbound connection logging, because the tell-tale sign is a server suddenly making connections to an unfamiliar external address. This is a good example of detection being available to organisations that log the right thing, which is usually egress rather than ingress.

Which control made response possible? Inventory, again. The organisations that responded in hours rather than weeks were those that already knew their software components.

Heartbleed and Log4Shell compared

Studying the pair is more instructive than either alone, because the contrast isolates what is common: both were in shared components, both were reachable by unauthenticated remote input, and in both cases the decisive factor in recovery was whether the organisation knew what it was running.

What beginners get wrong

• Calling it a bug in logging. The library did what it was documented to do; the flaw was that a convenience feature was applied to untrusted content. That is a design failure, not a coding slip.
• Thinking the application developers were careless. Logging user input is normal and correct. This is the case that shows a safe application can be compromised through a dependency.
• Believing input filtering was a fix. The trigger could be obfuscated using the library's own features, and attempts to block it by pattern failed. Removing the capability was the fix.
• Assuming a single patch closed it. Follow-up advisories addressed related issues; tracking the advisory was necessary.
• Missing why Scope is Changed. The vulnerable component was a logging library; the impact was control of the whole host process, which is a different security authority.
• Overlooking egress filtering. The exploit needed an outbound connection from the victim to the attacker. Blocking that broke the chain, and it is the control most organisations still do not apply.

Quick revision

• CVE-2021-44228, December 2021, Apache Log4j 2. A documented message-lookup feature performed JNDI lookups on attacker-controlled log content, causing the host to fetch and execute a remote class.
• Triggered by logging any attacker-supplied string (a header, a username, a search term), before authentication, with no user interaction.
• Vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, score 10.0. Scope Changed because a logging library's flaw yielded control of the whole host.
• Hard to handle because organisations did not know they contained it (a dependency of a dependency), the trigger could appear in any logged field, filtering could be obfuscated around, exploitation began within hours, and fixes came in stages.
• Controls: remove the capability (the real fix); egress filtering, which breaks the required outbound fetch; least privilege and segmentation to limit reach; outbound connection logging to detect; and a software bill of materials to make response possible.
• Against Heartbleed: a feature rather than a mistake, all three properties rather than one, Scope Changed rather than Unchanged, 10.0 rather than 7.5.

Test yourself

1. Explain the Log4Shell mechanism and why the application developers were not at fault.

Log4j substituted lookups into log message content, and one lookup type used JNDI, which can fetch and load a class from a remote server. Because the substitution applied to the message content, logging an attacker-supplied string caused the host to fetch and execute attacker-chosen code. Developers were not at fault because logging user-supplied input is normal and correct; the dangerous behaviour was inside the dependency.

1. Why is Scope recorded as Changed, and what does that contribute to the score?

Because the vulnerable component was a logging library, whose security authority is logging, while successful exploitation yielded arbitrary code execution over the entire host process and what it could reach, which belongs to a different authority. Scope Changed raises the impact calculation and multiplies the combined score by 1.08, helping it reach the maximum 10.0.

1. Why was input filtering an inadequate response?

Because the trigger string could be obfuscated in many forms using the library's own nested-lookup capability, and because the input could arrive in any field the application logged, so there was no single place to filter. The effective fix was to remove the lookup capability.

1. Which network control would have broken the attack chain even on an unpatched server, and why?

Egress filtering. Exploitation required the victim server to make an outbound connection to the attacker's machine to retrieve the class, so a server not permitted to open arbitrary outbound internet connections could be triggered but could not complete the attack.

1. Compare Heartbleed and Log4Shell in terms of root cause, properties broken and the hardest part of the response.

Heartbleed was a coding mistake (a missing length check) that broke confidentiality only, and its hardest response problem was re-keying, because exploitation left no trace and could not be disproved. Log4Shell was a documented feature reached by untrusted input, broke all three properties with Scope Changed, and its hardest response problem was discovering where the component was installed, since it was an indirect dependency.

Legally, passive reconnaissance reads information that is already public and does not touch the target's computers, so it does not engage section 43, which turns on access to a computer, computer system or network without permission. Reading a public web page is not unauthorised access to the publisher's computer in the sense the section addresses.

Two qualifications a careful student should hold. Privacy law is a separate question from the IT Act: compiling a detailed profile of identifiable individuals can raise data-protection issues even where each fact is public, which is why professional engagements restrict people-focused reconnaissance to what the scope requires. And the platform's terms may prohibit automated collection, which is a contractual matter rather than a criminal one but can still cause trouble.

Active reconnaissance

Active reconnaissance interacts with the target's systems. The moment you send a packet to a machine the target owns, you have left the passive world.

Examples:

• Resolving a host name against the target's own authoritative name server (as opposed to a public resolver's cache).
• Connecting to a web server to read its response headers.
• Requesting a page directly rather than through a cache.
• Attempting a DNS zone transfer.
• Any port scan, though scanning is usually treated as its own phase.

The defining property is the mirror image: the target's systems now hold a record of you. Web server logs, DNS query logs, firewall logs and intrusion detection systems can all see active reconnaissance, and a competent defender can detect it.

Legally, this is where section 43 begins to apply. Touching a computer system without permission is an act under clause (a), and the section requires neither damage nor dishonest intent. So the practical rule for a student is blunt: passive reconnaissance against anyone is generally fine; active reconnaissance happens only against systems you own or are authorised in writing to test.

The line is blurrier than it looks

Three cases that examiners like, and that a thoughtful answer acknowledges.

Visiting a website. Loading a company's public home page in a browser technically connects to their server, so it is interaction. In practice nobody treats ordinary browsing of a public page as active reconnaissance, because the page is published for that purpose and the visit is indistinguishable from any other visitor's. The distinction that matters is intent and pattern: one ordinary page view is browsing; a thousand automated requests enumerating paths is active reconnaissance and is visible as such.

DNS resolution. Asking a public resolver for a record usually returns a cached answer and never reaches the target: passive. Asking the target's own authoritative name server reaches their machine: active. Same question, different route, different side of the line.

Third-party services. If the target's website is hosted by a provider, touching it touches the provider's infrastructure too, which is why scopes name third parties explicitly and why the client cannot authorise testing of systems it does not own.

The professional resolution is not to reason about these at the keyboard. It is to have the scope settled first, which is what the authorisation chapter was for.

Competitive intelligence and OSINT

MU's bullet names competitive intelligence alongside OSINT, and the relationship is worth stating: they are the same activity done for different purposes.

Open-source intelligence (OSINT) is the collection and analysis of publicly available information to produce actionable knowledge. The term comes from the intelligence community, and the important word is analysis: OSINT is not a pile of facts, it is what the facts mean when combined.

Competitive intelligence is the lawful gathering of public information about commercial rivals: their products, hiring, suppliers, financial filings and strategy. Businesses do it openly and it is a recognised profession.

The overlap is nearly total in technique, and the difference is purpose. A competitive-intelligence analyst reading a job advertisement notes that a rival is expanding into a new area; a security researcher reading the same advertisement notes that it names the exact version of the software the company runs. The same public sentence answers both questions, which is precisely why organisations underestimate what they publish: the person writing the job advertisement is thinking about recruitment, not about disclosing a software inventory.

The aggregation problem

The single most important idea in this block, and the one that makes reconnaissance dangerous despite every individual fact being harmless.

Consider four facts, each of which a company would publish without hesitation:

1. A press release naming the new Head of Finance.
2. A conference talk by an engineer describing the company's architecture.
3. A job advertisement seeking an administrator for a named product at a named version.
4. A support page giving the format of employee email addresses.

Individually, none is sensitive. Combined, they give an attacker a named target, their likely email address, a known-vulnerable software version to look up, and an understanding of the internal architecture sufficient to write a convincing message. That is a spear-phishing campaign assembled entirely from material the company chose to publish.

The lesson for a defender is that footprint reduction cannot proceed fact by fact, asking "is this sensitive?", because the answer is almost always no. It has to ask "what does this enable when combined with everything else we publish?"

A worked example

Karan is authorised to assess his own college's public exposure before an attacker does. He begins passively and touches nothing:

• The college website lists department heads with addresses in the form firstname@college.test. He now knows the email format for everyone in the institution.
• An IT job advertisement from four months ago names the learning-management system and its version. He looks the version up and finds two published vulnerabilities.
• Certificate transparency logs, which record certificates issued for the college's domain, list a host called results-old.college.test that appears nowhere on the website.
• An archived copy of a page removed last year still shows an internal phone directory.

At this point Karan has not sent a single packet to the college. Everything came from third parties. He has the email format, a software version with known flaws, a forgotten host, and a staff directory.

Only now, and only because his authorisation names the college's systems, does he move to active reconnaissance: resolving results-old.college.test against the college's name servers to see whether it still exists, and reading its response headers. That step touches college systems and is lawful only because of the letter in his file.

His report separates the two halves, and the passive half is the more alarming, because it is the part the college can fix by changing what it publishes rather than by patching anything.

What beginners get wrong

• Skipping reconnaissance because it does not feel like hacking. It is the phase with the highest return, and omissions here silently limit everything after.
• Believing "passive" means "safe to do to anyone" without qualification. It does not engage section 43, but privacy law and platform terms are separate questions, and professional scopes limit people-focused collection.
• Thinking active reconnaissance begins at scanning. It begins the moment you touch the target's systems, which can be a single direct DNS query or a header read.
• Assessing published facts one at a time. The risk is in aggregation; individually harmless facts combine into an attack profile.
• Treating footprint reduction as hiding. You are not hiding from a determined attacker; you are declining to hand out free information.
• Forgetting that competitive intelligence uses the same sources. The job advertisement written for recruiters is read by attackers.

Quick revision

• Footprinting builds a profile of a target; OSINT is publicly available information plus the analysis that makes it useful.
• Passive: no interaction with the target's systems, information from third parties, leaves no trace in their logs, does not engage s.43. Active: touches their systems, leaves a trace, needs written authorisation.
• Blurry cases: ordinary browsing (intent and pattern decide), public resolver (passive) against the target's own name server (active), and third-party hosting.
• Competitive intelligence is the same technique for commercial purposes; the same published sentence serves both readers.
• The aggregation problem: individually harmless facts combine into a targeted attack. Assess what you publish as a set, not item by item.
• Do the whole process against your own organisation; what you find is what you can remove.

Test yourself

1. Distinguish passive from active reconnaissance, and state the legal consequence of the distinction.

Passive reconnaissance obtains information from third parties without interacting with the target's systems, so it leaves no trace in their logs and does not engage section 43. Active reconnaissance interacts directly with the target's systems, is recorded by them, and constitutes access that requires written authorisation.

1. Give a case where the same question is passive or active depending on how it is asked.

A DNS lookup: querying a public resolver usually returns a cached answer and never reaches the target, which is passive; querying the target's own authoritative name server reaches their machine and is active.

1. What is the aggregation problem, and why does it defeat a fact-by-fact review of what an organisation publishes?

Individually harmless public facts combine into an actionable attack profile, for example a staff name, an email format, a software version and an architecture description together enabling targeted phishing against a known-vulnerable system. A fact-by-fact review asks "is this sensitive?" and almost always answers no, missing what the set enables.

1. How do OSINT and competitive intelligence relate?

They are substantially the same collection and analysis of public information, differing in purpose: competitive intelligence seeks commercial insight about rivals, security reconnaissance seeks attack-relevant detail. The same published source, such as a job advertisement, commonly serves both.

1. Why is reconnaissance described as the phase with the highest return?

Because it converts a large, unknown target into a small, specific one before any suspicious contact: it reveals which systems exist, which are neglected, what software and versions are in use, and who works there, narrowing what every later phase must attempt.

Professional networking sites. The richest source by a distance. They give names, job titles, tenure, the technologies people list as skills, and often the reporting structure inferred from titles. A new joiner announcing their role is announcing that they do not yet know who normally asks them for things.

Conference talks and publications. An engineer describing their architecture at a meetup is doing something professionally valuable and is also describing the internal systems.

Social media. Personal accounts leak context: a holiday (so the person is away and cannot be consulted), a team photograph (badges, screens, office layout), interests that can be used to build rapport.

Job advertisements. Simultaneously a people source and a technology source; they reveal team structure, seniority and gaps.

Document metadata, covered in a later chapter, which often carries author names and internal user names.

Breach data. Credentials exposed in other organisations' breaches, which matter because of password reuse. A professional tester usually checks only whether an organisation's addresses appear in known breaches, without obtaining or using the credentials, because the credentials are not theirs and handling them raises the issues in the law chapters.

The limits a professional keeps

This is the chapter where the subjects are people, so the boundaries are firmer than elsewhere, and a student should be able to state them.

Only what the scope permits. If the engagement forbids social engineering, then collecting a detailed dossier on named employees serves no authorised purpose. The reconnaissance should go no further than the engagement needs.

Public sources only, and no deception to obtain more. Reading a public profile is passive reconnaissance. Creating a false identity to connect to employees and draw information from them is pretexting, a social-engineering technique, and it needs explicit authorisation because it engages section 66D.

Never their personal accounts. Attempting to access an individual's own accounts is unauthorised access to that individual's systems, and the client cannot authorise it because the client does not own them.

Handle the results as personal data. Names, roles and addresses are personal data. They are stored securely, minimised to what the finding requires, redacted in the report, and destroyed at the end of the engagement, for the reasons in the confidentiality chapter.

Write findings about the organisation, not about individuals. A report should say "the email format is discoverable and a staff list is publicly available, enabling targeted phishing", not "this named employee overshares on social media". The finding is a systemic one and naming individuals invites blame that is both unfair and counterproductive, since the earlier chapter on social engineering will show that a blame culture makes people hide their mistakes.

A worked example, run defensively

Nisha assesses her own organisation's people exposure, within a scope that permits reconnaissance but forbids any contact with staff.

• The website's leadership page gives six names with addresses as firstname.lastname@company.test. Finding: the email format is public.
• A professional networking search returns around eighty employees with titles. Combined with the format, she can construct eighty addresses without touching anything. Finding: a near-complete staff list plus format is available.
• Three engineers list, as skills, the exact technologies and versions the company runs. Finding: the technology stack is inferable from staff profiles.
• A recent press release names a new Chief Financial Officer who started six weeks ago. Finding: a high-value impersonation target who is new and may not know the organisation's norms.
• A conference talk by a staff engineer describes the internal deployment pipeline. Finding: internal architecture is publicly described.

She writes these as five organisational findings with one recommendation set: publish role-based addresses where possible, brief new senior staff on impersonation risk in their first week, review what is said in public talks, and, because none of this can be fully prevented, ensure multi-factor authentication and a verification procedure for payment changes so that a convincing message cannot by itself cause harm. She names no individual.

That last move is the chapter's point: since you cannot stop people being findable, the defences must make finding them insufficient.

What beginners get wrong

• Trying to hide employees. It is neither possible nor desirable; people need public professional identities. Reduce specific leaks (exact versions, internal architecture) and invest in controls that survive a convincing message.
• Thinking withholding addresses protects them. Once the format is known, every address can be constructed. The pattern is the exposure, not the individual address.
• Blurring reading a public profile with contacting the person. The first is passive; the second is social engineering and needs explicit authorisation.
• Collecting more than the engagement requires. People-focused reconnaissance without an authorised purpose is a privacy problem, not thoroughness.
• Naming individuals in findings. Findings are about the organisation's exposure. Naming people invites blame and discourages the reporting culture that limits damage.
• Touching employees' personal accounts. The client cannot authorise access to systems it does not own.

Quick revision

• Attackers seek names and roles (to choose a target), the email format (to write to anyone), reporting relationships (for plausible authority) and context (to be convincing).
• One published address reveals the pattern for the whole organisation; withholding individual addresses does not help. Mail systems and login pages may then confirm which constructed addresses are real.
• Sources: the organisation's own site, professional networks (richest), conference talks, social media, job advertisements, document metadata, and breach data (checked, not used).
• Professional limits: only what the scope requires; public sources only, with no deception (pretexting needs authorisation and engages s.66D); never personal accounts; treat results as personal data; write findings about the organisation, not individuals.
• Because people cannot be hidden, the real defences are multi-factor authentication, verification procedures for sensitive actions, email authentication, and training.

Test yourself

1. Why is a single published email address a significant exposure?

Because it reveals the organisation's address format, which combined with an easily obtained staff list lets an attacker construct a valid address for every employee, including people who have never published one. The pattern, not the individual address, is the exposure.

1. Name four things an attacker seeks from people-focused reconnaissance and what each enables.

Names and roles, to select a target with the access or authority required; the email format, to reach anyone; reporting relationships, so a message can plausibly claim authority over the recipient; and contextual detail such as projects, suppliers or recent events, to make the message convincing.

1. Where is the line between passive people reconnaissance and social engineering?

Reading publicly available profiles and publications is passive and touches no one. Creating a false identity to connect with employees and elicit information is pretexting, a social-engineering technique which requires explicit authorisation in the scope and engages section 66D.

1. Why should findings about people exposure be written about the organisation rather than about named individuals?

Because the exposure is systemic and largely unavoidable for people who need public professional identities, and because naming individuals assigns blame unfairly and discourages the open reporting culture that limits damage when someone is deceived.

1. Given that employees cannot be made unfindable, what defences actually reduce the risk?

Controls that make a convincing message insufficient: multi-factor authentication so a phished password does not grant access, verification through a second known channel for sensitive actions such as changing payment details, email authentication to make forgery harder to deliver, and training so people recognise the techniques.

Certificate transparency logs. These deserve explanation because they are the source students have not met. When a certificate authority issues a TLS certificate, it publishes a record in a public, append-only log, so that mis-issued certificates can be detected. The logs are open to anyone, and every record names the host names the certificate covers. So an organisation that obtains a certificate for staging.company.test has published that host name to the world, whether or not it appears anywhere else. For subdomain discovery this is often the single most effective passive source, and it cannot be opted out of, because the transparency is the point.

Public search services that index internet-facing hosts. Services exist that continuously scan the internet, recording what responds on each address: banners, certificates, technologies. Querying one of them is passive from the target's point of view, because the service did the scanning, not you, and the target saw the service. This is a genuinely useful distinction: an attacker can learn much of what a scan would tell them without ever scanning.

DNS records and address allocations, which are the next two chapters.

Archived copies of pages. Web archives keep copies of pages that have since been changed or removed, so a removed page naming an internal system may still be readable.

What the attacker builds

The output of this phase is a technology profile: a list of products, versions and hosting arrangements, and a list of hosts and address ranges.

An example of the shape:

Each row is individually modest and together they define exactly where an attacker will spend their effort.

The defensive reading

Every source above has a control, and they divide into three kinds.

Say less. Suppress version numbers in headers and error pages; use generic error pages in production; avoid naming exact versions in job advertisements (say "experience with the product" rather than "version 4.2.1"); review what is said in public talks about internal architecture.

Publish deliberately. Some disclosure is unavoidable and fine. The aim is not secrecy but avoiding needless specificity, because obscurity is not a security control and a determined attacker will fingerprint your software anyway. Which leads to the third and most important kind.

Make the knowledge useless. The real defence against "the attacker knows our version" is that the version has no unpatched known flaw. Patch management, which gets its own chapter later, is what turns an accurate technology profile into a dead end. An attacker who knows exactly what you run and finds it fully patched has gained very little.

Two specific controls deserve naming:

• Monitor certificate transparency logs for your own domains. Because you cannot prevent certificate host names being published, watch them instead: it tells you what your own organisation has provisioned, which often surprises the security team, and it detects certificates issued for your names that you did not request.
• Scan your own public repositories for secrets, and rotate anything found. Committed credentials are a recurring and serious exposure. Automated secret scanning in the build pipeline prevents recurrence, and the response to a leaked credential is always revocation, never deletion of the commit, because the history remains.

A worked example

Ravi is assessing his organisation's technology exposure, passively at first.

• Certificate transparency lists eleven host names for the domain. Six are on the website; five are not, including vpn-test.company.test and old-portal.company.test. Finding: five hosts exist that are not publicly linked, two with names suggesting they are unmaintained.
• A job advertisement from eight months ago names the ERP product and its version. He looks the version up: three published vulnerabilities, one rated High. Finding: the software estate is disclosed publicly, and a High-severity flaw may apply.
• A public repository belonging to the organisation contains a configuration example with an internal host name and a database user name. Finding: internal naming is disclosed.
• A public host-indexing service shows the response banners for the company's address range, including a web server version on a host nobody had mentioned. Finding: an unlisted internet-facing host exists.

None of this touched company systems. His recommendations follow the three kinds above: retire or patch the five unlinked hosts (the urgent one), stop naming versions in advertisements, add secret and configuration scanning to the repository pipeline, monitor certificate transparency for the domain, and confirm the ERP is patched, since that is what actually neutralises the disclosure.

What beginners get wrong

• Thinking header suppression is the fix. It slows an attacker slightly; fingerprinting usually identifies the software anyway. Patching is the control that matters, and the obscurity is a minor supplement.
• Ignoring client-side libraries. A JavaScript library named at a version in the page source is a component with its own CVEs.
• Missing certificate transparency. It is public, unavoidable, and often the best subdomain source. Organisations are frequently unaware they are publishing host names this way.
• Treating an internet-indexing service's data as an active scan. Querying it is passive from the target's viewpoint, because the service did the scanning. That is exactly why attackers use it first.
• Deleting a committed secret instead of revoking it. The commit history retains it. The only correct response is to rotate the credential.
• Assuming old information is stale. Organisations upgrade slowly, so a year-old advertisement is often still accurate.

Quick revision

• The aim is a technology profile: products, versions, hosting, plus hosts and address ranges. A product and version becomes a CVE list.
• Passive sources: job advertisements, staff profiles and talks, public code repositories (including committed secrets), certificate transparency logs (excellent for subdomains, unavoidable), internet-wide indexing services (passive from the target's view), web archives, DNS and registry data.
• Active sources: response headers, error pages, direct page requests.
• Controls in three kinds: say less (suppress versions, generic errors, vaguer advertisements), publish deliberately (obscurity is not security), and make the knowledge useless by patching, which is the real defence.
• Specifically: monitor certificate transparency for your own domains, and scan repositories for secrets, rotating anything found rather than deleting the commit.

Test yourself

1. Why is a product version number the most valuable single item in technology reconnaissance?

Because CVE records identify flaws in specific products at specific versions, so a product and version can be looked up directly against vulnerability databases to produce a list of known flaws, their severity and often how they work.

1. What are certificate transparency logs, and why are they so useful for subdomain discovery?

They are public, append-only logs in which certificate authorities record every certificate issued, so that mis-issuance can be detected. Each record names the host names the certificate covers, so obtaining a certificate for an internal-sounding host publishes that name; the logs cannot be opted out of, since publication is the mechanism's purpose.

1. Why is querying an internet-wide host-indexing service considered passive?

Because the service performed the scanning and the target's logs record the service, not the researcher. The researcher reads a third party's records, so the target's systems are never touched.

1. Is suppressing version banners an adequate defence, and what is?

It is not adequate, because software can usually be fingerprinted from its behaviour regardless. The effective defence is patch management, so that an accurate technology profile leads to no unpatched known vulnerability; banner suppression is a minor supplementary measure.

1. A credential is found committed in a public repository. What is the correct response and why is deleting the commit insufficient?

Revoke and rotate the credential immediately. Deleting the commit is insufficient because the repository history, and any clone or cached copy taken before deletion, still contains the secret, so only invalidating the credential removes the exposure.

All of this is passive by the definition of the earlier chapter: the searcher queries the search engine, not the target, so the target's logs record nothing. That is exactly why it is done first.

Document metadata

The second half of the chapter is the same problem arriving by a different route: information published inside files rather than on pages.

When software creates a document it records descriptive information in the file. Depending on the format and the tool, that can include:

• the author's name and often their user name on the machine, which reveals the organisation's naming convention for accounts;
• the organisation name registered in the software;
• creation and modification times, and the identities of everyone who edited it;
• the software and version used, which is a technology-profile item;
• file paths, which disclose internal server names and folder structures, for example a path showing a departmental file server's name;
• for images, the camera or device, and sometimes location coordinates;
• in some formats, content that was deleted but not removed, such as text hidden behind a redaction drawn as a shape, or earlier revisions retained in the file.

That last one is the most serious and the least understood. A redaction applied as a black rectangle over text in some document formats hides the text visually while leaving it in the file, so it can be recovered by anyone. Documents have been published in this state by organisations that believed they had removed the information.

An attacker who collects an organisation's published documents and extracts the metadata gains: a list of user names, the account naming convention, internal server and path names, and the software versions in use. Tools to do this in bulk are well known, and the whole operation is passive.

The defences

The two halves share a shape: the information was published by accident, so the control is process rather than technology alone.

For search-engine exposure:

• The real fix is that sensitive material must not be reachable. If a document requires authorisation, it must be behind authentication, not merely unlinked. A crawler directive asking search engines not to index a page is a request to well-behaved crawlers, not an access control, and it does not stop anyone who has the URL.
• Disable directory listing, which is a web-server setting and one of the commonest real findings.
• Keep non-public files out of the web root entirely, including backups, exports and configuration.
• Use generic error pages in production.
• Search for your own organisation regularly, using the same operators an attacker would. This is the single most useful action in the chapter, because it finds what is already exposed.
• Request removal of content that is indexed and should not be, and, because the index reflects the site, remove or protect the underlying content first, or it will simply be re-indexed.

A caution worth stating plainly: a crawler-exclusion file that lists the paths you do not want indexed is itself readable, so a file listing your sensitive directories is a map for an attacker. Excluding a path is not protecting it.

For document metadata:

• Strip metadata before publishing. Most office and PDF tools have a document-inspection feature that removes personal and hidden information; for a publishing workflow this should be a required step rather than an optional one.
• Redact properly. Remove the underlying text, do not cover it. Use the software's redaction feature or flatten the document, and verify by searching the published file for the text that should be gone.
• Prefer exported formats for publication, since converting often discards revision history and comments.
• Check images for embedded location and device data.
• Make it a gate. Since this is an accident, the control must be part of the process that publishes, not a reminder to be careful.

A worked example

Anjali audits her college's published material, entirely passively.

• Restricting a search to the college domain and to spreadsheet files returns a document listing student names with enrolment numbers, uploaded two years ago to a folder that was never linked. Finding: personal data is publicly retrievable; it is indexed, so the URL is effectively public.
• A query for the characteristic title of a directory listing, restricted to the domain, returns an open /uploads/ folder containing scanned forms. Finding: directory listing is enabled.
• Downloading three published PDFs and inspecting their metadata gives four staff user names in the form surname_initial, the internal path \\\\fileserver01\\admin\\, and the version of the software used. Finding: account naming convention, an internal server name and a software version are disclosed.
• One PDF has a section covered by a black rectangle; selecting the text underneath recovers it. Finding: an improper redaction has published the information it was meant to hide.

Her recommendations: remove the student spreadsheet and treat it as a personal-data incident (not merely a hygiene issue); disable directory listing and move uploads out of the web root; require metadata stripping before publication; re-issue the improperly redacted document and withdraw the original; and add a quarterly self-search using the same queries.

Note that the first and last findings need different responses. Removing the file stops future retrieval but does not undo the disclosure, since it has been indexed and may be cached or archived. Confidentiality, once lost, cannot be restored, which is the point made in the CIA chapter now arriving in a concrete form.

What beginners get wrong

• Believing an unlinked page is private. It can be indexed from other sources, and a URL known to anyone is effectively public. Authentication is the control.
• Using a crawler-exclusion file as protection. It is a request to polite crawlers, it does not restrict access, and the file itself advertises the paths you consider sensitive.
• Thinking removal undoes exposure. Caches and archives persist, and anything already retrieved is gone. Removal stops the bleeding; it does not heal.
• Redacting by drawing over text. In many formats the text remains in the file. Redaction must remove the content, and the result should be verified.
• Treating metadata as trivia. It supplies user names, the account naming convention, internal server paths and software versions, all of which feed later phases.
• Not searching for yourself. The technique is available to defenders at no cost, and it is the fastest way to find what is already exposed.

Quick revision

• Search engines index content that was never linked, so "nobody knows the URL" is not a control; indexes and archives also persist after removal.
• Advanced operators restrict by site, file type, words in the URL or title, and words in the body; combined, they surface directory listings, stray documents, configuration and backup files, unlinked administrative pages and error messages. Querying a search engine is passive.
• Document metadata can disclose author and user names, the organisation, edit history, software versions, internal file paths, image location data, and text that was hidden rather than removed (improper redaction).
• Defences: authenticate what must be protected; disable directory listing; keep non-public files out of the web root; generic error pages; search for yourself regularly; strip metadata and redact properly as a required publishing step, not a reminder.
• A crawler-exclusion file is readable and lists your sensitive paths; excluding is not protecting.

Test yourself

1. Why can a page an organisation never linked still appear in a search engine, and what follows for security?

Because crawlers find URLs from other sites, public documents, sitemaps and certificate data, so a page can be indexed without being linked. It follows that obscurity of the address is not a control; anything that must be restricted needs authentication.

1. What does a crawler-exclusion file actually do, and why can it make things worse?

It asks well-behaved crawlers not to index the listed paths; it does not prevent access by anyone who has or guesses the URL. It can make things worse because the file is itself publicly readable, so it advertises exactly which paths the organisation considers sensitive.

1. Name four kinds of information document metadata can disclose.

The author's name and machine user name (revealing the account naming convention), the organisation and edit history, the software and version used, and internal file paths and server names; images may also carry device and location data.

1. Why is drawing a black rectangle over text an unsafe way to redact a document?

Because in many formats the underlying text remains in the file and is merely hidden visually, so it can be selected, copied or extracted by anyone who receives the document. Proper redaction removes the content, and the published file should be verified afterwards.

1. An indexed spreadsheet of personal data is discovered and removed. Why is the problem not fully solved?

Because the content has already been indexed and may persist in caches and web archives, and anyone who retrieved it retains it. Removal prevents further retrieval from the source but cannot undo the disclosure, which is why confidentiality loss is treated as irreversible and, for personal data, as an incident.

5. Search for stray content. Apply the search-engine techniques to each domain: indexed documents, directory listings, unlinked administrative pages, error messages.

6. Inspect published documents. Sample the documents the organisation publishes and extract their metadata. Check for improper redaction.

7. Review people exposure. The email format, the staff list, technologies named in profiles and talks, and senior staff who are impersonation targets.

8. Check code and secrets. Search public repositories for the organisation's domains and internal names; scan for committed credentials.

9. Check registration data. WHOIS and registry records for exposed personal contact details and, importantly, for domain expiry dates.

10. Write it up as findings with decisions, which is the next section.

The three decisions

For every item found, exactly one of three decisions, and stating them explicitly is what makes the audit a piece of work rather than a list of worries.

Remove it. The item serves no purpose and can go: the forgotten test host is decommissioned, the stray spreadsheet is deleted, the directory listing is disabled, the improperly redacted document is withdrawn and reissued. This is the best outcome and should be used wherever possible, because it eliminates rather than manages.

Restrict it. The item is needed but not by everyone: the administrative interface is moved behind authentication or restricted to an internal network, the document is moved behind a login, the verbose error page is replaced with a generic one for the public and kept in the server-side log.

Accept and defend. The item cannot reasonably be removed, and here the audit's honesty matters. You cannot make your senior staff unfindable, or stop certificates for your host names being published, or prevent the software you run being fingerprinted. For each accepted exposure, name the control that makes it insufficient:

The right-hand column is the whole argument of the module in miniature: since reconnaissance cannot be prevented, security must not depend on it failing. An organisation whose defence is that an attacker will not find out what it runs has no defence at all.

What "obscurity is not security" does and does not mean

The slogan is often stated too strongly, and a good answer distinguishes.

It is true that obscurity must not be the control you rely on. A system protected only because its address is unpublished is protected by a fact you do not control and cannot verify, and it fails completely the moment the address leaks, which the earlier chapters showed happens routinely through certificates, archives and indexes.

It is also true that needless disclosure is a gift. Publishing an exact version number, an internal architecture, or a complete staff directory costs the organisation nothing to avoid and saves an attacker real effort. Reducing it is worth doing.

The reconciliation: obscurity is a valid supplementary measure and an invalid primary control. Reduce your footprint because it raises the attacker's cost, and never let anything depend on the reduction having worked.

A worked example, and the journal practical

This is the practical to record in the journal, and it can be done entirely lawfully against your own institution or a system you own.

Meera audits her college. Working only from third-party sources:

• Hosts. Certificate transparency gives fourteen host names; the college's IT department recognises nine. Five unknown hosts, of which two respond and three do not. One is a results portal from an old academic year still serving pages.
• Technology. The old portal discloses a web-server version with two published High-severity flaws. The main site suppresses its version.
• Stray content. A restricted search finds an indexed spreadsheet of student contact details and an open uploads directory.
• Documents. Metadata from four published PDFs yields the staff account naming convention and an internal file-server name.
• People. The email format is public; around eighty staff are listed on professional networks.
• Registration. One secondary domain expires in five weeks with no auto-renewal.

Her findings, with decisions:

The most valuable line is the first, and it was not a vulnerability in the ordinary sense. It was an asset nobody knew about, found by a free, lawful, passive technique. That is what this chapter exists to teach.

What beginners get wrong

• Treating the audit as tidying. Its main product is an inventory correction, and unknown assets are the most dangerous ones.
• Trying to remove everything. Much exposure is necessary. The discipline is to decide remove, restrict, or accept-and-defend, and to name the control for every acceptance.
• Relying on obscurity. It is a supplement, never a primary control. Anything that depends on an address staying secret is undefended.
• Auditing once. Exposure regrows continuously as people publish, provision and leave. It is a recurring exercise, and certificate transparency monitoring makes part of it continuous.
• Skipping the reconciliation step. Enumerating hosts is only half the work; comparing them with the asset register is where the finding is.
• Forgetting domain expiry. A lapsed domain can be re-registered by anyone and used to impersonate the organisation.

Quick revision

• Run reconnaissance against yourself: free, lawful, passive, and it measures your real exposure rather than guessing at it.
• Procedure: list domains, enumerate hosts (certificate transparency, DNS, indexing services, archives), reconcile against the asset inventory, profile technology, search for stray content, inspect document metadata, review people exposure, check repositories for secrets, check registration and expiry, write findings with decisions.
• The main product is often an inventory correction: unknown assets are unpatched, unmonitored and the most dangerous the organisation owns.
• Three decisions per item: remove, restrict, or accept and defend, and every acceptance must name the control that makes the exposure insufficient.
• Obscurity is a valid supplementary measure and an invalid primary control: reduce the footprint to raise the attacker's cost, but never depend on it.
• Repeat it; exposure regrows.

Test yourself

1. What is the most valuable finding a footprint audit typically produces, and why?

Assets the organisation did not know it owned, such as forgotten subdomains, test systems or cloud services. They are the most dangerous assets it has, because nothing unknown is patched, monitored or backed up, and no one will notice its compromise.

1. State the three decisions available for each item found, and the requirement attached to the third.

Remove it, restrict it, or accept it and defend against its use. Every acceptance must name the specific control that makes the exposure insufficient, such as multi-factor authentication against a discoverable email format, or patch management against a fingerprintable version.

1. In what sense is "obscurity is not security" true, and in what sense is reducing your footprint still worthwhile?

It is true that obscurity must never be the primary control, since it depends on a fact you neither control nor can verify and fails entirely once the information leaks. Reducing the footprint remains worthwhile because needless specifics cost nothing to withhold and save an attacker real effort, so obscurity is a legitimate supplementary measure.

1. Why must the host-enumeration step be followed by a reconciliation step?

Because the security value lies in the difference between what is discoverable and what the organisation's asset register records. Enumeration alone produces a list; comparing it with the inventory identifies the unknown, unmanaged assets that constitute the real finding.

1. Why is a footprint audit a recurring exercise rather than a one-off project?

Because exposure regrows continuously as staff publish material and talks, departments provision new hosts and cloud services, certificates are issued, and people join and leave. Parts of it, such as monitoring certificate transparency for your own domains, can be made continuous.

Root servers know one thing: which servers are authoritative for each top-level domain. They are a small, globally distributed set of addresses that every resolver knows in advance, and they answer with referrals rather than final answers.

TLD servers know which name servers are authoritative for each domain registered under them.

Authoritative name servers hold the actual records for a zone. They are the source of truth, and an organisation either runs them or, more often, pays a provider to.

A resolution, step by step

Your browser needs the address of results.college.test and nothing is cached anywhere.

1. The stub resolver asks the configured recursive resolver: "what is the address of results.college.test?"
2. The resolver has nothing cached, so it asks a root server. The root does not know, but it knows who handles .test, and returns a referral naming those servers.
3. The resolver asks a .test TLD server. It does not know the address either, but it knows college.test is delegated to particular name servers, and returns that referral.
4. The resolver asks one of college.test's authoritative name servers. This one knows, and returns the answer: the A record with the address.
5. The resolver caches the answer for the record's time to live, and returns it to the stub resolver, which gives it to the browser.

Two names for the two behaviours: the resolver performed a recursive query on your behalf (it took responsibility for finding the final answer), while its own queries to the root and TLD servers were iterative (each returned a referral rather than chasing it further). Authoritative servers normally refuse to act recursively for strangers, which matters later: a server that will, an open resolver, can be abused for amplification in denial-of-service attacks.

Caching and the time to live

Every record carries a time to live (TTL), a number of seconds for which a resolver may keep the answer. Caching is what makes the DNS fast and keeps the root servers from collapsing under the world's traffic.

For a security reader, three consequences:

A cached wrong answer persists. If an attacker succeeds in getting a resolver to cache a false record, that falsehood is served to every user of that resolver until the TTL expires. This is cache poisoning, and the damage is multiplied by the number of people using that resolver and by the TTL.

Change takes time to propagate. If you must move a service or, worse, respond to an incident by changing a record, users continue to receive the old answer until caches expire. Administrators therefore lower the TTL in advance of a planned change. In an incident, a long TTL is an obstacle.

Querying a cache is not querying the target. This is the passive/active line from the reconnaissance chapter, now explained: asking a public recursive resolver usually returns a cached answer, so the target's authoritative servers never see you. Asking the authoritative server directly does reach the target's machine, and is active.

The query itself, and where it is weak

A DNS query is small, and historically it is sent over UDP, a connectionless protocol with no handshake. That choice is the source of two weaknesses worth naming now because later chapters rely on them.

There is no authentication. A client asking a question accepts the first plausible answer that arrives. The original protocol's only checks that an answer belongs to a question are that it comes from the expected address and port and carries a matching 16-bit transaction identifier. An attacker who can guess or observe those can forge a reply, which is the basis of DNS spoofing and cache poisoning.

The source address can be forged. Because UDP has no handshake, an attacker can send a query claiming to come from a victim's address, and the response goes to the victim. Since responses can be much larger than queries, this gives amplification, which the denial-of-service chapter uses.

Both are addressed, partially, by later additions: DNSSEC signs records cryptographically so a forged answer can be detected, and encrypted DNS (over TLS or HTTPS) protects the query in transit from a local attacker. Neither is universal, and the reasons are discussed in the hardening chapter.

A worked example, read as reconnaissance

Karan looks up his own college's records using a public resolver, which is passive.

• college.test returns an A record pointing to an address. Querying the registry for that address shows it belongs to a hosting provider, so the site is hosted, not self-run.
• The NS records name two servers at a DNS provider, so the DNS is outsourced, and those servers are not the college's own to secure.
• The MX records point to a well-known cloud mail provider, so staff mail is there, which tells an attacker exactly which provider's login page a phishing message should imitate.
• A TXT record contains an SPF policy listing four systems permitted to send mail as the college, which is a partial inventory of its sending infrastructure.
• The TTL on the main A record is 300 seconds, which is short and suggests the administrators expect to change it.

Every one of those was answered from a cache and none reached the college's servers. Karan has learned the hosting arrangement, the DNS provider, the mail provider and part of the sending infrastructure without touching anything, which is why the reconnaissance chapter called DNS one of the richest passive sources.

What beginners get wrong

• Thinking the DNS only maps names to addresses. It carries mail routing, policy records, service discovery and verification tokens, and those are often more revealing than the addresses.
• Confusing recursive with iterative. The resolver answers your query recursively; the servers it consults answer iteratively with referrals.
• Ignoring the TTL. It governs how long a poisoned answer persists and how quickly a legitimate change or an incident response takes effect.
• Assuming any DNS lookup is passive. Querying a public resolver usually is; querying the target's authoritative server directly is not, because it reaches their machine.
• Forgetting that the protocol has no authentication. This is not a bug to be patched but a design property, and it is why DNSSEC exists and why several later attacks are possible at all.
• Believing the root servers know everything. They know only which servers handle each top-level domain, and answer with referrals.

Quick revision

• Names are read right to left: root, TLD, domain, subdomain. The namespace is divided into zones, and delegation between them is what lets the system scale.
• Parts: stub resolver (in the client), recursive resolver (does the work, caches), root servers (refer to TLDs), TLD servers (refer to domains), authoritative name servers (hold the truth).
• Resolution: stub asks resolver; resolver asks root, then TLD, then authoritative, following referrals; answer cached and returned. The resolver's own queries are iterative; the query it answers for you is recursive.
• TTL controls caching: a poisoned answer persists for its duration, changes propagate only as caches expire, and short TTLs are set before planned changes.
• Querying a cache is passive; querying the authoritative server is active.
• The protocol has no authentication and uses UDP, giving rise to spoofing and cache poisoning, and to source-address forgery and amplification. DNSSEC and encrypted DNS address parts of this.

Test yourself

1. Describe the resolution of a name from a cold cache, naming each server consulted.

The stub resolver asks the recursive resolver, which asks a root server and receives a referral to the top-level domain's servers, asks one of those and receives a referral to the domain's authoritative name servers, then asks an authoritative server, which returns the record. The resolver caches the answer for its TTL and returns it.

1. What is the difference between a recursive and an iterative query?

In a recursive query the server asked takes responsibility for obtaining the final answer, which is what a resolver does for a client. In an iterative query the server returns the best it has, usually a referral to another server, which is how root and TLD servers respond.

1. Give two security consequences of DNS caching.

A falsified record that a resolver accepts is served to all of that resolver's users until the TTL expires, multiplying the harm of cache poisoning; and legitimate changes, including emergency ones during an incident, do not take effect for clients until cached copies expire, which is why administrators lower the TTL before planned changes.

1. Why is querying a public resolver passive reconnaissance while querying the authoritative server is active?

Because the public resolver usually answers from its own cache, so the target's servers never receive a query and their logs record nothing. Querying the authoritative name server sends a packet to a machine the target operates, which is an interaction with their system and is recorded.

1. Which design property of the original DNS protocol underlies spoofing and amplification attacks?

The absence of authentication, combined with the use of connectionless UDP. A client accepts the first plausible reply matching the expected address, port and transaction identifier, which allows forged answers; and because there is no handshake, a query's source address can be forged so that a larger response is directed at a victim.

• Self-hosted means the name servers are the organisation's own machines, which are therefore targets, and must be patched and monitored like any other server.
• Outsourced means the security of the organisation's entire naming depends on an account at a provider. That account is a high-value target, because whoever controls it can repoint every name the organisation owns, and it should be protected with multi-factor authentication and registrar locking.

A mismatch between the NS records at the parent and those in the zone is a misconfiguration worth reporting; it causes intermittent failures and suggests the zone is not well maintained.

CNAME: the alias that points elsewhere

What it is for. A CNAME makes one name an alias for another. Asking for the alias returns the canonical name, which is then resolved.

What it reveals. That a service is really run somewhere else. shop.company.test as a CNAME to a hosting platform, status.company.test to a status-page provider, mail.company.test to a mail provider: each one names a third party the organisation depends on. For an attacker that is a list of suppliers to consider attacking instead, and a list of brands to impersonate.

It also introduces a specific and well-known risk. If a CNAME points to a service the organisation no longer uses, and that service allows anyone to claim the name, an attacker can register it and take control of content served at the organisation's own host name. This is called a dangling CNAME or subdomain takeover, and it is a common finding precisely because decommissioning a service and removing its DNS record are two separate tasks and the second is often forgotten. The defence is straightforward: remove the DNS record when you stop using the service, and audit for CNAMEs pointing at nothing.

TXT: the quiet prize

What it is for. A TXT record holds arbitrary text. Because it was the only flexible record available, it became the place where everything else is put.

What it reveals, and this is the richest single record type:

SPF (Sender Policy Framework). A TXT record listing every server permitted to send mail as the domain. Read as reconnaissance, it is a published list of the organisation's sending infrastructure: its mail provider, its marketing platform, its ticketing system, its payroll service, anything that sends mail on its behalf. An attacker learns the organisation's suppliers from one record. It frequently also reveals systems nobody remembers, a marketing tool from a campaign three years ago still authorised to send as the domain, which is both an intelligence gift and a genuine security weakness.

DMARC, published at a conventional subdomain as a TXT record, states what a receiver should do with mail that fails authentication, and where to send reports. Read as reconnaissance, its policy setting tells an attacker whether forged mail from this domain will be rejected, quarantined or merely monitored, which is to say whether a domain-spoofing phishing attempt is likely to be delivered. A policy of "none" is an invitation.

Domain verification tokens. Cloud services routinely ask an organisation to publish a TXT record to prove control of the domain. The tokens are recognisable, so the set of them is a list of the cloud services the organisation has signed up to, often including services the security team does not know about.

Other policy records. DKIM public keys (at their own selector subdomains) and various service-specific records.

The defensive reading: you cannot hide these, because their purpose requires them to be readable by strangers. What you can do is keep them accurate (remove sending systems you no longer use), set a strict DMARC policy, and recognise that the verification tokens are an inventory of your cloud estate that an auditor should reconcile.

SOA, PTR and SRV

SOA (Start of Authority) appears once per zone and holds administrative parameters: the primary name server, an administrative contact address, a serial number the secondaries use to detect changes, and timing values. It reveals an administrative email address, which is a person to target, and the serial number, which by convention often encodes a date, telling an attacker when the zone was last changed.

PTR maps an address back to a name, the reverse of an A record, and lives in a special reverse zone controlled by whoever holds the address range. Reverse lookups across an organisation's address range often produce a list of host names, sometimes descriptive ones (backup01, test-db), which is why reverse-DNS sweeps are a standard enumeration step.

SRV records locate a service by protocol and name, giving host and port. Where they are used, they advertise which services exist and on what ports, which is unusually helpful to an attacker.

A worked example: reading a zone

Sana examines her own organisation's records through a public resolver.

Her findings are almost all configuration hygiene, and two are serious: the DMARC policy of none, which leaves the domain spoofable, and the stale SPF entry, which authorises a system nobody controls any more. Neither required touching a single one of the organisation's servers.

What beginners get wrong

• Treating TXT as unimportant because it is "just text". It carries SPF, DMARC, DKIM and verification tokens, and is the most revealing record type.
• Forgetting AAAA. IPv6 is frequently unfiltered where IPv4 is carefully controlled. Enumerate both.
• Ignoring dangling CNAMEs. A CNAME to a service you no longer use can allow an attacker to claim the name and serve content from your host name.
• Reading NS as trivia. It identifies either servers to attack or a provider account whose compromise repoints everything the organisation owns.
• Overlooking what MX gives a phisher. Not the address, but the identity of the mail provider to imitate.
• Leaving stale SPF entries. They publish your suppliers and authorise systems you no longer control to send as you.

Quick revision

• A / AAAA: the host's address; reveals the hosting arrangement and neighbouring estate. Check IPv6 filtering separately.
• MX: mail servers with preferences; reveals the mail provider to imitate and any filtering service.
• NS: authoritative name servers; reveals self-hosted (targets) or outsourced (a provider account that must have multi-factor authentication and registrar locking).
• CNAME: an alias; reveals third-party dependencies, and a dangling CNAME enables subdomain takeover.
• TXT: the richest. SPF publishes the sending infrastructure (and stale entries); DMARC reveals whether forged mail is rejected; verification tokens list the cloud services in use.
• SOA: administrative contact and a serial number often encoding a date. PTR: reverse lookups yield host names. SRV: advertises services and ports.

Test yourself

1. What do A, MX, NS, CNAME and TXT each map, and give one thing each reveals to an attacker.

A maps a name to an IPv4 address, revealing the hosting arrangement; MX names the mail servers, revealing the mail provider to imitate in phishing; NS names the authoritative name servers, revealing whether DNS is self-hosted or outsourced and to whom; CNAME aliases one name to another, revealing third-party dependencies; TXT holds arbitrary text and reveals sending infrastructure through SPF, spoofing resistance through DMARC, and cloud services through verification tokens.

1. Why is the TXT record the most revealing type?

Because it carries SPF, which lists every system authorised to send mail as the domain and therefore names the organisation's suppliers; DMARC, whose policy tells an attacker whether forged mail will be delivered; and cloud-service verification tokens, which amount to an inventory of the services the organisation has signed up to.

1. What is a dangling CNAME and why is it dangerous?

A CNAME that still points at a third-party service the organisation no longer uses. If that service lets anyone claim the unused name, an attacker can register it and serve their own content from the organisation's host name, which is a subdomain takeover. It arises because decommissioning a service and deleting its DNS record are separate tasks.

1. Why must AAAA records be checked separately during an assessment?

Because IPv6 filtering is commonly overlooked. An organisation may firewall its IPv4 addresses carefully while the same service is reachable over IPv6 with no equivalent controls, so enumerating only A records understates the exposure.

1. What does a DMARC policy of "none" tell an attacker, and what should a defender do?

That mail forged to appear as coming from the domain will still be delivered rather than quarantined or rejected, so domain-spoofing phishing is likely to reach recipients. The defender should move the policy toward quarantine and then reject, once SPF and DKIM alignment has been verified using the reports.

Public code repositories and documents. Configuration files, scripts and published documents frequently name internal hosts.

Passive DNS. Services that record DNS answers observed across the internet over time and let you query the history of a domain. This can reveal names that existed in the past and addresses a name previously pointed to, which is useful for finding infrastructure that has moved but not been decommissioned.

The organisation's own records. SPF entries name sending systems; MX and NS name providers; and the SOA gives an administrative contact.

Active enumeration: asking the target

These touch the target's name servers and therefore require authorisation.

Zone transfer. If misconfigured to permit it, a single request returns the entire zone. It is the next chapter's subject.

Brute-force (dictionary) enumeration. Ask the target's name servers about a long list of likely names, www, mail, vpn, test, dev, staging, api, admin, backup, and record which resolve. It is effective, it finds names no passive source knows, and it is noisy: the target's DNS servers receive a large number of queries for names that do not exist, which is a distinctive and detectable pattern.

Permutation and alteration. Having found api.company.test, try api-dev, api2, api-staging, and so on. Organisations name things predictably, and this exploits that.

Reverse lookups across the address range. Once the organisation's allocated range is known from registry data, ask for the PTR record of each address. Where reverse DNS is populated, this yields host names directly, often descriptive ones.

A note on wildcards. Some zones answer every possible name with the same address, which makes naive brute-force enumeration report thousands of non-existent hosts. Recognising a wildcard (by querying a name that certainly does not exist and seeing whether it resolves) is a necessary step before trusting brute-force results.

From names to a map

Names alone are a list. Infrastructure mapping turns them into a model, and the steps are mechanical:

1. Resolve each name to its addresses, both A and AAAA.
2. Group by address. Several names on one address usually means virtual hosting, and one compromise reaches all of them.
3. Look up each address at the regional registry (the next chapter) to find who owns it and what the allocated range is. Addresses inside the organisation's own range are self-hosted; addresses in a provider's range are not, and the client cannot authorise testing of the provider.
4. Sweep the organisation's own ranges for further hosts that have no name at all, which exist more often than people expect.
5. Classify by apparent purpose from the names: production, staging, development, administrative, infrastructure.
6. Reconcile against the asset inventory, which is where the finding is.

That last step is the point of the whole exercise. A list of forty hosts is data. "Forty hosts exist and the organisation's register lists thirty-one, and of the nine unaccounted for, two are serving pages on outdated software" is a finding, and it is the one that gets acted on.

A worked example

Rahul audits his employer's estate, beginning passively.

• Certificate transparency for the domain returns twenty-three distinct host names.
• Passive DNS adds four more that no longer resolve but did within the last year.
• A scanning service's index confirms which of the twenty-three currently respond, and on which ports, without Rahul sending anything to the company.
• The SPF record names two sending systems not in the host list, one of them a marketing platform.

Now, and only because the engagement authorises it, he moves to active work:

• Brute-force enumeration against the company's name servers adds six names the passive sources missed, including jenkins and vpn-old. He first confirms there is no wildcard.
• Reverse lookups across the company's allocated range reveal four hosts with names but no forward record anybody had listed.

He resolves everything, groups by address, and reconciles:

The report's headline is not "we found thirty-three hosts". It is "nine internet-facing systems are outside the asset register, two of them serious", and the first recommendation is not a technical control but an ownership process: every host must have a named owner and appear on the register, or be decommissioned.

The defensive answer

Since names cannot be hidden, the defence is ownership and lifecycle rather than secrecy.

• Maintain an authoritative inventory of every host, with an owner, and reconcile it against certificate transparency and DNS regularly. The audit makes itself continuous if you monitor the logs.
• Decommission properly. Turning a server off is not decommissioning; the DNS record must be removed too, or you have created a dangling record.
• Do not put real data in non-production environments. If staging must have realistic data, it must be anonymised, and staging must be protected as production is.
• Restrict non-production environments to internal networks or authenticated access. A staging system does not need to be reachable by the internet.
• Monitor your name servers for the pattern of brute-force enumeration: a high rate of queries for names that do not exist.
• Name things blandly. This is the one place obscurity is cheap: svc-14 tells an attacker less than jenkins-prod. It is a supplementary measure and no substitute for the inventory.

What beginners get wrong

• Thinking the goal is a long list. The goal is the difference between the list and the inventory. Length without reconciliation is not a finding.
• Starting with brute force. Passive sources are free, lawful, silent, and frequently more complete. Exhaust them first.
• Forgetting the wildcard check. A wildcard makes every guessed name resolve, and an unwary enumeration reports thousands of phantom hosts.
• Ignoring names that no longer resolve. Passive DNS history points at infrastructure that may still exist without a name.
• Assuming a discovered host is in scope. It is not, until the scope says so. This is the discovery rule from the authorisation chapter, and it is where enumeration most often goes wrong professionally.
• Treating staging as unimportant. It often holds production data and is the least defended thing the organisation runs.

Quick revision

• The objective is the neglected host (test, staging, old, backup, dev): older software, unmonitored, often real data, inside the network, unowned.
• Passive: certificate transparency (best single source, cannot be opted out of), search engines and archives, internet-wide scanning services, public repositories and documents, passive DNS history, and the organisation's own SPF, MX and NS records.
• Active (needs authorisation): zone transfer, brute-force and permutation against the target's name servers (noisy and detectable), reverse lookups across the address range. Check for a wildcard first.
• Mapping: resolve names, group by address, look up registry ownership and ranges, sweep the ranges, classify by purpose, and reconcile against the asset inventory, which is where the finding lives.
• Defence is ownership and lifecycle: an authoritative inventory with named owners, proper decommissioning including DNS, no real data in staging, non-production kept off the internet, monitoring for enumeration, and bland naming as a supplement.

Test yourself

1. Why is a forgotten subdomain more valuable to an attacker than the main website?

Because the main site is defended, monitored and owned, whereas a forgotten host runs older unpatched software, is unmonitored so intrusion raises no alert, frequently holds copies of real data, sits inside the network, and has no owner to notice or respond.

1. Name three passive sources of host names and say why passive methods are preferred first.

Certificate transparency logs, passive DNS history, and internet-wide scanning services (also search engines, archives, public repositories and the organisation's own SPF records). They are preferred because they are free, lawful about any organisation, silent so the target sees nothing, and often more complete than guessing.

1. What must be checked before trusting brute-force subdomain results, and why?

Whether the zone uses a wildcard, by querying a name that certainly does not exist. If a wildcard answers every name, brute-force enumeration will report large numbers of hosts that do not exist.

1. What turns a list of discovered hosts into a security finding?

Reconciliation against the organisation's asset inventory. The finding is the set of internet-facing systems that are discoverable but unregistered and therefore unowned, unpatched and unmonitored, not the raw count of hosts.

1. Why is switching off a server insufficient as decommissioning?

Because the DNS record remains. That leaves a dangling record which may later resolve to an address or a third-party service that somebody else can claim, allowing an attacker to serve content from the organisation's own host name.

The lesson is the general one about configuration: a setting that is wrong but harmless-looking will not be found by operations, only by an assessment.

The fix, and the rest of DNS hardening

Restrict zone transfers to the known secondary servers by address, and where the software supports it authenticate them with a shared key (TSIG), which ties the permission to a cryptographic secret rather than to an address that can be spoofed. This is the single highest-value line in the chapter and it takes minutes.

The rest of the hardening list, which closes the DNS block:

Separate the roles. An authoritative server answers for your zones to the world. A recursive resolver answers queries for your users. They should not be the same machine, and the recursive resolver must not be reachable from the internet. A resolver that answers strangers is an open resolver, and it will be conscripted into amplification attacks against other people, as the denial-of-service chapter explains.

Protect the registrar account. This is the control people forget, and it outranks almost everything else on this list. Whoever controls the registrar account can repoint every name the organisation owns: the website, the mail, everything. Protect it with multi-factor authentication, restrict who can access it, and enable registrar lock, which prevents transfers of the domain to another registrar without a deliberate unlock step. A domain hijack through a registrar account is far more damaging than most compromises, because it redirects the organisation's identity rather than breaching one system.

Watch domain expiry. Enable auto-renewal and monitor expiry dates for every domain, including ones nobody uses. A lapsed domain can be registered by anyone and used to impersonate the organisation or to receive its mail.

Keep records accurate. Remove records for decommissioned services, which prevents the dangling-CNAME takeover of the record-types chapter; prune stale SPF entries; and remove old hosts.

Consider DNSSEC. DNSSEC signs records cryptographically so that a resolver can verify an answer genuinely came from the zone's owner and was not altered. It addresses the authentication gap identified in the resolution chapter, and it is the defence against cache poisoning and spoofed answers. It is not universal because it adds operational complexity, key management and a real risk of taking a domain offline through a signing error, and because validation must be performed by the resolver, which not all are. It is the right answer for a domain whose integrity matters, and the honest summary is that it protects the integrity of answers, not their confidentiality.

Consider encrypted DNS (DNS over TLS or over HTTPS) for your own users' queries, which stops a local attacker reading or tampering with lookups on the network. Note the complementary roles: DNSSEC authenticates the data, encrypted DNS protects the channel; neither replaces the other.

Log and monitor. Query logs on the resolver reveal internal hosts contacting suspicious domains, which is one of the best detective controls an organisation has, and it belongs to the defender's-mirror chapter. On the authoritative side, monitor for the enumeration pattern: many queries for names that do not exist.

Rate limit responses on authoritative servers, which reduces their usefulness as amplifiers.

A worked example

An assessor reviews an organisation's DNS, within scope.

• She first confirms the basics passively: NS records name two servers, both operated by the organisation itself rather than a provider.
• With authorisation, she requests a zone transfer from each. The first refuses. The second succeeds, returning 61 records.
• The transfer reveals 38 host names, of which the passive enumeration of the previous chapter had found 22. The new ones include vpn-legacy, hr-test and backup-dr.
• It also reveals a CNAME pointing to a cloud storage service that returns an error, suggesting the service was decommissioned but the record was not: a possible subdomain takeover.
• Reviewing the configuration with the administrators shows the second server permits transfers from any address, because it was rebuilt last year and the restriction was not carried across.

Her findings, in priority order:

1. Open zone transfer on the second name server. Restrict to the known secondaries and authenticate with TSIG. This is urgent and takes minutes.
2. Dangling CNAME to a decommissioned service. Remove the record and check for others.
3. Sixteen host names not on the asset register, discovered through the transfer, several suggesting unmaintained systems.
4. The registrar account lacks multi-factor authentication and registrar lock is not enabled.
5. Recommendations: separate authoritative from recursive, enable auto-renewal and expiry monitoring, and evaluate DNSSEC.

Note that the open transfer's real damage was not the transfer itself but what it revealed: sixteen unmanaged systems. The configuration error was a minute's work to fix; the inventory problem it exposed is months of work, and is the more important finding.

What beginners get wrong

• Calling the zone transfer an attack. It is a legitimate replication mechanism. The defect is an access-control setting, and describing it correctly is what makes the fix obvious.
• Thinking an open transfer is rare because the fix is easy. It persists because it causes no symptom, so operations never discovers it.
• Testing for it without authorisation. The request reaches the organisation's server and is recorded; it is active reconnaissance.
• Believing DNSSEC encrypts DNS. It authenticates records and protects integrity; it does not provide confidentiality. Encrypted DNS is the separate control for the channel.
• Ignoring the registrar account. It is the highest-leverage target in the whole DNS estate, since it repoints everything at once, and it is often protected only by a password.
• Running one server for both authoritative and recursive roles. An internet-reachable recursive resolver becomes an amplifier used against third parties.

Quick revision

• A zone transfer replicates a zone from primary to secondary; AXFR is full, IXFR incremental, and the SOA serial signals a change. It runs over TCP.
• An open transfer returns every record in one request, replacing all enumeration with an authoritative, complete answer. It is active and needs authorisation to test.
• It persists because defaults changed while deployments did not, because it produces no symptom, and because permissions get widened under time pressure.
• Fix: restrict transfers to the known secondaries, authenticated with TSIG.
• Hardening: separate authoritative from recursive and never expose a resolver (open resolvers become amplifiers); protect the registrar account with multi-factor authentication and registrar lock; monitor expiry and auto-renew; remove records for decommissioned services; consider DNSSEC (integrity of answers, not confidentiality) and encrypted DNS (the channel); log resolver queries and monitor for enumeration; rate limit responses.

Test yourself

1. What is a zone transfer legitimately for, and what makes an open one dangerous?

It replicates a zone's records from a primary name server to its secondaries so that all authoritative servers hold the same data. An open transfer is dangerous because any party can request it and receive the complete zone, disclosing every host name and record at once, including names no passive source or dictionary would find.

1. Why does this misconfiguration survive in production for years?

Because it produces no symptom: nothing fails, no user complains and no monitoring fires, so ordinary operations never discover it. It also persists where long-lived servers retain permissive settings from before defaults changed, or where a permission was widened under time pressure and never tightened.

1. State the fix precisely.

Configure the authoritative servers to permit zone transfers only to the known secondary servers, identified by address, and where supported authenticate those transfers with a shared key (TSIG) so the permission rests on a secret rather than a spoofable address.

1. Why is the registrar account described as the highest-leverage target in an organisation's DNS?

Because whoever controls it can change the name servers for every domain the organisation owns, redirecting its website, its mail and its services at once. That redirects the organisation's identity rather than compromising a single system, and the account is often protected only by a password, so multi-factor authentication and registrar lock are essential.

1. What does DNSSEC protect, and what does it not?

It protects the integrity and authenticity of DNS answers by signing records so a validating resolver can detect forged or altered responses, which defends against spoofing and cache poisoning. It does not provide confidentiality: queries and answers remain readable, so encrypted DNS over TLS or HTTPS is the separate control for protecting the channel.

Privacy: why modern WHOIS shows less

A student working from older material will expect names and addresses and mostly will not find them. Two changes account for it.

Registrar privacy services. For a small fee, or free by default with many registrars, the registrant's details are replaced in the public record by the privacy service's own, which forwards correspondence. The real registrant is still known to the registrar, but not to the public.

Data-protection law. The European General Data Protection Regulation caused registries and registrars to redact personal data from public WHOIS output as a matter of course, because publishing an individual's name, address, email and telephone worldwide is difficult to justify. The effect extends well beyond Europe because the operators applied it broadly.

So the modern position is: organisational domains often still show a company name and a role-based contact; domains held by individuals usually show a privacy service or redacted fields. For a defender this means an exposed personal name and address in a WHOIS record is a finding, not the expected state, and the remedy is to enable the registrar's privacy service.

A caution for accuracy: historical WHOIS data persists. Services archive past records, so details redacted today may remain visible in a record from before privacy was applied. Enabling privacy protects the future, not the past.

The regional internet registries

Addresses are allocated in a hierarchy. At the top is the global coordinating body, which allocates large blocks to five regional internet registries, each covering a part of the world. Those allocate to internet providers and to large organisations, who assign to customers.

MU's syllabus names ARIN because it is the best known and its database is the model; an Indian organisation's addresses are normally registered with APNIC, and the query is identical in form.

What a registry lookup returns. Given one address, it returns the block that contains it, the organisation that holds the block, the block's size, and technical and abuse contacts. Larger organisations also register autonomous system numbers, which identify their networks in internet routing, and from an autonomous system number all the address ranges it announces can be listed.

Why the address range is the most useful thing in this chapter

Because it defines boundaries, and boundaries are what both an attacker and an assessor need.

For an attacker, knowing that an organisation holds a range means every address in it is worth examining, including hosts with no DNS name at all. One discovered web server expands into a block of addresses to sweep.

For an assessor, the same lookup answers the question the authorisation chapter raised: what actually belongs to the client? If the address is inside a range registered to the client, it is theirs and the client can authorise testing of it. If it is inside a hosting or cloud provider's range, it is not, and the client cannot grant permission over the provider's infrastructure; the provider's own testing policy applies, and some require notification.

That distinction prevents the commonest scoping error in the profession, and it is why registry lookups belong in the pre-engagement work rather than in the middle of a test.

For a defender, the same lookup is an inventory check: sweeping your own registered ranges finds hosts you have forgotten, which is the point the enumeration chapter made from the other direction.

A worked example

Nisha maps her organisation's estate, beginning with a name and finishing with a boundary.

1. Domain WHOIS on company.test shows an organisational registrant, a role-based contact, a creation date of 2011, expiry in fourteen months with the status indicating a registrar lock is in place, and two name servers. Sound, except that a second domain the company owns, company-india.test, shows a former employee's personal name and mobile number and expires in six weeks with no lock.
2. She resolves the main site to an address and queries APNIC, which returns a range held by a hosting provider. So the website is hosted, and the provider's infrastructure is not the client's to authorise.
3. She resolves the VPN endpoint, queries APNIC again, and this time the range is registered to the company itself, a block of addresses along with an autonomous system number. That range is the client's own estate.
4. Sweeping the company's own range for names and responses finds three hosts that appear in no DNS record and on no inventory.

Her findings: the second domain's personal registrant data and imminent expiry without a lock (urgent, and a hijack and impersonation risk); the confirmed boundary between client-owned addresses and provider-owned ones, which is recorded in the scope; and three unregistered hosts inside the company's own range.

The middle finding is the one that makes the engagement safe, and it is invisible unless somebody does this lookup.

What beginners get wrong

• Conflating domain WHOIS with registry WHOIS. One is about a registered name and comes from registrars; the other is about an address block and comes from a regional registry.
• Expecting personal details. Privacy services and data-protection redaction are now normal. An exposed personal record is a finding, not the default.
• Assuming privacy fixes the past. Historical WHOIS archives retain what was published before privacy was enabled.
• Thinking ARIN covers the world. There are five regional registries; India's is APNIC.
• Ignoring expiry and lock status. A lapsed domain can be taken over and used to receive the organisation's mail, including password resets. Auto-renewal, monitoring and registrar lock are the controls.
• Assuming everything resolving to a client's name is in scope. If the address belongs to a hosting provider, the client cannot authorise testing of that infrastructure.

Quick revision

• Domain WHOIS: registrant, contacts, registrar, created/updated/expiry, name servers, status codes (transfer lock). Served by registrars and registries.
• Registry WHOIS: which organisation holds an address block, the block's size and abuse contacts, and autonomous system numbers. Served by the five regional registries: ARIN (North America), RIPE NCC (Europe, Middle East), APNIC (Asia-Pacific, India), LACNIC (Latin America), AFRINIC (Africa).
• Modern domain records are usually privacy-protected or redacted; an exposed personal registrant is a finding. Historical archives persist.
• Expiry and registrar lock are the actionable defensive items: a lapsed domain can be hijacked and used to receive the organisation's mail.
• The address range is the most useful output: it expands one host into an estate for enumeration, and it settles what the client owns and can lawfully authorise.

Test yourself

1. Distinguish domain WHOIS from a regional registry lookup.

Domain WHOIS returns registration details for a name (registrant, registrar, dates, name servers, status) and is served by registrars and domain registries. A regional registry lookup returns which organisation holds the address block containing a given IP address, the block's extent and its contacts, and is served by one of the five regional internet registries.

1. Why has WHOIS output become less revealing, and what does that mean for an assessor?

Registrar privacy services replace registrant details with a proxy, and data-protection law, principally the GDPR, caused widespread redaction of personal data. For an assessor it means exposed personal details in a record are a finding to report rather than the expected result, and that historical archives may still show pre-redaction data.

1. Which registry serves India, and why does the syllabus mention ARIN?

APNIC serves the Asia-Pacific region including India. The syllabus names ARIN because it is the best-known regional registry and its database is the model for the others; the query technique is identical.

1. Why is an address-range lookup important before testing begins?

Because it determines what the client actually owns. Addresses inside a range registered to the client are the client's own estate and can be authorised; addresses inside a hosting or cloud provider's range belong to that provider, which the client cannot authorise, so the provider's testing policy applies instead.

1. What are the risks of an unmonitored domain expiry, and what controls address them?

An expired domain can be registered by anyone, who can then serve content from the organisation's addresses and receive mail sent to the domain, including password-reset messages, enabling impersonation and account takeover. The controls are auto-renewal, current payment details on the registrar account, expiry monitoring for every domain owned, and registrar lock against unauthorised transfer.

What defeats it. Verification through a separate, known channel, and a culture in which verifying a senior person's request is explicitly expected rather than tolerated. The rule has to be stated by senior people themselves, or the social cost remains.

Urgency and fear

A deadline or a threat compresses the time available to think. "Your account will be suspended in two hours." "The payment must go today or we lose the contract." "There has been suspicious activity on your account."

Why it works. Careful evaluation takes time and attention. Remove the time and the target falls back on fast pattern-matching, which is exactly the mode in which a plausible-looking message passes. Fear narrows attention further, onto the threat and away from the message's oddities.

The tell. Urgency that is manufactured rather than inherent is the single most reliable indicator of a social-engineering attempt. Genuine business urgency exists, but it rarely also insists that you must not check with anyone.

What defeats it. A rule that certain categories of request are never urgent: changes to payment details, password resets for another person, transfers above a threshold. If the process says these always take a verification step, then urgency cannot bypass it, because the urgency is not what the procedure responds to.

Reciprocity

People feel obliged to return a favour. Give something small first and the target is more willing to give something back.

How it is abused. The attacker provides "help" before asking: a caller from "IT support" who fixes a minor problem and then asks the user to confirm their password; a free tool, a useful document, a held door.

What defeats it. Recognising that a favour does not create an obligation to bypass a control, and process rules that do not bend for goodwill.

Social proof

People look to others' behaviour to decide what is normal. "Everyone in your department has already completed this." "Three of your colleagues have signed in to the new portal."

How it is abused. A claim that others have complied lowers resistance and makes hesitation feel like being the odd one out. It is especially effective on new joiners, who have no baseline for what is normal here.

What defeats it. Making the true norm visible: if staff know the organisation never asks for credentials by email, a claim that everyone else has provided theirs contradicts a known rule rather than an unknown one.

Liking and familiarity

People comply more readily with those they like or recognise. Attackers build rapport, mirror language, mention shared connections, or simply appear familiar.

How it is abused. A friendly caller who mentions a colleague's name; a message from a compromised genuine contact, which is the strongest form, because the familiarity is real. This is why a compromised account inside a supply chain is so dangerous: the trust is not simulated.

What defeats it. Verification that does not depend on recognition. A known contact's account can be compromised, so a request for something sensitive is verified by channel, not by whether the sender seems familiar.

Commitment and consistency

Once someone has agreed to something small, they are more likely to agree to something larger consistent with it. An attacker may open with a trivial, harmless request and escalate.

What defeats it. Recognising the escalation pattern, and process gates that apply regardless of what was agreed earlier in the conversation.

The routine

The quietest lever, and the one that most often carries a real attack. A request that looks like ordinary business is not scrutinised, because scrutiny is reserved for the unusual. An invoice, a delivery note, a shared document, a calendar invitation, a request to update bank details from a supplier you actually use.

Why it works. The other levers push; this one simply does not trigger the check. Most successful business-email-compromise attacks rely on it, not on drama.

What defeats it. Process rather than alertness. If updating a supplier's bank details always requires a callback to a number already on file, the attack fails whether or not anyone felt suspicious.

Why these are hard to resist even when you know them

Three honest observations, and a good answer includes them.

Knowing about a bias does not switch it off. Awareness reduces susceptibility; it does not eliminate it. Security professionals are phished successfully.

The attacker only needs one success. A message sent to two hundred staff needs one person having a bad morning.

The target is doing their job. The finance clerk who pays an invoice is performing their function. The attack is shaped to look like the work.

Those three together are the argument for the defensive structure of the whole block: awareness lowers the rate, and controls must make a single human error survivable. That is the multi-factor authentication and verification-procedure argument, and it is why the defence chapter later refuses to rest on training alone.

A worked example: reading the levers in one message

An email arrives at a finance clerk's address. It appears to come from the Managing Director, whose name and title are on the company website. It reads: the MD is in a meeting and cannot take calls; a supplier payment must be released today or a contract is lost; the bank details have changed and are given below; please confirm when done.

Name the levers:

Four levers and a pre-emptive block on the one defence that would work, assembled from information that was all public: the MD's name from the website, the clerk's address from the email format, the supplier's name perhaps from a press release. Nothing here required any technical compromise.

Now the defence. Not "the clerk should have been suspicious", which is hindsight. The organisation should have had a rule that a change of bank details is always verified by a call to a number already on file, regardless of who asks or how urgent it is. Under that rule the clerk does not need to detect anything; the process catches it, and the "cannot take calls" line becomes the reason to stop rather than to proceed.

What beginners get wrong

• Calling people the weakest link. These responses make organisations function; the attack abuses cooperation. A design that needs constant suspicion is the failure.
• Thinking awareness alone is enough. It lowers the rate and never to zero, and the attacker needs one success. Controls must make one error survivable.
• Looking for spelling mistakes. Poor writing was never a reliable signal and is not now. The signals are structural: manufactured urgency, a request to bypass a process, pressure not to verify.
• Assuming a familiar sender is safe. A genuine contact's account can be compromised, and that is the most effective form of the attack.
• Blaming the person who clicked. It is unfair and operationally harmful: blame makes people hide mistakes, which lengthens the time to respond.
• Treating the quiet attacks as less serious. The routine-looking request, not the dramatic one, carries most successful business-email compromise.

Quick revision

• Social engineering triggers normal, useful instincts at the wrong moment; it does not defeat judgement, it arranges the situation.
• Levers: authority (markers of entitlement, plus the social cost of questioning), urgency and fear (compress thinking time; manufactured urgency is the strongest tell), reciprocity (a favour first), social proof ("everyone else has"), liking and familiarity (strongest when a genuine account is compromised), commitment and consistency (small agreement then escalation), and the routine (looks like ordinary business, so nothing triggers a check).
• Defences map to levers: verification through a separate known channel; rules that certain requests are never urgent; process gates that do not bend for goodwill, familiarity or prior agreement; making the true norm visible.
• Knowing the biases does not remove them, the attacker needs one success, and the target is doing their job, so controls must make a single error survivable.

Test yourself

1. Why is it said that social engineering does not defeat a person's judgement?

Because it arranges a situation in which normal, useful judgement produces the attacker's desired answer: deference to apparent authority, action under apparent urgency, and non-scrutiny of what looks like routine business are all sensible responses being triggered at the wrong moment.

1. Name five levers and give one sentence on how each is abused.

Authority, by imitating someone entitled to make the request; urgency and fear, by compressing the time available to think; reciprocity, by providing a small favour before asking; social proof, by claiming colleagues have already complied; and familiarity, by building rapport or by using a genuinely compromised known account.

1. Which single element of a message is the most reliable indicator of a social-engineering attempt, and why?

Manufactured urgency, particularly when combined with a reason the request cannot be verified. Genuine business urgency exists, but it rarely also insists that the recipient must not check with anyone, so pressure plus a pre-emptive block on verification is the structural signal.

1. Why is "the routine" lever more dangerous than the dramatic ones despite being the quietest?

Because the other levers push the target into acting while this one simply fails to trigger any check: an ordinary-looking invoice or supplier update is processed as work, and scrutiny is reserved for the unusual. Most successful business-email compromise relies on it.

1. Why must defences not rest on awareness training alone?

Because knowing about a bias does not switch it off, the attacker needs only one person to comply once, and the target is performing their normal duties when deceived. Controls such as multi-factor authentication and mandatory verification of sensitive changes are required so that a single human error does not by itself cause harm.

Whaling is spear phishing aimed at senior executives. They are attractive because they can authorise payments, because their instruction carries weight with others, and because their assistants act on their behalf. A common pattern is not to attack the executive at all but to impersonate them to finance staff, which is the business-email-compromise shape from the psychology chapter.

Business email compromise deserves naming as the financially most damaging form. There is often no malicious link or attachment at all: the message is plain text asking for a payment or a change of bank details. Nothing for a filter to detect, and the defence is entirely procedural.

Smishing and vishing

Smishing, over SMS, exploits three differences from email. Links are shortened, so the destination is hidden. Phone interfaces show less context and make inspection harder. And SMS carries an implicit trust, since people receive genuine bank alerts and delivery notices that way. Sender identifiers can be spoofed in many networks, so the message may appear in the same conversation thread as genuine messages from the real organisation, which is powerfully convincing.

Vishing, over voice, adds the pressure of a live conversation: the target cannot pause to think, and refusing a person feels harder than ignoring a message. Caller identification can be forged. A frequent pattern is the "support" call claiming a problem with the target's computer or account, and a more sophisticated one is a call that follows a phishing email to lend it credibility.

A combination worth knowing: an attacker who has a password may phish or vish the one-time code that protects the account, calling as "the bank's fraud team" and asking the victim to read out the code they have just received. This is why codes always carry a warning that nobody legitimate will ask for them, and why phishing-resistant factors matter, a point the defence chapter takes up.

How the deception is constructed

A student should be able to describe the construction, because recognising it is the defence.

The sender. Either a forged address in the target's own domain (which works when DMARC is absent or permissive), a look-alike domain differing by a character or a plausible suffix, a display name set to a trusted person while the real address is unrelated (very effective on phones, which often show only the display name), or a genuine compromised account, which defeats every sender check.

The link. Display text that differs from the destination; a look-alike domain; a shortener; a legitimate service abused to host the page; or a redirect through a trusted site.

The landing page. A copy of a real login page, often fetched live from the original so it is pixel-accurate, sometimes forwarding entered credentials to the real site so the victim ends up logged in and notices nothing.

The pretext. One or more of the levers from the previous chapter, most often authority plus urgency, with a reason the request cannot be verified.

Recognition, and the signals that are not reliable

Signals that do help:

• The request is for credentials, a code, a payment, or a change of payment details. Legitimate organisations do not ask for passwords or one-time codes.
• Manufactured urgency, especially with a reason not to verify.
• A mismatch between the display name and the actual address, or between link text and destination.
• The message asks you to break a normal process.
• It arrives out of the expected channel for that kind of request.

Signals that are not reliable, and this is where teaching often goes wrong:

• Spelling and grammar. Targeted messages are well written, and automated translation has removed this signal.
• A logo that looks right. Trivially copied.
• A link that begins with HTTPS. Certificates are free; encryption says nothing about honesty.
• A familiar sender. The account may be compromised.
• "I was expecting something like this." Attackers time messages to expectations, around results, payroll, renewals and deliveries.

The structural conclusion, which is the examinable one: recognition should rest on what the message asks you to do, not on how it looks.

Defences, in layers

Fully treated in the two chapters that follow, summarised here so the family is complete.

Technical. Email authentication (SPF, DKIM, DMARC) to make domain forgery harder to deliver; mail filtering and link inspection; blocking or flagging look-alike domains; and multi-factor authentication, which turns a harvested password into a failed login. Phishing-resistant factors bound to the site defeat even real-time credential relaying.

Procedural. Verification through a known second channel for any payment or bank-detail change; a rule that such requests are never urgent; and clear statements of what the organisation will never ask for.

Human. Training that teaches the levers rather than the spelling mistakes; simulated exercises used to measure and educate, never to punish; and above all an easy, no-blame reporting route, because the speed of the response depends on someone saying "I think I clicked something" within minutes rather than hiding it for a day.

A worked example

A university finance officer receives an email. The display name is the Registrar's; the actual address is at a domain one character different from the university's. It refers to a building project by its real name, states that a contractor's account details have changed, gives new details, says payment must go today because works are stopping, and adds that the Registrar is travelling and unreachable.

Reading it with the chapter's tools:

• Class: spear phishing shading into business email compromise. No link, no attachment, so filtering has little to act on.
• Reconnaissance used: the Registrar's name and title (public), the project name (a press release), the finance officer's address (the email format), and perhaps the contractor's name (a tender notice).
• Construction: a look-alike domain with a trusted display name, which on a phone shows only "Registrar".
• Levers: authority, urgency, the routine (paying a contractor is the job), and a pre-emptive block on verification.
• Unreliable signals: the message is well written, plausible and correct in every detail, so "look for mistakes" fails entirely.
• What stops it: the procedural control. A rule that bank-detail changes are verified by calling a number already held on file means the officer does not need to detect anything, and "unreachable" becomes the reason to stop rather than to proceed.
• What limits it if it succeeds: rapid, blameless reporting, because a payment recalled within the hour is often recoverable and one reported next week is not.

What beginners get wrong

• Teaching spelling mistakes as the signal. Targeted messages are well written; this advice fails exactly where it is most needed.
• Thinking phishing always involves a link or attachment. Business email compromise is often plain text, which is why it evades filtering and why the defence is procedural.
• Treating a familiar sender as safe. Compromised genuine accounts are the most effective vector.
• Believing a padlock or HTTPS indicates legitimacy. Certificates are free and say nothing about who the site belongs to.
• Forgetting SMS and voice. They lack email's authentication mechanisms, can be spoofed into genuine message threads, and voice adds live pressure.
• Using phishing simulations punitively. It suppresses reporting, and reporting speed is what limits damage.

Quick revision

• One attack, two axes: targeting (mass phishing, spear phishing, whaling) and channel (email, smishing by SMS, vishing by voice).
• Spear phishing is built from reconnaissance: email format, names and roles, context, the mail provider to imitate, and the DMARC policy.
• Business email compromise often has no link or attachment, so filters cannot see it; the defence is procedural.
• Construction: forged or look-alike sender, misleading display name, deceptive link, cloned landing page, and a pretext using authority plus urgency.
• Reliable signals: it asks for credentials, a code, a payment or a change of bank details; manufactured urgency with a reason not to verify; display-name or link mismatch; a request to break process. Unreliable: spelling, logos, HTTPS, familiarity.
• Layers: email authentication and filtering plus multi-factor authentication; verification through a second known channel; training on levers, and a no-blame reporting route.

Test yourself

1. Distinguish phishing, spear phishing and whaling, and say which is hardest for a mail filter to catch.

Phishing is generic and sent in volume; spear phishing targets a named individual using researched detail; whaling targets senior executives. Spear phishing, particularly in its business-email-compromise form, is hardest to filter because each message is unique, often contains no link or attachment, and may come from a genuinely compromised account.

1. What does reconnaissance contribute to a spear-phishing message?

The email format so the message is addressed correctly, the target's name, role and reporting line so it can claim plausible authority, contextual detail such as projects and suppliers to make it convincing, the mail provider to imitate on any login page, and the domain's DMARC policy, which indicates whether a forged sender will be delivered.

1. Why is "look for spelling mistakes" poor advice?

Because targeted messages are carefully written and automated translation has removed the signal, so the advice fails precisely against the attacks that matter most. Recognition should rest on what the message asks the recipient to do, not on how it reads.

1. How do smishing and vishing differ from email phishing in the defences available?

Email has authentication mechanisms (SPF, DKIM, DMARC) and mature filtering, whereas SMS and voice largely lack equivalents: sender identifiers and caller identification can be forged, spoofed messages can appear inside genuine threads, links are shortened and phone interfaces hide context, and a live call adds time pressure that a message does not.

1. Why is a no-blame reporting route treated as a security control?

Because the damage from a successful phish depends heavily on response time: a fraudulent payment recalled within the hour is often recoverable and credentials revoked quickly limit access. Blame makes people conceal mistakes, which delays response, so a culture in which reporting is easy and unpunished materially reduces loss.

Digital baiting. Free software, cracked applications, a desirable document, an offer, a fake update prompt.

Defences. Disable or restrict removable media by policy and technically; use endpoint controls that limit what a newly attached device may do, including restricting automatic recognition of new input devices; provide a safe route to hand in found items so the helpful instinct has somewhere to go; and train on the specific scenario, because it is concrete and memorable in a way that abstract advice is not.

Impersonation

What it is. The attacker assumes a trusted identity. It underlies much of the rest of this block: a phishing email impersonates a sender, a vishing call impersonates support, a pretext usually requires an identity to inhabit.

In person, impersonation relies on props and expectations more than on documents: a high-visibility jacket and a clipboard, a delivery uniform, a contractor's toolbag, a visitor badge from a previous visit, or simply confidence. People read roles rather than credentials; someone dressed as a cleaner at the expected hour is not examined.

Common physical impersonations: delivery driver, maintenance or utility engineer, fire-safety inspector, IT contractor, new starter, and auditor.

The legal position is sharp. Impersonation to deceive by means of a computer resource is exactly what section 66D punishes, and physical impersonation to obtain entry is trespass and may be other offences. An unauthorised "test" of a building or a help desk is not a grey area. Social engineering is tested only where the engagement's scope expressly authorises it, and a tester doing it carries their authorisation letter so that the exercise ends with a document rather than an arrest.

Defences. Verify identity by a defined process rather than by appearance; require and check visitor registration and escorting; issue visually distinct badges for staff, contractors and visitors; confirm expected visits with the requesting department before granting access; and make it culturally normal to ask an unescorted stranger who they are looking for, which requires management to say explicitly that challenging is expected and that nobody will be criticised for it.

Tailgating

What it is. Following an authorised person through a controlled door, so the attacker never presents a credential at all. Piggybacking is sometimes distinguished as the case where the authorised person knowingly holds the door; tailgating where they do not notice.

Why it works so reliably, and it does: it exploits politeness, not inattention. Holding a door for the person behind you is good manners, and refusing feels rude. The attacker helps by giving a reason not to challenge: carrying a large box, being on the phone, balancing coffee cups, wearing a uniform, or arriving in a crowd at the start of the day.

Defences. Physical measures work better than exhortation: airlocks or turnstiles that admit one person per authentication; anti-passback rules so a credential cannot be used to enter twice without an exit between; and door sensors that alarm when a door is held open. Beyond hardware, reception staff trained and explicitly empowered to challenge, escort policies for all visitors, and the cultural change of making it normal to ask. The honest point is that training alone struggles against politeness, which is why organisations that care about this buy turnstiles.

Once inside, the value is large: network sockets, unlocked screens, documents on desks and in printers, and the trust extended to anyone who is evidently already inside. This is the argument for clear-desk and screen-lock policies and for not treating physical presence as authentication on the network.

Combining the techniques

Real attacks chain them, and an examination question often describes a chain.

A representative sequence: reconnaissance gives the names of the IT manager and a supplier; a vishing call to the help desk, using a pretext (a new starter) and impersonating that supplier's engineer, obtains the name of the remote-access system; a spear-phishing email to a named employee, referencing the supplier by name, harvests credentials; and if remote access fails, tailgating into the building at the morning rush provides a network socket.

Each step is modest and each makes the next more credible, which is the pattern to recognise. It is also why isolated defences fail: a control that stops one step in a chain is worth more than it appears, because the chain cannot continue.

A worked example

A tester engaged with explicit authorisation for physical and social-engineering testing, carrying a signed letter, attempts entry to an office.

• Reconnaissance: a photograph on the company's social media shows the badge design and the reception layout; a job advertisement names the cleaning contractor.
• Pretext and impersonation: the tester arrives at 08:45 in the cleaning contractor's branded shirt, carrying supplies.
• Tailgating: staff are arriving in numbers; a person ahead holds the door, seeing full hands and a uniform. No credential is presented.
• Inside: two unlocked screens, printed documents in the printer tray, and an unused meeting-room network socket.
• The test ends when a staff member challenges the tester at 09:20 and the tester produces the authorisation letter. That challenge is recorded as a positive finding, and the person who made it should be commended in the report.

Findings and recommendations: install a turnstile or airlock at the main entrance (the only control that reliably addresses tailgating); enforce clear-desk and automatic screen locking; disable unused network sockets and require authentication for network access; verify contractor visits with the facilities team in advance; and, since one employee did challenge, recognise it publicly to reinforce the behaviour.

That last recommendation is deliberate. A social-engineering report that lists only failures teaches staff that the exercise exists to catch them out, which suppresses the reporting and challenging the organisation needs.

What beginners get wrong

• Thinking pretexting is about lying convincingly. It is about constructing a context in which the request is routine, and pre-empting verification.
• Believing people fall for baiting through foolishness. Much found media is connected by people trying to identify the owner. The instinct is helpful and is being exploited; give it a safe outlet.
• Treating tailgating as inattention. It is politeness. Exhortation works poorly against it; turnstiles and anti-passback work well.
• Assuming a badge or uniform is verification. People read roles, not credentials. Verification must be a process.
• Testing social engineering without explicit authorisation. Impersonation by computer engages section 66D and physical entry is trespass; it is authorised expressly or not at all.
• Writing a report that names and blames individuals. It suppresses challenging and reporting, which are the behaviours the organisation most needs.

Quick revision

• Pretexting: a fabricated scenario supplying a reason, a role and an expectation; works through the routine lever and usually pre-empts verification. Help desks are the most pretexted function; identity verification must be procedural and invariant.
• Baiting: offers something desirable, physically (found removable media, sometimes presenting as a keyboard) or digitally. Restrict media, control new devices, provide a safe hand-in route.
• Impersonation: assuming a trusted identity, relying on role-reading rather than credentials. Engages s.66D by computer and trespass physically; requires explicit scope authorisation.
• Tailgating (and piggybacking): entering behind an authorised person, exploiting politeness. Addressed by turnstiles, airlocks, anti-passback and door alarms more than by training.
• Real attacks chain these; breaking any one link stops the chain.
• Report findings about process, and record and commend successful challenges.

Test yourself

1. What does a pretext supply, and why is pre-empting verification part of it?

It supplies a reason the attacker is asking, a role entitling them to ask, and an expectation of how the target should respond, so the request seems routine. Pre-empting verification (the manager is travelling, the system is down) removes the one defence that would defeat it, so a good pretext includes it by design.

1. Why is baiting with found removable media effective, and what defences address it?

Because curiosity and, more often, the helpful instinct to identify and return the owner lead people to connect it; some devices present as keyboards and type commands, defeating file-based controls. Defences are restricting removable media technically and by policy, endpoint control over newly attached devices, a safe route for handing in found items, and specific training on the scenario.

1. Why does tailgating succeed even in organisations with badge access, and what actually stops it?

Because it exploits politeness rather than inattention: holding a door is good manners and challenging feels rude, and attackers supply reasons not to challenge such as full hands or a uniform. Physical controls stop it: turnstiles or airlocks admitting one person per authentication, anti-passback, and alarms on doors held open, supported by empowered reception staff and escort policies.

1. What is the legal position of impersonation in a security test?

Impersonation to deceive by means of a computer resource falls under section 66D of the IT Act, and physical impersonation to gain entry is trespass. It is therefore lawful only where the engagement's scope expressly authorises social-engineering and physical testing, and the tester carries the authorisation letter.

1. Why should a social-engineering report avoid naming individuals who were deceived, and what should it record instead?

Because naming individuals assigns blame for behaviour the organisation relies on and suppresses the challenging and reporting that limit damage. The report should record process failures and recommend controls, and should positively record instances where staff did challenge or report, so the desired behaviour is reinforced.

Question 1: which levers?

• The routine, and this is the principal one. Paying a supplier's invoice is the clerk's job, and a notification of changed bank details is a thing suppliers genuinely send. Nothing about the request was unusual, so nothing triggered scrutiny.
• Authority, mildly: the supplier's accounts department is entitled to state its own bank details.
• Familiarity: a real supplier, a real invoice number, an established relationship.
• Notably not urgency. The absence is instructive: the attacker did not need pressure because the request was already normal, and urgency might have prompted a check.

Question 2: what reconnaissance? The attacker knew the supplier relationship existed, the invoice number, and the clerk's address. The most likely source is a compromised mailbox at either company, giving access to genuine correspondence, which also explains the accurate invoice number and matching tone. Alternatively, public tender or contract records plus the email format.

Question 3: which control failed? Precisely: there was no requirement to verify a change of banking details through an independently obtained channel. The company treated an emailed instruction as sufficient authority to change where money is sent. Secondarily, there was no out-of-band confirmation to the supplier that details had changed, and no alerting on a payment to newly changed details.

Question 4: the single control. A mandatory callback to a telephone number already held on file (not one supplied in the message) before any change to payment details takes effect. This defeats the attack completely and regardless of how convincing the email was, because the attacker does not control the number on file.

Question 5: what would have limited the damage? Detecting it sooner. An alert when a payment is made to bank details changed within the last thirty days would have surfaced it in days rather than three weeks, and funds recalled quickly are sometimes recoverable.

The lesson. The most costly social engineering is often the least dramatic. There was no malware, no link, no urgency and nothing for a filter to detect. A control that depends on someone feeling suspicious would not have worked, because there was nothing to feel suspicious about.

Case two: the help desk and the second factor

The narrative. An attacker has obtained an employee's password from an unrelated breach where the employee reused it. The corporate account requires a second factor, a code from an application on the employee's phone, so the password alone fails.

The attacker telephones the company's IT help desk, gives the employee's name and employee number, and says they have a new phone and cannot generate codes, and that they have a customer presentation in twenty minutes. The help desk agent, following a procedure that asks for name, employee number and date of birth, all of which the attacker has from public and breach sources, resets the second-factor enrolment. The attacker registers their own device and signs in.

Question 1: which levers?

• Urgency: the presentation in twenty minutes, compressing the agent's decision and making a thorough check feel obstructive.
• The routine: "I have a new phone" is among the commonest genuine help-desk requests.
• Authority, weakly, and liking: a colleague in difficulty, and the help desk exists to help.

Question 2: what reconnaissance? The employee's name and role (professional networking site), the employee-number format (possibly a photograph of a badge, or a document's metadata), the date of birth (social media), and the password (a third-party breach, exploited through reuse). Note how little of this came from the company's own systems.

Question 3: which control failed? Two, and both should be named. First, the help desk's identity verification relied on information that is not secret: name, employee number and date of birth are all discoverable, so the procedure verified knowledge of public facts rather than identity. Second, the second factor could be reset by a telephone call, which means the strength of the second factor was reduced to the strength of the help-desk procedure. A third, upstream: password reuse was possible because there was no check against known-breached credentials.

Question 4: the single control. A stronger identity-verification procedure for second-factor resets: verification through the employee's manager, a video call with an identity document, or a code sent to a pre-registered alternative channel. Most simply, the reset should not be completable in one telephone call by someone who knows only public facts.

Question 5: what would have limited the damage? Alerting on second-factor re-enrolment followed by a sign-in from a new device and an unfamiliar location, and requiring re-authentication for sensitive actions so that a session obtained this way could not immediately do the most damaging things.

The lesson, and it is the most transferable in this chapter: a control is only as strong as its recovery path. An organisation that deploys multi-factor authentication and leaves a telephone call as the reset route has moved the attack, not prevented it. Attackers always look for the recovery path, because it exists precisely to let someone in who cannot authenticate normally.

A worked example: the analysis as a reproducible table

For the examination, this is the shape to produce for any scenario given:

What beginners get wrong

• Ending the analysis at "the employee was careless". It is hindsight, it produces no fix, and in both cases above the employee was doing their job correctly under the procedures they had.
• Naming the technique and stopping. "This was phishing" is a classification, not an analysis. The four questions are the analysis.
• Recommending "more training" as the single control. Training lowers the rate and cannot be the answer where, as in case one, there was nothing to notice. Name a process gate or a technical control.
• Missing the recovery path. Case two is the standard shape: the control was sound and its reset route was not.
• Listing twenty recommendations equally. Ranking is the professional contribution. Name the one that would have stopped it.
• Forgetting the damage-limiting question. Prevention fails eventually; detection speed determines the loss.

Quick revision

• The method, four questions: which lever, what reconnaissance, which control failed, what single control would have stopped it; plus a fifth, what would have limited the damage.
• Case one, supplier payment fraud: the routine and familiarity, no urgency needed; likely a compromised mailbox supplied the invoice detail; no independent verification of banking changes; callback to a number already on file defeats it; alerting on recently changed payment details limits it.
• Case two, help-desk second-factor reset: urgency and the routine; public facts plus a reused breached password; verification by non-secret facts and a resettable second factor; stronger reset verification defeats it; alerting on re-enrolment plus new-device sign-in limits it.
• Two transferable lessons: the costliest attacks are often the least dramatic, and a control is only as strong as its recovery path.
• An analysis that ends in blame has not finished; it must end in a control.

Test yourself

1. State the four questions that constitute an analysis of a social-engineering incident.

Which psychological lever or levers were pulled; what reconnaissance made the approach plausible and where it came from; which control failed or was absent, stated precisely; and what single control would most likely have prevented it. A fifth question, what would have limited the damage, completes it.

1. In the supplier-payment case, why would awareness training have been an inadequate recommendation?

Because there was nothing for the clerk to notice: the request was routine, unhurried, referenced a genuine invoice number and came from a real supplier relationship, so no amount of alertness reliably distinguishes it. The effective control is procedural, a mandatory callback to a number already on file before payment details can change.

1. What general lesson does the help-desk case teach about multi-factor authentication?

That a control is only as strong as its recovery path. Deploying a second factor while permitting it to be reset on a single telephone call, verified against facts that are publicly discoverable, reduces the strength of the second factor to the strength of the help-desk procedure and relocates the attack rather than preventing it.

1. Why did the attacker in the supplier case deliberately not use urgency?

Because the request was already routine and therefore unlikely to be questioned, whereas urgency is itself a recognised warning sign and might have prompted the clerk to check. The absence of pressure made the message more, not less, convincing.

1. Why must an analysis end in a control rather than in a judgement about the person deceived?

Because the individual was performing their normal duties under the procedures provided, so attributing the failure to them yields no improvement and discourages reporting. Identifying the missing process gate or technical control produces a change that prevents recurrence regardless of who is at the desk.

The honest limit. Training reduces susceptibility measurably and never to zero. Security professionals who research phishing are phished. Any programme whose success depends on a zero click rate is designed to fail.

Process gates: the highest-value control

This is where the real protection is, and it is the answer to almost every case in the previous chapter.

A process gate is a rule that a particular sensitive action requires a specific verification step, regardless of who asks, how senior they are, or how urgent it is. Its power is that it removes the decision from the individual: the clerk does not have to judge whether the message is genuine, because the procedure requires the callback either way.

The actions that need gates:

Three design rules make gates work:

Independent channel. The verifying contact must be obtained independently, from records the organisation already holds. A number in the email signature verifies nothing, because the attacker wrote it.

No exceptions for seniority. A gate that a sufficiently senior person can override is a gate the attacker will impersonate that person to bypass. This must be endorsed publicly by senior management, or staff will not enforce it against them.

Urgency is not a reason to skip; it is a reason to apply. Since manufactured urgency is the attacker's principal tool, a procedure that relaxes under pressure inverts the defence.

Multi-factor authentication: the highest-value technical control

Against credential phishing, this is the single most effective measure available, because it breaks the link between "the attacker learned the password" and "the attacker has access".

The factors, which an examination may ask you to name: something you know (a password), something you have (a phone, a token, a security key), something you are (a fingerprint, a face). Genuine multi-factor authentication uses factors from different categories; a password plus a security question is two things you know, and is not multi-factor.

The methods are not equal, and the ranking matters:

• SMS codes: the weakest. Vulnerable to SIM-swap attacks and to interception, and phishable, but far better than nothing.
• Authenticator application codes: better, since there is no telephone network to attack, but still phishable: an attacker who relays the login in real time can ask the victim for the code and use it within its validity window.
• Push approval: convenient, and vulnerable to fatigue attacks, where an attacker with the password sends repeated prompts until an irritated or confused user approves one. Number matching, which requires the user to type a number shown on the login screen, largely addresses this and should be enabled.
• Phishing-resistant factors (security keys and platform authenticators using the standards behind them): the strongest, because the credential is bound to the legitimate site's identity and simply will not produce a valid response to a look-alike domain. This defeats even a real-time relay, which the other methods do not.

Where it must be applied. Everywhere that matters, and specifically on the paths attackers use: remote access and VPN, email, administrative accounts, cloud consoles and anything holding personal data. An organisation that enables it for staff and exempts executives has protected the wrong people.

The recovery path. The lesson from the previous chapter, repeated because it is the commonest failure: securing the login and leaving a weak reset route relocates the attack. The reset procedure must be at least as strong as the control it restores.

Limiting the damage

Prevention fails, so these determine the loss:

• Least privilege. If the deceived account can reach little, the incident is small. This is the control that turns a compromise into an inconvenience.
• Segmentation, so a foothold does not reach everything.
• Rapid revocation, the ability to disable an account and terminate its sessions in minutes.
• Detection: alerts on impossible travel, new-device sign-ins, second-factor re-enrolment, mailbox forwarding rules created (a classic post-compromise step for payment fraud), and payments to recently changed details.
• A tested incident response plan, so the first hour is executed rather than improvised.

The reporting culture, which underpins all of it

Treat it as a control, because it is one. The damage from a successful attack is largely a function of time: a fraudulent payment recalled within the hour is often recoverable; credentials revoked in minutes limit what is reached.

That time depends entirely on somebody saying "I think I did something". Which means:

• Reporting must take seconds (a button in the mail client, one number to call).
• It must be blameless, stated explicitly and by senior people.
• Reports must be acknowledged, or people stop making them.
• Near misses should be reported too, because they reveal campaigns in progress.

An organisation that disciplines the person who clicked has bought a quieter incident log and a longer average time to detection.

A worked example

A company reviews its social-engineering posture after the supplier-payment case. The recommendations, ranked by effect:

1. Process gate: bank-detail changes require a callback to a number already on file; no exceptions for seniority or urgency. Signed off publicly by the finance director.
2. Multi-factor authentication on email and remote access, using phishing-resistant keys for finance and administrative staff, with a reset procedure requiring manager verification.
3. Detection: alert on payments to details changed within thirty days, and on any mailbox rule that forwards externally.
4. Least privilege review of the finance system, so that no single account can both change payee details and release payment.
5. Training on the levers, with simulations measured on reporting rate as well as click rate, and explicitly non-punitive.
6. Reporting: a one-click report button and a published commitment that no one is penalised for reporting.

Note the ordering. Training is fifth, not because it is unimportant but because items one to four protect the company even when training fails, and item one alone would have prevented the incident that prompted the review.

What beginners get wrong

• Treating training as the programme. It reduces the rate; it cannot be the control where there was nothing to notice.
• Running punitive phishing simulations. They suppress reporting, which lengthens response time and increases loss.
• Measuring only the click rate. The reporting rate matters as much; if both fall, people have learned to stay silent.
• Calling a password plus a security question multi-factor. Both are things you know.
• Assuming all second factors are equivalent. SMS is weakest; application codes are phishable in a real-time relay; push is vulnerable to fatigue without number matching; only site-bound keys resist phishing.
• Securing the login and not the reset. The recovery path must be as strong as the control.
• Allowing seniority to override a gate. The attacker will impersonate exactly that seniority.

Quick revision

• Ordering principle: a control that needs everyone alert every time will fail. Rank by whether the control works when someone is deceived.
• Training teaches the levers, the organisation's "we will never ask" statements, the high-risk actions, and how to report; simulations must be non-punitive and measured on reporting rate as well as clicks. It lowers the rate, never to zero.
• Process gates are the highest-value control: independent-channel verification for bank-detail changes, large or new payments, password and second-factor resets, access grants and data releases; no exception for seniority, and urgency is a reason to apply the gate, not to skip it.
• Multi-factor authentication: factors from different categories (know, have, are). SMS weakest; app codes phishable in real time; push needs number matching; site-bound security keys are phishing-resistant. Apply to email, remote access and administrative accounts, and secure the reset path.
• Damage limitation: least privilege, segmentation, rapid revocation, detection (impossible travel, new devices, re-enrolment, forwarding rules, changed payee details), and a tested response plan.
• A fast, blameless reporting culture is a control, because loss is a function of time.

Test yourself

1. Why can awareness training not be the primary defence against social engineering?

Because the attacker needs only one person to be deceived once, because knowing about a bias does not remove it, and because in the most damaging attacks the request looks entirely routine so there is nothing for an alert person to notice. Training lowers the rate, while process gates and multi-factor authentication work regardless of whether anyone was alert.

1. What is a process gate, and what three design rules make one effective?

A rule that a sensitive action requires a specific verification step regardless of who asks or how urgent it is. It must use an independently obtained channel such as a number already held on file; it must have no exception for seniority, since the attacker will impersonate exactly that seniority; and urgency must trigger the gate rather than excuse it, because manufactured urgency is the attacker's principal tool.

1. Name the three categories of authentication factor and explain why a password plus a security question is not multi-factor.

Something you know, something you have, and something you are. A password and a security question are both things you know, so an attacker who obtains them by the same means, such as a phishing page or research, defeats both; genuine multi-factor authentication requires factors from different categories.

1. Rank the common second-factor methods by resistance to phishing and explain the strongest.

SMS is weakest (SIM swap, interception, phishable); authenticator application codes are better but still phishable through a real-time relay; push approval is vulnerable to fatigue attacks unless number matching is enabled; security keys and platform authenticators are phishing-resistant because the credential is cryptographically bound to the legitimate site's identity and will not produce a valid response to a look-alike domain.

1. Why is a blameless reporting culture treated as a security control, and what does punishing a click cost an organisation?

Because loss depends largely on elapsed time: a fraudulent payment recalled within the hour is often recoverable and credentials revoked in minutes limit what an attacker reaches, and that speed depends on someone reporting immediately. Punishing clicks makes people conceal mistakes, lengthening detection and response time and increasing loss, while also suppressing the near-miss reports that reveal campaigns in progress.

1. It authenticates the envelope sender, not the visible From. By itself it does nothing about what the user sees.
2. It breaks on forwarding. When a message is forwarded, the forwarding server relays it from an address that is not in the original domain's SPF record, so SPF fails for legitimate mail. This is the main reason SPF alone cannot be enforced strictly.
3. It has a lookup limit. The specification caps the number of DNS lookups a record may require (ten), and organisations that add many providers exceed it, which makes the record permanently fail for everyone. This is a common real finding, and it is caused by adding services over the years without pruning.

The reconnaissance angle, from the DNS chapter: an SPF record is a published list of the organisation's mail-sending suppliers, and stale entries authorise systems nobody controls any more. Prune it.

DKIM: was it altered, and did the domain sign it

What it is. The sending server computes a cryptographic signature over selected headers and the body, and attaches it. The corresponding public key is published in DNS at a selector name the signature specifies.

How it is checked. The receiver reads the signature header, fetches the public key from the signing domain's DNS, and verifies. A pass means the message was signed by someone holding the private key for that domain and that the signed parts have not been altered in transit.

What it does well. Unlike SPF it is tied to the message rather than the connection, so it survives forwarding in most cases, which is why DMARC can be enforced at all.

Its weaknesses.

• It proves the signing domain, which again need not be the visible From. Alignment is still required.
• A short or old key weakens it, so keys should be at least 2048 bits and rotated.
• Some mailing lists modify messages in ways that break the signature, which is why mailing lists and DMARC interact awkwardly.

DMARC: alignment, policy and reporting

DMARC is the one that makes the other two meaningful, and it contributes three things.

1. Alignment. DMARC requires that a passing SPF or DKIM result be for a domain that matches the domain in the header From, the one the user sees. This closes the gap described above: an attacker who passes SPF for their own domain while displaying yours now fails DMARC, because the authenticated domain and the displayed domain do not align.

Alignment may be relaxed (a subdomain matches the organisational domain) or strict (exact match). Relaxed is the practical default.

A message passes DMARC if either SPF or DKIM passes and aligns. Either is enough, which is what lets legitimate forwarded mail survive on DKIM when SPF has broken.

2. Policy. The record states what a receiver should do with mail that fails:

• p=none: do nothing, just report. This is monitoring mode, and it is where every deployment starts.
• p=quarantine: treat as suspicious, typically deliver to the spam folder.
• p=reject: refuse the message outright, so it never reaches the user.

A policy of none is the single most common finding in this area. It means the organisation publishes DMARC, appears to be protected, and in fact forged mail is still delivered. As the DNS chapter noted, an attacker reads the policy before deciding whether domain spoofing is worth attempting, so none is an invitation.

3. Reporting. Aggregate reports are sent to an address in the record, listing which servers sent mail claiming the domain and whether they passed. This is what makes deployment possible: before enforcing, an organisation uses the reports to discover every legitimate sender, including the marketing platform and the ticketing system that nobody told the mail administrator about, and to fix their authentication.

Deploying them, in the right order

The sequence matters because enforcing too early blocks your own mail.

1. Publish SPF listing known senders, and stay within the lookup limit.
2. Enable DKIM signing on every sending system, with adequate key length.
3. Publish DMARC with p=none and a reporting address.
4. Read the reports for weeks. Identify every legitimate sender; some will be surprises. Fix their SPF or DKIM.
5. Move to p=quarantine, perhaps applying to a percentage of mail first.
6. Move to p=reject once the reports show legitimate mail passing consistently.

Two additions worth naming: BIMI, which can display a brand logo for messages that pass DMARC at enforcement, giving a commercial incentive to reach p=reject; and MTA-STS with TLS-RPT, which address a different problem, ensuring mail is delivered over TLS rather than downgraded, and are often recommended alongside.

What these do not do, stated honestly

This is the part most notes omit, and an examiner rewards it.

They authenticate the domain, not the intent. A message that passes all three may still be phishing, sent from a domain the attacker registered and configured properly. Authentication proves authorisation, not honesty.

They do not protect against look-alike domains. If the attacker sends from a domain one character different from yours, they are sending from their own domain and can pass SPF, DKIM and DMARC for it perfectly. Your DMARC policy governs your domain and says nothing about theirs. Look-alike domains are addressed by different measures: defensive registration of near-miss spellings, monitoring for newly registered similar domains, and receiver-side detection.

They do not protect a compromised account. Mail sent from a genuinely compromised mailbox is genuinely authorised, passes everything, and is the hardest form of the attack.

They do not stop display-name abuse. An attacker can set the display name to a trusted person's name while sending from an unrelated address that passes authentication for its own domain. Phone clients showing only the display name are particularly exposed, which is why some organisations tag external mail with a visible warning.

So the honest summary: these three make domain spoofing substantially harder, which removes one large category of phishing. They leave look-alike domains, compromised accounts and display-name abuse, which is why the procedural and multi-factor defences of the previous chapter remain necessary.

A worked example

An assessor reviews a company's email authentication.

Recommendations in order: fix the SPF lookup overflow and remove stale entries; enable DKIM on every sending system; add a DMARC reporting address and analyse for several weeks; progress none to quarantine to reject; register or monitor the obvious look-alike domains; and tag external mail visibly, since authentication cannot address display-name abuse.

The finding that matters most is the combination of the first and fourth rows: the company believed it had email authentication, and in practice its SPF was erroring and its policy was doing nothing. Publishing the records is not the same as being protected, and the reports are what tell you which you have.

What beginners get wrong

• Thinking SPF alone stops spoofing. It authenticates the envelope sender, which the user never sees. Without DMARC alignment, the visible From can still be forged.
• Not knowing there are two From addresses. Alignment cannot be understood without it, and it is the examinable core of DMARC.
• Leaving DMARC at p=none indefinitely. It reports and protects nothing; the domain remains spoofable.
• Enforcing before reading reports. This blocks legitimate senders nobody had catalogued and gets the policy rolled back.
• Believing DMARC stops look-alike domains. It governs only your domain; an attacker's own domain can pass its own checks.
• Letting the SPF record grow past the lookup limit. It then fails for everyone, and it is a frequent real finding.
• Assuming a passing message is trustworthy. Authentication proves authorisation, not intent.

Quick revision

• Two sender addresses: the envelope sender (routing, invisible) and the header From (displayed, trusted). SPF checks the first; DMARC requires alignment with the second.
• SPF: a TXT record of authorised sending hosts. Breaks on forwarding; capped at ten DNS lookups, and exceeding it makes it fail entirely.
• DKIM: a cryptographic signature over headers and body, public key in DNS at a selector; survives forwarding; use 2048-bit keys and rotate.
• DMARC: requires SPF or DKIM to pass and align with the visible From; sets policy none (monitor), quarantine, or reject; provides aggregate reports.
• Deployment order: SPF, DKIM, DMARC at none, read reports and fix senders, then quarantine, then reject.
• Limits: they do not stop look-alike domains, compromised accounts, or display-name abuse, and they prove authorisation rather than honesty.

Test yourself

1. What are the two sender addresses in an email, and why does the distinction matter?

The envelope sender, used for routing and bounces and never shown to the user, and the header From, which the mail client displays. It matters because SPF authenticates the envelope sender, so an attacker can pass SPF for a domain they control while displaying a victim's domain; DMARC's alignment requirement is what closes that gap.

1. What does DMARC add that SPF and DKIM do not provide on their own?

Alignment, requiring that a passing SPF or DKIM result be for a domain matching the visible From address; a policy telling receivers whether to do nothing, quarantine or reject failing mail; and aggregate reporting, which reveals every system sending as the domain and makes safe enforcement possible.

1. Why does SPF break on forwarding, and how does DMARC accommodate legitimate forwarded mail?

Because a forwarding server relays the message from an address not listed in the original domain's SPF record, so the SPF check fails. DMARC passes if either SPF or DKIM passes and aligns, and DKIM signatures are attached to the message and usually survive forwarding, so forwarded mail can still pass.

1. Why is a DMARC policy of p=none a finding rather than a protection?

Because it instructs receivers to take no action on messages that fail authentication, so forged mail claiming the domain is still delivered. The organisation appears protected by publishing a record while remaining spoofable, and an attacker can read the policy and conclude that spoofing will work.

1. Name three things email authentication does not defend against.

Look-alike domains, since the attacker sends from a domain they own and can pass its own SPF, DKIM and DMARC; compromised genuine accounts, whose mail is properly authorised; and display-name abuse, where a trusted name is shown while the address belongs to an unrelated authenticated domain.

Addresses and ports: the building and the doors

An IP address identifies a host. A port identifies which service on that host, a 16-bit number, so 0 to 65535.

The analogy that holds: the address is the building, the port is the door. A packet needs both, and a scanner's question is precisely "which doors are open?"

Ranges to know:

• 0 to 1023, well-known ports, conventionally assigned to standard services and on many systems requiring privilege to bind.
• 1024 to 49151, registered ports, used by particular applications.
• 49152 to 65535, dynamic or ephemeral ports, used as the source port for outgoing connections.

That last group explains something students find confusing: every connection has two ports, a source and a destination. Your browser connecting to a web server uses destination port 443 and some arbitrary high source port, and the server's reply is addressed back to that source port. A firewall that permits return traffic must therefore track which conversations are in progress, which is the difference between a stateless and a stateful firewall and matters in the firewall chapter.

Ports worth recognising, because service identification begins with an educated guess:

A port number is a convention, not a rule: a web server can listen on 8080 or 7777, which is why version detection probes rather than assuming.

TCP against UDP

The two transport protocols behave differently, and the difference determines how each is scanned.

TCP is connection-oriented and reliable. Before data flows, the two ends perform a handshake; thereafter, sequence numbers order the bytes, acknowledgements confirm receipt, and lost segments are retransmitted. The protocol therefore has a defined response to every situation, including nonsensical ones, and that definiteness is what makes TCP scanning informative.

UDP is connectionless and unreliable. A datagram is sent; there is no handshake, no acknowledgement, no retransmission and no ordering. It suits things that prefer speed over perfection, DNS queries, time synchronisation, streaming media, and many network services.

The consequence for scanning, previewed here and taken up properly later: TCP gives an unambiguous answer (a SYN gets SYN/ACK if open or RST if closed), whereas UDP usually gives silence when open, since a service that receives a datagram it does not understand may simply ignore it. Silence is also what a firewall produces. So UDP scanning is slow, ambiguous and frequently skipped, which is exactly why services that live on UDP are often less examined and worth a tester's attention.

The TCP flags

Six control bits in the TCP header. Every scan type in the next chapters is a different combination of them, so learn what each means.

Two of these do nearly all the work in scanning:

SYN is the only flag that opens a connection, so it is how a scanner asks "is anyone there?"

RST is the protocol's way of saying "no". A closed port answers with RST. A host receiving a packet for a connection it does not have answers with RST. Recognising that RST means refusal is most of what is needed to read a scan's results.

PSH and URG are not used for scanning logically; they appear in the XMAS scan simply because setting them alongside FIN produces a packet with several flags lit, which is where the name comes from.

Two more fields matter later:

• The sequence number orders bytes and is what an attacker attempting session prediction would need to guess, which appears in the session-hijacking chapter.
• The window size, along with the IP header's TTL and other defaults, varies between operating systems, and the pattern of those defaults is what operating-system fingerprinting reads.

ICMP, the third protocol a scanner meets

ICMP is not a transport protocol; it carries control and error messages for IP. A scanner meets it constantly:

• Echo request and reply are ping, the simplest host-discovery method.
• Destination unreachable messages report problems, and the code matters. Port unreachable is the signal that a UDP port is closed, and is the only positive information a UDP scan usually gets. Administratively prohibited indicates a firewall is rejecting rather than silently dropping, which the firewall-detection chapter uses.
• Time exceeded is what makes traceroute work, by sending packets with increasing TTL and noting which router reports the expiry.

Many networks block inbound ICMP, which is why "it does not respond to ping" does not mean "it is not there", a point the host-discovery chapter develops.

A worked example: reading one exchange

A scanner sends a TCP packet to 203.0.113.10 port 22 with only the SYN flag set, from source port 51344.

What is in the packet, layer by layer: an Ethernet frame addressed to the local router's MAC; an IP header with source and destination addresses and a TTL; a TCP header with source port 51344, destination port 22, an initial sequence number, and the SYN flag set alone.

What the rules force, depending on the target's state:

Four possible outcomes, each forced by the specification rather than chosen by the target, and each telling the scanner something different. That table is port scanning in miniature, and the next chapter builds every scan type from it.

What beginners get wrong

• Confusing an address with a port. The address selects the host, the port selects the service on it. Both are needed and they come from different layers.
• Forgetting the source port. Every connection has two ports; the ephemeral source port is why stateful firewalls must track conversations.
• Assuming a port number identifies the service. It is a convention; services can listen anywhere, which is why version detection probes.
• Expecting UDP to behave like TCP. There is no handshake, so an open UDP port usually says nothing, and silence is ambiguous between open and filtered.
• Reading no reply as "the host is down". Many networks drop ICMP and unsolicited packets; absence of a reply is absence of information.
• Treating RST as an error. It is the protocol's normal way of refusing, and it is the most informative response a scanner receives.

Quick revision

• Layers: application (banners and versions), transport (TCP/UDP and ports, where scanning happens), internet (IP addresses, TTL, best-effort), link (MAC, ARP, local only).
• Address selects the host, port selects the service (0 to 65535: well-known 0 to 1023, registered to 49151, ephemeral above, used as source ports).
• TCP: connection-oriented, reliable, handshake and sequence numbers, and a defined response to every situation, which is what makes scanning informative. UDP: connectionless and unreliable, so an open port usually stays silent and results are ambiguous.
• Flags: SYN (open a connection), ACK (acknowledges), FIN (orderly close), RST (refusal, the key signal), PSH and URG (delivery hints, used in XMAS only to light several flags).
• ICMP carries control and errors: echo for ping, port unreachable as the only positive UDP signal, administratively prohibited revealing a rejecting firewall, time exceeded for traceroute. Inbound ICMP is often blocked.
• One SYN yields four outcomes: SYN/ACK (open), RST (closed), silence (filtered), ICMP prohibited (filtered, firewall confirmed).

Test yourself

1. Distinguish an IP address from a port, and say which layer each belongs to.

An IP address identifies a host and belongs to the internet layer; a port is a 16-bit number identifying the service within that host and belongs to the transport layer. A packet needs both to reach a specific service on a specific machine.

1. Why does TCP give a scanner clearer information than UDP?

Because TCP is connection-oriented with a specification that defines a response to every situation, including malformed or out-of-sequence packets: an open port answers a SYN with SYN/ACK and a closed port with RST. UDP is connectionless, so an open port commonly returns nothing at all, making silence ambiguous between open and filtered.

1. Name the six TCP flags and say which two carry most of the meaning in scanning.

SYN, ACK, FIN, RST, PSH and URG. SYN carries most meaning because it is the only flag that opens a connection and so is how a scanner asks the question; RST carries the rest because it is the protocol's refusal, returned by a closed port or for a connection that does not exist.

1. What are the four possible outcomes of sending a bare SYN to a port, and what does each mean?

SYN/ACK means a service is listening, so the port is open; RST means the host is alive but nothing is listening, so the port is closed; no reply means a firewall silently dropped the packet, so the port is filtered and its state unknown; an ICMP administratively-prohibited message means a firewall rejected it, so the port is filtered and a firewall is confirmed.

1. Why does "no response to ping" not establish that a host is absent?

Because many networks block inbound ICMP echo requests at the perimeter, so a live, fully functioning host may simply never answer. Absence of a reply is absence of information, which is why host discovery uses TCP and UDP probes as well as ICMP.

Why the SYN and the ACK can share packet 2 is worth stating: they are independent bits in the same header, so the server acknowledges and initiates simultaneously. That is why the exchange is three packets and not four.

The other outcome: RST

If nothing is listening on the port, the standard requires the host to reject the attempt, and it does so by replying with RST (usually RST with ACK). It says: there is nothing here, do not continue.

And that is the whole basis of port scanning:

Two different, unambiguous, mandatory responses. The target is not choosing to inform the scanner; the specification requires it to answer this way so that ordinary connections work. A host that stopped answering would break every legitimate client.

Why that is enough

Everything else follows from those two lines.

To find open ports, send a SYN to each port and record which reply with SYN/ACK. That is a SYN scan, and it is the reason port scanning is fast and reliable rather than a matter of guesswork.

To avoid completing connections, send the SYN, read the reply, and if it is SYN/ACK send RST instead of the final ACK. The connection never reaches ESTABLISHED, so the application on the target may never be told a connection occurred, and historically it was not logged by the service. This is the half-open or SYN scan, and its "stealth" is exactly this and nothing more.

To fingerprint through firewalls, note that a third response exists that the table does not list: no reply at all. That cannot happen in a correctly functioning direct conversation, because the standard requires SYN/ACK or RST. So silence means something in between interfered, which is what "filtered" means and what the firewall-detection chapter reads.

To scan without opening connections at all, exploit a different rule. The specification also says what a host must do with a segment that arrives for a connection that does not exist: a closed port must reply RST, and an open port must ignore it. That single asymmetry is what FIN, NULL and XMAS scans use, and it is why those scans can probe without ever sending a SYN.

The examinable point: a scanner is not breaking anything. It is asking questions the standard obliges the target to answer, or sending packets the standard specifies a response to. Port scanning is a consequence of TCP being well specified.

The half-open state and what it costs the target

Dwell on packet 2 for a moment, because it matters twice more in this book.

When the server sends SYN/ACK it must remember the half-formed connection: the client's address and port, the sequence numbers, the options negotiated. It holds that in a finite structure, often called the backlog, and waits for the third packet. If the ACK never arrives, the entry sits there until a timeout expires, and the server may retransmit the SYN/ACK several times first.

Two consequences:

• A SYN scan leaves the target holding half-open entries until they time out. A scan of many ports is therefore not free for the target, even though the scanner has done nothing wrong.
• A deliberate flood of SYNs that are never completed fills the backlog, so genuine clients cannot connect. That is the SYN flood, the protocol denial-of-service attack of Module 2, and it is the handshake's cost turned into a weapon. The defence, SYN cookies, works by refusing to allocate the state at all until a valid ACK proves the client is real.

Closing a connection, briefly

For completeness, since FIN appears in the scan types. An orderly close is four packets, because each direction closes independently: one side sends FIN, the other ACKs it, then the other side sends its own FIN, which is ACKed. Either side may also abort at any time with RST, which is immediate and unacknowledged.

The point that matters for scanning: FIN is meaningful only within an existing connection. Sending a bare FIN to a port with no connection is nonsense, which is precisely why the standard's rule for nonsense packets is what the FIN scan exploits.

A worked example

A tester, with authorisation, probes three ports on one host and reads the exchanges.

Port 443. Sends SYN. Receives SYN/ACK. Concludes open, and immediately sends RST to tear down the half-open connection rather than completing it. The target briefly held a half-open entry and its web service was probably never informed.

Port 25. Sends SYN. Receives RST/ACK. Concludes closed: the host is alive and reachable, and no mail service is listening. Note that this is still useful, because it proves the host exists.

Port 3306. Sends SYN. Receives nothing, twice, after retransmission. Concludes filtered: since the standard requires one of the two answers, silence means an intermediate device dropped the packet. Whether a database is behind it is unknown.

Three ports, three distinct conclusions, all derived from two lines of the specification. And one further observation for the report: the mixture is itself informative. A host that returns RST on some ports and silence on others has a firewall with per-port rules; a host that returns silence on everything except two ports has a default-deny firewall, which is the reasoning the firewall chapter formalises.

What beginners get wrong

• Thinking the handshake is four packets. It is three, because SYN and ACK are independent flags that can be set in the same segment.
• Believing a half-open scan is undetectable. It avoids completing the connection, so the application may not log it, but the pattern of many SYNs without ACKs is exactly what a network sensor looks for.
• Forgetting that a closed port is informative. RST proves the host is alive, which silence does not.
• Treating no reply as "closed". Closed has a specific signal, RST. Silence means filtered, and the state is unknown.
• Thinking scanning exploits a flaw. It uses required behaviour; a host that refused to answer would break normal connectivity.
• Missing that half-open connections cost the target resources. That cost is what the SYN flood weaponises.

Quick revision

• Three packets: SYN (client, sequence x), SYN/ACK (server, acknowledges x + 1, sends its own y), ACK (client, acknowledges y + 1). States: SYN-SENT, SYN-RECEIVED (half-open), ESTABLISHED.
• The handshake confirms willingness, exchanges initial sequence numbers, and proves the return path works.
• The basis of scanning: a SYN to an open port must be answered SYN/ACK; to a closed port, RST. Both are mandatory, so the target cannot decline to inform the scanner.
• A third outcome, silence, is impossible in a direct exchange and therefore means an intermediate device dropped the packet: filtered.
• A second rule, that a segment for a non-existent connection gets RST from a closed port and is ignored by an open one, is what FIN, NULL and XMAS scans use.
• The server allocates state at SYN-RECEIVED; scanning leaves half-open entries, and flooding them deliberately is the SYN flood, answered by SYN cookies.
• Closing is four packets (FIN and ACK each way), or an immediate RST. FIN is meaningful only inside an existing connection.

Test yourself

1. Describe the three-way handshake, naming the flags and what each packet accomplishes.

The client sends a segment with SYN set and its initial sequence number; the server, if a service is listening, replies with SYN and ACK together, acknowledging the client's number and supplying its own; the client replies with ACK acknowledging the server's number, after which the connection is established. It confirms mutual willingness, exchanges initial sequence numbers and proves the return path works.

1. Why is port scanning possible at all, and why is it not an exploitation of a flaw?

Because the TCP specification requires a host to answer a SYN with SYN/ACK when a service is listening and with RST when none is, so the response distinguishes open from closed. This is required behaviour that makes ordinary connections work; a host that refused to answer would be unable to serve legitimate clients.

1. What does a complete absence of response indicate, and why can it not occur in a direct exchange?

It indicates the port is filtered, meaning an intermediate device such as a firewall silently discarded the packet, so the port's real state is unknown. It cannot occur directly because the standard requires either SYN/ACK or RST, so silence proves something intervened.

1. What is the half-open state, what does it cost the target, and which attack weaponises it?

After sending SYN/ACK the server has allocated connection state and is waiting for the final ACK, which is the half-open or SYN-RECEIVED state. It consumes an entry in a finite backlog until it times out. Deliberately flooding a target with SYNs that are never completed fills that backlog so genuine clients cannot connect, which is the SYN flood.

1. Why can a bare FIN sent to a port be used for scanning?

Because FIN is meaningful only within an existing connection, so a bare FIN refers to a connection that does not exist, and the specification dictates the response to such a segment: a closed port replies RST while an open port ignores it. That asymmetry lets a scanner infer state without ever sending a SYN.

• Timestamp request, which asks a host for its clock. Some hosts answer it while echo is blocked.
• Address mask request, older and rarely answered, but occasionally revealing.
• Non-echo replies as evidence. Sending a packet to a host and receiving any ICMP error, such as destination unreachable, proves something is there to generate it, even though it is not the reply you asked for.

TCP probes: asking the handshake instead

Since ICMP is often blocked but services must be reachable to be useful, the reliable method is to use TCP, and the previous chapter supplies the logic.

TCP SYN probe. Send a SYN to a commonly open port (443, 80, 22, 445). By the handshake rules, an open port answers SYN/ACK and a closed one answers RST, and either response proves the host is alive. That is the key insight: for discovery you do not care which answer you get, only that you got one. A "closed" reply is a successful discovery.

TCP ACK probe. Send a bare ACK. A host with no matching connection must reply RST, so an RST proves it is alive. This is useful where a firewall blocks incoming SYNs but permits packets that look like established traffic, which stateless filters commonly do.

Choosing which ports to probe matters. Probing 443 and 80 finds web servers; adding 22 finds Linux hosts and 445 finds Windows hosts; adding 3389 finds machines offering remote desktop. A sweep using several well-chosen ports finds substantially more than one using a single port.

ARP: the probe that cannot be refused

On the local segment, there is a method no host firewall can ignore, and it is the most reliable discovery technique that exists.

IP is a layer above the link, so before one machine on a local network can send an IP packet to another it must learn the destination's MAC address. It does this with an ARP request, broadcast to the whole segment: "who has this IP address?" The owner must reply, because if it does not, no traffic can reach it at all.

Consequently a host on the same segment cannot hide from ARP while remaining usable. A host firewall can drop ICMP and every TCP probe and still must answer ARP, because ARP is how it receives anything.

An ARP sweep therefore finds every live host on the local network, quickly and definitively. Two limits: it works only on the local segment, because ARP does not cross routers, so it is an internal-testing technique; and it is noisy in the sense that it broadcasts, though ordinary network operation produces ARP traffic constantly.

The security reading, which points forward: because ARP has no authentication and hosts accept replies freely, the same protocol that makes discovery reliable also makes ARP poisoning possible, which is the man-in-the-middle chapter.

UDP probes

Sending a UDP datagram to a closed port normally produces an ICMP port-unreachable message, which proves the host is alive. Sending to an open port usually produces nothing, or a service-specific reply.

It is slower and less reliable than TCP discovery because hosts commonly rate-limit ICMP error generation, so responses are throttled. It is worth including for hosts that run only UDP services, and a probe to a well-known UDP port such as 53 or 161 sometimes elicits a service reply that both proves the host and identifies the service.

Other discovery routes

Reverse DNS. Look up the PTR record for each address in the range. This touches only DNS servers, not the hosts, so it is quiet, and it often returns descriptive names that reveal purpose even for hosts that never answer a probe.

Broadcast and multicast responses. On a local network, hosts announce themselves through discovery protocols for printers, file sharing and media devices, and simply listening for a while identifies many without sending anything.

Routing information. ICMP time-exceeded responses from traceroute reveal intermediate routers, which are themselves hosts and often forgotten in inventories.

Reading the results honestly

The output of discovery is a list of addresses in three states:

The middle row is where care is needed. A report that says "only 40 of 1,024 addresses are in use" is making a claim the evidence does not support; the defensible statement is "40 responded to the probes used; the remainder did not respond and may be absent, firewalled, or powered off". The distinction matters because a heavily firewalled but live host is exactly the kind of thing an assessment must not miss.

A worked example

Vikram is engaged to assess an internal network segment, and separately the organisation's external range.

Externally, against the allocated range of 256 addresses:

• ICMP echo to all 256: no replies at all. The perimeter blocks ping.
• TCP SYN to 443 and 80: nine hosts answer, seven with SYN/ACK and two with RST. All nine are alive; the two returning RST have no web service but exist.
• TCP SYN to 22, 445 and 3389: two further hosts answer, one of which offers remote desktop, a finding in itself.
• Reverse DNS across the range: names for fourteen addresses, including three that answered nothing. Those three are recorded as "named in DNS, unresponsive to probes", which is a finding worth following up because a name usually implies a host.
• Result: eleven confirmed live, three suspected, 242 unknown.

Internally, on the local segment:

• ARP sweep: sixty-three hosts, immediately and unambiguously, including nineteen that answer no ICMP and no TCP probe because their host firewalls drop everything. They cannot refuse ARP.

The contrast is the lesson. Externally he must infer from several probes and accept uncertainty; internally ARP gives a definitive answer. And the nineteen firewalled hosts that ARP found would have been invisible to every other method, which is why an internal assessment that relies on ping sweeps understates the estate badly.

What beginners get wrong

• Treating no reply as "no host". It means no reply. Firewalls, host firewalls and powered-off machines all look identical from outside.
• Relying on ping alone. Inbound ICMP is widely blocked; a ping sweep on a firewalled network finds almost nothing.
• Forgetting that RST proves life. For discovery, a closed port is as good as an open one; any response establishes the host exists.
• Skipping ARP on internal tests. It is the only probe a usable host cannot refuse, and it finds firewalled machines nothing else sees.
• Expecting ARP to work remotely. It does not cross routers; it is a local-segment technique only.
• Scanning every port on every address. Discovery exists to avoid wasting the overwhelming majority of the work on empty space.
• Overstating the conclusion in the report. Say what responded to what, not how many hosts exist.

Quick revision

• Discovery precedes port scanning to avoid spending the expensive scan on empty addresses, and it converts an allocated range into the real scope.
• ICMP echo (ping) is simplest and widely blocked; no reply means no reply, not absence. Timestamp and address-mask requests, and any ICMP error received, are alternative evidence.
• TCP SYN probes to common ports are the reliable external method: SYN/ACK or RST both prove the host is alive. TCP ACK probes elicit RST and pass some stateless filters.
• ARP on the local segment cannot be refused by a usable host, so an ARP sweep is definitive internally; it does not cross routers. The same lack of authentication enables ARP poisoning later.
• UDP probes rely on ICMP port-unreachable and are slowed by ICMP rate limiting.
• Quiet routes: reverse DNS across the range, listening for local discovery-protocol broadcasts, and routers revealed by traceroute.
• Report three states: up (with the evidence), no response (unknown), and unreachable. Do not claim absence.

Test yourself

1. Why is host discovery performed before port scanning?

Because scanning every port on every address in a range spends the great majority of the effort on unused addresses, and on firewalled networks each probe to an empty address costs a full timeout. Discovery filters the range down to the addresses worth scanning, and for an assessor it converts an allocated range into the engagement's real scope.

1. Why does a TCP SYN probe make a better discovery method than ping, and why does a closed port still count as a success?

Because inbound ICMP is widely blocked at perimeters while services must remain reachable, so TCP probes to common ports get through where ping does not. A closed port answers RST, and since the purpose of discovery is only to establish that something is there, any response, SYN/ACK or RST, proves the host is alive.

1. Why can a host on the same network segment not hide from an ARP sweep?

Because ARP is how other machines learn the MAC address needed to deliver any IP traffic to it. A host that did not answer ARP requests could not receive traffic at all, so any usable host must reply, regardless of how restrictive its firewall is for ICMP and TCP.

1. What are the limits of ARP-based discovery?

It works only on the local segment, because ARP is a link-layer protocol and does not cross routers, so it is available for internal testing and not for assessing a remote network.

1. How should an assessor report addresses that responded to nothing?

As having produced no response to the probes used, with the probes named, rather than as absent hosts. A firewalled but live host, a powered-off machine and an unallocated address are indistinguishable from outside, and a live host that silently drops all probes is precisely what an assessment must not record as nonexistent.

Where the "stealth" claim is true and where it is not. True: the application layer commonly records nothing, because no connection was established. Not true: the network sees a burst of SYNs from one source across many ports with no completing ACKs, which is the most recognisable pattern in intrusion detection. Calling it a stealth scan is a statement about application logs only, and the next-but-one chapter develops this.

Its cost to the target. Each probe to an open port leaves a half-open entry in the backlog until it times out, so a wide SYN scan consumes resources on the target even though nothing malicious was intended.

Privilege. It constructs raw packets, so it normally requires administrative rights on the scanning machine.

FIN, NULL and XMAS: the inverse scans

These three share one idea and differ only in which flags they set. All rely on rule 2.

What each sends: