A multi-layer joint anti-killing method of malicious code

Abstract

This application discloses a multi-layered joint anti-virus evasion method for malicious code, belonging to the field of network security technology. The method includes: on the server-side configuration side, overwriting the original communication configuration of the communication server associated with the original malicious code payload with a custom communication configuration to construct a traffic masquerading layer; on the payload data side, externally encrypting the original malicious code payload to form an encrypted wrapper layer; on the loader side, reconstructing an independent replacement loader; on the deployment topology side, constructing a deployment architecture where encrypted payload data and the replacement loader are stored separately; on the runtime execution side, when the replacement loader runs on the target host, it obtains and restores the encrypted payload data via the network and loads the restored running original malicious code payload; the running original malicious code payload initiates a network connection request to the associated communication server, and the communication server responds to the network connection request, conducting command and control communication with the target host through the traffic masquerading layer.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to a multi-layered, combined method for evading detection of malicious code. Background Technology

[0002] As network attack and defense continue to escalate, the detection and avoidance technologies for malicious code (especially remote control Trojans) are constantly evolving. Currently, mainstream security protection systems have evolved from single-dimensional static feature matching to a multi-layered comprehensive detection architecture encompassing static feature library matching, traffic fingerprinting, dynamic behavior monitoring, and heuristic scanning. These multiple detection dimensions complement and synergize with each other, making it difficult for single-dimensional countermeasures to effectively bypass the complete detection system.

[0003] Existing malware defense and evasion techniques mainly suffer from the following problems: On the one hand, the physical coupling between the payload and the loader leads to an excessively large detection scope. In traditional schemes, the encrypted malicious code payload is usually directly embedded as a byte array into the loader's source code and compiled into a single executable file. Security software can then use multi-dimensional features such as resource segment characteristics, data segment entropy values, and the ratio of code segments to data segments to make correlation judgments. Furthermore, since the loader always contains complete payload data, once this compilation pattern is marked by a signature library, all executable files generated based on the same template will be fully detected. In addition, the payload and the loader coexisting in the same executable file allows security software to complete the determination of the entire attack chain by scanning a single file.

[0004] On the other hand, existing solutions lack sufficient depth in disguising command and control communication traffic behavior. The default heartbeat intervals, Uniform Resource Locator (URI) formats, and Hypertext Transfer Protocol (HTTP) header structures of remote control frameworks exhibit clear patterns, and the default Secure Sockets Layer (SSL) certificates and communication ports are widely included by security vendors. Existing communication layer countermeasures are mainly limited to port modification or simple protocol header spoofing, making it difficult to completely disguise command and control communication as normal web page access behavior at the traffic audit level.

[0005] Furthermore, traditional loaders exhibit distinct call timing patterns for sensitive system application programming interfaces (APIs) such as memory allocation, thread creation, and memory protection, making them easily identifiable by dynamic behavior monitoring systems. Moreover, adversarial sample generation methods primarily focus on byte-level static perturbations of executable files, without addressing broader adversarial dimensions such as traffic masquerading, API call chain hiding, and payload separation deployment. Summary of the Invention

[0006] In view of this, embodiments of this application provide a multi-layered combined anti-virus evasion method for malicious code.

[0007] According to one aspect of this application, a multi-layered, combined method for evading antivirus software is provided, comprising: On the server-side configuration side, the original communication configuration of the communication server associated with the original malicious code payload is overwritten with a custom communication configuration to build a traffic masquerading layer; On the payload data side, the original malicious code payload is externally encrypted to form an encrypted wrapping layer that surrounds the original malicious code payload. On the loader side, the original loader that comes with the original malicious code payload is discarded, and an independent replacement loader is rebuilt. The import table of the replacement loader does not contain the function names of the sensitive system application programming interfaces required by the original malicious code payload. On the deployment topology side, before compiling the executable file of the replacement loader, the encrypted payload data processed by the encryption wrapping layer is physically stripped from the executable file of the replacement loader and deployed independently on a remote storage medium, forming a deployment architecture in which the encrypted payload data and the replacement loader are stored separately. On the runtime execution side, when the replacement loader is running on the target host, it obtains the encrypted payload data from the remote storage medium via the network, restores the encrypted payload data to obtain the original malicious code payload, and loads and runs the restored original malicious code payload through the replacement loader; the running original malicious code payload initiates a network connection request to the associated communication server, and the communication server responds to the network connection request and conducts command and control communication with the target host through the traffic masquerading layer.

[0008] Compared with existing technologies, this application has significant advantages: This application systematically constructs adversarial mechanisms from four dimensions: traffic layer, code layer, loading layer, and deployment architecture layer. This enhances the survivability of malicious code under static detection, traffic detection, and dynamic behavior detection. By physically separating the encrypted payload data from the executable file of the replacement loader and deploying it independently on a remote storage medium, the executable file of the replacement loader does not contain any payload data. This deployment architecture, which separates the payload from the loader, fundamentally reduces the detection surface and avoids the problem of all executable files generated from the same template becoming invalid due to a single file being marked by a signature library. The encrypted payload data is independently deployed on a remote storage medium, and the loader only retrieves it via the network at runtime and restores it in memory, without writing payload data to the disk, further reducing the risk of being captured by real-time file system monitoring. Simultaneously, the traffic masquerading layer makes command and control communication traffic appear as normal network access behavior in multiple dimensions such as port, certificate, protocol format, and behavior pattern, making it difficult for network layer detection devices to identify. In summary, this application effectively solves the problems of existing technologies, such as the easy failure of single adversarial methods, the excessive detection surface caused by the coupling of the payload and the loader, and the obvious characteristics of communication traffic.

[0009] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 The system architecture and processing flowchart of a multi-layered combined anti-virus evasion method for malicious code provided in an embodiment of this application are shown. Detailed Implementation

