JPWO2020236981A5 - - Google Patents

Description

More specifically, in some embodiments, a machine learning model may be trained to detect whether a particular byte stream is executable code. This machine learning model may then be run against one or more different regions, including regions typically not analyzed by conventional detection solution files, to detect executable code within one or more files. . Detected executable code may be flagged for further analysis by malware detection software, which greatly improves detection of hidden malware payloads. In some embodiments, only part of the file may be passed to the model. In some embodiments, the entire data in the file may be passed to the model.

Portable Executable (PE) File

In some embodiments, once the random forest is generated for each architecture, for every input the three models 306, 308, 310 are run simultaneously without determining the architecture associated with that input. There is In some embodiments, there is no significant delay or impact on efficiency in malware detection models leveraging the machine learning models described herein. This is negligible because, in some embodiments, each random forest model run takes, for example, O(log(n)) operations. This can be seen in FIG. FIG. 3 shows these three separate sets of random forest models 306, 308, 310 being run twice, once on bytes from the data directory 112 of the PE file 100 ( arrow 302), and then on bytes from the section body 116 of the PE file 100 (arrow 304). For arrow 302, the code probabilities for the architecture predicted by the random forest model are x86:P1, x64:P2, and .NET:P3. Probabilities P1, P2, and P3 imply the likelihood that bytes from data directory 112 are executable x86, x64, or .NET code, respectively. For arrow 304, the code probabilities for the architecture predicted by the random forest model are x86:P4, x64:P5, and .NET:P6. Probabilities P4, P5, and P6 suggest that the bytes from section 116 may be executable x86, x64, or .NET code, respectively.

As another example, runtime testing was performed by running the malware detection model on 300 .NET files. Without feature extraction, the test took 4 seconds, and with feature extraction, the test took about 6 seconds. Overall, approximately 40% of the runtime constitutes feature extraction. This increase may be considered acceptable as feature extraction represents a significant improvement in the detection of previously undetected malware.

Position independent code detection

FIG. 14 is a diagram illustrating an example of a library independent code detection system, according to some embodiments described herein. FIG. 14 illustrates how, in some embodiments, among other things, the hooking module detects attempts by suspicious code to access independent functions. In some embodiments, for example, suspicious code 1250 attempts to obtain the function of interest via static or dynamic flow: 1 ) metadata in imported module 1204 (i.e., exported header), 2) trying to find the target directory directly from the loader's internal record 1252, and 3) attempting to call the target function directly without going through the corresponding trampoline. . In any case, in some embodiments, suspicious code does not obtain the modified address of exported function code 1240 when the monitored function is loaded via the IAT table or loader. Thus, in some embodiments, calls from questionable code at runtime are not redirected to trampoline code 1246 and are not verified as calls with the loader. However, in some embodiments, even though the exported function code 1240 is used to execute the function, the call is diverted to the hooking engine's 1242 divert code 1248 . Thus, in some embodiments, the hooking engine did not complete via the standard (e.g., static/dynamic/local) flow in the detour code 1248 because the call did not trigger the trampoline code 1246. Demonstrate that. Suspicious code 1250 is therefore flagged by the system as potentially malicious. In some embodiments, bypass code 1248 represents code fragments that are executed only when the monitored function is called (either dynamically, statically, or indirectly). This occurs because the system herein modifies the function of interest. Therefore, any executable that contains trampoline code 1246 attempts to call the exported function and the bypass code is executed.

local flow

Claims (22)

