401.

3 - Vulnerability Management and

Response

Vulnerability Assessments
Why do we need Vulnerability Assessments?
Lack of Asset Inventory

Due to the enormous number of systems each organization has nowadays, it’s a challenge to have an up-to-date
diagram of the organization’s network diagram, communication flow, critical infrastructure, or sensitive data and
how is it stored.

This lack of asset inventory leads to some serious security problems.

This leads to assets not being monitoring, patched, or scanned; because we cannot secure WHAT we don’t
KNOW we HAVE. This presents vulnerabilities that we don’t know that we have.

Prioritizing the vulnerabilities and reducing risk

Even though organizations have the lack of asset inventory, modern scanners have the capacity to scan
everything.

Though, it isn’t just about finding and fixing vulnerabilities. It’s from the tens of thousands of vulnerabilities you’ll
find, you’ll need to focus and prioritize the most important vulnerabilities that will reduce the most risk. (Risk =
Threat x Vulnerability)

Even popular scanning tools aren’t able to scale to exclude risk we’ve accepted

As vulnerabilities increased exponentially over the years, to the point that the data model of the most popular
scanning tools isn’t able to scale to exclude the risk we’ve accepted, and that there are some vulnerabilities
(even if it seems so critical to the tool) that we’re not going to fix, because we have limited resources and need
to focus on the ones which cause the most risks.

Everything can’t be patched

Recent large-scale breaches began with the exploitation of unpatched software vulnerabilities.

Some people might think, “Why aren’t organizations patching if they had the patch in place and they could’ve
prevented these breaches?”

Everything can’t be patched.

Sometimes it’s applications which reside on shared infrastructure.

Vendor-specific appliances.

Old hardware.

Sometimes there isn’t a patch, or the patch isn’t effective.

It’s not about finding the flaws on 1 system, doing this at a scale of 10,000 or more system requires proper
strategies, tactics and methodology.

We’ll learn how to have a comprehensive vulnerability management program.

Definitions
Vulnerability

Flaw or weakness in a system that can be exploited

Vulnerability Assessment (VA)

Discovering vulnerabilities before an attacker can leverage them to cause harm.

Security Audit

Evaluation of a network or system against a set of standards. It quantifies how the organization is applying
specific standards, but doesn’t mean that these procedures are effective.

401.3 - Vulnerability Management and Response 1

 While audits can improve the security posture of an organization, but they’re not focused on the concept of
vulnerabilities and struggle to provide any insight (accurate or deep understanding) into organization risk.

Vulnerability Management

Ongoing repeatable process for identifying, remediating (‫)المعالجة‬, or accepting risk.

Importance of Vulnerability Assessors

Many consider Vulnerability Assessment to be a lesser form of Penetration Testing.

Many think that Vulnerability Assessors are the people who run the scanner.
Vulnerability Assessment ≠ Penetration Testing

Vulnerability Assessment Is Hard

Penetration Testing

Actualizes risk to demonstrate (‫ )التوضيح‬the business implications (‫)الاثار المترتبة‬.

Vulnerability Assessment

Must be able to expose risk with a similar degree of confidence of penetration testing, across a larger
environment, without exploitation, while somehow limiting the incidence of false positive.

In other words, VA is doing the job of a penetration tester and more, without being able to exploit the
vulnerabilities like he does.

To accomplish this appropriately, we’ll need to gain an understanding of risk rating systems like CVSS.

Qualitative and quantitative assessment metrics.

The Vulnerability Assessment Framework (VAF)

A vulnerability assessment framework is a structured process for identifying, classifying, and prioritizing
vulnerabilities in an organization. It helps organizations understand their security risks and take steps to mitigate
them.

The 7 steps of VA:

1. Engagement Planning

2. Threat Modeling

3. Discovery

4. Vulnerability Scanning

5. Validation

6. Remediation

7. Reporting

Validation, Remediation and Reporting can be an iterative loop. Reporting then loops back to engagement planning

401.3 - Vulnerability Management and Response 2

 Steps to Perform Vulnerability Assessments
Step 1: Engagement Planning
The Engagement Planning step in a vulnerability assessment framework is the crucial first phase where you
set the stage for the entire process. It's like laying the foundation before building a house – crucial for a
successful and efficient assessment. Here's a breakdown of what happens in this step:

1. Defining Scope and Objectives:

Identifying Assets: You clearly define which systems, networks, applications, and data will be
assessed. This ensures everyone involved is on the same page and avoids surprises later on.

Setting Goals: Establish the specific objectives of the assessment. Are you seeking a high-level
overview of security posture, or a deep dive into specific areas? Knowing the goals helps tailor the
assessment and resource allocation.

2. Stakeholder Engagement:

Identify Stakeholders: Pinpoint all individuals and teams who will be impacted by the assessment,
including IT, security, management, and business units.

Secure Buy-in: Explain the goals, approach, and potential impact of the assessment to gain buy-in and
support from stakeholders. Their cooperation is crucial for successful vulnerability identification and
remediation.

Manage Expectations: Clearly communicate the expected timeline, deliverables, and limitations of the
assessment. This sets realistic expectations and avoids post-assessment surprises.

2. Establishing Rules of Engagement:

Permissions and Access: Clearly define the level of access granted to assessors and any restrictions
on specific systems or data. This protects sensitive information while enabling a thorough assessment.

Communication Protocol: Define how communication will occur between assessors and stakeholders.
Regular updates, escalation procedures, etc.

Resource Allocation: Determine the human resources, budget, and tools needed for the assessment.
This includes assessor expertise, scanning tools, and reporting software.

4. Legal and Compliance Requirements:

Understand Legislation: Identify any relevant regulations or industry standards that influence the
assessment approach and reporting requirements.

Data Privacy Considerations: Address data privacy concerns surrounding vulnerability scans and
potential data exposure during the assessment.

5. Scheduling and Reporting:

Define Timeline: Establish a realistic timeline for the assessment, considering scope, complexity, and
resource availability.

Schedule Downtime: If necessary, coordinate with stakeholders to schedule downtime for system
scans or manual testing to minimize disruption.

Reporting: Determine how assessment findings will be reported and delivered to stakeholders,
including format and frequency.

Step 2: Intelligence and Threat Modeling

401.3 - Vulnerability Management and Response 3

 1. Gathering Intelligence (OSINT)

Purpose of this phase is to determine what information is available for bad actors that can be used
against the target organization.

Inputs — organization name, URL, IP addresses or ranges, industry, organization type.

Outputs — URLs, IP addresses, email addresses, technologies used, resumes, names, host names.

Other sources of intelligence based on industry, nationality, government entity, etc.

2. Threat Modeling

Threat Modeling — This process helps to identify threats, and prioritize the defenses most likely to
succeed against the most probable attacks.

Identifying and prioritizing the threat actors that will most likely target your organization.

Who the attackers that are most interested? What will they target? How would this attack serve their
goals?

We then define appropriate countermeasures to prevent or mitigate the effects of these attacks.

Step 3: Discovery

The purpose of this phase is to determine which systems are available and to then map out the network.

This phase also validates documentation, network diagrams, and open-source information.

Inputs — URLs, host names, domain names, IP addresses, or ranges, such as subnets and CIDR blocks.

Outputs — DNS, IP addresses or host names of systems that are likely to be live.

Common tools used during this phase:

ping - traceroute

Fierce Domain Scanner is a DNS reconnaissance tool (IP Ranges, Host Names using reverse DNS), Brute-
forcing and many other tools.

ike-scan can be used for two main purposes:

401.3 - Vulnerability Management and Response 4

 Discovering IKE hosts: it scans a range of IP addresses to identify those who’re running Internet Key
Exchange (IKE) protocol, which’s commonly used for VPN tunnels. This helps discover the potential
VPN endpoints on the network.

Fingerprints IKE Implementations: By sending specific IKE packets and analyzing responses, ike-scan
can attempt to identify the type of IKE software or vendor used on the target host. This can help us
understand the security posture of the VPN implementation..

Step 4: Scanning

The purpose of this phase is to identify known or unknown vulnerabilities in the identified technologies.

Inputs — IP addresses, ports, services, and applications.

Output — List of potential vulnerabilities is provided from the tools which include scanners such as Nessus,
NexPose, Burp, W3AF. These scanners use tools such as Nmap to identify open ports and identify services
attached to these ports.

Concerns and How to Mitigate Them

Accuracy and completeness:

False positives: Scanners can generate false positives, identifying vulnerabilities that don't actually exist.
This can lead to wasted time and resources investigating non-existent threats.

Validate scan results (Validation Phase): Manually verify findings and prioritize vulnerabilities based
on risk and exploitability.

False negatives: Scanners may miss real vulnerabilities due to limitations in their detection methods or
misconfigurations. This creates a false sense of security and leaves the system vulnerable.

Use a combination of scanning tools: Employ diverse tools with different strengths and weaknesses
to improve overall coverage and accuracy.

Performance and disruption:

Resource consumption: Extensive scanning can consume significant system resources, potentially
impacting performance and availability. This is especially concerning for critical systems.

Configure scans carefully: Optimize scan settings to balance thoroughness with performance and
minimize disruption.

Network traffic: Aggressive scans can generate high volumes of network traffic, overwhelming bandwidth
and potentially triggering security measures.

Downtime: In some cases, scanning may require taking systems offline, leading to downtime and
disruption to operations.

Ethical and legal considerations:

Unauthorized scanning: Scanning systems without proper authorization is illegal and unethical. It's crucial
to have explicit permission before scanning any network or system.

Obtain proper authorization: Always have explicit permission before scanning any network or system.

Additional concerns:

Human expertise: While scanners are valuable tools, they should not replace human expertise in
analyzing results, making risk assessments, and implementing appropriate mitigations.

401.3 - Vulnerability Management and Response 5

 Invest in training: Train personnel on vulnerability assessment, threat modeling, and ethical hacking
practices.

Step 5: Validation

The purpose on this phase is to assign a confidence value and validate potential vulnerabilities. The way in
which findings are validated is different when comparing vulnerability assessment to penetration testing.

With penetration testing, validation is most often performed by attempting to exploit the identified
vulnerabilities.

With vulnerability assessments, we are performing validation by performing steps such as validating the
installed version of an application on the affected device, confirming a missing patch, auditing (examining)
the configuration of a device to check for misconfigurations, and various other methods.

Inputs — listing all potential identified vulnerabilities from the scanning phase.

Output — the end goal is to produce a listing of validated vulnerabilities and confidence rating values.

Step 6: Remediation

The purpose of this phase is to assign risk and priority ratings to validated vulnerabilities. We must then
determine then appropriate option for remediation/mitigation of the vulnerabilities identified as the most
priority which introduces the most risk.
1. Prioritization:

Not all vulnerabilities require immediate attention. The prioritization stage involves analyzing identified
vulnerabilities based on various factors like:

Severity: Scores like CVSSv3 help assess the potential impact of an exploit.

Exploitability: How easy it is for attackers to leverage the vulnerability.

Assets affected: Importance and sensitivity of the systems containing the vulnerability.

401.3 - Vulnerability Management and Response 6

 Leadership approval: Changes must be prioritized based on risk assessment and cost-benefit
analysis that has leadership approval.

Compliance requirements: Regulatory mandates for addressing specific vulnerabilities.

2. Remediation options:

Once prioritized, vulnerabilities need to be addressed. Available remediation options include:

Patching: Applying software updates that fix the vulnerability.

Configuration changes: Modifying system settings to mitigate the vulnerability.

Workarounds: Implementing temporary solutions until a permanent fix is available.

Disabling services or applications: Removing vulnerable components if patching or configuration

changes are not feasible.

Segmentation: Isolating vulnerable systems from critical assets to limit attack spread.

3. Implementation:

The chosen remediation approach is implemented based on the specific context and resources available.

4. Verification:

It's crucial to verify that the remediation was successful. This involves:

Re-scanning systems to confirm vulnerabilities are no longer present.

Testing implemented workarounds or configurations to ensure effectiveness.

Monitoring systems for any unexpected effects or side effects from the remediation.

Step 7: Reporting
In this phase, any findings that are not remediated from the remediation phase must be reported as risk.
A risk assessment report or security plan will include an executive summary, detailed analysis, findings,
recommendations, and an appendix where verbose information is placed for those wanting more information.
The reporting phase is a crucial step in the vulnerability assessment process, as it communicates the findings
to stakeholders and guides remediation efforts. Here are the key elements of a detailed vulnerability
assessment report:
Executive Summary:

Briefly summarize the scope and objectives of the assessment.

Highlight the key findings, including the number and severity of vulnerabilities identified.

Provide a high-level overview of the remediation plan.

Vulnerability Details:

List each identified vulnerability, including its unique identifier, severity level, description, affected
systems, and current remediation status.

Use a table format for clarity and easy comparison.

Remediation Details:

For each vulnerability, describe the recommended remediation actions, including the status (e.g.,
pending, in progress, completed), and estimated timeline for completion.

Prioritize remediations based on severity and exploitability.

Additional sections may include:

Methodology: Briefly describe the methods and tools used for the assessment.

Risk Assessment: Analyze the potential impact of each vulnerability if exploited.

Recommendations: Provide guidance for improving the security posture beyond identified
vulnerabilities.

Tips for effective reporting:

Use clear, concise, and objective language.

401.3 - Vulnerability Management and Response 7

 Avoid technical jargon when possible.

Tailor the report to the audience's level of technical expertise.

Use visuals like charts and graphs to present complex data effectively.

Executive Summary
This report summarizes the findings of a vulnerability assessment conducted on [date]. 2 vulnerabilities were
identified, with 1 classified as high severity.

Remediation plans have been outlined for all identified vulnerabilities, with [number] already completed.

Vulnerability Details

Remediation
ID Severity Description Affected Systems
Status

SQL injection vulnerability in web webserver1,

VULN-123 High Completed
application webserver2

Outdated software version on critical

VULN-456 Medium database1 In progress
server

Remediation Details
Vulnerability ID Description Status ETA

VULN-123 Patch web application with latest security update Completed

VULN-456 Upgrade software to latest version In progress 2 days

Criticality and Risks

Vulnerability Criticality

They’re ratings applied to identified vulnerabilities. They’re likely subjective and have different meanings to
different organizations. What a company classifies as high may be considered grave to another company.
The determination of the criticality is often based on models such as OWASP Risk Rating Methodology where
Risk = Likelihood * Impact.

Qualitative Risk Levels

Low - Medium - High - Severe - Grave

The problem with qualitative risks levels is that they don’t have any context around those ratings, so they have
a little meaning.

Can be used when we need to have a fast and clear criticality level.

We could add meaning to these levels by adding quantitative impact levels to each of them.

Quantitative Impact Levels

Low – A risk with an impact of <$10,000 USD

Medium – A risk with an impact between $10,000 - $49,999

High – A risk with an impact between $50,000 - $99,000

Severe – A risk with an impact between $100K - $249K

Grave – A risk with an impact of $250K or greater

401.3 - Vulnerability Management and Response 8

 These quantities can differ from an organization to another depending on variables such as reputation risk.
They’re also subjective and have different meaning to different organizations.

Customized Risk Analysis

