Y0uR SeCuiTy iS N0t En0Ugh

HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

 Y0uR SeCuiTy iS N0t En0Ugh
HaCkRhIn0-TeaM wE FrEE t0 FlY HaCkRhIn0-TeaM

HaCkRhIn0-TeaM /dēˈkript/ by HaCkRhIn0-TeaM HaCkRhIn0-TeaM

WEB
APPLICATION
EXPLOITATION
WEB ENGINEERING

Web applications provide an interface

between end users and the web servers
through a set of pages that are generated
at the server end. Though web applications
enforce certain security policies, but they
are vulnerable to various types of attacks
such as cross-site scripting, SQL Injection,
session hijacking, etc.
UNVALIDATED INPUT

 Unvalidated input: when the input from the client is not validated by the backend servers then the attacker
can inject any malicious script into the field and trick the website into doing something that it should not.
 It exploits a lack of boundary checkers

 Instead of [email protected], the attacker enter //////////

PARAMETER TAMPERING

 Manipulation of parameters exchanged

between client and server side to
modify applications such as user’s
credentials and permission, price of
products, etc.
 For example: price changes in hidden
HTML tags
CROSS-SITE SCRIPTING ATTACKS
 It allows the attacker to inject client-side scripts into web pages. It may be used to bypass access control.

Stores
Username: ABC Username: ABC
Password: 123 and
Password: 123 in
the database

Runs the malicious script directly

<script> malicious code </script>

DDOS ATTACK
 The attackers try to make the machine and network resources unavailable for the user.

Send so many
requests to the
website through
zombie PCs

Website application
SQL INJECTION
 Attackers try to control the database of your
web servers.
 Attackers executed SQL injection attacks from
the address bar and through queries and
searches
 COOKIE POISONING ATTACK

 Many web application uses cookies

to save user information such as
login, password, and emails.
Cookies positioning allows the
attacker to modify valid cookies &
gain the
authentication/authorization
information about another user
and go on to steal information.
ATTACKING METHODOLOGY
OWASP TOP 10 WEB APPLICATION VULNERABILITY
1. Broken access control
2. Cryptographic Failures
3. Injection
4. Insecure design
5. Security misconfiguration
6. Vulnerable and outdated components
7. Identification and authentication failures
8. Software and data integrity failures
9. Security logging and Monitoring Failures
10. Server-side request forgery
WEB APPLICATION TESTING TOOLS

• Static Testing
• FindBugs/findsecbugs
• SonarQube
• Yet Another Source Code Analyzer (YASCA)
• Dynamic Testing
• Interception Proxies (OWASP ZAP/Burp)
• Fuzzers (Peach/AFL)
• Debuggers (Immunity/GDB/OllyDbg/WinDBG/IDA)
THANK YOU
EXPLOITING HOST
VULNERABILITIES
LIFECYCLE OF ETHICAL HACKING

 Planning and scoping

 Information gathering

 Vulnerability scanning (Vulnerability Management & Vulnerability Analysis)

 Exploitation

 Maintaining access

 Clearing tracks

 Reporting and communication

 ATTACKING HOSTS

 OS- agnostic attack: exploit common weaknesses found across different systems. For example: using default account
settings or taking advantage of poorly configured permissions can work on various operating systems
 OS-specific attacks: target weaknesses that are specific to OS. For example: if there is a common feature or flaw present
in Windows, attackers might exploit it to gain unauthorized access.
 Password cracking: decode passwords to gain unauthorized access to a system or account
 Privilege escalation: exploiting vulnerabilities to elevate one’s privileges from a standard user to an administrator or root
level, granting them more control over the system.
 Kernel attacks: the kernel is the core part of an operating system that manages system resources and provides a bridge
between software applications and hardware components. Kernel attacks involve exploiting vulnerabilities in the kernel to
gain unauthorized access, manipulate system resources, or execute malicious code at a very low level, which can be harder
to detect and defend against.
 Physical access-based attack: These attacks involve gaining physical access to a computer or device, such as stealing a
laptop or gaining access to a server room. Once physical access is obtained, attackers can bypass many security measures
and directly manipulate the hardware or access sensitive information stored on the device.
INSECURE SERVICE MISCONFIGURATION
1. Services needing configuration: When you set up a service or software on your computer or
network, you often need to adjust its settings to fit your needs. If you don't configure it properly, it
might have default settings that are easy for attackers to exploit.
2. Misconfigurations and default credentials: Misconfigurations happen when you don't set up a
service correctly, leaving it vulnerable. Default credentials are usernames and passwords that
come pre-set with the service. If you don't change these default credentials, attackers can easily
guess them and gain access.
 For example, imagine you set up a new security camera system in your house. If you don't change