[0011] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0012] It should be understood that cybersecurity is essentially a contest of offense and defense. Cybersecurity is fundamentally a continuous game between attackers and defenders; security detection technologies are constantly evolving, and malicious code must evolve in parallel. If evasion techniques are not upgraded, malicious code will be quickly detected by security products, making it impossible to effectively test the target's defense capabilities in authorized testing scenarios.

[0013] This invention is proposed based on the above background, aiming to provide a systematic anti-disruption solution from multiple dimensions to cope with the current situation where multi-layered security detection systems are constantly improving their ability to detect and kill malicious code.

[0014] like Figure 1 As shown, the multi-layered anti-virus evasion method for malicious code provided in this application includes a pre-production stage and a runtime stage. The pre-production stage (payload data side, loader side, deployment topology side) is completed on the attacker's end, and the server-side configuration side is executed on a communication server controlled by the attacker; the runtime stage is executed on the target host, i.e., the runtime execution side.

[0015] Specifically, the method comprises five aspects, namely (I) to (V). The specific operations for each aspect are now explained: (i) On the server-side configuration side, the original communication configuration of the communication server associated with the original malicious code payload is overwritten with a custom communication configuration to build a traffic masquerading layer.

[0016] Specifically, by loading custom communication configuration, the default listening port of the communication server is overridden by the custom listening port parameters contained within, the default socket security certificate of the communication server is replaced by the custom socket security certificate parameters contained within, and the default communication parameters of the communication server are overridden by the communication protocol format parameters and data interaction behavior parameters between the communication server and the target host contained within, thus completing the traffic-side configuration.

[0017] For example, the communication server is a server program of the Cobalt Strike framework, and the custom communication configuration is a Malleable C2 Profile file. The custom communication configuration includes a global configuration block, an HTTP-Stager configuration block, an HTTP-GET configuration block, and an HTTP-POST configuration block.

[0018] In one feasible implementation, the configuration method for custom listening port parameters is as follows: edit the startup script of the communication server (e.g., the teamserver file), and change the default listening port parameter (e.g., the default port 50050) to the target port value (e.g., 65000 or 37533) so that the communication server listens on the target port.

[0019] In one feasible implementation, the configuration method for custom socket security certificate parameters is as follows: A custom Java keystore file (e.g., cobaltstrike.store) is generated using a key generation tool (e.g., Java's keytool), and the keystore password parameter is configured in the communication server's startup script. Specifically, when generating the certificate, the certificate's Common Name (CN) field is set to the target domain name (e.g., www.microsoft.com), the Organization (O) field is set to the target organization name (e.g., Microsoft Corporation), and the Organization Unit (OU), Location (L), Province (ST), and Country (C) fields are all set to values ​​matching the target organization information. After generating the custom certificate, the custom certificate's keystore password is synchronized to the communication server's startup script. Through this method, the certificate information presented by the communication server during the transport layer security handshake process is consistent with that of a normal organization service certificate.

[0020] In one feasible implementation, the communication protocol format parameters include at least: the request header format and response header format of the Hypertext Transfer Protocol, the Uniform Resource Locator (URL) path format, and the data transmission encoding method. The data interaction behavior parameters include at least: the heartbeat interval and jitter parameters between the communication server and the target host.

[0021] For example, the HTTP request and response header formats in the custom communication configuration are configured as follows: In the client sub-block of the http-get or http-post configuration block, the header statement is used to customize the name and value of the request header fields carried when the target host sends an HTTP request to the communication server; In the server sub-block, the header statement is used to customize the name and value of the response header fields carried when the communication server returns an HTTP response to the target host, for example, setting Content-Type to "application / javascript; charset=utf-8".

[0022] In addition, the Uniform Resource Locator (URI) path format can be configured in the following way: customize the URI path format used by the target host when requesting resources from the communication server. The URI path can be configured to a common static resource path format, such as " / jquery-3.3.1.min.js", so that the request appears as a normal access to the front-end resource library at the traffic audit level.

[0023] Similarly, the data transmission encoding method is configured in the following way: at least one of the encoding and data appending instructions is combined in a specified order to transform the transmitted data, and the final carrying location of the encoded data is specified.

[0024] For example, the heartbeat interval and jitter parameters are configured as follows: in the global configuration block of the custom communication configuration, the base interval time for the target host to send heartbeat requests to the communication server is set, and the jitter percentage is set so that the actual heartbeat interval changes randomly according to the jitter percentage based on the base interval, so that the heartbeat traffic presents a normal network behavior pattern with randomness in time distribution.

[0025] In addition to configuring the communication behavior parameters of the communication server, the custom communication configuration also includes payload type parameters.

[0026] Specifically, after starting the communication server, the payload type is set to stageless using the payload generation command on the communication server to generate an independent payload file containing complete malicious code functionality. The stageless payload type allows the target host to execute the original malicious code payload without making a secondary request to the communication server to obtain additional payload components.

[0027] Therefore, the server-side configuration, through custom ports, forged SSL certificates, custom HTTP communication formats and heartbeat behavior, and setting the payload type to a phaseless payload type, completed multi-level traffic masquerading configuration for the communication server from the transport layer to the application layer. When the communication server conducts command and control communication with the target host, by making the command and control communication server interact with the target host according to the communication mode defined in the custom communication configuration, the interaction traffic between the communication server and the target host appears as normal network application layer protocol access behavior at the traffic auditing level.

[0028] (ii) On the payload data side, the original malicious code payload is externally encrypted to form an encrypted wrapping layer that wraps around the original malicious code payload.

[0029] In one feasible implementation, the binary byte stream of the original malicious code payload is encrypted using at least one of the following encryption methods: XOR encryption algorithm, AES symmetric encryption algorithm, and memory encoder, to generate encrypted payload data for wrapping the original malicious code payload.

[0030] For example, 1) when using the XOR encryption algorithm, a preset XOR key is obtained. The XOR key is either a single byte value or a key sequence of multiple bytes. The binary byte stream of the original malicious code payload is divided into consecutive processing units. Each processing unit is then XORed with the XOR key bitwise to generate XOR ciphertext, which is one implementation of the encrypted payload data. When the XOR key is a single byte value, each byte of the original malicious code payload is XORed with the same single-byte key. The encryption and decryption processes use the same XOR key, meaning that performing the same single-byte XOR operation on the XOR ciphertext again will restore the original malicious code payload. When the XOR key is a byte sequence of length greater than 1, bytes in the byte sequence are XORed with the corresponding bytes of the original malicious code payload. After the byte sequence is processed, the process is repeated from the beginning until the entire payload is processed. To further increase the difficulty of static signature matching by antivirus software, multiple XOR encryption can be used. This involves using different XOR keys to perform multiple XOR operations on the original malicious code payload to generate multi-layered XOR encrypted ciphertext. The corresponding decryption process is performed in reverse order, using the same key sequence to restore the data layer by layer.

