Comprehensive Guide to Attack Identification in Intrusion Detection Systems

Intrusion Detection

Intrusion detection helps systems combat network attacks, extending the security management capabilities of system administrators (including security auditing, monitoring, attack identification, and response), and enhancing the integrity of the information security infrastructure. It collects information from several key points in the computer network system and analyzes this information to see if there are any behaviors that violate the security policy or signs of being attacked. Intrusion detection is the last security gate for system protection, monitoring without affecting network and host performance, thus providing real-time protection against internal attacks, external attacks, and misuse.

The impact of intrusion behavior depends on the degree of damage to the information security CIA triad, business pressure, regulatory pressure, and other factors.

Hackers, without authorization, control and use our resources (including but not limited to reading and writing data, executing commands, controlling resources, etc.) to achieve various purposes. Broadly speaking, hackers use SQL injection vulnerabilities to steal data, or obtain the account password of the target domain name in the ISP to tamper with the DNS to point to a black page, or find the target’s social account, and perform unauthorized control of virtual assets on Weibo/QQ/email, all of which fall under the category of intrusion.

The scope of enterprise intrusion detection is mostly narrow: it generally refers to the behavior of hackers controlling PCs, systems, servers, and networks (including office networks and production networks).

The most common method for hackers to control host assets such as PCs and servers is to execute commands through Shell, and the action of obtaining Shell is called GetShell.

For example, obtaining a WebShell through an upload vulnerability in a web service, or directly executing commands/code using an RCE vulnerability (the RCE environment indirectly provides a Shell). Additionally, by implanting a “Trojan backdoor” in some way, and subsequently using the integrated SHELL function of the Trojan for remote control of the target, this is also quite typical.

Therefore, intrusion detection can focus on the GetShell action and the malicious behavior after GetShell is successful (to expand the results, hackers will mostly use Shell for probing, searching and stealing, and lateral movement attacks on other internal targets, these characteristics that distinguish them from good people can also be used as important features).

Some commercial products like to report some “external scanning, attack detection, and attempt behaviors” before GetShell, and call it “situational awareness,” telling enterprises that someone is “trying to attack.” In the author’s view, the practical value is not great. Many enterprises are basically under “unknown” attacks all the time, knowing that someone is “trying” to attack, if they cannot effectively act, and cannot effectively alert actions, besides consuming energy, there is not much practical value.

When we get used to “attacks” being the norm, we will solve problems in such a norm, what reinforcement strategies can be used, which can achieve normalized operations, if there are strategies that cannot be normalized, such as requiring many people to work overtime for temporary assault, then this strategy will mostly gradually disappear after a while. There is no essential difference between whether we do this strategy or not.

Similar to SQL injection, XSS, and other web attacks that do not directly GetShell, they are temporarily not considered in the narrow “intrusion detection” scope, and it is recommended to be classified into “vulnerabilities,” “threat awareness,” and other fields for further discussion. Of course, if GetShell operations are performed using SQL injection, XSS, and other entry points, we still focus on the key point of GetShell, regardless of where the vulnerability entry is.

Intrusion Detection Technology

Intrusion detection technology: Intrusion detection refers to “detecting intrusions or attempts to intrude into the system by operating on behaviors, security logs, audit data, or other information available on the network.”

Intrusion detection technology structurally includes: intrusion detection knowledge base, intrusion detection subject, intrusion detection system, and other substructures.

1. Use features, models, anomaly detection, and other means for intrusion prevention.

2. Deploy on the host to achieve blind spot-free coverage.

3. Still available in high-availability scenarios, based on anomaly heuristic rules, capturing variant intrusion methods through behavioral characteristics.

4. Can associate multiple behavioral characteristics through a time window to improve the sensitivity and accuracy of intrusion detection.

5. Discover unknown intrusion behaviors based on known behavior judgments.

Intrusion Detection System

Intrusion detection system is a structured system instance implemented according to the intrusion detection framework design requirements. It includes functions such as automated monitoring, auditing, mitigation, blocking, and event restoration of intrusion behaviors. Each intrusion detection system instance basically contains four modules: event generation, event database, event analysis engine, and event alert engine trigger. Each intrusion detection instance contains one or more modules. Depending on the enterprise environment, the database, analysis engine, and alert engine of each instance may have different degrees of unification. Each module may also be associated multiple times, crosswise, and without a fixed order to form a joint whole. (In most cases, the blocking function may affect the normal operation of the business, and it is not recommended to try it lightly.)

