Penetration Testing

Course Description

Penetration Testing covers risk management, security architectures, incident handling, disaster recovery, and secure systems administration in a networking context, taught through the offensive perspective that penetration testing provides.

Within the SCNS taxonomy, CNT is the Computer Networks prefix. Daytona State publishes this at 3 credits, prerequisites CET1600 and CTS2321, offered spring, giving approximately 45 contact hours.

Penetration testing is authorized simulated attack — assessing security by attempting to defeat it, under contract, within defined scope, and with written permission. The perspective is genuinely valuable: defences are designed against imagined attacks and tested against real technique, and the gap between the two is where organizations get compromised.

⚠⚠ Authorization is the entire legal boundary — and Florida has its own statute

The most important content in any offensive security course, and the line is bright rather than blurry.

The same action is a paid profession with written authorization and a felony without it. The technical activity is identical; the authorization is what distinguishes them.

• The federal Computer Fraud and Abuse Act (18 U.S.C. § 1030) criminalizes accessing a computer without authorization or exceeding authorized access. Penalties are serious and include imprisonment.
• Florida has its own statute. Chapter 815, Florida Statutes — the Florida Computer Crimes Act — criminalizes offences against computer users, intellectual property, and computer equipment, with felony classifications. State charges are available independently of federal ones.
• Get written authorization before touching anything. A signed rules of engagement document naming the scope, the systems, the permitted techniques, the testing window, and the emergency contacts is the professional standard and the legal protection.
• Stay in scope. Testing a system not listed, pivoting to an out-of-scope host, or continuing past the authorized window can void the authorization for everything.
• Verbal permission is not sufficient, and permission from someone without authority to give it is not permission. Confirm that the signatory owns the systems — cloud and hosted infrastructure frequently requires the provider's authorization as well.
• Never test systems you do not own without it — not your employer's "to show them", not a friend's, not a public website, not to prove a point. Careers and liberty have been lost this way, and "I was trying to help" has never been a defence.
• Report findings responsibly and do not disclose publicly without agreement.
• Handle discovered data carefully. Encountering personal or protected data during a test creates obligations, and exfiltrating more than needed to demonstrate a finding is indefensible.

Practise only in environments built for it — the course lab, and free legal platforms such as TryHackMe, Hack The Box, OverTheWire, and locally hosted deliberately vulnerable machines. There is no shortage of legal targets, which removes any excuse.

Rule 11 applies — computer crime law and its interpretation change; verify current statute.

Learning Outcomes

Required Outcomes

• Describe the penetration testing lifecycle and the phases of an engagement.
• Describe engagement scoping, rules of engagement, and authorization documentation.
• Describe legal and ethical obligations governing security testing.
• Distinguish penetration testing from vulnerability scanning, red teaming, and auditing.
• Conduct passive reconnaissance and open-source intelligence gathering.
• Conduct active reconnaissance, host discovery, and port scanning.
• Perform service enumeration and fingerprinting.
• Conduct vulnerability identification using scanners and manual verification.
• Validate findings and eliminate false positives.
• Describe and demonstrate common exploitation techniques in a laboratory environment.
• Describe web application vulnerabilities and test for them.
• Describe network service and protocol weaknesses.
• Describe password attacks, credential reuse, and authentication weaknesses.
• Describe privilege escalation on common operating systems.
• Describe lateral movement and pivoting concepts.
• Describe post-exploitation objectives and the limits set by scope.
• Describe social engineering techniques and the rules governing their authorized use.
• Assess and communicate risk, including likelihood, impact, and business context.
• Write a professional penetration test report with prioritized, actionable remediation.
• Describe remediation strategies and defensive controls for identified weaknesses.
• Describe incident handling and disaster recovery as they relate to tested weaknesses.
• Apply secure systems administration practices identified through testing.

Optional Outcomes

• Describe wireless network testing.
• Describe cloud environment testing and its authorization requirements.
• Describe Active Directory attack paths.
• Describe evasion and the purple-team value of detection testing.
• Describe scripting for test automation.
• Prepare for a penetration testing certification.

