Building a Python Tool to Enumerate and Test Default Credentials on Network Devices

Network appliances often arrive with factory usernames, temporary passwords, or vendor-defined access patterns that remain unchanged after installation. A Python utility can help administrators identify these exposures across routers, switches, firewalls, wireless controllers, cameras, and industrial gateways, provided every test is authorised and carefully controlled.

The safest design treats credential checking as an asset-management and configuration-audit task rather than a password attack. The tool should discover approved devices, compare their settings with a controlled credential catalogue, limit connection attempts, and produce evidence that a security team can review. This approach is useful for Australian businesses managing equipment across Sydney offices, Melbourne data centres, regional branches, and remote sites connected through mixed broadband services.

Define the authorised scope

Begin with an explicit inventory file containing IP addresses, hostnames, device types, owners, maintenance windows, and permitted protocols. Avoid scanning arbitrary address ranges by default. A command-line option such as --inventory assets.yml makes the scope visible and gives operators a reviewable record of what the program was allowed to contact.

The inventory should also classify systems by sensitivity. A small office switch, a hospital network appliance, and an operational technology gateway should not receive identical treatment. Australian organisations may need to align the process with the Essential Eight, the Information Security Manual, contractual obligations, or privacy requirements. Include an approval identifier and an emergency stop mechanism so a scheduled assessment can be halted quickly.

Model vendor defaults safely

A credential catalogue should contain vendor, model family, protocol, default username, and a reference to the vendor’s documentation. Do not distribute a large collection of live passwords inside the application. Store test values in a protected configuration file, inject them through an approved secrets manager, or require an administrator to provide a temporary audit list at runtime.

Represent each entry as data rather than hard-coded branching logic. A YAML record might identify ssh, https, or a vendor API, along with a connection port and a maximum number of attempts. This makes updates easier when manufacturers change their setup process and prevents old credentials from quietly becoming part of every scan.

A useful audit can also flag weak configuration without logging in. For example, DHCP fingerprints, TLS certificates, SNMP banners, or management-page titles may reveal a likely vendor and model. Treat those signals as uncertain until confirmed, and avoid using them to expand the scan beyond the authorised inventory.

Build conservative protocol adapters

Python’s standard library can handle configuration, logging, concurrency controls, and structured output, while well-maintained packages can support SSH, HTTPS, and vendor APIs. Keep each protocol adapter behind a common interface such as identify(), test_credential(), and close(). The main runner should not need to know whether a result came from Paramiko, an HTTP client, or a specialised SDK.

Every adapter needs strict timeouts, certificate handling appropriate to the assessment, and a single clean shutdown path. Disable interactive shell commands by default. A successful login should prove only that the supplied account works; it should not automatically execute commands, alter settings, download files, or explore the device.

Connection pacing matters on Australian networks where a remote branch may rely on a constrained link or a managed service with aggressive intrusion prevention. Use a low global rate, a per-host delay, and bounded concurrency. If a device reports lockout risk, repeated authentication failure, or rate limiting, stop testing that host and record the reason.

Prevent accidental password spraying

The tool should never try every password against every device. Pair a device with only the small set of credentials explicitly associated with its vendor and deployment record. A dry-run mode can display intended targets and protocols without opening connections, allowing an engineer to verify the plan during a change-control meeting.

Separate “default credential confirmed”, “authentication failed”, “device unavailable”, and “test skipped” states. Never treat a timeout as evidence that credentials are safe. Likewise, avoid printing passwords in terminal output, exception traces, CSV files, or debug logs. Hash or redact account identifiers when reports leave the security team.

For troubleshooting documentation, a concise operational note can sit beside the code; this practical reference illustrates the value of recording a problem, its context, and the steps taken without exposing sensitive material. That discipline is especially valuable when a managed service provider supports several customers.

Produce useful evidence

A result should include the asset identifier, observed device information, protocol, test time in UTC, credential reference, outcome, and remediation status. Store secrets separately from findings, and encrypt reports at rest. JSON is convenient for dashboards, while CSV can help a smaller team review affected assets in a spreadsheet.

The remediation message should be practical: change the factory account, disable unused management services, restrict administration to a management VLAN or VPN, enable multi-factor authentication where supported, and update firmware. For devices in a Brisbane warehouse or a remote Western Australian site, note whether an onsite visit, console cable, or out-of-hours maintenance window is required.

Add regression tests for parser behaviour, timeout handling, redaction, and lockout safeguards. Mock protocol responses rather than connecting to production equipment during development. A fixture representing a failed login must verify that the runner stops at the configured attempt limit and records no secret values.

Package it as a maintainable open-source utility

A command-line interface should expose safe defaults: dry-run enabled for first use, bounded concurrency, conservative timeouts, and explicit confirmation before live testing. Include a sample inventory containing fictional addresses and credentials, plus documentation explaining authorisation, supported device families, data retention, and responsible disclosure.

Use a permissive licence only when it matches the project’s goals and dependencies. A small changelog should document new protocol adapters, catalogue corrections, and security fixes. Publishing design notes alongside the source can help users understand the boundaries of the utility; the Phil Schwartz portfolio is a useful example of how software projects can present background, licensing, downloads, and technical purpose in one place.

Before release, review the tool as both software and security infrastructure. Confirm that packaging does not include secrets, that logs are safe to share, and that an untrusted inventory cannot trigger arbitrary commands. A focused credential-audit tool should make authorised reviews repeatable while making accidental disruption, unauthorised access, and unnecessary data collection difficult by design.