Intrusion Detection Instance

1. Baseline Monitoring System: A near-real-time or scheduled baseline monitoring system based on the collection, auditing, and configuration of security policy baselines. The baseline monitoring system can also be integrated into HIDS, or rely on the advanced audit function of the operating system as an engine.

Policy:

System: Included in the intrusion detection system

Framework: Included in the intrusion detection framework

2. Network Intrusion Detection System (NIDS): A network intrusion detection system based on network traffic characteristics, network traffic models, and heuristic logic for monitoring, auditing, and controlling (traditional NIDS and model-based Web IDS/WAF);

3. Host Intrusion Detection System (HIDS): A host intrusion detection system based on terminal behavior for monitoring, auditing, and controlling suspicious behaviors such as programs, executable codes, and abnormal operations of the operating system;

4. Anti-Virus System (AV): An intrusion prevention system based on the terminal for monitoring and controlling malicious programs, malicious code execution, and anti-malware (anti-Trojan, virus, worm, ransomware) behaviors;

5. Anti-Leakage System: A system based on the terminal or network for preventing, detecting, and mitigating abnormal behaviors such as abnormal or process transfer, theft, and copying of confidential information (targeting enterprise confidentiality with transparent encryption and decryption (HDLP), network behavior auditing (NDLP, behavior auditing), and untrusted device monitoring);

6. Public Stream Data Processing Engine: A data processing engine based on big data for real-time data cleaning and storage, determining the accuracy and real-time nature of alerts.

7. Public Security Information Event Management System: A system based on event processing processes for event alerting, display, and management.

8. Threat Intelligence System: The implementation subject actively obtains threat intelligence through various channels or purchases threat intelligence vendor products;

9. Malicious Sample Analysis Sandbox: A sandbox for detecting malicious files based on dynamic and static combined methods by analyzing the characteristics and behaviors of unknown files.

10. Honeypot Bait System: A system based on a combination of pseudo/real states for collecting intelligence on intruders (honeypot);

11. Other expandable intrusion detection systems for monitoring, auditing, and controlling abnormal means or processes;

• 1. Direct anomaly detection based on single-instance single-point perception
• 2. Temporal anomaly detection based on single-instance multi-point perception
• 3. Combination event detection based on multiple instance anomalies in a short time

Common Intrusion Techniques and Responses

If there is insufficient understanding of common hacker intrusion techniques, it is difficult to target effectively, and sometimes you may even fall into the trap of “political correctness.” For example, the penetration testing team says, we did action A, and you didn’t even notice, so you are not good. But the actual situation is that the scenario may not be a complete intrusion chain, and even if the action is not detected, it may not have any impact on the intrusion detection effect. Each attack vector’s harm to the company, the probability of occurrence, how to rank them, the cost of solving it, and the benefits it brings all require professional experience to support and make decisions.

Now, let’s briefly introduce the classic process in hacker intrusion tutorials (the complete process can refer to the kill chain model):

Before intruding on a target, hackers may not know enough about the target, so the first thing is often “reconnaissance,” which is collecting information to deepen understanding. For example, hackers need to know what assets the target has (domain names, IPs, services), their respective statuses, whether there are known vulnerabilities, who manages them (and how they are legally managed), and what known leaked information exists (such as passwords in social engineering databases), etc.

Once reconnaissance is complete, skilled hackers will brew and verify the feasibility of “attack vectors” one by one based on the characteristics of various assets. The following lists common attack methods and defense suggestions.

High-Risk Service Intrusion

All public services are “high-risk services” because the protocol or the open-source components that implement the protocol may have known attack methods (advanced attackers even have corresponding 0days). As long as your value is high enough, hackers have enough motivation and resources to exploit it. When you open high-risk services to the internet, facing everyone, it is equivalent to opening a “big door” for hackers.

For example, SSH and RDP are services related to operations management, designed for administrators. As long as you know the password/key, anyone can log in to the server and complete the intrusion. Hackers may obtain credentials by guessing passwords (combined with information leaks from social engineering databases, network disk searches, or brute force attacks). In fact, this type of attack is so common that hackers have long made it into fully automated worm-like tools that scan the entire internet. If a host purchased in the cloud is set with a weak password, it is often infected with a worm virus within a few minutes because there are too many automated attackers.

