10 Tips for PNPT

This post contains general PNPT preparation advice only. It does not include exam-specific machines, targets, credentials, screenshots, exploit chains, report content, or private exam details.

I completed the technical portion of the PNPT exam in less than two days, and one thing became very clear during the process:

Technical skill matters.

But methodology matters more.

PNPT is not about memorizing a magic command or throwing random exploits at a network until something works. It is a hands-on penetration testing exam that rewards people who can think through an environment logically, document what they find, and explain the business and technical impact of their attack path.

There will naturally be some overlap with general penetration testing advice: enumerate carefully, take notes, pivot when needed, and do not underestimate the report.

But PNPT has its own feel.

Where CPTS pushed me hard on depth, tooling, and methodical technical execution, PNPT felt more like proving I could handle a realistic engagement from start to finish.

These are the ten biggest lessons I would give anyone preparing for PNPT.

No spoilers. No exam details. Just the things that made the biggest difference.

1. Treat It Like a Real Engagement, Not a CTF

This is the biggest mindset shift.

Do not approach PNPT like you are chasing flags.

Approach it like a client handed you a scope and asked you to perform a penetration test.

That means your job is not just:

Find vulnerability -> exploit vulnerability -> move on

Your job is closer to:

Understand the environment -> identify exposure -> validate risk -> expand access -> document impact -> explain remediation

That difference matters.

In a CTF mindset, it is easy to become obsessed with finding “the intended trick.”

In an engagement mindset, you ask better questions:

What is externally exposed?
What does this organization appear to rely on?
What authentication paths exist?
What systems trust each other?
What information did I gain?
What access did that information create?
What can I prove safely and clearly?

That is where PNPT clicked for me.

Once I stopped thinking like I was solving isolated boxes and started thinking like I was assessing a network, the process became much more natural.

You are not just looking for shells.

You are building an attack narrative.

2. Enumerate With Intent

Everyone says enumeration is everything.

That is true.

But for PNPT, I would phrase it slightly differently:

Enumeration with intent is everything.

Do not enumerate just to generate output. Enumerate to answer questions.

For example, instead of thinking:

I need to run another scan.

think:

What am I trying to learn?

Good enumeration questions include:

What hosts are reachable?
What services are exposed?
What technologies are in use?
What names, emails, or usernames can I collect?
What authentication portals exist?
What default or weak configurations might be present?
What can I access anonymously?
What changes after I get credentials?
What changes after I get a new network position?

The best progress often comes from information that was already available, but not yet understood.

A hostname that seemed unimportant may reveal a naming convention.

A web page may expose a username format.

An error message may reveal a backend technology.

A share may look boring until you authenticate with a different account.

A credential may seem limited until you test it against the right service.

Enumeration is not a box to check.

It is how you form the next question.

3. Keep a Living Map of the Environment

One thing that helps tremendously is maintaining a simple map as you go.

It does not need to be beautiful. It does not need to be a polished diagram during the exam. It just needs to keep you oriented.

Track things like:

External targets:
- Host
- Ports
- Web apps
- Interesting names
- Possible usernames
- Initial findings

Internal targets:
- Host
- IP
- Role
- Ports
- Access level
- Credentials tested
- Interesting files
- Next actions

You want to avoid the classic problem where, twelve hours in, you have a pile of scans, shells, notes, and screenshots but no clear picture of what is happening.

A simple table can save you from that.

Example:

Host: WEB01
IP: 10.10.10.10
Role: External web server
Access: Web only
Interesting: Login portal, employee names, possible vhost
Next: Directory brute force, tech fingerprinting, username list

Later:

Host: FILE01
IP: 10.10.20.15
Role: Internal file server
Access: SMB with user01
Interesting: Readable shares, config files
Next: Search for credentials, scripts, backups

You do not need fancy tooling to think clearly.

You need a map.

PNPT rewards people who can understand the environment as a system, not just a collection of targets.

4. Re-Enumerate Every Time Your Access Changes