[0031] 2) When using the AES symmetric encryption algorithm, obtain the preset AES key and initialization vector. The AES key length can be any of 128 bits, 192 bits, or 256 bits, and the appropriate key length can be selected according to actual security requirements. The binary byte stream of the original malicious code payload is used as plaintext data. Combined with the AES key and initialization vector, encryption operations are performed according to the AES symmetric encryption algorithm to generate AES ciphertext. The AES ciphertext is one implementation of the encrypted payload data.

[0032] In one feasible implementation, AES encryption uses CBC (Cryptographic Block Chaining) mode, where each plaintext block is XORed with the previous ciphertext block before encryption, thereby increasing the randomness and resistance to analysis of the ciphertext. It should be understood that other feasible implementations may also employ other AES operating modes such as CTR or GCM mode, and this application does not impose any limitations on these.

[0033] During the decryption phase, the same AES key and initialization vector as those used in the encryption process are obtained. The AES ciphertext is taken as input, and decryption is performed according to the AES decryption algorithm to reconstruct the original malicious code payload. The AES decryption logic is pre-written in the replacement loader's source code and dynamically executed in memory during replacement loader runtime. Compared to single-byte XOR encryption, AES symmetric encryption offers higher resistance to reverse engineering and analysis. Because the ciphertext encrypted with AES exhibits a uniform statistical distribution, it effectively eliminates the fixed-byte characteristics of the original malicious code payload. Furthermore, the encryption process involves multiple rounds of nonlinear transformations, increasing the difficulty for antivirus software to reconstruct the payload content through static analysis.

[0034] 3) When using a memory encoder for encryption, the method also includes: according to the set target architecture parameters and encoding number parameters, calling the memory encoder to perform randomization encoding on the original malicious code payload to generate encoded payload data. The header of the encoded payload data contains a decoder stub, which is used to decode and restore the original malicious code payload when the encrypted payload data is restored.

[0035] For example, when using a memory encoder (such as the Shikata Ga Nai encoder), target architecture parameters and encoding iteration parameters must be specified. The target architecture parameter specifies the target platform bitness (e.g., 32-bit or 64-bit) for the encoded payload to ensure the decoder stub can adapt to the target processor's registers and instruction set. The encoding iteration parameter specifies the number of iterations to encode the original malicious code payload. Based on the target architecture parameters and encoding iteration parameters, the memory encoder performs polymorphic XOR additive feedback encoding on the original malicious code payload, generating encoded payload data. The encoded payload data includes the decoder stub and the encoded payload body, with the decoder stub located at the beginning of the encoded payload data. The decoder stub is generated by the encoder based on dynamic instruction replacement and dynamic block sorting; each generated decoder stub is different. It contains decoding logic corresponding to the encoding process, used to decode the encoded payload body layer by layer in reverse order of encoding during execution to reconstruct the original malicious code payload. The entire decoding process is completed automatically by the decoder stub, without requiring additional external decryption keys or decryption logic.

[0036] It should be understood that the XOR encryption, AES symmetric encryption, and memory encoder methods mentioned above are optional processing methods. In specific implementation, any one of these methods can be selected to process the original malicious code payload based on the security detection strength of the target host environment or the feature detection preferences of the antivirus software; alternatively, multiple methods can be combined. When using a combined processing method, the execution order of each method can be adjusted according to actual needs. For example, AES symmetric encryption can be used first to encrypt the original malicious code payload, and then XOR encryption can be applied to the encrypted data; or a memory encoder can be used first for randomization encoding, and then AES encryption can be applied to the encoded data. By flexibly selecting and combining multiple encryption or encoding methods, encrypted payload data with different feature forms can be generated, increasing the difficulty of static feature matching and thus improving the flexibility against static detection.

[0037] It should be noted that on the payload data side, the obtained encrypted payload data will be stored in the attacker's local development or compilation environment. Specifically: when using XOR encryption or AES symmetric encryption, the XOR ciphertext or AES ciphertext generated by encryption is written into the source code file of the replacement loader in the form of a byte array, as a component of the source code, to be physically stripped later on the deployment topology side; when using a memory encoder, the binary content of the encrypted payload data is also written into the source code file of the replacement loader in the form of a byte array, or saved locally on the attacker's local machine as a separate binary file (e.g., a .bin file) for use during subsequent deployment.

[0038] It should be understood that the above storage methods are all temporary intermediate storage. The encrypted payload data will subsequently undergo physical stripping on the deployment topology side and be deployed independently on remote storage media.

[0039] At this point, the payload data side has completed the external encryption processing of the original malicious code payload. Through at least one of XOR encryption, AES symmetric encryption, and a memory encoder, the original binary byte stream of the original malicious code payload is converted into encrypted payload data without a fixed feature format. The encrypted payload data is independent of the original payload, acting as an encrypted wrapping layer around it, thus hiding the static byte features of the original payload and enabling it to resist detection based on static feature matching.