Customized risk analysis is a vital component to have a complete and clear assessment strategy. When
developing personalized ratings, we should consider: Quantitative and Qualitative Risk Assessments.

Qualitative Risk Assessment — Factors in the likelihood, difficulty in exploitation, and other factors.

Quantitative Risk Assessment — Factors in the financial impact and other metrics.

Which means, when a High/Critical rating is assigned as a severity of a vulnerability, it’s judged against
predetermined criteria, which varies from framework to framework, and from an organization to another.

Technical Severity is a part of the equation. After all, we have a lot of other factors that affects the equation.

Example: Heartbleed
Heartbleed is a serious security vulnerability discovered in April 2014 that affected the OpenSSL
cryptographic library, which is widely used to secure communication over the Internet. The vulnerability
was officially designated as CVE-2014-0160.

It presented a critical security risk and has become an important case for discovery and patch management
programs.

The CVSS classified gave it a 5.0/10.0 score, even though it literally impacted a lot of organizations, it was just
a 5.0 for CVSS, although its impact was 10.0/10.0.

Tailoring the outputs to fit you

Frameworks, guides and output that’s produced by tools are useful, but we must tailor and customize them to
fit into our organization.

Risk is subjective.

Common Vulnerability Scoring System (CVSS)

It’s a universal language to express vulnerability severity, and help determine the urgency and priority of
response.

CVSSv2
Focus on exploit availability: CVSSv2 heavily relied on the existence of public exploits to assign severity,
potentially underestimating vulnerabilities that have available exploits but are used in targeted attacks.

Incomplete impact assessment: It lacked granular metrics for confidentiality, integrity, and availability (CIA)
impact, making it difficult to fully assess the potential damage a vulnerability could cause.

Ease of Exploitation: I didn’t consider the ease of exploitation of a specific vulnerability.

CVSSv3
It addressed limitations of CVSSv2:

401.3 - Vulnerability Management and Response 9

 Expanded metrics: CVSSv3 introduced new metrics like Attack Scope, CIA Impact, and Required Privileges
for a more comprehensive assessment.

Environmental customization: It allows tailoring scores to specific environments, considering data sensitivity
and infrastructure specifics.

💡 There’s always a risk for auto-generated risk ratings.

Calculating CVSS Scores

The calculation for CVSS scoring is broken into three segments:

Base Score Metrics

Temporal Score Metrics

Environmental Score Metrics

These components are further broken down to perform the actual calculation.

Customized calculation of CVSS scores can be performed to provide significant value beyond the traditional
precomputation seen in most vulnerability scanning tools and vulnerability databases.

The scoring system is flexible enough that when environmental considerations are manually evaluated,
significant value can be derived from CVSS.

The primary goal of CVSS is to consider both exploitability and impact when developing an overarching
score for an individual vulnerability.

MS17-010

It was a 0day. A 0day is a vulnerability that you have 0 days to prepare for, means that you weren’t ready for
it.

It’s a vulnerability where attackers can exploit a vulnerability in the SMB protocol, which’s used by Windows to
do everything including file and print sharing and logging into Active Directory.

2 months later, WannaCry was released and hits the world, takes advantages of MS17-010, this means
systems that weren’t patched yet were impacted.

401.3 - Vulnerability Management and Response 10

 1 month later, Petya was released and uses the same vulnerability.

2 months later NotPetya was released and uses the same vulnerability.

Even till today, ransomware uses this vulnerability to determine if it can still be exploited on the target system,
even after 7 years.

So you should ask yourself:

When did your organization patch? If not, Why?

Did you patch all Windows systems? Or just some of them?

Do you still have systems today that aren’t patched? How long do you wait to patch?

Meltdown and Spectre

Hardware Vulnerabilities & Its Impact

Hardware vulnerabilities are worse than software because anti-malware solutions or detection/prevention
techniques can’t do anything to it.

They affected intel CPU architecture, it’s a vulnerability in how the CPU was designed, which means you
cannot fix it unless the CPU is redesigned. And this process of redesign till it’s released to the market, takes a
lot of time.

In order to patch this vulnerability, you’d need to change your hardware. And it doesn’t matter how much
money do you have, it won’t happen over night.

Why? Because you have to wait for the Intel engineers to design a new CPU.

It also depends, because not all CPUs are removable. CPUs in laptops for example are soldered to the
motherboard, unlike PCs.

How was it patched then?

A lot of organization’s just implemented the software code fix which prevented the OS from being used to get
to the CPU, but this hit performance of CPU to 50%, and this couldn’t be applied to production servers or
organizations might lose their business.

Cloud Providers had the advantage

CSP on the other hand, deployed the software patch, and gave each user a CPU and a half to compensate for
the CPU 50% performance hit.

So, what’s the goal of securing our infrastructure if attackers can discover and exploit 0days?

Sometimes vulnerabilities don’t have fixes and they’re 0days, but 0days don’t fall off the sky, they require a lot
of resources and validation that they’re worth exploiting.

Our goal is to make the attacker invest as much resources as he can, with maximum effort to try to
compromise our organization. To make it as hard as it should be that he may give up to break in.

Top 30 Vulnerabilities

The top 30 vulnerabilities being exploited in the world, are maybe 6 years old and patched but attackers still
use it because of unpatched systems.

An adversary doesn’t have to use a 0day if your systems are patched for 6 years.

Know & Control What You Have is better than patching

401.3 - Vulnerability Management and Response 11

 The only thing that’s better than patching is not having to.

You should have an asset inventory, and get rid of hardware you don’t need. Same goes for software, having
software inventory and finding software you don’t need, then you uninstall them.

Application Control and Fighting Malware

When you have the software, you need to have application control, when you have application control you
can stop an adversary trying to get to stage 2 in his malware.

Not every Vulnerability has CVSS

Many vulnerabilities compromised by attackers and penetration testers do not have a CVSS score as they
apply to misconfigurations and abused features.

An example could be Microsoft's PowerShell. In part, PowerShell is an incredibly powerful scripting language
and interface to the .NET Framework.

One of its biggest benefits is automation and is an incredible tool for administrators. As you can imagine it is
also an incredibly powerful tool for attackers.

Microsoft has invested a lot of time into ensuring that Windows Defender detects and prevents potentially
harmful PowerShell commands and scripts (cmdlets) from running.

The point is that features, and misconfigurations can provide attackers with opportunities even if the
environment is patched up to date.

Penetration Testing
The What and Why of Penetration Testing
What is Penetration Testing?

It involves modeling the techniques used by real-world adversaries to find vulnerabilities; and use these
techniques to exploit the vulnerabilities under controlled circumstances, in a professional, safe manner
according to a carefully designed scope of Rules of Engagement.

The goal of penetration testing it to determine business risk and potential impact, all with the goal of helping
the organization improve security practices.

We need to put in mind, that the difference between a pentester and an attacker is the permission the
pentester takes before breaking into the system.

Difference between VA and Pentesting

The main difference between vulnerability assessment and penetration testing, is that penetration testing is
exploiting the vulnerability not just verifying its existence.

Penetration Tests generally have more limited scope such as limiting the tester to certain IP addresses,
network range, or web application.

The role of penetration testing is well-understood by the majority of organizations and gave birth to newer testing
techniques such as Red Teaming, Adversary Emulation, and Purple Teaming. Each have their own unique
approaches and benefits.
The Limited Scope of Pentesting introduces concepts like Red Teaming and Adversary Emulation

Often, penetration testing is limited in scope to where the testers are not truly able to emulate and mimic the
behavior of adversaries. This is where activities such as Red Teaming and Adversary Emulation come into

401.3 - Vulnerability Management and Response 12

 play. A methodical and very detailed approach must be taken regarding penetration testing in order to
provide the biggest business value to your customer.

Red Team

Red Team emulates Tactics, Techniques, and Procedures (TTPs) of real adversaries to improve the people,
processes, and technology in the target environment.

It’s a specific type of pentest where the Red Team directly targets the Blue Team, this is Red vs Blue.

You’re using the TTPs of an attacker to break into the organization.

Goal

It’s goal is to make the Blue Team better. Your focus is on training and measuring Blue Team’s detection,
response, technologies and defense overall.

Difference between Red Teaming and Pentesting

It’s the same idea as a pentest but it has a different focus area, where the Red Teaming’s customer is the Blue
Team.

What are exactly TTPs?

Tactics

What: The "why" or overall goal of an action.

Focus: Strategic approach to achieve a specific objective.

Example: In cybersecurity, a tactic could be "gain initial access to a network."

Techniques

What: The "how" something is done to achieve a tactic.

Focus: Specific methods and approaches to implement a tactic.

Example: Using phishing emails might be a technique to achieve the tactic of gaining initial access.

Procedures

What: The specific steps taken to implement a technique.

Focus: Detailed, practical instructions on how to carry out a specific method.

Example: Sending a spear-phishing email pretending to be from a trusted source with a malicious
attachment.

Imagine baking a cake

Tactic: The goal is to bake a cake.

Technique: You might choose to use a specific recipe or method (e.g., creaming butter and sugar).

Procedure: The recipe provides step-by-step instructions on mixing ingredients, baking times, and
temperatures.

401.3 - Vulnerability Management and Response 13

 Adversary Emulation

What is Adversary Emulation?

It’s a type of Red Team exercise, but a little less restircted. A real world emulation of a real adversary and making
a real world attack, and it has less restrictions.
Goal

It’s goal is to test the overall preparedness of an organization vs a real, sophisticated attack.

It’s less restricted, different focus area.

Examples

One test was a team had to clone an ID badge of an employee of the target organization in a subway in public,
and they did.

Another test was replacing the eraser of a white board with a malicious eraser which has an audio recorder
which’s used for eavesdropping.

Why would I do Adversary Emulation?

If you’re not patching your systems, you won’t even have to worry about this, because it’ll be easier to break
in when you’re not patched, and the adversary won’t invest resources to even care to clone an ID of an
employee in your organization when he can walk in the front door.

Are these types of attacks possible?

Yes there are, they likelihood of them happening maybe low, but they’re your focus after having a strong
systems defense and want to take the next step of security.

Purple Team

It’s Red vs Blue on an on-going basis to improve both, where Red and Blue Teams work together.

While Red Team Exercises and Adversary Emulations are performed without the Blue Team knowing about it,
Purple Team Engagements are fully known and performed together with the Blue Team.

Why Perform Penetration testing?

Vulnerability scanners do not typically perform validation.

It allows for the validation of vulnerability findings (from the VA process).

401.3 - Vulnerability Management and Response 14

 Attempts to exploit a given vulnerability, demonstrate the true impact of that vulnerability of the organization.

Offense informs defense — It shows the effectiveness of security controls.

Rules of Engagement
Clearly Determining the Pentesting Guidelines and Rules

Pentesting is going to cause harm and it’s dangerous, so we need to clearly identify what we’re allowed to do,
what we’re expected to do, what we’re NOT expected to do before starting the process.

We need to define things like:

Start dates and end dates of testing – There may be business operation concerns that require testing to be
performed at specific times, such as the evenings and weekends. Imagine a hedge fund company who
perform stock trading during normal trading hours. They may opt to avoid testing during these hours to lower
the risk of impact.

Time of day testing is permitted – Same as the above, but specifically focused on time of day.

Contact information for testers, system owners, and business owners – If a system accidentally gets taken
offline by a tester it is important to be able to contact the system owner. The same is required in the opposite
direction. If a system owner notices that a tester has taken a system or service offline, they may need to
contact the offending person.

What data is and is not allowed to be viewed – Think PII (Personally identifiable information such as SSN, Full
Name, Email Address, Phone Number) data and regulatory requirements. It may require disclosure (informing
relative authorities or individuals) if a tester enumerates a database full of credit card records or medical
records.

How to respond if an exploit attempt has been blocked or new rules were added to block the tester's IP
addresses – Imagine if a tester is running a scan and a security control or administrator blocks the offending
IP address. This may end the ability for the tester to continue testing. There needs to be a process where the
tester can request that they be unblocked to continue their test. It should be noted in the final report that the
company successfully detected an attack and took action.

How results should be submitted and in what format – Any findings delivered to the customer of the pen test
should be delivered in a secure manner. This most likely includes encryption and needs to be determined
before the testing begins.

Scoping
As we said, scope and rules are tied closely together, and both must be determined before starting a test.

The defined scope instructs the pentest team as to what systems and services they can and cannot target.

The scoping document should include:

What systems, networks, domains and applications are in play?

What if a new unidentified systems are discovered?

A tester runs a scan and uses a compromised system to connect to another system, but that system is
not listed as being in scope neither out of scope.

Assume out-of-scope — I should be assumed that it is out of scope as it was not included in the the
rules we determined before starting the test.

Contact the customer — The customer can be contacted about that and if he agrees about adding it to
scope, it can be added.

Which ones should explicitly be avoided (‫?)تجنبها بشكل صريح‬

These are what cannot be tested and are often high-value

systems.

What if the system resides at a vendor location or in the cloud?

Pentesting Limitations and Importance of Red Teaming and Adversary Emulation

The limitations of the scope greatly impact how “real world” of a test can be performed.

401.3 - Vulnerability Management and Response 15

 Attackers do not have these limitations, this is why adversary emulation and Red Teaming are maybe suitable
at times.

Too narrow of a scope reduces the value to the customer

Clarifying the importance of increasing scope — Sometimes the customer do not understand the benefit
of increasing the scopes or allowing additional attacking techniques. The pentest team can help explain as
to why additional targets should be in scope.

Sometimes the customer intentionally limits the scope — They may

not really want a penetration test and only want to
pass an audit.

Types of Penetration Testing

External Pentest vs Internal Pentest
External Pentest — focuses on the perspective of an attacker from outside the organization.
Internal Pentest — focuses on what an attacker could do if starting from within the organization's network.
The external test problem is that most people view it as they want you to get into the organization through the
traditional defenses as layers, one after another, and that’s not how it works.
This is maybe the goal of an organization to test the products and technologies they have in their environment,
but that should not be the focus of an organization when conducting a pentest.
Having limited time and focusing on improving defenses

At last, pentesters have a limited time to perform pentesting, and during that limited time they don’t want to
waste their efforts on just “breaking in” because the goal of pentesting is not just improving prevention, but
maybe it’s more focused on improving defenses and detection inside the organization.

Prevention techniques will eventually fail

Maybe the right thing to do is to give the pentesting team an IP on the inside, and make them start the
process by testing your defenses against an attack who actually broke in, which’s more important, because
your prevention techniques will eventually fail vs the adversary, and they’ll be able to break in.

When they break in, they can do C2, Data Exfiltration, Lateral Movement, Privilege Escalation, Machine in the
Middle.

So, the right thing is to focus your time and budget on what you really need to test.

Web Application
They’re the no.1 attack vector for adversaries nowadays, because everything is application code and web
applications are growing rapidly.

Application code often contains security issues, due to the complexity of it and all the moving parts and
functionalities.

The Open Web Application Security Project (OWASP) is a fantastic resource that provides tools, reports, and
recommendations on all things related to web app security.

A great tool provided by OWASP is the Zed Attack Proxy available at [Link]

