Ethical Hacking Methods Best Practices

01Purpose and scope

This manual supports the course Ethical Hacking Methods. It describes how authorized security testers plan, carry out and report on attacks against systems they have been permitted to test, so that weaknesses are found and fixed before someone with harmful intent finds them.
The scope covers practical work on network services, web applications, wireless networks, and social engineering assessments at the level a working tester or systems administrator needs. It does not cover malware analysis, exploit development for novel vulnerabilities, or forensic investigation after a real breach, although testers often need to understand those areas.
The intended readers are junior testers, system administrators moving into security work, and developers who want to understand how attackers approach their code. Experienced staff may use this manual as a checklist of habits rather than a set of rules.
This guidance does not replace qualified professional judgment, approved procedures or required authorization. Computer misuse and unauthorized access laws differ by jurisdiction and change over time, so check the current authoritative source for your location and your employer's written policy before any test begins.

02Core principles

Authorization comes first. Every action needs a written grant from someone with the legal and organizational power to approve testing of the target. A verbal assurance from a project manager is not enough, and a grant that covers one subsidiary does not cover its parent company's systems.
Use the least intrusive method that answers the question. If a version banner or a configuration file settles whether a service is vulnerable, there is no need to run a heavy exploit against it. Lower impact tests also reduce the chance of an outage that disrupts business operations.
Prove, do not assume. A scanner result is a lead, not a finding. A finding is something you reproduced, documented, and can explain well enough that another tester could repeat it under the same conditions.
Limit the impact on people and data. Testers often gain access to sensitive records more easily than they expect. The goal is to demonstrate access with the smallest amount of real data touched, then stop.
Expect trade-offs. Thorough testing takes time and can strain fragile production systems. Faster testing with aggressive tools may miss subtle flaws or trigger alarms that consume the client's response team. Agree on the balance before the work starts instead of making it up during an engagement.

03Planning and preparation

Start with a rules of engagement document. It should name the systems in scope by address range, domain, application URL or account, list explicitly excluded systems, and record the agreed testing windows. It should also name a primary contact and an escalation contact who can halt testing at any hour, and state which techniques are permitted, such as credential guessing, phishing simulation, or denial of service testing, which is usually prohibited.
Check third-party dependencies early. Cloud platforms, managed hosting providers and software-as-a-service products often have their own testing policies, and some require advance notice or prohibit certain tests outright. Shared infrastructure can mean that testing one client's address affects another tenant, which is a scope problem and not just a technical detail.
Prepare your environment. Use a dedicated testing workstation with current tools such as Nmap for discovery, Burp Suite or similar proxies for web work, Wireshark for traffic inspection, and a framework such as Metasploit for controlled validation. Keep notes in an encrypted location, and record the hash or version of each tool so results can be reproduced.
Confirm that a rollback or recovery path exists before touching anything that changes state. If a test may modify a database, take a copy or obtain written agreement that the client will restore from backup. Plan a lab run against a similar system where possible, because many tools behave differently against production software.
Decide how credentials, test accounts and any discovered secrets will be handled. Test accounts should be created with clear names, given only the access they need, and removed at the end of the engagement. Discovered passwords should never be pasted into reports in plain text.

04Recommended workflow

