Certified Ethical Hacker guideStudy & preparation

CEH System Hacking: Vulnerabilities, Access, and Malware

How vulnerability analysis, system hacking, and malware threats connect on CEH, with original scenarios for suspected flaws, privilege escalation, and malware classification.

Short answer

CEH Exam Blueprint v5.0 assigns 19 questions to System Hacking Phases and Attack Techniques: six for Vulnerability Analysis, six for System Hacking, and seven for Malware Threats. Connect them by distinguishing a possible weakness, demonstrated access or increased privilege, and the behavior of malicious software. A scan finding does not by itself prove exploitation, and malware categories can overlap in blended attacks.

How are the three system-hacking subdomains connected?

EC-Council's CEH Exam Blueprint v5.0 assigns 19 questions to System Hacking Phases and Attack Techniques, covering vulnerability analysis, system hacking, and malware threats. Study the connection by separating what might be vulnerable, what access has actually been demonstrated, and what malicious software does.

The blueprint, checked November 3, 2026, divides this domain into three parts:

  1. Vulnerability Analysis: six questions. Start with the distinction between identifying a possible flaw and validating it.
  2. System Hacking: six questions. Its headings include gaining access, password cracking, exploitation, escalating privileges, maintaining access, and persistence.
  3. Malware Threats: seven questions. Learn the characteristics that distinguish malicious programs and their behavior.

These are related areas, but the list is not a claim that every attack follows one sequence. A scenario can describe a suspected vulnerability without any successful exploitation. Another can begin after access already exists and ask about an increase in privilege.

For the broader allocation, use the CEH blueprint and nine-domain guide. Here, keep your notes centered on three questions: what is suspected, what is demonstrated, and what behavior is described?

Does a vulnerability scan prove exploitation?

No. NIST SP 800-115 distinguishes identifying possible vulnerabilities from validating them through authorized testing. Automated findings can include false positives. A scanner's report is evidence of what the scanner detected; it is not automatically evidence that someone gained access.

Consider a fictional authorized lab. A scan flags a service as potentially vulnerable, but the exercise gives no validation result. You can identify a suspected weakness. You cannot conclude that the weakness was successfully exploited or that administrator access exists.

Now change one clue: the exercise states that an authorized test successfully used the weakness to obtain limited access. The conclusion changes because the outcome is supplied. Exploitation has been demonstrated, but the access is still limited. Neither the scan label nor the successful test establishes privileges beyond those described.

Use this short reading process:

  1. Identify the evidence: scan alert, validation result, or demonstrated action.
  2. State the narrowest conclusion it supports.
  3. Reject an answer that adds an outcome the scenario never provides.

If you confuse service discovery with vulnerability validation, revisit footprinting, scanning, and enumeration. NIST's assessment guide supplies stable conceptual distinctions here; its September 2008 publication date means it should not be treated as a current tool recommendation list.

For broader question practice, full CEH prep planned for launch includes 1,800 questions across nine domains.

How do gaining access and escalating privileges differ?

The key is the starting point. Gaining access establishes access; privilege escalation increases a level of access that already exists. NIST's assessment guidance supports that distinction, while the CEH blueprint lists both among the system-hacking topics.

In a fictional lab exercise, a tester first obtains access as an ordinary user. A later step gives that same tester administrator privileges. The first outcome demonstrates access. The second demonstrates an increase in privilege. Calling both outcomes merely “getting in” loses the distinction the scenario supplies.

For each scenario, write two brief notes:

  • Before: no demonstrated access, limited access, or an already privileged account.
  • After: the precise access or permissions the exercise says were obtained.

The blueprint also names maintaining access and persistence. Keep a separate study question for those headings: does the scenario concern retaining access over time? Do not select privilege escalation just because the account remains accessible; look for evidence that its privileges increased.

This is a way to interpret the supplied facts, not an instruction to attempt any technique. Keep practical exercises within the systems and actions authorized for your lab. Before moving on, explain the difference between initial access and increased privilege without naming a tool.

How can you distinguish a virus, worm, and Trojan?

Use the replication and disguise clues. NIST SP 800-83 Revision 1 provides the following classic distinctions:

  • Virus: replicates into host programs or data. The connection to a host is the decisive clue in a simple classification exercise.
  • Worm: a self-contained program that replicates and usually executes without user intervention. Look for self-contained replication rather than assuming every malicious file is a virus.
  • Trojan: appears benign but conceals a malicious purpose and does not self-replicate. A useful-looking program with hidden malicious behavior fits this distinction when the scenario supplies those facts.

Two other terms describe different behavior. A keylogger records keyboard use. A rootkit alters or hides host functionality. If the question asks what the program records or conceals, focus on that behavior instead of forcing the answer into the virus/worm/Trojan comparison.

These definitions come from the July 2013 NIST revision, checked November 3, 2026. They are useful for conceptual classification, not a ranking of today's most common threats. NIST also describes blended attacks, so the classic categories should not be treated as an exhaustive set of mutually exclusive labels for every real incident.

For terminology review, full CEH prep planned for launch includes 500 flashcards. In your own notes, pair each label with its decisive behavior rather than memorizing the name alone.

What clues matter in an original scenario?

The following teaching cases are original examples, not recalled exam questions. Each supplies the evidence needed for its answer.

Case 1: the unvalidated alert. An authorized scan flags a possible vulnerability. No follow-up test or evidence of access is provided. The supported conclusion is a suspected flaw. Successful exploitation, escalation, and malware installation are all unsupported additions.

Case 2: the changed permissions. A lab tester already has ordinary-user access. The exercise then explicitly states that the tester obtains administrator privileges. The decisive change is the privilege level, so privilege escalation is the supported answer. The scenario starts after initial access.

Case 3: the disguised program. A program presents itself as a useful utility, secretly records keyboard use, and does not self-replicate. Its benign appearance and concealed purpose support the Trojan classification; its recording behavior supports the keylogger description. Which answer fits depends on whether the question asks about disguise or function.

For each case, say why the closest alternative is unsupported. Then change one clue and reconsider the answer. For example, replacing “no follow-up test” in Case 1 with an explicitly successful authorized validation changes what you can conclude about exploitation. It still tells you nothing about a higher privilege level unless that result is also stated.

Try the 20 free CEH practice questions and apply the same evidence check to each scenario you encounter.

How should you review mistakes in this domain?

Review the distinction you missed before adding more terminology. Use three headings in your study notes: finding versus validation, access versus privilege, and malware behavior. Under each, write one sentence explaining your mistake and one original example that makes the distinction clear.

A useful next study session is to explain the three cases above without looking at their answers, then return to the relevant blueprint heading for anything still uncertain. Put that review into the free CEH study plan; use the CEH study schedule guide if you need to fit this domain into a wider preparation calendar.

Keep study planning and booking decisions separate. Before committing to an exam purchase, check the CEH cost and eligibility routes.

Once you can explain these distinctions, broaden your review beyond this domain: full CEH prep planned for launch includes a 125-question mock for broader practice. Use any misses to decide which concepts need another explanation and example.

<!-- Writer self-check, 2026-11-03: checked every factual claim against RESEARCH.md S01, S17, and S19; product claims against CONTEXT.md and exam.json. Original scenarios are labeled and supply their clues. Matched PLAN.md and TEMPLATE.md; checked intent uniqueness, direct answer, sources, SEO lengths, existing-guide links, both free tools, and three separated commercial links. No yearFocus is assigned to this PLAN entry. Independent editorial review remains required. -->

Trust the source

Official sources

Exam policies can change. Use these primary sources for the most current details.