This tool allows you to trap all communications between a web browser and the web server, giving you
the ability to monitor and manipulate traffic to see how each side of the connection responds.

Social Engineering

401.3 - Vulnerability Management and Response 16

 Use of influence and persuasion to deceive people for the purpose of obtaining sensitive target information
or for the victim to perform an action.

Human nature desires to be helpful and fears "getting into trouble" (the 2 week job example), which is the
main goal of social engineering.

It’s much simpler to have someone open the door for you than to spend time picking the lock.

If you collect enough online information related to a person, you can manipulate them, even at distance
without getting close to them (through emails, messages, calls, etc.).

Human-based Social Engineering

For example, someone calls in to the help desk posing as the VP of the corporation. The attacker explains that
he is traveling and has forgotten his password for a meeting he needs to attend very soon. This covers
urgency and impersonation. How many help desks wouldn't think twice before completing this request for
someone posing as a VP?

Computer-based Social Engineering

If a user is browsing the web and gets a pop-up to re-enter credentials, how many average users would
question this request that seems to come from their own computer?

Most of the recent email worms come crafted to look real and convincing and generate as many downloads
and clicks as possible.

💡 The only defense against Social Engineering is “awareness”.

There’s always someone who’s gonna click the link

Then someone’s gonna say “there’s always someone who’s gonna click the link”. But at least, instead of 90%
of people clicking links, we now have 10% of people, and these 10% are distributed all over the organization
with different privileges.

Humans are the weakest link controversy

You should be stopping these emails and malicious documents from reaching your devices and environment
at the first place, so instead of blaming humans, we can work on our defenses, besides the awareness for
end-users.

Additional Types of Penetration Testing

Mobile Device Testing

401.3 - Vulnerability Management and Response 17

 The attack surface of mobile devices certainly includes similar attacks as those related to web clients and
apps.

Mobile devices are used for much more than just the web and require a unique focus.

Product Security Testing

This type of testing could include Internet of Things (IoT) devices, network appliances, such as printers,
switches, and routers, and much more.

Often involves reverse engineering, fuzzing, and debugging.

Fuzzing — also known as fuzz testing, is an automated software testing technique that involves feeding
invalid, unexpected, or random data as inputs to a program to identify bugs and vulnerabilities. Imagine
throwing different types of objects at a system to see how it reacts; that's essentially what fuzzing does!

Physical Penetration Testing

This type of testing factors in devices such as badge readers, elevators, security gates, biometric devices,
safes, and many others.

The Focus of Pentesting

It is important to remain focused on demonstrating the true impact to the company.

For example, you got Domain Administrator access.

What were you able to do with that access?

What does that mean to us?

Based on your expertise, how should we go about fixing the vulnerability?

Penetration Testing Process

These are not required, and a tester can start at any phase and move in any direction; however, it is a helpful,
sequenced approach that many follow.

The report provided to the requestor upon conclusion of the pentest is likely the most valuable part of the
process.

OSINT (Reconnaissance Process)

401.3 - Vulnerability Management and Response 18

 OSINT — It is the practice of collecting data via opensource locations such as the public internet,
presentations, printed media, conferences, presentations, and many other locations.

It’s a passive effort — Reconnaissance should be mostly passive, meaning that an analyst performing these
activities should go undetected.

Users publish an enormous amount of data on sites like Twitter, Facebook, and LinkedIn. The ability to access
this information can be extremely beneficial to an analyst or penetration tester.

Some organizations use OSINT to provide them with information that are publicly available on them, and
determine according what information attackers can leverage and how would they use it to approach their
organization.

Example

An adversary wants to design a malware to design a specific organization, he wants to know what kind of
anti-malware software this organization uses. After searching, he finds the logo of the organization he’s
targeting in an anti-malware company’s website and that they’re using the product.

We can find what type of routers your organization is using from job posting, your employees expertise, etc.
Same concept applies here.

Enumeration
Goal is to identify:

Open ports on the target system

Services associated with these ports

Versions of applications running

It’s a standard practice to run well-known services on non-standard ports in an effort to hide them.

An example would be admins running HTTPs over TCP port 4433 instead of 443 (default).

This approach doesn’t do much protection, and the fingerprint of these applications are still the same.
Tools such as Nmap can find them with ease.

Applications Fingerprints

An application fingerprint is a unique identifier for a specific software application. It's like a digital
signature that can be used to identify the application, even if it's trying to hide its identity.

There are two main types of application fingerprints:

Passive fingerprints: These are collected by observing the application's behavior, such as the fonts it
uses, the operating system it's running on, and the network protocols it speaks.

Active fingerprints: These are collected by sending probes to the application and measuring its
response. For example, an active fingerprint might involve sending a specific HTTP request and seeing
how the application responds.

We can also enumerate important system details such as user accounts, network shares and other relevant
data.

Vulnerability Identification (Scanning)

It’s closely tied to the Enumeration phase.

Here, we use the same tools that the adversary will use to make vulnerability identification.

This phase helps us to select the best targets and services to use in the exploitation phase.

Correlating specific version numbers of services and applications to known vulnerabilities

401.3 - Vulnerability Management and Response 19

 Scanners such as Nessus and OpenVAS are good at identifying specific version numbers of services and
applications running on a target, then correlating them to any known vulnerabilities.

This allows us to determine the way we move into the exploitation phase.

Exploitation
The exploitation phase is where we take all the knowledge gained thus far and attempt to gain access using it.

This could include password attacks, social engineering, and many other techniques.

We want to think about the least ones that will make us get caught, and the least likely to take out a
production service or system (staying undetected).

AV-evasion: Ghostwriting

Another factor to take into consideration is that many antimalware (AV), and other controls aimed at
preventing or detecting out attempts.

AV-evasion is a very common technique used by pentesters and attackers at the same time.

One technique, known as ghostwriting, changes the way malware, a payload, or other code looks at a
very low level in order to evade signature detection.

It is performed by opening up compiled code and inserting benign assembly instructions or moving things
around to change its signature, without changing the functionality of the payload.

Not every exploit is software-based

Often when we talk about exploitation, people think about software code. That could be true, but not every
exploit is software-based.

Example: Routers, switches can have default configurations, exploiting this configuration doesn’t require
us to install software code to exploit a vulnerability.

Post-Exploitation
Includes activities performed once we exploited a vulnerability and gained a foothold inside the organization.

It includes many actions such as:

Pivoting and lateral movement

Privilege escalation

Data exfiltration

Maintaining access (Persistence) — techniques attackers use to establish persistent control over a
compromised system. This allows them to re-enter the system even after their initial foothold is disrupted,
such as after a reboot or security update.

Includes tools like Metasploit Framework, Cobalt Strike, Empire, Covenant, and many others.

Reporting
It’s one of the most important, if not the most important phase of all.

Focus should be on quality and value

This is the document we leave behind once the testing is completed. It’s a representation of your work and as
such, the focus should be on the quality and value.

You do not want to simply take the results from scanners as Nessus and paste them into the report.

The most common sections to include are:

Executive Summary

This should be no longer than a page or two. It should include a summary of the overall project, a high-
level overall risk statement, and then some of the top findings in non-technical terms. Assume that anyone
in the organization may read the summary.

Introduction

401.3 - Vulnerability Management and Response 20

 Include the Rules of Engagement details, scope of testing, tester information, most significant findings,
and consider including information such as the tools or services used.

Methodology

Findings and Risk Assessment

This is the section where you list the findings in order from most critical to least critical. A qualitative and
quantitative assessment can be performed on each finding including impact, likelihood, and other factors.

Recommendations

For any findings, recommendations can be made to improve the security of the organization. What types
of things would have prevented the testers from being successful?

Conclusion

This should simply be a summary of the entire document, similar to the executive summary.

Appendix

This is where verbose scan results, code snippets, images, and other relevant data should be placed.

Penetration Testing Tools

Port Scanning / Nmap
Stands for Network mapping. It’s a process of enumerating all the hosts that respond on a given network.

Port scanning goes a step further and tells you which ports on each machine have listening processes bound
to them.

It supports a large number of scanning techniques, including port (TCP and UDP), SYN, FIN, ACK, and ICMP
ping sweeps. It also offers advanced features, such as remote OS detection, stealth scanning, and other
functionality.

Example of TCP Scans

