Cybersecurity: Why Legacy Telnet and Zero Trust Flaws Persist

Any strategy, regulatory framework, or management system is going to tell us how important encryption is, and it will require us to implement it, whether in transit or at rest. But the most relevant factor is how basic this control is and how relatively simple it is to implement. 

However, because it is such a basic and simple control, on some occasions it may end up being skipped, especially when we talk about internal communications, where, despite the whole Zero Trust philosophy, organizations still consider their internal network to be a trusted network. 

This story begins, like all stories, on a rainy night, on which a pentest was being carried out. The infrastructure was federated through Active Directory and security in general was quite high, the usual for a financial institution. Encryption? Of course. 

The applications made use of encryption, most of them consuming APIs encrypted over HTTPS, and although in some cases the certificates were self-signed, in others, where the applications were proprietary, the certificates were properly configured. 

For the integrations, this company made use of periodic SAST, DAST, and CSA scans, so the encryption algorithms were also the most recent. On top of that, breaking the certificate was not that simple — active monitoring would surely have detected any kind of attempt to break the encryption, so it was not too viable. 

Even though one of the most important parts was intercepting the transactions, at the start of the pentest it was not viable enough. 

The pentest went on. It scanned for exploration, service detection; a few vulnerabilities, and finally, a domain user used for support, which reused a local user password; and we had access to several production servers. It was not a domain user, but it worked all the same. It gave access to several servers in the most relevant segments. Among them, a Windows 2016 application server. 

That server caught our attention because most of the servers were 2019, 2022, and 2025; but out of some 700 servers, there was only one 2016. Why? 

Upon getting into that server, and running an ARP scan to check what it had visibility of, we came across something very interesting: an OS/390 Mainframe, which we have to admit is already a very different thing altogether. We are not talking about an old server, but about an entire virtualization system, only on a Mainframe. And the most interesting part: a service over Telnet. 

Telnet? In 2026? For those who are very young and may not know what Telnet is, it is a cleartext protocol. Let us remember that we could not carry out a "Man In The Middle" because that would have raised alerts in the SOC, but we could carry out local "sniffing" to see what that Windows 2016 was sending over Telnet to the Mainframe. When we saw what it was, we knew the report was going to come out red. 

We had complete transactions, captures of the Mainframe dashboard, users, requests for the transactions; even though we had not taken the full Domain, it really was no longer necessary as we already had access to the most important thing and to what affected the business the most. 

Now, there are going to be some occasions in which operations or the business force us to keep legacy systems. Examples of that are the OT environments that are so fashionable today; however, in those cases, it is necessary to apply compensating controls to prevent this type of vulnerability from being exploited. In this case, there were none. The network was practically completely flat. 

This is a real case, and what is worrying is that many times the people who are leading the security strategies do not understand these very simple concepts. 

To sum up, let us list some of the things that were done wrong: 

1. The password policy was deficient, allowing multiple authentication attempts to be made without the accounts being locked out, which made it possible to try different passwords against the local users until a local user could be compromised. 
2. The users are surely poorly trained in awareness, or there are weak support procedures that allow the widespread use of local users as support users. Today, there are different mechanisms to avoid having local users and still be able to provide technical support to users. 
3. The network was completely flat, which would allow the production segments to be seen from any point. 
4. While there is a monitoring service, which we realized was very strict, it is important to remember that monitoring is usually based on signatures or on anomalous behaviors. In this case, we made use of behaviors that were up to a point valid, such as RDP connections, a few pings, and ARP scans, which generally do not generate alerts given that it is a protocol very much used by NOCs
5. The use of Telnet as an unencrypted service. At first, we might think it was the center of everything, but there were so many findings that made it possible to get here that it is not necessarily the protagonist. Sadly, when the client saw the results, they immediately blamed Telnet for some reason. We believe that in their mind, they thought they could remediate the findings simply by encrypting the connection. 
6. Finally, although it is not as relevant, the excess of trust in the internal network as a safe environment led to there being no masking of information. We found that the Windows server also stored logs with sensitive information, transaction IDs, and other data that is quite useful to an attacker. 

Finally, the conclusion, which is aimed less at those who are leading security, and more at those who dedicate themselves to assessing it. Sometimes you do not need AI agents, exploitation frameworks, or C2. Sometimes just a Hydra against a dictionary with 10 passwords is more than enough.