Proactive PAM Defenses against LightBasin (UNC1945) & other Advanced Attackers | BeyondTrust

On October 19, 2021, CrowdStrike released a detailed analysis of a cyberattack waged on telecommunications companies by a group dubbed LightBasin (also referred to as UNC1945). The LightBasin attack uses a blend of industry-specific protocol abuse and standard Unix/Linux attacks to take over multiple systems. This particular threat actor group has reportedly compromised at least 13 telecommunications firms since 2019.

CrowdStrike detailed what I counted as 7 cybersecurity defense strategies to protect against the LightBasin attack. Parsing CrowdStrike’s attack analysis, I also recognized three additional LightBasin attack strategies, for which no defenses were cited.

This blog will:

• Map CrowdStrike’s 7 recommended protections against the LightBasin attack to the SANS CIS Controls
• Identify and map cybersecurity controls for the three additional LightBasin attack strategies for which CrowdStrike did not offer recommendations
• Detail how two BeyondTrust products, Password Safe and Privilege Management for Unix & Linux address the security gap by providing protection against the three additional LightBasin attack strategies

Mapping CrowdStrike’s 7 LightBasin Cyber Defense Recommendations to CIS Controls

In their analysis, CrowdStrike details the following 7 recommendations to defend against this specific LightBasin attack:

1. Use ingress and egress advanced firewalls to validate only expected protocols are being used, especially between federated partners

2. If you suspect compromise, immediately begin an incident response investigation.

3. Evaluate and test any managed service povider’s (MSP) security controls.

4. Ensure systems monitoring and SIEM (event-forwarding from endpoints and endpoint protection tools) management is in place and functioning.

5. Utilize endpoint detection and response (EDR) tools (such as CrowdStrike’s Falcon Sensor).

6. Ensure you have a modern, tested incident response plan.

7. Utilize and maintain your threat intelligence resources.

Mapping CrowdStrike’s recommendations to a common security controls framework allows a defender to review where they may have additional defenses not yet covered by the recommendations in *any* blog post. In this case, I’ll map them to the SANS Institute CIS Controls v8:

1. Network Monitoring and Defense: 13

2. Incident Response Management: 17

3. Service Provider Management: 15

4. Audit Log Management: 8

5. Continuous Vulnerability Management: 7

6. Incident Response Management: 17

7. Security Awareness and Skills Training: 14

The above mapping covers 7 of the 18 current CIS Controls.

Identifying & Mapping Additional LightBasin Cyber Defense Measures

In their analysis, I noticed three additional attack strategies for which CrowdStrike offered no security recommendations. Next, I will directly map those attack strategies to three additional CIS Controls. (We’ll label these bullets with letters, to differentiate from the recommendations above.)

Here are those three attack strategies:

A. “evidence uncovered indicative of password-spraying attempts using both extremely weak and third-party-focused passwords (e.g., huawei)”

B. “persistence established through the modified SysVinit script /etc/rc.d/init.d/sshd”

C. “The actor also replaced the legitimate iptables binary with a trojanized version”

Performing the same CIS Controls mapping, we get:

A. Account Management: 5

B. Access Control Management: 6

C. Data Protection: 3

Let’s now look at additional protections available against these three layers of the attack.

While the attack described in this case is using telecommunications networks for lateral movement, financial (SWIFT) and healthcare customers have similar backend peering systems with partners. Additionally, many other private companies have peered VPN agreements that also must be watched in the same way CrowdStrike describes telecommunications companies must watch GPRS and eDNS traffic.

Attack A. Protection against password spraying

The initial foothold into the customer network described by CrowdStrike was an attack on poorly-protected default or widely-shared passwords on well-known accounts.

BeyondTrust Password Safe is a proven, enterprise-class privileged credential management solution recognized for its ability to set unique passwords for each instance of an account (each account on each server), and to rotate those passwords regularly (or even upon every use), as well as to enforce other advanced password security best practices.

Setting cryptographically secure pseudorandom number generator (CSPRNG)-created passwords—rather than passwords which would be found in a hash, rainbow table, or crack table—defeats password spray attacks simply by enforcing that the accounts do not have leaked/well-known passwords.

