osi-layer-pentest

name

osi-layer-pentest

description

Use when planning, structuring, documenting, or reviewing a penetration test through an OSI-layer lens. Applies when the user wants layer-based attack-surface mapping, wants findings or engagement notes organized by Physical/Data Link/Network/Transport/Session/Presentation/Application, wants to see which layers were actually tested on a target, or wants cross-layer findings explained without flattening them into generic app issues.

Osi Layer Pentest

Use the OSI model as an analytical scaffold for pentest planning, evidence organization, attack-path explanation, and remediation ownership.

Core rules

• Treat the OSI model as a thinking and documentation aid, not as a claim that products cleanly implement seven separate layers.
• Prefer validating lower-layer trust assumptions before spending heavily on upper-layer exploitability when the target and ROE allow it.
• Preserve Session and Presentation analysis explicitly when they materially exist, even if the implementation folds them into transport or application behavior.
• Do not force every finding into exactly one layer. Use:
  • primary layer
  • supporting/dependent layers
• Use layered framing to avoid misattribution. A routable admin panel is not only an application issue if segmentation and service exposure also failed.

Layer map defaults

Layer 1, Physical

Track adjacency and real-world access preconditions.

Typical scope:

• exposed ports, removable media, local keyboard/mouse/console access
• rogue-device placement opportunities
• boot interruption, kiosk escape via local input
• locked-room, cabinet, cable, and device-access assumptions

Layer 2, Data Link

Track same-segment trust and local broadcast-domain abuse.

Typical scope:

• ARP, MAC, VLAN, Wi-Fi, NAC edge trust
• local MITM opportunity
• rogue AP or switching-path abuse

Layer 3, Network

Track paths, segmentation, and routing trust.

Typical scope:

• reachability, ACLs, routing, firewall pathing
• inter-network trust and exposure
• control-plane or path-validation issues

Layer 4, Transport

Track TCP/UDP exposure and state behavior.

Typical scope:

• port exposure
• handshake and timeout behavior
• rate limiting, backlog, state exhaustion, UDP reachability

Layer 5, Session

Track authentication-bearing state machines and relay/fallback conditions.

Typical scope:

• SMB/RDP/RPC session setup
• Kerberos/NTLM negotiation, signing, relay, fixation, fallback
• session integrity and re-authentication weaknesses

Layer 6, Presentation

Track secure representation and transformation boundaries.

Typical scope:

• TLS versions/ciphers/certificates
• encoding, compression, serialization/deserialization
• data-format trust boundaries

Layer 7, Application

Track business logic and user-visible service abuse.

Typical scope:

• authn/authz, APIs, uploads, SSRF, injection, logic flaws
• runtime debug exposure
• unsafe app behaviors and direct feature abuse

Workflow

1. Confirm ROE and scope first.
2. Inventory attack surfaces and trust boundaries.
3. Start at the lowest realistic layer for the target.
4. Note where lower-layer success or weakness enables higher-layer testing.
5. Document tested layers, lightly-touched layers, and untested layers explicitly.
6. When reporting, map each finding to a primary layer and optional supporting layers.

Documentation pattern

When adding OSI-layer documentation inside an engagement, create a dedicated folder such as:

• engagements/<target>/osi-layers/

Useful files:

• README.md — purpose, scope, and current layer coverage
• layer-coverage.md — tested vs partial vs not-tested
• one file per active layer, for example:
  • physical.md
  • network.md
  • transport.md
  • application.md

For each layer file, prefer this structure:

• objective for this target
• what was actually tested
• evidence and commands/actions
• findings or observations
• current confidence
• next logical tests
• boundaries and unverified claims

Cross-layer finding pattern

Use a compact block like:

- Finding: Exposed admin surface reachable through unexpected route
- Primary layer: Application
- Supporting layers: Network, Transport
- Why: business function abuse was the direct issue, but segmentation and service exposure enabled it

When not to overuse it

• Do not relabel every note just for the sake of the model.
• Do not rewrite older engagement history if that would distort the real chronology.
• Do not pretend Session or Presentation are absent just because the product uses TCP/IP abstractions.

References

Read references/layer-mapping-guide.md when you need a concise field guide for mapping real pentest activity into OSI layers without over-forcing it.