Memory horse detection method and device, electronic equipment and readable medium

Abstract

The invention relates to a memory horse detection method and device, electronic equipment and a readable medium, and the method comprises the steps: monitoring a call event in a system, and determining a suspicious class on a JVM (Java Virtual Machine) which is subjected to abnormal call under the condition that abnormal call is detected; decompiling the suspicious class to obtain a Java source code of the suspicious class; the initial score of the Java source code on each evaluation dimension is output through a preset language model, and each evaluation dimension is a plurality of dimensions used for evaluating whether memory horse features exist in the code or not; and performing comprehensive calculation on each initial score according to a preset scoring rule to obtain a total evaluation score, and determining a memory horse detection result of the suspicious class through the total evaluation score. According to the method, after the abnormal calling behavior of the system is detected, the suspicious class is found out, then the Java source code of the suspicious class is evaluated from multiple dimensions, whether the memory horse features exist in the suspicious class or not is determined, and the problem that the memory horse features in the Java class cannot be comprehensively detected is solved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a memory horse detection method, device, electronic device and readable medium. Background Art

[0002] With the widespread application of Java language in enterprises, the detection of Java memory hacking (techniques that modify Java bytecode at runtime to achieve malicious purposes) has received more and more attention. Existing memory hacking detection methods are mainly based on feature extraction and matching. However, due to the high concealment, dynamics and variability of memory hacking, this method cannot adapt to the rapid mutation of memory hacking, resulting in the inability to fully detect memory hacking features in Java classes during the detection process.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The present application provides a memory horse detection method, device, electronic device and readable medium to solve the above-mentioned technical problem of "it is impossible to fully detect the memory horse features in the Java class during the detection process".

[0005] According to one aspect of an embodiment of the present application, the present application provides a memory horse detection method, including: monitoring call events in a system, and when an abnormal call is detected, determining a suspicious class on the JVM where the abnormal call occurs; decompiling the suspicious class to obtain the Java source code of the suspicious class; outputting the initial score of the Java source code on each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions for evaluating whether there are memory horse features in the code; comprehensively calculating each initial score according to a preset scoring rule to obtain a total evaluation score, and determining the memory horse detection result for the suspicious class through the total evaluation score.

[0006] Optionally, monitoring call events in the system includes: determining the type of exception to be monitored, and writing an eBPF program according to the exception type, wherein the exception type is the type of abnormal behavior occurring during system operation; loading the eBPF program into the kernel space of the system to capture system call events through the eBPF program; obtaining target behavior baseline data, wherein the target behavior baseline data is behavior information during normal system calls; and identifying the captured system call events according to the target behavior baseline to determine whether the system call event is a normal call.

[0007] Optionally, the captured system call event is identified according to the target behavior baseline data to determine whether the system call event is a normal call, including: obtaining a process identifier corresponding to the system call event; extracting target behavior information corresponding to the process identifier from the target behavior baseline data; obtaining behavior indicators of the system call event; and determining whether the system call event is a normal call based on the behavior characteristics and the target behavior information.

[0008] Optionally, determining a suspicious class on the JVM where the abnormal call occurs includes: determining the JVM where the abnormal call occurs; obtaining a class list of loaded classes on the JVM; traversing each class in the class list, and finding suspicious classes in the class list by analyzing the class name, bytecode, source and dynamic behavior of each class.

[0009] Optionally, the initial scores of the Java source code in each evaluation dimension are output through a preset language model, including: extracting features of the Java source code to obtain code features; splicing the code features with the Java source code according to an instruction template to obtain input information; inputting the input information into the preset language model, and the preset language model outputs the initial scores of the Java source code in each evaluation dimension.

[0010] Optionally, the various initial scores are comprehensively calculated according to preset scoring rules to obtain a total evaluation score, including: extracting weight values ​​corresponding to various evaluation dimensions from the preset scoring rules; multiplying the initial score of each evaluation dimension by the weight value to obtain a comprehensive score on each flatness dimension; and adding up the various comprehensive scores to obtain a total evaluation score.