[0040] (iii) On the loader side, discard the original loader that comes with the original malicious code payload and rebuild an independent replacement loader. The import table of the replacement loader does not contain the function names of the sensitive system application programming interfaces required by the original malicious code payload.

[0041] It should be noted that "discarding the original loader" means not using the loader program attached to the original malicious code payload as the final execution carrier delivered to the target host, and not copying or using the code logic or compilation artifacts of the original loader.

[0042] It should be understood that a replacement loader is a standalone executable file (EXE or DLL). The replacement loader is an independently built executable file, which can be either an EXE executable or a DLL dynamic link library. This executable file is generated by writing source code and compiling it in a compiler. The source code refers to the C / C++ source code file written by the attacker, not the loader code included with a third-party framework. This source code contains the network acquisition logic for encrypted payload data, the decryption or decryption logic corresponding to the encryption method on the payload data side, and the loading and execution logic for loading and executing the decrypted original malicious code payload in the target host's memory. The executable file is the binary executable file generated by compiling and linking the above source code using a compiler (such as the Visual Studio compiler). This file is the final carrier delivered to the target host for actual execution. Having the source code means that this solution can flexibly adjust the loader's functional logic and code structure according to the adversarial needs of the target environment, without being limited by the loader templates provided by third-party frameworks. Having the executable file means that the replacement loader can be deployed on the target host in an independent binary form, and can run directly to execute network acquisition logic, decryption or restoration logic, and loading execution logic. Moreover, the replacement loader uses a dynamic API call mechanism without an import address table, so that the import table of the executable file does not contain function names of sensitive system application programming interfaces, reducing the suspicion of static detection.

[0043] In one feasible implementation, on the loader side, when rebuilding the independent replacement loader, the method further includes: configuring the runtime library linking method to at least one of static linking or dynamic linking when compiling the replacement loader's source code, and / or configuring the code optimization options to at least one of minimizing size or maximizing runtime speed. Furthermore, without modifying the source code, the difficulty of static feature matching by the antivirus software is increased by changing the code structure characteristics of the generated executable file.

[0044] It should be noted that, in terms of implementation flexibility, the generation of encrypted payload data and the construction of the replacement loader can be regarded as two relatively independent parallel processing flows. An attacker can first generate the encrypted payload data and save it as an independent binary file, and then write and compile the loader source code; or they can first write the loader source code (with reserved decryption logic interface), and then perform encryption processing on the original payload to generate encrypted payload data; or they can do so simultaneously.

[0045] It's important to note that the encryption method used on the payload data side dictates the corresponding restoration logic that needs to be configured on the loader side. Attackers, based on the encryption method chosen on the payload data side, can write corresponding decryption logic (XOR decryption or AES decryption) in the replacement loader's source code, or configure a corresponding loading execution method (for memory encoders, configure it to jump to the decoder stub entry point for execution), and embed this into the replacement loader's executable file during compilation. Since this correspondence is determined during the compilation phase, the loader does not need to obtain additional decryption information from the payload data side at runtime; it only needs to restore the retrieved encrypted payload data based on its built-in decryption logic.

[0046] By achieving logical coordination through the "pre-agreed encryption-decryption algorithm correspondence" between the payload data side and the loader side, it can be guaranteed that the encrypted payload data can be correctly restored to the original malicious code payload after being pulled, without the need for additional interaction at the runtime data transmission level.

[0047] (iv) On the deployment topology side, before compiling the executable file of the replacement loader, the encrypted payload data after being processed by the encryption wrapping layer is physically separated from the executable file of the replacement loader and deployed independently on a remote storage medium, forming a deployment architecture in which the encrypted payload data and the replacement loader are stored separately.

[0048] Here, the encrypted payload data is deployed to the remote storage medium in at least one of the following ways: (1) Store the encrypted payload data as a file on a remote storage medium; For example, remote URL fetching (i.e., HTTP / HTTPS remote separation) can be used. Specifically, encrypted payload data can be stored on a remote HTTP or HTTPS server (such as a cloud server, CDN node, or code hosting platform controlled by the attacker) with disguised extensions such as .dat, .png, and .js. This makes it appear as a normal data file or resource file during storage and transmission, reducing the risk of being identified as a malicious payload by security devices.

[0049] The replacement loader's executable file does not contain any bytes of encrypted payload data; it only contains the network request module and the decryption execution module. The remote Uniform Resource Locator (URL) address where the encrypted payload data resides is predefined in the replacement loader's source code.

[0050] In one feasible implementation, to circumvent the static detection of plaintext URL strings by security software, the URL address can be Base64 encoded and stored in the source code of the replacement loader, and then decoded and restored at runtime to obtain the target URL.

[0051] (2) Divide the encrypted payload data into multiple data fragments and deploy them on multiple different remote storage media; For example, the encrypted payload data is divided into multiple data fragments of a preset fixed size (e.g., 1024 bytes or 4096 bytes per fragment). These data fragments are then deployed in a random order to multiple different remote storage media. These remote storage media can include different Uniform Resource Locator (URL) paths, different cloud storage buckets, different content delivery network nodes, and can even be embedded in the EXIF ​​metadata of different legitimate image files using steganography. This ensures that even if a single remote storage location is discovered by a security device, an attacker cannot obtain the complete encrypted payload data.

[0052] Correspondingly, a fragment index table is pre-embedded in the executable file of the replacement loader. The fragment index table contains at least the remote storage address, fragment sequence number, and integrity check value of each data fragment. In one feasible implementation, to increase the difficulty for security devices to analyze the replacement loader, the fragment index table can be stored in the executable file of the replacement loader in encrypted and Base64 encoded form, and the address information of each fragment can be obtained by decoding and restoring it at runtime.

