Default Credentials on Exposed VPN and SSH Gateways: The Gunra Path With the Faintest Audit Trail

Exploit development attracts attention. Misconfiguration does not. Yet the Gunra advisory published on 10 August 2026 describes an intrusion that began with neither a novel exploit nor a compromised user. It began with default credentials on an internet-facing appliance, at a site where a control most organisations assume they have was missing [1].

The documented intrusion path

The advisory records that, against one victim, Gunra actors gained access to an administrator account for a secure socket layer VPN appliance by exploiting default credentials at a time when account lockout controls were not present [1]. From that foothold, the actors downloaded OpenSSH from an attacker-controlled server and used it to establish tunnelling between compromised systems [1]. They later identified an unused account with access to both the internet-facing and internal corporate networks, modified the account configuration to bypass a mandatory password change requirement, and used it for further activity [1].
Three failures compound here, and only one of them is a missing patch. A default credential was accepted on a boundary device. No lockout policy interrupted repeated authentication attempts. An unused account retained cross-boundary privilege that no one had reviewed.

Why this vector is quiet

The advisory's stealth section notes that Gunra actors typically delete system and network access logs and clear command history while active in victim networks [1]. An intrusion that starts with a valid, default administrative credential on the appliance itself produces authentication events that look, at a glance, like normal administration. Add log deletion on top, and the record of how the actor arrived may not survive the intrusion.
Exposed management interfaces therefore belong in the exposure register, not in a configuration checklist.

Sizing the exposed population

SSH and VNC are the two most common remote-administration protocols visible from the internet. ZoomEye observations collected on 28 September 2026 recorded [2]:
| Query | ZoomEye matches (28 Sep 2026) |
|---|---|
| service="ssh" && port="22" && country="US" | 30,905,509 |
| service="vnc" | 9,190,464 |
| service="rdp" | 16,471,930 |
These are counts of fingerprint-matched services that responded to indexing, and they say nothing about configuration or credential strength. A service that answers on a public address is, however, a service whose authentication policy has to be assumed hostile-facing until proven otherwise.
The scale shows why reducing the exposed population and hardening it are separate programmes. No organisation can patch or reconfigure the global set; every organisation can re-examine its own boundary.

Controls that close the path

Each element of the documented intrusion maps to a control that can be verified.

• Change default credentials before a device is placed on a network, and verify the change rather than asserting it. Vendors ship default accounts for a reason, and the reason is deployment convenience, not production security.
• Implement account lockout, or rate limiting, on every authentication path that terminates on a boundary device [1]. The advisory notes the absence of lockout as a contributing condition, which makes its presence a specific, checkable requirement.
• Review accounts with cross-boundary access. The advisory's unused account held access to both the internet-facing and internal networks [1]. A periodic review of which identities can cross a trust boundary is a small, tractable task.
• Ensure administrative activity on boundary devices is logged to a destination the device cannot delete. If the local log is the only copy, the advisory's own description of log deletion applies directly.

Where external measurement fits

An external view tells you which of your management interfaces are visible at all. That is the precondition for everything else: a device that is not reachable from the internet cannot be reached with a default credential from the internet. Reducing exposure and hardening authentication are complementary, and the second is far cheaper when the first has already narrowed the set.

Limits

A ZoomEye observation confirms that a service is externally reachable and matched a fingerprint. It does not reveal credentials, configuration or lockout policy, and it must never be read as evidence that a specific system is vulnerable or compromised.

Practical next steps

Produce a current list of externally reachable management services, confirm the credentials on each one, verify lockout behaviour on the boundary authentication paths, and review which accounts can cross from the external network into the internal one.

References

[1] Cybersecurity and Infrastructure Security Agency et al., "#StopRansomware: Gunra Ransomware", advisory AA26-222A, 10 August 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-222a
[2] ZoomEye, external asset queries collected on 28 September 2026. https://www.zoomeye.ai/
[3] MITRE ATT&CK, Enterprise matrix, version 19.1. https://attack.mitre.org/