HOST = "[Link]"
for PORT_NUMBER in 1 to 65535 {
if(connect_to(HOST,PORT_NUMBER) == SUCCESS) {
print "Port PORT_NUMBER is listening"
close_connection(HOST, PORT_NUMBER)

# nmap -A -T4 [Link]

Starting Nmap ( [Link] )
Interesting ports on [Link]:
Not shown: 994 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.3
25/tcp closed smtp
53/tcp open domain ISC BIND 9.3.4
70/tcp closed gopher
80/tcp open http Apache httpd 2.2.2
|_ HTML title: Go ahead and ScanMe!
113/tcp closed auth
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.20-1
(Fedora Core 5)

Information can be misleading

Most scanners print a nice report that names the service running on each port, but this information can be
misleading.

401.3 - Vulnerability Management and Response 21

 This information is based on what service typically listens at that port and often comes from an /etc/services

file on a UNIX host or the equivalent on other platforms. Basically, this is a text file that maps port numbers to
their well-known service names.

Printing the name of the service makes the report look good, but the information isn't necessarily reliable.

Application Fingerprint

Nmap have included functionality to decipher the responses returned after connecting to a port to identify the
software that is listening, sometimes including version and patch level information.

OS Identification and its advantage to attackers

Nmap has the ability to probe (‫ )استكشاف‬a target and determine which OS and version it runs.

It can save the attacker a lot of time if he knows what OS does a machine run.

For example, if he knows that the targeted machine is using Windows, he will save a lot time trying only
Windows-oriented attacks and skipped all other OSes’ attacks, and also attacks specific to this version of
Windows.

It comes with a database of hundreds of "signatures" of different operating systems and networking
equipment and relies on its user community to help keep it up-to-date by submitting new signatures as
new operating systems become available.

Metasploit
False Positives From Vulnerability Scanners

Vulnerability scanners are useful for finding vulnerabilities, but because they are often looking for conditions
of a vulnerability, they can have false positives.

Exploitation Frameworks Overcome The Issue

The next evolution in tools is exploitation frameworks. These are tools that, if a vulnerability exists, will
exploit the system and provide the person running the tool access to the system. One very popular tool in this
space is Metasploit.

Metasploit will exploit a vulnerability if it is present and provide access to the system through various
methods that can be specified in the tool.

It’s not only a useful tool for penetration testing, but it is also a helpful way to verify whether a vulnerability
really exists on the system.

If a vulnerability scanner finds an exposure, it is easy for an administrator to say it is a false positive. However,
if Metasploit exploits it, it is pretty hard to say it is a false positive!

Meterpreter

It’s a custom Metasploit shell, which offers an enormous amount of power and functionality to the user.
Meterpreter payloads and how it works

1. Delivery

Meterpreter is typically delivered to a target system through various methods, such as:

Exploiting a software vulnerability.

Phishing emails or malicious links.

401.3 - Vulnerability Management and Response 22

 Social engineering techniques.

2. Injection and Execution

Once delivered, Meterpreter is injected into a running process on the target system. This can be done
in various ways, depending on the chosen delivery method.

Once injected, the code executes and establishes a communication channel with the attacker's
machine.

3. Interactive Shell

Meterpreter provides an interactive shell, similar to a command prompt, that allows the attacker to:

Explore the filesystem: List directories, view files, and download data.

Run processes: Execute commands and utilities on the target system.

Manipulate registry: View and modify registry entries.

Manage users and processes: Create, delete, and modify user accounts and processes.

Download and upload files: Transfer files between the attacker and the target system.

Perform further exploitation: Use additional tools and techniques to gain deeper access or
escalate privileges. Actions which can be performed include a wide range of post-exploitation
capabilities such as:

Sniffing from the victim’s network interfaces

Screen capture

Interacting with webcam and microphone

Impersonating other users

Stopping/Spawning new processes

4. Communication and Control

Meterpreter maintains a communication channel with the attacker's machine, allowing them to send
commands and receive data in real-time.

This communication can be encrypted to ensure confidentiality and integrity.

5. Stealth and Persistence

Meterpreter can be configured to hide its presence on the target system, making it difficult for security
software to detect.

It can also be configured to persist on the system, even after a reboot, providing the attacker with
continued access.

Password Compromise
MFA can greatly improve your security

The important thing to know, from a defensive perspective, is that proper use of Multi Factor Authentication
(MFA) using solutions based on the FIDO2 standard, such as YubiKeys, can greatly improve your security.

Hardware-based solutions prevent MFAbypass

There are MFAbypass techniques through the use of reverse proxy servers; however, hardware-based solutions
prevent those techniques from working.

Password Stuffing

401.3 - Vulnerability Management and Response 23

 It’s where attackers use stolen credentials (username and password pairs) from one service to try and gain
unauthorized access to user accounts on other services.

1. Attackers acquire stolen credentials: These credentials can be obtained through various means, like data
breaches, phishing attacks, or buying them on the dark web, password dumps uploaded on Pastebin website
for example.

2. Automated login attempts: Attackers use bots or scripts to automatically try these stolen credentials on
numerous websites and online services.

3. Success based on password reuse: The attack relies on the fact that many users reuse the same username
and password across multiple platforms. Even if the credentials were stolen from a different service, there's a
chance they might work on another platform used by the same victim.

Password Spraying

Password spraying is a simple concept which takes a commonly used password and tries it across a very
large number of accounts, typically web and cloud resources.

Avoiding account lockout

It is effective as one goal is to avoid account lockout.

If a password is tried against an account a single time, and then we try the same password on a second
account, we won't lock out the first account. We then continue to a third account using the same password,
moving onto yet another account.

401.3 - Vulnerability Management and Response 24

 One password at a time

The idea is that once we exhaust all possible accounts using the password, we start at the beginning with a
second password guess and repeat the process.

Difference between Stuffing and Spraying

Credential stuffing attacks exploit genuine, stolen credentials to gain unauthorized access to other accounts.

While in password spraying attacks, criminals don’t have access to known credentials, so they test a
commonly used password against several usernames to see what works.

Attacks and Malicious Software

High-Profile Breaches and Ransomware
Marriott Data Breach

Marriott Hotels are the biggest series of hotels in the world. This means that they have a lot of customers’ data
on their systems, especially important ones which may be relevant to really important people.

This breach is a good example because it was predictable.

It was discovered in September 8, 2018 and reported November 30, 2018.

Investigation showed → 9.1 million payment cards & 24 million passports

The breach was active from 2014 and detected in 2018.

Marriott purchased Starwood in 2016, but they were still using the IT infrastructure that they inherited
from Starwood.

After the attackers successfully exploited the systems, they gained access to:

Reservation Database

Credit Card Numbers

Passport Numbers

Mailing Addresses

Name, Phone, and Emails

All of these data could be used to steal money or identities. They were likely sold in markets on the dark
web.

By accessing the files that were private and belonging to Marriot consumers, confidentiality was breached.

How could the breach been avoided?

The breach could’ve been avoided by just following fundamental security principles.

It hasn’t been disclosed that they got breached as of a specific vulnerability, but the unmonitored access
for over four years was the main reason for that.

Another lesson it would serve is that, prevention is ideal, but detection is a must.

The attackers performed reconnaissance and scanning for years before executing their attack.

401.3 - Vulnerability Management and Response 25

 Which means there were a lot of logs and red flags that this attack was happening, but no action was
taken due to poor monitoring.

And because of this, Marriott had its data stolen for years before they even knew it was happening.

You cannot prevent all APTs, but you can detect them

It’s highly unlikely that an organization will be able to prevent all APTs, however, companies should be able to
fully detect attacks.

💡 Timely detection → Timely response → Damage reduction

Steps taken postmortem

They invested a lot to try to recover from this breach. Which clearly explains that security as an afterthought
is exponentially expensive than implementing security in the first place.

A website was made to answer your questions about the breach [Link] , and it was not on a
corporate domain. But later, they fixed it and moved the page to Starwood’s domain.
The Equifax Breach

WannaCry Ransomware

401.3 - Vulnerability Management and Response 26

 It targeted the most important and critical infrastructure.

The attack itself was not targeted towards a specific target, there were just organizations that were not
following security fundamentals such as patching and account management.

It affected hundreds thousands of systems across multiple industries, including schools, universities, shipping
companies like FedEx, which affected their business and countless other resources.

For ransomware, the business model is this:

Encrypt the data

Charge a fee that seems reasonable for the service of decryption

Return the data without harm

These adversaries know that if they follow the business model, then they will stay in business. People would
rather pay a small "maintenance" fee than permanently lose their data.

Root Cause

WannaCry was not a virus or a payload for specific targeted attack, it was a worm.

WannaCry infects a system and then probes (discovers) the internal network for similarly vulnerable systems.

The attack exploited a vulnerability in Microsoft SMB protocol, that’s why most impacted systems were
Windows systems.

Server Message Block (SMB) is a file sharing protocol that allows Windows systems connected to the
same network or domain to share files. SMB also enables computers to share printers and serial ports
from other computers within the same network.

SMBv1 vulnerability could allow for Remote Code Execution (RCE).

However, Microsoft released a patch in March 14, 2017 to address the vulnerability 2 months before the
WannaCry attacks, which then occurred in May 12, 2017.

EternalBlue exploits the SMB vulnerability

The U.S. National Security Agency (NSA) discovered the vulnerability in the Windows implementation of the
SMB protocol. However, instead of reporting the vulnerability to Microsoft, it developed an exploit kit dubbed
‘EternalBlue’ to exploit the vulnerability.

The EternalBlue exploit kit was however stolen by the Shadow Brokers hacking group who later leaked the
exploit kit on April 08, 2017.

WannaCry Tools

WannaCry attack had multiple layers and utilized two key tools for exploitation:

EternalBlue

DoublePulsar

It’s a trojan backdoor tool. Once successfully executed, it runs in kernel mode, allowing for privileged
access on compromised systems.

WannaCry uses three primary commands

401.3 - Vulnerability Management and Response 27

 Ping — diagnostic tool used to test system reachability

Kill — system command used to terminate running processes. This tool can be highly effective for
disabling services such as antivirus.

Exec — used to run the remote code that the attacker wishes to execute on the victim system.
Ransomware as a Service (RaaS)
WannaCry may be news by now, and it’s mostly patched, but other ransomware has followed in its footsteps.

Methods are changing, but they’re still exploiting the known vulnerabilities which may exist on a large
percentage of the targeted systems.

Lack of segmentation is also a reason of ransomware spreading in the network.

Ransomware as a Service (RaaS)

The idea of RaaS is now possible, where cyber criminals can create a customized version of various types of
ransomware for profit.

The above example is of Satan ransomware and the ability to make your own customized version.

In this example, 30% of the profits go to the developer for the service.

In other words, you buy a unique instance of an author's ransomware, customized to your liking, and infect
systems with the goal of earning money.

Attacks Summary
Every major breach had one or more of the following commonalities:

A critical system was visible from the internet. Sensitive information and databases should never be
located in the DMZ or visible from the internet.

Unpatched and unmitigated vulnerabilities on the system visible from the internet.

Flags and security alerts that indicated vulnerability scanning and system enumeration taking place were
ignored and unmonitored.

A system that had weak authentication. Sometimes attackers do not need to exploit system
vulnerabilities, they can simply log in.

Security practices that would've helped to prevent/detect the attacks

Implementing DLP was maybe one way to detect the massive amounts of data was being exfiltrated from
inside the network.

Deploying some sort of host or network-based IDS.

401.3 - Vulnerability Management and Response 28

 Performing periodic vulnerability scans to identify potential problems before attackers can take
advantage of them

Common Attack Techniques

OS Command Injection

Attack
Some web application use OS level commands to perform certain functions.

For example, a mailbox application might make a call to the OS to create a new folder for a user’s
attachments and name the folder to match the username supplied by the user.

If the input is not properly validated, the user can type and OS level command like: ksmith; rm -rf / .

So, when the folder create mkdir command was run within the operating system, the rm -rf / command
would be run as a sperate command which deletes the entire filesystem beginning from the root / .

Defense
Avoid making system calls from within your application, especially to the system() function.

When possible, use built-in application functions instead.

Strip OS command and characters from input — if you must make system calls, you need to be aggressive
about filtering and validating user input.

A better option is: Define valid characters for input, and strip out everything else.

Buffer Overflow

Attack

401.3 - Vulnerability Management and Response 29

 By carefully crafting the input, the attacker can manipulate the return address to point to their injected
shellcode instead of returning to the legitimate program flow.

This allows the attacker to execute arbitrary code, leading to various consequences such as unauthorized
access, privilege escalation, or system compromise.

Defense
Update, patch and run latest versions of your:

Software

Languages/runtime environment/sever add-ons

Run a vulnerability scanner against your applications

Utilize endpoint protection suites offering exploit mitigations

Validate and sanitize (filtering, transforming or rejecting) user input that may contain harmful characters or
patterns.

SQL Injection

Attack

401.3 - Vulnerability Management and Response 30

 SQL Injection Explanation: [Link]

Test website for applying SQL injection: [Link]

It’s another vulnerability taking advantage of insufficient input validation.

SQL injection can lead to OS compromise; because some databases do allow the execution of system
commands.

Defenses
Validate User Input — only allow specific set of valid characters.

Have lengths limits on input — Many SQL attacks depend on long strings

Adding more tiers — Add an application layer between the web server and the database

Account used by web service to access the database should have restrictive rights.

It shouldn’t be able to add/drop/modify tables or stored procedures.

Do not display SQL errors to web users — Attackers can learn a lot from just seeing the error messages
when they’re trying different SQL injection techniques.

Monitor SQL error messages — monitoring SQL logs to detect if someone is searching for or exploiting SQL
vulnerabilities on your site.

Cross-Site Scripting (XSS)

Input Attack Defenses Summary

401.3 - Vulnerability Management and Response 31

 Define an allowlist — Only allow specific valid characters from user input to avoid characters that have
special meaning in scripting languages.

Be suspicious of all input, including HTTP headers and cookie data.

Validate all data on the server-side, not only the client-side — as the data on the client-side can be easily
manipulated.

Use an up-to-date well-validated third-party library of input checking routines.

Malware Analysis
Common Types of Malware
Viruses & Worms

Virus W orm

A type of malware that requires user interaction It’s a self-replicating (no user interaction) piece
to infect the system. of code that carries one or more exploits and
payloads.
Requires a host file, such as an executable or a
document. They often appear after a significant vulnerability
is reported. Exploit code is often published
Once executed, it often copies itself onto file
against publicly discovered vulnerability.
shares, removable medias, email copies.
It often scan systems for listening ports
It’s goal is often destructive, such as deleting
associated with vulnerable services, launch an
files, however they can do whatever actions
attack, and execute their payloads.
decided by their author.
Their goal is often to infect as many systems as
possible and set up a C2 channel.

Trojans

It’s a program that often performs the desired action (seems legitimate) of the victim, as well as the
malicious action.

Unlike viruses and worms, Trojans do not self-replicate but rely on social engineering tactics to trick
users into unintentionally installing them.
Example

Imagine if we wanted to create a trojaned copy of the network utility

program "netcat."

This is a tool that is commonly used by system administrators and penetration testers to move files around
on a network, open up ports, and perform other operations.

The easiest way to trojan the program would be to get a copy of the netcat source code.

If we want to open up a port on the victim's computer each time they run netcat, we could add code that
discretely runs at runtime.

No warning would be given to the victim, and the program would operate as expected in all other ways.

We could compile this new version of the program and publish it online for downloading.

Rootkits
Rootkits are a type of malicious software (malware) designed to conceal (hide) the presence of other
malicious software or unauthorized access on a computer system. They are particularly stealthy and

401.3 - Vulnerability Management and Response 32

 persistent, making them difficult to detect and remove. Rootkits typically target the most privileged level of
access on a system, known as "root" or "administrator" access, hence the name "rootkit."

Here's how rootkits work and their key characteristics:

1. Concealment (Hiding): The primary purpose of a rootkit is to hide malicious activities or unauthorized
access from the system administrator and security software. This includes hiding files, processes,
network connections, registry entries, and other system objects associated with the rootkit's presence.

2. Privilege Escalation: Rootkits often exploit vulnerabilities in the OS kernel or system drivers to gain
privileged access to the system. Once installed, they operate at the highest level of privilege, allowing
them to control and manipulate system functions without detection.

3. Persistence: Rootkits are designed to maintain persistence on the infected system even after reboots and
system updates. They often install themselves as kernel-mode drivers or modify system boot processes
(Bootkits) to ensure they are loaded early during system startup.

4. Remote Control: Many rootkits include remote control capabilities, allowing attackers to remotely access
and control infected systems. This enables them to execute additional malicious actions, such as stealing
sensitive data, launching attacks on other systems, or turning infected devices into bots for use in
botnets.

Adware and Spyware

Adware primarily focuses on delivering unwanted advertisements, while spyware is designed to secretly
monitor and gather sensitive information from infected systems for malicious purposes.

Adware
1. Purpose: Adware, short for advertising-supported software, is designed to display advertisements to
users, often in the form of pop-up ads, banners, or sponsored links, usually without the user's consent.

2. Functionality: Adware typically operates by embedding itself into legitimate software or web browsers,
modifying browser settings, or installing browser extensions or toolbars. It then monitors the user's
browsing habits, search queries, and online activities to deliver targeted advertisements based on the
collected data.

3. Monetization: Adware developers generate revenue through pay-per-click (PPC) advertising, affiliate
marketing programs, or selling user data to advertisers or third-party companies.

4. Impact: While adware may be considered less harmful compared to other types of malware, it can still
disrupt the user experience, slow down system performance, consume network bandwidth, and
compromise user privacy by collecting and transmitting sensitive information without consent.

Spyware
1. Purpose: Spyware is malicious software designed to secretly monitor and gather information about a
user's activities, often without their knowledge or consent. This can include capturing keystrokes, logging
passwords, recording browsing history, and capturing screenshots.

2. Functionality: Spyware typically infiltrates a computer system through malicious email attachments,
software downloads, or vulnerabilities in the operating system or applications. Once installed, it operates
stealthily in the background, collecting sensitive information and transmitting it to remote servers
controlled by attackers.

3. Goals: The primary goal of spyware is to steal personal or confidential information, such as login
credentials, financial data, or sensitive business information. This information can then be used for
identity theft, financial fraud, espionage (‫)تجسس‬, or other malicious purposes.

4. Detection and Removal: Detecting and removing spyware can be challenging, as it often operates covertly
and may evade detection by antivirus software. Specialized anti-spyware tools and security measures are
typically required to identify and remove spyware infections effectively.

Malware Analysis Stages

401.3 - Vulnerability Management and Response 33

 Fully Automated Analysis
As malware analysis is time-consuming and requires advanced skills. And with large number of suspicious
files, we need the fully-automated analysis in some way.

Some of the good things about it:

It has the ability to handle a large number of files.

It’s fast and saves time.

Provides a comprehensive amount of information in its reporting.

It’s has some negative things such as:

False positives against legitimate files and program.

Potentials problems with packed or obfuscated malware.

Limited detection capability vs malware that detects that its being analyzed (Self-defending malware).

Tools — Cuckoo Sandbox, CAPE, VirusTotal.

Static Properties Analysis

Execution of a malware specimen can be dangerous if not performed by a skilled analyst in a properly
controlled environment.

Performing static properties analysis allows us to learn about the intentions of a malware without actually
executing it.

We can learn things such as:

ASCII or Unicode strings.

Specimen hashes and section hashes

Potential of being packed or obfuscated

Indicators of Compromise (IOCs)

Tools — PEstudio, Detect-it-Easy, and others.

Interactive Behavior Analysis

Fully automated analysis and static properties analysis may not provide you with a comprehensive
analysis.

Maybe because the malware is obfuscated or encrypted, so extracting information without actually
running it isn’t practical.

By allowing the malware to run in a very controlled environment, we can monitor its behavior to allow a
more detailed analysis.

Some key things we can watch here is:

401.3 - Vulnerability Management and Response 34

 Registry access

Filesystem access

Process behavior

Network activity

Tools — ProcMon, RegShot, ProcessHacker, Wireshark.

Manual Code Reversing

It’s the most advanced form of malware analysis as it requires advanced skills to perform it.

Tools such as disassemblers and decompilers are commonly used in this phase.

A disassembler takes a compiled program, such as an executable file or a Microsoft Word document, and
converts it to machine code to form assembly, known as disassembly.

This allows the analyst to look at the code instructions to determine its intention.

The analyst can then choose to decompile the assembly code to convert it to form a pseudocode using a
decompiler. This would be easier for people who can read programming languages such as C++ and
C#.NET.

Web Application Security

In this module we’ll learn:

Some of the most important things you need to know in order to design and deploy secure web applications.

We’ll learn the basics of how the web works, as there are a lot of professionals who deal with these technologies
everyday without knowing how they work. It’s difficult to secure something if you don’t know how it works.

We’ll learn about HTTP, client-side programming, cookies, authentication and maintaining state.

Web Communication Basics

Web communications is what happens over HTTP
HTTP (Hyper Text Transfer Protocol) is a foundational protocol that creates the concepts of world wide web
(www), in things like web browsing.

Web and Internet are not the same — It’s important to not have a misunderstanding of the web conflate (mix up)
it with the internet.

The internet is a global collection of autonomous systems and networks that can carry protocols of
communications, while HTTP can be an example of a protocol which operates within the internet (as we
discussed in book 1).

The idea of the internet was founded in the 1969 while HTTP was introduced around 1989.

Client-Server Communications
Web based communications represent server (web server) and client (browser) communication.

When it comes to client-server communication, a developer should think of whether he should keep track of the
state of the the communication or not (stateful or stateless).

Stateful communications — In stateful communications, we keep track of every communication happens

between the client and the server so that we can dynamically adjust relative to what’s happening (conditions).

The idea of creating web and HTTP — When the concepts of the web was initially created, the idea was to
easily share publicly available information like files (in a form of a web page for example) to any place in the
world, there’s no need to have a state (stateless).

Example: When you visit an e-commerce web site, and add some stuff to your cart, you’d open the cart and
find nothing (that’s stateless). It’s just a static file appearing on your screen, no need for dynamic files. That’s
because it was only designed to share information, not to keep state of communication.

It’s just a file server which’s done differently — Initially a web server is just a file server which’s done in a
different way and transmits information using HTTP instead of things like FTP.

401.3 - Vulnerability Management and Response 35

 So, the web was designed to be stateless (not stateful), and whenever we use something in a way that it wasn’t
designed for, it introduces security weaknesses. We actually need state today.

Readable HTTP Communication

Because publicly available data was meant to be easily accessible, we need to know that HTTP was readable as
well. We can read a lot of information about the communication like the example of the request and response,
and if you sniff, you’d be able to see things like GET, HEAD, POST, PUT.

HTTP is plaintext, there’s no confidentiality, it’s end-to-end unprotected. Because if something is generally
available to the public, there’s no need to protect it in-transit.

We don’t implement security just for the sake of security, we always need to implement it for a reason.

If you want confidentiality, you’d use HTTPs (Hyper Text Transfer Protocol Secure), completely different
protocol, also operates on a different port number.

HTTP operates on TCP Port 80, while HTTPs operates on TCP Port 443.

Web Communication Structure

User-Agent — is a string used by web browsers to identify themselves to webservers.

User-Agents can give you information about what browsers are being used, which means you can:

Monitor your network and check if someone in your organization has installed different browsers than the
one they should use, because chromium-based browsers like chrome and edge don’t require administrative
privilege to be installed.

Monitor malicious traffic because adversaries can have their custom User-Agent strings, to bypass WAF and
IDS/IPS that may flag known malicious User-Agent strings.

import requests

# Define the custom User-Agent string

custom_user_agent = "MyEvilBot/1.0"

# Set headers with the custom User-Agent string

headers = {
"User-Agent": custom_user_agent
}

# Make an HTTP GET request with the custom User-Agent

url = "[Link]
response = [Link](url, headers=headers)

# Check the response status code

if response.status_code == 200:
print("Request was successful!")

401.3 - Vulnerability Management and Response 36

 else:
print("Request failed:", response.status_code)

Cookies

It would be impossible to build even a simple shopping cart system without knowing the user’s past actions such
as adding items to the cart (same E-commerce website example).

Web designers started by adding state information into the URLs, which produced complex URLs
like: [Link] .

They decided there must be a better way to save the state of information, and here came the idea of cookies.

What is a cookie?
It’s a piece of data created by a web server and stored in the web browser.

Both the name and contents are chosen by the application and can be almost anything the programmer wants.

Setting a Cookie

from flask import Flask, make_response

app = Flask(__name__)

@[Link]('/')
def set_cookie():
# Step 1: Create a response object
response = make_response("Cookie has been set!")

# Step 2: Set the cookie in the response

response.set_cookie('username', 'john_doe', max_age=3600, httponly=True)

# Step 3: Return the response with the set cookie to the user's browser
return response

if __name__ == '__main__':
[Link](debug=True)

When servers set a cookie — the server sets a cookie in the HTTP response and sends it to the user's browser,
and the browser saves the cookie locally.

The cookie typically includes a name-value pair (e.g., 'username'='john_doe') and any optional attributes such
as expiration time, domain, and path.

The cookie is sent in every subsequent request as a part of the HTTP request headers — After the cookie is
saved in the browser, the browser includes it in subsequent HTTP requests to the same server. This process is
automatic and transparent to the user. The cookie is sent as part of the HTTP request headers, allowing the
server to identify the user and maintain session state or remember user preferences.

Cookies can contain virtually anything, but they're most commonly used to keep track of user authentication
and application session state.

Do cookies violate our privacy?

401.3 - Vulnerability Management and Response 37

 Cookies don’t take your information forcibly — Some people think that cookies somehow magically take
information from your computer and spread it around the internet. And it’s simply not so. For a cookie to exist, it
must have been set by a web server and can only be sent back to that web server (or other web servers within
the same domain).

Cookies have information you only provide — The web server must specify the contents of the cookie at the
time it’s created, and it cannot go snooping around your hard drive to find the information it wants. Which means,
any information that cookie has, you’re the one who already provided it with this information.

Cookies can contain sensitive data and can be sniffed — As cookies may contain sensitive data, such as credit
card numbers or PINs, it could be vulnerable to being sniffed, as it’s sent to the server with each request our
browser makes.

Websites mostly encrypt sensitive cookies — Most websites encrypts the contents of these sorts of cookies,
so for an attacker to recover the data inside it would be difficult.

Persistent vs Session (Non-Persistent) cookies

Cookies are not all the same, we have two different types of cookies: Persistent and Non-Persistent cookies.

Persistent Cookies

Most cookies are persistent cookies.

Stored as a text file on disk — When a browser receives them, it stores them in a text file on the disk.

They can be loaded to the browser when restarted — And when it exists, the cookies are still in the file, so that
the next time the browser starts up, it can load them back into memory and they’ll still be active.

Expiration Dates — They have expiration dates, after which time the browser will delete them.

They can survive a reboot.

Infinite Expiration Dates — Some sites get around this restriction by setting the expiration date to years in the
future, causing the cookies to persist infinitely.

Viewing and Editing Cookies — These days, most browsers offer some way to view the cookies. You can view
them from developer options (Inspect) in any browser, and you can edit them as well.

Session (Non-Persistent) Cookies

They can only survive a current session.

They’re usually stored in memory.

Ending a session destroys cookies — After ending a session, closing the browser destroys them and renders
them inaccessible to the next user of that computer.

They cannot survive a reboot.

Good for users who access the application from shared computers — they are well-suited for web applications
that need to maintain user state or session information temporarily while the user interacts with the application,
especially if users might be accessing them from a shared computer (library computer for example).

They can still be edited by using a proxy — In memory, cookies can still be edited by either a user or a machine
in the middle (attacker) by using an application that sits between the client computer and the web server,
which’s commonly called a proxy. An example on a proxy would be OWASP ZAP.

First-party and Third-party cookies

First-party cookies and third-party cookies are both types of HTTP cookies, which are small pieces of data sent
from a website and stored in a user's web browser while the user is browsing that website. However, they serve
different purposes and have distinct characteristics:

1. First-Party Cookies:

Definition: First-party cookies are set by the website that the user is currently visiting. They are directly
associated with the domain of the website being visited.

Purpose: First-party cookies are primarily used to enhance the user experience on the website. They can
remember user preferences, maintain login sessions, store shopping cart items, and track user behavior
within the website.

401.3 - Vulnerability Management and Response 38

 Examples: Login cookies, session cookies, preferences cookies, shopping cart cookies.

2. Third-Party Cookies:

Definition: Third-party cookies are set by domains other than the one the user is currently visiting. They
are often associated with third-party advertising or tracking services.

Purpose: Third-party cookies are typically used for cross-site tracking, behavioral advertising, and
analytics. They allow advertisers and analytics providers to track users across multiple websites and
build profiles of their online behavior.

Examples: Advertising cookies from ad networks, tracking cookies from analytics providers, social media
cookies embedded in share buttons or widgets.

Here are some key differences between first-party and third-party cookies:

Origin: First-party cookies are set by the website the user is actively visiting, while third-party cookies are set by
domains other than the one the user is currently visiting.

Storage Location: Both types of cookies are stored in the user's web browser, but they are associated with
different domains.

Control and Privacy: Users generally have more control over first-party cookies because they are directly
related to the website they are interacting with. Many web browsers offer settings to manage first-party cookies,
such as blocking them or clearing them on exit. Third-party cookies, on the other hand, are often used for
tracking and advertising purposes, raising privacy concerns. Some web browsers offer options to block third-
party cookies or implement tracking protection mechanisms.

Regulation: Due to privacy concerns and the potential for abuse, there have been regulatory efforts to limit the
use of third-party cookies. For example, the European Union's General Data Protection Regulation (GDPR) and
the California Consumer Privacy Act (CCPA) include provisions related to cookie consent and user privacy, which
affect both first-party and third-party cookies.

SSL/TLS
What if we want to secure confidential communications on the web?
SSL is a protocol that provides an encrypted tunnel between two SSL-aware applications.

Virtually all web browsers and HTTP servers support SSL, at least as an option.

HTTPs = HTTP + SSL/TLS — HTTPs is just HTTP which uses helper protocols like Secure Socket Layer (SSL)
and Transport Layer Security (TLS).

End-to-end encryption where data is secured in-transit only — End-to-end encryption means that the
communication and data are encrypted while being in transit (HTTPs), but the data is not encrypted at-rest (on
the device).

SSL had vulnerabilities then TLS was introduced — SSL was introduced first, but it had a serious number of
vulnerabilities, and so TLS came as a successor.

So, you’re not supposed to use it, and use TLS instead, also later versions of TLS. But at last, they both serve
the same idea, which’s end-to-end encryption.

TLS is the successor of SSL — The industry says SSL, but when implemented is literally TLS not actually SSL.

This happened because SSL became synonymous with the idea of end-to-end encryption. So, you always
need to make sure when someone talks about SSL, that he implements TLS not SSL.

As for why SSL is sometimes referred to as TLS, it's important to understand that TLS is essentially the
successor to SSL. When TLS was first introduced, it was designed to be backward compatible with SSL to
ensure a smooth transition to the new protocol. As a result, TLS retains much of the syntax, structure, and
functionality of SSL, while also incorporating enhancements and improvements.

SSL/TLS secures communications not applications — HTTPs doesn’t mean your application is secure, or it
doesn’t have buffer overflows, SQL injection vulnerabilities, command injections attacks.

Some people only consider SSL’s encryption function, however it performs three important functions:

Encryption — Protect the confidentiality of data as it passes over the network.

401.3 - Vulnerability Management and Response 39

 Server identity verification — the name on the web server SSL certificate needs to exactly match the
domain name of the browser’s address bar. This confirms to the users that they’re talking to the server to
which they think they’re talking to.

Data integrity — it ensures that the data sent between the two endpoints arrives whole and intact.

Is it always HTTP from servers? Or can it be HTTPs?

It depends on the developer (retailer example in US vs in Europe).

Desktops/Laptops
How many do online banking using a laptop/desktop?

How many look at the URL before username and password?

How often to you double check?

Mobile Phones
How many do online banking using an app on mobile phone?

How many look for the lock sign or HTTPs to make sure its encrypted?

It happens for a lot of companies where the website uses HTTPs while the mobile app uses HTTP, because most of
the mobile applications are developed for companies by third-party developers.

Developing Secure Web Applications

OWASP Top Ten

Embedded security earlier in the process is intended to help prevent application vulnerabilities from being
introduced.

Consensus list of the most critical web application security issues.

There’s no fixed schedule for updating OWASP Top 10.

The list is the same every update, but in different order.

[Link]

How to Develop Web Applications

People have to be trained on how to write better code.

Most people who’re studying in universities, are studying a syllabus from a book which’s more than 20
years old.

If we don’t teach people properly from the beginning, they end up with bad habits, and bad habits are
hard to change.

Security must be built in the SDLC

401.3 - Vulnerability Management and Response 40

 Training Developers — Developer training on vulnerabilities, web application attacks, errors and best coding
practices.

Concepts such as input validation and session tracking are common to most web applications.

Peer reviews helps detecting errors earlier in the process — Code should be reviewed by others (peer
reviews) as it’s effective for detecting defects or other errors. It can also be an important supplement to
testing, because they can find errors earlier in the process that might not show up during debugging/testing
phases.

Software testing — It’s the process of executing a program or system with intent of finding errors. A formal
and complete test plan is necessary to ensure it covers all possible events or scenarios that might occur
when the program is placed in production.

Functionality Testing

It’s important to test how the application will respond to expected, unexpected, or invalid input.

Manual and automated testing — Good test procedures often include a combination of manual and
automated testing activities.

Performance Testing

This helps to demonstrate that the architecture and resources provided are sufficient for the web
application's needs.

Also helps to determine what threshold exist and what risks might be present for DoS attacks.

Configuration management and version control — Without a configuration management and version control
system, developers can be working on older versions of code or can be making conflicting changes to code
or systems. Some important components of configuration management:

Having separate environments for development, testing and production.

Changes shouldn’t be directly made into production — Changes should never be made directly to the
production environment, and where possible, a separate team from developers should be responsible for
moving code into the production environment.

This helps ensure that processes are followed, tweaks, backdoors, or undocumented fixes aren’t placed
into production environment and overlooked.

Basics of Secure Coding

It’s about best practices when it comes to code, because there’s no secure code. Your code will always have
vulnerabilities, but you can make them less.

When people end up using code from the internet, which’ve been used by many people and it’s not reviewed,
such as cryptographic libraries, it may have vulnerabilities which may have a huge impact on people who’re
using it (just like HeartBleed).

Assume all code has vulnerabilities, even YOUR code — You surely won’t be able to write every single
piece of code, because a web application consists of a lot of different parts of code, where we can use

401.3 - Vulnerability Management and Response 41

 frameworks and public libraries. But you need to realize that every piece of code might have a
vulnerability, even the code that you write.

Daily reviews before deployment improves security a lot — Reviewing code daily, and fixing it before
being deployed and put into production is an effective way to reduce a lot of vulnerabilities that you might
face. Because once the code goes into production, it’ll be really hard to make changes.

Web Application Vulnerabilities

In order for an adversary to compromise a web application, they have to find just one vulnerability.

Web Application Authentication

The idea of HTTP was sharing the information that’s publicly available for everyone. So, Why would we need to
authenticate people for information that’s publicly available?
The two most commonly seen web authentication methods are:

HTTP Authentication
In HTTP authentication, the user’s authentication credentials are sent within the HTTP headers. There are two
types for this authentication:

Basic mode
1. Client sends a request

GET /example HTTP/1.1

Host: [Link]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/w
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

2. Server sends a response for authentication

HTTP/1.1 401 Unauthorized

Date: Mon, 28 Feb 2024 [Link] GMT
Server: Apache/2.4.41 (Unix)
WWW-Authenticate: Basic realm="Example Realm"
Content-Length: 123
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html>
<head>
<title>401 Unauthorized</title>
</head>
<body>
<h1>Unauthorized</h1>
<p>This server could not verify that you are authorized to access the document
<p>Either you supplied the wrong credentials (e.g., bad password), or your bro
</body>
</html>

401.3 - Vulnerability Management and Response 42

 3. User enters his credentials and client sends the same request with the credentials included in the
HTTP header. The user ID and password are base64 encoded, which is easily reversible.

GET /example HTTP/1.1

Host: [Link]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/w
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

4. Server receives the request and decodes the base64 encoded credentials, and tests whether
they’re correct or not

HTTP/1.1 200 OK
Date: Mon, 28 Feb 2024 [Link] GMT
Server: Apache/2.4.41 (Unix)
Content-Length: 123
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html>
<head>
<title>Example Page</title>
</head>
<body>
<h1>Welcome to the Example Page</h1>
<p>This is a protected resource.</p>
</body>
</html>

Here, you type your username and password and send them across the network, unprotected.

Just like FTP and TFTP, they’re easily sniffable as they’re plaintext.
Issues with basic mode
This means that the application is also storing my credentials as plaintext?

Yes, some applications save usernames and passwords as plaintext.

Also, this means that if someone breaks into the application, he can steal all plaintext usernames and
passwords.

Remember when talking about password dumps?

Did the attacker steal the hashes and crack them then released the passwords?

Or did he just steal the plaintext password?

In late 2020, Facebook disclosed that 50 million user accounts still had their passwords stored plaintext
on Facebook servers and Facebook engineers had access to the passwords.

That’s why we need MFA and unique passwords for every single website — And that’s why you need
MFA, and a unique password for every single website (password manager); because your password
can be stored in plaintext, and if you’re using the same password everywhere, and this password gets
compromised, it’s a game over scenario.

Having MFA adds an extra layer of security, where the password compromise is ≠ account
compromise.

You can add it to many web applications, there’s a lot of open source code to implement a 2nd
factor.

It can be a 6 digit number on a software-based token that’s regenerated every 30/60 seconds.

401.3 - Vulnerability Management and Response 43

 You should also consider doing that for your personal accounts linked Facebook, Microsoft,
LinkedIn, etc.
Digest Mode
It’s similar to basic authentication, but instead of base64 encoding, it uses a one-way cryptographic
MD5 hash to create a hashed password that is sent within the HTTP headers across the network..

It’s still sniffable, and you can sniff the hash and crack it.

But does he need to crack it?

Replay Attack (pass-the-hash) — If you send your MD5 hash and login, then anyone can send
your MD5 hash and login the same as you.
HTML Form-Based Authentication
It’s common to use <INPUT TYPE="PASSWORD"> tag for the password input field.

Obscures characters with asterisks and contents are not auto-filled or cached — This field type
obscures the typed characters with asterisks (*) as they’re displayed on the screen, and the contents of
password fields are not cached or auto-filled when you reload or navigate between screens.

ID & passwords are plaintext, so we need SSL/TLS — The user ID and password are sent cleartext along
with any other form data, so a separate mechanism, such as SSL, is required for secure form-based
authentication.

Common Attacks Against Web Application Authentication

Guessing or brute forcing of user accounts and password

Default accounts — Many systems and web apps have default admin, test, or demo users that many
admins forget to disable or change.

Guessing credentials — Apart from default accounts, attacks often try to guess valid user IDs and
passwords for applications.

Giving same authentication errors — Web Apps should give exactly the same response for all
authentication errors (invalid user ID, invalid password, account locked, etc.). This prevents the
attacker from determining valid user IDs by guessing or brute forcing.

Implementing account lockout policy — It’s also important to implement account lockout policy for
repeated incorrect password attempts, which makes it difficult for the attacker to perform brute
forcing or even dictionary attacks.

Sniffers, keyloggers, phishing emails, social engineering — Sniffing the credentials if attackers can
compromise the network, or by using a keystroke logger, or even through phishing or other social
engineering attacks.

💡 Multi-factor Authentication & One-time passwords can be a response to these weaknesses in

password-based web authentication schemes.

Access Control

Make sure that your web users can’t go where they are not supposed to go within the web server

Many web developers consider only the path that a typical user will take through the site, from the home
page → login page → any page with a hyperlink.

401.3 - Vulnerability Management and Response 44

 As a security professional, you need to consider the path the attacker is going to take.

Preventing users from accessing custom code libraries and configuration files built along with your
website

It’s common for web developers to put shared functions and subroutines into separate files that are
included or accessed by each page on the website.

Attackers might guess the name and location — If these files exist within the folders published by a web
server, an attacker might guess the name and location of files.

Blocking through naming, location, access rights, and other controls — You can block users from
accessing code libraries and configuration files directly through naming, location, access rights, and other
controls on the web server.

Disable directory browsing

Many web servers permit users to browse directories. This means that the user can get a list of the files
and folders within the directory of the website.

Surely that’s not something we want to happen, because this might allow users to find code libraries,
configuration files, older versions or backups of published pages.

URL directory traversal attacks

They are a kind of a combination of flawed access controls and an input attack.

With directory traversal, the user exploits vulnerabilities on the web server to access restricted
directories, execute commands, and view data outside of the directories meant to be published by the
web server.

Session Tracking
Session Tracking/Maintaining State

HTTP is stateless — this means, each individual request & response pair is independent of all previous
and future requests & responses exchanged between webserver & client.

If a web application needs to track a user over a series of web requests, it needs to handle the tracking
itself.

The most popular technique for tracking a user through multiple web requests is the use of session IDs.

When the user requests the first webpage in their session, the server creates a unique identifier,
usually a random number or string, and sends it back to the client along with his web request.

Session IDs are sent to the web server on all subsequent requests — This session ID is often stored
as a hidden form element, part of the URL query string, or in a cookie. These methods cause the
browser to send the same session ID back to the web server on all subsequent web requests.

Hacking Session Information

Session attacks can be as simple as convincing the application that you logged in as another user, or as
complex as tricking it into shipping a basketful of items that were never paid for.

401.3 - Vulnerability Management and Response 45

 URL Session Tracking

The user session ID is passed with the URL.

This method is the easiest to implement, but it’s also the ugliest.

All attackers need to do to attack this mechanism is to edit the number is their browser’s URL bar.

Also, when such URLs are shared by users who don’t know, their session can be used by others, leading
to a hijacked account.

Hidden Form Elements

The state information is embedded into hidden fields in an HTML form.

These hidden fields are never displayed to the user.

Seeing hidden fields through browser’s View Source — Hidden fields are convenient but aren't hard to
alter. Attackers like to see hidden fields and will often use their browser's View Source command to look
for them.

Saving & editing HTML pages then loading it back — If they happen to find one they want to change, they
can simply save the entire HTML page to their hard drive, edit the field value, and load it back into their
browser.

Modern browsers and editing HTML data — Most modern browsers even support editing of the HTML
data of a webpage in some kind of "developer mode". If they fill out the other fields and click the "Log on"
button, they send the modified data instead of the original!

Cookies

The user information is stored by the browser as a cookie.

Protection from Session Attacks

Most session attacks require the attacker to guess another user’s session ID.

Ensure session IDs are random and sufficiently long

Session tracking toolkits — Using session tracking toolkits that are already available with your web
development framework. Don’t try to reinvent the wheel.

Testing predictability — Use a tool to test predictability of session IDs such as Burp. It can collect a
sample of session identifiers and graph the distribution of session IDs over time.

Hashing or digitally signing session IDs — This can be used to test each session ID received to
ensure if it’s valid or not before acting upon it.

Store and pass only session IDs between the browser and server; store other session information in a
database keyed by session ID

This should be done as data could be intercepted and manipulated by the attacker.

Even if the data needs to be on the client side, ensure the data is encrypted.

Provide a new session ID immediately upon user authentication

Have session IDs expire on logout or periodically timeout

401.3 - Vulnerability Management and Response 46

 When a user logs out, their session ID should become invalid both on the client and on the server.

If a user leaves the site without logging out, the session ID should expire within a short period of time.

Web Application Monitoring

The attacker can cause website deformation or unauthorized changes

Spreading social or political messages — Basic deformation can be in a form of spreading a social or
political message.

Steal information or direct users to malicious sites through modified links — Other attacks, the attacker
might change important links or forms to steal information or redirect the user to malicious sites.

Hiding webpages on your webserver and using it for phishing attacks — An attacker might hide new
webpages on your server, this happens commonly for phishing attacks, where the phisher uses your web
server to host the webpages that are the link destinations for phishing emails.

Detecting the defacement (deformation)

You can detect this type of defacement by monitoring the content produced by the web server, and by
monitoring the files and configurations on the webserver itself.
Content Monitoring

For content monitoring, implementing a system that loads and compares pages periodically — To
monitor the content produced by the web server, you can implement a system that loads the
webpages periodically (such as once an hour) and compares the newest result to a known valid prior
page load.

Webserver Monitoring

For webserver monitoring, you can use a file integrity checker.

How does a file integrity checker work?

A file integrity checker monitors the filesystem based on a number of present rules and
generates alerts when files are added, modified, or deleted out of compliance with those rules.

Implement a system to record and alert when the web application becomes unavailable

This provides the application owner protection against hardware, software, and network failures in
addition to denial-of-service (DoS) attacks.

A systems that loads a webpage and checks for errors — The most basic systems load a webpage and
generate an error condition if the webpage does not load successfully.

A system that logs in as a valid user and checking for expected results — A more complete and rigorous
test would involve a recurring process that logs in as a valid user, performs a transaction or query within
the application, and checks to see whether the expected result is returned.

Web Application Firewall (WAF)

WAFs provide the ability to monitor and block malicious HTTP/HTTPs traffic.

401.3 - Vulnerability Management and Response 47

 They look for common attacks, behaviors, and vulnerabilities like the ones defined in OWASP Top Ten.

Many WAFs are deployed in monitor mode only, which has the risk of blocking legitimate traffic. That’s why
WAFs needs constant and attention and tuning.

There are two types of WAFs: Traditional WAFs & Next-Generation WAFs.

Considerations
WAF can work great with well known vulnerabilities. Because if you know a vulnerability exist, you can let it
know, and then it blocks it.

But what if you’re working on your custom web application?

You’ll probably have no vulnerabilities, because you didn’t discover any of them yet.

So every vulnerability counts as a zero day, which explains some of the limitations of WAFs.

This demonstrates the defense-in-depth idea, and that there’s no silver bullet for having a better
security.

And that’s why we talked about a web application in Book 1, and the idea of a 3-tired architecture and its
benefits. That you shouldn’t have all the components of a web application on a single machine, where
it’ll have a single point of compromise. The middle tier can be a WAF.

Security Operations and Log Management

One of the challenges in cybersecurity is the timely detection of attacks.

Adversaries compromise systems for a long time before an organization detects it.

One of the primary reasons is not having proper visibility of what’s happening on your systems.

Logs contain events that are the evidence so you can track, find, and monitor the adversary. They provide the
information that is required for timely detection.

While turning on logs is important, ensuring that you’re having the right logs is more important.

As too many organizations turn on logging, and it ends up for them with many logs that do not have any value
to them.

Logging Overview
Terms and Definitions

Ultimately, logging is a key accountability mechanism across IT.

Let's look at a few of the key terms:

Message: Some system indication that an event has transpired

Log file: Collection of the above log records

Alert: A message usually sent to notify an operator

401.3 - Vulnerability Management and Response 48

 Device: A source of security-relevant logs

There are plenty of other terms in logging:

Logging: The act of creating a log

Auditing: Sometimes used to name act of reviewing log records for the purpose of auditing

Monitoring: Real-time or near-real

Alerting: Sending a signal to an operator (the signal alert is treated as a type of log as well)

Debug traces: Special logs specific to application debugging or tracing

Lots of Log Data Floating Around

Every machine has the capability to write logs.

More and more data to collect. This can happen due to:

Growth in log volume — People log more.

Number of sources — People collect logs from more sources; each system, application, appliance, or any
device, maybe writing a log or often more than one.

Most systems will have its own language or log format

Before standards are developed and adopted, we had to face multiple log formats and transport
mechanisms, as well as the level of recorded details.

A large amount of organizations’ data may be logs

According to some estimates, a significant percentage of all organizations' data might be logs (as broadly
defined).

Logs can be overwhelming if they aren’t properly managed.

💡 The key to successful logging is to focus on quality of logs, not the quantity!

Example: Build a Simple Syslog Server

401.3 - Vulnerability Management and Response 49

 First, prepare your environment:

1. Build a Linux server; any reasonable hardware and any distribution (CentOS, Fedora, or anything else) will do.

2. Deploy it on the network where you can access it and make sure that it's close to the other server producing
logs.

3. Only allow SSH (TCP port 22) for management and the appropriate syslog ports:

UDP 514: This is the least secure option, as spoofing is possible due to the lack of sequence numbers and
control flags.

TCP 514: Reliable syslog service using TCP as opposed to UDP, helping to prevent simple spoofing
attacks.

Open any ports necessary for log agents to transmit logs inbound to the log server.

Now you are ready to operate it:

1. Configure assets to forward logs via syslog or use log agents to ship logs.

2. Retention Policy — Configure log system to purge logs based on organizational retention policy. This
configuration is custom to each software solution.

For example, in syslog servers, one would use [Link] . For other solutions, there might be a
lifecycle management policy that can be enforced within a GUI.

Payment Card Industry Data Security Standard (PCI DSS): Requires organizations to retain audit trail
history for at least one year.

Health Insurance Portability and Accountability Act (HIPAA): Requires healthcare organizations to retain
audit logs for at least six years.

3. Parsing and augmenting logs — Optionally, parse and augment logs. Parsing involves using regex to extract
text values from a log and store them into fields. Augmentation involves added context to a log given its
current information.

For example, a log containing an IP address could have geolocation information looked up against the IP
address and then stored inside the log for later correlation and searching.
Log Collection Architecture

401.3 - Vulnerability Management and Response 50

 Log Relay

A log relay acts as an intermediary between log sources (e.g., servers, applications, network devices) and a
centralized log management system.

It collects log data from multiple sources, aggregates it, and then forwards it to a designated destination,
such as a syslog server, SIEM (Security Information and Event Management) platform, or log analytics
service.

Windows Event Collector (WEC)

It is a feature in the Windows operating system that enables the collection and forwarding of Windows event
logs to a centralized location for analysis and monitoring.

Process of Log Collection

1. Log Agents

Log agents are installed on individual servers, workstations, or devices to capture log data generated by
operating systems, applications, services, and network devices.

Log agents collect log messages locally and preprocess them, which may involve parsing, filtering, and
enriching the log data to extract relevant information or add context.

Once the log data is processed, log agents transmit it to designated log relays using a specified protocol
or transport mechanism. This could be syslog, TCP, UDP, HTTP, or other protocols supported by the log
relay.

2. Log Relays

Acts as an intermediate node — They serve as intermediate nodes in the logging architecture, receiving
log data from multiple log agents and aggregating it before forwarding it to centralized log management
servers.

Operates at strategic locations to optimize log transmission — They typically operate at the network
perimeter or in strategic locations within the infrastructure to optimize log transmission and reduce
bandwidth usage.

Upon receiving log data from log agents, log relays may perform additional processing, such as load
balancing, protocol conversion, or encryption, before forwarding the logs to centralized log
management servers.

3. Centralized Log Management Servers

They receive log data forwarded by log relays and store it in a centralized repository or database for long-
term retention, analysis, and monitoring.

These servers may be hosted on-premises or in the cloud, depending on the organization's requirements
and preferences.

They provide features for searching, querying, analyzing, and visualizing log data, as well as
generating reports, alerts, and notifications based on predefined rules and criteria.

401.3 - Vulnerability Management and Response 51

 Lack of Accepted Log Standards

SIEM solutions provide their own log agents

Many SIEM (Security Information and Event Management) solutions provide their own log agents or
forwarders tailored to collect, standardize, and forward logs from various sources to a centralized server.

These log agents or forwarders are typically designed to integrate seamlessly with the SIEM platform and
support standardized log formats and protocols.

How Log Agents parse logs for standardized format before sending it to SIEM?

<PRI> TIMESTAMP HOSTNAME APP_NAME[PID]: MESSAGE

<PRI> : The priority value, which combines facility and severity level.

TIMESTAMP : The timestamp when the event occurred.

HOSTNAME : The hostname or IP address of the system generating the log.

APP_NAME : The name of the application or process generating the log.

PID : The process ID of the application or process generating the log.

MESSAGE : The actual log message.

Consider the following syslog-formatted log message:

<34> Feb 24 [Link] myhost sshd[1234]: Authentication failed for user john from 192.168

PRI : 34 (Facility: 4, Severity: 3)

TIMESTAMP : Feb 24 [Link]

HOSTNAME : myhost

APP_NAME : sshd

PID : 1234

MESSAGE : Authentication failed for user john from [Link]

The log agent would parse this message and store it in a structured format, such as JSON:

{
"timestamp": "Feb 24 [Link]",
"hostname": "myhost",
"app_name": "sshd",
"pid": 1234,
"severity": "34",

401.3 - Vulnerability Management and Response 52

 "message": "Authentication failed for user john from [Link]"
}

How to Start Managing Logs

Log Filtering

Logs are not created equally — When dealing with logs, we should consider the fact
that all logs are not created equally.

Some logs are great for identifying unauthorized activity, others are great for
meeting compliance, others are noisy and pointless.

There are three collection strategies, hybrid tends to be the recommended approach,
where we collect everything then analyze data, then determine accordingly what’s
important and filter out the rest.

Setting Up and Configuring Logging

Selecting Log Analysis Tools

Log collection tools

Examples are syslog-ng (general purposes logging + reliable delivery + a lot of convenience features),
NXLog, Winlogbeat, Fluentd, and more.

Secure centralization

It’s the protection of logs in transit.

401.3 - Vulnerability Management and Response 53

 Some examples include Stunnel (SSL/TLS encryption), OpenSSH, and IPsec.

VPNs offer this capability and can be used if log encryption is needed.

Many logging devices (such as network devices) might not support end-to-end encryption, this security
measure becomes difficult.

If possible, choose a log agent or service that support TLS encryption.

Pre-processing

It’s the task of converting logs from one format to another.

For example, NXLog helps convert multi-line logs → single line format.

Storage

Log storage may be not a challenge when we’re talking about MBs or even GBs, but multiple terabytes
and then petabytes can be a serious challenge.

One can always store logs in flat files (such as standard files in /var/log/syslog ).

Another way which’s currently used, major logging systems prefer non-relational storage such as
Elasticsearch and Hadoop.

Analysis tools — SEC, OSSEC, OSSIM, Elastic Stack (Elasticsearch, Logstash, Kibana).
How to Start Using the Tools

Log Monitoring Strategy

401.3 - Vulnerability Management and Response 54

 This strategy helps us to answer questions such as:

How do we plan a response strategy to activate when monitoring logs?

Where do we start the process?

How do we tune it for more efficient analysis?

Setting Up a Log Monitoring Program: Phased Approach

Challenges to Organization-Wide Log Management Deployment

Data crossing network and state boundaries

For example, can an analyst located in the United States be monitoring logs that originate in France?

401.3 - Vulnerability Management and Response 55

 Data privacy law and other cross-border concerns related to moving sensitive data (yes, logs are
sensitive data!) also make deployment complicated and mandate (‫ )تفرض‬the involvement of a legal team.

Access to remote locations with data sources

The team that plans and executes the log management strategy might need to travel to remote locations
where the log sources are, or obtain the cooperation of system administrators from such locations.
Log Aggregation and SIEM

One of the best ways to begin creating a baseline on your network and systems is to aggregate all the logs
on your network and correlate them for analysis of the behaviors on the network.

Centralizing your logs in your network is a first step to begin aggregation for correlation and analysis.

Normalize Logs

After centralizing the logs, you should copy them so that the copies of the original logs are normalized
and correlated.

Logs are not only for threat detection, but also for compliance

You should do this because often you are collecting logs not only for threat detection but also to
meet some regulatory enforcement or compliance. Those regulations require you to be able to look
back at the original logs in the event of a compromise.

Correlating means logs have been changed (normalized)

If you are correlating, that means the logs have been normalized; in other words, those logs have
been changed and potentially may not be admissible in court in the event prosecution is necessary.

The moral of the story is to always have a separate log aggregator and correlation server.

Correlating normalized logs

Gaining understanding of what’s happening across the environment

When your logs are normalized, you can then begin to correlate across multiple systems and
platforms to gain an understanding of what is happening across the environment throughout the
day.

This is done by SIEM solutions

This helps you quickly discern whether there are anomalies. The solution used to do this aggregation
and correlation is called a SIEM, which stands for Security Information and Event Monitoring.

Ensure all systems are using the same time zone to reduce confusion

To reduce confusion, ensure all your systems are configured to use the same time zone.

Use UTC time when comparing logs

If your systems span multiple time zones physically, it is recommended you use UTC time; otherwise,
normalizing your logs gets more difficult because now you have to adjust for time zone differences
when comparing logs.

SIEM: Overview

401.3 - Vulnerability Management and Response 56

 Today, the best way to manage the correlation of logs centrally is through the use of a SIEM.

SIEM aggregates, parses, normalizers, correlates logs for you

These technologies can aggregate all the logs in your environment if you want them to be managed on a
central log server. Then they will parse, normalize, and correlate them for you or enable you to correlate
the logs.

Assists you in finding emerging threats, either its security or resource related

The purpose is to assist you in finding current or emerging threats in the monitored environment, whether
they are security-related or resource-related, such as disks filling up

There are two primary approaches to data collection in SIEM solutions:

1. Agent-Based Data Collection:

SIEM solutions can use agents or log collectors deployed on endpoints, servers, network devices, and
other sources to collect logs and events directly from those sources.

These agents are software components installed on the target systems and are responsible for
capturing and forwarding logs to the SIEM platform for further processing.

Agent-based data collection provides real-time visibility into events occurring on individual systems
and allows for detailed monitoring and analysis of endpoint activity.

However, deploying and managing agents across a large number of systems can be resource-
intensive and may introduce overhead on the monitored systems.

2. Agentless Data Collection:

SIEM solutions can also collect data from various sources using agentless methods, such as network-
based protocols like syslog, NetFlow, SNMP (Simple Network Management Protocol), or API-based
integrations with third-party systems.

With agentless data collection, the SIEM platform collects logs and events directly from network
devices, servers, applications, and cloud services without requiring the installation of additional
software agents.

Agentless data collection can simplify deployment and reduce overhead on monitored systems since
it does not require software agents to be installed.

However, it may have limitations in terms of real-time visibility and detailed endpoint monitoring
compared to agent-based approaches
SIGMA

401.3 - Vulnerability Management and Response 57

 It’s an open-source project that provides generic language (‫ )لغة عامة‬for writing SIEM rules. It can be
converted manually or automatically into search expressions.

Write rules in Sigma format → convert them using sigma-cli

Effectively, it allows organizations to write rules in Sigma format and then convert them with a tool
powered by pySigma called sigma-cli (previously called sigmac).

Example on converting from Sigma format .yml → Elastic Search .json

sigma -t <target_format> <input_file.yml> <output_file.ext>

sigma -t elasticsearch sigma_rules.yml sigma_rules_es.json

Process of converting Sigma rules to work with SIEM using sigma-cli

1. Write rule in Sigma Format

2. Create a file mapping generic field names to field names within a given SIEM platform

3. Use sigma-cli to convert from Sigma format to a specific SIEM product rule format

Rules can become portable and can be shared. Has pre-written community rules which map to MITRE
techniques

The key advantage here is that rules can become portable and much more likely to be shared.

To that effect, the Sigma project has a rules folder that contains many pre written community rules that
also map to MITRE techniques and categories.

Docs — [Link]

Sigma main rule repo — [Link]

Sigma Format

title: Detect Suspicious PowerShell Command Execution

description: |
Detects suspicious PowerShell command execution with specific arguments.
author: John Doe
date: 2022/02/28
references:
- [Link]

logsource:
category: process_creation
product: windows
service: sysmon

# The detection section contains the actual detection criteria or conditions

401.3 - Vulnerability Management and Response 58

 # that must be met for the rule to trigger an alert
detection:
selection:
Image: '*\[Link]'
CommandLine: '* -encodedcommand *'
condition: selection and commandline
timeframe: 5m

falsepositives:
- Legitimate usage of PowerShell with encoded commands.
- Administrative or legitimate scripting activity.

# Severity
level: high
# Assigns tags related to MITRE ATT&CK knowledge base
tags:
- [Link]
- attack.t1086

In this example, the Sigma rule aims to identify potential instances of malicious PowerShell command
execution, particularly those involving the use of encoded commands.

The rule can help security analysts detect and investigate suspicious activities related to PowerShell usage,
which is commonly abused by attackers for various purposes such as lateral movement, execution of
malicious payloads, and obfuscation of commands.

Sharing Rules (Integrating MISP & Sigma)

Because Sigma rules are a generic format, they are perfect for sharing.

Projects such as MISP (Malware Information Sharing Platform & Threat Sharing) make this a simple task.

MISP is an open-source threat intelligence platform designed for collecting, sharing, and analyzing
threat intelligence information.

It allows organizations to collaborate on security-related events, indicators of compromise (IOCs),

malware samples, and other threat data in a structured and standardized manner.

MISP supports various types of threat intelligence, including indicators such as IP addresses, domain
names, hashes, and patterns of suspicious behavior.

The integration of Sigma rules with MISP allows organizations to leverage Sigma's detection logic to
enhance their threat intelligence capabilities within the MISP platform.

Now, organizations can create custom rules and share them openly with anyone, or strategically with specific
partners or industries.

Sigma rules introduces new problems

A rule that works in one environment may not work well in another.

Knowing Thyself — Some rules are intended to be applied based on knowing “Thyself”.

Rules should be reviewed — That’s why rules that are shared should go through a quality review.

401.3 - Vulnerability Management and Response 59

 Orchestration (‫)التنسيق‬

Process of automated quality review and orchestration for implementing shared rules

1. Pull shared rule from MISP.

2. Convert Sigma rule with sigmac to a SIEM-specific format.

3. Test rule outside alert engine by seeing if it would match on existing data.

4. If matches are found, move to a location for manual assessment and open a ticket. Otherwise, validate
performance and, if good, move alert into production.

Key Logging Activity

Real-Time Tasks

Here are few things that you need to do as a part of your log monitoring program

Malware outbreaks

It can be detected by an antivirus solution, but also from firewall and IDS logs.

It clearly require immediate action in the form of quarantine and cleaning.

Convincing and reliable intrusion evidence

It usually comes from a combination of logs, such as correlation from IDS/IPS and firewall logs.

Such events requires immediate response as well, such as a system shutdown or disconnect if possible.

Log deletion and corruption detection

It needs to happen ASAP because it’s an indicator of an intrusion or insider abuse.

Serious internal network abuse or policy violation

Such as access to illegal content from the systems owned by your company, will likely trigger an
immediate response because of massive legal liability concerns.

Web proxy logs will likely be the source of such info.

Loss of service on critical assets

Whether because of security problems, human errors, or software bugs, it also requires an immediate
response.

401.3 - Vulnerability Management and Response 60

 Server logs contain plenty of information on such potential problems.

Regulated data theft

It tops the charts for most organizations and requires immediate response due to double trouble of direct
loss and regulatory fines.

Daily Tasks

If you detect anything from this list, you’d probably want to initiate a response in a day or so.

Service disruption

Disruption in other less critical services, such as a failure of the secondary DNS server or other systems,
which will not immediately disrupt your business.

Suspicious login failures

Such as large number of access attempts from one source across one or many systems.

A response might be needed for such an event, especially if these events are followed by a successful
login message.

Running some kind of activity summary report across all logs everyday

Helps you to take a quick look at everything that happened in your environment.

Helps you improve your situational awareness.

Weekly Tasks

Review of all log trends (pattern or direction)

Review inside and perimeter log trends and activity by running a summary of events versus time.

Log events are analyzed over time to identify trends, including changes in event frequency, distribution,
or patterns.

Some useful summaries to look at:

401.3 - Vulnerability Management and Response 61

 System Failure Trend

Attacks Trend

Configuration Change Trend

User Access Trend

Host and network devices changes

Learn when/how the authorized changes happen to detect the unauthorized changes.

Routine account creation/removal

Looking for new accounts created without proper authorization, as well as old accounts NOT being
removed.

Monthly Tasks

Summary of minor policy violations

Such as network acceptable use policy (AUP)

It outlines the rules and guidelines that govern the appropriate use of an organization's network
infrastructure, systems, and resources by employees, contractors, and other authorized users.

The AUP defines acceptable and unacceptable behaviors related to network usage to ensure security,
reliability, and compliance with legal and regulatory requirements.

Inappropriate web browsing, such as non-work-related sites reflected in web proxy logs.

Reviewing firewall, web proxy, network IDS/IPS logs for such events can happen monthly.

Security technology performance measurement

For example, a report on successfully blocked attacks or other indications of successful attack blocking
or a report on denied connections from a firewall are examples of such monthly reports.

Quarterly Tasks

401.3 - Vulnerability Management and Response 62

 Annual Tasks

How Logs Help

Here we learn that even though logs help us to figure out who, where, when, how, what and more information
objectively (or at least we like to hope so), challenges to that might hide in all the seemingly innocuous places
(‫)الأماكن التي تبدو غير ضارة‬.

For example:

Logs tell us who did something, but is "who" a person or a system?

Is "where" spoofed? Is relying on logs for locating the perpetrator a bad idea? (It is!)

The question, "When?" brings up a long string of challenges. In what time zone? Is the time right?

Asking how something happened is often more akin to asking, "How do you think it happened?" which points
at beliefs and not facts.

Similarly, the log should tell us "What happened?" but really shows, "What got recorded [in logs]?"

Digital Forensics and Incident Response

Digital Forensics
A lot of companies worry about their systems getting compromised, but they don't have an in-action plan or a
strategy for incident handling and response, because it'll eventually happen.

What is Digital Forensics?

401.3 - Vulnerability Management and Response 63

 It's the scientific methodology all related to how we identify, collect, examine, and analyze in a way that
allows us to preserve data integrity and protect it.

It's the science of how we collect digital artifacts of evidence, or indicators of activity, in a system.

Who uses Forensic and IR Processes?

The Investigative Process

Being unbiased, remaining objective, following the evidence

In the investigation process, we don't want to be biased towards something, because this will limit our
thinking and might get us away from the real evidence.

401.3 - Vulnerability Management and Response 64

 Example: If a digital forensic examination shows that a user connected a

USB drive and opened a document on that drive, the evidence will show that activity.

If, on a different device, an examiner finds the same document but no evidence of a USB drive, they
cannot assume that the sources are the same.

Let your data drive your decisions, not the other way around.

Follow the grade school scientific method and don’t jump into conclusions

You collect the information, process it, even if the information will lead you to a conclusion that you
didn't foresee; because you shouldn't foresee any conclusion in any investigation.

Follow the Evidence

Imagine we are investigating user activity on a system. The following process is an example of how a
forensic analyst may walk through an investigation.

User Activity

Whenever a user performs activity on the system, such as browsing, connecting USB drives and so on, the
traces of that activity are left on the systems.

The trace evidence created is mostly done in the background, completely transparent from the user.

Creates Evidence

There are wide range of artifacts, but know that plugging in a USB drive may leave dozens of forensic
artifacts.

Forensic analysts are trained to understand which artifacts are created by a specific user event and how
these artifacts interact with each other to tell a story of what took place.

Recovered by Digital Forensics

Digital forensic analysts can recover many, if not all, of these artifacts and interpret them to define the
activity that took place.

Remaining Forensically Sound

401.3 - Vulnerability Management and Response 65

 It’s the process or methodology being used in forensic investigation maintains the integrity and reliability of
the evidence being collected or analyzed.

You collected the information the way it has to be collected, the collection was done in such a way that
there's integrity and reliability that:

You collected all the information

No information left behind

You didn't manipulate the information as it was being collected

Example: If I take a hard drive out of a computer and I want to do analysis, when I connect that hard drive to
my computer, I'll be destroying information if it's not done properly.

The moment I plugin that hard drive inside my computer, my OS will start to investigate that hard drive, will
start to be curious, what type of files are there? It'll start to index data, to make data more usable.

Write-blocker can be used

It's an actual interface that's configured in such a way that you can read but not write.

Chain of Custody (CoC) document — NIST

The CoC maintains the history of a piece of evidence, including the first person who acquired it, all the
way to the person who currently has it.

It may include a make, model, device's serial number, physical characteristics, size (preferably in
bytes), or key information.