[0011] Optionally, the memory horse detection result of the suspicious class is determined by evaluating the total score, including: comparing the total evaluation score with a preset score range to obtain a comparison result, wherein the preset score range includes different score ranges corresponding to each degree of suspicion; determining the degree of suspicion of the suspicious class according to the comparison result; generating alarm information for the suspicious class according to the degree of suspicion, and using the alarm information as the memory horse detection result of the suspicious class.

[0012] According to another aspect of an embodiment of the present application, the present application provides a memory horse detection device, including: a monitoring module, which is used to monitor call events in the system, and when an abnormal call is detected, determines the suspicious class on the JVM where the abnormal call occurs; a decompilation module, which is used to decompile the suspicious class to obtain the Java source code of the suspicious class; a processing module, which is used to output the initial score of the Java source code on each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions used to evaluate whether there are memory horse features in the code; a calculation module, which is used to comprehensively calculate each initial score according to a preset scoring rule to obtain a total evaluation score, and determine the memory horse detection result for the suspicious class through the total evaluation score.

[0013] According to another aspect of an embodiment of the present application, the present application provides an electronic device, including a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, the memory and the processor communicate through the communication bus and the communication interface, and the steps of the above method are implemented when the processor executes the computer program.

[0014] According to another aspect of an embodiment of the present application, the present application also provides a computer-readable medium having a non-volatile program code executable by a processor, and the program code enables the processor to execute the above method.

[0015] The above technical solution provided by the embodiment of the present application has the following advantages compared with the related art:

[0016] The present application adopts a memory horse detection method, including: monitoring call events in the system, and determining the suspicious class on the JVM where the abnormal call occurs when an abnormal call is detected; decompiling the suspicious class to obtain the Java source code of the suspicious class; outputting the initial score of the Java source code in each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions used to evaluate whether there is a memory horse feature in the code; comprehensively calculating each initial score according to a preset scoring rule to obtain a total evaluation score, and determining the memory horse detection result of the suspicious class through the total evaluation score. After detecting that the system has abnormal call behavior, the suspicious class is first found, and then the Java source code of the suspicious class is evaluated from multiple dimensions, and whether there is a memory horse feature in the suspicious class is determined based on multiple dimensions, thereby solving the problem of being unable to fully detect the memory horse features in the Java class. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0019] Figure 1 A flowchart of an optional memory horse detection method provided according to an embodiment of the present application;

[0020] Figure 2 A block diagram of an optional memory horse detection device provided according to an embodiment of the present application;

[0021] Figure 3 A schematic diagram of an optional electronic device structure provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0023] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application and have no specific meaning. Therefore, "module" and "component" can be used interchangeably.

[0024] With the widespread application of Java language in enterprises, the detection of Java memory hacking (techniques that modify Java bytecode at runtime to achieve malicious purposes) has received more and more attention. Existing memory hacking detection methods are mainly based on feature extraction and matching. However, due to the high concealment, dynamics and variability of memory hacking, this method cannot adapt to the rapid mutation of memory hacking, resulting in the inability to fully detect memory hacking features in Java classes during the detection process.

[0025] In order to solve the problems mentioned in the background technology, according to one aspect of the embodiment of the present application, a memory horse detection method is provided, such as Figure 1 As shown, including:

[0026] Step 101, monitoring call events in the system, and when an abnormal call is detected, determining a suspicious class on the JVM where the abnormal call occurs;

[0027] Step 103, decompile the suspicious class to obtain the Java source code of the suspicious class;

[0028] Step 105: outputting the initial score of the Java source code on each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions for evaluating whether there is a memory horse feature in the code;

[0029] Step 107, comprehensively calculate each initial score according to the preset scoring rule to obtain an evaluation total score, and determine the memory horse detection result for the suspicious class according to the evaluation total score.

[0030] This application is mainly used in the security protection scenarios of software systems developed in Java language, and detects and defends against Java memory horse mining from multiple dimensions in an intelligent way.

[0031] When an abnormality is detected in a call event in the system, the classes on the JVM (Java Virtual Machine) are analyzed to find suspicious classes, and then model recognition is performed on the Java source code of the suspicious classes to identify whether there are memory horse features in the suspicious classes.

