AppSec IR Writeup | TryHackMe
Table of Contents:
- Task 2 info
- Task 2 questions/answers
- Task 3 info
- Task 3 questions/answers
- Task 4 info
- Task 4 questions/answers
- Task 5 info
- Task 5 questions/answers
- Practical info/q&a
- Answer Glossary for those who just want the answers and don’t care about the explanations.
Introduction
In this room, we will examine application security (AppSec) and incident response (IR). More specifically, we will learn how shifts in threat landscapes, software architecture, and attacker behavior have made AppSec IR, an intersection of these two practices, increasingly relevant and teach the basics of this hybrid function.
Learning Prerequisites
While this room has no hard prerequisites, in covering AppSec incident response, it does assume an understanding of application security, including some common application-level attacks. Before attempting this room, ensure you understand the basics of these topics:
Learning Objectives
- Understand the intersection between AppSec and incident response
- Understand the steps that can be taken to prepare for an application incident
- Understand the process of responding to an application incident
- Understand the importance of learning from an application incident
Information for task 2
AppSec IR Fundamentals
Application security (AppSec) is fairly self explanatory, it refers to security principals relating to application-layer vulnerabilities, exploits, or breaches.
Incident response (IR) refers to the processes and technologies for detecting and responding to cyberthreats, security breaches, or cyberattacks.
When we combine these two essentially we apply IR to AppSec (AppSec IR) which refers to the overall practice of handling security incidents involving applications.
The goals of AppSec IR are
- Preparation
- Detection & Identification
- Containment
- Eradication
- Recovery
The room will take us through how each of these IR stages apply to an AppSec perspective. To tackle these stages the AppSec-aware responder must think about how the vulnerability got introduced, how it could’ve been prevented, and how fixing it ties back into the software development cycle.
The AppSec IR Collaboration
A big difference between traditional IR and AppSec IR is the level of collaboration between the software development department and the cybersecurity department.
For example the AppSec team might find a vulnerability and start development on a permanent patch, while the cybersecurity/IR team would create a web application security (WAS) rule to temporarily hold off the attacker.
Key Tools for Application-Layer Incident Response
- Application Logs & SIEM: Keeping tabs on what the attacker did is critical for risk and damage assessment, therefore it is imperative that we harness and understand the power and capabilities of logs to capture user activities, errors, input validation failures, etc.. This coupled with security information and event management system (SIEM) can help with the organization of events found in application logs.
- Web Application Firewalls (WAF): This is an application specific firewall that intercepts HTTP traffic and filters it based on a rule set. Common rule sets include SQL injection rules, cross site request forgery (CSRF), or cross site scripting (XSS) among others. Often thought of as a first line of defense, WAFs serve as a quick reaction tool in AppSec IR and can be especially useful during the containment phase.
- Threat Intelligence (feeds/platforms): In combination with a SIEM use various indicators of compromise (IOCs), and tactics techniques and procedures (TTPs) to enrich detections or to tune WAF/RASP rules, and guide triage/prioritization.
- Runtime Application Self-Protection (RASP) RASP is sort of a SIEM combined with a WAF for the internals of an application. An example of this would be a program called seccomp that restricts syscalls on a computer, as a web server program shouldn’t be calling sys_execve for any reason.
These are of course just a few of the tools used in AppSec IR. There is an overlap with DevSecOps, with pipelines and automation further helping teams to rapidly deploy patches or roll back to a safe version.
questions and answers for task 2:
Question 1: Which tool type analyses logs and aggregates security events across applications?
Answer: SIEM
Question 2: Which IR phase focuses on deploying emergency WAF rules to stop an ongoing exploit?
Answer: Containment
Explanation: “WAFs serve as a quick reaction tool in AppSec IR and can be especially useful during the containment phase.”
Information for task 3
Preparing for Application Incidents
Ideally we would like to not get hacked or breached, but if you or your organization possesses sought after or valuable information the odds of you eventually getting hacked are more likely than not. Therefore it’s paramount to prepare for what could happen, when making an AppSec IR plan it’s paramount we must first prioritize containment and a timely response.
Prevention
One of the most effective and fundamental ways of combating AppSec incidents is by preventing them from happening in the first place. The way this applies to AppSec is through something i mentioned earlier called the SDLC. This is known as developing a “Secure by Design” approach, which in the context of AppSec turns your SDLC into an SSDLC (Secure Software Development Life Cycle). Some examples of this include following secure coding practices like input validation, session management, and good error handling.
Observability
Since incidents can still occur we must be able to detect them. Some important events we need to capture are the following
- Authentication attempts
- API calls or transactions
- Server errors
Not only should these events be logged, but they should also be included in your SIEM for real time monitoring, some examples include Elastic Stack, Splunk, and Azure Sentinel. Using these tools alerts can be triggered on suspicious patterns, such as repeated failed logins, observed unusual spikes in traffic or application failures/errors.
Insufficient logging is such a problem in cybersecurity that OWASP has listed “Security Logging and Monitoring Failures” as one of the top security risks for organizations.
Containment Readiness and Incident Response Playbooks
The technical “plans” for containment and response are known as IR playbooks. These are documents that contain a plan to first, limit the chances of an incident occurring, and secondly, to give engineers the best chance at success in later stages of IR. There is also a THM room on IR Playbooks that is a very good resource. They are effectively a way to turn a chaotic situation into an organized response or at least somewhat of an organized response because of course there is always a chance everything falls apart due to an unknown variable and things do erupt into chaos, but the point of an IR paybook is to reduce that as much as possible.
Consider the following made up scenario (not the one from THM):
- The cybersecurity team at example inc. has found there was a web server running bash, their playbook instructs them to first isolate the threat (the web server), now the clock is ticking, hundreds of thousands of dollars may be lost because due to downtime, the playbook then instructs the network forensics specialist to identify the offending IP addresses and blacklist them. After that the forensics team finds which function caused the breach and temporarily disable it, for example if the vulnerability was in the autoindexing function on the server temporarily disabling that function could be enough to bring the server back online until it is patched; on the contrary if the vulnerability was in the session manager it would be more effective to shut down the service entirely. After this the development team patches the vulnerability and the server goes back online. Then the forensics team goes through the logs to find any possible indicators of persistence as well as lateral movement or data exfiltration.
Without this playbook the process for handling even incident like the one just described could erupt into chaos and also might even do more damage than the attacker would’ve done anyways.
Questions and answers for task 3:
What type of document outlines step-by-step actions to contain and respond to specific security incidents?
Question 1: Which approach reduces the likelihood of serious application incidents occurring?
Answer: Secure by Design
Question 2: Which OWASP Top 10 category highlights the risk of poor observability in applications?
Answer: A09: Security Logging and Monitoring Failures
Question 3: What type of document outlines step-by-step actions to contain and respond to specific security incidents?
Answer: IR Playbooks
Information for Task 4
Responding to an Application Incident
My professor who’s been in the industry for over a decade once said “there are two types of companies, those that have been hacked and those that haven’t been hacked yet.” That is why it is imperative that the incident is detected swiftly and the threat is contained.
Detection & Identification
Detection in a real incident typically would come from one of the following sources:
- Log anomalies: If proper logging has been configured (the preparation stage)
- User complaints or reports: Comprehensive and active channels where users can report issues can make all the difference when a user facing application incident occurs.
- Bug bounty: Setting up a bug bounty program where users or other third parties can earn money by identifying existing vulnerabilities is very important.
Containment
If confirmation is received that an incident is ongoing, the first step will always be containment to minimize the impact to the application, its users, and the company.
Here are some common actions that can be taken for the containment of an incident:
- Disable the vulnerable feature or route: This is when some type of application management system comes in handy, we would use this to turn off the vulnerable feature or API endpoint. This would prevent the attacker from being able to access the feature in question, the drawback is that not just the attacker will be kicked off the system, if this is a very important system, it is imperative that the IR playbook contains information and analysis on weather or not the service is worth shutting down or not. Sometimes the entire services doesn’t need to be shut down, sometimes it’s just a certain feature of the application so keep that in mind.
- Apply WAF rules / block malicious traffic: The same things can be said for a WAF, if for some reason it’s not possible to shut the service down in a timely manor, just block all connections to and from it. Although the same problem also arises with the drawbacks of losing a service so make sure that the drawbacks are included in the playbook so the IR team can make a decisive call.
All of these decisions and actions must be made within minutes or even seconds of identifying a threat. But it’s also important to note that these fixes only are temporary until the software development team or specialist on the AppSec team can implement a permanent fix to it.
Questions and answers for task 4
Question 1: What is a common detection method involving incentivizing third parties to find vulnerabilities
Answer: Bug Bounty
Question 2: What specific mechanism allows a vulnerable feature to be disabled instantly without redeploying the application?
Answer: Feature Flag
Question 3: What type of tool is commonly used to block specific malicious traffic patterns or IP addresses during an incident?
Answer: WAF
Information for task 5
Remediation & Recovery
After temporarily implementing countermeasures you’re application may be able to come back online, but this doesn’t settle the incident. The final goal must be to eradicate the threat and recover systems as well as taking any lessons learned from the incident.
Removing the Threat
The goal with the threat now contained is to
- Patch vulnerabilities: The software engineering and development team will now take over to patch the vulnerability that allowed the attackers in.
- Remove malicious artefacts: If the attacker has left malware, web shells, backdoors, or any other malicious code it’s time for that stuff to go.
- Evidence collection: This is now somewhat of a crime scene and it’s now important to preserve and maintain a chain of custody for all evidence of the attack so it can be used on court if need be.
- Reset credentials/revoke accounts: If the forensics team find evidence that the attacker now has access to an account or a collection of accounts during privilege escalation these accounts need to be cleaned up, this includes resetting passwords or API keys.
Additionally applications following a recent incident should be closely monitored with a high priority.
Restoring and Validating Systems
- Validation and testing: Validating that the effected systems are fully secure and functional
- System restoration: Once it is confirmed the systems are secure and function it’s now time to bring the system/feature back online.
- Monitoring for recurrence: With the lessons learned from the previous incident it’s now important that we make sure there are no other instances of a similar vulnerability in the application
At this point the focus should turn towards making a post-mortem, with an emphasis on honesty and the objective of understanding what happened and how to improve.
Get Samuel McLamb’s stories in your inbox
Join Medium for free to get updates from this writer.
Questions and answers for task 5
Question 1: A developer will push a ______ in order to patch the vulnerability and close the security hole.
Answer: Hotfix
Question 2: Routes disabled during the ___________ phase can now be re-enabled during the restoration phase.
Answer: Containment
Question 3: The process of discussing what lessons can be learned from this incident going forward is called what?
Answer: Post-mortem
Question 4: Following this process, what should be produced?
Answer: Incident Report
Task 6 information
Practical
Putting things into action in a simulated environment is what this next task aims to do. We step into the shoes of an AppSec engineer who has just been informed of a critical breach, it’s now up to us to find out how the attacker got information.
We get access to an IP address which is a web server as well as an ssh server.
We get access to the ssh server with the creds appsecir:TryHackMe! and the application logs are located in /home/appsecir/Documents/Logs
Upon visiting the webserver we land on this page:
After poking around here for a minute and not finding anything too interesting, I logged into the server via ssh and took a look at the log file with JLogViewer.
What stands out to me initially are these messages here
This looks just like a IDOR exploit, going off this assumption we take a look at the 105 user.
Sure enough
Now that it seems that we know that the vulnerability its we go to the flag submission link
Answers: Secure coding practices and code review, and A threat model identifying access control flaws.
These answers are apart of the prevention method from the Preparing for Application Incidents task
We can see that the user logs into their account which is sam.jones@company.thm or 106 but then we see that they send this request
This is the first warning for “user_id mismatch” and the first account Sam broke into.
going to the 999 admin user we get see the option to disable the entire users endpoint
clicking on this and then verifying the change in flag submission will move you onto the next question
Sanitizing the input wouldn’t fix the issue because it’s a url and the endpoint would have to be accessed at some point one way or another
Adding authentication middleware to the /users/:id/profile would would but would be inefficient, we don’t need middleware to do this.
Enforcing server-side validation that the session user matches the requested user ID would fix it because we can already see that it knows the difference from the logs, it’s just not enforcing it.
the fourth answer is incorrect.
We can see from the logs that the value in the message field says “user_id mismatch”, it seems that this indicates malicious behavior and should be blocked.
Answer: IR Playbook
Per the definition of an IR Playbook: “These are documents that contain a plan to first, limit the chances of an incident occurring, and secondly, to give engineers the best chance at success in later stages of IR.” Because a playbook includes response procedures, this is the correct answer.
Finally after reviewing the Post-Incident Summary Report we get the flag
Summary of the room:
- We learned what incident response is and why it’s important.
- We learned about the importance of being prepared.
- We learned the process of detection and containerization of the threat.
- We learned about eradicating the threat.
- We learned about the recovery process
- We learned about drawing lessons learned from an incident and applying those lessons to the IR Playbook
Answer Glossary:
questions and answers for task 2:
Question 1: Which tool type analyses logs and aggregates security events across applications?
Answer: SIEM
Question 2: Which IR phase focuses on deploying emergency WAF rules to stop an ongoing exploit?
Answer: Containment
Explanation: “WAFs serve as a quick reaction tool in AppSec IR and can be especially useful during the containment phase.”
Questions and answers for task 3:
What type of document outlines step-by-step actions to contain and respond to specific security incidents?
Question 1: Which approach reduces the likelihood of serious application incidents occurring?
Answer: Secure by Design
Question 2: Which OWASP Top 10 category highlights the risk of poor observability in applications?
Answer: A09: Security Logging and Monitoring Failures
Question 3: What type of document outlines step-by-step actions to contain and respond to specific security incidents?
Answer: IR Playbooks
Questions and answers for task 4
Question 1: What is a common detection method involving incentivizing third parties to find vulnerabilities
Answer: Bug Bounty
Question 2: What specific mechanism allows a vulnerable feature to be disabled instantly without redeploying the application?
Answer: Feature Flag
Question 3: What type of tool is commonly used to block specific malicious traffic patterns or IP addresses during an incident?
Answer: WAF
Questions and answers for task 5
Question 1: A developer will push a ______ in order to patch the vulnerability and close the security hole.
Answer: Hotfix
Question 2: Routes disabled during the ___________ phase can now be re-enabled during the restoration phase.
Answer: Containment
Question 3: The process of discussing what lessons can be learned from this incident going forward is called what?
Answer: Post-mortem
Question 4: Following this process, what should be produced?
Answer: Incident Report
Task 6 questions and answers:
Question 1 : What should have been in place to prevent the discovered vulnerability from reaching production? Select two.
Answer: Secure coding practices and code review, A threat model identifying access control flaws
Question 2: What vulnerability did you identify
Answer: IDOR
Question 3: At what time did the attacker successfully authenticate into an account that wasn’t theirs? (YYYY-MM-DD HH:MM:SS)
Answer: 2025–08–24 19:17:32
Question 4: What is the user email attached to user with account ID 105?
Answer: john.doe@company.thm
Question 5: not even a question
Question 6: What should be recommended to the web development team to fix the IDOR vulnerability?
Answer: Enforce server-side validation that the session user matches the requested user ID
Question 7: What log pattern or keyword should be monitored after the patch is deployed?
Answer: user_id mismatch
Question 8: What document should be updated after this incident to include IDOR response procedures?
Answer: IR Playbook
Flag: THM{AppS3c_Inc1d3NT_R3spONder}