This is one of the most important habits in any internal assessment.

When your access changes, your enumeration results change.

Getting a credential means you should go back.

Getting a shell means you should go back.

Finding a new subnet means you should go back.

Compromising a new user means you should go back.

Too many people enumerate once, get stuck, and assume there is nothing else to find.

But the environment may look completely different from a new position.

After new credentials, re-check:

• SMB
• LDAP
• WinRM
• SSH
• RDP
• Databases
• Web portals
• Admin panels
• Internal apps
• File shares
• User descriptions
• Group memberships
• Password reuse

After a new foothold, re-check:

• Local files
• Running processes
• Network connections
• Internal routes
• DNS resolution
• Cached or stored credentials
• Accessible subnets
• Installed software
• User context
• Local privileges

After a new pivot, re-check:

• Internal ports
• Hostnames
• Web apps
• Domain services
• Previously unreachable systems
• Previously filtered systems

The phrase I kept coming back to was:

What can I see now that I could not see before?

That question matters more than any single tool.

5. Be Comfortable Pivoting, But Understand the Why

Pivoting is not just a technical trick.

It is a change in perspective.

Initial access is rarely the finish line. Often, it is the first place where the real environment starts to become visible.

You should be comfortable with the basic idea:

Attacker -> Compromised host -> Internal network

But more importantly, you should understand what that gives you.

A pivot may allow you to:

• Reach internal hosts
• Scan new services
• Access internal web apps
• Talk to domain services
• Test credentials against systems that were not externally exposed
• Discover trust relationships
• Move from isolated access to meaningful internal visibility

Labs like TryHackMe’s Wreath are valuable because they help reinforce that initial access is only one stage of the process.

Do not just practice commands.

Practice thinking from the pivot.

Ask:

What network can this host reach?
What can this host resolve?
What ports are open from here?
What can I authenticate to from here?
What was blocked externally but reachable internally?

That mindset is the important part.

The tool matters less than understanding the route.

6. Trust the Fundamentals

It is easy to convince yourself that you need some obscure exploit, advanced tradecraft, or tool you have never used before.

Usually, you do not.

The fundamentals carry you much further than you expect.

For PNPT, the fundamentals include:

• Networking
• Linux basics
• Windows basics
• Web enumeration
• Service enumeration
• Password attacks
• Credential reuse
• Active Directory basics
• SMB enumeration
• Privilege escalation methodology
• Pivoting
• Reporting

TCM Security’s Practical Ethical Hacking course covers the core mindset and techniques needed to build that foundation.

Do not rush through it.

It is tempting to watch a course, copy the commands, and call it preparation.

That is not enough.

For every technique, ask:

Why does this work?
What does this tell me?
What are the prerequisites?
What are the common failure points?
How would I validate this manually?
What would I screenshot for a report?
How would I explain the risk to a client?

The exam is not really testing whether you can copy commands.

It is testing whether you understand what those commands are doing.

7. Track Credentials Like a Professional

Credentials are one of the easiest places to get messy.

Do not let that happen.

Every username, password, hash, token, or key should be tracked carefully.

Use a simple structure:

Credential:
User:
Domain / host:
Secret type:
Where found:
Where tested:
Works on:
Fails on:
Privileges:
Notes:

Example:

User: example.local\jdoe
Secret type: Password
Where found: Internal configuration file
Works on: SMB FILE01, LDAP DC01
Fails on: WinRM DC01
Privileges: Standard domain user
Notes: Can read shared folder containing deployment scripts

This matters because credentials are not static facts.

They are possibilities.

A credential might fail in one place and work somewhere else.

A password might be reused.

A low-privileged account might have access to a sensitive share.

A local account might behave differently than a domain account.

A service account might have privileges that are not obvious at first glance.

Do not write:

creds bad

Write exactly where and how they failed.

Precision prevents wasted time.

Precision also helps your report.

8. Prove Things Before You Move On

PNPT is not just about getting access.

It is about being able to prove what happened.