[0032] As an optional embodiment, monitoring call events in a system includes: determining an exception type to be monitored, and writing an eBPF program according to the exception type, wherein the exception type is the type of abnormal behavior occurring during system operation; loading the eBPF program into the kernel space of the system to capture system call events through the eBPF program; obtaining target behavior baseline data, wherein the target behavior baseline data is behavior information during normal system calls; and identifying the captured system call events according to the target behavior baseline to determine whether the system call event is a normal call.

[0033] The target behavior baseline refers to the normal pattern of system calls and network behaviors collected and recorded when the system is operating normally. Obtaining the target behavior baseline data can be used to detect abnormal behavior.

[0034] For example, we can use bpf_get_current_pid_tgid() to get the process ID and thread ID. We can use bpf_get_current_comm() to get the process name. For execve() calls, we can use bpf_probe_read_user() to read the command line arguments. For network-related calls, we can collect IP address and port information. We can use BPF map to store the collected data, with the key being the process ID and the value being a structure containing the above information.

[0035] For example, you can use the bpf_prog_load() function of the libbpf library to load the eBPF program, and use bpf_map__fd() to get the file descriptor of the BPF map; use the poll() function to listen to the perf buffer event. When the event arrives, read the data from the BPF map and convert the data into a structured format (such as JSON), including timestamp, process ID, system call type and other information, and then use the target behavior baseline data to make an abnormal judgment on the event information.

[0036] In addition, the eBPF program will continue to monitor DNS (Domain Name System) queries. If frequent and unusual DNS queries are detected, especially queries for suspicious domain names, they will still be marked as abnormal behavior. At this time, subsequent processing will still be carried out according to the abnormal call. This monitoring can help detect potential threats at the network level, such as malware trying to connect to its command and control server.

[0037] eBPF (extended Berkeley Packet Filter) is a powerful kernel technology that allows users to run user-defined code in the kernel, thereby efficiently monitoring and analyzing the system in real time. When capturing events, the eBPF program can record the process ID, target address, port, data volume, and other information that calls these system calls, and send this information to user space for processing or logging. With eBPF, users can insert small pieces of code into any point of the operating system for data collection, security monitoring, performance analysis, etc.

[0038] This application uses eBPF technology to continuously monitor system call behavior, especially calls related to process creation and network communication. Once an abnormal call is detected, the Java process is deeply analyzed by injecting Java Agent. Using eBPF technology can achieve efficient and low-interference system call and kernel event monitoring, providing additional contextual information for detection while minimizing the performance impact on the target system.

[0039] Using eBPF technology for monitoring also includes the following benefits: eBPF runs in kernel space and can perform high-frequency monitoring and data collection with very low overhead; eBPF programs are verified to ensure that they will not cause system crashes or security vulnerabilities; eBPF supports dynamic loading and unloading of monitoring programs, and users can adjust the monitoring logic as needed.

[0040] This application uses Java Agent technology to achieve dynamic bytecode enhancement of the target program, combined with real-time decompilation and analysis, and can detect memory horses generated or modified at runtime, which is impossible to achieve with static analysis methods.

[0041] First, locate the target Java process where the abnormal calling behavior is located, including obtaining the parent process ID and parent process command line of the target Java process, and then inject the pre-prepared Agent JAR into the target Java process through the Java Instrumentation API (Application Programming Interface). The Agent JAR is embedded in the Java application in a specific way and can execute additional code when the Java program is running, so as to monitor method calls, modify class bytecodes, and collect runtime data.

[0042] The eBPF system call monitoring module provided in this application is mainly composed of the following components: eBPF program: runs directly in the kernel space and is responsible for capturing system call events; user space program: is responsible for loading the eBPF program, collecting and analyzing data; behavior baseline database: stores normal behavior patterns; anomaly detection engine: analyzes captured events and identifies abnormal behaviors.

[0043] The eBPF program monitors system call behavior. When an abnormal call is detected, the Agent JAR is injected into the Java process for in-depth analysis. This combines low-level system monitoring with high-level application monitoring to provide powerful security protection and problem diagnosis capabilities.

