Task 1 Introduction

This lab introduces the evolution of software development practices and explains why modern development must integrate security from the beginning. As software delivery became faster and more automated, security also needed to evolve to keep pace.

Why Evolution Matters

Early software development focused mainly on functionality and speed. Security was often added at the end, which led to vulnerabilities and costly fixes. Over time, practices improved by integrating testing, automation, and collaboration, shaping today’s DevSecOps approach.

Learning Objectives Explained

1. Understanding history: Learn how software development moved from traditional models to agile and DevOps driven workflows.
2. Importance of DevSecOps: Recognize why security can no longer be isolated and must be part of development and operations.
3. DevSecOps culture: See DevSecOps as both a mindset and a discipline that promotes shared responsibility for security.

DevSecOps Concept in Simple Terms

DevSecOps means embedding security into every phase of the software development lifecycle. Security is automated, continuous, and shared across teams instead of being a final checkpoint.

DevSecOps Learning Path Summary

1. Introduction to DevSecOps: Covers secure SDLC, development environments, and commonly used tools.
2. Security of the Pipeline: Focuses on protecting CI CD pipelines, source code, automated testing, dependency handling, and environment security.
3. Security in the Pipeline: Examines how pipelines can be attacked, how vulnerabilities are exploited, and how they can be defended.
4. Infrastructure as Code: Explores cloud DevOps concepts, secret management, and security issues in tools like Terraform, Vagrant, and Docker.

Answer the questions below

I’m ready to start!

No answer needed

Task 2 DevOps: A New Hope

DevOps emerged as a response to long standing inefficiencies in traditional software development models. As systems grew complex and user expectations increased older approaches failed to scale and adapt.

Waterfall Model Overview

• Originated in the 1970s
• Strict hierarchical structure with isolated roles
• Developers built features
• System administrators handled infrastructure and deployments
• QA teams tested functionality

Problems with Waterfall

• Teams worked in silos with little collaboration
• Bugs and security flaws were pushed between teams
• Delays due to handoffs and blame culture
• Backlogs increased as releases became frequent
• Poor scalability and communication breakdown

This model lacked flexibility and created friction as software demands increased.

Agile Model Overview

Introduced in the early 2000s to solve waterfall limitations.

Agile Manifesto Core Values

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a fixed plan

Improvements with Agile

• Focus on collaboration and self organising teams
• Faster feedback cycles
• Greater flexibility and adaptability
• Stronger alignment with customer needs

Remaining Gap

Agile improved development speed and collaboration but did not fully address operational challenges like deployment infrastructure and automation.

Birth of DevOps

• Originated from discussions in 2008 between Andrew Clay and Patrick Debois
• Gained momentum after DevOpsDays event in 2009
• Focused on cultural change rather than only process change

What DevOps Introduced

• Unified development QA and operations
• Shared responsibility across teams
• Heavy use of automation and integration
• Continuous visibility into systems and workflows
• Engineers expanded skill sets beyond traditional roles

Why DevOps Matters

• Builds trust and collaboration between teams
• Aligns technical work with business goals
• Enables smaller reversible changes
• Improves delivery speed and reliability
• Enhances communication and accountability

Modern DevOps Infrastructure Key Points

• Fully automated self service environments
• Developers can provision cloud resources independently
• CI CD automates testing staging and production deployments
• Infrastructure as Code enables repeatable deployments
• Containerised workloads are provisioned dynamically

Declarative vs Imperative Approaches

Declarative approach

1. Define the desired end state
2. System handles configuration automatically
3. Minimal human interaction

Imperative approach

1. Define step by step actions
2. Changes applied after manual or gated approval
3. Higher risk of errors as releases increase

Answer the questions below

What methodology relies on self-organising teams that focus on constructive collaboration?

agile

What methodology relies on automation and integration to drive cultural change and unite teams?

DevOps

What traditional approach to project management led to mistrust and poor communication between development teams?

waterfall

What does DevOps emphasize?
building trust

Task 3 The Infinite Loop

DevOps is represented as an infinite loop to show that development operations and feedback never stop. Each phase continuously feeds into the next, ensuring faster delivery better quality and continuous improvement.

How DevOps Works in Practice

The infinite loop highlights collaboration automation and constant feedback across the entire lifecycle rather than linear handoffs between teams.

Key DevOps Concepts and Tools

CI and CD: Continuous Integration and Continuous Deployment focus on frequent code merging with automated testing.

• Code is tested as soon as it is pushed or merged
• Bugs are detected early in the development cycle
• Small frequent changes reduce risk
• Easier version control and reliable rollbacks
• Improves maintainability of modular code

Infrastructure as Code: Infrastructure is managed and provisioned using code instead of manual setup.

• Enables reusable infrastructure definitions
• Ensures consistency across environments
• Improves speed and reliability of deployments
• Common tools include Terraform and Vagrant
• Forms a foundation for infrastructure security testing

Configuration Management: Maintains and enforces the desired state of infrastructure over time.

• Ensures systems remain correctly configured
• Reduces manual intervention
• Saves time and improves visibility
• Often implemented using IaC principles

Orchestration: Automates workflows and system coordination.

• Manages resource planning automatically
• Improves system stability
• Enables rapid response to failures
• Works closely with monitoring and automation

Monitoring: Focuses on observing system performance and health.

• Collects data on services and infrastructure
• Enables faster incident detection and recovery
• Supports root cause analysis
• Improves visibility across teams
• Can trigger automated responses

Microservices Architecture: Applications are broken into smaller independent services.

• Easier scaling of individual components
• Reduced overall complexity
• Flexibility in technology choices
• Better fault isolation

Answer the questions below

What helps in adding tests in an automated manner and deals with the frequent merging of small code changes?

CI/CD

What process focuses on collecting data to analyse the performance and stability of services?

Monitoring

What is a way to provision infrastructure through reusable and consistent pieces of code?

lac

Task 4 Shifting Left

Shifting left means introducing security as early as possible in the software development lifecycle. DevOps makes this possible by improving visibility automation and collaboration between development operations and security teams.

Traditional Security Approach

• Security testing was done at the final stages of development
• Security teams acted as gatekeepers before production
• Applications were either approved or sent back for fixes
• Led to long delays stress rollbacks and high costs
• Created friction and blame between teams

What Shifting Left Changes

• Security is embedded from design and coding stages
• Security testing happens continuously not at the end
• Developers and security teams collaborate closely
• Issues are identified and fixed early

Why Shifting Left Is Needed

• Modern development is fast and cloud driven
• Infrastructure provisioning is automated and rapid
• Faster releases increase the risk of unnoticed flaws
• Late stage security reviews become bottlenecks
• Fixing issues later becomes expensive and risky

Key Benefits of Shifting Left

• Early detection of security flaws
• Lower remediation costs
• No last minute rollbacks
• Faster and smoother releases
• Improved trust between teams
• Better product quality and security

Role of Automation

• Code analysis tools run during development
• Automated security tests integrate into pipelines
• Continuous feedback helps developers fix issues quickly

Connection to DevSecOps

Shifting left in DevOps leads directly to DevSecOps. Security becomes a shared responsibility and a built in design principle rather than an afterthought.

Security as a Design Feature

• Security is not optional
• Security is part of architecture and coding decisions
• Blending security strengthens DevOps practices

Modern Reality

• Cyber threats are increasing
• Regulations are becoming stricter
• Integrating security early is no longer a choice
• It is a mandatory requirement for modern software development

Answer the questions below

What term is it used to describe accounting for security from the earliest stages in a development lifecycle?

shift left

What is the development approach where security is introduced from the early stages of a development lifecycle until the final stages?

DevSecOps

Task 5 DevSecOps Security Strikes Back

DevSecOps is a culture driven approach that integrates security into every stage of development and operations. Security becomes a shared responsibility and a normal daily activity rather than a separate final step. Automation and platform design play a major role in making this possible.

Value of DevSecOps

1. Reduces vulnerabilities across applications
2. Improves security test coverage
3. Increases automation of security controls
4. Minimizes business risk and economic loss
5. Protects brand reputation
6. Simplifies auditing monitoring and compliance

How to Implement DevSecOps Effectively

1. Focus on culture first
2. Encourage open communication and trust
3. Promote shared ownership of security
4. Bridge security knowledge gaps between teams
5. Provide teams with tools training and guidance
6. Enable developers to make secure decisions independently

Key DevSecOps Challenges

Security Silos

Security is often treated as a separate function handled only by specialists.
This creates isolation and prevents developers and operators from building security into their work early.
This approach does not scale well.
Best practice is shared responsibility where security teams act as enablers not blockers.

Lack of Visibility and Prioritisation

Security should be treated as a normal part of application development.
Developers should work confidently without fear of blame.
Security teams should empower autonomy rather than enforce policing.
Clear processes help teams understand what matters most from a security perspective.

Stringent Processes

Overly rigid security approvals slow down innovation.
Not all changes carry the same level of risk.
Low risk tasks should follow lightweight processes.
High risk changes should go through stricter reviews.

Use of Sandbox Environments

Developers need freedom to experiment safely.
Sandbox environments provide isolated testing spaces.
They are temporary and disconnected from internal networks.
They contain no real customer data.

Answer the questions below

What DevSecOps challenge can lead to a siloed culture?

Security Silos

What DevSecOps challenge can affect not prioritizing the right risks at the right times?

Lack of visibility

What DevSecOps challenge stems from needlessly overcomplicated security processes?

Stringent Processes

Task 6 DevSecOps Culture

DevSecOps culture focuses on shared responsibility trust and collaboration. Security is embedded into everyday work instead of being owned by a single team.

Promoting Team Autonomy

1. Security should be automated and integrated into development pipelines
2. Security tests should feel like normal tests such as unit testing
3. Engineers should be confident to make secure decisions on their own
4. Security teams cannot be part of every discussion
5. Security acts as a support function not a control gate

Role of Education and Guidance

1. Use playbooks and runbooks to explain common flaws
2. Help teams understand risk and remediation
3. Build overlapping knowledge across teams
4. Encourage learning instead of dependency on security specialists

Visibility in DevSecOps

1. Teams must see the security state of the services they own
2. Dashboards help visualize risks and critical issues
3. Visibility helps teams prioritize security work
4. Prevents important issues from being lost in backlogs

Transparency Across Tools and Processes

1. Security tools should be accessible to developers
2. Alerts should explain what the issue is and where it exists
3. Developers should see affected code lines and fixes
4. Access to detailed findings promotes learning and autonomy
5. Removes the traditional barrier between security and development

Flexibility Through Understanding and Empathy

1. Different teams view risk differently
2. Deadlines priorities and pressures vary across roles
3. One size solutions do not work for everyone
4. Understanding team workflows helps design better security processes

Building Trust with Teams

1. Learn how teams own and operate their services
2. Tune security scanners based on real risks
3. Avoid excessive false alarms
4. Focus on what truly impacts the service
5. Demonstrate value instead of enforcing fear

Practical Example of Empathy
A platform team may prioritize service uptime over low impact vulnerabilities. Security processes should reflect this reality by adjusting priorities and triage methods.

Answer the questions below

How can you make security scalable so it’s not left behind when start ups face hypergrowth or in large corporations?

promote autonomy of teams

How can you support teams in understanding risk and educating on security flaws?

Visibility and Transparency

What are key factors to successfu Ily instill security in the development process by accounting for flexibility?

Understanding and Empathy

Task 7 Exercise Fuel Trouble

Goal was to reach a planet with the least risk
Fuel allowed travel up to 130000 light years
Available models were Waterfall Agile and DevOps

Comic 1 Analysis

Decision was made early to go to Testooine
Once initial tests passed the plan did not change
No further feedback or reassessment was considered
Even though Testooine was the farthest planet the decision stayed fixed

Model Used

Waterfall Model

Reason

Waterfall follows a rigid upfront plan
Decisions are made once and followed through
Late feedback does not influence earlier stages

Comic 2 Analysis

Initial tests suggested Testooine
Further tests revealed high risk
Decision was changed to Hoth after new findings
Course was adjusted based on updated test results

Model Used

Agile Model

Reason

Agile allows responding to change
Continuous testing influences decisions
Feedback leads to adapting the plan

Comic 3 Analysis

Initial analysis suggested Hoth
Cost and risk were continuously evaluated
Multiple teams contributed insights
Trajectory parameters were adjusted
Final decision moved to Dagobug after further testing

Model Used

DevOps Model

