How to analyze APT Trojans based on the threat intelligence cycle model

About the Threat Intelligence Processing Cycle Model

The term "Threat Intelligence Processing Cycle" (F3EAD) originates from the military and is the commander of all levels of the U.S. Army's main combat arms. Designed methods of organizing resources and deploying forces. The Network Emergency Response Center draws on this method and processes threat intelligence information in the following six stages:

Threat Intelligence Processing Cycle F3EAD

Threat Intelligence Processing Cycle Model 's application

Step one: Find

's "onion" deployed on the partner's public cloud server on a certain day of the month "The system alarm found a suspected Trojan horse program, so the emergency response team quickly started the emergency response process:

Relevant people and others can call the group with one click and access by phone.

The victim system is isolated for investigation.

The security system and audit logs are exported for traceability analysis.

Business system architecture and code related data preparation, intrusion breaches and affected scope to be analyzed

Second step: Positioning

Based on The audit records of the security system found that there was another *.ko file in the malicious file directory, and this file was transferred from another server through SCP.

It can be seen that the attacker first obtains the permissions of a vulnerable server, and then jumps the SCP Trojan file to machines accessible through the compromised server, including the current victim machine, and installs it. control.

Next, we will focus on analyzing this set of Trojan files. According to the naming rules of the AV manufacturer (Appendix 1), we temporarily named it "Backdoor:Linux/Rmgr!rookit", where "rmgr" comes from the Trojan code Many functions use the rmgr prefix.

2.1. Trojan files

The Trojan files we have so far are divided into four parts, and their functions are briefly described as follows:

2.2 Trojan workflow

The Trojan uses various techniques to hide itself from implantation to execution, including possible subsequent penetration activities. It is difficult to detect without a security system. At the same time, this Trojan has also done a lot of confrontation, and conventional security monitoring capabilities may not be able to detect it. A brief description of its running process is as follows:

Trojan workflow

2.3 Main functions of each part of the Trojan

1. rmgr.ko

The rootkit uses the common LKM kernel module. The main operations after this rootkit is loaded are listed below.

1) proc_create_data creates the virtual file /proc/.dot3 for subsequent interaction with the Trojan user mode process;

2) register_kprobe registers 4 kp structures:

kp_kallsyms_lookup_name\krp_alloc_pid\kp_do_exit\kp_seq_path is used to use kprobe to preemptively erase the operations on the Trojan process when the system executes these functions;

3) The above kp structure Registered processing function, fake_seq_path is used to remove the kernel process chain list;

4) When the system reads the "/proc/net/tcp" file, it is processed by fake_seq_show, Erase the Trojan network connection;

5) patch vfs_readdir in fake_sys_getdents and erase all information related to the Trojan;

6) When the system accesses Trojan-related files, it will be processed by fake_filldir, and whether the caller is operating a Trojan horse will determine whether to return the correct result;

7 ) Delete itself in the kernel module linked list, kobject_del deletes its own kernel object;

8) kthread_create creates a kernel thread dot_thread

Create the kernel module to self-start/etc/sysconfig/modules/ati_remote3.modules

Write the kernel module file /lib/modules/%s/kernel/drivers/input/misc/ati_remote3. ko

Release the rmgr_fake_libc.so file to disk

Release the rmgr_daemon file to disk and run it through call_usermodehelper_exec with the "[khelper]" process name.

2. rmgr__fake_libc.so

This shared library file is released and written to disk by the kernel rootkit. The path is /tmp/.tmp_{21 random alphanumeric characters}, used to hide the behavior of the user-mode process of the Trojan.

The function prefixed by subhook is excerpted from the open source code (Appendix 2). Please go to github for detailed functions. This article will not go into details.

Fake prefixed functions are mainly used to combat common HIDS process and command records. fork and execve are directly called through syscall without using glibc encapsulation, avoiding hooks. HIDS in glibc mode.

fake_bash_add_history disables the bash command audit function.

3. rmgr_daemon

This process is released and written to disk by rmgr.ko, the path is /tmp/.tmp_{21 random alphanumeric}. Developed by C, after compilation, upx is packed and compressed. You can directly use the open source software upx -d rmgr_daemon to unpack without special processing.

Its main functions are:

1) Monitor kernel module status and interact with kernel rootkit information;

2) Update;

3) Generate rmgr_fake_sshd, patchELF, modify the dependent dynamic library, that is, add rmgr_fake_libc.so, the function is as mentioned above;

Get the path from the kernel

Return path

patch ELF

4) Connect C2 hm2.yrnykx.com; 5) Manage rmgr_fake_sshd;

The patchELF code is excerpted from GitHub - NixOS/patchelf (Appendix 3)

4. rmgr_fake_sshd

The file is written to disk by rmgr_daemon, and the path is /tmp/.tmp_{ 21 random alphanumeric characters}, its operation is managed by rmgr_daemon.

As a backdoor, it has hard-coded PRIVATE KEY, as shown below:

Because some functions are hooked through patchELF, the command execution and other behaviors after ssh login are hidden. The rmgr_fake_sshd itself, as well as the child processes derived from ssh login, are hidden through rmgr.ko through patch kernel calls based on the aforementioned analysis.

rmgr_fake_sshd loads the hard-coded sshd_config when it starts. Please pay attention to several key configurations. Listen on the local port 26657, and rmgr_daemon connects to this port to forward the ssh command from C2. Commonly used network protocols for fitting business environments are implemented here, so that the detection logic of conventional NIDS is bypassed.

Step Three: Eliminate

This mainly refers to reinforcement to avoid being attacked by the same method. The specific methods are as follows:

Breakthrough reinforcement, patch update, and ACL reinforcement.

Operation and maintenance channel, deactivate the old account, modify the server account in the attack link, and enable two-factor authentication.

Limit the accessible system scope based on user roles.

The victim system dumps to save the virtual machine image for investigation.

Reinstall the victim system and re-release and deploy the business environment.

New system kernel module loading requires signature verification.

Step 4: Use

to complete the emergency response work. After analyzing the incident scene and documents, the key information extracted from the entire incident will be precipitated as Threat intelligence. This article reduces the content of the threat intelligence pyramid model to two parts: iocs and ttps. ttps is summarized using the att&ck matrix model. Threat Intelligence Pyramid Model

1. iocs

1) md5:

7d859a22f38f0bcd55a46bc8b67c40df

fa73b2fd914a0cfd5e7d3161af903b6c

2) c2:

hm2.yrnykx.com

2. ttps

Step 5: Analysis

As can be seen from the ttps in the previous section, the att&ck matrix cannot completely cover all the concealment methods used by this Trojan to fight against the security system.

A rough classification of its concealment (process, network, file) methods include:

C2 avoids NIDS detection through fake_sshd;

bypasses hook through patchELF libc command audit HIDS;

Use fake_bash_add_history to invalidate shell audit;

Use patch seq_show to modify the system's return of file information reading under /proc to realize Trojan-related files, processes, Concealment of network connection information;

Hide Trojan files through patch vfs_readdir;

By removing kernel process and module linked list information, avoid rookit detection tools from discovering traces of Trojans in the kernel;

It can be seen that this Trojan package has a lot of technical details to fight against security systems, but it mainly targets some old HIDS and post-mortem forensic investigation tools known on the market. It can still be discovered by kernel-mode process-derived syscall hooks and inotify cloud scanning.

The dimension of confrontation between Trojans and security systems

A complete Trojan system cannot be developed just because of a penetration intrusion. It will inevitably draw on many open source or Family code. Therefore, from the perspective of traceability, we can do code "archaeology" work, and at the same time incorporate relevant code styles and Trojan behavior into the security system feature library. Due to space limitations, we will not go into details here.

Step Six: Spread

The spread is the article itself.

Summary

In fact, the actual incident response processing sequence cannot be completely consistent with the above process. But after completing the entire process, the author believes that the security incident handling can be regarded as a successful conclusion. In fact, the F3EAD process pays more attention to the analysis to application of intelligence (improving security countermeasures capabilities), especially the iterations in the "analysis" stage.

The analysis phase (iteration) of the F3EAD cycle

From cold intelligence to implementation to the improvement of the security capabilities of our security system, this is the realization of threat intelligence of true value.

The above is the detailed content of How to analyze APT Trojans based on the threat intelligence cycle model. For more information, please follow other related articles on the PHP Chinese website!