[0053] With the above-mentioned fragmented deployment method, even if the security device intercepts some of the network requests for fragments, it is still unable to restore the complete encrypted payload content. At the same time, the dispersed request patterns are initiated on different URL paths and at different times, making it more difficult for the network traffic level to associate multiple requests as downloading the same malicious payload, thereby further improving the concealment of the payload acquisition process.

[0054] (3) Embed the encrypted payload data into a legitimate carrier file by steganography and deploy the carrier file on a remote storage medium; For example, the carrier file is a completely legitimate file that appears or sounds perfectly normal, such as a PNG or JPG image file, a PDF document file, or a WAV audio file. After the encrypted payload data is embedded, the carrier file remains consistent with the original file in appearance, size, and playback effect, and can be opened, viewed, or played normally without arousing suspicion from users or security software.

[0055] In one feasible implementation, least significant bit (LSB) steganography is used to embed the encrypted payload data into an image carrier file. Specifically, a 24-bit bitmap without an alpha channel is selected as the carrier. Each pixel in the image has three color components: red (R), green (G), and blue (B), with each component ranging from 0x00 to 0xFF, totaling 8 bits. The binary byte stream of the encrypted payload data is split into a continuous sequence of binary bits, and the least significant bit (i.e., the 8th bit of each color component) of the three RGB color components of each pixel is replaced sequentially. Since the change of the least significant bit has a minimal impact on the overall pixel color (only changing 1 / 256 of the color value), the human eye cannot perceive the difference between the modified image and the original image, thus completing the steganography embedding without altering the visual appearance of the image. When the carrier file is in PNG format, since PNG uses lossless compression, the modified pixel data is not destroyed during compression and decompression, therefore LSB steganography can be stably implemented in PNG images.

[0056] In another feasible implementation, the encrypted payload data is embedded in the carrier file using an EOF append method. Specifically, the encrypted payload data is appended after the End of File (EOF) marker in the carrier file. Since the operating system and most applications use the EOF marker as the end of valid data when reading a file, the data appended after the EOF marker will not be read or processed by normal applications, so the carrier file can still be opened, browsed, or played normally. During extraction, the replacement loader locates the EOF marker position in the carrier file and reads the appended data to obtain the encrypted payload data.

[0057] In one feasible implementation, to improve the concealment and anti-detection capability of steganography, the above-mentioned LSB steganography can be combined with the EOF appending method.

[0058] Meanwhile, in the executable file that replaces the loader, extraction logic corresponding to the steganography method is pre-configured. When LSB steganography is used, the extraction logic is as follows: read the least significant bit of the RGB color components of each pixel in the carrier file pixel by pixel, and restore the read binary bit sequence into a byte sequence by combining them into groups of 8 bits to obtain the encrypted payload data. When EOF appending is used, the extraction logic is as follows: locate the EOF mark position in the carrier file, read the data appended thereafter, and obtain the encrypted payload data.

[0059] Based on this, the types of remote storage media include: remote server storage space accessed via Hypertext Transfer Protocol or Hypertext Transfer Security Protocol, object storage nodes of cloud storage service providers, content delivery network nodes, storage space of code hosting platforms, remote storage space accessed via File Transfer Protocol or Universal Network File System Protocol, and steganography storage space embedded in legitimate carrier files.

[0060] Based on the deployment architecture that stores encrypted payload data separately from the replacement loader, the executable file of the replacement loader does not contain any encrypted payload data. This makes it impossible to obtain the complete malicious code payload through static analysis of the replacement loader, further reducing the risk of being captured by real-time file system monitoring.

[0061] (v) During runtime execution, the replacement loader obtains encrypted payload data from the remote storage medium via the network when the target host is running. It restores the encrypted payload data to obtain the original malicious code payload and loads and runs the restored original malicious code payload through the replacement loader. The running original malicious code payload initiates a network connection request to the associated communication server. The communication server responds to the network connection request and conducts command and control communication with the target host through the traffic masquerading layer.

[0062] Here, the replacement loader is configured on the target host to run in DLL-side loading mode or fileless mode.

[0063] Specifically, the replacement loader is configured to run on the target host via DLL-side loading: a legitimate executable program with a digital signature is selected as the host process, wherein the host process depends on at least one dynamic link library file during runtime; the replacement loader is constructed as the dynamic link library file that the host process depends on and deployed in the directory where the host process's executable file is located; wherein the replacement loader has a higher priority than the dynamic link library file with the same name that the host process depends on, and the replacement loader contains remote acquisition logic, restoration logic, and loading and execution logic for encrypted payload data; when the host process is started, the target host's operating system loads the replacement loader first according to the dynamic link library search order, so that the replacement loader loads and runs the original malicious code payload in the host process.

[0064] For example, we will use OneDrive.exe, which has a Microsoft digital signature, as the host process. OneDrive.exe relies on version.dll to obtain file version information at runtime. An attacker can analyze OneDrive.exe's import table or the list of DLLs loaded at runtime to determine that version.dll is a dependent dynamic link library file. Since this DLL is not loaded with a full path, Windows will search for it according to the DLL search order. The attacker compiles a replacement loader into a dynamic link library file and names it version.dll, making it identical to the name of the DLL that OneDrive.exe depends on; then deploys this malicious version.dll in the directory where OneDrive.exe is located. According to Windows' DLL search order, the application's directory has higher priority than the system directory. Therefore, when OneDrive.exe is launched, the operating system will preferentially load the malicious version.dll from the directory where OneDrive.exe is located, rather than the legitimate version.dll in the system directory. To ensure the host process runs normally and avoid arousing suspicion from users or security software, the replacement loader can use DLL proxy technology, where the malicious DLL exports the same functions as the legitimate version.dll. While performing malicious operations in the background, it forwards legitimate function calls to the original version.dll in the system directory. The loader replaces the logic for remotely acquiring, restoring, and loading encrypted payload data in the DllMain entry function, thereby loading and running the original malicious code payload in the context of the legitimate OneDrive.exe process.