Reason

DevOps emphasizes continuous collaboration
All teams share responsibility
Decisions evolve with constant feedback testing and analysis

Final Mapping Summary

Comic 1 Waterfall

Comic 2 Agile

Comic 3 DevOps

Answer the questions below

What Software Development Model did the team in Comic 1 follow?

Waterfall

What Software Development Model did the team in Comic 2 follow?

Agile

What Software Development Model did the team in Comic 3 follow?

DevOps

What is the flag?

THM{ONE_TWO_THREE}

Task 1 Introduction

Weaponizing a vulnerability means converting a known weakness in a system or software into a working exploit that attackers can use for unauthorized access or malicious actions.

The primary goal is privilege escalation. Attackers take advantage of one or more vulnerabilities to gradually gain higher access within a system or network.

Modern organizations have a large attack surface. This includes physical devices virtual machines cloud resources and mobile platforms all of which may contain exploitable weaknesses.

Vulnerability discovery is increasing. Databases like the National Vulnerability Database show a rising number of reported vulnerabilities which gives attackers more opportunities.

Exploits are often chained together. A single exploit may not be powerful enough but when combined with others it can lead to full system compromise.

Low impact vulnerabilities still matter. Easy to exploit flaws can act as entry points and allow attackers to move deeper into the environment.

Multi stage exploitation is a key concept. Attackers first gain initial access then pivot internally and exploit more critical vulnerabilities.

Defensive understanding is essential. Security engineers must learn how attackers combine vulnerabilities to design better detection prevention and response mechanisms.

This topic builds foundational knowledge. It explains exploit development concepts and real attack scenarios to strengthen both offensive awareness and defensive security skills.

I have understood the basics and I'm ready to start the room.

No answer needed

Task 2 Exploit

An exploit is a technical method or tool used to take advantage of a vulnerability in a system or software. It allows attackers to execute actions that the system was not designed to permit.

Exploits can appear in many forms. They may be executable files email attachments malicious links hidden files or payloads delivered through messages removable media or other digital channels.

Once executed an exploit can enable remote or local control disrupt system operations steal sensitive data install malware or misuse system resources.

There are two main types of exploits. Local exploits require existing access to a system and are commonly used for privilege escalation. Remote exploits are launched over a network to gain access without prior authorization.

Exploits are not limited to connected systems. In standalone environments they can be delivered using USB drives or other physical media.

Different threat actors develop exploits. These include nation states for espionage organized crime groups for financial gain and underground hackers selling exploits on dark web markets.

An exploit is a means not an end. It is used to achieve larger objectives such as persistence data theft lateral movement or full system compromise.

Exploit development is complex. It demands advanced security knowledge constant updates and skilled professionals which makes high quality exploits valuable and expensive.

What is the term for an exploit that is used to gain control of a system remotely?

remote exploit

Task 3 Vulnerability Lifecycle

• The Vulnerability Lifecycle explains how a security weakness is identified, handled, and resolved.
• The Department of Defense(DoD) uses a Vulnerability Disclosure Program to manage this process through structured stages.
• A VDP focuses on triage, validation, coordination, and mitigation of reported vulnerabilities.

Key Stages of the Vulnerability Lifecycle

Stage 1 : Discovery

A vulnerability is identified by researchers, vendors, or security teams.
It may be private or publicly disclosed.
A zero day vulnerability is discovered but not yet publicly known.
Vendors often start working on fixes before public disclosure.

Stage 2 : Coordination

The vulnerability details are shared securely between researchers and the vendor.
Disclosure is handled carefully to avoid misuse.
This stage ensures responsible reporting and controlled communication.

Stage 3 : Mitigation

A proof of concept or exploit may be developed to confirm exploitability.
Vendors design solutions to prevent exploitation.
Keeping details confidential is critical to stop attackers.

Stage 4 : Management

The vendor develops and releases a patch or update.
Organizations track affected systems and plan patch deployment.
Risk is managed until systems are fully secured.

Stage 5 : Lessons Learned

Organizations analyze how the vulnerability occurred.
Security controls and development practices are improved.
Knowledge gained is used to prevent similar issues in the future.

Practical Vulnerability Flow

1. Product Launch : A hardware or software product is released into the market.
2. Vulnerability Discovery : Researchers find weaknesses either privately or publicly.
3. Proof of Concept or Exploit : A demonstration is created to show the vulnerability is real.
4. Patch Development : The vendor builds a fix to close the security gap.
5. Patch Release : The patch is officially made available to customers.
6. Patch Installation : Users apply the patch and secure their systems.

A vulnerability not patched by the vendor and unknown to most people is called a?

0-day

What is a commonly used term for a demonstration that proves the exploitability of a newly discovered vulnerability?

Proof of concept

What does a product manufacturer typically release to prevent a known vulnerability from being exploited by adversaries?

patch

Task 4 Opportunity for Weaponizing Vulnerabilities

Weaponizing a vulnerability means turning a known weakness into a working exploit. It requires strong technical knowledge of the target software hardware or system. The process varies based on the technology being targeted and its complexity. Time skill and deep understanding are essential to make a vulnerability exploitable.

Methods Used to Weaponize Vulnerabilities

Exploits can be developed locally by attackers or security researchers.
They can also be bought from underground forums or specialized marketplaces. Both methods aim to create reliable and repeatable exploitation techniques.

Opportunity Window for Exploitation

The opportunity period is the time between vulnerability discovery and patch application.

This window depends on several factors :

• Availability of patches
• Time taken to discover the vulnerability
• Severity and impact of the flaw
• User or organization delay in applying updates

Zero Day and N Day Exploits

A zero day vulnerability is unknown to the public and has no available patch. Exploiting zero day vulnerabilities may take days months or even years. Such attacks are usually targeted and require extensive effort. An n day vulnerability refers to a flaw where a patch already exists. Here n indicates the number of days since the patch was released.

Role of CVE and Public Disclosure

• The exact discovery date of a vulnerability is usually unknown.
• CVE databases record the date of CVE ID assignment and publication.
• CVEs are often published when vendors release patches.
• Attackers can reverse engineer patches to identify the vulnerability.

Exploit Development Timeline

• Most public exploits appear within the first week after patch release.
• Delaying CVE announcements gives customers more time to update systems.
• Once a CVE is published vulnerability details become publicly accessible.

Defensive Response

Security vendors start building detection signatures after CVE release.
Prevention and mitigation strategies are deployed to protect systems.
Faster patching reduces the exploitation window significantly.

Can it take days, months, or even years to develop a 0-day exploit? (yea/nay)

yea

An exploit developed once the vendor has released the patch is called?

n-day

Task 5 Exploit Chaining

Exploit chaining also called multi stage exploitation is the technique of combining multiple vulnerabilities to fully compromise a system.
Instead of relying on a single flaw attackers link several exploits together.
The final objective is usually full Remote Code Execution with the highest privileges.

Goal of Exploit Chaining

• The main aim is to bypass multiple layers of security.
• Attackers gradually increase their level of access.
• A successful chain gives complete control over the target system or network.

Chaining Exploits Lifecycle

1. Reconnaissance :

• The attacker collects information about the target environment.
• This includes network scanning port scanning and vulnerability scanning.
• The goal is to identify potential weaknesses that can be exploited.

2. Initial Exploit :

• An unpatched or misconfigured vulnerability is targeted first.
• This exploit provides initial access to the system.
• It is often a low privilege or limited access entry point.

3. Privilege Escalation :

• Additional vulnerabilities are used to gain higher privileges.
• Attackers may access system files credentials or administrative functions.
• This step is critical for deeper system control.

4. Persistence :

• The attacker ensures long term access to the system.
• Backdoors scheduled tasks or malicious services may be installed.
• Persistence allows access even if the initial vulnerability is fixed.

5. Lateral Movement :

• The attacker moves across the network to other connected systems.
• Exploits and stolen credentials are used to compromise more resources.
• This expands control and increases data exposure.

6. Remote Code Execution :

• The final exploit in the chain enables RCE.
• Attackers can run arbitrary code with maximum privileges.
• This may involve kernel level exploits or malware deployment.

Why Exploit Chaining Is Effective

• Multiple small weaknesses combine into a major breach.
• Security controls are bypassed step by step.
• Detection becomes harder as each stage looks less severe alone.

Defensive Measures

• Regular patching and updates reduce exploitable entry points.
• Strong network segmentation limits lateral movement.
• Monitoring logging and least privilege access help disrupt exploit chains.

What is the technique called to string together multiple exploits?

Exploit chaining

After initial access to the system, the process for gaining higher access within the system is called?

Privilege escalation

The step in which the adversary tries to maintain long time access to the system is called?

persistence

Task 6 Chaining Multiple Vulnerabilities

• This case study explains exploit chaining to achieve complete Remote Code Execution.
• Focus is on understanding how vulnerabilities are linked together rather than tool usage.
• It demonstrates how a small initial flaw leads to full system compromise.

Target Setup :

• Windows Server used as the target machine.
• A vulnerable web application is hosted on the server.
• AttackBox is used for testing with sqlmap already installed.
• System needs a few minutes after startup to function properly.

Initial Scenario :

• Bob is a Security Engineer assigned to test a web application.
• Target application is hosted at http://10.48.144.120/ai.
• Penetration testing reveals SQL injection and arbitrary file upload issues.
• Goal is to chain these vulnerabilities to gain RCE.

Finding the Initial Entry Point :

• Web application login page contains email and password fields.
• Bob tests normal input and input with special characters.
• Different responses are observed when a quote character is added.
• This behavior indicates a possible SQL injection vulnerability.

Confirming SQL Injection :

• Bob intercepts login requests using browser developer tools or Burp Suite.
• The request URL and parameters are identified.
• The email parameter is suspected to be injectable.

Exploiting SQL Injection with Sqlmap :

• Sqlmap is used to automate exploitation of the SQL injection.
• Tool confirms time based blind SQL injection.
• Backend database is identified as MySQL.
• Operating system is detected as Windows.
• Web server technology is Apache with PHP support.

Chaining to Arbitrary File Upload :

• Sqlmap uses the SQL injection to upload a malicious file.
• A file stager and backdoor are placed in the web root directory.
• The uploaded file is accessible through the browser.

Gaining Initial Server Access :

• The malicious PHP file allows command execution on the server.
• Bob now has a foothold on the system.
• This confirms successful chaining of SQL injection to file upload.

Establishing a Web Shell :

• Bob creates a simple PHP backdoor.
• The backdoor executes system commands via a request parameter.
• The file is uploaded and accessed through the browser.

Achieving Remote Code Execution :

• The web shell allows arbitrary command execution.
• Bob can run system commands and interact with the server.
• This completes the Remote Code Execution chain.

What is the response when we enter email test@chatai.com’ as user email and password 123 in the login form?

undefined

Execute the command whoami, what is the output you receive?

nt authority\system

Have you noticed the file flag.txt in the web root directory? What is the flag value?

THM{010101_PAWNED}

How many files are available in the C:\xampp\htdocs\img folder?

2

Task 7 Automating Common Tasks

Purpose of Automation

• Automation helps security engineers reduce manual effort and human error.
• It improves speed accuracy and consistency in security operations.
• Automated processes help detect and fix vulnerabilities faster.

This reduces the overall risk of successful cyber attacks.

Why Automation Is Important

• Manual security tasks are time consuming and error prone.
• Automation enables continuous monitoring and faster response.
• It strengthens the overall security posture of an organization.

Common Ways to Automate Security Tasks

Scripts

• Scripts are used to automate routine and complex tasks.
• Popular scripting languages include Python PowerShell Bash and PHP.
• Scripts can automate
• Vulnerability scanning
• Log collection and analysis
• Network traffic monitoring
• Incident response steps
• Large data set analysis

Example Use Case

• A script can scan log files and detect malicious keywords.
• This helps identify suspicious activity early.
• Scripts are flexible and customizable based on needs.

Scheduling Tools

• Scheduling tools automate when tasks are executed.
• Common tools include cron jobs and Windows Task Scheduler.
• They allow scripts to run at fixed intervals without manual effort.

Common Uses

• Regular vulnerability scans
• Automated backups
• Scheduled software updates
• Periodic security reports

Scheduled scanning helps detect new vulnerabilities quickly.
Reports can categorize issues by severity and remediation steps.

SOAR Platforms : Security Orchestration Automation and Response platforms centralize automation.

They integrate multiple security tools into one workflow.

