Cyber Offence: Threats and Opportunities

Penetration Testing Execution Standard (PTES)

Penetration Testing

• Reporting
• Post-Exploitation
• Pre-Engagement
• Intelligence Gathering
• Threat Modeling
• Exploitation
• Vulnerability Analysis

Threat Modeling

• Structured risk assessment of a system's security.
• Identify assets, attackers, and vulnerabilities early in design.
• Diagram and analyze how data flows and where it's exposed.
• Output: prioritized list of threats with mitigations.

Why Threat Modeling Matters

• Proactive defense: Find design flaws before attackers do.
• Attacker's perspective: Reveals systemic weaknesses beyond code bugs.
• Improves collaboration: Developers, security, and ops share a common view of threats.
• Aligns with standards: Supports NIST 800-53 controls, OWASP guidance, etc.

Frameworks Overview

• STRIDE: Categorize threats by type (from Spoofing to Elevation of Privilege).
• DREAD: Rate threat severity (Damage, Reproducibility, Exploitability, Affected Users, Discoverability).
• PASTA: 7-stage risk-centric process mixing business & technical analysis.
• Trike: Risk management approach with an attacker–asset model.
• VAST: Visual, Agile, Simple Threat modeling for at-scale DevOps integration.

STRIDE Framework

• Threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
• Approach: Use system model (e.g., DFD) and ask "What threats in each STRIDE category could occur here?"
• Output: List of threats per component, e.g., "Spoofing threat at login interface"
• Usage: Part of Microsoft SDL; requires detailed architecture diagrams.

DREAD Risk Assessment

• Acronym: Damage, Reproducibility, Exploitability, Affected Users, Discoverability.
• Scoring: Each factor scored 0-10; average yields overall threat risk.
• Example: High damage + easy reproducibility + easy exploit = High risk threat.
• Usage: Prioritize threats after identification (often used alongside STRIDE).
• Caution: Subjective ratings; Microsoft dropped DREAD due to inconsistency.

PASTA Framework (Risk-Centric)

• P.A.S.T.A.: Process for Attack Simulation and Threat Analysis
• Stages (7):
  • Define Objectives
  • Define Technical Scope
  • Application Decomposition
  • Threat Analysis
  • Vulnerability Analysis
  • Attack Modeling
  • Risk/Impact Analysis
• Attacker-centric: Analyze threats from an attacker's point of view; simulate attacks in Stage 6.
• Business alignment: Ties threats to business impact and compliance requirements.
• Output: Prioritized threat enumerations with risk scores and countermeasures.

Trike Framework (Risk-Based)

• Origin: Developed circa 2005 as an open-source security auditing framework.
• Focus: Risk management perspective – define acceptable risk levels and identify threats that exceed them.
• Method: Model the system with actors, assets, actions, and rules; create an actor-asset matrix.
• Threat identification: Determine how each actor could violate intended actions (e.g., CRUD – Create, Read, Update, Delete – abuses)
• Risk scoring: Assign likelihood levels to actions and attacker profiles; calculate risk on a 5-point scale (lower number = higher risk in Trike's scheme).
• Status: Trike v1 had documentation, but v2 is not well-maintained (limited tooling/docs).

VAST Methodology

• VAST = Visual, Agile, Simple Threat modeling
• Created by: Anurag “Archie” Agarwal (ThreatModeler tool)
• Two model types:
  • Application Threat Models (process-flow diagrams for app architecture)
  • Operational Threat Models (infrastructure / cloud attack surfaces)
• Integration: Designed to plug into Agile/DevOps workflows – threat modeling on the fly with development cycles.
• Scalability: Supports large enterprise with broad team participation (developers, even non-security staff).
• Automation: Often implemented via tooling (ThreatModeler platform) with a library of threats and auto-generation of threat reports.

Comparing the Frameworks

• Scope & Depth
  • STRIDE: Focused at design level, broad threat coverage, but can yield long lists.
  • DREAD: Risk rating addon – simple scoring, but subjective.
  • PASTA: Full-stack process (strategic to technical), very thorough, best for high-risk, complex systems.
  • Trike: Formal risk audit style, ensures policy compliance, but not widely supported (niche usage).
  • VAST: Agile integration, scales enterprise-wide, relies on tooling and known threat patterns.
• Attacker vs Defender Use
  • STRIDE/PASTA: Useful for both – attackers can map potential weaknesses, defenders use to design mitigations.
  • DREAD: Mainly a defender's tool for prioritization (attackers don't need to "score" their attacks formally).
  • Trike: Defender-focused (auditing to meet acceptable risk). Attackers could invert it to find policy gaps.
  • VAST: Defender tool to automate threat discovery; for attackers, output might reveal what the org is aware of.