Perhaps your password is set very strong, but this is not a reason to continue exposing the service to the internet. We should restrict these ports, allowing only our own IP (or internal bastion host) to access, completely cutting off the possibility of hackers intruding through it.

Similarly, MySQL, Redis, FTP, SMTP, MSSQL, Rsync, etc., any service used to manage servers or databases, files, should not be open to the internet without restrictions. Otherwise, worm-like attack tools will break our services within a few minutes, even directly encrypting our data and demanding Bitcoin for extortion.

Some high-risk services have RCE vulnerabilities (remote command execution), and as long as the port is open, hackers can use existing exploits to directly GetShell and complete the intrusion.

Defense suggestions: The cost of intrusion detection for each high-risk service is high because the specific reference of high-risk services is very diverse and may not have common characteristics. Therefore, using reinforcement methods to converge attack entry points is more cost-effective. Prohibiting all high-risk ports from being open to the internet can reduce the probability of intrusion by more than 90%.

Web Intrusion

With the reinforcement of high-risk ports, many attack methods in the hacker knowledge base will fail. However, web services are the main service form of modern internet companies and cannot all be shut down. Therefore, vulnerabilities in dynamic web services written in PHP, Java, ASP, ASP.NET, Node, C, etc., become the main entry point for hacker intrusions.

For example, using the upload function to directly upload a WebShell, using the file inclusion function to directly reference and execute a remote WebShell (or code), then using the code execution function as a Shell entry to execute arbitrary commands, parsing some image, video services, uploading a malicious sample, triggering a vulnerability in the parsing library…

Application security under web services is a specialized field, and specific attack and defense scenarios and confrontations have developed very maturely. Of course, since they all use web services as entry points, intrusion behaviors will also have some commonality in a certain sense. Relatively speaking, we can more easily find some differences between hacker GetShell and normal business behavior.

For detecting intrusion traces of web services, consider collecting WAF logs, Access Logs, system calls recorded by Auditd, or Shell commands, as well as network layer response-related data, to extract the characteristics of successful attacks. It is recommended to focus our main efforts on these aspects.

0day Intrusion

According to leaked toolkits, NSA had 0day weapons for directly attacking services like Apache and Nginx in the early years. This means that opponents may not care at all about how our code and services are written, and with a 0day attack, they can GetShell without anyone knowing.

However, for intrusion detection, this is not scary: because no matter what vulnerability the opponent uses as an entry point, the Shellcode it uses and the subsequent behavior itself still have commonality. Whether Apache is attacked by a 0day vulnerability or a PHP page is exploited by a low-level code vulnerability, from the perspective of intrusion behavior, it may be exactly the same, and the intrusion detection model can still be used.

Therefore, focusing on the hacker GetShell entry and subsequent behavior may be more valuable than focusing on the vulnerability entry. Of course, specific vulnerability exploitation still needs to be followed up in practice and then verify whether its behavior meets expectations.

Office Terminal Intrusion

In most APT reports, hackers first target people (office terminals), such as sending phishing emails, tricking us into opening them, controlling our PCs, and then conducting long-term observation/scrutiny, obtaining our legitimate credentials, and then roaming the intranet. Therefore, these reports mostly focus on describing the Trojan behavior used by hackers and the similarity of family codes. Anti-APT products and solutions mostly use similar methods at the system call level of office terminals to test the behavior of “undetectable Trojans.”

Therefore, EDR products + email security gateways + behavior auditing at the office network exit + APT product sandboxes, combined, can collect corresponding data and create similar intrusion detection perception models. The most important point is that hackers like to focus on important internal infrastructure, including but not limited to AD domain controllers, email servers, password management systems, and permission management systems. Once taken down, it is equivalent to becoming the “God” of the intranet, able to do whatever they want. Therefore, for companies, important infrastructure should have targeted attack and defense reinforcement discussions, and Microsoft even issued a special reinforcement white paper for AD attack and defense.

Conclusion

Most of the ideas in this article come from public information, produced through self-study combined with work experience. If there are errors, please contact for modification.