SOAR platforms can automate

• Incident response
• Threat hunting
• Alert handling
• Incident management

They often integrate with

• Firewalls
• Intrusion Detection Systems
• SIEM solutions

Examples of SOAR platforms include Splunk and Shuffle.

Best Practices for Security Automation

1. Testing
   Always test automation in a controlled environment first.
   Avoid deploying untested scripts in production.
2. Documentation
   Ensure scripts are clearly documented.
   This makes maintenance and troubleshooting easier.
3. Logging and Monitoring
   Track automated tasks through logs.
   Monitoring ensures automation behaves as expected.
4. Regular Review
   Review automation workflows periodically.
   Remove outdated checks and add new ones as threats evolve.
5. Updates and Patching
   Keep scripts and tools updated.
   Fix security flaws within automation itself.

As a security engineer, is it important to ensure that automated scripts being executed are acquired from legitimate sources? (yea/nay)

yea

Task 8 Conclusion

Strong security depends on understanding both attacker techniques and defensive practices.

Early detection patching and automation reduce overall risk.
Continuous learning is essential in the field of cybersecurity.

I have completed the room.

No answer needed

Task 1 Introduction

Dynamic Application Security Testing focuses on evaluating a live application by interacting with it the same way an external attacker would. Instead of reviewing source code, this approach targets a running system to uncover security weaknesses that appear during real use.

Task 2 Dynamic Application Security Testing (DAST)

Dynamic Application Security Testing is the practice of testing a live web application to identify weaknesses and vulnerabilities. It follows a black box testing approach where the tester has no prior knowledge of the internal code or architecture. Vulnerabilities are discovered in the same way an external attacker would by interacting with the running application and attempting to exploit flaws manually or with automated tools.

Because the application is tested from an external perspective, DAST helps uncover issues that are visible and exploitable in real world conditions. These findings are often high priority since attackers can discover them without any insider access. DAST does not replace other security testing techniques but works best when combined with them as part of a secure development lifecycle.

Manual vs Automated DAST

Manual DAST
A security professional manually tests the application to identify vulnerabilities. This approach is effective for finding complex issues and business logic flaws that automated tools may miss because they lack functional understanding of the application.

Automated DAST
Automated tools scan the application for known vulnerability patterns. This method is fast and efficient and can be run frequently without human involvement. It is ideal for identifying common issues early in development.

Using both manual and automated DAST together usually provides better coverage than relying on only one method. Manual testing offers depth while automated testing provides speed and consistency.

DAST in the Secure Software Development Lifecycle

Automated DAST is commonly used during testing phases of development. These tools are often optimized for speed to give developers quick feedback and catch simple vulnerabilities early. They are not meant to be exhaustive but to identify obvious issues as soon as possible.

Manual DAST is typically performed less frequently such as weekly or at major milestones to avoid slowing down development. These scans usually involve deeper testing and more aggressive techniques.

Before an application goes live, performing a full web application penetration test is considered best practice to identify any remaining security flaws.

Note that many sources refer to automated DAST simply as DAST while manual DAST is often grouped under traditional web application penetration testing.

DAST Pros and Cons

Pros

1. Identifies vulnerabilities during runtime including deployment specific issues
2. Detects issues like HTTP request smuggling, cache poisoning and parameter pollution that static analysis cannot
3. Works independently of programming language
4. Produces fewer false positives compared to static analysis
5. Can sometimes detect business logic flaws depending on the tool

Cons

1. Limited code coverage and may miss edge case scenarios
2. Some vulnerabilities are harder to detect compared to static techniques
3. Modern JavaScript heavy applications are difficult to crawl
4. Limited guidance on how to fix issues due to lack of code context
5. Some scans can take a long time
6. Requires a running application

Most DAST tools work by running automated tests that follow two core steps

1. Spidering or Crawling : The tool explores the application to map pages endpoints and parameters that can be tested
2. Vulnerability Scanning : Attack payloads are sent to the identified locations to detect possible vulnerabilities. Users can usually customize which attack types are included.

In this room ZAP proxy will be used as the demonstration tool. While many enterprise DAST tools are commercial and expensive they operate on the same fundamental principles. Differences usually lie in detection accuracy reporting dashboards and enterprise integrations.

Is DAST a replacement for SAST or SCA? (Yea/Nay)

Answer: Nay

What is the process of mapping an application’s surface and parameters usually called?

Answer: Spidering/Crawling

Does DAST check the code of an application for vulnerabilities? (Yea/Nay)

Answer: Nay

Task 3 Spiders and Crawlers

Spidering an application with ZAP
Spidering discovers all reachable pages and resources of a running web application by automatically following links from a starting URL. It helps testers understand what parts of the application are accessible before deeper testing.

Why spidering is important

• Builds a clear map of the application structure.
• Defines the scope of security testing.
• Helps uncover hidden or less obvious endpoints.
• Prepares the application for further active or passive scans.

Regular spider in ZAP
The regular spider works by reading HTML responses and extracting links that are directly present in the source code.

How it works
ZAP starts from a given URL and follows every static link it can detect without executing scripts.

1. Open ZAP and go to Tools then Spider.
2. Enter the starting URL http://10.48.143.193:8082/.
3. Leave Context and User empty and click Start Scan.

Important options

• Recurse. Enables deep crawling by following links recursively.
• Spider Subtree Only. Restricts crawling to subfolders of the starting URL.
• Advanced Options. Allows fine tuning of crawl behavior.

Result

• Discovered URLs appear in the Sites tab.
• Out of scope URLs are ignored.
• Only static HTML links are detected.

Spider limitations

The regular spider cannot execute javascript. As a result dynamic links created at runtime are missed. For example the nospiders gallery page is visible in the browser but not detected by the regular spider because it is generated using javascript.

AJAX spider

The AJAX spider is designed to overcome javascript related limitations of the regular spider.

How it works

ZAP controls a real browser such as Firefox or Chrome which renders the page and executes all scripts. ZAP then extracts links from the rendered content.

Advantages

• Detects javascript generated links.
• Reflects real user interaction with the application.
• Ideal for modern dynamic web applications.

Using the AJAX spider

Steps:

1. Go to Tools then AJAX Spider.
2. Enter the starting URL http://10.48.143.193:8082/.
3. Select Firefox as the browser and start the scan.

Result
After the scan completes the Sites tab is updated with additional URLs including the nospiders gallery page which was missed by the regular spider.

Final takeaway
Use the regular spider for quick and simple discovery. Use the AJAX spider when testing modern Javascript heavy applications. Using both provides better coverage during DAST.

ZAP can run an AJAX spider by using browsers without a Graphical User Interface(GUI). What are these browsers called?

Answer: headless

Analysing the Sites tab, what HTTP parameters can be passed to login.php using the POST method? (In alphabetical order and separated by commas)

Answer: pass, user

What other .php resource, besides nospiders-gallery.php was found by the AJAX spider but not by the regular spider?

Answer: /view.php

Task 4 Scanning for Vulnerabilities

Configuring a Scan Policy in ZAP

When performing DAST scans it is important to customize what tests are executed. A tailored scan policy reduces unnecessary payloads, saves time, and produces more relevant results. Since DAST is often used in a white box setup, the technologies used by the application are already known and should guide the scan configuration.

Application context

• Operating system is Linux.
• Web server is Apache 2.4.
• Programming language is PHP without any framework.
• No database is used.

Why scan policy customization matters

If the default scan policy is used, ZAP will attempt irrelevant tests such as SQL injection even though the application has no database. This increases scan time and noise, especially for larger applications. Custom policies help focus only on meaningful attack vectors.

Scan policy management in ZAP

To create or modify scan policies, navigate to Analyse then Scan Policy Manager and click Add to create a new policy.

Scan policy configuration concepts

Each test category in a scan policy has two key parameters.

Threshold

This controls how easily ZAP reports a vulnerability.

• Low threshold produces more findings but increases false positives.
• High threshold reports only high confidence findings but may miss real issues.
• Setting threshold to OFF disables that category entirely.

Strength

This controls how aggressively ZAP tests a category.

• Higher strength runs more payloads and tests.
• Higher strength increases scan duration significantly.

These settings must be tuned per application and improved gradually through testing and validation.

Policy tuning for this application

Since the application does not use a database or XML processing, related tests can be safely disabled. Injection categories tied to databases and XML can be turned off. Cross site scripting DOM based checks should also be disabled as they consume significant resources and slow down scans in this environment.

Running the first active scan

Once the custom scan policy is ready, start an active scan from Tools then

Active Scan.

• Select the starting point as http://10.48.172.35:8082/.
• Enable the Recurse option so all discovered pages are scanned.
• Select the newly created scan policy.
• Leave other options as default and start the scan.

Reviewing scan results

After the scan completes, findings appear in the Alerts section. Each alert includes a description of the vulnerability and the request and response used to identify it.

Validating findings

All results should be reviewed manually. If an alert is incorrect, it can be marked as a false positive by right clicking the alert and selecting Mark as False Positive. This helps keep reports accurate and actionable.

Will disabling some test categories help speed up the scanning phase? (Yea/Nay)

Answer: Yea

There should be two high-risk alerts in your scan results. One is Path Traversal. What’s the name of the other one?

Answer: Cross Site Scripting (Reflected)

Task 5 Authenticated Scans

Dealing with logins

So far scans were limited to public areas of the application. Some vulnerabilities exist only behind authentication. Since ZAP does not know credentials by default it cannot test protected areas. To solve this we must teach ZAP how to log in and maintain a valid session.

Core idea

ZAP records the login process using a ZEST script. This script replays the same requests during spidering and scanning so authenticated pages can be tested.

Important preparation

Disable ZAP HUD from the toolbar before starting. Some features do not work correctly when HUD is enabled.

Recording authentication

ZEST script basics

A ZEST script records and replays a sequence of HTTP requests. For authentication it stores the login flow so ZAP can repeat it automatically.

Steps to record

1. Click Record a New ZEST Script from the toolbar.
2. Give the script a name and select type as Authentication.
3. Set the prefix to the base URL of the application to avoid recording unrelated traffic.
4. Click Start Recording.
5. Open a browser using Open Browser from ZAP.
6. Navigate to http://10.48.172.35:8082/login.php.
7. Log in manually using
   Username nospiders
   Password nospiders
8. Stop recording after successful login.
9. Close the browser if needed.

Script cleanup and testing

Only requests required for login should remain in the script. Unnecessary requests can be deleted. ZAP checks status code and response length to verify success.
Use the Run button in the Script Console to replay the script. A successful login redirects from login.php to cowsay.php.

Creating a context

A context defines which URLs belong together and where authentication rules apply.

Context creation

1. Go to the Sites tab.
2. Right click the base URL of the application.
3. Select Include in Context then New Context.

Authentication configuration

In the Context settings select Authentication.
Choose Script based Authentication.
Load the recorded ZEST script.

Users configuration

At least one user must be defined or ZAP will skip authentication.
In this case credentials are already inside the ZEST script so the user entry is only a requirement not actively used.

Authenticated spidering

Now that authentication is configured ZAP can discover protected resources.

Run the spider again and this time select

• The created Context
• The created User

ZAP should now find additional URLs that require login. New resources can be reviewed in the Added Nodes tab.

Avoiding logouts

Some discovered pages such as logout.php can terminate the session if accessed.

Solution

Right click logout.php in the Sites tab.
Exclude it from the Context.
This prevents ZAP from logging itself out during scans.

Session verification

To ensure ZAP knows whether it is logged in or not we define indicators.

Logged in indicator

Choose a page accessible only after login such as cowsay.php.
Select text related to the logout link.
Right click and flag it as Authentication Logged in indicator for the Context.

Logged out indicator

Choose a page visible when logged out such as aboutme.php.
Select the login link HTML.
Right click and flag it as Authentication Logged out indicator.

Verification strategy

ZAP needs rules on how to check session validity.
Select Poll the Specified URL strategy.
Configure it to poll aboutme.php every 60 requests to verify login state.

Final authenticated scan

Run an Active Scan again.
Select the Context and User.
ZAP will now scan both public and authenticated areas.

Outcome

If configured correctly ZAP discovers a new high risk vulnerability that was previously hidden behind authentication. This confirms authenticated scanning is working correctly.

Which type of script was used to record the authentication process to our site in ZAP?

ZEST scripts
What additional high-risk vulnerability was found on the site after running the authenticated scan?

Remote OS Command Injection