Comparing the Frameworks: Ease of Use

• STRIDE: Moderate learning curve; requires understanding of system architecture.
• DREAD: Easy to grasp, quick to apply, but needs consistency.
• PASTA: Steep learning curve (7 stages, many stakeholders) – requires training and effort, but yields rich results.
• Trike: Complex initial setup (detailed modeling of actors/assets); not beginner-friendly.
• VAST: Easiest for non-experts (tool-guided), minimal training – but you need the tool support.

Case Study: Bybit Crypto Exchange Hack (2025-Feb!)

• The Breach: Attackers stole ~$1.5 billion in crypto by compromising multi-sig wallet procedures.
• What Went Wrong: Focus on code security missed operational threats – attackers phished device credentials of signing officers and manipulated transactions.
• Threat Modeling Analysis: A thorough threat model would have flagged:
  • Threat actor: Sophisticated APT targeting key personnel (not just generic hacker)
  • Threat scenario: Compromise of signer's laptop (crossing a trust boundary between secure signing device and network)
  • Controls gap: Lack of out-of-band verification or monitoring on large transfers
• Lesson: Model the whole system, including human and process elements. Use frameworks (like PASTA) to incorporate operational security in threat scenarios, not just software flaws.

Key Takeaways

• Threat modeling = think like an attacker, act like an engineer. It bridges offense and defense, letting us anticipate attacks in a structured way.
• Choose the right framework: No single method fits all. Use simple methods (STRIDE) for quick wins; rigorous methods (PASTA) for critical systems; automated methods (VAST) for scale. Combine as needed.
• Don't ignore people and processes: Include social engineering, insider threats, supply chain, and other non-code attacks in your models. Attackers will find the weakest link, so model the entire system.
• Practice, practice: The more you threat model real systems (and analyze real incidents), the faster and more intuitively you'll uncover threats. Make it a continuous part of development (and your attack planning!).
• For cyber offense professionals: Use threat modeling to map target attack surfaces systematically, identify multiple paths (attack trees), and prioritize the most effective exploits. It's a way to organize and justify your hacking strategy with the same thoroughness defenders use to protect.

The Importance of Vulnerability Analysis

• Proactive Threat Mitigation – Identify security flaws before attackers do
• Compliance & Security Standards – Organizations must meet NIST 800-115, OWASP, and ISO 27001 requirements
• Cost of an Exploit – Unpatched vulnerabilities cost companies millions (e.g., Equifax Data Breach - $1.4 billion in damages due to an unpatched vulnerability)

Vulnerability Analysis

• Vulnerability testing is the process of discovering flaws in systems and applications which can be leveraged by an attacker.

Vulnerability Identification

Analysis

• source and cause
• scanners - and their integrated databases

Risk Assessment

• Assign each vulnerability a severity score
• Vulnerabilities are ranked based on a variety of factors, including:
  • The systems affected
  • The information put at risk
  • Ease of attack or compromise
  • Potential infrastructure and organizational damage

Remediation

• Severity
• Vulnerability Exposure

Vulnerability Analysis Types

• Active vs. Passive
• Manual vs. Automated

Vulnerability Analysis Types

• Manual scanning
• Automated Scanning

Automated Vulnerability Scanning

• Strengths of Automated Scanning:
  • Efficient for large-scale assessments
  • Uses vulnerability databases (CVE, NVD, OSVDB)
  • Can detect misconfigurations & outdated software
• Limitations:
  • False Positives – Scanners report potential issues that require human verification
  • Limited Context – Cannot detect business logic flaws or zero-day vulnerabilities

Manual Techniques – Fuzzing & Exploit Development