[0065] It should be understood that the above description using OneDrive.exe and version.dll as examples is only one possible implementation. In other implementations, the host process can also be other legitimate executable programs with digital signatures, such as Teams.exe, and the hijacked DLL can also be other dynamic link library files that are not loaded using the full path, such as WinHTTP.dll and userenv.dll.

[0066] Alternatively, the replacement loader is configured to run on the target host in a fileless manner: the replacement loader is compiled into a script file; the script file contains remote acquisition logic, restoration logic, and loading execution logic for encrypted payload data; the script file is stored in at least one persistent storage location among the target host's registry configuration items, Windows administrative event subscriptions, or scheduled task configurations; when the script file is triggered for execution, the target host's operating system calls the built-in script engine to execute the script file, so that the script file acquires encrypted payload data from remote storage media into memory through the remote acquisition logic, restores the encrypted payload data in memory to obtain the original malicious code payload through the restoration logic, and calls the target system's application programming interface in the following manner (method three) through the loading execution logic to allocate an executable region in memory, write the restored original malicious code payload into the executable region, and guide the original malicious code payload to execute in the executable region; wherein, the acquisition, restoration, executable region allocation, writing, and guidance execution of encrypted payload data are all completed in the target host's memory, and no encrypted payload data or original malicious code payload is written to the target host's disk.

[0067] For example, a PowerShell script is used as the script file for illustration. The replacement loader is compiled into a PowerShell script file (.ps1), which contains the following core logic: Downloading encrypted payload data from a preset Uniform Resource Locator (URL) to a memory byte array using the System.Net.WebClient class; restoring the encrypted payload data in memory to obtain a byte array of the original malicious code payload; allocating a memory region with executable permissions in the current process memory space of the target host by calling the VirtualAlloc application programming interface; writing the restored original malicious code payload byte array into the executable memory region; creating a thread using the CreateThread application programming interface, using the starting address of the executable memory region as the thread entry point, and guiding the original malicious code payload to execute in the executable region.

[0068] In one feasible implementation, the aforementioned VirtualAlloc and CreateThread application programming interfaces can be declared and invoked through PowerShell's Add-Type and DllImport mechanisms. After the script file is executed, the encrypted payload data, the restored original malicious code payload, and the intermediate data during execution all exist only in the target host's memory. The script file itself does not write any executable file to the disk, thus achieving end-to-end fileless execution.

[0069] It should be understood that the above description using PowerShell scripts as an example is only one possible implementation. In other implementations, the script file may also be a VBScript script, a JavaScript script, or other script types that are interpreted and executed by the operating system's built-in script engine.

[0070] Based on this, the replacement loader obtains encrypted payload data over the network: (1) When the encrypted payload data is stored as a file on a remote storage medium, the replacement loader initiates a GET request to a preset URL via the WinHTTP or WinINet application programming interface to obtain the encrypted payload data. Specifically, it sequentially calls WinHttpOpen to create a session handle, WinHttpConnect to establish a connection with the server, WinHttpOpenRequest to create an HTTP request, WinHttpSendRequest to send a GET request, and WinHttpReceiveResponse to receive the server response. Then, it repeatedly calls WinHttpReadData to read the response data into the memory buffer until all data has been read.

[0071] (2) When the encrypted payload data is divided into multiple data fragments and deployed on multiple different remote storage media, the replacement loader initiates network requests to each fragment address sequentially according to the fragment index table, acquiring each data fragment one by one. For each acquired data fragment, the data is written to the corresponding offset position in the target host's heap memory according to the fragment sequence number, until all data fragments are acquired. After all data fragments are acquired, the replacement loader performs integrity verification on the reassembled complete data based on the preset integrity check value (e.g., CRC32 or MD5 check value) in the fragment index table to confirm the integrity and correctness of each fragment. After successful verification, the replacement loader performs unified decryption processing on the reassembled complete encrypted payload data in memory to restore the original malicious code payload.

[0072] (3) When the encrypted payload data is deployed via steganography, the replacement loader first obtains the carrier file from the remote storage medium (e.g., downloads an image file via HTTP or HTTPS protocol), then extracts the encrypted payload data from the carrier file in the target host's memory according to the preset extraction logic, and finally restores the encrypted payload data to obtain the original malicious code payload.

[0073] After restoration, it is configured to load and run the restored original malicious payload in at least one of the following ways: Method 1: The restored original malicious code payload is embedded as static data into the data segment of the replacement loader. The access permissions of the data segment are configured to include executable permissions through compiler instructions, and the starting address of the storage address of the static data is constructed as the first function pointer. The original malicious code payload is directly called through the first function pointer, so that the original malicious code payload is executed in the data segment. Method 2: Allocate a storage area with executable permissions in the heap memory, write the restored original malicious code payload into the storage area, and construct a second function pointer from the starting address of the storage area; directly call the original malicious code payload through the second function pointer to execute the original malicious code payload in the heap memory; Method 3: Define a third function pointer that has the same calling convention, return type, and parameter types as the target system's application programming interface (API). By replacing the loader runtime, the export table of the operating system kernel dynamic link library is parsed to obtain the entry address of the target system's API, and the entry address is assigned to the variable of the third function pointer. Through the variable of the third function pointer, the loader calls the target system's API to allocate executable memory for the restored original malicious code payload in the process of the target host, write the restored original malicious code payload into the executable memory, and guide the execution of the original malicious code payload in the executable memory.

[0074] The specific implementation process of each method will now be explained.

