Container Alarm Events

Malware

Malicious software includes viruses, worms, Trojans, and web shells implanted by hackers to steal your data or control your servers.

For example, hackers will probably use your servers as miners or DDoS zombies. This occupies a large number of CPU and network resources, affecting service stability.

Unclassified malware

Check malware, such as web shells, Trojan horses, mining software, worms, and other viruses and variants. The malware is found and removed by analysis on program characteristics and behaviors, AI image fingerprint algorithms, and cloud scanning and killing.

Ransomware

Check for ransomware in web pages, software, emails, and storage media.

Ransomware can encrypt and control your data assets, such as documents, emails, databases, source code, images, and compressed files, to leverage victim extortion.

Web shells

Check whether the files (often PHP and JSP files) in the web directories on containers are web shells.

Hacker tools

Report alarms on the malicious behaviors that exploit vulnerabilities or are performed using hacker tools.

Vulnerability Exploits

The exploit of vulnerabilities in the server system, software, or network to obtain unauthorized access rights, steal data, or damage the target system.

Exploits can be performed remotely or locally. In a remote vulnerability exploit, an attacker connects to the target system through the network and discovers system vulnerabilities to launch attacks. In a local vulnerability exploit, an attacker obtains low access permissions on the target system and exploits vulnerabilities to escalate permissions or perform other malicious operations.

Vulnerability escapes

HSS reports an alarm if it detects container process behavior that matches the behavior of known vulnerabilities (such as Dirty COW, brute-force attack, runC, and shocker).

File escapes

HSS reports an alarm if it detects that a container process accesses a key file directory (for example, /etc/shadow or /etc/crontab). Directories that meet the container directory mapping rules can also trigger such alarms.

Abnormal System Behaviors

Abnormal system behaviors occur while servers are running, and are usually caused by system faults, malicious attacks, or security vulnerabilities. Abnormal system behaviors may cause data loss or system breakdown. To protect server system and data security, it is important to detect and handle abnormal system behaviors in a timely manner.

Reverse shells

Monitor user process behaviors in real time to report alarms on and block reverse shells caused by invalid connections.

Reverse shells can be detected for protocols including TCP, UDP, and ICMP.

You can configure the reverse shell detection rule and automatic blocking in the Malicious File Detection rule on the Policies page. HSS will check for suspicious or remotely executed commands.

You can also configure automatic blocking of reverse shells in the HIPS Detection rule on the Policies page.

File privilege escalation

Report alarms on root privilege escalations exploiting SUID and SGID program vulnerabilities.

Process privilege escalations

After hackers intrude containers, they will try exploiting vulnerabilities to grant themselves the root permissions or add permissions for files. In this way, they can illegally create system accounts, modify account permissions, and tamper with files.

HSS can detect the following abnormal privilege escalation operations:

• Root privilege escalation by exploiting SUID program vulnerabilities
• Root privilege escalation by exploiting kernel vulnerabilities
• File privilege escalation

Important file changes

Monitor important system files (such as ls, ps, login, and top) in real time and generate alarms if these files are modified. For more information, see Monitored important file paths.

HSS reports all the changes on important files, regardless of whether the changes are performed manually or by processes.

Abnormal process behaviors

Check the processes on servers, including their IDs, command lines, process paths, and behavior.

Send alarms on unauthorized process operations and intrusions.

The following abnormal process behavior can be detected:

• Abnormal CPU usage
• Processes accessing malicious IP addresses
• Abnormal increase in concurrent process connections

High-risk system calls

Users can run tasks in kernels by Linux system calls. CGS reports an alarm if it detects a high-risk call, such as open_by_handle_at, ptrace, setns, and reboot.

High-risk command executions

Check executed commands in containers and generate alarms if high-risk commands are detected.

Abnormal container processes

• Malicious container program

  HSS monitors container process behavior and process file fingerprints. It reports an alarm if it detects a process whose behavior characteristics match those of a predefined malicious program.

• Abnormal processes

  Container services are usually simple. If you are sure that only specific processes run in a container, you can whitelist the processes on the Policy Groups page, and associate the policy with the container.

  HSS reports an alarm if it detects that a process not in the whitelist is running in the container.

Sensitive file access

HSS monitors the container image files associated with file protection policies, and reports an alarm if the files are modified.

Abnormal container startups

HSS monitors container startups and reports an alarm if it detects that a container with too many permissions is started. This alarm does not indicate an actual attack. Attacks exploiting this risk will trigger other HSS container alarms.

HSS container check items include:

• Privileged container startup (privileged:true)

  Alarms are triggered by the containers started with the maximum permissions. Settings that can trigger such alarms include the –privileged=true parameter in the docker run command, and privileged: true in the securityContext of the container in a Kubernetes pod.

  If the alarm name is Container Security Options and the alarm content contains privileged:true, it indicates that the container is started in privileged container mode.

• Too many container capabilities (capability:[xxx])

  In Linux OSs, system permissions are divided into groups before assigned to containers. A container only has a limited number of permissions, and the impact scope of this container is limited in the case of an incident. However, malicious users can grant all the system permissions to a container by modifying its startup configurations.

  If the alarm name is Container Security Options and the alarm content contains capabilities:[xxx], it indicates that the container is started with an overlarge capability set, which poses risks.

• Seccomp not enabled (seccomp=unconfined)

  Secure computing mode (seccomp) is a Linux kernel feature. It can restrict system calls invoked by processes to reduce the attack surface of the kernel. If seccomp=unconfined is configured when a container is started, system calls will not be restricted for the container.

  If the alarm name is Container Security Options and the alarm content contains seccomp=unconfined, it indicates that the container is started without seccomp, which poses risks.

  NOTE:

  If seccomp is enabled, permissions will be verified for every system call. The verifications will probably affect services if system calls are frequent. Before you decide whether to enable seccomp, you are advised to test-enable it and analyze the impact on your services.