the default username and password (like "admin" and "1234"), someone could find this information
online and access your camera feed without your permission. This is an example of a
misconfiguration and using default credentials.
 OS AGNOSTIC ATTACKS AND FLAWS
1. Unsure file and folder permissions: When files and folders on your computer or network are not set up correctly, it
can create opportunities for attackers. For instance, if certain files are accessible to everyone when they shouldn't
be, attackers might be able to access sensitive information. Or if folders allow anyone to delete or modify files inside,
it could lead to data loss or manipulation. Attackers might exploit these weak permissions to gather information,
escalate their privileges (gain more control over the system), or support other types of attacks.
2. Hardware keyloggers vs. software keyloggers:
1. Hardware keyloggers: These are physical devices that can be plugged into a computer to record keystrokes.
They work regardless of the operating system because they intercept input directly from the keyboard before it
reaches the computer's software. For example, if an attacker plants a hardware keylogger between the
keyboard cable and the computer, it can capture all keystrokes, including passwords and sensitive information,
without needing to interact with the operating system.
2. Software keyloggers: These are programs installed on a computer that monitor and record keystrokes. Unlike
hardware keyloggers, they rely on the specific operating system they're installed on. For instance, a software
keylogger designed for Windows won't work on a Mac or Linux system. Software keyloggers can be installed
remotely or through malware, and they record keystrokes as users type, potentially capturing passwords, credit
card numbers, and other sensitive data.
LINUX ATTACK
1. Unsecure sudo attacks: On Linux systems, the "sudo" command allows regular users to perform
administrative tasks. But if an account has unrestricted or overly permissive sudo access, it's like
leaving the door wide open for attackers. They can exploit this to gain superuser privileges, essentially
giving them control over the entire system.
2. Ret2libc attacks: These attacks target a vulnerability called buffer overflow, where attackers input more
data than a program expects, overflowing into other parts of the computer's memory. Ret2libc attacks
specifically target the C library used by Linux systems. By exploiting buffer overflows, attackers can
manipulate the system to execute malicious code. However, modern security measures have made
these attacks less likely to succeed.
3. Sticky bits: Sticky bits are like extra security measures on Linux files or directories. When applied, they
prevent files or directories from being deleted by users who don't own them. It's similar to a "do not
touch" sign — even if someone has permission to access a file or directory, they can't delete it unless
they're the owner.
LINUX ATTACKS

 Linux attacks refer to various techniques and methods used by attackers to compromise,
manipulate, or exploit systems running the Linux operating system. Linux, being an open-source
and widely used operating system, is subject to security vulnerabilities and attacks just like any
other operating system.
 It is very important to understand the Linux exploitation.

 One of the flaws you find is regarding permission: there are some we learn special bit permission
which is user ID permission, group ID permission
LINUX ATTACK

 Analyze the sudo tool and its configuration file.

 In this case, I am typing ifconfig command, it does not give me the IP address configuration, but I mention the
full path and then able to see the IP address but as a regular user
 Now I want to check whether a regular user can use the sudo command to run any other administrative tools

 Sudo –l: this command will let you know how many tools the user can execute. In the following example, the
user can run all the commands as the root user using sudo
 If I have a user who can only be allowed to run bash commands, then I have to specify the path the user can
go
 This does not seem to be dangerous as it allows a regular user to open a terminal as an administrator
 Let’s see the company hire a new intern and we just want them to edit a file, some files require editing, and
only users with specified permissions and administrators can have that access
 If we give them access as usr/bin/vim: this is not dangerous either but what if we will give them access to the
shadow file
 /usr/bin/vim/etc/shadow, then they can edit the password, store a new password, update and delete it
LINUX ATTACK
 Let’s take a look at the user who has suid bit enabled, the first bit here is enabled which means that anyone
with this permission can execute /usr/bin/passwd. It could be executed as an owner of the file. Here, we are
allowing a user to execute the tool as a root
LINUX ATTACK

 Here permission is denied if a regular user tries to access the file which contains list of passwords

 They cannot able to see the content