[0075] (1) Method 1 is adopted: For example, the restored original malicious payload is stored in a global variable (located in the data segment of the replacement loader, i.e., the .data segment). At compile time, the data segment's attributes are set to readable, writable, and executable using the compiler directive `#pragma comment(linker, " / section:.data,RWE")`. Then, a first function pointer is used for type casting (e.g., `((void(...)`). The command directly jumps to execute the original malicious code payload without calling sensitive system application programming interfaces such as VirtualAlloc, VirtualProtect, and CreateThread, thus effectively avoiding detection of the "allocation-write-execution" call sequence pattern by dynamic behavior monitoring systems.

[0076] (2) Method 2: For example, first, a heap with execute permissions is created using the HeapCreate function (passing the HEAP_CREATE_ENABLE_EXECUTE flag). Then, storage space is allocated in the heap using the HeapAlloc function. The restored original malicious code payload is copied to the heap memory using memcpy. Finally, a second function pointer is used to force a cast (e.g., void( The function directly jumps to execute the original malicious code payload. The entire execution process completes memory allocation through HeapCreate and HeapAlloc, without calling sensitive system application programming interfaces such as VirtualAlloc and VirtualProtect, thus effectively avoiding detection of the "allocation-write-execution" call sequence pattern by dynamic behavior monitoring systems.

[0077] (3) Method 3: For example, the process first brute-force searches the loaded module list (InInitializationOrderModuleList) in the process environment block (PEB) of the current process to locate the memory base address of the operating system kernel dynamic link library Kernel32.dll. Then, the PE export table of Kernel32.dll is manually parsed, and the memory address of the GetProcAddress function is located by string matching through the three core arrays AddressOfFunctions, AddressOfNames, and AddressOfNameOrdinals in the export directory table. After obtaining the GetProcAddress address, the addresses of target system application programming interfaces (APIs) such as VirtualProtect, CreateThread, and WaitForSingleObject are dynamically obtained and called through this third function pointer. Throughout this process, it is unnecessary to write any sensitive API function names into the executable file's Import Address Table (IAT), thus effectively eliminating detection based on static feature matching of the import table.

[0078] After the replacement loader loads and runs the original malicious payload, the original malicious payload proactively initiates an HTTPS connection request to the communication server. This connection request uses the HTTPS protocol and presents custom socket security certificate information during the transport layer security handshake. Fields such as the Common Name (CN) and Organization (O) of this certificate are set to information consistent with normal organization services, making the certificate information presented during the transport layer security handshake identical to a normal web service certificate, thus avoiding detection based on certificate characteristics. At the application layer, the connection request is made according to the Uniform Resource Locator (URL) path format defined in the custom communication configuration. The URI path is configured to a common static resource path format, such as " / jquery-3.3.1.min.js", making the connection request appear as a normal access to the front-end resource library at the traffic audit level. The communication server responds to the network connection request by returning data according to a custom Hypertext Transfer Protocol (HTTP) response header format, for example, setting the response content type to "application / javascript", making the response traffic appear as a normal front-end resource loading response.

[0079] After deployment, attackers manage the online target host sessions through a communication server (such as the Cobalt Strike client), executing remote commands, file browsing, file uploading, file downloading, privilege escalation, and other post-exploitation operations. Throughout the process, command and control communication traffic follows the communication protocol format and data interaction behavior defined by the custom communication configuration—the heartbeat interval varies randomly by a percentage of jitter based on the base time, making the heartbeat packets random rather than having a fixed periodic pattern in time distribution. All communication data is encoded and transformed according to the specified encoding method and then carried in the HTTP protocol fields—making the command and control interaction traffic appear as normal network application layer protocol access behavior at the traffic audit level.

[0080] Compared with existing technologies, this application has significant advantages: This application systematically constructs an adversarial system from four dimensions: traffic layer, code layer, loading layer, and deployment architecture layer, forming a complete adversarial closed loop to effectively address the current multi-layered and multi-dimensional security detection system. Simultaneously, by physically separating the encrypted payload data from the executable file of the replacement loader and deploying it independently on a remote storage medium, the executable file of the replacement loader does not contain any payload data, fundamentally reducing the detection surface. Furthermore, this application supports multiple deployment and loading / execution methods for encrypted payload data, which can be flexibly selected or combined according to the security detection strategy of the target environment, exhibiting high adaptability. Moreover, the acquisition, restoration, loading, and execution of encrypted payload data are all completed in the target host's memory, without writing any malicious executable files to the disk. Command control communication traffic presents normal network access behavior in multiple dimensions, including port, certificate, protocol format, and behavior patterns. In summary, this application effectively solves the problems of easy failure of single adversarial methods, excessive detection surface, and obvious communication traffic characteristics in existing technologies, significantly improving the concealment and survivability of malicious code under mainstream security detection systems.

[0081] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0082] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A multi-layered, combined anti-virus evasion method for malicious code, characterized in that, The method includes: On the server-side configuration side, the original communication configuration of the communication server associated with the original malicious code payload is overwritten with a custom communication configuration to build a traffic masquerading layer; On the payload data side, the original malicious code payload is externally encrypted to form an encrypted wrapping layer that surrounds the original malicious code payload. On the loader side, the original loader that comes with the original malicious code payload is discarded, and an independent replacement loader is rebuilt. The import table of the replacement loader does not contain the function names of the sensitive system application programming interfaces required by the original malicious code payload. On the deployment topology side, before compiling the executable file of the replacement loader, the encrypted payload data processed by the encryption wrapping layer is physically stripped from the executable file of the replacement loader and deployed independently on a remote storage medium, forming a deployment architecture in which the encrypted payload data and the replacement loader are stored separately. On the runtime execution side, when the replacement loader is running on the target host, it obtains the encrypted payload data from the remote storage medium via the network, restores the encrypted payload data to obtain the original malicious code payload, and loads and runs the restored original malicious code payload through the replacement loader; the running original malicious code payload initiates a network connection request to the associated communication server, and the communication server responds to the network connection request and conducts command and control communication with the target host through the traffic masquerading layer.

2. The multi-layered combined anti-virus evasion method for malicious code according to claim 1, characterized in that, On the server-side configuration side, the original communication configuration of the communication server associated with the original malicious code payload is overwritten with a custom communication configuration to construct a traffic masquerading layer, including: By loading the custom communication configuration, the default listening port of the communication server is overridden by the custom listening port parameters contained therein, the default socket security certificate of the communication server is replaced by the custom socket security certificate parameters contained therein, and the default communication parameters of the communication server are overridden by the communication protocol format parameters and data interaction behavior parameters between the communication server and the target host contained therein, thus completing the traffic-side configuration. When the communication server communicates with the target host via command and control, the communication server and the target host are made to interact with each other according to the communication mode defined by the custom communication configuration, so that the interaction traffic between the communication server and the target host appears as normal network application layer protocol access behavior at the traffic audit level.

3. The multi-layered combined anti-virus evasion method for malicious code according to claim 2, characterized in that, The communication protocol format parameters include at least: The request header format and response header format of the Hypertext Transfer Protocol; The heartbeat interval and jitter parameters between the communication server and the target host; Uniform Resource Locator (URL) path format; Data transmission encoding method.

4. The multi-layered combined anti-virus evasion method for malicious code according to claim 1, characterized in that, On the payload data side, the original malicious code payload undergoes external encryption processing to form an encrypted wrapper layer surrounding the original malicious code payload, including: The binary byte stream of the original malicious code payload is encrypted using at least one of the following encryption methods: XOR encryption algorithm, AES symmetric encryption algorithm, and memory encoder, to generate encrypted payload data for wrapping the original malicious code payload.

5. The multi-layered combined anti-virus evasion method for malicious code according to claim 4, characterized in that, When using the memory encoder for encryption, the method further includes: Based on the set target architecture parameters and encoding count parameters, the memory encoder is invoked to perform randomization encoding on the original malicious code payload to generate encoded payload data. The header of the encoded payload data contains a decoder stub, which is used to decode and restore the original malicious code payload when the encrypted payload data is restored.

6. The multi-layered combined anti-virus evasion method for malicious code according to claim 1, characterized in that, On the loader side, the replacement loader is configured to load and run the restored original malicious code payload in at least one of the following ways: Method 1: The restored original malicious code payload is embedded as static data into the data segment of the replacement loader. The access permissions of the data segment are configured to include executable permissions through compiler instructions, and the starting address of the storage address of the static data is constructed as the first function pointer. The original malicious code payload is executed in the data segment by directly calling the first function pointer; Method 2: Allocate a storage area with executable permissions in the heap memory, write the restored original malicious code payload into the storage area, and construct a second function pointer from the starting address of the storage area; The original malicious code payload is executed in the heap memory by directly calling the second function pointer; Method 3: Define a third function pointer that has the same calling convention, return value type, and parameter types as the target system's application programming interface. When the replacement loader runs, it parses the export table of the operating system's core dynamic link library to obtain the entry address of the target system's application programming interface and assigns the entry address to the variable of the third function pointer. Through the variable of the third function pointer, the replacement loader calls the target system application programming interface to allocate executable memory for the restored original malicious code payload in the process of the target host, writes the restored original malicious code payload into the executable memory, and guides the execution of the original malicious code payload in the executable memory.

7. The multi-layered combined anti-virus evasion method for malicious code according to claim 1, characterized in that, The encrypted payload data is deployed to the remote storage medium through at least one of the following methods: (1) The encrypted payload data is stored in the remote storage medium as a file; (2) Divide the encrypted payload data into multiple data fragments and deploy them on multiple different remote storage media respectively; (3) Embed the encrypted payload data into a legitimate carrier file by steganography, and deploy the carrier file on the remote storage medium.

8. The multi-layered combined anti-virus evasion method for malicious code according to claim 1 or 6, characterized in that, The replacement loader is configured to run on the target host in a DLL-side-loading manner: A legitimate executable program with a digital signature is selected as the host process, wherein the host process depends on at least one dynamic link library file during runtime; The replacement loader is constructed as a dynamic link library file that the host process depends on, and deployed in the directory where the executable file of the host process is located; wherein, the replacement loader has a higher priority than the dynamic link library file with the same name that the host process depends on, and the replacement loader contains the remote acquisition logic, restoration logic and loading execution logic of the encrypted payload data; When the host process is started, the target host's operating system loads the replacement loader first according to the dynamic link library search order, so that the replacement loader loads and runs the original malicious code payload in the host process.

9. The multi-layered combined anti-virus evasion method for malicious code according to claim 1 or 6, characterized in that, The replacement loader is configured to run on the target host in a fileless manner: The replacement loader is compiled into a script file; wherein the script file contains remote acquisition logic, restoration logic, and loading execution logic for the encrypted payload data; The script file is stored in at least one persistent storage location among the registry configuration items, Windows administrative event subscriptions, or scheduled task configurations of the target host; When the script file is triggered to execute, the operating system of the target host calls the built-in script engine to execute the script file, so that the script file obtains the encrypted payload data from the remote storage medium to memory through the remote acquisition logic, restores the encrypted payload data in memory through the restoration logic to obtain the original malicious code payload, and calls the target system application programming interface through the loading execution logic in the manner of claim 6, so as to allocate an executable area in memory, write the restored original malicious code payload into the executable area, and guide the original malicious code payload to execute in the executable area; The acquisition, restoration, executable region allocation, writing, and boot execution of the encrypted payload data are all completed in the memory of the target host, without writing the encrypted payload data or the original malicious code payload to the disk of the target host.

10. The multi-layered combined anti-virus evasion method for malicious code according to claim 1, characterized in that, When rebuilding an independent replacement loader on the loader side, the following is also included: When compiling the source code of the replacement loader, the runtime library linking method is configured to at least one of static linking or dynamic linking, and / or the code optimization options are configured to at least one of minimizing size or maximizing runtime speed.

Images