1
: Confirm the scope in writing with the authorizing party. Read the rules of engagement against the list of targets you actually have, and flag any address or account that is unclear before you send a single packet.
2
: Perform passive reconnaissance. Gather information that does not touch the target directly, such as public DNS records, certificate transparency logs, job postings that reveal technology stacks, and documentation published by the client. Record sources so you can explain later where each fact came from.
3
: Run active discovery within the agreed rate limits. Use Nmap or a comparable tool to identify live hosts, open ports and service versions. Start with conservative timing options, because aggressive scanning can crash older devices and will generate noise that makes later monitoring harder.
4
: Enumerate services and identify candidate weaknesses. For web applications, map the site, note input points, authentication flows and session handling. For network services, check default configurations, anonymous access, outdated software versions and weak authentication. Treat each candidate as a hypothesis to test.
5
: Validate findings with controlled tests. Reproduce the weakness using the minimum payload that shows it exists. For a suspected injection flaw, a harmless query that returns a predictable result is usually enough. Capture the request, response and timestamp for each validation.
6
: Demonstrate impact without causing harm. If you gain access to a system, show that access with a benign artifact such as a file you create and name for the engagement, then stop. Do not read personal records, change production data, or pivot further than the agreed scope permits unless the rules explicitly allow it.
7
: Clean up. Remove test accounts, uploaded tools, scheduled tasks, modified configuration files and temporary backdoors. Record each change you made so the client can verify that the environment has been returned to its prior state.
8
: Preserve evidence and prepare the report. Store screenshots, logs and tool output in a restricted location with an agreed retention period. Write up each validated finding while the details are fresh, including the exact conditions under which it was reproduced.

05Quality checks, risk controls and compliance

Before a finding enters the report, have a second person repeat the reproduction steps where practical. Track how many of your candidate findings were rejected during validation. A high rejection rate suggests that you are relying too heavily on scanner output or that your methods need tightening.
Rate severity consistently. Many teams use the Common Vulnerability Scoring System as a starting point, then adjust for the client's environment, such as whether a flaw is exposed to the internet or sits behind an authenticated portal. Write down the reasoning for any adjustment, because readers will ask why a score differs from a public advisory.
Build stop conditions into the work. Halt testing and notify the escalation contact if a service degrades, if you encounter evidence of a live attack by a third party, if you find data that suggests a crime, or if you reach a system outside scope. Those situations are reporting events, not opportunities to keep testing quietly.
Handle data with care. Redact personal information in screenshots, encrypt evidence at rest, avoid copying bulk records to your own devices, and delete working copies when the engagement closes. Privacy and breach notification duties may apply to data you touch, and those duties depend on the jurisdiction and the data type.
Compliance requirements vary by sector and location. Financial, healthcare, government and payment card environments may impose specific testing requirements or reporting obligations. Confirm these with the client's compliance staff and the current authoritative sources, and do not assume a general methodology satisfies a specific regulation.
Where the work touches regulated or high-risk systems, such as medical devices, industrial control systems, or systems that affect public safety, this guidance is not a substitute for specialist training, approved procedures or the authorization that those environments require. Coordinate with the system owner before testing begins.

06Collaboration and documentation

Keep one point of contact on the client side for status updates, scope questions and urgent issues. Send brief written updates at agreed intervals, even when nothing notable has happened, so the client is never surprised by traffic in their logs. A short message that says testing is paused for a specific reason is better than silence.
Maintain a running activity log with timestamps, source addresses, tools used, commands or requests sent, and the person who performed each action. This log is the main way to separate your activity from a real intrusion during incident review, so it should be complete enough that someone unfamiliar with the engagement can follow it.
Structure the final report for two audiences. The executive summary should describe overall risk, major themes and the most urgent actions in plain language. The technical section should give each finding a title, affected asset, severity, reproduction steps, evidence references, business impact and recommended remediation with enough detail for a developer to act on it.
Recommend fixes that the client can carry out. Saying use parameterized queries is useful, but naming the framework function, the affected code path if known, and a test to confirm the fix is more useful. Where a fix is not immediate, suggest compensating controls such as web application firewall rules, network segmentation or added monitoring, and label them as temporary.
Arrange a debrief after delivery and offer retesting of fixed findings. Retesting confirms that remediation worked, and it gives the client a documented basis for closing items. Be clear about what the retest covers, since a fixed finding does not mean the entire system is secure.

07Measures and continuous improvement