The first investigator should record as much data as possible about an item to prevent future
confusion.

Subsequent evidence transfers (lab analysis), the following information about the item should be
recorded:

Date/time of transfer

How the item was transferred

Who was it transferred from

401.3 - Vulnerability Management and Response 66

 Who was it transferred to

Commands — Other important information that the analysts may include is the commands they typed.

Our methodology should be repeatable

That if someone followed the same steps we did, they would come to the same conclusion, because it's
a forensically sound and approved methodology.

Examples of Digital Forensic Artifacts

Artifacts fall into various categories but together can yield clear insight to a variety of activities on a system.

An example on other artifacts would be the NTFS filesystem’s timestamp:

Modified Time (M): The last time the file contents were modified

Access Time (A): The last time the file was accessed by a process

Metadata Change Time (C): The last time the file's metadata (permissions, filename, and so on) was
changed

Creation Time (B): The time the file was created

Examples of digital forensic artifacts: [Link]

There are always new artifacts which are discovered on almost a daily basis, because not everything was
documented.

Not everything that was engineered was ever written down.

Volatility of Information & Battle Against Time

At last, it's a battle against time

Not all artifacts are created equally, and how long will they survive before they're destroyed.

Volatility of Information — There are certain artifacts that degrade quickly (memory) on a computer, and
there are others that remain more persistently (hard drive). That's called the volatility of information.

