The Importance of Privileged Access Management

Last month, Okta disclosed that one of its third-party support vendors had been compromised in an attack by the hacking group Lapsus$ and that as many as a few hundred of their customers may have had data exposed through the breach.[1] The incident was especially notable because the victim is itself an industry leader in Identity and Access Management. 

Later reports suggested the attack may have followed a familiar pattern: threat actor compromises a local system, escalates privileges, and moves laterally within the environment. Once inside, the attacker performs initial reconnaissance to gain an understanding of the firm’s security posture. According to reports that purport to derive from the Okta vendor’s investigation of the incident, the Lapsus$ hackers determined that a FireEye endpoint protection agent was installed on the compromised system and they were able to bypass its protection by simply terminating the agent. (We’ve seen this play before, too.)  With nothing to stop them, the attackers allegedly then downloaded the official version of Mimikatz, a well-known credential dumping utility that otherwise would have been blocked by the endpoint agent.[2]

Expert recommendations on how this kind of incident could be prevented vary from assessing incident readiness and business continuity capabilities to better log management to proactively resetting passwords to better communication and sharing of information. But more specifically, how could THIS breach have been prevented?

Let’s start with the ability to shut down FireEye’s endpoint agent. If the firm had better fine-grained access controls implemented they could have prevented the ability for the threat actor to terminate the FireEye agent. (Incidentally, Symantec Endpoint Security products use proprietary technology that specifically prevents and alerts on any such tampering.)

Introducing Symantec PAM Server Control

Symantec PAM, by Broadcom Software, is designed to prevent security breaches by protecting sensitive administrative credentials, controlling privileged user access, proactively enforcing security policies, and monitoring and recording privileged user activity across virtual, cloud and physical environments. One of the core capabilities of Symantec PAM is the ability to protect against security breaches with fine-grained protections over operating system-level access and privileged user actions on your servers, including Windows, through the server control agents. 

Using centrally managed task delegation and platform-specific software restrictions, the Symantec PAM Server Control (PAMSC) agents provide file, directory, and resource-specific, kernel-level controls, registry protection, and other localized granular controls to ensure that high-value assets and resources hosted on critical servers are protected from damages caused either by malicious or accidental insider actions.

How Server Control Agents Address an Okta-like Breach

In the Okta incident, the threat actor allegedly was able to terminate the FireEye agent that provided endpoint protection on the local system. This action could have been mitigated with Symantec PAM Server Control. With Server Control, critical system daemons and application processes like FireEye can only be shut down (killed) by authorized users, regardless of their level of authority in the system. In other words, if you are a system administrator, you cannot kill the agent just because you have an admin account. 

Using PAM Server Control’s “Process Class” capability, you can protect executable programs running in their own address spaces from being killed. You can define PROCESS records to protect important daemons and applications against denial-of-service attacks. PAM SC intercepts and authenticates the following kill signals:

■ sigterm - term 15 (This is the common kill signal.)
■ sigkill - kill 9
■ sigstop - stop (machine dependent)

Other signals, including sighup and sigurs1, are passed to the process that they target, and that process determines whether to ignore the kill signal or respond to it in some manner.

These are the permitted access types for the PROCESS class records:
READ R Allows the kill signal to be passed to UNIX
NONE N Blocks intercepted kill signal

Example:
1 newres PROCESS /usr/sbin/syslogd owner(nobody) defacc(N) \
audit(ALL)
This example defines a process record that protects the process called syslogd from unauthorized kill commands. All attempts to kill the process, both authorized and unauthorized, are audited.

How to Mitigate Using Server Control:
Define a PROCESS class to Server Control that is protected from being killed by sigterm, sigstop, and sigkill signals.

Example:
1 In the Administrator window, in SELANG, define the resource in the PROCESS class.
PAMSC> newres PROCESS /usr/sbin/syslogd  defacc(none) owner(nobody)
The program is defined in the process class.

2 In the root window, find the process identifier number (PID) of the SEPMDADM utility.
# ps -ef | grep /usr/sbin/syslogd  | grep -v grep
The system displays the process identifier for the utility. The first number following the user ID is the process ID, or PID.

3 In the root Window, try to kill the process by using the TERM signal, and watch the Trace Window.
# kill pid
Permission denied.

4 In the root Window, try to kill the process by using the KILL (-9) signal. Use the PID from step 2 as a parameter to pass with the kill command, and watch the Trace Window.
# kill -9 pid
Permission denied.

5 In the Auditor window, review the audit log. You should see a denial audit record for the PROCESS database record.
$ /usr/seos/bin/seaudit -a -sd today | tail

Summary

The Symantec PAM Server Control’s fine-grained rules can prevent an insider who has elevated privileges from killing the process. If you want to ensure that certain programs are protected from denial of service attacks or kill programs from malevolent users, define a PROCESS class to Server Control that is protected from being killed by sigterm, sigstop, and sigkill signals.

To learn more about how Broadcom Software can help you with your PAM solutions contact us here.

[1] https://www.acaglobal.com/insights/update-okta-announces-366-customers-impacted-lapsus-breach

[2] https://www.itpro.co.uk/security/cyber-security/367236/leaked-mandiant-report-okta-breach-lapsus-operation