Track a small set of indicators. Useful ones include the share of candidate findings confirmed after validation, the time from discovery to a reproduced finding, the number of scope clarification requests raised during an engagement, the share of findings retested as closed, and the number of incidents caused by testing activity. Compare these across engagements rather than against an external benchmark you cannot verify.
Hold a short retrospective after each engagement. Ask what slowed validation, which tools produced noise that wasted time, where the scope document was unclear, and whether any step created more risk than it was worth. Record the answers in a shared lessons file that the team reviews before the next project.
Be wary of metrics that reward volume. A team that is measured by the number of findings may report low-value issues to look productive, and a team measured by the number of tests may run more scans without thinking. Pair every count with a measure of quality, such as how many findings the client actually fixed.
Update your methods as technology changes. New frameworks, authentication schemes and cloud services create new failure modes. Maintain a personal or team reference of tested techniques, the conditions under which they worked, and the ones that caused problems, so institutional knowledge does not depend on one person's memory.

08Common mistakes and how to prevent them

Testing an address that was never in scope is the most damaging error. It usually happens when a hostname resolves to a shared host or when a client's scope list was copied from an old document. Resolve targets to addresses before testing, confirm ownership where possible, and stop when ownership is unclear.
Running full-speed scanners against fragile systems causes outages that damage trust more than any finding can repair. Use reduced concurrency, longer timeouts and off-peak windows for older equipment, and ask the client which systems are known to be sensitive.
Reporting raw scanner output without validation wastes the client's time and hurts the tester's credibility. Every item in the report should carry evidence that you reproduced it, or be clearly labeled as an unverified observation.
Leaving test accounts, uploaded tools or open listeners behind is a serious problem that can become a real vulnerability after the engagement ends. Build the cleanup step into the schedule, and verify it with the client before closing the work.
Writing vague remediation advice such as improve security makes findings hard to act on. Name the setting, code path, configuration or policy change needed, and explain how to confirm it worked.
Storing sensitive material carelessly is common under time pressure. Keep credentials and personal data out of notes, use encrypted storage, and delete working files according to the retention plan rather than leaving them on laptops indefinitely.

09Practical checklist

Obtain written authorization that names every system, account and technique in scope.
Confirm testing windows, escalation contacts and stop conditions before any active testing.
Check cloud, hosting and third-party provider policies that apply to the targets.
Prepare a clean tool environment and a recovery path for any system that may change state.
Validate each candidate finding with a controlled, reproducible test and captured evidence.
Stop and report when scope is unclear, a live third-party attack appears, or sensitive data is exposed.
Redact personal data, encrypt evidence and remove test accounts and tools at the end of the work.
Keep a timestamped activity log that a reviewer could follow without asking you questions.
Write each finding with reproduction steps, severity reasoning and specific remediation advice.
Arrange retesting of fixed findings and record the results for the client.

★Learning sources

Micro Degree: Ethical Hacking Methods
Micro Degree: Data Analytics Applications
Micro Degree: Azure Cloud Fundamentals
Micro Degree: Google Cloud Platform Basics

?Frequently asked questions

Do I need written permission before running any test, even a simple port scan?

Yes. A port scan against a system you do not have permission to test can still break computer misuse laws in many places and can cause real operational problems for the owner. Obtain a written grant that names the targets, and check the current authoritative source for your jurisdiction if you are unsure how the law applies.

How do I decide when to stop exploiting a vulnerability?

Stop once you have shown that the weakness is real and have captured enough evidence for the client to understand its impact. Continuing past that point usually adds risk without adding value, and it can expose more personal data than the engagement requires. If the rules allow further demonstration, take only the step that was agreed.

What should I do if I find evidence that a real attacker is already inside the system?

Stop your active testing against the affected system and notify the escalation contact immediately, using the channel named in the rules of engagement. Do not attempt to investigate or remove the attacker on your own unless the agreement explicitly covers incident response. Preserve your own activity log so it can be separated from the attacker's activity.

Is this course enough to start work on regulated systems such as medical devices or payment environments?

No. Regulated and safety-related environments require specialist training, approved procedures and specific authorization from the system owner and sometimes from a regulator. This manual gives general methods, but it does not replace qualified professional judgment or the rules that govern those systems.