LINUX ATTACK
LINUX ATTACK
WINDOWS ATTACK
1. cPassword in Windows Group Policy: In older versions of Windows, there was a setting called "cPassword" in Group
Policy. This setting could store passwords, which was a security risk because if someone got access to it, they could see
those passwords. Nowadays, in modern Windows versions, this isn't done by default because it's not secure. However, it's
still possible to enable this feature, which can be risky.
2. Cleartext credentials: Cleartext credentials are passwords or other sensitive information that is stored or transmitted without
encryption, meaning they can be easily read if intercepted. In Windows, cleartext credentials can be found in various places:
1. LDAP: LDAP (Lightweight Directory Access Protocol) is a protocol used for accessing and maintaining directory
services. In some configurations, Windows systems may store or transmit credentials in cleartext when using LDAP,
which can pose a security risk.
2. LSASS: LSASS (Local Security Authority Subsystem Service) is a core Windows process responsible for security-
related functions. Sometimes, Windows may store credentials in cleartext within the memory of the LSASS process,
which could be exploited by attackers.
3. Unattended installation files: When setting up Windows, administrators can create unattended installation files that
contain configuration settings, including usernames and passwords. If these files are not secured properly, the
credentials stored within them could be exposed.
WINDOWS ATTACK
1. Scan Active Directory for user accounts with service principal names (SPNs) set:
 Attackers search through the Active Directory to find user accounts that have service principal names (SPNs) associated with
them. SPNs are used by services running on a network to authenticate and communicate with other services.
2. Request service tickets using the SPNs:
 Once attackers identify accounts with SPNs, they request Kerberos service tickets for those service accounts. These tickets a re
encrypted and contain the hashed password of the service account.
3. Extract the service tickets from memory and save them to a file:
 After obtaining the service tickets, attackers extract them from the computer's memory where they are stored temporarily duri ng
the authentication process. They then save these tickets to a file for further analysis.
4. Conduct an offline brute-force attack against the passwords in the service tickets:
 Attackers use specialized tools to perform a brute-force attack on the hashed passwords extracted from the service tickets. By
trying different combinations of characters, they attempt to crack the passwords offline, without actively interacting with t he
network. Once a password is cracked, attackers gain unauthorized access to the associated service account.
CREDENTIAL ATTACKS

• Password cracking typically relies on methods that crack hashes.

• Most passwords are not stored reversibly (although some poorly engineered systems will store them in plaintext
or encrypted).
• Tools like Hashcat, Rainbow Crack, and John the Ripper focus on figuring out what the original value was by trying
to find a matching hash.
CREDENTIAL TESTING TOOLS
• Hashcat – A GPU-based cracking tool that is very fast at brute-forcing
• John the Ripper – A popular password-cracking tool
• Medusa, Hydra, and Patator – Three brute-force login testing tools
• CeWL – A wordlist creation tool
• Cain and Abel – An outdated password-cracking and penetration-testing tool
• Mimikatz – A very useful tool for capturing the Windows SAM and other Windows penetration testing tasks
• Dirbuster – A dated, but sometimes useful Java tool that brute-forces directories and filenames on web servers
• W3AF – The Web Application Attack and Audit Framework is an open-source application security scanner with
directory and filename brute-forcing capabilities.
PHYSICAL DEVICE ATTACK

1. They attempt to capture encryption keys from a running system by moving physical memory to another system
the attacker controls, where they can bypass system security to access the unencrypted keys.
2. By cold booting a system from an offline state, then using a removable drive to load an operating system that
the attacker controls, thus allowing the capture of encryption keys from physical memory.
3. JTAG debugging pins are an interface found on some hardware that provides very low-level access to firmware,
potentially allowing reverse engineering or the capture of encryption keys.
4. Serial consoles provide local direct login, typically without credentials, and as an administrative user.
MOBILE DEVICE ATTACK

 Attackers can break into your mobile phones and tablets

 They use tools like Drozer which is like a toolbox for testing the security of Android apps. It helps testers
find vulnerabilities or weaknesses in those apps.
 Drozer can do things like trying out known ways (exploits) to break into Android apps or devices. It's
like trying different keys to see if one will unlock the door.
 Another tool mentioned is APKX or APK Studio. These tools are used to take apart (decompile)
Android app files (APKs) and look at the code inside. It's kind of like taking apart a machine to see
how it works.
THANK YOU