Task 6 Checking APIs with ZAP

Modern web applications rely heavily on APIs. Unlike traditional web apps APIs cannot be easily spidered because endpoints do not usually reference each other. Even if an endpoint name is known its parameters and expected behavior are not obvious. Because of this API security testing depends on proper API specifications rather than crawling.

Core idea

Instead of discovery through spidering API testing relies on API definition files provided by the development team. These files describe all endpoints parameters methods and responses which allows direct security testing.

API descriptions

APIs are commonly documented using standard machine readable formats. These specifications contain everything needed to understand how to interact with the API and are sufficient for security testing.

Common API specification formats supported by ZAP

• OpenAPI formerly Swagger
• SOAP
• GraphQL

Understanding an OpenAPI definition

An OpenAPI file lists all available endpoints under a paths section. For each endpoint it defines

• HTTP methods such as GET or POST
• Required and optional parameters
• Parameter location such as path query or body
• Expected responses

Example explanation

The endpoint /asciiart/{art_id}

• Uses the GET method
• Requires a parameter art_id
• art_id is passed in the URL path
• art_id is of type string

This tells testers exactly how to construct valid requests for the endpoint.

Swagger UI

Because API definition files are designed for machines they can be difficult to read. Many APIs provide a graphical interface called Swagger UI that makes exploration easier.
The Swagger UI allows

• Viewing endpoints in a readable format
• Sending test requests
• Understanding parameters and responses visually

Note on production environments

Production systems may hide API definitions to reduce exposure. In such cases testers should request the specification directly from the development team.

Importing an OpenAPI definition into ZAP

ZAP allows importing API definitions either from a local file or directly from a URL.

Steps to import from a URL

1. Go to Import.
2. Select Import an OpenAPI definition from a URL.
3. Enter http://10.48.172.35:8081/swagger.json.
4. Click Import.

Result of import

All API endpoints and parameters appear in the Sites tab. ZAP treats them like normal web resources and immediately applies passive scanning rules.

Scanning the API

Once the API definition is loaded it can be tested like any other target.

Steps to scan

1. Right click the API base URL in the Sites tab.
2. Select Attack then Active Scan.

Outcome

After the scan completes ZAP reports vulnerabilities found in the API endpoints. These findings can then be reviewed and used to answer task questions or improve API security.

What high-risk vulnerability was found on the /asciiart/generate endpoint?

Remote OS Command Injection

Read the details on the Path Traversal vulnerability detected. Based solely on the information presented by the scanner, would you categorise this finding as a false positive? (yea/nay)

yea

Task 7 Integrating DAST into the development pipeline

When people talk about DAST in real projects they usually mean automated scanning inside the development pipeline not manual testing. The goal is early visibility of vulnerabilities without slowing developers into misery.

Why DAST in CI CD is tricky

Adding DAST sounds simple until reality shows up. A few decisions must be made carefully.

Key considerations

• Decide at which stages scans should run.
• Decide what triggers a scan such as every commit or scheduled runs.
• Decide scan intensity since full scans can take a long time.
• Balance security coverage with developer productivity.

No single setup works everywhere. Security and development teams must agree on a setup that finds issues early without breaking the pipeline flow.

Pipeline overview

The environment already includes a full CI CD setup.

Main components

• Gitea repository at http://10.48.172.35:3000/ storing application and API code.
• Jenkins instance at http://10.48.172.35:8080/ running the pipeline.

Pipeline behavior

Whenever a commit is made in Gitea Jenkins automatically

• Pulls the code.
• Builds a Docker image.
• Deploys the application container.

Automated scanning with zap2docker

To automate ZAP we use zap2docker which is a Docker version of ZAP built for automation. It removes the pain of manual setup and fits nicely into pipelines.

Scan types available
Baseline scan

• Short spidering only.
• No active scanning.
• Fast and suitable for every commit.

Full scan

• Full spidering and active scanning.
• Very thorough.
• Very slow and unsuitable for frequent commits.

API scan

• Targets APIs using OpenAPI GraphQL or SOAP definitions.
• Requires an API specification file.

In baseline and full scans passive scan results are capped at ten alerts. An AJAX scan can also be enabled if needed.

Integrating ZAP into Jenkins

The environment already has zap2docker installed. Jenkins just needs to be told to run it.

Jenkins project structure

Inside Jenkins there is an organization called thm.

It contains two repositories :

• simple webapp
• simple api

Each repository has a main branch with builds already configured.

Existing pipeline stages

• Build Docker image.
• Deploy Docker image.

These stages are defined inside the Jenkinsfile stored in each repository.

Adding ZAP scanning

A third stage is already present in the Jenkinsfile but commented out. This stage runs a baseline ZAP scan after the container is built.

Why baseline scan only

This scan runs on every commit. Running a full scan here would slow the pipeline badly. The goal is to catch obvious issues early not everything under the sun.

Enabling the scan

• Open the Jenkinsfile in Gitea.
• Uncomment the ZAP scan stage.
• Commit the changes.

Jenkins automatically detects the commit and starts a new build.

Observing the build

A new stage called Scan with OWASP ZAP appears in the build.
The scan takes around five minutes.

The build fails because vulnerabilities are found. This is expected behavior not a disaster.

Reviewing scan reports

To view the results

• Open the failed build in Jenkins.
• Go to the Workspace section.
• Open the zap reports folder.

Download the report and open it locally. Opening it directly in Jenkins breaks formatting because life is unfair.

Repeat for the API

1. Follow the same process for the simple api repository.
2. Enable the ZAP stage.
3. Trigger a build.
4. Download the API scan report.

Final takeaway

Integrating DAST into CI CD gives fast feedback on security issues. Using lightweight scans on every commit keeps developers moving while still catching real problems early. Full scans can wait for later stages when time is less precious.

Download the ZAP report for the simple-webapp repository. How many medium-risk vulnerabilities were found?

3

Check the main branch of the simple-api repository on Jenkins. One of the builds failed during the Build the Docker image step. What is the number of the pre-existing failed build?

4

Download the ZAP report for the simple-api repository. What high-risk vulnerability was found?

Remote OS Command Injection

Task 8 Conclusion

This room introduced the fundamentals of Dynamic Application Security Testing and demonstrated how OWASP ZAP can be used for both manual and automated security testing of web applications and APIs.

Key takeaways

• DAST tests running applications from an external attacker perspective.
• ZAP can perform spidering scanning authenticated testing and API testing.
• DAST works on real deployed applications not source code.

Role of DAST in security

DAST is not meant to replace other security testing methods. It provides value by identifying runtime issues that may not be visible in code reviews.

DAST should be used together with

• SAST for source code level vulnerabilities.
• SCA for vulnerable dependencies and libraries.
• Penetration testing for deep manual exploitation.
• Secure design and threat modeling practices.

Final thought

DAST is not a silver bullet. When integrated properly into the software development lifecycle it strengthens overall application security and helps teams detect vulnerabilities early and continuously.

Task 1 Introduction

This room focuses on Static Application Security Testing or SAST which is a technique used to identify security weaknesses during the application development process. It explains how SAST helps detect issues early, its strengths and limitations, and how it works alongside other security practices to improve application security from the start.

Task 2 Code Review

Code review is a key practice in building secure applications. It involves examining an application’s source code to identify potential security vulnerabilities using a white box approach. Since the reviewer has full access to the code, this method provides wider coverage of application functionality and helps reduce the time needed to discover security flaws.

If vulnerabilities introduced early in development are not addressed, they often persist until the later stages of a project where fixing them becomes more complex, time consuming, and expensive. Code reviews aim to detect these issues early when they are easier and cheaper to resolve.

Cost of Defects in Software

Security defects become more costly to fix as the project progresses through the development lifecycle. Early detection through code review significantly reduces remediation effort and overall cost.

Manual vs Automated Code Review

Code reviews are most effective when manual analysis and automated tools are used together. Each approach has distinct advantages at different stages of development.

Manual code reviews benefit from human judgment and contextual understanding, allowing for deeper and more accurate analysis. However, reviewing very large codebases can be exhausting, increasing the risk of missed vulnerabilities due to human fatigue.

Automated code review tools are highly efficient at detecting common and well known vulnerabilities quickly. They work consistently regardless of codebase size and save significant time. Their limitation is that they rely on predefined rules, so vulnerabilities outside their rule set may go undetected.

From a cost perspective, manual reviews are generally more expensive due to the time and expertise required. Automated tools provide faster results at a lower cost.

For best results, automated code reviews should be run early in the development lifecycle to identify simple and common issues. Manual reviews should be conducted periodically or at key milestones to uncover complex vulnerabilities that automated tools may not detect.

Are automated code reviews a substitute for manual reviewing? (yea/nay)
nay
What type of code review will run faster? (Manual/Automated)
Automated
What type of code review will be more thorough? (Manual/Automated)
Manual

Task 3 Manual Code Review

Before using SAST tools, it is important to understand how manual code review is typically carried out. This makes it easier to see how SAST tools analyse code and detect vulnerabilities.

In this task, the objective is to identify SQL injection vulnerabilities in the source code of a simple application. Although the application contains multiple security issues, the focus here is only on SQL injection to clearly demonstrate how traditional code reviews work and how these steps relate to SAST analysis techniques.

Before proceeding, ensure the virtual machine is running by clicking the green Start Machine button for this task. The machine launches in split view. If it is not visible, use the Show Split View button at the top right of the room.

The source code used in this task is located at
/home/ubuntu/Desktop/simple-webapp/

Searching for Insecure Functions

The first step in manual code review is identifying potentially insecure functions. Since SQL injection is the target vulnerability, attention should be given to functions that execute database queries.

As the application uses PHP and MySQL, the following functions are commonly used to send SQL queries and are often starting points for investigation:

MySQL functions
mysqli_query()
mysql_query()
mysqli_prepare()
query()
prepare()

A simple way to find these functions is by using grep to search through the project files recursively. For example, to search for mysqli_query(), navigate to the project directory and run:

cd /home/ubuntu/Desktop/simple-webapp/html/
grep -r -n 'mysqli_query('

The recursive option searches all files under the directory, while the line number option shows where the match occurs. This search reveals one instance of mysqli_query() in db.php on line 18.

At this point, the presence of the function alone does not confirm a vulnerability. Further analysis is required.

Understanding the Context

Opening db.php shows the following code:

function db_query($conn, $query){
    $result = mysqli_query($conn, $query);
    return $result;
}

Here, mysqli_query() is wrapped inside a custom function called db_query(), and the query parameter is passed directly without modification. Since functions are often abstracted in this way, analysing a single line is not sufficient. The next step is to trace how db_query() is used across the application.

Tracing User Input to Vulnerable Functions

Using grep again to locate calls to db_query():

grep -r -n 'db_query('

This reveals three calls within hidden panel.php. Examining the first instance:

$sql = "SELECT id, firstname, lastname FROM MyGuests WHERE id=".$_GET['guest_id'];
$result = db_query($conn, $sql);

This is a clear SQL injection vulnerability. The value from the guest_id GET parameter is directly concatenated into the SQL query without sanitisation, allowing an attacker to manipulate the query.

The remaining two instances are:

$sql2 = "SELECT id, logtext FROM logs WHERE id='".preg_replace('/[^a-z0-9A-Z"]/', "", $_GET['log_id']). "'";
$result2 = db_query($conn, $sql2);

$sql3 = "SELECT id, name FROM asciiart WHERE id=".preg_replace("/[^0-9]/", "", $_GET['art_id'], 1);
$result3 = db_query($conn, $sql3);

At first glance, both appear protected because the input is filtered using preg_replace(). However, each filter must be carefully evaluated.

In the second query, only alphanumeric characters and double quotes are allowed. Since the value is enclosed within single quotes in the SQL query, the attacker cannot break out of the string. This makes the query safe from SQL injection.

In the third query, only numeric characters are intended to be allowed. However, the third argument of preg_replace() limits the replacement to a single occurrence. This means only the first invalid character is removed, while any remaining malicious characters are left intact. As a result, this query is vulnerable to SQL injection.

Conclusion of Manual Review

Through manual code review, two SQL injection vulnerabilities were identified in the application. While this application is small and easy to analyse, real world applications contain far more complex codebases. Manually tracing functions and data flows in such environments can become time consuming and error prone.

This highlights why manual code review alone is not scalable and why automated SAST tools are useful. In the next steps, SAST tools will be used to perform similar analysis and evaluate how effectively they detect these vulnerabilities.