[0044] As an optional embodiment, the captured system call event is identified according to the target behavior baseline data to determine whether the system call event is a normal call, including: obtaining a process identifier corresponding to the system call event; extracting target behavior information corresponding to the process identifier from the target behavior baseline data; obtaining behavior indicators of the system call event; and determining whether the system call event is a normal call based on the behavior characteristics and the target behavior information.

[0045] For each process of a system call event, corresponding behavior indicators are obtained, including: process ID (i.e., process identifier), system call type, and parameters, etc., and then the behavior baseline database (i.e., target behavior baseline data) is queried to obtain the normal behavior model of the process (i.e., target behavior information). By comparing the two, it is possible to determine whether the behavior of the current process is normal. The behavior baseline database includes a variety of pre-built normal behavior models of each process.

[0046] Model construction in the behavioral baseline database includes the initial learning phase, statistical model construction, and baseline update mechanism.

[0047] The initial learning phase includes: setting a learning time window (such as 7 days); during this period, recording all observed system call patterns; for each process, recording the following information: common system call sequences, system call frequencies, typical command line parameters, common file access patterns, and normal network connection patterns.

[0048] The construction of statistical models includes: for each process, calculating the following statistical indicators: the average frequency and standard deviation of each system call, the Markov chain model of the system call sequence, the n-gram model of the command line parameters, and the frequency distribution of file access and network connections; using KDE (Kernel Density Estimation) to create a probability distribution model for continuous variables (such as system call interval time).

[0049] The baseline update mechanism includes: setting an update cycle (such as weekly); in each update cycle, calculating the deviation of the newly observed behavior from the existing baseline, and if the deviation is within a predetermined threshold (such as 3 standard deviations), updating the baseline model, using an exponential moving average (EMA) to smooth the update and avoid sudden changes; configuring the anomaly detection algorithm.

[0050] Anomaly detection includes the following four aspects:

[0051] (1) Frequency anomaly detection: Calculate the system call frequency within the current time window (such as 1 minute); use the Z-score method to detect anomalies and record the degree of anomaly.

[0052] (2) Sequence anomaly detection: Use a sliding window (such as the last 10 system calls) to construct a sequence; calculate the probability of the sequence in the Markov chain model; if the probability is lower than a threshold (such as 0.01), mark it as an anomaly and record the degree of anomaly.

[0053] (3) Parameter anomaly detection: Apply the n-gram model to the command line parameters; calculate the perplexity of the parameter sequence; if the perplexity is higher than the threshold, mark it as an anomaly and record the degree of anomaly.

[0054] (4) Context-dependent detection: Check the context of the system call (such as file path, network address); use a pre-defined rule set (such as a sensitive file list, a suspicious IP address list) for matching; if the match is successful, increase the anomaly score.

[0055] Assign weights to the above four anomaly types, such as frequency anomaly: 0.3, sequence anomaly: 0.4, parameter anomaly: 0.2, context-related: 0.1, and then calculate the total score, total score = Σ(anomaly type weight * abnormality degree of this type). If the total score exceeds the predetermined threshold (such as 0.7), an abnormal behavior alarm is triggered.

[0056] As an optional embodiment, determining a suspicious class on a JVM where an abnormal call occurs includes: determining the JVM where the abnormal call occurs; obtaining a class list of loaded classes on the JVM; traversing each class in the class list, and finding suspicious classes in the class list by analyzing the class name, bytecode, source, and dynamic behavior of each class.

[0057] Specifically, get all loaded classes, obtain the class list, traverse the class list, and filter and analyze each class in the class list according to the class name: check whether the class name contains encrypted strings or obfuscation features. For example, class names containing random characters or encrypted strings (such as a1b2c3d4) may indicate that these classes are obfuscated, which is common in malware or unauthorized code; check whether the package name is uncommon or suspicious, such as package names containing uncommon prefixes or names, especially those that do not belong to known libraries or applications.

[0058] In addition to the class name, you can further screen suspicious classes through bytecode, source, and dynamic behavior analysis, including: Check the bytecode of the class: analyze the bytecode of the class to find signs of malicious code or unauthorized modification; Check the source of the class: confirm the source of the class file (such as loading from a JAR package) to identify whether it comes from a trustworthy source; Dynamic behavior analysis: monitor the behavior of these classes at runtime to observe whether there are any abnormal operations (such as unauthorized file access and network communication).