Setting each account on each endpoint to a unique value defeats lateral movement, even if an attacker can crack the /etc/shadow file from a pwned server. Additionally, since Password Safe can set and rotate SSH keys, lateral movement via those methods can be restricted or prevented as well.

Other potential protections against password spraying include locking these well-known accounts and accessing them only via pbrun -h <hostname> -u <account> with BeyondTrust Privilege Management Unix/Linux (an endpoint privilege management solution, formerly called PowerBroker) from a trusted jump host, accessed and authenticated via a centralized directory such as Active Directory. While these last two methods won’t ensure your users aren’t subject to the same password spray attack, they will contain the attacker to audited access methods (with Privilege Management for Unix & Linux’s session logging features) on a constrained jump host.

Attack B. Access control management defense

CrowdStrike also describes a second LightBasin attack method where the /etc/init.d/sshd initialization script is edited by the attacker to insert a persistence listener. We can assume that the attacker has root access to make this modification—but how did they get that?

We know that the password spray attack was done against more accounts than just “root”, so we can guess that those accounts had some sudo access. But for the sake of argument, we’ll assume that full root access was also obtained, and discuss defenses there as well.

First, there are many widely recognized techniques for privilege escalation for users who have sudo rights to certain tools. These are well-documented in the popular GTFOBins repository.

When providing a user sudoers rights to one of these tools, it is almost impossible to limit the escapes. However, with the Privilege Management for Unix & Linux product, we can employ tools like pbksh, pbvi, and pbless, as well as Advanced Control and Audit (ACA) to either allow only elevation to tools that do not have the documented backdoors from GTFOBins, or to limit file access post-escape.

In the animated GIF below, we see the Privilege Management for Unix & Linux pbvi utility being used in an elevation, but not allowing the “run scripts” escape common to vi.

PMUL policy can even be written to change the request for vi to pbvi, as in this PMUL example script:

procedure SafeFileEdits() {

editorlist={ ‘vi’, ‘vim’, ‘vim-tiny’, ’emacs’, ‘nano’, ‘ed’, ‘edlin’};

if (basename(runcommand) in editorlist) {

runcommand=”pbvi”;

}

morelist={ ‘more’, ‘less’};

if (basename(runcommand) in morelist) {

runcommand=”pbless”;

}

unset(“editorlist”);

unset(“morelist”);

}

When using this policy, simply call SafeFileEdits(); before the accept; in your policy. Applying this simple bit of policy, we can block the attacker from escaping from an allowed elevation, but this doesn’t block editing the SSHD file *directly*. For this second piece, we need to review the arguments passed by the user. The best solution in this case is to write a policy that only allows editing known files. No user should ever need to manually edit a sysv init script or systemctl control file.

It’s worth pointing out that many attacks may NOT go through the PMUL elevation systems. Forcing root’s shell to pbksh or pbsh may help reduce these instances, but cannot eliminate all attacks.

The CrowdStrike team called out deploying file integrity monitoring (FIM), which is another capability provided by Privilege Management for Unix & Linux. Specific to the attack in question, a FIM policy could greatly aid in early detection of an attack, and is documented directly in the Privilege Management for Unix & Linux documentation:

{“sysconf”:

{

“dev”:{“risk”:10,”mode”:true,”uid”:true,”gid”:true},

“exec”:{“ino”:true,”hash”:true,”risk”:10,”mode”:true,”uid”:true,”ctime”:true,”pmask”:”022″,”gid”:true,”size”:true,”mtime”:true},

“other”:{“risk”:6,”mode”:true,”ino”:true,”pmask”:”002″,”gid”:true,”uid”:true,”ctime”:true,”size”:true,”mtime”:true},

“script”:{“ino”:true,”hash”:true,”risk”:10,”mode”:true,”uid”:true,”ctime”:true,”pmask”:”022″,”gid”:true,”size”:true,”mtime”:true}

},

“bin”:

{

“all”:{“ino”:true,”hash”:true,”risk”:10,”mode”:true,”uid”:true,”ctime”:true,”pmask”:”022″,”gid”:true,”size”:true,”mtime”:true,”own”:”root”}

},

},