That means you should capture evidence as you work.

When you find something meaningful, ask:

Can I prove this clearly later?

Examples of evidence worth capturing:

• Scan results showing exposed services
• Web pages revealing sensitive information
• Successful authentication
• File access
• Misconfigurations
• Privilege escalation evidence
• Internal access through a pivot
• Directory or domain enumeration results
• Sensitive data exposure
• Screenshots showing impact
• Command output showing user context
• Proof of access tied to the scope

You do not need to screenshot every single command.

But you do need enough evidence to tell the story.

A good report does not simply say:

Access was obtained.

A good report shows:

Access was obtained as this user, through this service, using this weakness, resulting in this impact.

That requires evidence.

If you wait until the end to gather proof, you may forget what mattered.

Capture it while the context is fresh.

9. Slow Down When You Get Stuck

When you get stuck, the instinct is to speed up.

Run more tools.

Try more exploits.

Open more tabs.

Jump to a different target.

Sometimes that helps.

Usually, it creates noise.

The better move is to slow down and review.

Ask:

What do I know?
What have I proven?
What am I assuming?
What have I not tested?
What changed since my last enumeration pass?
Which credentials have I not tested against which services?
Which hosts have I not revisited from my new position?
Which files did I skim instead of actually reading?

Every time I felt stuck, the answer was not some brand-new tool.

It was going back to what I already had and looking at it more carefully.

That is not glamorous, but it works.

Make yourself a stuck checklist.

Something like:

Stuck checklist:
- Review all hosts
- Review all credentials
- Review all shares
- Review all web apps
- Review all screenshots
- Review all notes from the last major access change
- Re-test credentials against important services
- Re-scan from the newest network position
- Check for usernames, passwords, hostnames, and config files
- Identify assumptions that have not been validated

Being stuck does not mean you are out of skill.

It usually means the next clue is buried in your existing data.

10. The Report Is Not Just Paperwork

The report is part of the job.

Do not treat it like an annoying formality after the fun part is over.

A penetration test that cannot be clearly explained is not finished.

Your report should make the attack path understandable to someone who was not sitting beside you during the assessment.

That means your notes need to support:

• Executive summary
• Scope
• Methodology
• Attack path
• Findings
• Evidence
• Impact
• Reproduction steps
• Remediation
• Risk ratings

The technical section should answer:

What did I find?
Why did it matter?
How did I validate it?
What access did it provide?
What was the business or security impact?
How should it be remediated?

The report should not read like a random terminal history.

It should read like a professional explanation of risk.

Instead of:

I found a password and logged in.

write the finding as:

Insecure credential storage allowed recovery of valid credentials.

Then explain where the credential was found, what access it provided, why that access mattered, and how to fix it.

That is the difference between “I hacked the network” and “I performed a penetration test.”

PNPT cares about that difference.

Bonus: Prepare to Explain Your Work

One thing I appreciated about PNPT is that it pushes you to think beyond exploitation.

You need to be able to explain what you did.

That means understanding your own attack path well enough to walk someone through it clearly.

Practice explaining:

How did initial access happen?
What was the first major weakness?
How did access expand?
What was the highest-impact issue?
What could the organization fix first?
Which issues were symptoms, and which were root causes?
What evidence supports each finding?

This is where good notes make a massive difference.

If you documented as you went, explaining the path is natural.

If you waited until the end, you are stuck reconstructing the story from memory.

Do not do that to yourself.

Final Thoughts

PNPT taught me that realistic penetration testing is less about tricks and more about process.

Enumeration matters.

Pivoting matters.

Active Directory fundamentals matter.

Reporting matters.

But the biggest thing is mindset.

Treat the exam like an engagement. Understand the environment. Move logically. Validate your assumptions. Track your evidence. Slow down when you get stuck. Explain the risk clearly.

For anyone preparing for PNPT, my advice is simple:

Do not chase hacks.

Build methodology.

The tools will change. The commands will change. The environments will change.

But a solid methodology will carry you through all of it.