Bonus Exercise

Continue using manual code review techniques to identify other types of vulnerabilities in the provided project. The guided questions will help structure your analysis.

Local File Inclusion (LFI) attacks are made possible by the misuse of one of the following functions in PHP:
require() include() require_once() include_once()

Answer the following questions using grep to search for LFI vulnerabilities only on the .php files in the html/ directory of the simple-webapp project.
No answer needed

Which of the mentioned functions is used in the project? (Include the parenthesis at the end of the function name)
include()

How many instances of the function found in question 2 exist in your project’s code?
9

Only one of the function’s instances is vulnerable to LFI. Remember that for LFI to be present, the attacker must be able to manipulate a part of what is sent to the vulnerable function. The vulnerable instance must contain some reference to a GET or POST parameter or other manipulable inputs.

What file contains the vulnerable instance?
view.php

What line in the file found on the previous question is vulnerable to LFI?
22

Task 4 Automated Code Review

Static Application Security Testing

Static Application Security Testing or SAST involves the use of automated tools to analyse source code for security vulnerabilities. The purpose of SAST is not to replace manual code reviews but to automate basic and repetitive security checks so vulnerabilities can be detected early without requiring a highly specialised reviewer.

SAST works alongside other security techniques such as Dynamic Application Security Testing and Software Composition Analysis to provide broader coverage across the development lifecycle. Like all security approaches, SAST has strengths and limitations that must be understood.

Pros of SAST

It does not require a running instance of the application
It provides wide coverage of application functionality
It runs quickly compared to dynamic testing techniques
It reports the exact location of vulnerabilities in the source code
It is easy to integrate into CI CD pipelines

Cons of SAST

Source code may not always be available such as in third party applications
It can generate false positives
It cannot detect vulnerabilities that depend on runtime behaviour
Most tools are language specific and only analyse supported languages

SAST Under the Hood

Although SAST tools differ in implementation, most follow two core steps.

First, the source code is transformed into an abstract model. This is usually done using Abstract Syntax Trees or similar structures. This representation allows the tool to analyse code in a structured way that is independent of the programming language. If a language feature is not correctly represented in the model, related vulnerabilities may be missed.

Second, the abstract model is analysed for security issues using different analysis techniques. From a user perspective, the focus is on understanding these techniques rather than the modelling process itself.

Semantic Analysis

Semantic analysis is similar to manually searching for insecure functions during a code review. It focuses on identifying risky function usage within a local context.

For example, directly concatenating user input into a SQL query would be flagged as insecure:

mysqli_query($db, "SELECT * from users where username=".$_GET['username'])

Dataflow Analysis

Dataflow analysis is used when vulnerabilities cannot be identified by examining a function in isolation. Consider the following function:

function db_query($conn, $query){
    $result = mysqli_query($conn, $query);
    return $result;
}

On its own, this function does not appear vulnerable. Dataflow analysis traces how data moves through the application to determine whether user controlled input reaches a dangerous function without proper sanitisation.

In this context, user inputs are called sources and dangerous functions are called sinks. If data flows from a source to a sink without adequate filtering, a vulnerability exists.

Control Flow Analysis

Control flow analysis examines the order in which operations are executed. It is useful for identifying issues such as race conditions, uninitialized variables, and resource leaks.

For example:

String cmd = System.getProperty("cmd");
cmd = cmd.trim();

If the system property is not defined, the first line returns null and the second line causes a runtime exception.

Structural Analysis

Structural analysis evaluates language specific code structures and best practices. This includes detecting dead code, improper exception handling, and weak cryptographic implementations.

Example:

$options = array('private_key_bits' => 1024, 'private_key_type' => OPENSSL_KEYTYPE_RSA);
$res = openssl_pkey_new($options);

Here, RSA is used with a 1024 bit key, which is considered insecure by modern standards.

Configuration Analysis

Configuration analysis focuses on application configuration files rather than source code. Many vulnerabilities arise from insecure configuration settings.

For example, the following PHP settings may expose the application to attacks such as Remote File Inclusion or Server Side Request Forgery:

allow_url_include = On
allow_url_fopen = On

Not every SAST tool implements all of these analysis techniques. However, understanding them provides a useful framework for evaluating and comparing different SAST solutions.

Does SAST require a running instance of the application for analysis? (yea/nay)

Answer: Nay

What kind of analysis would likely flag dead code segments?

Answer: Structural analysis

What kind of analysis would likely detect flaws in configuration files?

Answer: Configuration analysis

What kind of analysis is similar to grepping the code in search of flaws?

Answer: Semantic analysis

Task 5 Rechecking Our Application with SAST Tools

Now that the basics of SAST are clear, we can apply it to a real application. In this task, a simple PHP web application located in the simple webapp folder on the desktop is analysed using an automated SAST tool.

Rechecking Our Application with Psalm

Psalm which stands for PHP Static Analysis Linting Machine is a static analysis tool for PHP. It is already included in the project, so no installation is required.

Navigate to the project directory in the terminal. At the root of the project, there is a psalm.xml file which defines the tool configuration. This file controls how strict the analysis is and which directories are scanned. In this case, only the html directory is analysed, while the vendor directory is excluded to avoid scanning third party libraries.

The errorLevel setting determines how strict Psalm is. Lower values result in more reported issues.

Once inside the project directory, Psalm can be executed using the command provided. When run with default options, Psalm mainly performs structural analysis. It reports coding mistakes such as incorrect operators, type issues, or unsafe coding practices.

An example error highlights the incorrect use of the assignment operator instead of a comparison operator inside an if condition. While this is not a security vulnerability, it can cause logic errors and unexpected behaviour at runtime. Fixing such issues improves code quality and reliability.

Running Dataflow Analysis with Psalm

Psalm also supports taint analysis, which enables dataflow analysis to identify security vulnerabilities. Running Psalm with the taint analysis option produces more security focused results.

In this case, Psalm detects a vulnerability where user controlled input from a GET parameter is concatenated into a file path passed to the include function. This is a classic Local File Inclusion vulnerability. Psalm provides a full trace showing how the data flows from the input source to the dangerous sink function.

Dataflow analysis typically produces the most valuable findings from a security perspective. However, structural issues should not be ignored, as they can lead to subtle bugs or business logic flaws.

False Positives and False Negatives

All SAST tools produce imperfect results. Two types of errors must always be considered.

False positives occur when the tool reports a vulnerability that does not actually exist.
False negatives occur when the tool fails to report a real vulnerability.

In the manual review, three potential SQL injection cases were examined. Two were confirmed as vulnerable, and one was deemed safe due to proper filtering. Initially, Psalm only reported one SQL injection issue. This happened because Psalm considered multiple issues to be the same sink, since they all passed through the same database wrapper function.

By commenting out one vulnerable query, Psalm then reported a different SQL injection. This shows that the tool grouped the findings together instead of treating them separately.

Improving Results with Annotations

To help Psalm better understand the application logic, annotations were added to the database wrapper function. By marking the function parameter as a SQL sink and enabling specialisation, Psalm was instructed to treat each call independently and trace tainted input more accurately.

After adding these annotations and rerunning the analysis, Psalm correctly reported multiple SQL injection paths.

Comparing Manual Review and Psalm Results

The final comparison highlights the strengths and limitations of SAST tools.

The first SQL query was correctly identified as vulnerable by both methods.
The second query was flagged by Psalm but was safe in practice, making it a false positive.
The third query was vulnerable but not detected by Psalm, making it a false negative.

This comparison reinforces an important lesson. SAST tools are extremely useful for scaling security analysis and finding issues early, but they are not perfect. Their results must always be reviewed by a human. SAST should be used as a powerful complement to manual code review, not as a replacement.

What type of error occurs when the tool reports on a vulnerability that isn’t present in the code?
false positive

How many errors are reported after annotating the code as instructed in this task and re-running Psalm?
9

Task 6 SAST in the Development Cycle

Static Application Security Testing is usually introduced very early in the development lifecycle. Since it does not require a running application, it is commonly applied during the coding phase to detect issues as soon as they are introduced.

Ways to Implement SAST

Depending on project needs, SAST can be integrated in different ways.

CI CD Integration

SAST tools can be integrated into the CI CD pipeline so that every pull request or merge triggers a security scan. This ensures that code entering the main branch has passed basic security checks. In some cases, running SAST only during merges instead of on every pull request helps reduce delays in the pipeline and avoids slowing down developers.

IDE Integration

SAST tools can also be integrated directly into developers’ IDEs. This allows issues to be detected while code is being written, enabling developers to fix problems immediately rather than later in the process. Early fixes save time and reduce overall development costs.

In many projects, using both approaches together is ideal. IDE integrations can focus on fast structural checks and secure coding practices, while CI CD pipelines can run deeper and more time consuming analyses such as taint or dataflow analysis. The exact setup should be chosen based on the project’s requirements and team workflow.

Integrating SAST in IDEs

The virtual machine includes VS Code with SAST tools already configured.

Psalm

Psalm supports IDE integration through a VS Code plugin available in the Visual Studio Marketplace. It provides real time feedback while coding and highlights structural issues directly in the editor. Taint analysis is not available in the IDE version, so only basic analysis results are shown.

Semgrep

Semgrep is another SAST tool available as a VS Code extension. It displays inline alerts and can be customised using user defined rules. The rules used in this project are located in the semgrep rules directory within the project folder. Creating custom rules is outside the scope of this task.

Both tools display detected issues directly in the code. Semgrep scans the entire project when VS Code starts and reports all findings, while Psalm reports issues only in the file currently being edited.

Working with SAST Alerts in VS Code

Detected issues appear inline in the editor. Hovering over a highlighted line provides more details about the problem. A complete list of detected issues can also be viewed through the Problems panel at the bottom of the VS Code interface.

Using SAST tools directly in the IDE helps developers write cleaner and more secure code, contributing significantly to the overall security of the final application.

Use both Psalm and Semgrep in the IDE to answer the questions at the end of this task.

How many problems in total are detected by Semgrep in this project?

Press enter or click to view image in full size

Answer: 27

How many problems are detected in the showrecipe.inc.php file?

Press enter or click to view image in full size

Answer: 8

Open showrecipe.inc.php. There are two types of problems being reported by Semgrep in this file. One is identified as “tainted-sql-string” and refers to possible SQL injections.

What other problem identifier is reported by Semgrep in this file? (Write the id reported by Semgrep)

Press enter or click to view image in full size

Answer: echoed-request

What type of vulnerability is associated with the problem identifier on the previous question?

Answer: Cross-site Scripting

Task 7: Conclusion

SAST is one of the many techniques that help improve application security during the development phase. Using tools such as Psalm demonstrates how automated static analysis can significantly reduce the time and effort required compared to fully manual code reviews. However, like all automated solutions, SAST results must be manually reviewed to confirm their accuracy, since false positives can occur.

To gain a more complete understanding of application security testing, exploring Dynamic Application Security Testing is recommended, as it complements SAST and further strengthens a secure development process.

Overview
This room covers the remaining OWASP API Security principles after the first five studied earlier. The focus is on understanding risks impact and mitigation.

Key learning objectives
a. Identifying security misconfigurations in APIs
b. Preventing Denial of Service attacks against APIs
c. Ensuring proper logging and monitoring mechanisms

Learning prerequisites
Before starting this room it is recommended to understand
a. How websites work
b. HTTP protocols and methods
c. Basic security principles
d. OWASP Top 10 web vulnerabilities

Machine and environment details
a. Operating system used is Windows
b. Tool used is Talend API Tester free edition
c. Backend application is Laravel based

Goal
Begin hands on learning with the configured environment to understand remaining OWASP API security principles

TASK 1.1 I can connect and log in to the machine.
No answer needed

Task 2 | Vulnerability VI — Mass Assignment

How it happens
Mass assignment occurs when client side input is automatically mapped to server side objects or variables. Attackers study application logic and send crafted requests to modify sensitive fields. This is common in modern frameworks like Laravel and Code Ignitor.

Example scenario
A user profile page allows updates to email name and address.
Username is read only on the UI but an attacker modifies it in the request.
If the server does not filter fields properly the database gets updated with tampered values.

Why it is dangerous
Server trusts all incoming fields.
Hidden or restricted fields can be modified by attackers.
Business logic is bypassed.

Likely impact
Data tampering in the database.
Privilege escalation from normal user to admin.
Unauthorized increase in user benefits such as credits.

