Learn Ethical Hacking Series):Exercise 1: DIVA vulnerable app analysis (abbreviated).
jadx decompilation findings:
1. Hardcoded credentials:
File: com/payatu/diva/InsecureDataStorage1Activity.java:24
Content: username = "admin", password = "password123"
2. Insecure storage:
SharedPreferences: /data/data/jakhar.aseem.diva/shared_prefs/
Contains plaintext usernames and passwords from all login attempts
3. Exported activities:
AndroidManifest.xml: 13 activities with android:exported="true"
Including: APICredsActivity (displays API credentials when
launched directly via adb: am start -n jakhar.aseem.diva/.APICredsActivity)
The DIVA analysis demonstrates exactly the point we made in episode 69 about mobile apps shipping secrets in the binary. The hardcoded credentials in InsecureDataStorage1Activity.java are not some obscure finding buried deep in obfuscated code -- they are sitting right there in a clearly named Java class, line 24, extracted by jadx in under 30 seconds. The 13 exported activities are the more interesting finding from a practical standpoint. Every exported activity without an intent filter check can be launched by ANY other app on the device (or by adb remotely). APICredsActivity being exported means any malicious app installed alongside DIVA can invoke it and scrape whatever credentials it displays -- no user interaction required, no permissions needed beyond what every app already has. In a real-world app with payment credentials or OAuth tokens, this would be a Critical-severity finding.
Exercise 2: Frida hooking (abbreviated).
# Login bypass:
Java.perform(function() {
var Login = Java.use('com.target.app.LoginActivity');
Login.validateCredentials.implementation = function(u, p) {
console.log('[*] Bypassed login for: ' + u);
return true;
};
});
# Result: any username/password accepted
# HTTP URL logging:
Java.perform(function() {
var URL = Java.use('java.net.URL');
URL.$init.overload('java.lang.String').implementation = function(url) {
console.log('[*] URL: ' + url);
return this.$init(url);
};
});
# Logged 47 unique API endpoints in 5 minutes of app usage
The login bypass is trivially effective and reinforces the lesson from episodes 17 and 69: client-side authentication is not authentication. The Frida hook replaces the entire validation function with return true -- the app does not know the difference. The URL logging hook is arguably more valuable from a pentest perspective because it reveals the app's complete API surface without reading a single line of decompiled code. Those 47 unique endpoints captured in 5 minutes of normal usage are your roadmap for the server-side testing phase. Some of those endpoints will be admin-only paths that the app UI never shows, debug endpoints left in the production build, or API versions that were supposed to be deprecated. All of them are now visible, ready for testing with Burp Suite (which we covered across episodes 11, 21, and 26).
Exercise 3: MobSF audit comparison (abbreviated).
App A (banking): Score 42/100 -- certificate pinning present,
but ATS exceptions found, 2 tracker SDKs, plaintext logging
App B (social media): Score 31/100 -- no cert pinning, 7 tracker
SDKs, location data in plaintext logs, hardcoded API key
App C (e-commerce): Score 55/100 -- cert pinning, encrypted
storage, but exported content provider leaks product data
Most common finding: tracker SDKs (present in all 3 apps,
sending device data to analytics providers in plaintext)
The tracker SDK finding across all three apps is the one that should make you uncomfortable. These are not vulnerabilities the app developers introduced -- they are vulnerabilities the developers imported by adding analytics SDKs (supply chain risk, episode 45). Seven tracker SDKs in a social media app means seven third-party companies receiving device identifiers, location data, and usage patterns, often transmitted without encryption. From a privacy perspective (episode 55) this is a GDPR nightmare. From a security perspective, each SDK is an additional attack surface that the app developer does not control and probably does not audit. The banking app scoring only 42/100 despite having certificate pinning is a good reminder that pinning alone does not make an app secure -- the ATS exceptions and plaintext logging undermine it. The e-commerce app had the best score (55/100) but still leaked product catalog data through an exported content provider, which is exactly the kind of finding that automated scans catch instantly but manual testers might miss if they are not checking inter-app communication.
Episode 69 covered mobile application security -- the Android and iOS security models, static analysis with jadx, dynamic analysis with Frida and Burp Suite, common mobile vulnerabilities (insecure storage, deeplink hijacking, WebView exploitation), the OWASP Mobile Top 10, and MobSF for automated assessment. The closing argument was that mobile security testing is becoming a core professional skill because organizations are building mobile-first products and the attack surface is growing faster than testing capacity.
Today we take the natural next step. You have spent 69 episodes learning how to find and exploit vulnerabilities across web applications, networks, wireless protocols, cloud infrastructure, mobile apps, and everything in between. You have built tools (episodes 59-61), written exploits (episodes 42-43), reversed binaries (episode 44), conducted red team operations (episode 50), and documented findings professionally (episode 66). The question is: now what?
Knowledge sitting in your head and lab notes does not pay rent. This episode is about turning everything you have learned into a career -- whether that means getting hired at a security firm, starting your own consultancy, or building a freelance practice. The skills are real. The market is desperate for qualified pentesters. The gap between "I can hack things in my lab" and "someone pays me to hack things professionally" is smaller than you think, but it requires deliberate efford to cross.
Certifications are the entry ticket. Not because a certificate makes you a better hacker (it absolutely does not), but because HR departments and procurement teams use certifications as a filter. If a job listing says "OSCP required" and you do not have it, your resume goes in the bin regardless of how many boxes you have rooted on Hack The Box.
OSCP (Offensive Security Certified Professional)
Cost: ~$1,600 (90-day lab access + exam)
Format: 24-hour practical exam -- hack 5 machines, write report
Reputation: THE certification for pentesting. Universally respected.
Difficulty: challenging. Requires real skills, not memorization.
Prep time: 3-6 months of dedicated practice
Value: opens doors. Many job listings require OSCP.
Verdict: GET THIS FIRST. Nothing else matters until you have OSCP.
PNPT (Practical Network Penetration Tester)
Cost: ~$400
Format: 5-day practical exam -- full pentest including AD
Reputation: growing, respected in the community
Difficulty: moderate. More realistic than OSCP (includes AD, reporting)
Value: good for those who want a practical cert without OSCP's price
Verdict: good alternative or complement to OSCP
CEH (Certified Ethical Hacker)
Cost: ~$1,200
Format: multiple choice exam (125 questions, 4 hours)
Reputation: recognized by HR departments, not by practitioners
Difficulty: easy if you memorize the material
Value: checks a box on job applications. Does NOT prove you can hack.
Verdict: get it if your employer pays, skip if you are self-funding
CRTO (Certified Red Team Operator)
Cost: ~$400
Format: 48-hour practical exam -- AD compromise using Cobalt Strike
Reputation: excellent for red team roles specifically
Difficulty: moderate-high. Requires real red team skills.
Value: demonstrates adversary simulation capability (episode 50 material)
Verdict: after OSCP, if you want to specialize in red teaming
GPEN (GIAC Penetration Tester)
Cost: ~$2,500 (with SANS training: ~$8,000+)
Format: proctored exam with practical component
Reputation: highly respected, especially in US government/military
Difficulty: moderate
Value: expensive but opens doors in government contracting
Verdict: if your employer pays for SANS training, absolutely
Priority order: OSCP -> PNPT or CRTO -> specialized certs
I want to be direct about the CEH. The security community has a running joke that CEH stands for "Certified Enough to be Hired" -- it proves you can pass a multiple-choice exam, not that you can find a SQL injection in a running application. Having said that, the reality of the job market is that HR filters exist whether we like them or not. If a government contract requires CEH and your employer will pay for it, take it. Just do not confuse passing the CEH with being a competent pentester. OSCP is the one that actually proves you can do the work, because the exam IS a pentest -- 24 hours, five machines, no multiple choice, no study guides, just you and a network full of vulnerabilities.
The PNPT from TCM Security deserves special attention because it includes Active Directory attacks (which we covered in episode 33) and requires a professional report as part of the exam submission. This makes it closer to a real engagement than even the OSCP, which historically focused more on individual machine compromise than realistic enterprise scenarios. At $400 versus OSCP's $1,600, it is also considerably more accessible. If budget is a constraint, PNPT first and OSCP second is a perfectly valid path.
We covered setting up a hacking lab way back in episode 2, but a practice lab for professional development needs to go further than a Kali VM and some Metasploitable targets:
The professional practice lab:
Hardware:
- Any computer with 16+ GB RAM and 200+ GB storage
- Or: cloud VMs on AWS/Azure free tier (sufficient for most labs)
- A dedicated network segment (even just a separate VLAN on your router)
Core VMs:
- Kali Linux (your attack machine -- always current version)
- Windows Server 2019/2022 (Domain Controller for AD practice)
- Windows 10/11 (domain-joined workstation)
- Ubuntu Server (web application target)
- Metasploitable 2/3 (deliberately vulnerable -- good for warm-ups)
Active Directory Lab (CRITICAL for professional work):
1. Windows Server as DC (install AD DS, DNS, DHCP)
2. Join 2 Windows 10 VMs to the domain
3. Create users, groups, GPOs with realistic structure
4. Deliberately misconfigure: Kerberoastable service account,
user with disabled preauth, admin session on workstation,
writable share with sensitive data
5. Practice: BloodHound recon, Kerberoasting, AS-REP roasting,
DCSync, Golden Ticket -- the full episode 33 attack chain
The AD lab is non-negotiable if you want professional work. A startling percentage of real-world pentest engagements involve Active Directory, and the path from "initial foothold" to "Domain Admin" is what clients are paying you to demonstrate. If you can walk into an engagement, compromise an AD environment, and explain the attack chain clearly in a report (episode 66), you are already more valuable than half the junior pentesters on the market.
Practice platforms (free):
- Hack The Box (free tier: 2 active machines)
- TryHackMe (free tier: guided learning rooms)
- VulnHub (downloadable VMs, completely free)
- PortSwigger Web Security Academy (web attack labs, free)
- PicoCTF (beginner-friendly CTF, completely free)
- OverTheWire (wargames, free, excellent for Linux fundamentals)
Practice platforms (paid, worth every cent):
- Hack The Box VIP ($14/month: all machines + retired archive)
- TryHackMe Premium ($10/month: all rooms, attack boxes)
- Proving Grounds ($19/month: OSCP-like machines by OffSec)
- HackTheBox Academy ($18/month: structured courses with labs)
My recommendation for someone preparing for a professional career: start with TryHackMe for structured learning (it holds your hand more, which is fine when you are building foundations), then move to Hack The Box for realistic challenges (nobody holds your hand on a real engagement). Once you are consistently solving medium-difficulty HTB boxes without hints, you are ready to attempt the OSCP. Proving Grounds is specifically designed by Offensive Security to prepare for the OSCP exam -- the machines have a similar difficulty curve and the same "try harder" philosophy.
Capture The Flag competitions test specific security skills in a competitive environment, and they are surprisingly relevant to professional pentesting:
CTF formats:
Jeopardy-style:
Categories: web, crypto, reversing, forensics, pwn (binary exploit)
Format: solve challenges, find the "flag" (a hidden string)
Good for: building depth in specific technical areas
Start with: PicoCTF, Google CTF beginners, OverTheWire
Attack-Defense:
Format: each team has a server to defend + attack other teams
Good for: real-time offensive AND defensive skills simultaneously
Start with: local university CTF events, DEF CON CTF qualifiers
King of the Hill:
Format: compromise a shared machine, maintain access the longest
Good for: persistence, stealth, and defense against other attackers
Available on: TryHackMe King of the Hill mode
The most valuable habit you can build with CTFs: after solving a challenge, read other people's writeups. Your solution works, great. But you used one approach out of many possible approaches. The person who solved it by exploiting a race condition you never considered, or the team that found a shortcut through a logic flaw you did not notice -- their writeups teach you lateral thinking that no structured course can provide. This is the same principle behind reading CVE analyses and post-mortems: understanding HOW other people think about problems makes you a more versatile tester ;-)
CTF performance is also increasingly valued by employers. Placing well in recognized competitions (DEF CON CTF qualifiers, Google CTF, Pwn2Own) is stronger evidence of practical skill than any certification, because nobody can memorize their way through a live CTF. Some security firms actively recruit from CTF teams.
Here we go -- the business side. This is where quit some technically brilliant hackers struggle, because running a consulting practice requires skills that have nothing to do with finding vulnerabilities:
Getting your first client:
1. Build a portfolio
- Blog about CTF writeups (demonstrates methodology + writing)
- Contribute to open-source security tools (demonstrates coding)
- Publish responsible disclosures / bug bounty reports
- Write sample pentest reports (redacted or fictional targets)
- Your Hack The Box profile (shows consistent practice)
2. Find clients
- Local small businesses (they need pentests but cannot afford
big firms -- you are their affordable entry point)
- MSPs (Managed Service Providers) subcontract pentesting work
- Freelance platforms (Upwork, Toptal -- competitive but viable)
- Networking: BSides conferences, local OWASP chapter meetups
- Word of mouth (your best channel after the first 3-5 clients)
3. Pricing (varies hugely by region and experience)
- Junior freelancer: $150-250/hour or $1,500-3,000/day
- Experienced: $250-400/hour or $3,000-5,000/day
- Fixed price per engagement: web app pentest $5,000-15,000,
network pentest $10,000-30,000, red team $30,000-100,000+
- START LOW to build your reputation, increase as demand grows
- Never compete on price alone -- compete on report quality
The portfolio point deserves emphasis. When a potential client asks "can you show me what a pentest report looks like?", you need to have something to show them. Write a full pentest report against a deliberately vulnerable application (DVWA, Juice Shop, WebGoat) using the format from episode 66 -- executive summary, methodology, findings with CVSS scores and reproduction steps, risk summary, appendices. Redact it appropriately and use it as your sample. One high-quality sample report wins more clients than ten certifications on your LinkedIn profile, because the report is the DELIVERABLE. It is what the client actually pays for. If the sample report is clear, professional, and demonstrates that you can find real bugs and explain them to non-technical stakeholders, the client will trust you with their environment.
Legal protection (NON-NEGOTIABLE):
- Professional liability insurance (E&O) -- MANDATORY before first engagement
- Written scope and rules of engagement for EVERY engagement
- "Get out of jail free" letter signed by an authorized executive
- Limitation of liability clause in your contract
- Data handling agreement (how you store and destroy client data)
- Register a company (LLC or equivalent in your jurisdiction)
- Separate business bank account
- Keep detailed logs of every action during an engagement
The "get out of jail free" letter (formally, a "letter of authorization" or "permission to test") is not optional. Without it, everything you do during a pentest is potentially a criminal offense -- unauthorized access to computer systems, interception of communications, data exfiltration. The letter must be signed by someone with actual authority to authorize testing (a C-level executive or equivalent, NOT a mid-level IT manager who "thinks it is probably fine"), and it must specify exactly what you are authorized to do: which systems, which IP ranges, which attack techniques, what hours, what is explicitly out of scope. If the police show up at 2 AM because you triggered an IDS alert and the client's SOC called law enforcement, that letter is the only thing standing between you and a very unpleasant conversation. We touched on this in episode 26 (the full web pentest methodology) and episode 50 (red team operations), but it bears repeating: no letter, no test. Period.
A professional pentest engagement follows a structured lifecycle. This is the workflow you will follow hundreds of times over your career:
1. PRE-ENGAGEMENT
Client inquiry -> initial meeting -> understand needs
Proposal: scope, methodology, timeline, price, deliverables
Contract: signed by both parties, includes ROE and liability
Kick-off: confirm scope, get credentials/VPN access, emergency contacts
2. RECONNAISSANCE (episodes 4, 5, 47, 65)
OSINT, scanning, target mapping, asset discovery
Document everything from the start -- not "I'll write it up later"
3. EXPLOITATION (episodes 11-28, 29-40, 31-33, 35-37)
Web vulnerabilities, network attacks, privilege escalation, AD
Screenshot every finding as you find it. Timestamp everything.
4. POST-EXPLOITATION (episode 34)
Lateral movement, data access demonstration, impact assessment
Show the client what an attacker COULD access, not just that
you got in. "Domain Admin" means nothing to a CEO. "Full access
to 200,000 customer records including payment data" does.
5. REPORTING (episode 66)
Draft report -> internal QA review -> client delivery
The report is the product. Not the hack. The report.
6. DEBRIEF
Report walkthrough with client technical and management teams
Answer questions, explain attack chains, demonstrate impact
Prioritize remediation collaboratively
Offer retest after remediation (additional engagement)
The debrief meeting is where you build long-term client relationships. A pentester who drops a PDF and disappears gets hired once. A pentester who sits with the development team, walks them through each finding, explains WHY the vulnerability exists (not just what it is), and helps them prioritize fixes based on business risk -- that pentester gets hired back every year. The debrief is also where episode 66's emphasis on multi-audience writing pays off: the CTO wants the executive summary, the engineering lead wants the finding details, and the developers want the reproduction steps. If your report serves all three audiences well, the debrief is a conversation rather than a lecture.
The security field reinvents itself at a pace that makes most other tech disciplines look static. A vulnerability class that did not exist last year becomes this year's most exploited attack vector. Staying current is not optional -- it is the difference between a pentester who finds real bugs and a pentester who runs outdated tools against modern defenses:
Daily:
- Twitter/X security researchers and bug bounty hunters
- RSS feeds: security vendor blogs, researcher publications
Weekly:
- Hack The Box or TryHackMe: 1-2 machines or rooms per week
- Read 1 CVE analysis in depth (not just the advisory -- the
technical writeup, the PoC, the root cause)
Monthly:
- Attend a security meetup or webinar (BSides, OWASP chapter)
- Study one tool's documentation thoroughly (a tool you use
superficially -- read ALL the flags and options)
- Practice one technique you have not used recently
Quarterly:
- Take a training course (Offensive Security, SANS, HTB Academy)
- Attend a conference (BSides, DEF CON, Black Hat if budget allows)
- Write a blog post or CTF writeup about something you learned
Key resources:
- PortSwigger Research (cutting-edge web security research)
- Google Project Zero (vulnerability research at the highest level)
- SpecterOps (red team and AD research)
- The Hacker News (daily security news aggregation)
- SANS Reading Room (deep research papers)
- Reddit: r/netsec, r/AskNetsec (community discussion)
The blog writing recommendation is not just about building a portfolio (though it helps with that too). Writing forces you to UNDERSTAND a topic at a level that just reading does not achieve. If you cannot explain a technique clearly in writing, you do not understand it well enough to use it reliably on an engagement. I have been writing technical tutorials for years now, and the act of writing has taught me more about the subjects I cover than any course or certification ever did. The process of explaining something clearly to someone else exposes every gap in your own understanding -- gaps that you can then fill before they cost you on a real engagement.
This section is for the other side of the table -- organizations looking to hire pentesters or evaluate pentesting firms:
What to look for in a pentester or firm:
- OSCP or equivalent practical certification (not just CEH)
- Sample reports (redacted) -- report quality tells you everything
- References from previous clients (call them, do not just read)
- Clear methodology explained in plain language
- Professional liability insurance (ask for proof)
- Experience in YOUR industry (healthcare, finance, etc.)
- Willingness to explain their approach before the engagement
Red flags:
- "We guarantee zero vulnerabilities after our test" (impossible)
- No written scope or rules of engagement (liability disaster)
- Report is just a Nessus/Qualys scan export (not a real pentest)
- Cannot explain methodology without jargon (red flag for report quality)
- No insurance (you are accepting THEIR liability)
- Fixed price without a scoping meeting (they have no idea what
they are testing, and you are paying for whatever they decide)
Getting value from the engagement:
- Involve developers in the debrief (they learn the most from it)
- Track remediation of each finding to completion
- Re-test after remediation (verify the fixes actually work)
- Compare results across annual tests (measure improvement over time)
- Feed findings back into DevSecOps pipeline (episode 67)
The biggest red flag -- a firm that cannot explain their methodology in plain language -- connects directly to the communication skills we discussed in episode 66. If a pentesting firm cannot articulate what they do in terms a non-technical executive understands, their report will have the same problem. And a report that nobody understands is a report that drives zero remediation, which means you paid $20,000 for a PDF that sits in someone's inbox until the next breach.
AI is lowering the barrier to entry for security testing -- for legitimate pentesters and for attackers alike. AI can generate pentest reports, suggest attack techniques, and automate parts of the engagement workflow. This raises two questions that anyone building a career in this field needs to think about.
First, will AI replace pentesters? No. AI cannot understand business context, assess real-world risk, make judgment calls about what to test versus what to skip, communicate findings to a non-technical board, or build the trust relationships that drive repeat business. AI is a force multiplier for skilled pentesters (automating the tedious enumeration and pattern-matching we covered in episodes 5, 61, and 65), not a replacement for human expertise and judgment.
Second, will AI-armed script kiddies flood the market with cheap pentests? Yes, and this is already happening. The result is a flood of "pentest reports" that are essentially automated scan outputs wrapped in AI-generated prose -- zero manual testing, zero business context, zero actionable remediation advice. This is exactly why report quality (episode 66) matters more than ever. A professional pentest that finds real business logic flaws (episode 22), explains attack chains in terms executives understand, and helps the client actually FIX their security posture is worth 10x the price of an AI-generated scan dump. The pentesters who can demonstrate this value will thrive. The ones competing on price alone will lose to AI -- and they should, because a $500 "pentest" that finds nothing the client's own Nessus scan would not have found is not a pentest at all.
Exercise 1: Create a professional pentest proposal for a fictional client. The client is a mid-size e-commerce company with a web application, mobile app, and internal corporate network. Include: (a) scope of work with specific system boundaries, (b) methodology (reference PTES or OWASP Testing Guide), (c) timeline for a 2-week engagement with milestones, (d) deliverables (interim status reports, final report, debrief meeting), (e) pricing with line items for each testing phase, (f) terms and conditions including liability limitation and data handling. This is a document you could send to a real client. Save to ~/lab-notes/pentest-proposal.md.
Exercise 2: Set up a complete AD lab and compromise it. Install Windows Server as a Domain Controller, join 2 Windows workstations, create 10 users across 3 groups (IT Admins, Finance, Standard Users), and introduce 3 deliberate misconfigurations: a Kerberoastable service account with a weak password, an admin session left on a workstation, and a writable network share containing a file with credentials. Practice the full attack chain from initial access to Domain Admin using BloodHound for path discovery. Document every step with screenshots and timestamps as if writing a real pentest report. Save to ~/lab-notes/ad-lab-pentest.md.
Exercise 3: Plan your 12-month security career roadmap. Define: (a) which certification to pursue first and a week-by-week study schedule, (b) which 3 practice platforms to use and how many hours per week on each, (c) 5 specific skills from this series you want to deepen (with the episode numbers for reference), (d) 3 networking activities to pursue (meetups, conferences, online communities), (e) a timeline for your first freelance engagement or job application with specific milestones. Be realistic about time commitments -- this plan should be something you can actually follow. Save to ~/lab-notes/career-roadmap.md.