[0059] For example, Java Agent technology is used to register a class loading event listener through the Instrumentation API; parameter settings: monitoring scope: exclude Java core classes and common third-party libraries, monitoring threshold: the number of newly loaded classes per second > 10 triggers a deep inspection; the implementation steps include: implementing the Class File Transformer interface, recording the information of each loaded class in the transform method, and using the add Transformer method to register the transformer; detecting that Tomcat's WebappClass Loader has loaded multiple new classes in a short period of time; if the number of newly loaded classes exceeds the threshold (10 / second), a deep inspection is triggered and the newly loaded class is treated as a suspicious class.

[0060] Class loading analysis helps detect malicious classes or unauthorized code loaded in the JVM, which is critical to protecting applications from attacks and ensuring system security; ensuring that only authorized and verified classes are loaded helps to comply with compliance requirements for software use and release. By monitoring class loading, potential performance issues such as excessive class loading or unnecessary class loading can be identified.

[0061] After finding the suspicious class, use ASM (Abstract Syntax Tree Manipulation) or Javassist library to extract the bytecode of the suspicious class. ASM is a Java bytecode manipulation framework that can analyze, modify, and generate bytecode. Using the ASM library, you can easily access and manipulate the bytecode of the class, traverse the bytecode structure of the class, and extract relevant information, such as class name, method, and field.

[0062] Use a decompilation tool such as CFR (Class File Reader) to convert the bytecode into Java source code. Bytecode decompilation is a method of analyzing Java programs. By converting Java bytecode back into readable Java source code, it is easier to understand and analyze the behavior of the program during subsequent model recognition.

[0063] This application integrates multi-level detection at the bytecode level, system call level, and network behavior level, and significantly improves the accuracy and reliability of detection through information fusion and cross-validation.

[0064] As an optional embodiment, the initial scores of the Java source code in each evaluation dimension are outputted through a preset language model, including: extracting features of the Java source code to obtain code features; splicing the code features with the Java source code according to an instruction template to obtain input information; inputting the input information into the preset language model, and the preset language model outputs the initial scores of the Java source code in each evaluation dimension.

[0065] You can use AST (abstract syntax code tree) to analyze Java source code, including the following code analysis: package name and class name, import statement list, method name and parameter list, field name and type, reflection API usage, dynamic class loading operations, network operation related code, file operation related code, system command execution related code, encryption / decryption operations, Base64 encoding / decoding operations.

[0066] Extract code features, including: using the Java Parser library to parse the source code to generate AST; traversing AST; extracting relevant features in the visitor method; converting the extracted code features into structured data (such as JSON format).

[0067] Code features include but are not limited to: class name, inheritance relationship, key methods, sensitive operations, and parameter names.

[0068] The preset language model provided in this application can be Code BERT or GPT-4.

[0069] The decompiled source code and extracted features are spliced ​​according to the instruction template, and then input into the preset language model for recognition to obtain the recognition result given by the model.

[0070] For example, an instruction template provided by the present application is: "Analyze the following Java code to determine whether there are memory horse features, with special attention to [feature list]", where "[feature list]" is a fill-in area for code features.

[0071] This application uses advanced large language models (such as GPT-4) to perform deep semantic understanding of Java bytecode, which can capture complex and hidden malicious code patterns that are difficult to identify with traditional methods.

[0072] As an optional embodiment, the various initial scores are comprehensively calculated according to preset scoring rules to obtain a total evaluation score, including: extracting weight values ​​corresponding to various evaluation dimensions from the preset scoring rules; multiplying the initial score of each evaluation dimension by the weight value to obtain a comprehensive score on each flatness dimension; and adding up the various comprehensive scores to obtain a total evaluation score.

[0073] Specifically, the evaluation dimensions include but are not limited to the frequency of reflection API usage, dynamic class loading operations, suspicious network operations, sensitive file operations, and system command execution.

[0074] The preset scoring rules include weight values ​​corresponding to each evaluation dimension, such as the weight value of reflection API usage frequency is 0.2, the weight value of dynamic class loading operation is 0.25, the weight value of suspicious network operation is 0.2, the weight value of sensitive file operation is 0.15, and the weight value of system command execution is 0.2.