A system for library position independent code detection, comprising:
one or more computer-readable storage devices configured to store a plurality of computer-executable instructions;
and one or more hardware computer processors communicatively coupled to one or more other computer-readable storage devices, the one or more hardware computer processors carrying instructions executable by a plurality of computers. to the system by executing
causing a process of implementing an import address table (IAT) entry for a monitored symbol, and implementing the IAT entry,
a process of replacing the monitored symbol address in the IAT entry of the monitored symbol with the modified address;
executing trampoline code for calls to the modified address to detect and verify calls to monitored symbols;
Redirecting the call to the modified address to the monitored symbol address,
causing a process of implementing one or more loader API functions, the process of implementing the loader API functions comprising:
modifying the one or more loader API functions to return values that lead to the trampoline code;
diverting execution of the watched symbol to a diversion code to detect and verify calls to the watched symbol;
a process of redirecting the call of the monitored symbol to the monitored symbol address;
monitoring the trampoline code and the detour code of the monitoring target symbol to determine whether a call in an executable file includes a static call, a dynamic call, or a local call; Determining whether or not a local call is included in the call from the execution file includes monitoring the detour code and determining whether the return address is the same address as the monitored symbol of the execution file. includes processing,
if the system determines that at least one call in the executable does not contain a static call, a dynamic call, or a local call, the executable is suspicious for a malware detection system; Alternatively, a system characterized by causing processing to raise a malicious flag. 2. The system of claim 1, wherein if the system determines that at least one call in the executable code does not include a static call, a dynamic call, or a local call, the at least A system characterized by classifying a call as an independent call. 2. The system of claim 1, wherein when the system determines that the call includes a static call, a dynamic call, or a local call, it classifies the call as a benign call. system to do. 2. The system of claim 1 , wherein the system classifies the executable as benign if the system determines that the calls include static calls, dynamic calls, or local calls. system to do. 2. The system of claim 1, wherein
a hooking engine including the trampoline code and the detour code;
and one or more call databases configured to store data relating to calls. 2. The system of claim 1 , wherein the dynamic call includes attempting to obtain the monitored symbol address during execution of the executable. 2. The system of claim 1 , wherein the static call includes attempting to obtain the watch target symbol address during initialization of the executable. 2. The system of claim 1 , wherein the one or more loader API functions include either or both of GetModuleHandle and GetProcAddress. 2. The system of claim 1 , wherein said at least one call is initialized by said executable using metadata obtained from a module containing said watched symbol. . 2. The system of claim 1 , wherein the at least one call is initialized by the executable using data obtained from a loader internal record. 2. The system of claim 1 , wherein the at least one call is initiated by the executable calling a watched symbol without triggering the trampoline code. A computer-implemented method for performing library position-independent code detection, the method comprising:
A process of implementing, by a computer system, an Import Address Table (IAT) entry for a monitored symbol, the process of implementing the IAT entry includes:
a process of replacing the monitored symbol address in the IAT entry of the monitored symbol with the modified address;
executing trampoline code for calls to the modified address to detect and verify static calls to monitored symbols;
a process of redirecting a call to the modified address to a monitored symbol address;
A process of implementing one or more loader API functions by the computer system, the process of implementing the loader API functions comprising:
modifying the one or more loader API functions to return values that lead to the trampoline code;
diverting execution of the monitored symbol to a diversion code to detect and verify calls to the monitored symbol;
a process of redirecting a call to the monitored symbol to the monitored symbol address;
a process of monitoring, by the computer system, the trampoline code and the diversion code of the monitored symbol to determine whether calls in an executable include static, dynamic, or local calls; The process and the process of determining whether a call from the executable file includes a local call include: Includes processing to determine whether
If the computer system determines that at least one call in the executable file does not include a static call, a dynamic call, or a local call, the computer system performs the execution for a malware detection system. flagging a file as suspicious or malicious;
A method, wherein the computer system comprises a computer processor and an electronic storage medium. 13. The method of claim 12 , wherein if the computer system determines that at least one call does not include a static call, a dynamic call, or a local call, the method comprises: and classifying the calls as independent calls. 13. The method of claim 12 , wherein the method classifies the call as a benign call if the computer system determines that the call comprises a static call, a dynamic call, or a local call. A method, comprising processing. 13. The method of claim 12 , wherein the method classifies the executable as benign if the computer system determines that the calls include static, dynamic, or local calls. A method, comprising processing. 13. The method of Claim 12 , wherein the trampoline code and the diversion code comprise one or more portions of a hooking engine, the hooking engine configured to store data associated with the call. connected to a calling database. 13. The method of claim 12 , wherein the dynamic invocation includes attempting to obtain the monitored symbol address during execution of the executable. 13. The method of claim 12 , wherein the static call includes attempting to obtain the watch target symbol address during initialization of the executable. 13. The method of claim 12 , wherein the one or more loader API functions include either or both of GetModuleHandle and GetProcAddress. 13. The method of claim 12 , wherein said at least one call is initialized by said executable using metadata obtained from a module containing said watched symbol. . 13. The method of claim 12 , wherein the at least one call is initialized by the executable using data obtained from a loader internal record. 13. The method of claim 12 , wherein the at least one call is initiated by the executable calling a watched symbol without triggering the trampoline code.

Images