“include”:[

{“bin”:true,”path”:”/bin/*”,”chk”:”bin”,”recurse”:true},

{“bin”:true,”path”:”/usr/bin/*”,”chk”:”bin”,”recurse”:true},

{“bin”:true,”path”:”/lib/*”,”chk”:”bin”,”recurse”:true},

{“bin”:true,”path”:”/sbin/*”,”chk”:”bin”,”recurse”:true},

{“bin”:true,”path”:”/usr/sbin/*”,”chk”:”bin”,”recurse”:true},

{“bin”:true,”path”:”/usr/lib/*”,”chk”:”bin”,”recurse”:true},

{“sysconf”:true,”path”:”/etc/*”,”chk”:”sysconf”,”recurse”:true},

{“sysconf”:true,”path”:”/boot/*”,”chk”:”sysconf”,”recurse”:true}

],

}

While this kind of configuration doesn’t block the attacker, it does help the defending engineers to immediately recognize an unexpected configuration, and to rapidly act upon it.

Attack C: Data protection

For cases where a systems administrator needs a full shell, replacing vi with pbvi is unworkable. In the third attack strategy, the attackers replaced system files outright. In this case, replacing vi with pbvi or less with pbless is also not enough. This is what Privilege Management for Unix & Linux ACA is for.

The BeyondTrust Implementation Services team commonly employs a “Block Backdoors” technique in the policy we’re delivering to customers. The current version I’m working with has two parts, one to prevent users from adding or editing user accounts or group membership to prevent backdoor user creation, and one to prevent access to tools/commands/files that might cause system downtime (attacking the availability in the CIA triad):

procedure BlockUserBackdoors() {

softwarecommands={‘yum’, ‘rpm’, ‘dpkg’, ‘apt’, ‘aptitude’};

if (!(basename(runcommand) in softwarecommands)) {

aca(“file”, “/etc/passwd”, “!all:log=2|read:log=1”, “BACKDOOR”);

aca(“file”, “/etc/shadow”, “!all:log=2|read:log=1”, “BACKDOOR”);

aca(“file”, “/etc/group”, “!all:log=2|read:log=1”, “BACKDOOR”);

}

if (basename(runcommand) == “ln”) { if (runargv[1] != “-s”) { reject(“Cannot hardlink files.”); } }

unset(“softwarecommands”);

}

procedure BlockSystemDamage() {

damagecommands={‘/usr/bin/rm’, ‘/usr/bin/mv’, ‘/usr/sbin/halt’, ‘/usr/sbin/shutdown’, ‘/usr/sbin/reboot’, ‘/usr/sbin/init’, ‘/usr/bin/systemctl’, ‘/bin/rm’, ‘/bin/mv’, ‘/sbin/halt’, ‘/sbin/shutdown’, ‘/sbin/reboot’, ‘/sbin/init’};

for dmgcomm in damagecommands {

aca(“file”, dmgcomm, “all:log=1|!exec:log=2”, “SYSTEMDAMAGE”);

if ((runcommand == dmgcomm) || (basename(runcommand)==basename(dmgcomm))){

reject(“This command is blocked from executing to prevent system availability issues.”);

}

}

unset(“damagecommands”);

softwarecommands={‘yum’, ‘rpm’, ‘dpkg’, ‘apt’, ‘aptitude’};

if (!(basename(runcommand) in softwarecommands)) {

aca(“file”, “/etc/”, “!all:log=2|read:log=0|exec:log=0”, “SYSTEMDAMAGE ETC”);

aca(“file”, “/usr/”, “!all:log=2|read:log=0|exec:log=0”, “SYSTEMDAMAGE USR”);

}

unset(“softwarecommands”);

}

The first procedure blocks all reads and writes to the passwd/shadow/group files from any elevated request of any kind–even a full shell—unless the user is installing a package.

The second procedure blocks execution of common commands like rm, mv, halt, shutdown and reboot. It also blocks all access except read() and exec() to files in /etc/ and /usr/, again, unless a package management tool was the elevated request. It works the same as making a file immutable, or mounting /usr and /etc read-only, but cannot be undone by the local system administrator, and still allows patching to work unimpeded. Because we haven’t allowed the link() call, a user can’t even get around it by soft or hard linking a protected file outside of the protected paths.