401.3 - Vulnerability Management and Response 67

 Memory

The data which changes more frequently is the most volatile.

An example on that would be memory, where processes are created, destroyed, overwritten.

Memory contains a lot of valuable data as well like, encryption keys, passwords, process information.

That's an example on memory forensics.

Hard Drive

Files are not deleted completely — When you delete a file, the file doesn't get deleted from the hard drive
completely.

To delete a file is typically means that you cut the connector between a filename and the data storage
(the blocks).

You just cut the connector and erase the name, but the data still persists.

If you have a sufficiently large enough storage, and you never fill the entire storage, the artifacts will never be
overwritten.

Example: You have 15 TB hard drive, and you never use all 15 TBs over a 5-year period, you have never
deleted data from 5 years ago. It doesn't get overwritten until the storage is filled up or close to getting filled
up.

DFIR Subdisciplines (‫)تخصصات فرعية‬

Forensics may only focus on disk images, but in an incident, we need more than just focusing on one type of
artifact or analysis.

Incident response teams are often very diverse

Teams often have wide range of backgrounds and skills that cover all the DFIR subdisciplines.

Endpoint (disk-based and memory)

Network

Threat Intelligence

Reverse Engineering

Incident Handling
It’s an action plan for dealing with intrusions, cyber theft, denial of service, malicious code, fire, floods, and
other security-related events.

