curl -i https://app.example.test/api/healthHTTP/2 200
content-type: application/json
{"status":"ok"}A baseline response helps establish behavior. It does not validate authorization or prove a weakness.
Coverage / Target domains
One house.
Different systems.
The five phases adapt to the system under test. Scope, access, operational consequences, and evidence change across Web, Mobile, Platform, IoT, and OT engagements.
Here, Platform means operating systems, infrastructure, cloud, and identity—not a particular vendor product. Examples below are illustrative baselines, not complete test plans.
HOUSE LENS Web doors are URLs and API operations; room keys are sessions and authorization rules.
Domain / WebWeb Penetration Testing
Web trust boundaries
Treat each request as an Actor–Action–Resource decision. Cover authenticated and unauthenticated routes, objects belonging to different users, administrator functions, uploads, and multi-step business actions. A browser hiding a button does not enforce server-side policy.
Applications, APIs, authentication, and business logic.
How the phases adapt
Follow roles and state transitions. Test authorization at the object and function level, session handling, input processing, and application-specific abuse cases.
Evidence to preserve
A request/response pair with the test identity, expected policy, and observed boundary violation.
HOUSE LENS A mobile app is a doorway into the same house, not the whole house. The backend safe still needs server-side access controls.
Domain / MobileMobile Penetration Testing
Mobile trust boundaries
Distinguish findings that require a rooted or jailbroken test device from findings possible on a normal device. App storage, platform permissions, deep links, and transport behavior need device-specific evidence. Backend authorization remains a separate server-side test even when the mobile UI is restrictive.
Android and iOS apps, their local data, platform interactions, and backend APIs.
How the phases adapt
Combine static review with runtime observation. Consider storage, deep links, exported components, transport behavior, and server-side trust. Device state and OS version affect results.
Evidence to preserve
App build/version, device state, relevant runtime behavior, and evidence of an actual data or permission boundary.
Android Debug Bridge (ADB)
Official tool documentation ↗adb devices
adb shell pm list packagesList of devices attached
emulator-5554 device
package:com.example.labapp
[other installed packages]Requires an authorized Android device or emulator with debugging enabled. Lists connected devices and packages; this is inventory, not a vulnerability finding. iOS requires a different toolchain.
HOUSE LENS The platform is the house structure, internal services, and key system: hosts, cloud roles, and directory permissions.
Domain / PlatformPlatform Penetration Testing
Platform trust boundaries
Separate local host permissions, network service authorization, directory delegation, and cloud IAM. The same account can have different privileges in each layer. Record the token or role used for a test, and show the exact resource or operation made accessible.
Hosts, operating systems, infrastructure services, cloud configurations, and identity systems.
How the phases adapt
Review service exposure, host permissions, configuration, identity paths, and segmentation. For cloud systems, assess permissions and service configuration as well as hosts.
Evidence to preserve
The affected configuration, original identity, demonstrated permission change, and the resources actually reachable.
nmap -sV -p 22,443 192.0.2.10PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.x
443/tcp open https nginxIdentifies reachable services on the approved host. Pair this with configuration and permission review; version banners alone are insufficient.
HOUSE LENS IoT devices are connected fittings in the house. Their firmware, physical interfaces, and cloud links each create a boundary.
Domain / IoTIoT Penetration Testing
IoT trust boundaries
Inventory firmware version, physical interfaces, update mechanisms, local services, and device-to-cloud identity. Use a dedicated test device and record physical-access requirements. A firmware string or debug connector is a lead; a finding needs an explained trust failure and a demonstrated consequence.
Connected devices, firmware, physical interfaces, companion apps, and device-to-cloud communication.
How the phases adapt
Map trust boundaries across the device ecosystem. Assess update validation, key storage, debug interfaces, local services, and backend authorization on an approved test unit.
Evidence to preserve
Device model, firmware hash, interface used, observed behavior, and whether access requires physical proximity.
file firmware.binfirmware.bin: [format-dependent identification or data]Inspect an authorized firmware sample. Identification depends on the image format and magic database; encrypted or proprietary images may simply be reported as data.
HOUSE LENS OT controls the house’s machinery. Testing an entry must not endanger the process the machinery supports.
Domain / OTOT Penetration Testing
OT trust boundaries
Document dependencies and the process owner’s operating constraints before selecting a test. Start with approved captures and architecture review; validate intrusive hypotheses in a representative lab. Findings should explain the affected operational function rather than assume every IT weakness creates a physical safety event.
Industrial control systems, engineering workstations, supervisory systems, and their relationship to physical processes.
How the phases adapt
Start with system-owner-approved documentation and passive observations. Use a representative lab for intrusive validation. Active scans and exploit tests require process-specific approval and controls.
Evidence to preserve
The asset and process context, approved capture or configuration evidence, and the consequence for operational control or availability.
TShark / Wireshark
Official tool documentation ↗tshark -r approved-capture.pcapng -c 51 0.000000 192.0.2.10 → 192.0.2.20 [decoded protocol and packet summary]
[up to five captured packets]Reads an existing approved capture and sends no network probes. Protocol names depend on traffic and dissectors. Passive visibility does not prove that a command is unauthenticated or exploitable.