Practical example overview
Signup API endpoint is apirule6 user using POST.
Input fields are name username and password.
Database also has a credit field with default value 50.
Developer used mass assignment to store all client data.
Attackers can send a higher credit value and it gets stored.

Core problem
No server side filtering is applied.
Mass assignment blindly inserts all received fields including credit.

Secure approach
Apply server side filtering using a secure endpoint.
Force credit to default value 50 regardless of client input.
Only required fields should be accepted from the request.

Mitigation measures
Understand how the framework handles insert and update operations.
In Laravel use fillable and guarded arrays.
Avoid automatic binding of client input to code variables.
Allowlist only necessary properties that can be updated from client side.

TASK 2.1 Is it a good practice to blindly insert/update user-provided data in the database (yea/nay)?

Nay

TASK 2.2 Using /apirule6/user_s, insert a record in the database using the credit value as 1000.

No answer needed

TASK 2.3 What would be the returned credit value after performing Question#2?

50

Task 3 | Vulnerability VII — Security Misconfiguration

Security Misconfiguration Notes

How it happens
Security misconfiguration occurs when security controls are incorrectly implemented or poorly configured. Common causes include default or incomplete configurations publicly accessible cloud storage misconfigured CORS settings and verbose error messages exposing sensitive details. Attackers exploit these weaknesses to gather information and gain unauthorized access.

Common sources of misconfiguration
a. Public access to API documentation endpoints or logs
b. Default credentials left unchanged
c. Misconfigured web application firewalls
d. Debug mode enabled in production
e. Excessive error details returned in responses

Likely impact
Intruders gain deep knowledge of API structure and components.
Security mechanisms can be bypassed.
Stack traces and error details may expose confidential data file paths and internal logic.
This information helps attackers profile the system and plan targeted attacks.

Practical example overview
Company MHT faced server availability issues.
Bob created a GET endpoint apirule7 ping v to expose server health status.
No error handling was implemented.
On failure the API returned full stack traces including controller route function names and file paths.

Core issue
The API leaks sensitive internal information through detailed error responses.
Attackers can use this data for reconnaissance and exploitation.

Secure approach
Bob created a secure endpoint apirule7 ping s.
Proper error handling was added.
Only minimal and required information is shared with the client.
Internal details are hidden from responses.

Mitigation measures
Restrict administrative interfaces to authorized users only.
Disable default usernames and passwords on public facing systems.
Disable directory listing and apply strict file and folder permissions.
Remove unnecessary code snippets and error logs.
Turn off debugging features in production environments.

TASK 3.1 Is it an excellent approach to show error logs from the stack trace to general visitors (yea/nay)?

Nay

TASK 3.2 Try to use the API call /apirule7/ping_s in the attached VM.

No answer needed

TASK 3.3 What is the HTTP response code?

500

TASK 3.4 What is the Error ID number in the HTTP response message?

1401

Task 4 | Vulnerability VIII — Injection

Overview
Injection attacks are one of the oldest and most common web and API attacks. They happen when user input is not properly validated and is directly processed by backend logic or databases.

How it happens
APIs accept user input and embed it directly into queries or system commands.
Attackers insert malicious payloads into input fields.
The backend executes this input as part of SQL OS or XML processing.
Applications built without secure frameworks are more exposed.

Common types of injection
SQL injection targets databases.
OS command injection targets operating system commands.
XML injection targets XML parsers and configurations.

Why applications are vulnerable
Missing input validation and sanitization.
Dynamic query construction.
No use of parameterized queries.
Custom or legacy frameworks without security protections.

Likely impact
Exposure of sensitive information.
Unauthorized account access.
Data modification or deletion.
Denial of Service conditions.
Complete account takeover or remote code execution.

Practical example summary
Users at company MHT faced unexpected account issues.
A vulnerable login API endpoint allowed unfiltered input.
Attackers used crafted payloads to bypass authentication.
Authorization keys were issued without proper checks.

Secure implementation
A secure login endpoint was introduced.
Parameterized queries replaced dynamic queries.
Framework level input filtering was applied.
Malicious payloads were blocked successfully.

Mitigation measures
Validate and sanitize all client provided data on the server side.
Always use parameterized queries for database access.
Use built in security features of modern frameworks.
Apply Web Application Firewall rules to detect and block injection attacks.

TASK 4.1 Can injection attacks be carried out to extract data from the database (yea/nay)?

Yea

TASK 4.2 Can injection attacks result in remote code execution (yea/nay)?

Yea

TASK 4.3 What is the HTTP response code if a user enters an invalid username or password?

403

Task 5 | Vulnerability IX — Improper Assets Management

Overview
Inappropriate asset management occurs when outdated or unused API versions remain active even after newer secure versions are deployed. These older APIs often lack updated security controls and become attractive targets for attackers.

How it happens
Multiple API versions such as v1 and v2 exist simultaneously.
The system migrates fully to v2 but v1 is not removed.
Older APIs do not include the latest security patches.
Shared databases between API versions increase exposure.
Poor endpoint tracking and incomplete documentation contribute to the issue.

Why it is dangerous
Outdated APIs expose obsolete features.
Security mechanisms are weaker or missing.
Attackers can easily identify vulnerabilities.
Sensitive data may be leaked through legacy endpoints.

Likely impact
Unauthorized access to confidential data.
Excessive data exposure from older endpoints.
Possible full system or server compromise.

Practical example summary
Company MHT developed multiple API versions.
Old version v1 remained accessible on the server.
The endpoint apirule9 v1 user login returned extra user details such as balance and address.
The newer v2 endpoint restricted information properly.

Secure approach
Deactivate and remove unused API versions.
Allow access only to the latest secure endpoints.
Ensure users interact only with the v2 API.

Mitigation measures
Block deprecated APIs at the network level.
Separate development QA and production APIs onto different servers.
Maintain complete and up to date API documentation.
Document authentication error handling CORS policies and rate limiting.
Use open standards to automatically generate API documentation.

TASK 5.1 Is it good practice to host all APIs on the same server (yea/nay)?

Nay

TASK 5.2 Make an API call to /apirule9/v1/user/login using the username “Alice” and password “##!@#!!”.

No answer needed

TASK 5.3 What is the amount of balance associated with user Alice?

100

TASK 5.4 What is the country of the user Alice?

USA

Task 6 | Vulnerability X — Insufficient Logging & Monitoring

Overview
Insufficient logging and monitoring occurs when malicious activity happens on a system but there is not enough recorded evidence to investigate or trace the attacker. Many organizations focus only on infrastructure logs and ignore detailed API level logging.

How it happens
APIs do not log enough request and response details.
Only server or network events are recorded while API activity is ignored.
Critical details like IP address accessed endpoints input data and timestamps are missing.
Logs are not centralized or monitored regularly.

Why it is a problem
Without proper logs it becomes difficult to detect attacks in real time.
Attack patterns cannot be identified or correlated.
Forensic investigation after an incident becomes almost impossible.

Likely impact
Inability to identify the attacker or hacker.
Delayed detection of ongoing attacks.
Higher damage due to lack of visibility and response.

Practical example summary
Company MHT faced repeated attacks in the past.
The attackers could not be identified due to missing logs.
Bob created an API endpoint apirule10 logging.
The endpoint logs user metadata such as IP address and browser details.
Logs are stored in the database for analysis.

Enhanced monitoring approach
Logged data is also forwarded to a SIEM solution.
SIEM helps correlate events and detect suspicious behavior across systems.

Mitigation measures
Use a SIEM system for centralized log management.
Log denied access failed authentication attempts and validation errors.
Ensure logs contain enough detail to identify intruders.
Treat logs as sensitive data and protect them during storage and transfer.
Set up alerts to detect and respond to suspicious activities quickly.

TASK 6.1 Should the API logs be publically accessible so that the attacker must know they are being logged (yea/nay)?

Nay

TASK 6.2 What is the HTTP response code in case of successful logging of user information?

200

Task 7 | Conclusion

Overview
A large portion of the OWASP API Security Top 10 focuses on authorization authentication and security misconfigurations. These areas remain the most common reasons APIs are compromised in real world systems.

Key takeaway
Most API breaches happen due to weak or broken authentication and authorization controls.
Security misconfigurations further increase attack surfaces and simplify exploitation.

Why APIs are targeted
Attackers often focus on well known endpoints.
Modules like sign in role based access and user profile management are frequent targets.
Poorly secured endpoints provide easy entry points into systems.

Developer responsibility
API developers must follow strong cybersecurity best practices.
Critical modules should receive higher security priority.
Access control and identity checks must be implemented correctly and consistently.

Conclusion
Secure API development requires continuous attention to authentication authorization and configuration.
By applying best practices and learning from OWASP guidelines developers can significantly reduce risks.
Building secure APIs is an ongoing process and continuous improvement is essential.

TASK 7.1 I have completed the room.
No answer needed

Task 1 | Introduction

Context Summary
After McSkidys disappearance, TBFC security has become weak and the email protection system has stopped working. Since the filtering tool is offline, staff members must check each suspicious email manually. The SOC team believes that Malhares Eggsploit Bunnies are sending phishing mails to steal user credentials and disrupt SOC mas operations. Some of these mails pretend to be routine TBFC communications, volunteer activities or event information, making them harder to detect. Incorrect decisions could help the attackers move closer to their plan.

Key Points
• TBFC defences are currently weakened
• Email Protection Platform is unavailable
• All suspicious messages must be manually reviewed
• Attackers are sending phishing mails disguised as normal work communication
• Wrong judgments increase the risk of compromise

Learning Objectives
• Identify phishing mails
• Recognise current phishing techniques
• Distinguish between spam and phishing

TASK 1.1 I have access to the Wareville Email Threat Inspector!
No answer needed

Task 2 | Spotting Phishing Emails

Here is your text with all blank line spaces removed while keeping the content exactly the same.

Overview

Phishing remains highly effective because it targets people not technology. With TBFC email protection offline and defences weakened since McSkidy went missing, attackers called the Eggsploit Bunnies are sending tailored phishing messages to steal credentials and disrupt SOC celebration plans.

Main attacker goals

• Credential theft
• Malware delivery via attachments or scripts
• Data exfiltration
• Financial fraud via fake payroll or invoice changes

Spam versus phishing

• Spam is mass unsolicited content meant to annoy or advertise.
• Phishing is targeted and deceptive with the aim of gaining access or sensitive data.
• Not every unwanted mail is dangerous. identify the intent before acting.

Common phishing techniques and how to spot them

Impersonation
Sender pretends to be a coworker, manager or internal service.
Check sender address for mismatch with company domain.

Social engineering
Uses emotion or pressure words like urgent or immediately to force quick action.
Attempts to prevent normal verification by saying do not call or do not reply to usual channels.

Typosquatting and punycode tricks
Domains use lookalike letters or unicode characters that resemble legitimate domains.
Inspect full domain and check headers for encoded ACE values.

Spoofing
Display name shows a trusted identity while headers reveal a different origin.
Check SPF DKIM DMARC results and the Return Path header. failed checks are strong red flags.

Malicious attachments
Files like html or hta can run scripts outside browser sandboxes.
Treat unexpected attachments with extreme caution.

Legitimate service abuse and fake login pages
Attackers use trusted sharing services to host lures that redirect to fake sign in pages.
Verify the URL carefully before entering credentials.

Side channel communications
Attackers move the conversation to text apps or calls to avoid company controls.
Treat out of band requests as suspicious and verify via known internal channels.

Trending flow to watch for
Email claims a trusted share from Dropbox Drive or OneDrive.
Shared item links to a hosted document or a login prompt.
Fake login steals credentials or prompts a manual download of a malicious file.

Triage checklist for each message
• Who sent it compare the visible name to the actual email address.
• Does the domain match internal standards and company email structure.
• Do SPF DKIM DMARC and Return Path look valid in headers.
• Is there an unexpected attachment and what is its file type.
• Is the message asking for credentials approvals payments or unusual actions.
• Are urgency or secrecy cues present that try to stop verification.
• Is a trusted third party used to host content and does the destination URL match expected patterns.
• Has the request moved to a different communication channel.
If multiple checks fail treat the email as phishing and escalate.

How to mark phishing and earn a flag
For every phishing email identify three clear signals such as spoofing impersonation social engineering punycode or malicious attachment. use those signals as evidence when reporting.