Major Topics

Required Topics

• The penetration testing lifecycle
• Scoping, rules of engagement, and authorization
• Legal and ethical obligations
• Testing, scanning, red teaming, and auditing distinguished
• Passive reconnaissance and OSINT
• Active reconnaissance and scanning
• Enumeration and fingerprinting
• Vulnerability identification and validation
• Exploitation techniques in a lab
• Web application vulnerabilities
• Network service and protocol weaknesses
• Password and authentication attacks
• Privilege escalation
• Lateral movement and pivoting
• Post-exploitation and scope limits
• Social engineering and its authorization
• Risk assessment and business context
• Report writing and remediation guidance
• Defensive controls and remediation
• Incident handling and disaster recovery
• Secure systems administration

Optional Topics

• Wireless testing
• Cloud testing and authorization
• Active Directory attack paths
• Evasion and purple teaming
• Scripting and automation
• Certification preparation

Resources & Tools

• The Web Application Hacker's Handbook (Stuttard & Pinto) and Penetration Testing (Georgia Weidman) — the standard texts; Weidman's is the better starting point.
• RTFM: Red Team Field Manual — a reference rather than a tutorial, and useful once you know what you are doing.
• Kali Linux and Parrot OS — free distributions bundling the standard toolset; run them in a virtual machine.
• Nmap, Burp Suite Community, Wireshark, and Metasploit Framework — free, and the tools you will actually be asked about.
• OWASP (owasp.org) — free: the Top Ten, the Web Security Testing Guide, and WebGoat and Juice Shop as legal practice targets.
• TryHackMe, Hack The Box, OverTheWire, and PortSwigger Web Security Academy — legal practice environments with substantial free content. PortSwigger's academy is free in full and is excellent.
• VulnHub and Metasploitable — free vulnerable virtual machines to run in your own lab.
• PTES and the NIST SP 800-115 technical guide — free methodology references that structure an engagement properly.
• MITRE ATT&CK — free, and the shared vocabulary between offence and defence.
• CompTIA PenTest+ and OSCP — the recognized certifications; OSCP is hands-on, demanding, and well regarded.

Career Pathways

• Penetration tester — consultancies and in-house security teams; usually reached after other security experience rather than directly from a degree.
• Security analyst — the more common entry point; see this repository's CIS2121 guide on SOC work.
• Vulnerability management analyst — scanning, validation, and remediation tracking; a realistic first role using this material.
• Application security engineer — testing and securing software, and a strong path for anyone who can code.
• Security engineer — building and hardening rather than breaking.
• Red team operator — senior and specialized.
• Systems and network administrator — offensive knowledge makes for markedly better defensive administration.
• Government and defence security — Florida has substantial federal, defence, and space-sector work, much requiring clearance eligibility.
• Bug bounty — legal, authorized testing under published programme rules; a genuine way to build a record.
• SOC code 15-1212 Information Security Analysts. Note the honest sequencing point below.

Special Information

⚠ The report is the deliverable — not the shell

The professional reality that most surprises students, who arrive interested in exploitation and discover the job is largely writing.

• Clients buy a report, not an intrusion. The compromise demonstrates the finding; the report is what the organization acts on, and a brilliant test written up badly produces no security improvement.
• Write for two audiences. An executive summary that a non-technical decision-maker can act on, and technical detail sufficient for an engineer to reproduce and fix the issue.
• Prioritize by business risk, not by scanner severity. A medium-severity finding on a system holding customer data may matter more than a critical on an isolated test box. Context is the analyst's contribution.
• Every finding needs evidence, reproduction steps, impact, and remediation. A finding without a fix is a complaint.
• Be specific about impact. "Could allow an attacker to read the customer database" is actionable; "could compromise security" is not.
• Do not overstate. Inflating severity to make the engagement look valuable destroys credibility and wastes the client's remediation budget on the wrong things.
• Report what you could not test and why — scope limits, time limits, systems that were unavailable. A report implying complete coverage it did not have is dangerous.
• Handle the report as sensitive. It is a map of how to compromise the organization; transmit and store it accordingly.

