pwneye consolidates IP camera discovery, credential testing, and stream validation across ONVIF and RTSP into one CLI for authorized penetration testers and security researchers.
| Tool | Hackerest/pwneye — a portable Python CLI for discovering, authenticating against, and validating ONVIF/RTSP IP cameras |
| Category | Network camera assessment / offensive security tooling |
| Primary Use | Authorized testing of camera deployments: WS-Discovery enumeration, ONVIF/RTSP credential validation, stream verification, and snapshot/recording evidence collection |
| Safe Use | For penetration testers and security researchers working against cameras in owned lab environments or under explicit written authorization; the tool performs active credential bruteforce and device actions and must never be pointed at systems you do not own or control |
| Telemetry Note | Defenders observe WS-Discovery multicast probes, repeated ONVIF authentication failures and RTSP DESCRIBE/OPTIONS request bursts against camera ports, plus vendor-default credential patterns; successful compromise may show as camera reboots, factory resets, or PTZ/stream configuration changes in device logs |
pwneye positions itself as a focused, portable offensive security toolkit for the two protocols that actually run the IP camera world: ONVIF for management and control, and RTSP for media streaming. Written in Python 3.10+ and released under GPL-3.0, the current version is 1.4.0 with the codename panopticon, and it runs on macOS and Linux. The value proposition is consolidation: instead of stitching together a discovery scanner, an ONVIF client, a bruteforcer, and an ffmpeg wrapper, pwneye folds all of that into a single CLI workflow with per-target caching under ~/.pwneye. For authorized assessors working camera-heavy environments — retail, industrial, corporate campuses — that consolidation matters, because camera fleets are notoriously heterogeneous and the tool's vendor-aware logic absorbs much of that heterogeneity.
The architecture is two-track by design. ONVIF is treated as the management plane: discovery via WS-Discovery, authentication testing, metadata extraction, media profile enumeration, and device actions. RTSP is the media plane: port detection, banner-based vendor identification, credential and connection-string testing, and stream validation. The README explicitly frames ONVIF as the protocol that yields the richest post-auth context, and that framing is operationally correct — an authenticated ONVIF session reveals device information, configured users, network configuration, media profiles, and the RTSP stream URIs the camera exposes, which is exactly the reconnaissance data an assessor needs before touching the streaming side. The default workflow (pwneye -t <ip>) lets the tool decide protocol ordering, while --skip-onvif and --skip-rtsp constrain it to one plane.
Discovery is handled through WS-Discovery multicast, the standard ONVIF mechanism. pwneye --discover runs a continuous loop that probes every few seconds and prints only newly found devices, reporting host, port, XAddrs, manufacturer, hardware, MAC, and capability flags like NetworkVideoTransmitter and ptz. A detail worth noting: pwneye --discover all cycles through all configured non-loopback IPv4 interfaces, and the README is candid that interfaces are selected at startup and the same IP seen on different interfaces is not merged. It also warns that a VPN must actually transport WS-Discovery multicast for cross-VPN discovery to work — selecting an interface does not trigger a unicast subnet scan. That kind of precision in documentation suggests an author who has hit these edge cases in practice.
Credential testing is multithreaded on both protocol tracks. On the ONVIF side, -ou and -op accept single credentials or username/password wordlist files, with --threads N controlling concurrency; after a failed explicit attempt, expanding to common ONVIF credentials requires interactive confirmation, a deliberate friction point. The RTSP side is more interesting: pwneye ships with a knowledge base of over 450 vendor credential and connection-string profiles, meaning once the banner identifies a vendor, the bruteforce can pivot to vendor-appropriate defaults and RTSP paths rather than blind dictionary work. Manual vendor selection (--vendor) and manual connection strings (-cn) are also supported, which reduces request volume when the device family is already known — a noise-management feature assessors will appreciate.
The credential-selection semantics deserve attention because they affect test reproducibility. Omitting a credential option lets pwneye draw from its normal sources including cached findings; passing an explicit empty string (-p '') fixes that field to empty and takes precedence over cache. Blank lines in wordlists are ignored. This tri-state behavior — unspecified, explicit value, explicit empty — gives fine-grained control over how much autonomy the tool exercises, which is a thoughtful design for professionals who need to document exactly what was tested.
Post-auth ONVIF capabilities are where the tool moves from reconnaissance into device interaction, and this is the part that demands strict authorization discipline. Authenticated actions include --reboot, --reset (factory reset), --shell (interactive ONVIF shell), PTZ movement from the CLI or the built-in viewer, and --deface / --undeface for stream defacement and restore via a saved deface profile. Every one of these is disruptive on a production camera. A factory reset on a client's surveillance device during an unauthorized scan is not a gray area — it is damage. The restore capability (--undeface) at least implies the author expects responsible operators who clean up after themselves, but none of this belongs outside a lab or a contract with explicit scope.
The RTSP side is built around the reality that DVR/NVR deployments multiplex many channels behind one address. pwneye handles multi-channel streams with automatic detection, guided enumeration, and interactive channel selection via --multi-channel, and it includes a dedicated live preview client with zoom and fast channel switching for DVR/NVR-style targets. Connection-string templates like /cam/realmonitor?channel={channel}&subtype=0 show the expected path grammar for channel-based devices. Stream validation, live preview through ffplay, recording through ffmpeg, and snapshot capture (--snapshot, --record) round out the evidence-collection story — which is the legitimate end state of an authorized assessment: proof that a camera is accessible, documented, and reportable.
External dependencies are minimal and honest: ffplay, ffprobe, and ffmpeg must be in PATH depending on mode, with per-distro install commands provided. Installation is pipx install git+https://github.com/Hackerest/pwneye.git, and the tool self-manages updates through pwneye --update, which checks for newer releases before upgrading the pipx installation; --check-updates is check-only. Cache behavior is also configurable: --no-cache disables reads and writes entirely, while --fresh ignores cached reads but still records new findings — a sensible pattern for re-testing targets without stale results contaminating the run.
From a defensive standpoint, pwneye is a useful threat model anchor. Its traffic patterns are observable: WS-Discovery multicast probes on the management VLAN, bursts of failed ONVIF authentications against port 80 or 8080 device services, high-volume RTSP DESCRIBE attempts across vendor-default paths, and the eventual signature of success — reboots, resets, PTZ movement, or stream configuration changes in camera audit logs. Camera fleets should be segmented away from user networks, ONVIF should be disabled or authenticated with non-default credentials, RTSP should never face the internet, and monitoring should flag repeated failed authentications. The 450+ vendor profile knowledge base is effectively a map of how weak default credentials still are across the industry.
At 421 stars with active versioning, pwneye is a credible, actively maintained entry in the camera-assessment niche. Its strengths are the unified workflow, vendor-aware RTSP logic, multi-channel DVR/NVR handling, and disciplined caching/update mechanics. Its capabilities — reboot, reset, deface, shell — are powerful and correspondingly dangerous outside authorized scope. For professionals assessing camera deployments under contract, it replaces a fragile toolchain with one coherent instrument; for everyone else, the tool's own feature list is a checklist of what unhardened cameras expose.
In summary, pwneye earns its place as a specialist tool: it does one thing — IP camera assessment across ONVIF and RTSP — and covers the full arc from passive discovery through authenticated device interaction to stream evidence capture. Used in labs and authorized engagements, it is exactly the kind of focused offensive tooling that makes assessments of camera infrastructure tractable. Used anywhere else, its features read as a vandalism kit. The license, documentation quality, and cleanup-oriented design (--undeface, restore profiles) suggest the author intends the former, and the rest is on the operator.
Hackerest/pwneye.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.