[0075] The preset language model obtains the initial score of the Java source code in each evaluation dimension based on the analysis of the Java source code, multiplies the initial score of each evaluation dimension by the weight value, and then calculates the sum of each product to obtain the total evaluation score.

[0076] For example, if the initial score of reflective API usage is 1.0, the initial score of dynamic class loading is 1.0, the initial score of suspicious network operations is 0.8, the initial score of sensitive file operations is 0.5, and the initial score of system command execution is 1.0, then the comprehensive score of reflective API usage is 0.2*1.0=0.2, the comprehensive score of dynamic class loading is 0.25*1.0=0.25, the comprehensive score of suspicious network operations is 0.2*0.8=0.16, the comprehensive score of sensitive file operations is 0.15*0.5=0.075, and the comprehensive score of system command execution is 0.2*1.0=0.2, then the total evaluation score of the entire suspicious class is 0.2+0.25+0.16+0.075+0.2=0.885.

[0077] As an optional embodiment, the memory malware detection result of a suspicious class is determined by evaluating the total score, including: comparing the total evaluation score with a preset score range to obtain a comparison result, wherein the preset score range includes different score ranges corresponding to each degree of suspicion; determining the degree of suspicion of the suspicious class based on the comparison result; generating alarm information of the suspicious class based on the degree of suspicion, and using the alarm information as the memory malware detection result of the suspicious class.

[0078] The preset score range can be set according to actual conditions, and this application does not limit the specific score range.

[0079] For example, (0, 0.3] is used as a non-suspicious score interval, (0.3, 0.5] is used as a low-suspicious score interval, (0.5, 0.7] is used as a moderately suspicious score interval, and (0.7, 1] is used as a highly suspicious score interval. If the total evaluation score obtained in the above embodiment is 0.885, the suspicion level of the suspicious class is highly suspicious.

[0080] Generate suspicious class alarm information based on the degree of suspicion. The alarm information may include the detection information, including the detection time, suspicious class name and location, suspicious feature summary, large language model analysis results, scoring details, and recommended response measures. The scoring details include the evaluation score of the suspicious class and the degree of suspicion.

[0081] In addition, the alarm information also includes detailed information of the suspicious class, including: alarm reason, tool information (Webshell management tool (such as Ice Scorpion, Ant Sword, Cleaver, etc.)), command line, process path, process ID, parent process command line, parent process file path, parent process ID and process chain.

[0082] After the user receives the alarm information, he or she can give user feedback, optimize the preset language model, learn from each detection result, continuously update and optimize its detection model, and improve the ability to identify new and variant memory horses.

[0083] The response actions in the alert message may include immediately isolating the affected Tomcat server, saving memory snapshots and system logs for further analysis, checking for vulnerabilities in the web application, especially the file upload function, updating security patches for all servers, and reviewing and strengthening network access control policies.

[0084] This application uses eBPF technology to monitor the Java system level. When the system call behavior is found to be abnormal, the running Java class is further decompiled by bytecode enhancement and injection agent; then, the decompiled Java class is analyzed by the trained large language model, and the code structure, call relationship, operator usage and other information of the Java class are analyzed to determine whether it has the characteristics of a memory horse. If the model determines that it is a memory horse, the corresponding alarm information is fed back to the operation and maintenance personnel, and the operation and maintenance personnel perform corresponding security protection according to the alarm information.

[0085] The present application adopts a memory horse detection method, including: monitoring call events in the system, and determining the suspicious class on the JVM where the abnormal call occurs when an abnormal call is detected; decompiling the suspicious class to obtain the Java source code of the suspicious class; outputting the initial score of the Java source code in each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions used to evaluate whether there is a memory horse feature in the code; comprehensively calculating each initial score according to a preset scoring rule to obtain a total evaluation score, and determining the memory horse detection result of the suspicious class through the total evaluation score. After detecting that the system has abnormal call behavior, the suspicious class is first found, and then the Java source code of the suspicious class is evaluated from multiple dimensions, and whether there is a memory horse feature in the suspicious class is determined based on multiple dimensions, thereby solving the problem of being unable to fully detect the memory horse features in the Java class.