• Fuzzing – Injecting random/malformed inputs into an application to trigger unexpected behavior.
• Exploit Development – Writing custom PoC scripts to confirm vulnerability impact.
• Fuzzing Techniques:
  • Black-Box Fuzzing – No prior knowledge of the system
  • White-Box Fuzzing – Full code access for deeper analysis
  • Mutation-Based Fuzzing – Altering existing test cases to create unexpected inputs
• Why is Manual Testing Important?
  • Finds zero-day vulnerabilities that scanners cannot detect
  • Provides real exploitability insights through PoC development

Types of Vulnerability Assessments

• Host Assessment: Scans critical servers, workstations and other network hosts.
• Wireless Assessment: Focuses on the security of an organization's Wi-Fi network.
• Network Assessment: Identifies vulnerabilities in public and private networks.
• Database Assessment: Looks for weaknesses in an organization's database.
• Application Assessment: Searches web applications, websites and source code.

Vulnerability Assessment Tools

• Web application scanners
• Protocol scanners
• Network scanners
• External and internal vulnerability scanners
• Environmental scanners

Case Study – Log4Shell (CVE-2021-44228)

• Vulnerability: Untrusted data in logs triggers JNDI lookup, leading to remote code execution.
• Exploit: Attackers inject ${jndi:ldap://…}$ into logs, forcing Log4j to load and execute malicious code.
• Impact:
  • Affected millions of Java applications
  • CVSS Score: 10.0 (Critical)
  • Enabled full remote control of servers

Case Study – Heartbleed (2014)

• Vulnerability: OpenSSL buffer over-read in TLS heartbeat extension.
• Exploit: Extracting server memory, including passwords & private keys.
• Impact: Millions of web servers vulnerable.

Case Study – EternalBlue (2017) & WannaCry

• Vulnerability: SMBv1 buffer overflow (CVE-2017-0144).
• Exploit: "EternalBlue" tool enables remote code execution.
• Impact: Used in WannaCry ransomware, affecting hospitals, businesses globally.

Takeaways

• Combine Automated & Manual
• Continuous Vulnerability Management
• Incident Learnings

Modern Browser Architecture (Multi-process Model)

• Renderer Process (tab contents, JS engine)
• Browser Process (UI, IPC broker)
• GPU Process
• Utility Processes
• Sandboxing boundaries

Which process controls what?

• Browser: Controls "chrome" part of the application including address bar, bookmarks, back and forward buttons. Also handles the invisible, privileged parts of a web browser such as network requests and file access.
• Renderer: Controls anything inside of the tab where a website is displayed.
• Plugin: Controls any plugins used by the website, for example, flash.
• GPU: Handles GPU tasks in isolation from other processes. It is separated into different process because GPUs handles requests from multiple apps and draw them in the same surface.

The Browser as an Attack Surface

• Parses untrusted input (HTML, JS, images, fonts)
• Accesses hardware, files, network, camera, etc.
• Used by billions → huge value to attackers
• Ideal for: espionage, surveillance, and persistence

Who Attacks Browsers and Why?

• Red Teams: Gaining internal access via phishing or drive-bys
• APTs/Spyware Vendors: Targeting activists, journalists
• Bug Hunters: High-reward exploit dev
• Pwn2Own Participants: Pushing technical boundaries

What Makes Browsers Vulnerable?

• Handle complex data from the internet
• Interpret HTML, JavaScript, CSS, images, fonts
• Run complex JavaScript engines (like V8)
• Features → Complexity → Bugs → Exploits

Anatomy of a Modern Exploit Chain

• The steps an attacker takes to compromise a system by exploiting vulnerabilities in a browser and other components.

High-Level Browser Exploitation Flow

• Trigger a bug (memory or logic)
• Gain memory control (read/write)
• Execute shellcode or ROP/JOP
• Escape the sandbox
• Achieve OS-level compromise or persist

Real Attack Example – CVE-2021-30551 (Chrome V8 Bug)

• What happened? A bug in Chrome’s V8 JavaScript engine
• What did it do? Let attackers run code remotely
• Who used it? State-sponsored attackers
• Was it fixed? Yes, but after it was exploited in the wild

V8 Engine – Internals That Matter to Attackers

• Ignition: V8's baseline JS interpreter
• TurboFan: Optimizing JIT compiler
• Inline Caches (ICs): Accelerate property access
• Hidden Classes: Track object layout

Type Confusion – A Critical Exploitation Primitive

• Happens when:
  • Engine expects one type, but gets another
• Common setup:
  • Array of floats → tricked into storing objects
• Outcome:
  • Can read/write outside of expected memory bounds

WebAssembly – Exploiter’s New Playground

• What is it?
  • A binary format for near-native speed
• Why use it?
  • Predictable memory layout (linear memory)
  • Can hold shellcode RWX memory allocation
• Helps bypass:
  • JS analysis tools
  • JIT (Just-In-Time compiler) restrictions

Real-World Exploits – Techniques from Pwn2Own

• Attackers often begin in the JS engine
• Common steps:
  • Heap grooming
  • Trigger memory corruption (e.g., UAF, OOB)
  • Build R/W primitive
  • Escape sandbox
  • Full chain → OS compromise

Common Terms

• JS = JavaScript
• UAF = Use-After-Free (accessing memory after it's freed)
• OOB = Out-of-Bounds (accessing memory beyond allowed range)
• R/W = Read/Write primitive

Fuzzing – How Bugs Are Discovered at Scale

• libFuzzer (coverage-guided)
• ClusterFuzz (at Google scale)
• Fuzzilli (fuzzing JS engines)

Terms

• Fuzzer = Tool that feeds random/mutated input to find crashes
• libFuzzer = In-process fuzzing engine
• Fuzzilli = JS-specific fuzzer designed to trigger JIT bugs

Who Gets Targeted, and How?

• High-value targets:
  • Journalists, NGOs, Gov networks
• Attack vectors:
  • Drive-by downloads
  • Malicious links
  • Zero-click iMessage or browser delivery
• Common goal: Surveillance, data exfiltration, persistence

Terms

• Zero-click = Exploit runs without user interaction
• APT = Advanced Persistent Threat (state-backed attacker)

What are common browsers vulnerabilities?

• Cross-Site Scripting
• Code Execution Exploits in the Browser
• Code Execution Exploits in Plug-ins
• Man-in-the-Middle Attacks
• SQL Injection
• DNS Poisoning

What is cross-site scripting?

• An attack where malicious scripts are injected into otherwise benign and trusted websites

What is client-side code?

• Client-side code is JavaScript code that runs on a user’s machine. In terms of websites, client-side code is typically code that is executed by the web browser after the browser loads a web page.

How can an attacker use cross-site scripting to cause harm?

• A typical cross-site scripting attack flow is as follows:
  1. The victim loads a webpage and the malicious code copies the user’s cookies
  2. The code then sends an HTTP request to an attacker’s webserver with the stolen cookies in the body of the request.
  3. The attacker can then use those cookies to impersonate the user on that website for the purpose of a social engineering attack or even to access bank account numbers or other sensitive data.

What are the different types of cross-site scripting?

• Reflected cross-site scripting
• Persistent cross-site scripting

How to prevent cross-site scripting

• If possible, avoiding HTML in inputs
• Validating inputs
• Sanitizing data
• Taking cookie security measures
• Setting Web Application Firewall (WAF) rules

Key MitM Terms

• SSL (Secure Sockets Layer): Older, now-deprecated cryptographic protocol.
• TLS (Transport Layer Security): Current standard for secure web communications.
• SSL Stripping: Attack method removing SSL protection to force insecure connections.
• DNS Spoofing: Falsifying DNS responses to redirect users to malicious sites.
• Session Hijacking: Stealing browser session identifiers to impersonate users.

What is a Man-in-the-Middle Attack?

• Active/ Passive
• MitM is an attack where an adversary secretly intercepts and possibly alters communications between two parties without either knowing.
• Goal: Eavesdropping, data theft, or manipulating information.
• Common targets: Web browsers, applications, network traffic.

Browser Communication and MitM Vulnerabilities

• Browser relies heavily on HTTP/HTTPS protocols.
• HTTP:
  • Plain text, highly vulnerable to interception.
• HTTPS:
  • Encrypts traffic with TLS.
  • Still vulnerable if poorly configured or compromised (SSL stripping, TLS downgrade).

Real-world Scenario: Public Wi-Fi Networks

• Example scenario: MitM attacks on public Wi-Fi hotspots.
• Attack methods:
  • Rogue Access Points.
  • Fake login pages.
  • SSL stripping techniques.

Impact and Consequences of MitM

• Data theft (credentials, banking info, personal data).
• Injection of malware and ransomware.
• Loss of privacy and trust.
• Regulatory, financial, and reputational damages.

Protocols and Browser Communication Security

• Browsers depend on HTTP and HTTPS for communication.
• Secure communication prevents interception and tampering.
• Insecure protocols make browsers vulnerable to MitM attacks.

HTTP vs HTTPS

SSL/TLS Protocol Basics

• SSL (Secure Sockets Layer): Older protocol (deprecated).
• TLS (Transport Layer Security): Modern standard for secure communication.
• TLS Handshake:
  • Key exchange
  • Session key creation
  • Secure session established

Common Vulnerabilities in Browser Protocols

• SSL Stripping Attacks
• TLS Downgrade Attacks (e.g., POODLE attack)
• Expired or fraudulent certificates
• Lack of HSTS (HTTP Strict Transport Security)

Real-World Attack Example: SSL Stripping

• Introduced by Moxie Marlinspike (2009).
• Forces browsers to use HTTP even if HTTPS is available.
• Intercepts sensitive data like login credentials.

Importance of HSTS

• HTTP Strict Transport Security (HSTS) enforces HTTPS connections.
• Protects against SSL stripping attacks.
• Preload lists in browsers improve security.

Techniques of Browser-based MitM Attacks

• SSL Stripping Attacks
• DNS Spoofing and Cache Poisoning
• Session Hijacking via Cookies
• Common Goal: Intercept or manipulate browser communication

Techniques of Browser-based MitM Attacks: SSL Stripping Attack

• Forces downgrade from HTTPS to HTTP.
• Intercepts and modifies links invisibly.
• Tools: SSLstrip, Bettercap.

Techniques of Browser-based MitM Attacks: DNS Spoofing and Cache Poisoning

• Attacker fakes DNS responses.
• Redirects browsers to malicious servers.
• Can persist by poisoning DNS cache.

Techniques of Browser-based MitM Attacks: DNS Rebinding Attack

• Bypasses browser same-origin policies.
• Allows malicious scripts to interact with internal services.

Techniques of Browser-based MitM Attacks: Session Hijacking via Cookie Theft

• Captures browser session cookies.
• Replays cookies to impersonate users.
• Tools: Wireshark, Bettercap.

Advanced Browser-based MitM Attack Techniques

• HTTP/2 and HTTP/3 vulnerabilities
• Exploiting browser plugins via MitM
• Browser fingerprinting attacks
• Targeted phishing using MitM data

Advanced Browser-based MitM Attack Techniques: Exploiting HTTP/2 and HTTP/3 Protocols

• HTTP/2 Multiplexing Vulnerabilities:
  • Request queueing manipulation.
• HTTP/3 (QUIC) Packet Injection Risks.
• New attack surface for MitM in modern browsers.

Advanced Browser-based MitM Attack Techniques: Browser Plugin Exploitation via MitM

• Intercepting plugin updates over insecure channels.
• Injecting malicious payloads via plugin vulnerabilities.
• Case: Outdated Flash, Java plugins historically vulnerable.

Advanced Browser-based MitM Attack Techniques: Browser Fingerprinting in MitM Context

• Collecting unique browser/device data during MitM.
• Enhancing user tracking without cookies.
• Used in advanced phishing and surveillance campaigns.

Advanced Browser-based MitM Attack Techniques: Targeted Phishing Using MitM Data

• Intercepted data improves phishing realism.
• Personalized phishing campaigns based on browser behavior.
• Harder to detect than traditional phishing.

Detecting Browser-based MitM Attacks

• MitM attacks can be invisible to users.
• Early detection reduces damage.
• Browsers, network tools, and user awareness all play roles.

Browser Warning Signs

• SSL/TLS certificate errors.
• Unexpected redirects to HTTP pages.
• Missing padlock or security icons.
• Pop-ups asking to "trust" unknown certificates.

Network Detection Methods

• Monitor for unexpected DNS changes.
• Analyze SSL/TLS handshake failures.
• Detect abnormal certificate issuers.
• Use IDS/IPS systems with MitM detection rules.

SQL Injection

• Injection as “code as data” vulnerability
• Persistent prevalence despite decades of study
• OWASP Top 10 ranking (#3- this all types of injection though)
• Impact: data exfiltration, full system compromise

Anatomy of a Database Query

• Client → Web application → Database sequence
• Injection vectors: URL parameters, form fields, headers
• Unsafe string concatenation vs. parameter binding
• Role of the DB driver or ORM layer

Types of SQL Injection

• In-Band Error-Based
• In-Band Union-Based
• Inferential (Blind SQLi)
• Out-of-Band

In-Band SQLi – Error-Based

• Leverages database error messages to reveal schema details
• Common payload: ' AND 1=CONVERT(int,@@version)--
• Requires verbose error output enabled in app

In-Band SQLi – UNION-Based

• Uses UNION SELECT to append attacker-controlled result sets
• Must match original query’s column count and data types
• Example: … UNION SELECT username, password FROM users--

Blind SQLi – Boolean-Based

• Infers true/false responses via page behavior changes
• Payloads like AND SUBSTRING(password,1,1)='a'
• Extracts data one character at a time

Blind SQLi – Time-Based

• Uses functions like SLEEP() (MySQL) or WAITFOR DELAY (MSSQL)
• Payload: IF(LENGTH(password)>5,SLEEP(5),0)
• Measures response latency to glean data

Out-of-Band (OOB) SQL Injection

• Exfiltrates data via DNS or HTTP callbacks
• Uses functions like xpdirtree or LOADFILE()
• Effective when in-band and blind methods fail

Other Types of SQL Injection

• Second-Order SQL Injection
• Malicious input stored safely, executed in later query context
• Common in multi-page or multi-step workflows
• Filters applied at entry point can be bypassed

Bypassing Input Filters

• Comment obfuscation: UN/**/ION
• Encoding payloads: URL-encoding (%27), Unicode escapes (\u0027)
• Case-insensitive matching and whitespace tricks

Advanced Injection Vectors

• Stored procedures & custom functions
• JSON/XML query endpoints (e.g., OPENJSON)
• GraphQL and NoSQL injection parallels
• Impact on microservices and APIs

Case Study – CVE-2013-3900 (ColdFusion)

• SOAP web service exposed unsanitized parameters
• Attackers exfiltrated entire user tables

Case Study – CVE-2014-3704 (“Drupalgeddon”)

• Flaw in Drupal’s Form API allowed arbitrary SQL
• Automated exploits scanned the internet for vulnerable sites
• Led to mass defacements and data leaks

Detection Techniques: SQL Injection

• Audit database logs for anomalous statements
• Web logs: regex alerts on keywords (UNION, --, OR '1'='1')
• Runtime monitoring and anomaly scoring

Defense SQLi

• Parameterized Queries
• ORM & Query Builders
• Runtime Application Self-Protection (RASP)
• Web Application Firewalls (WAF)

DNS Security

• DNS as the Internet’s “phone book” for name→IP resolution
• Criticality: underpins virtually all TCP/IP services
• Threats range from phishing redirects to nation-state surveillance
• Strategic importance: availability, integrity, confidentiality

Terms

• DNS: Domain Name System
• TCP/IP: Transmission Control Protocol/Internet Protocol

DNS Architecture & Message Format

• Hierarchical zones: root, TLD, authoritative, recursive resolvers
• Message sections: Header, Question, Answer, Authority, Additional (RFC 1035)
• Transport: UDP (primary) and TCP fallback on port 53
• Transaction ID (16 bits) and flags in DNS header

Terms

• TLD: Top-Level Domain
• RFC: Request for Comments
• UDP: User Datagram Protocol
• TCP: Transmission Control Protocol
• TXID: Transaction Identifier

DNS Resolution Process

• Recursive resolver asks root → TLD → authoritative servers
• Iterative vs. recursive queries—who caches what
• Caching levels: stub resolver, ISP resolver, enterprise DNS
• TTL (Time-To-Live) governs cache lifetime

DNS Cache Poisoning Overview

• Definition: injecting forged records into a resolver’s cache
• Goal: redirect victim’s queries to attacker-controlled IPs
• Exploits the window between query and legitimate reply
• Impacts: widespread victim redirection until TTL expires

DNS Spoofing vs. Cache Poisoning

• Spoofing: targeting individual hosts (e.g., ARP spoofing + rogue DNS)
• Cache poisoning: corrupting an entire resolver’s cache
• Spoofing requires network-level access; poisoning exploits protocol flaws
• Both achieve name-resolution hijack

Historical Context – Early BIND Flaws

• 1997: BIND’s (Berkeley Internet Name Domain) lack of Transaction ID randomization (CVE-1997-0880)
• Simple offset incrementing made guessing trivial
• Patch cycle led to early defenses on ID fields BIND remains a reference implementation

The 2008 Kaminsky Attack

• Dan Kaminsky’s breakthrough: mass querying to force many TXID guesses
• Exploited lack of source port randomization in BIND
• Demonstrated ability to poison .com nameservers in minutes
• Catalyst for modern DNS hardening (Black Hat USA 2008)

Source Port & TXID Randomization

• RFC 5452: “Preventing Use of Known-Answer Queries”
• 32-bit entropy: 16-bit TXID + 16-bit source port
• Dramatically raises guesswork to ~4 billion combinations
• Adopted by BIND, Unbound, Microsoft DNS, etc.

DNS Response Race Conditions

• Attacker floods spoofed responses before genuine reply
• Resolver accepts first valid-looking packet matching ID & port
• Network latency and jitter influence success window
• Mitigation: increase validation checks, reduce acceptance windows

DNSSEC Fundamentals

• Adds digital signatures to DNS records (RRSIG, DNSKEY, DS)
• Establishes chain of trust from root down to leaf (RFC 4033, 4034)
• Prevents tampering: resolver verifies signature before caching
• Adoption: ICANN root signed 2010; variable TLD adoption

DNSSEC Deployment Challenges

• Key management complexity and rollover risks
• Zone signing increases response sizes (UDP truncation → TCP fallback)
• NSEC vs. NSEC3 for authenticated denial of existence
• Resolver performance and caching considerations

Terms

• NSEC / NSEC3: Next SECure / Next SECure version 3

DNS over TLS (DoT) & HTTPS (DoH)

• RFC 7858: DNS over TLS on port 853
• RFC 8484: DNS over HTTPS with HTTP/2 or HTTP/3
• Encrypts queries/responses to prevent on-path tampering
• Debates on centralization vs. privacy

Case Study – Operation Tempura (Iran, 2018)

• Sophisticated DNS poisoning against Iranian government domains in early 2017–2019
• Attackers manipulated both public and private recursive resolvers to poison caches
• Users of sites like health.ir and education.gov.ir were redirected to malicious replicas

Monitoring & Detection (DNS Attacks)

• DNS analytics tools: dnscap, Bro/Zeek for passive DNS logs
• SIEM integration: alert on sudden TTL anomalies or unexpected authorities
• Monitor for high query failure rates or repeated ID mismatches
• Use RPZ (Response Policy Zones) to block known bad IPs

Terms

• SIEM: Security Information and Event Management
• RPZ: Response Policy Zone
• TTL: Time To Live
• NXDOMAIN: Non-Existent Domain

Mitigation Best Practices (DNS)

• Enforce DNSSEC validation on all resolvers
• Use source port/TXID randomization (RFC 5452)
• Deploy DoT/DoH for stub-to-resolver encryption
• Segregate recursive and authoritative infrastructure

Terms

• VLAN: Virtual Local Area Network
• DMZ: Demilitarized Zone
• Ansible/Puppet: Configuration management systems
• DoT: DNS over TLS
• DoH: DNS over HTTPS

Post-Exploitation

• Why Post-Exploitation Matters?

Why Post-Exploitation Matters?

• Global median dwell time is 10 days from compromise to detection, underscoring how much an adversary can accomplish in the post-exploit window.
• 68 % of breaches involve a human element—emphasizing that once inside, people-driven actions (errors or social engineering) play a critical role in breach outcomes. –Verizon
• Attackers leverage this window to escalate privileges, move laterally, and exfiltrate data, mapping directly to MITRE ATT&CK® post-exploitation TTPs¹.

Terms

• TTPs: Tactics, Techniques & Procedures

Establishing Persistence

• Techniques: scheduled tasks, services, registry run keys, login scripts

Example CVE (conceptual)

• CVE-2021-4034 “