⚠ Methodology beats tool knowledge — and validation is what makes you credible

• Follow a documented methodology — PTES or NIST SP 800-115 — so that coverage is systematic and defensible rather than dependent on what you happened to think of.
• Reconnaissance is where engagements are won. Thorough enumeration finds the forgotten host, the unpatched service, and the exposed interface; rushing to exploitation misses them.
• Scanners find candidates, not findings. Automated tools produce false positives at meaningful rates, and reporting an unvalidated scanner result is the fastest way to lose a client's trust. Verify manually.
• Understand what you are running. Executing an exploit you cannot explain is dangerous — some are destructive, some are unreliable, and some do more than advertised. In a client environment that is a serious problem.
• Take notes continuously — commands, timestamps, hosts, and results. The report is assembled from them, and reconstructing an engagement from memory is both painful and inaccurate.
• Know when to stop. Demonstrating access is the objective; ranging further than needed, accessing more data than necessary, or causing disruption exceeds the mandate.
• Have a break-things plan. Tests occasionally cause outages. Agreed emergency contacts and a stop procedure are part of the rules of engagement for that reason.

⚠ The career sequencing is not what students expect

Honest guidance, because penetration testing is the most-wanted and least-accessible entry role in security.

• Very few people are hired directly into penetration testing. It is a senior, generalist role — you cannot assess systems you have never administered, applications you have never built, or networks you have never run.
• The realistic paths in are through systems administration, network administration, help desk into security, SOC analysis, or software development. Each builds the underlying knowledge that testing depends on.
• Build depth in something first. Testers who were administrators find misconfigurations that scanners do not; testers who were developers find logic flaws that tools cannot.
• Learn to script. Python and shell scripting separate a tester who runs tools from one who solves problems.
• Home labs and legal platforms are the portfolio. Documented write-ups of practice machines, a home lab you built, and bug bounty findings are what demonstrate ability when you have no professional testing experience.
• Certifications carry real weight in this field — Security+ to start, PenTest+, and OSCP, which is hands-on and respected precisely because it is difficult.
• Bug bounty programmes are legal, authorized testing with published scope; they are a legitimate way to build a public record. Read each programme's rules and stay inside them.

⚠ Offence is only useful if it improves defence

The framing that makes the course's stated content — risk management, incident handling, disaster recovery, secure administration — cohere with the offensive technique.

• The point of testing is remediation. An organization that receives a report and fixes nothing has bought an expensive document.
• Findings should map to controls. Patch management, configuration hardening, segmentation, least privilege, multi-factor authentication, and monitoring are where most findings resolve.
• The same weaknesses recur. Default and weak credentials, missing patches, excessive privilege, exposed services, and unvalidated input account for a large share of real compromises — which is why fundamentals outperform sophistication defensively.
• Detection matters as much as prevention. A test that was not detected reveals a monitoring gap, and reporting that is frequently more valuable than the vulnerability. This is the purple-team argument.
• Incident response and recovery capability is testable too — whether backups restore, whether the plan works, and whether people know their roles.
• Risk is likelihood times impact, in business terms. Security exists to let an organization operate, and recommendations that ignore cost, usability, and operational reality get ignored.

⚠ Only about three Florida institutions carry this number — hedge accordingly

This course appears at roughly three institutions statewide. Content, credit value, and emphasis vary more than they would for a widely taught course. Read your own institution's catalog description and syllabus rather than assuming this guide describes your section exactly, and have any transfer evaluated in writing.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement.

CNT2402 is 3 credits and approximately 45 contact hours, offered spring. Expect laboratory work in an isolated environment and a written engagement report as a major deliverable. Build a home lab — virtualization software and vulnerable virtual machines are free, and the practice is what develops capability.

The course transfers on the ordinary lower-division basis. Computing A.S. degrees are applied and do not carry the A.A.'s guaranteed junior-status transfer. In this field specifically, certifications and demonstrable hands-on work weigh heavily — and, as the legal section above sets out, that work must be done in environments you are authorized to test.