[0086] According to another aspect of the embodiment of the present application, the present application provides a memory horse detection device, such as Figure 2 As shown, including:

[0087] The monitoring module 202 is used to monitor the call events in the system, and when an abnormal call is detected, determine the suspicious class on the JVM where the abnormal call occurs;

[0088] A decompiling module 204 is used to decompile the suspicious class to obtain the Java source code of the suspicious class;

[0089] A processing module 206 is used to output an initial score of the Java source code on each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions used to evaluate whether there is a memory horse feature in the code;

[0090] The calculation module 208 is used to perform comprehensive calculations on the initial scores according to the preset scoring rules to obtain the total evaluation score, and determine the memory horse detection result for the suspicious class according to the total evaluation score.

[0091] It should be noted that the monitoring module 202 in this embodiment can be used to execute step 101 in the embodiment of the present application, the decompilation module 204 in this embodiment can be used to execute step 103 in the embodiment of the present application, the processing module 206 in this embodiment can be used to execute step 105 in the embodiment of the present application, and the calculation module 208 in this embodiment can be used to execute step 107 in the embodiment of the present application.

[0092] Optionally, the monitoring module 202 includes:

[0093] A determination submodule is used to determine the type of exception to be monitored and write an eBPF program according to the exception type, wherein the exception type is the type of abnormal behavior that occurs during the operation of the system;

[0094] The loading submodule is used to load the eBPF program into the kernel space of the system to capture system call events through the eBPF program;

[0095] The acquisition submodule is used to acquire target behavior baseline data, wherein the target behavior baseline data is the behavior information when the system is called normally;

[0096] The identification submodule is used to identify the captured system call event according to the target behavior baseline and determine whether the system call event is a normal call.

[0097] Optionally, the identification submodule is also used to obtain a process identifier corresponding to the system call event; extract target behavior information corresponding to the process identifier from the target behavior baseline data; obtain behavior indicators of the system call event; and determine whether the system call event is a normal call based on the behavior characteristics and the target behavior information.

[0098] Optionally, the monitoring module 202 is also used to obtain a class list of loaded classes on the JVM; traverse each class in the class list, and find suspicious classes in the class list by analyzing the class name, bytecode, source and dynamic behavior of each class.

[0099] Optionally, the processing module 206 is also used to extract features from the Java source code to obtain code features; splice the code features with the Java source code according to the instruction template to obtain input information; input the input information into a preset language model, and the preset language model outputs the initial score of the Java source code in each evaluation dimension.

[0100] Optionally, the calculation module 208 is also used to extract weight values ​​corresponding to each evaluation dimension from preset scoring rules; multiply the initial score of each evaluation dimension by the weight value to obtain a comprehensive score on each flatness dimension; and add up each comprehensive score to obtain a total evaluation score.

[0101] Optionally, the calculation module 208 is also used to compare the total evaluation score with a preset score range to obtain a comparison result, wherein the preset score range includes different score ranges corresponding to each degree of suspicion; determine the degree of suspicion of the suspicious class according to the comparison result; generate alarm information for the suspicious class according to the degree of suspicion, and use the alarm information as the memory horse detection result of the suspicious class.

[0102] It should be noted here that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments.

[0103] According to another aspect of the embodiments of the present application, the present application provides an electronic device, such as Figure 3 As shown, it includes a memory 301, a processor 303, a communication interface 305 and a communication bus 307. The memory 301 stores a computer program that can be run on the processor 303. The memory 301 and the processor 303 communicate through the communication interface 305 and the communication bus 307. When the processor 303 executes the computer program, the steps of the above method are implemented.

[0104] The memory and processor in the above electronic device communicate via a communication bus and a communication interface. The communication bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus may be divided into an address bus, a data bus, a control bus, etc.

[0105] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0106] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0107] According to another aspect of the embodiments of the present application, a computer-readable medium having a non-volatile program code executable by a processor is provided.

[0108] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0109] When the embodiments of the present application are specifically implemented, reference may be made to the above-mentioned embodiments, which have corresponding technical effects.

[0110] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application, or a combination thereof.