• Container privilege escalation (no-new-privileges:false)

  Processes can escalate permissions by running the sudo command and using SUID or SGID bits. Default container configurations do not allow privilege escalation.

  If –no-new-privileges=false is specified when a container is started, the container can escalate privileges.

  If the alarm name is Container Security Options and the alarm content contains no-new-privileges:false, it indicates that privilege escalation restriction is disabled for the container, which poses risks.

• High-risk directory mapping (mounts:[...])

  For convenience purposes, when a container is started on a server, the directories of the server can be mapped to the container. In this way, services in the container can directly read and write resources on the server. However, this mapping incurs security risks. If any critical directory in the server OS is mapped to the container, improper operations in the container will probably damage the server OS.

  HSS reports an alarm if it detects that a critical server path (/boot, /dev, /etc, /sys, and /var/run) is mounted during container startup.

  If the alarm name is Container Mount Point and the alarm content contains mounts:[{"source":"xxx","destination":"yyy"...], it indicates that a file path mapped to the container is unsafe. In this case, check for risky directory mappings. You can configure the mount paths that are considered secure in the container information collection policy.

  NOTE:

  Alarms will not be triggered for the files that need to be frequently accessed by Docker containers, such as /etc/hosts and /etc/resolv.conf.

• Startup of containers in the host namespace

  The namespace of a container must be isolated from that of a server. If a container and a server use the same namespace, the container can access and modify the content on the server, which incurs container escape risks. To prevent such problems, HSS checks the container PID, network, and whether the container namespace is host.

  If the alarm name is Container Namespace and the alarm content contains Container PID Namespace Mode, Container IPC Namespace Mode, or Container Network Namespace Mode, it indicates that a container whose namespace is host is started. In this case, check the container startup options based on the alarm information. If you are sure that the container can be trusted, you can ignore the alarm.

Container Image blocking

If a container contains insecure images specified in the Suspicious Image Behaviors, before the container is started, an alarm will be generated for the insecure images.

Suspicious command executions

• Check whether a scheduled task or an automated startup task is created or deleted by running commands or tools.
• Detect suspicious remote command execution.

Abnormal User Behavior

Abnormal or unexpected user behaviors that occur in a specific environment or system, sometimes within a short period of time, such as abnormal logins or unauthorized access. To detect and identify these abnormal behaviors, user operations need to be checked and analyzed.

Invalid accounts

Hackers can probably crack unsafe accounts on your containers and control the containers.

HSS checks suspicious hidden accounts and cloned accounts and generates alarms on them.

Brute-force attacks

Detect and report alarms for brute-force attack behaviors, such as brute-force attack attempts and successful brute-force attacks, on containers.

Detect SSH, web, and Enumdb brute-force attacks on containers.

Password thefts

Report alarms on user key theft.

Abnormal Network Access

Abnormal network access refers to exceptions that occur during network connection or data transmission and different from normal usage. These exceptions include abnormal resource usage, unauthorized access, and abnormal connections. Abnormal network access behaviors on servers may be a prelude to attacks.

Abnormal outbound connections

Report alarms on suspicious IP addresses that initiate outbound connections.

Port forwarding

Report alarms on port forwarding using suspicious tools.

Abnormal Cluster Behaviors

Abnormal cluster behaviors occur in the cluster environment, such as pod creation, execution exceptions, and user information enumeration. These exceptions may indicate that the cluster is under an attack.

Abnormal pod behaviors

Detect abnormal operations such as creating privileged pods, static pods, and sensitive pods in a cluster and abnormal operations performed on existing pods and report alarms.

User information enumerations

Detect the operations of enumerating the permissions and executable operation list of cluster users and report alarms.

Binding cluster roles

Detect operations such as binding or creating a high-privilege cluster role or service account and report alarms.

Kubernetes event deletions

Detect the deletion of Kubernetes events and report alarms.

Fileless Attacks

A fileless attack does not release malicious executable files. Instead, it writes malicious code into the system memory or registry. Because there are no malicious files used, such an attack is difficult to detect.

Fileless attacks are classified into the following types based on disk file activities:

• No file activities.

  That is, no disk files are stored or operated in disks. Generally, such attacks are initiated in the upper-layer hardware, firmware, or software layer rather than the OS.

• Indirect activities through files.

  That is, no files are stored in disks, but activities are indirectly performed through files. Malicious code is usually indirectly loaded to the memory for execution through white files. Most of such malicious code is carried by scripts, which are executed through program commands or specific mechanisms such as disk boot records.

• File activities required.

  Generally, malicious code is converted into data. Attackers exploit file-related program vulnerabilities or features to convert malicious data into malicious code for execution.

Process injection

Scan for malicious code injection into running processes and report alarms.

Dynamic library injection

Scan for the payloads injected by hijacking functions in the dynamic link library (DLL) and report alarms.

Memory file process

Scan for the behaviors of creating an anonymous malicious file that exists only in the RAM through the memfd_create system call and executing the file, and report alarms on such behaviors.

bin

/bin/ls

/bin/ps

/bin/bash

/bin/login

usr

/usr/bin/ls

/usr/bin/ps

/usr/bin/bash

/usr/bin/login

/usr/bin/passwd

/usr/bin/top

/usr/bin/killall

/usr/bin/ssh

/usr/bin/wget

/usr/bin/curl