Short memory aids
• Verify sender not trust display name.
• Inspect headers for authentication failures.
• Pause on urgency requests verify by known channels.
• Never enter credentials on a page reached from an unsolicited link.

TASK 2.1 Classify the 1st email, what’s the flag?

THM{yougotnumberI-keep-it-going)

TASK 2.2 Classify the 2nd email. What’s the flag?

THM{nmumber2-was-not-tha-thard!}

TASK 2.3 Classify the 3rd email. What’s the flag?

THM{Impersonation-is-areal-thing-keepIt}

TASK 2.4 Classify the 4th email. What’s the flag?

THM{Get-back-SOC-mas!!}

TASK 2.5 Classify the 5th email. What’s the flag?

THM{It-was-just-a-sp4m!!}

TASK 2.6 Classify the 6th email. What’s the flag?

THM{number6-is-the-last-one!-DX!}

TASK 2.7 If you enjoyed today’s room, you can explore the Phishing Analysis Tools room in detail!

No answer needed

Task 1 | Introduction

• The Open Worldwide Application Security Project is a global community focused on improving application security.
• In 2019 the project released the top ten API vulnerabilities list.
• This module covers the first five principles in Part one and the remaining principles in Part two.

TASK 1.1 I can connect and log in to the machine.

No answer needed

Task 2 | Understanding APIs — A refresher

What an API is
• A communication layer that lets two software components interact
• Uses structured requests and responses
• Application means any software with a specific function
• Interface means the contract that defines how communication works
• Documentation explains how requests and responses must be structured
• APIs are core building blocks for modern enterprise applications

Major Breaches Linked to API Weakness

LinkedIn 2021
• Data of more than seven hundred million users scraped through API misuse
• Exposed names emails phone numbers locations profile links and work details

Twitter 2022
• More than five point four million user records offered for sale
• Zero day in API revealed accounts linked to phone numbers or emails

Pixlr 2021
• Nearly one point nine million users affected
• Exposed usernames emails country information and hashed passwords

Why It Matters

• Insecure APIs can leak sensitive data at massive scale
• Breaches damage user trust and increase financial risk
• Understanding these incidents prepares you to apply OWASP API Security Top Ten principles

Task 2.1 In the LinkedIn breach (Jun 2021), how many million records (sample) were posted by a hacker on the dark web?

1

Task 2.2 Is the API documentation a trivial item and not used after API development (yea/nay)?

nay

Task 2.3 I understand the APIs and am ready to learn OWASP Top 10 Principles.

No answer needed

Task 3 | Vulnerability I — Broken Object Level Authorisation (BOLA)

How it happens
• API uses object IDs to fetch or update data
• If the endpoint does not verify who is requesting the data users can change the ID and access someone else’s information
• This is the same concept as IDOR

Likely impact
• Unauthorised access to sensitive data
• Possible full account takeover
• Major risk to user privacy and company reputation

Example explained
• Endpoint returns user details based only on ID
• No check is done to confirm if the caller is authorised
• Anyone can request any ID and get confidential data
• Adding an authorisation token in the header fixes the issue
• Invalid or missing token should return a forbidden response

Mitigation
• Enforce proper authorisation checks at code level
• Validate that the logged in user is allowed to access the requested object
• Use strong random tokens for reliable access control

Task 3.1 Suppose the employee ID is an integer with incrementing value. Can you check through the vulnerable API endpoint the total number of employees in the company?

3

Task 3.2 What is the flag associated with employee ID 2?

THM{838123}

Task 3.3 What is the username of employee ID 3?

Bob

Task 4 | Vulnerability II — Broken User Authentication (BUA)

How it happens
• Authentication is poorly implemented or incompletely validated
• API accepts incorrect or partial credentials like checking only email and ignoring password
• Missing security controls such as authorisation headers or tokens
• Attackers can abuse weak authentication endpoints to impersonate users

Likely impact
• Attackers can hijack sessions or bypass authentication
• Sensitive data becomes easily accessible
• Attackers can perform actions as another user including full account takeover

Example summary
• Login endpoint is built to return a token after verifying email and password
• Developer checks only the email in the query and ignores the password
• Anyone with the victim’s email can obtain a valid token
• Fix is to validate both email and password properly in the login logic

Mitigation
• Enforce strong passwords with high entropy
• Never expose credentials in requests
• Use secure JWTs and proper authorisation headers
• Implement MFA, account lockout, captcha to slow brute force attempts
• Store passwords with strong hashing not in plain text

Task 4.1 Can you find the token of hr@mht.com?

cOC%Aonyis%H)mZ&uJkuI?_W#4&m>Y

Task 4.2 To which country does sales@mht.com belong?

China

Task 4.3 Is it a good practice to send a username and password in a GET request (yea/nay)?

Nay

Task 5 | Vulnerability Ill — Excessive Data Exposure

How it happens
• API returns more information than necessary
• Developers expose all object properties without checking sensitivity
• They rely on front end filtering rather than limiting data at the API level
• Attackers can intercept responses and extract hidden sensitive fields
• Security tools may flag this but cannot judge which data is legitimate to return

Likely impact
• Attackers can access confidential information like phone numbers account details and access tokens
• Sensitive tokens in responses can be reused to call other critical endpoints
• Data leakage can be large scale if responses consistently include unnecessary fields

Example summary
• A comments portal stores comment text and other internal metadata
• Developer creates an endpoint that returns all stored fields including sensitive ones
• Front end is expected to hide unnecessary data but the API itself exposes everything
• Fix is to create an endpoint that returns only the minimal required fields

Mitigation
• Never depend on front end filtering for sensitive data
• Regularly review API responses to ensure only necessary fields are included
• Avoid generic serialization methods that expose entire objects
• Test API endpoints with different cases to confirm no unintended data is leaked

Task 5.1 What is the device ID value for post-ID 2?

iOS15.411

Task 5.2 What is the username value for post-ID 3?

hacker#!

Task 5.3 Should we use network-level devices for controlling excessive data exposure instead of managing it through APIs (programmatically) — (yea/nay)?

Nay

Task 6 | Vulnerability IV — Lack of Resources & Rate Limiting

How it happens
• API does not restrict how often a client can send requests
• No limits on payload size or file uploads
• Attackers can spam endpoints or upload massive files
• Leads to heavy resource usage across network storage and compute
• Can cause denial of service and make the application unavailable
• Lack of captcha on login or recovery forms allows automated abuse through scripts

Likely impact
• Direct attack on the availability principle of security
• Downtime damages brand reputation
• Financial loss due to excessive resource consumption or misuse of paid services

Example summary
• A company uses an email marketing plan with limited monthly emails
• Developer creates an OTP endpoint but adds no rate limiting
• Attacker can brute force the endpoint and trigger thousands of emails in seconds
• Fix is to enforce rate limiting so users must wait before requesting another OTP

Mitigation
• Use captcha to block automated scripts
• Implement rate limits for how frequently clients can call the API
• Set maximum allowed data size for all parameters and request payloads

Task 6.1 Can rate limiting be carried out at the network level through firewall etc. (yea/nay)?

Yea

Task 6.2 What is the HTTP response code when you send a POST request to /apirule4/sendOTP_s using the email address hr@mht.com?

200

Task 6.3 What is the “msg key” value after an HTTP POST request to /apirule4/sendOTP_s using the email address sale@mht.com?

Invalid Email

Task 7 | Vulnerability V — Broken Function Level Authorisation

How it happens
• A low privilege user bypasses checks and performs actions meant for high privilege roles
• Occurs when access control policies are complex or poorly separated between regular and admin functions
• Weak role validation lets intruders impersonate privileged users
• Similar to IDOR but focused on permissions for functions rather than objects
• APIs with many user roles and hierarchical permissions are more vulnerable

Likely impact
• Targets the authorisation and non repudiation principles of security
• Intruders may impersonate privileged users
• Attackers may gain admin rights and perform sensitive operations

Example summary
• Developer adds an endpoint to fetch all employee data and protects it with a custom isAdmin header
• A non admin user can simply set isAdmin to one and access everything
• Root cause is trusting client side indicators instead of checking roles in the backend
• Fix is to validate the actual user role from the database before allowing admin functions

Mitigation
• Design and test authorisation systems carefully and deny access by default
• Allow operations only for users who actually belong to the authorised group
• Review all API endpoints for functional authorisation flaws and ensure logic aligns with business role hierarchy

Task 7.1 What is the mobile number for the username Alice?

+1235322323

Task 7.2 Is it a good practice to send isAdmin value through the hidden fields in form requests — yea/nay?

Nay

Task 7.3 What is the address flag of username admin?