[0111] For software implementation, the technology described herein can be implemented by a unit that performs the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0112] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0113] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0114] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0115] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0116] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0117] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk. It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, article or device. Without more constraints, an element defined by the phrase "comprising a..." does not exclude the existence of other identical elements in the process, method, article or apparatus comprising the element.

[0118] The above description is only a specific implementation of the present application, so that those skilled in the art can understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest range consistent with the principles and novel features applied for herein.

Claims

1. A memory horse detection method, characterized in that: include: Monitoring call events in the system, and when an abnormal call is detected, determining a suspicious class on the JVM where the abnormal call occurs; Decompiling the suspicious class to obtain a Java source code of the suspicious class; Outputting the initial score of the Java source code on each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions for evaluating whether there is a memory horse feature in the code; The initial scores are calculated comprehensively according to the preset scoring rules to obtain a total evaluation score, and the memory horse detection result of the suspicious class is determined by the total evaluation score.

2. The method according to claim 1, characterized in that The call events in the monitoring system include: Determine the exception type to be monitored, and write an eBPF program according to the exception type, wherein the exception type is the type of abnormal behavior that occurs during system operation; Loading the eBPF program into the kernel space of the system to capture system call events through the eBPF program; Acquire target behavior baseline data, wherein the target behavior baseline data is behavior information when the system is normally called; The captured system call event is identified according to the target behavior baseline to determine whether the system call event is a normal call.

3. The method according to claim 2, characterized in that The step of identifying the captured system call event according to the target behavior baseline data and determining whether the system call event is a normal call includes: Obtaining a process identifier corresponding to the system call event; extracting target behavior information corresponding to the process identifier from the target behavior baseline data; Obtaining behavior indicators of the system call event; Determine whether the system call event is a normal call according to the behavior feature and the target behavior information.

4. The method according to claim 1, characterized in that: The determining of the suspicious class on the JVM where the abnormal call occurs includes: Determine the JVM where the abnormal call occurs; Get a class list of loaded classes on the JVM; Each class in the class list is traversed, and the suspicious class in the class list is found by analyzing the class name, bytecode, source and dynamic behavior of each class.

5. The method according to claim 1, characterized in that Outputting the initial scores of the Java source code on various evaluation dimensions through a preset language model includes: Performing feature extraction on the Java source code to obtain code features; Splicing the code feature with the Java source code according to the instruction template to obtain input information; The input information is input into the preset language model, and the preset language model outputs an initial score of the Java source code on each evaluation dimension.

6. The method according to claim 1, characterized in that The initial scores are calculated comprehensively according to the preset scoring rules to obtain the total evaluation score, including: Extracting weight values ​​corresponding to each of the evaluation dimensions from the preset scoring rules; Multiplying the initial score of each evaluation dimension by the weight value to obtain a comprehensive score on each flatness dimension; Add up the various comprehensive scores to obtain the total evaluation score.

7. The method according to claim 1, characterized in that The determining of the memory horse detection result of the suspicious class by the total evaluation score includes: Comparing the total evaluation score with a preset score range to obtain a comparison result, wherein the preset score range includes different score ranges corresponding to each suspicious degree; Determining the suspicious degree of the suspicious class according to the comparison result; Generate warning information of the suspicious class according to the suspicious degree, and use the warning information as the memory horse detection result of the suspicious class.

8. A memory horse detection device, characterized in that: include: A monitoring module is used to monitor call events in the system and, when an abnormal call is detected, determine a suspicious class on the JVM where the abnormal call occurs; A decompilation module, used for decompiling the suspicious class to obtain the Java source code of the suspicious class; A processing module, used to output the initial score of the Java source code on each evaluation dimension through a preset language model, wherein each evaluation dimension is a plurality of dimensions used to evaluate whether there is a memory horse feature in the code; The calculation module is used to comprehensively calculate the initial scores according to the preset scoring rules to obtain the total evaluation score, and determine the memory horse detection result of the suspicious class according to the total evaluation score.

9. An electronic device, comprising a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, and the memory and the processor communicate through the communication bus and the communication interface, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer readable medium having a non-volatile program code executable by a processor, characterized in that: The program code enables the processor to execute the method according to any one of claims 1 to 7.

Images