" ensuring that "firewalls responsible for the GPRS network have rules in place to restrict network traffic to only those protocols that are expected, such as DNS or GTP" "

It's scary that this suggestion even has to be made. Why would you not? As all our comms converge on a common infrastructure, such lax security is potentially lethal.

When pentesting small business environments I’ve yet to see anything but EOL (without ever being patched) OpenSUSE installs with VNC complete with weak passwords…. No matter what the telco system is, it’s always secured piss poorly

"No matter what the telco system is, it’s always secured piss poorly"

Except customer services - that's guarded by the most secure vault doors ever conceived.

Never worked for a telco but when dealing with core DC infrastructure it always seemed to be some sort of ancient OpenBSD system that had been running for eight years and all the engineers were too afraid to touch. Said server will almost certainly have a non-descriptive name like Saturn, nobody really knows what it does but everyone knows it's very important so shouldn't be touched. Oh and an upgrade or any sort of modification is absolutely out of the question because the last time someone tried that the whole server had to be rebuilt after tracking down the guy who built it and left the company seven years ago.

Many security pundits demand that the names of systems are non-descriptive, to make it more difficult for miscreants to know without investigating which systems should be attacked. And some say that having a fully populated DNS available to be queried is a bad idea as well.

It's a small measure (and certainly not enough by itself), but it is another brick in the wall.

Mind you, it never seems to stick, and I've seen many organizations who slip back into easily identified naming schemes.

The thing that needs to be considered here is that putting a backdoor that listens to a nominated non-privileged port, and provides a stepping stone into a secure environment is not that difficult on any UNIX like box. It does not even need a privileged process to work on many out-of-the-box installs.

The protection required here is firstly to stop the initial access to the system, which could be through a non-OS route (such as the sgsnemu process mentioned), and then for any internet connected system (or even those in the hinterland), total control of all ports not explicitly used by the required services. Other protections are to have a minimalist install of the system, removing or not installing in the first place as much software as you can, and limiting what ordinary users can access or run. Mind you, the rise of very functional scripting languages like Perl and Python, and the requirement that they be installed for the OS utilities to function makes securing systems from internal threats after the initial breach much more complicated.

This is basic UNIX security protection, and most experienced admins. will understand this.

Unfortunately, many experienced UNIX admins have been cast aside by organizations wanting to trim their staff costs, or have seen the writing on the wall, and have switched to newer technologies, or have simply retired.

This leaves relative noob administrators, or people who are experts in Windows or other platforms, to pick up support, and many of these will use the hand's off management principal, because they don't understand the systems.

Quite right, looking at the description here

https://www.cybersecurity-help.cz/blog/2377.html

none of this should even be doable on a secured UNIX system.

Surprised they are not targeting banks as well. In the UK at least, Solaris is still a big thing.

"The firm also recommends that *nix implementations in telco-land need "basic security controls and logging in place (e.g., SSH logging forwarded to a SIEM, endpoint detection and response (EDR) for process execution, file integrity monitoring (FIM) for recording file changes of key configuration files)".

which you can buy from us of course.....

A lot of juicy stuff in big TELCOS, up to this day, are also stored on their HP-UX.

> the group also knows telco kit well enough to implant the TinyShell backdoor in Serving GPRS Support Node emulator sgsnemu and use it to hop across mobile networks in search of servers to compromise.

That part of the sentence does not make sense! The SGSN is a type of node in GPRS infrastructure. From the Cloudstrike article the LightBasin "crew" are using a SGSN emulator as a way for their TinyShell to use/abuse the mobile network (via mobile SIMs/devices they control) to tunnel traffic to the command server if this cannot be reached via normal Internet connectivity.

So an accurate rewritten text would be:

"the group also knows telco kit well enough to implant the TinyShell backdoor and also to emulate SGSN infrastructure (via the software "sgsnemu") so that TinyShell can hop across mobile networks to contact the C2 server whenever direct Internet connectivity to that C2 server is not possible."

I was involved with several mobile carriers' deployments of GPRS "2.5G" back in the early 2000s so used to know the handset<->SGSN<->GGSN traffic flow inside-out.

Having worked for Telcos I have seen first hand the mess the security is. Despite raising concerns time and time again, it always got swept under the carpet. I remember talking to one guy during an external audit. I went through my concerns with him. The report (when it was published later) was pretty scathing.

Roll forward 2 YEARS and the guy gets employed by the Telco in question. He turned up at my desk with a forlorn look on his face and said "Nothing raised in that report has been implemented. If anything, its got worse!". I just grinned and welcomed him to my hell.

Even the new network designs had such obvious security implications that anybody looking at it would say 'Hold up - you did what?' but they still got implemented because it was deemed too late to fix it.