THM{3432$@#2!}

Task 8 | Conclusion

• This module covered core API security principles related to authentication, authorisation and data handling
  • You learned how weak controls can lead to excessive data exposure, privilege misuse and account takeover
  • Practical examples showed how simple implementation mistakes can create serious vulnerabilities
  • Part two will cover the remaining five OWASP API security principles

Task 8.1 I have completed the room (Part 1).

No answer needed

Task 2 : Username Enumeration

We want to find which usernames already exist on the Acme IT Support website.
Why? Because later, these usernames might help us find authentication vulnerabilities (ways to log in without proper permission).

How do we do it?
We notice that if we try to sign up with a username that’s already taken (like admin), the site gives a message:

“An account with this username already exists.”

This is a clue. It means we can test lots of usernames, and whenever we see this message, we know the username is valid and already in the system.

The tool we’ll use: ffuf

• ffuf is a program that can quickly try many possible usernames from a list.

We give it:

• A wordlist (a file with many common usernames)

The URL of the signup page

• The form data that needs to be sent (username=FUZZ&email=x&password=x&cpassword=x)
• FUZZ is a special placeholder — ffuf replaces it with each username from the list, one by one.
• The error message text we’re looking for (username already exists).

When ffuf runs, it tells us which usernames triggered that exact error message — meaning they already exist.

What to do next:

• Save those found usernames into a file named valid_usernames.txt.
• We’ll use that file later for another task.

What is the username starting with si*** ?

simon

What is the username starting with st*** ?

steve

What is the username starting with ro**** ?

robert

Task 3 : Brute Force

Now that we have a list of real usernames (valid_usernames.txt from the last task), we’re going to try to guess their passwords using a brute force attack.

What is a brute force attack?
It’s when a tool automatically tries many username–password combinations until it finds one that works.

What we’re doing:

• We’ll test every username from valid_usernames.txt
• Against many common passwords from a password list (in this case, 10-million-password-list-top-100.txt)
• We’ll use ffuf again to automate the process.

Breaking down the ffuf command:

ffuf -w valid_usernames.txt:W1,/usr/share/wordlists/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 \
-X POST \
-d "username=W1&password=W2" \
-H "Content-Type: application/x-www-form-urlencoded" \
-u http://10.201.77.177/customers/login \
-fc 200

• -w valid_usernames.txt:W1, ... :W2 → We’re using two wordlists:
• W1 = usernames from our file
• W2 = passwords from the common password list
• -X POST → We’re sending a POST request (because it’s a login form).
• -d "username=W1&password=W2" → This is the login form data. ffuf replaces W1 and W2 with usernames and passwords from our lists.
• -H "Content-Type: application/x-www-form-urlencoded" → Tells the site we’re sending form data.
• -u http://10.201.77.177/customers/login → The login page URL.
• -fc 200 → We’re filtering out (ignoring) results that have HTTP status code 200 (which means “OK” but likely means “login failed” here). If we get a different status code, that might mean a successful login.

Goal:
Run this and ffuf will tell us the one correct username–password pair that works. That’s the answer to the task question.

What is the valid username and password (format: username/password)?

steve/thunder

Task 4 : Logic Flaw

A logic flaw happens when a website’s normal checks can be tricked so that you skip or bypass them. In this case, the password reset feature is built in a way that lets you send the reset link to yourself instead of the real account owner. Normally, you type the account’s email first, then the username, and the system sends a reset link to that account’s email. The problem is the site uses both the email in the URL (GET request) and the email from the form (POST request), but if both exist, it trusts the POST one more.

That means if you visit the reset page with Robert’s email in the URL, but in the form data you send your own email, the server will ignore Robert’s email and send the reset link to you. If you create your own account first, you can use your account’s special @customer.acmeitsupport.thm email in that POST field. When you do this, the reset link for Robert’s account shows up in your account’s support ticket, letting you log in as Robert and see his private information.

What is the flag from Robert’s support ticket?

THM{AUTH_BYPASS_COMPLETE}

Task 5 : Cookie Tampering

Cookies are little pieces of data a website saves in your browser while you use it. They can store things like whether you’re logged in, your user ID, or even your admin status. If a website isn’t careful with how it uses cookies, you can sometimes change them and get more access than you should.

In the first example, the website sends two cookies after you log in:

logged_in=true
admin=false

If you change logged_in to true, the site thinks you’re logged in. If you also change admin to true, the site will think you’re an admin and give you full access — even if you’re not supposed to have it. You can test this by sending requests with curl and adding your own Cookie: header to control the values.

Sometimes cookies don’t store obvious words like true or false but instead have a long, random-looking string. That string could be:

• A hash (like MD5 or SHA-256) — this is one-way, but you can sometimes look it up in online databases like CrackStation if it’s from a common word.
• Encoded data (like Base64) — this is reversible. You can decode it to see what it really contains, change the values, then re-encode it.

For example, if a cookie looks like this:

session=eyJpZCI6MSwiYWRtaW4iOmZhbHNlfQ==

That’s Base64. Decoding it shows:

{"id":1,"admin": false}

If you change false to true and re-encode it to Base64, the site may think you’re an admin and give you more privileges.

It’s basically about checking if the site trusts the cookie values too much — and if it does, you can edit them to get more access.

What is the flag from changing the plain text cookie values?
THM{COOKIE_TAMPERING}

What is the value of the md5 hash 3b2a1053e3270077456a79192070aa78 ?
463729

What is the base64 decoded value of VEhNe0JBU0U2NF9FTkNPRElOR30= ?
THM{BASE64_ENCODING}

Encode the following value using base64 {“id”:1,”admin”:true}
eyJpZCI6MSwiYWRtaW4iOnRydWV9

Reference: https://tryhackme.com/room/authenticationbypass

• CyberChef is a web-based tool used for:
• Encoding
• Decoding
• Encrypting
• Extracting and processing data
• Uses “recipes” — sequences of operations applied step by step to transform data.

🔧 Task 2: Accessing the Tool

• Can be used online in any modern browser.
• Can also be downloaded for offline use on Windows or Linux.

🧭 Task 3: Navigating the Interface

CyberChef interface has 4 key sections:

1. Operations — List of available functions (e.g., “From Base64”)
2. Recipe — Where you build your sequence of operations (core area)
3. Input — Where you paste or upload your data
4. Output — Shows the processed result

In which area can you find “From Base64”?

Operations

Which area is considered the heart of the tool?

Recipe

🧠 Task 4: Before Anything Else (Your Thought Process)

Follow this 4-step approach:

1. Define your goal — What are you trying to decode or find?
2. Input the data — Paste or upload it into CyberChef
3. Pick operations — Try ones like ROT13, Base64, Base85, URL Decode, etc.
4. Check output — If it’s not what you want, change the recipe and try again.

At which step would you determine, “What do I want to accomplish?

1

🚀 Task 5: Practice, Practice, Practice

Examples of common operations:

• Extracted hidden email → hidden@hotmail.com
• Extracted IP ending in .232 → 102.20.11.232
• Found domain starting with “T” → TryHackMe.com
• Decimal 78 to Binary → 01001110
• URL Encode https://tryhackme.com/r/careers → https%3A%2F%2Ftryhackme%2Ecom%2Fr%2Fcareers

🍳 Task 6: Your First Official Cook

Applied CyberChef to a file and got:

• IP starting and ending with 10 → 10.10.2.10
• Base64 of “Nice Room!” → TmljZSBSb29tIQ==
• URL Decoded version of encoded link → https://tryhackme.com/r/room/cyberchefbasics
• Unix timestamp 1725151258 to readable time → Sun 1 September 2024 00:40:58 UTC
• Base85 decoded string <+oue+DGm>Ap%u7 → This is fun!

🎯 Task 7: Conclusion

• CyberChef is a flexible and easy-to-use tool for handling various data formats.
• Perfect for small-scale data tasks like decoding, converting formats, or extracting information.
• While powerful, it may not be ideal for larger or more complex automation tasks.

Cybersecurity is constantly changing because hackers try to find weaknesses in important systems to steal data or cause damage. To prevent this, strong rules and security measures are needed. Companies must create strict policies, monitor for threats, and follow regulations to protect their systems from attacks.

Learning Goals:

• Learn why rules and regulations are important in cybersecurity.
• Understand global laws, policies, and security standards.
• Know about Governance, Risk Management, and Compliance (GRC).
• Improve cybersecurity skills using standards like ISO 27001 and NIST 800–53.

1.1 — No Answers needed

Task 2 | Why is it important?

Important Terms:

• Governance: Managing an organization to meet goals while following laws and rules.
• Regulation: Laws that must be followed to prevent harm.
• Compliance: Following the rules and laws that apply to a business.

Information Security Governance

This is about protecting an organization’s information by setting up policies, strategies, and risk management processes. It helps prevent cyber threats, ensures data safety, and follows necessary laws.

Key Processes:

1. Strategy: Making a security plan that fits the company’s goals.
2. Policies & Procedures: Creating rules for handling and protecting data.
3. Risk Management: Identifying and reducing security risks.
4. Performance Measurement: Checking if security measures are working.
5. Compliance: Following cybersecurity laws and industry standards.

Information Security Regulation

Security regulations are legal rules that organizations must follow to protect data from hacking, theft, and misuse. Examples include:

• GDPR: Protects the personal data of EU citizens.
• HIPAA: Protects health-related data in the U.S.
• PCI-DSS: Ensures the secure handling of credit card data.
• GLBA: Protects customer financial information in banks and financial institutions.

Benefits of Security Governance & Regulation:

• Stronger Security: Reduces the risk of cyber attacks.
• Trust & Confidence: Customers feel safe sharing their data.
• Legal Protection: Avoids fines and penalties for breaking laws.
• Better Business Alignment: Ensures security fits business goals.
• Smart Decisions: Helps leaders make informed security choices.
• Competitive Advantage: Builds a strong reputation for data protection.

By following cybersecurity governance and regulations, businesses can protect their data, avoid legal trouble, and gain trust from customers and partners.

2.1 — Regulation

2.2 — Healthcare

Task 3 | Information Security Frameworks

An Information Security Framework is a set of documents that guide how an organization protects its data. It includes:

• Policies: Rules that define security goals and guidelines.
• Standards: Specific requirements for security processes.
• Guidelines: Best practices (not mandatory) for improving security.
• Procedures: Step-by-step instructions for security tasks.
• Baselines: Minimum security requirements that must be met.

Steps to Create Security Documents:

1. Identify Scope & Purpose: Define what the document will cover (e.g., password policy for strong passwords).
2. Research & Review: Check laws, regulations, and best practices to ensure accuracy.
3. Draft the Document: Write clear and actionable security rules.
4. Review & Approve: Get feedback from experts and senior management.
5. Implement & Communicate: Train employees and ensure they follow the rules.
6. Review & Update: Regularly update policies based on new threats and regulations.

Real-World Examples:

• Password Policy: Defines rules for creating and managing strong passwords.
• Incident Response Procedure: Details how to handle security breaches (e.g., malware attack, data theft).

Using Existing Security Frameworks:

Companies don’t always create their own standards. Instead, they follow industry-specific frameworks:

• Financial Sector: Uses PCI-DSS, GLBA for data security.
• Healthcare: Follows HIPAA for patient data protection.
• Other Industries: Use standards based on laws and available resources.

By following these frameworks, organizations can protect sensitive data and meet legal security requirements.

3.1 — Review and update

3.2 — Procedure

Task 4 | Governance Risk and Compliance (GRC)

Governance, Risk, and Compliance (GRC) Framework helps organizations manage security, reduce risks, and follow legal rules. It ensures the company operates safely and follows industry standards.

Three Main Parts of GRC:

1. Governance: Sets security rules (policies, standards) and tracks performance.
2. Risk Management: Identifies and reduces risks like cyber threats.
3. Compliance: Ensures the company follows laws and industry standards.

Steps to Build a GRC Program:

1. Define Goals: Decide what the GRC program should achieve (e.g., reduce cyber risks by 50% in a year).
2. Risk Assessment: Find security risks and fix weak points.
3. Create Security Rules: Set policies (e.g., strong password rules, logging access).
4. Establish Governance: Form a security team to review risks and make decisions.
5. Implement Security Controls: Use tools like firewalls, training, and monitoring systems.
6. Monitor & Measure: Track performance and update policies as needed.
7. Improve Continuously: Learn from security incidents and refine the system.

Example — GRC in Finance:

• Governance: Financial policies (e.g., anti-money laundering, fraud prevention).
• Risk Management: Prevent fraud, phishing, and cyber threats.
• Compliance: Follow laws like PCI DSS, use SSL/TLS for secure transactions.

A GRC framework helps businesses stay secure, manage risks, and comply with laws effectively.

4.1 — Risk Management

4.2 — yea

Task 5 — Privacy and Data Protection

Privacy and data protection laws are essential in all sectors (finance, healthcare, government, etc.) to protect people’s personal information (PII). These laws ensure data is handled responsibly, build trust, and prevent misuse.

Important Data Protection Regulations:

1. GDPR (General Data Protection Regulation) — A strict EU law (since 2018) that protects personal data.

• Companies must get permission before collecting personal data.
• Only necessary data should be collected.
• Strong security measures must protect stored data.
• Companies violating the rules face heavy fines (up to 4% of revenue or €20 million).

2. PCI DSS (Payment Card Industry Data Security Standard) — Ensures secure card transactions and prevents fraud.

• Used by businesses handling online card payments.
• Requires strict security measures (firewalls, encryption, monitoring unauthorized access).

These regulations help protect personal data and ensure businesses follow strict security practices.

5.1 — 4

5.2 — cardholder data

Task 6 — NIST Special Publications

NIST 800–53

NIST 800–53 is a security framework by the U.S. National Institute of Standards and Technology (NIST). It provides a set of rules to protect information systems from threats like cyberattacks, errors, and natural disasters. It includes 20 categories (families) of security controls, helping organizations improve their security and follow regulations.

Key Points:

• Helps secure data and systems while ensuring compliance with laws.
• Covers security risks like hacking, system failures, and privacy issues.
• “Program Management” is a crucial part, requiring organizations to plan, implement, and monitor security programs.
• Businesses must regularly check their security measures, track threats, and improve controls over time.

NIST 800–63B

NIST 800–63B is a guide that helps organizations verify users’ identities for secure digital access. It provides rules for authentication methods like passwords, biometrics (fingerprints, face scans), and security tokens.

Key Points:

• Ensures secure login and identity verification.
• Defines different levels of security based on risk.
• Guides organizations on how to store and manage login credentials safely.

Both frameworks help protect information and maintain cybersecurity best practices.

6.1 — Physical

6.2 — Administrative

6.3 — Map

Task 7 — Information Security Management and Compliance

Information Security (IS) management protects data from unauthorized access, use, or damage through planning, implementation, and monitoring of security measures. It includes risk assessment, security procedures, incident response, and awareness training. Compliance ensures organizations follow legal, industry, and regulatory security standards.

ISO/IEC 27001

ISO 27001 is a global standard for setting up and managing an Information Security Management System (ISMS). It includes:

• Defining scope and security policies
• Identifying and managing risks
• Implementing security controls
• Conducting audits and regular reviews

Benefits: Helps organizations improve security, comply with regulations, and manage risks effectively.

SOC 2 (Service Organisation Control 2)

SOC 2 is a security and compliance framework developed by AICPA to assess data protection based on confidentiality, availability, integrity, and privacy. It helps businesses prove their security measures to customers and stakeholders.

SOC 2 Audit Process:

• Define scope and select an auditor
• Review security policies and controls
• Conduct audit and receive a report with findings and improvements

SOC 2 ensures secure handling of sensitive data, especially for service providers dealing with customer information.

7.1 — Risk treatment

7.2 — Availability

Task 8 — Conclusion

This session covered the importance of an effective information security governance and regulation framework to protect an organization’s assets. It discussed key laws like GDPR and PCI DSS, the Governance, Risk Management, and Compliance (GRC) framework, and real-world implementation strategies.

It also introduced governance enablers like ISO/IEC 27001 and NIST standards, emphasizing the need for continuous security improvements due to evolving threats. While 100% security is impossible, proactive measures help mitigate risks.

Stay tuned for more sessions on security governance and policies!

8.1 — THM{SECURE_1001}