They can be intentional or unintentional.

It's not about IF or WHEN, it's about right now that the adversary is present, and we need to have a strategy
and a plan of action.

Sooner or later an incident is going to occur. It might not happen every day, but if it happens you’d want to have
a tested and clear strategy for acting upon the incident.

Being prepared to handle an incident and handle it correctly could be the difference between thriving and
disappearing.

One of the best ways to act on an incident and minimize your chance of making a mistake is by having well-
documented, proper procedures in place.

What Is an Incident? An Event?

401.3 - Vulnerability Management and Response 68

 💡 Incident – Harm or the potential for harm

Event — Any observable occurrence in a system and/or network

It’s important to understand that:

Any incident consists of a series of events

Not all events are considered incidents

Example: An unauthorized logon is considered an incident, whereas an authorized logon is not, yet both are
network events.

Some other examples of events include a system boot sequence, a system crash, or even packet flooding
within a network.

Six-Step Incident Handling Process (PICERL)

You’ll find the most steps circle back to preparation at last. That’s why we talked about the importance of
having a well-documented plan.

Common Problems
Poorly implementing best practices — In preparation, a large number of organizations fail at basic
security measures and poorly implement traditional best practices such as, principle of least privilege,
strong password, etc.

Threat Intelligence not employed — Also, many organizations do not employ threat intelligence as
effective as they could.

Limiting scope of compromise to infected machines only

While a victim organization may identify some of an incident, limiting their scope to the systems they
already know are compromised is a fatal mistake.

Instead, they should (at least) scan their enterprise for relevant indicators to identify other
compromised systems.

Trying to kill the attacker processes as fast as possible

This usually means that vital evidence may be lost making it more difficult to understand the incident.

Not fixing vulnerabilities

Failure to apply lessons learned

Not fixing the root cause — The most common problem that occurs during lessons learned is not
identifying an/or fixing the root cause.

Example: If a threat actor was able to guess a weak password, the question is, "Why was the
weak password allowed in the first place?" What needs to be fixed? Weak policy? Lack of
enforcement?

Incident response is not a linear (static) approach, it’s a dynamic one.

That’s because there are multiple events happening in the environment when an incident occurs, and it
differs from one incident to another.

401.3 - Vulnerability Management and Response 69

 Preparation
Knowing the organization asset inventory

Incident responders must know the organization and the prioritization of critical assets and systems.

Having a policy that covers organization’s approach

It’s important to have a policy in place that covers an organization’s approach when dealing with an
incident.

Notifying law enforcement officials?

One item is that a security policy needs to cover whether a company is going to notify law
enforcement officials or remain silent when an incident occurs.

The answer might depend on the severity of the incident.

Cleanup or watch and learn?

Another important item to consider is whether to contain the incident and move into cleanup
phases or to observe the attack in an attempt to gather more evidence, known as watch and learn.

Visibility into all network locations and systems is key for responding to incidents.

Have plans for rebuilding systems

Sometimes only cleaning the system is not safe for an organization you don’t know what the attacker
exactly did on all of the systems.

Often rebuilding systems may be the most cost-effective way to eradicate rootkits.

Leadership support to the incident handlers

You need to have leadership support as a lot of organizations don't have a dedicated IR team.

If you want to have a specific team member and you don't want to have a conflict with his manager,
because taking someone from another team will affect the business productivity as he's not doing his
job anymore.

Compensating people after an incident

Incidents are tiring and people get affect by it, not only the organizations but also the incident handlers
themselves.

Incidents might be very tiring an psychologically affects people. So, they need time to recover.

Identification, Detection, Verification & Triage

Signs of an incident — There are signs for an incident that we can identify like IDS alerts, unknown log
files, failed logon events, etc.

Correctly identifying an incident

Correctly identifying an incident can be the difference between cleaning up the problem in few
minutes and causing your organization’s network to be down for several hours or even days.

Any system outage could potentially cost your company a lot of money, so it is important to be able
to identify an incident correctly the first time and respond accordingly.

Verifying the incident, if it’s a real one or a false positive.

401.3 - Vulnerability Management and Response 70

 Incidents might be easy, or difficult

Sometimes it’s easy, such as a website defacement.

It might be difficult, requiring a full forensic examination.

Sending your best incident handler and volatility concerns

For example, you want to send your best incident handler has to go, because they have to be able to
execute commands to retrieve information, but they have to not execute too many commands;
because every interaction with the system is destroying evidence (creating processes, overwriting old
processes, destroying processes), the concept of volatility.

Containment

If you identified that there's an incident, you’re still left with the task of isolating and eliminating the source
of the incident.

💡 It’s about stopping the attacker’s control over the systems.

Goal is to stop the threat actor from continuing to operate in the environment

Such as lateral movement & persistence.

This requires having a proper scoping.

Determining the enormity of the scale and which systems were impact

You need to have an idea of the enormity of the scale, the number of systems, and which systems
were impacted.

Identify and isolate all impacted systems — We need to identify all the impacted systems,
because we need to be able to isolate them.

Clearly understand systems connections and configurations — Before isolation, you need to
have a clear understanding on the impacted system's connections and configurations in order to
revert them back to their state after the incident.

Isolating systems might mean that we need to disconnect systems, make them unavailable, which
impairs and impacts the business.

Examples on containment

Isolating a system

Patching systems

Removing attacker processes, accounts, etc.

Changing passwords

Applying filters to routers and/or firewalls

Impairment affects the business

401.3 - Vulnerability Management and Response 71

 This impairment cannot be for a long time because it might be the end of an organization.

That's why this process undergoes something like the person responsible for that decision in the
organization might need to sign a paper that they "accepts all risks that are going to occur from
the incident response".

Also circles back to preparation.

Eradication (Remediation)

Before the system goes back online, an incident handler must make sure they fix the problem or the
vulnerability (root cause) that the attacker used to compromise the system.

This phase involves thoroughly investigating the incident to understand how it occurred, what
vulnerabilities were exploited, and what actions need to be taken to prevent similar incidents in the
future.

💡 Containment is about stopping control, while eradication is about removing.

Rebuilding systems from scratch without identifying the root cause is a problem

There are a lot of cases where systems were taken offline, rebuilt, and put back on the network only to
be compromised again within minutes or hours.

Root cause analysis should be performed to determine why the incident happened in the first place.

Cleaning up the damage from an incident does nothing to prevent the problem from occurring
again unless the problem is accurately identified and removed, patched or otherwise mitigated.

Try to identify and fix the root cause

E.g. compromise due to weak passwords

Containment is changing the password

Eradication is finding and fixing the root cause is: Why was the password allowed? Weak policy?
Lack of enforcement?

Attackers ensure having remote access, monitor compromised systems closely

Attacks often try to have additional ways of ensuring remote access to a compromised system.

Backup access “backdoors” or “rootkits” — Even if the exploited vulnerability gets fixed, they might
have backup access methods such as “backdoors”.

Monitor the network, hosts and applications logs.

As an incident handler, you need to not only fix the vulnerability used during the initial system
compromise but also identify and remove every additional backdoor left by the attacker.

Vulnerability Assessment

It’s a good idea to run vulnerability assessment on the affected systems to see that the problem got
fixed and that no new holes were opened up during the eradication process.

401.3 - Vulnerability Management and Response 72

 Your goal as an incident handler is to make sure that a new compromise using the same, or even a
similar vulnerability doesn’t happen again.

Recovery
The recovery phase focuses on restoring affected systems, services, and data to normal operation
following a security incident.

Recovery efforts may include restoring data from backups, rebuilding compromised systems,
reinstalling software, and reconfiguring network settings.

Not reusing exploitable code/configurations/backups

Ensure you are not restoring vulnerable code or a vulnerable configuration that has already proven
itself to be exploitable by any number of attack methods.

If you restore a system from backup, then you could be restoring a previous state that contained the
vulnerability exploited by the attacker.

Vulnerable code might even refer to OS or software that hasn’t been patched.

Two options for restoring compromised systems:

New OS installation, adding latest patches, restoring data from backups

Installing the operating system (OS) and applications from scratch using the official and original
media, adding the latest OS and application software updates (fixing the vulnerability exploited
during the incident), and, finally, restoring the data from a backup.

Restoring from a trusted backup & patching the system

Restoring the system from a trusted backup and patching the system, at least fixing the
vulnerability involved in the incident.

The trusted backup already contains the latest system and application data available.

Monitoring eradication and recovery

You need to monitor that your eradication & recovery was successful, and that the adversary can't
come back into the systems.

Try to bring systems online during off-hours

It’s easier to monitor

At last it’s a business decision

Lessons Learned
A report drafted by the primary incident handler — A report outlining the entire process should be
drafted by the primary incident handler.

Identify most relevant conclusions that aid to avoid similar incidents — It is very important to summarize
the incident, identifying the most relevant conclusions obtained to aid in avoiding similar incidents in
the future.

Areas of improvement — The report should contain areas for improvement, both in the security
infrastructure and in the incident-handling process itself.

Scheduling a follow-up review

Right after an incident, there’s a lot of “momentum”, and the impact fades over time. So, we need to
schedule a follow-up review.

What has been implemented?

Has the organization been compromised again? The same compromise or a different one?

It may be after 30, 60, or 90 days or sometimes more.

Key Mistakes in Incident Handling

401.3 - Vulnerability Management and Response 73

 Taking Notes
The single most mistake that people do is forgetting to take notes in an investigation.

People eventually forget — No one can remember everything, and eventually some information will be
forgotten, so documenting everything is essential during the incident handling process.

Ensuring everything is captured and nothing is missed — Note-taking can even help to slow down an
investigator to ensure everything is accurately being captured and to ensure nothing is missed.

Allows others to see through the eyes of the incident handler — Note-taking allows others to see the
incident through the eyes of the handler.

Notes should be non-biased and based on facts — It is important that the steps captured, and the outcomes
reached be based on facts, staying clear of any bias or unprofessional qualities.

Things to Consider

Steps must be customized for your environment

The incident handling process needs to be customized by each organization to take into account the
various policies, network topologies, and other aspects of operation that might affect any of the phases
outlined.

Plan for the incident by making things simple with checklists and tested procedures.

Practice, practice, practice

There’s no dedicated team to IR, which means you need practice — Probably people that will perform an
incident are not in an IR team, which means they need to practice, at least weekly, on how they would
perform an IR if one is required.

Because they have their jobs, which means they won't be practicing IR enough. They should practice
using the tools, following the methodology, and so on.

401.3 - Vulnerability Management and Response 74

 Threat Hunting

Many organizations may have specific teams or request the existing teams to take on a form of a
proactive incident response, known as “threat hunting”.

Threat hunting is using knowledge of attacker activities and methodologies to search for historical,
previously unknown events within an organization.

401.3 - Vulnerability Management and Response 75