JP2020522808A - Real-time detection of malware and steganography in kernel mode and protection from malware and steganography - Google Patents

Abstract

A method for real-time detection of malware in kernel mode includes detecting file manipulation requests initiated by processes running in user mode. Malware detection analysis is performed on the file buffer associated with the detected file manipulation request to detect behavior indicative of the presence of malware. In response to detecting the behavior indicative of the presence of malware, the process responsible for initiating the detected file manipulation request is identified. A search for the identified process in one or more of the program blacklist and the program whitelist is performed to determine if the identified process is a trusted process. In response to determining that the identified process is not a trusted process, a malware modifying action is performed on the identified process. Information describing the malware is sent to the client device.

Description

The present disclosure relates generally to malware detection, and more particularly to real-time detection of malware and steganography in kernel mode and protection from malware and steganography.

CROSS REFERENCE TO RELATED APPLICATIONS This application claims the benefit of US Provisional Application No. 62/512,659, filed May 30, 2017, which is incorporated by reference in its entirety.

Malware refers to malicious computer software programs that can infect a computer, tablet, or device without the owner's knowledge or permission. Steganography is one such method of infecting devices and networks with malware.

Malware may include viruses, worms, Trojan horses, botnets, spyware, and adware. Viruses replicate themselves after attaching to executable programs. Worms replicate themselves across networks, rapidly infecting many devices. Trojan horses disguise themselves as legitimate software and attempt to steal user identities, passwords, and other personal information. Botnets are groups of remotely controlled infected devices. Individual bots (devices) can be instructed to send spam emails or participate in denial of service attacks. Spyware is designed to capture keystrokes, credit card numbers, and other personal information. Adware infects devices and downloads and displays unwanted ads.

Traditional malware protection tools may detect signatures and try to quarantine and repair or remove the malware. However, the number of malware programs is increasing dramatically and signatures are usually created only for known malware. Therefore, traditional signature-based approaches typically cannot identify or detect unknown malware.

Moreover, traditional approaches based on runtime heuristic scanning with rules can result in many false positives and false negatives. Other traditional sandboxing-based methods of executing suspicious files and observing malicious behavior in a virtual machine can determine if they are in the sandbox (virtual machine or container) and avoid detection. It is usually impossible to detect malware. Finally, traditional methods based on static code analysis also cannot reliably detect malware.

The disclosed embodiments have advantages and features that become more readily apparent from the detailed description, the appended claims, and the accompanying drawings (or drawings). A brief introduction of the figure is as follows.

FIG. 2 is an exemplary block diagram of a system for real-time detection of malware and steganography in kernel mode and protection from malware and steganography, according to an embodiment. FIG. 3 is an exemplary block diagram of real-time malware detection and protection from malware for applications running in user mode on a platform, according to embodiments. FIG. 6 illustrates an exemplary filter manager and mini filter driver for real-time detection of malware and protection from malware, according to embodiments. FIG. 7 illustrates exemplary components of a Volume Shadow Service (VSS) for real-time detection of malware and protection from malware, according to embodiments. FIG. 6 illustrates example data points for a Monte Carlo pie approximation, according to an embodiment. FIG. 6 illustrates an exemplary process for real-time detection of malware and protection from malware according to embodiments. FIG. 6 illustrates components of an exemplary portable executable (PE) file for real-time steganographic detection and protection from steganography in kernel mode, according to an embodiment. FIG. 6 illustrates an exemplary process for real-time steganographic detection and protection from steganography in kernel mode, according to an embodiment. FIG. 3 is a block diagram illustrating components of an exemplary machine capable of reading instructions from a machine-readable medium and executing them on a processor or controller.

The drawings (drawings) and the following description relate to preferred embodiments merely for purposes of illustration. It will be readily appreciated from the following discussion that alternative embodiments of the structures and methods disclosed herein are workable alternatives that may be employed without departing from the principles of the claims. Please note.

Reference will now be made in detail to some embodiments, examples of which are illustrated in the accompanying drawings. It should be noted that like or similar reference numbers may be used in the figures and may indicate similar or similar functionality, where practicable. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. It will be readily appreciated by those skilled in the art from the following description that alternative embodiments of the structures and methods presented herein may be employed without departing from the principles described herein.

Introduction Conventional security products may include behavioral analysis and run-time heuristics to protect devices from unknown malware by looking for suspicious application program interface (API) calls and actions. Malware refers to software intended to damage or disable computers and computer systems. Malware may include sophisticated programs that avoid detection by security products by creating polymorphic or metamorphic malware. Polymorphic malware mutates by encrypting subversive code using a mutation engine that produces new "signatures" in different executions. Metamorphic malware dynamically rebuilds executable code to obscure malicious intent. To avoid detection, malware may add redundant processor opcodes such as push, pop, NOP, and jump instructions to change the signature of the executable, but without affecting functionality.

Ransomware is a fast-growing category of malware. Ransomware is a type of malware that infects computers, tablets, devices, or smartphones with the purpose of forcing users to "pay" to restore access to their devices or personal data. Some types of ransomware may lock user devices or systems to prevent users from accessing those devices or systems. Other types of ransomware may use encryption software to encrypt user personal data such as word processing documents, photos, music, videos, emails, and so on. In such cases, the user may be required to pay a ransom to regain access. Steganography is one such method of infecting devices and networks with ransomware.

Steganography refers to the technique of hiding a computer file, message, image, or video within another computer file, message, image, or video. In digital steganography, electronic communication may include steganographic encoding within a transport layer such as a document file, image file, program, or protocol. Media files may be used for steganographic transmission because of their large size. For example, the sender may start with a harmless image file and adjust the color of each hundredth pixel to correspond to a letter of the alphabet.

Conventional methods for detecting ransomware may rely on malware file signature detection, runtime heuristic scanning, sandboxing, static code analysis, and so on. However, conventional methods based on detecting malware file signatures may only detect previously identified malware and may not protect against new forms of ransomware, such as self-transforming ransomware. Traditional methods based on run-time heuristic scanning may use a set of rules to generate false positives and false negatives. Traditional methods based on sandboxing may execute suspicious files in virtual machines and observe malicious behavior. However, ransomware may be able to determine if it is in the sandbox (virtual machine or container) and avoid detection. Conventional methods based on static code analysis may try to disassemble the executable code and build a parse tree to identify suspicious API calls. However, such conventional methods based on static code analysis cannot reliably detect ransomware.

"Packed" and "hidden malware" are traditionally undetected and may pass through local device firewalls, network firewalls, and antivirus software. Traditional firewall features such as filtering and deep packet inspection, intrusion protection systems, application awareness are often used. However, traditional firewalls rely on port assignments to detect malware. Therefore, there is a weak association between the actual application type and the firewall assumptions about the application. Moreover, deep packet inspection is of limited value when the endpoint is the destination rather than the firewall due to strong encryption.

Configuration Overview A system, method, and/or computer program product (eg, a computer-readable storage medium storing instructions executable by one or more processing units) for real-time detection of malware and protection from malware is illustrated. Disclosed by an exemplary embodiment. A processor in a computer may generally run in at least two different modes: user mode and kernel mode. Typically, applications may run in user mode and core operating system components may run in kernel mode.

In one embodiment, file manipulation requests initiated by processes running in user mode are detected. Malware detection analysis is performed on the file buffer associated with the detected file manipulation request to detect behavior indicative of the presence of malware. In response to detecting the behavior indicative of the presence of malware, the process responsible for initiating the detected file manipulation request is identified. A search for the identified process in one or more of the program blacklist and the program whitelist is performed to determine if the identified process is a trusted process. In response to determining that the identified process is not a trusted process, a malware modifying action is performed on the identified process. Information describing the malware is sent to the client device.

The disclosed embodiments provide integrated real-time detection of security threats to protect devices and networks from malicious attacks and data loss. A static analysis is performed that uses an array of tests to search for potentially infected files, identify suspicious program instructions, and determine if they are malware Good. When detected, the unique sequence of bytes identifies malicious software without requiring execution and distinguishes it from legitimate programs. Dynamic analysis monitors the behavior of an application during execution to determine if it contains malware. In addition to directly identifying malware, system status is monitored in real time.

Since current malware may be polymorphic or metamorphic, it may evade detection by traditional antivirus software that uses file signatures. In one embodiment, a unique state-based mechanism is used to detect if a file is encrypted without permission. The responsible process is identified and isolated from other devices. This eliminates the need to know malware in advance. Changes in the state of the data make malware identification quick and reliable. Integrated steganographic detection identifies the presence of data and malware hidden from execution on the device. The system runs inline on the firewall to prevent malware and files with hidden data from entering the network. Together, it works as an integrated end-to-end system that leverages the strengths of static analysis, dynamic analysis, system state changes to more accurately detect malware with fewer false positives and fewer false negatives.

Further, systems, methods, and/or computer program products for real-time steganographic detection and protection from steganography in kernel mode (eg, a computer-readable storage medium storing instructions executable by one or more processing units). Are disclosed by way of example embodiments. Detects sending files through a firewall, operating system, or email system. The size of the file is determined. The stored file size of the file is retrieved from the file system. The determined size of the file is compared to the stored file size of the file. Steganographic detection analysis is performed on the file in response to the determined size of the file being greater than the stored file size of the file. Steganographic correction actions are performed in response to the steganographic detection analysis indicating the presence of steganography in the file. Information describing steganography is sent to the client device.

The disclosed embodiments combine both known and unknown malware and security threats by integrating a combination of analytics to identify unauthorized data encryption, data leakage, rootkit installation, and steganography. It can protect many types of devices. The system and method provide an end-to-end solution for faster, more accurate malware detection, isolation, analysis, and removal with less computational overhead and storage utilization compared to existing techniques. .. Real-time analysis of file system state changes enables real-time protection before user data is encrypted or deleted. The creation of dynamic API monitoring heuristics, dynamic code analysis, tripwires and honeypots helps discover suspicious behavior in near real time.

The disclosed embodiments proactively check for tampering with system configurations (MFT, MBR, Registry, and Windows Task Manager) and fix malicious changes to ensure users are not locked out. To do. MFT refers to the master file table. MBR refers to the master boot record. The Windows registry stores low-level configuration settings about the operating system and about applications, device drivers, security account managers (SAMs), and access system performance counters. The task manager schedules the execution of programs. A centralized, detailed logging system allows system administrators to manage all devices in their environment and provide the basis for various data analysis.

Benefits and advantages of the disclosed embodiments include continuously cleaning the system without knowledge of where the ransomware is. As part of this approach, the method may decommission a server, eg a DNS server. The result is a ransomware evidence of state change isolation and detection approaches. Polymorphic ransomware can encrypt the payload in a container and modify signatures that are undetectable by conventional methods. Metamorphic ransomware modifies its signature by inserting meaningless machine instructions into the code. Instead of searching for known malware, the disclosed embodiments look for state changes in the system. Further advantages and benefits include the simplicity in using a program blacklist to identify malware. Accordingly, the disclosed embodiments require less maintenance as the disclosed system and its associated database or third party threat intelligence/service providers compile and update program blacklists.

Thus, the disclosed embodiments may perform static state analysis (disk scanning) and real-time analysis. Malware signatures are not used, but calculations are done to detect if a file has been encrypted. Both read and write buffers in the I/O request packet may be used. Therefore, no additional memory allocation or additional read/write operations are required. There is no post-processing analysis that requires additional memory and calculations. In another embodiment, the disclosed methods and systems may be used to combat memory-based attacks, where the files are stored in memory rather than on disk. In-memory monitoring of file allocations may be performed and data that does not touch the disk may be scanned. The combination of statistical analysis on the device, integrated inline with the firewall, provides strong protection for the network and the device.

Method and System for Malware and Steganography Detection and Prevention In one embodiment, a method for real-time detection of malware in kernel mode and protection from malware includes file manipulation requests initiated by processes running in user mode. Is detected. Malware detection analysis is performed on the file buffer associated with the detected file manipulation request to detect behavior indicative of the presence of malware. In response to detecting the behavior indicative of the presence of malware, the process responsible for initiating the detected file manipulation request is identified. A search for the identified process in one or more of the program blacklist and the program whitelist is performed to determine if the identified process is a trusted process. In response to determining that the identified process is not a trusted process, a malware modifying action is performed on the identified process. Information describing the malware is sent to the client device.

In one embodiment, detecting the file operation request includes determining from the file handle corresponding to the file operation request whether the file operation request corresponds to a predetermined operation. The file operation request is intercepted in response to determining that the file operation request corresponds to a predetermined action.

In one embodiment, the step of intercepting the file operation request includes determining by the filter manager whether the mini filter driver is registered to intercept the file operation request. In response to determining that the minifilter driver is registered to intercept the file manipulation request, the filter manager sends the file manipulation request to the minifilter driver.

In one embodiment, the step of performing malware detection analysis comprises one or more of Monte Carlo approximation, entropy decision, sequence coefficient analysis, arithmetic mean decision, chi-square decision, and standard deviation decision to determine whether the Included in determining if the data is encrypted.

In one embodiment, determining that the identified process is not a trusted process further comprises identifying the identified process on a blacklist of programs. Performing the malware fix action terminates the write operation associated with the detected file operation request and terminates the detected file operation request by deleting the detected file operation request from memory. The method further includes the steps of isolating a disk file image associated with the identified process.

In one embodiment, in response to identifying the identified process on the program's whitelist, the minifilter driver ignores the detected file manipulation request.

In one embodiment, the step of determining whether the identified process is a trusted process includes identifying the identified process in response to not identifying the process on a program blacklist or program whitelist. The method further includes sending a request for authorization to the client device.

In one embodiment, the step of determining that the identified process is not a trusted process is performed by the identified process in response to sending a request to the client device to authorize the identified process. The method further includes receiving a disallowed message from the client device.

In one embodiment, the identified process is added to the program's blacklist.

In one embodiment, the identified process is added to the program's whitelist in response to receiving a message from the client device that the identified process is authorized.

In one embodiment, a non-transitory computer-readable medium stores instructions that, when executed by at least one processor, detect file operation requests initiated by a process executing in user mode. At least one processor. Malware detection analysis is performed on the file buffer associated with the detected file manipulation request to detect behavior indicative of the presence of malware. In response to detecting the behavior indicative of the presence of malware, the process responsible for initiating the detected file manipulation request is identified. A search for the identified process in one or more of the program blacklist and the program whitelist is performed to determine if the identified process is a trusted process. In response to determining that the identified process is not a trusted process, a malware modifying action is performed on the identified process. Information describing the malware is sent to the client device.

In one embodiment, the instructions that cause at least one processor to detect a file operation request include determining from a file handle corresponding to the file operation request whether the file operation request corresponds to a predetermined operation. Further included are instructions for causing at least one processor to perform. The file operation request is intercepted in response to determining that the file operation request corresponds to a predetermined action.

In one embodiment, the instructions that cause the at least one processor to intercept the file manipulation request include at least determining by the filter manager whether a minifilter driver is registered to intercept the file manipulation request. It further includes instructions to cause one processor to perform. In response to determining that the minifilter driver is registered to intercept the file manipulation request, the filter manager sends the file manipulation request to the minifilter driver.

In one embodiment, the instructions that cause the at least one processor to perform malware detection analysis are one or more of a Monte Carlo approximation, entropy decision, series coefficient analysis, arithmetic mean decision, chi-square decision, and standard deviation decision. The method further includes instructions that cause the at least one processor to perform a plurality to determine whether the data in the file buffer is encrypted.

In one embodiment, the instruction causing at least one processor to determine that the identified process is not a trusted process is to identify the identified process on a blacklist of programs. It further includes an instruction to perform. The instructions that cause the at least one processor to perform the malware modification action include terminating the write operation associated with the detected file operation request and deleting the detected file operation request from memory. The instructions further include causing the at least one processor to terminate the detected file manipulation request and isolate the disk file image associated with the identified process.

In one embodiment, a non-transitory computer readable medium is detected by a minifilter driver in response to identifying a process identified on a whitelist of programs when executed by at least one processor. Further storing instructions that cause the at least one processor to ignore the file operation request.

In one embodiment, the instructions that cause the at least one processor to determine whether the identified process is a trusted process do not identify the process on a blacklist of programs or a whitelist of programs. In response, the method further includes instructions that cause the at least one processor to send a request to the client device to authorize the identified process.

In one embodiment, the instructions that cause the at least one processor to determine that the identified process is not a trusted process are to send a request to the client device to authorize the identified process. In response, the method further includes instructions that cause the at least one processor to receive a message from the client device that the identified process is not authorized.

In one embodiment, the non-transitory computer readable medium further stores instructions that, when executed by the at least one processor, cause the at least one processor to add the identified process to a blacklist of programs.

In one embodiment, a non-transitory computer-readable medium, when executed by at least one processor, is responsive to receiving a message from a client device that the identified process is authorized, causes the identified process to be processed. Further storing instructions that cause the at least one processor to add to the program whitelist.

In one embodiment, a method for real-time steganographic detection and protection from steganography in kernel mode includes detecting transmission of a file through a firewall, operating system, or email system. The size of the file is determined. The stored file size of the file is retrieved from the file system. The determined size of the file is compared to the stored file size of the file. Steganographic detection analysis is performed on the file in response to the determined size of the file being greater than the stored file size of the file. In response to the steganographic detection analysis indicating the presence of steganography in the file, steganographic correction actions are performed and information describing steganography is sent to the client device.

In one embodiment, determining the size of the file includes obtaining a pointer to a section header of the file, the section header being associated with multiple sections of the file. A section size is determined for each section of the plurality of sections of the file. The size of each section of the multiple sections of the file is summed to determine the size of the file.

In one embodiment, obtaining the pointer to the section header of the file includes opening the file using the filename or path of the file. The file header is read. The magic number is retrieved from the header. The magic number is verified to get a pointer to the section header of the file.

In one embodiment, performing steganographic detection analysis on the file includes identifying additional payloads in the file. The added payload is analyzed to determine the file format of the added payload. Steganography detection analysis is performed based on the file format of the added payload.

In one embodiment, performing steganographic detection analysis on the file includes identifying additional payloads in the file. One or more of Monte Carlo approximation, entropy decision, sequence coefficient analysis, arithmetic mean decision, chi-square decision, and standard deviation decision are made to determine if the data in the appended payload is encrypted. To do.

In one embodiment, performing steganographic detection analysis on the file includes identifying additional payloads in the file and identifying the presence of unauthorized data in the additional payloads.

In one embodiment, performing steganographic detection analysis on the file includes identifying additional payloads in the file and identifying the presence of assembly or machine level instructions within the additional payloads. ..

In one embodiment, performing the steganographic correction action includes terminating the processing and transmission of the file and isolating the file.

In one embodiment, the non-transitory computer-readable medium includes instructions that, when executed by the at least one processor, detect the transmission of the file through a firewall, operating system, or email system. At least one processor. The size of the file is determined. The stored file size of the file is retrieved from the file system. The determined size of the file is compared to the stored file size of the file. Steganographic detection analysis is performed on the file in response to the determined size of the file being greater than the stored file size of the file. In response to the steganographic detection analysis indicating the presence of steganography in the file, steganographic correction actions are performed and information describing steganography is sent to the client device.

In one embodiment, the instructions that cause the at least one processor to determine the size of the file include instructions that cause the at least one processor to obtain a pointer to a section header of the file, the section header of the file. Associated with multiple sections. A section size is determined for each section of the plurality of sections of the file. The size of each section of the multiple sections of the file is summed to determine the size of the file.

In one embodiment, the instructions that cause the at least one processor to obtain a pointer to a section header of the file cause the at least one processor to open the file using the filename or path of the file. Including instructions. The file header is read. The magic number is retrieved from the header. The magic number is verified to get a pointer to the section header of the file.

In one embodiment, the instructions that cause the at least one processor to perform steganographic detection analysis on the file include instructions that cause the at least one processor to identify the added payload in the file. The added payload is analyzed to determine the file format of the added payload. Steganography detection analysis is performed based on the file format of the added payload.

In one embodiment, the instructions that cause the at least one processor to perform steganographic detection analysis on the file include instructions that cause the at least one processor to identify the added payload in the file. One or more of Monte Carlo approximation, entropy decision, sequence coefficient analysis, arithmetic mean decision, chi-square decision, and standard deviation decision are made to determine if the data in the appended payload is encrypted. To do.

In one embodiment, the instructions that cause the at least one processor to perform steganographic detection analysis on the file identify the additional payload in the file and the presence of unauthorized data in the additional payload. Identifying at least one processor.

In one embodiment, the instructions that cause the at least one processor to perform steganographic detection analysis on the file include identifying an additional payload in the file, and assembly level instructions or machine level instructions within the additional payload. Of the presence of the at least one processor.

In one embodiment, the instructions that cause the at least one processor to perform the steganographic correction action include instructions that cause the at least one processor to finish processing and transmitting the file and quarantine the file. Including.

In one embodiment, the computer system comprises at least one computer processor. A non-transitory computer-readable medium stores instructions that, when executed by at least one computer processor, detect at least one transmission of a file through a firewall, operating system, or email system. Let the processor do it. The size of the file is determined. The stored file size of the file is determined from the file system. The determined size of the file is compared to the stored file size of the file. Steganographic detection analysis is performed on the file in response to the determined size of the file being greater than the stored file size of the file. Steganographic correction actions are performed in response to the steganographic detection analysis indicating the presence of steganography in the file. Information describing steganography is sent to the client device.

In one embodiment, the instructions that cause the at least one computer processor to determine the size of the file include instructions that cause the at least one computer processor to obtain a pointer to a section header of the file, where the section header is Associated with multiple sections of the file. A section size is determined for each section of the plurality of sections of the file. The size of each section of the multiple sections of the file is summed to determine the size of the file.

In one embodiment, the instructions that cause the at least one computer processor to obtain a pointer to the section header of the file causes the at least one computer processor to open the file using the filename or path of the file. Includes instructions to perform. The file header is read. The magic number is retrieved from the header. The magic number is verified to get a pointer to the section header of the file.

In one embodiment, the instructions that cause the at least one computer processor to perform steganographic detection analysis on the file include instructions that cause the at least one computer processor to identify the added payload in the file. The added payload is analyzed to determine the file format of the added payload. Steganography detection analysis is performed based on the file format of the added payload.

Real-time Detection of Malware and Steganography in Kernel Mode and Protection from Malware and Steganography FIG. 1 illustrates an exemplary system for real-time detection of malware and steganography and protection from malware and steganography in kernel mode according to an embodiment. A block diagram is shown. The system includes a management node 100, a cloud host 105, and a security manager 115. In other embodiments, the system comprises additional or fewer components than those described herein. Similarly, functionality may be distributed among components and/or different entities in a different manner than described herein.

The management node 100 is a computer system that is protected from malware and steganography in kernel mode. The management node 100 may be a computer (eg, running Windows, MacOS, or another operating system), a data center, a mainframe, or any other device having storage and computing power. In one embodiment, management node 100 includes I/O manager 120, Windows service manager 170, registry 175, static analysis module 180, storage device 155, kernel 165, and hardware abstraction layer 160. In other embodiments, management node 100 comprises additional or fewer components than those described herein. Similarly, functionality may be distributed among components and/or different entities in a different manner than described herein.

In one embodiment, the management node 100 is a Windows computer. The kernel driver 130 may be dynamically installed in the filter manager 125 within the I/O manager 120. This embodiment provides a high performance mechanism for intercepting file system events on the Windows platform. In other embodiments, the management node 100 utilizes the detection system capabilities of a particular device. For example, storage device 155 in this example may be a volume formatted for NTFS file system, FAT16, or FAT32.

Management node 100 may include one or more devices that provide input and output (I/O) to and from the outside world. Such devices may include keyboards, mice, audio controllers, video controllers, disk drives, network ports and the like. In one embodiment, device drivers may provide software connections between such devices and the operating system on the management node 100. The kernel mode I/O manager 120 manages communication between applications and interfaces provided by device drivers. Communication between the operating system and device drivers occurs primarily through I/O request packets because the device may operate at a speed that does not have to match the operating system. These packets may be similar to network packets or Windows message packets. They are passed from the operating system to specific drivers, and from one driver to another.

In one embodiment, I/O manager 120 detects file operation requests (eg, read, write, open files, etc.) received by management node 100. The filter manager 125 may determine from the file handle corresponding to the file operation request whether the file operation request corresponds to a predetermined operation. A file handle is a number or identifier that the operating system temporarily assigns to a file when the file is opened. The operating system uses the file handle internally when accessing the file. If the filter manager 125 determines that the file manipulation request corresponds to a predetermined action, the filter manager 125 intercepts the file manipulation request for malware detection. If a behavior is detected that indicates the presence of malware, I/O manager 120 may identify the user mode process responsible for initiating the detected file manipulation request.

In one embodiment, the filter manager 125 is installed with Windows. It is activated only when the minifilter driver is loaded. A minifilter driver refers to a driver that filters file system operations. The mini filter driver may be located between the I/O manager 120 and the base file system. The filter manager 125 may attach to the file system stack for the target volume. The mini filter driver may indirectly attach to the file system stack by registering with the filter manager 125 for the I/O operations that the mini filter driver has chosen to filter.
In one embodiment, to intercept a file manipulation request, the filter manager 125 determines whether a mini filter driver is registered to intercept the file manipulation request. In response to determining that the minifilter driver is registered to intercept the file manipulation request, the filter manager 125 sends the file manipulation request at the minifilter driver. Once the user processor responsible for generating the file manipulation request has been identified by the I/O manager 120, the filter manager 125 causes the process identified in one or more of the program blacklist and program whitelist to be identified. May be performed to determine if the identified process is a trusted process.

The kernel driver 130 runs in kernel mode as part of a kernel mode operating system component that manages I/O, plug and play memory, processes and threads, security and the like. Similar to the operating system itself, the kernel driver 130 may be implemented as a discrete module component with a well-defined set of required functionality. Kernel driver 130 may provide a set of system defined standard driver routines. Kernel driver 130 may intercept I/O request packets before and after execution. I/O request packets are kernel-mode structures used by drivers to communicate with each other and the operating system. The minifilter kernel driver (shown with respect to FIG. 3 and described below) supports routines for file operations. Thus, the kernel driver 130 is a high performance mechanism for receiving and processing file open, read, write, close, and other operations. In one embodiment, kernel driver 130 accesses kernel mode read and write buffers for quick statistical analysis on the data that the process is requesting.

Windows service manager 170 may be used to simplify common tasks associated with Windows services. The Windows service is a computer program (similar to a daemon) that runs in the background on the management node 100. The Windows service may be configured to start when the operating system is started and running in the background, which may be started manually or by an event. The Windows service manager 170 can create services (both Win32 and legacy drivers), delete existing services, and change service configurations without restarting Windows. Windows Services Manager 170 may have both GUI and command line modes.

The registry 175 is a hierarchical data store that stores low-level settings for the operating system and applications that use the registry 175. The kernel 165, device drivers, services, and user interfaces can all use the registry 175. Therefore, the registry 175 contains information, settings, options, and other values about the program and the hardware abstraction layer 160. When the program is installed, new subkeys are added to the registry 175, including the location of the program, its version, and settings such as how the program starts. The registry 175 may contain keys used by the malware to schedule their execution after a reboot.

In one embodiment, static analysis module 180 may be a compile-time static verification tool that detects coding errors in programs and kernel mode driver code. The Windows service may monitor the status of the kernel driver 130 and is proactive, such as periodically verifying registry keys and values, looking for hidden processes, and performing static scans of the entire system. Various anti-malware tasks. The static analysis module 180 may manage system-wide scans that perform analysis on all files. It detects encryption, identifies steganography, protects against computer "lockouts", and monitors the status of the Master File Table (NTFS MFT) and Master Boot Record (MBR) for tamper evidence. Including, but not limited to. The static analysis module 180 also uses the Windows API to determine whether the Volume Shadow Copy Service (VSS) (shown below with respect to FIG. 4) has been disabled from unauthorized processes. You can do it. In an embodiment, if an unknown process is tampering with VSS, static analysis module 180 may detect that the unknown process is malware. Then, the static analysis module 180 may determine whether the unknown process is a system process to avoid a false detection via the management tool.

The storage device 155 is a component of the management node 100 that stores data and applications on the management node 100. Storage devices 155 may include RAM, cache, and hard disks, and possibly optical disk drives and externally connected USB drives. Storage device 155 is formatted for a file system that controls how data is stored and retrieved. The file system may include any of the NTFS file system, FAT16, FAT32, and the like. The NTFS file system is a file system of the Windows NT family. The File Allocation Table (FAT) is a computer file system architecture, a family of industry standard file systems. File system variants of FAT are FAT16 and FAT32.

The kernel 165 is a computer program that has control over the management node 100 and is the core of the operating system of the management node 100. The kernel 165 is typically loaded at boot time (eg, after the boot loader). The kernel 165 processes the rest of the boot and I/O requests from the software and translates them into data processing instructions for the management node 100 processor. The kernel 165 also handles memory and peripherals such as keyboards, monitors, printers, and speakers.

The hardware abstraction layer 160 allows the operating system of the management node 100 to provide hardware devices (eg, processor 310 described below with reference to FIG. 3) at a more general or abstract level than the detailed hardware level. ) Is the layer of programming that allows us to interact with. Hardware abstractions are software routines that emulate platform-specific details and give programs direct access to hardware resources. Using the hardware abstraction layer 160, device independent high performance applications may issue standard operating system calls to the hardware. For example, Windows 2000 is one of several operating systems that includes a hardware abstraction layer.

The cloud host 105 provides hosting on a virtual server that derives computing resources from a broad underlying network of physical web servers. In one embodiment, cloud host 105 may use virtual hardware, network, storage, and composite solutions from cloud vendors. Cloud hosting may be enabled through virtualization, whereby the entire computing capacity of an infrastructure or data center is distributed and provided to multiple users or managed nodes simultaneously. For example, physical servers may be virtualized and consolidated to host several cloud servers, all sharing processors, memory, storage, networks, and other resources. The cloud host 105 may execute machine learning algorithms such as naive Bayes classification, linear regression, logistic regression, and business intelligence analysis on the operational data. This information can be used to identify the extent of malware attacks, infected devices, predict and prevent propagation.

Security manager 115 provides an enterprise-wide view of managed node 100 and its policies. It is used to create, manage, deploy, and monitor devices, virtual machines, and containers. Security manager 115 may perform on-premises analysis. In one embodiment, the identified process responsible for initiating a particular file manipulation request may be determined not to be a trusted process. The security manager 115 may send a message at the management node 100 to perform a malware remediation action on the identified process. The management node 100 may send information describing the malware to the client device.

The client device consumes digital content, executes software applications, browses websites hosted by or otherwise interacting with managed node 100 on network 110, and downloads files. An electronic device used by a user to perform functions such as. For example, the client device may be a smartphone or tablet, notebook, or desktop computer. Further, the client device may be a device connected to the Internet of Things, such as consumer electronics, or yet another web server. The client device may include a display device, and a user may view digital content stored on the client device or downloaded from the management node 100 on the display device. Further, the client device may include a physical and/or user interface (UI), such as an on-screen button, with which the user interacts to consume digital content and obtain digital content. And performing functions such as sending digital content.

In one embodiment, the security manager 115 may send a signal or message to the management node 100 to perform the malware remediation action. The malware modification action may include terminating the write operation associated with the detected file operation request. The malware modification action may include terminating the detected file manipulation request by deleting the detected file manipulation request from memory. The malware remediation action may include quarantining the disk file image associated with the identified process. A disc file image is a file that stores all the content and structure of the entire disc. The disc may be an optical disc, a hard disc drive, or the like. The disk file image may be an exact copy of the disk volume or the entire physical disk drive. A disk file image may hold all the properties of its source: files, folders, properties, disk name, etc.

In one embodiment, the security manager 115 may send a signal or message to the management node 100 to perform steganographic correction actions. Steganographic correction actions may include terminating the processing and transmission of files that are about to pass through the firewall. Steganographic modification actions may include quarantining the file.

Firewall 135 is a network security system that monitors and controls incoming and outgoing network traffic based on security rules. The firewall 135 establishes a barrier between the trusted internal management node 100 and the untrusted external network 110. Firewall 135 may be a network firewall or a host-based firewall. If the firewall 135 is a host-based firewall, it may be located within or run on the management node 100 to control network tracks in and out of the management node 100.

The malware analysis module 140 performs malware detection analysis on incoming files for the management node 100 or on files associated with detected file operations. The malware analysis module 140 may be located within the management node 100 or may be executed on the management node 100. In one embodiment, the malware analysis module 140 may perform malware detection analysis on the file buffer associated with the detected file manipulation request to detect behavior indicative of the presence of malware. Similarly, malware analysis functionality can be distributed among other entities of the management node 100.

In one embodiment, the malware analysis module 140 may perform real-time steganographic detection and steganographic protection in kernel mode. Upon detecting the transmission of a file through a firewall, operating system, or email system, the malware analysis module 140 may determine the size of the file. The size of a file is a measure of how much data a file contains or how much storage it consumes. File size is usually expressed in units of measurement based on bytes.

In one embodiment, the malware analysis module 140 may determine the size of the file by obtaining a pointer to the section header of the file. Section headers are associated with multiple sections of a file. For each section i of the multiple sections of the file, the malware analysis module 140 may determine the size s _{i of the} section i. The malware analysis module 140 may sum the size s _i of each section i of multiple sections of the file to determine the size of the file as Σ _i s _i .

In one embodiment, the malware analysis module 140 may obtain the pointer to the section header of the file by opening the file using the filename or path of the file. The filename of a file is the name used to uniquely identify the file. The file system may impose restrictions on the filename length and the characters allowed in the filename. The file name may include one or more of a host name, device name, directory (or path), file base name, type (format or extension), and file version.

The malware analysis module 140 reads the header of the file. The file header may typically include metadata stored at the beginning of the file. The metadata may reside in other areas, such as at the end of the file, depending on the file format or the type of data contained. The file header may be character-based (text), binary header, etc. The header of the file may identify the file format and store information about the image format (for the image file), size, resolution, color space, etc.

The malware analysis module 140 may retrieve the magic number from the header. The magic number may be a numeric or text value used to identify a file format or protocol. For example, the magic number may be a byte within the file used to identify the format of the file. The magic number is typically a short sequence of bytes (eg, 4 bytes long) placed at the beginning of the file. For example, for a portable executable (PE) file, the hexadecimal signature may be "4D 5A" and the magic number may be "MZ". Malware analysis module 140 may validate the magic number to obtain a pointer to the section header of the file.

The file system may be the file size of the file. For example, the file system may store the number of bytes in the file that indicates the amount of storage associated with the file. The stored file size may be a non-negative integer byte up to the system limit. In another example, the stored file size may be the number of blocks or tracks occupied by the file on the physical storage device. In this example, software may be used to keep track of the exact number of bytes. The malware analysis module 140 may retrieve the stored file size of the file from the management node 100 file system. The maximum file size supported by a file system may depend not only on the capacity of the file system, but also on the number of bits reserved for storage of file size information. The maximum file size in the FAT32 file system is, for example, 4,294,967,295 bytes, which is 1 byte smaller than 4 gigabytes.

Malware analysis module 140 may compare the determined size of the file with the stored file size of the file. In response to the determined size of the file being greater than the stored file size of the file, malware analysis module 140 may perform steganographic detection analysis on the file. In one embodiment, the malware analysis module 140 may perform steganographic detection analysis by identifying the added payload in the file. The attached payload is the body or data that performs the actual malicious purpose of the malware. The payload (if not identified and removed) can cause the management node 100 to slow down or freeze, send spam, encrypt data, delete files on disk, crash the system, or corrupt files. is there. The malware analysis module 140 may analyze the attached payload to determine the file format of the attached payload. The file format of the added payload is the structure of the way information is stored (encoded) in the added payload. For example, the added payload may be JPEG or TIFF for image or raster data, AI (Adobe Illustrator) for vector data, or PDF for document exchange. The malware analysis module 140 may perform steganographic detection analysis based on the file format of the attached payload.

In one embodiment, the malware analysis module 140 performs one or more of a Monte Carlo approximation, entropy decision, sequence coefficient analysis, arithmetic mean decision, chi-square decision, and standard deviation decision to determine whether within the appended payload. It may be determined whether the data is encrypted. A Monte Carlo approximation implementation is shown and described below with respect to FIG.

In one embodiment, the malware analysis module 140 may make an entropy decision to determine if the data in the attached payload is encrypted. Entropy is

As, the amount of information content in the added payload is measured by taking the negative logarithm of the probability distribution of values and calculating the entropy of the added payload.

In the entropy determination above, H is the total entropy and P _i is the value of the bytes read from the attached payload. Encrypted and obfuscated files typically have much higher entropy than plain text or structured data files. Entropy H may be compared to an entropy threshold. Entropy above the threshold indicates that the attached payload is likely to be encrypted or compressed, so it may have been affected by ransomware. The malware analysis module 140 performs entropy calculations on sections (buffers) or the entire attached payload to hide (or "pack") the hidden or encrypted copy of the malware in the attached payload. May be detected.

In one embodiment, the malware analysis module 140 may perform a series coefficient analysis to determine if the data in the attached payload is encrypted. Sequence coefficient analysis describes the relationship between observations of the same variable over a specific time period, in this case the varying value of each byte in the added payload. Sequence coefficient analysis determines if the byte values in the added payload are correlated. If there is no correlation, it means that the value of the later byte in the added payload cannot be predicted by the previous value. The lower the serial correlation value, the higher the probability of strong encryption. If the serial correlation of a variable is measured as zero, it means that there is no correlation and each of the observations is independent of each other. Conversely, if the serial correlation of a variable slopes toward 1, it means that the observed values are serially correlated and future observed values are affected by past values.

In one embodiment, the malware analysis module 140 may make a chi-square decision to determine if the data in the appended payload is encrypted. Chi-square determination may be used to distinguish compressed files from encrypted files. Chi-square decision is a simple statistical test commonly used to compare observed data with expected data. The chi-square test is intended to test the chance that an observed distribution is due to chance. It is also called the "goodness of fit" statistic, because it measures how well the observed distribution fits the expected distribution when the variables are independent. The compressed payload will have high entropy and large chi-square value. The expected value for a completely random payload of bytes would average 127.5 (255/2). This allows the determination of encrypted files, compressed files, and encrypted compressed files. The formula for calculating the chi-square value is

Is.

In one embodiment, the malware analysis module 140 makes one or more of an arithmetic mean decision and a standard deviation decision to determine if the data in the appended payload is encrypted. If the added payload is encrypted, the arithmetic mean of the data values of the added payload should be approximately equal to 127.5 (255/2). Standard deviation σ is a measure used to quantify the amount of variation or variance in data values. The arithmetic mean and standard deviation are calculated for the portion of the payload added and for the entire payload added. Malware analysis module 140 may read the operating system's internal I/O buffers directly, thus reducing read and write overhead. This allows a greater number of statistical decisions to be calculated and analyzed, resulting in more accurate and faster decisions using less system resources. Statistical decisions can provide partial and global values even when the data is provided out of order. Such out-of-order decisions enable high performance, multi-threaded, and multi-process implementations.

In one embodiment, the malware analysis module 140 may perform steganographic detection analysis by identifying the presence of unauthorized data in the appended payload. For example, the malware analysis module 140 may detect unauthorized rootkit installations or data encryption. Detection of unauthorized changes to the data is described in detail below with respect to FIG. In one embodiment, the malware analysis module 140 may identify instructions on disk where an unauthorized system is collecting sensitive information (outbound embodiment). Therefore, unauthorized transmission of data can be prevented. In one embodiment, static analysis is used to protect against malware by analyzing files without program execution. In an inbound embodiment, unauthorized code coming into the corporate environment may be detected, for example a sequence of malicious code hidden in mp3 downloaded from the Internet.

In one embodiment, malware analysis module 140 may perform steganographic detection analysis by identifying the presence of assembly-level or machine-level instructions in the appended payload. Assembly-level instructions refer to low-level programming languages, which have strong (but often not one-to-one) correspondence between languages and architectural machine-level instructions. The malware analysis module 140 identifies suspicious instruction sets, eg, machine or assembly level language indications. In an embodiment, the method partially disassembles the file and looks for such suspicious instruction sets.

In response to the steganographic detection analysis indicating the presence of steganography in the file, the malware analysis module 140 may send a signal to the management node 100 to perform steganographic correction actions. Malware analysis module 140 may send information describing steganography to client devices.

The router 145 is a networking device that transfers data packets between the management node 100 and the network 110. The router 145 may perform a traffic detection function. When a data packet comes in from the network 110, the router 145 reads the network address information in the packet to determine the final destination. Switch 150 is a computer networking device that connects devices over a network by using packet switching to receive, process, and transfer data to a destination device. In one embodiment, the switch 150 is a multi-port network bridge that uses hardware addresses to process and transfer data at the data link layer (Layer 2) of the OSI model.

The network 110 enables communication between client devices and the management node 100. To this end, the network 110 receives the request and the corresponding data (eg, the content of the file to be posted on the web page) from the client device and forwards the request to the management node 100. Similarly, the network 110 receives the response from the management node 100 and forwards the response to the client device.

The network 110 may include the Internet and mobile phone networks. In one embodiment, the network 110 uses standard communication technologies and/or protocols. As such, the network 110 may include links using technologies such as Ethernet, 802.11, Long Term Evolution (LTE), and so on. The networking protocols used on the network 110 are Multi-Protocol Label Switching (MPLS), Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), HTTP, Simple Mail Transfer Protocol (SMTP), File. It may include a transfer protocol (FTP) or the like. The data exchanged over network 110 can be represented using technologies and/or formats including Hypertext Markup Language (HTML), Extensible Markup Language (XML), and so on. In addition, all or part of the link is encrypted using conventional encryption techniques such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet Protocol Security (IPsec). Can be converted to. In another embodiment, the entity may use custom and/or proprietary data communication techniques in place of or in addition to those described above.

Malware Detection for Applications Running in User Mode on Platform and Kernel Mode FIG. 2 illustrates real-time detection of malware and protection from malware for applications 225 running in user mode on platform 235, according to an embodiment. 3 shows an exemplary block diagram. The platform shown is based on a processor manufactured by, for example, Intel, AMD, or ARM. The operating system on the platform includes user mode 235 and kernel mode 240.

In one embodiment, kernel mode 240 is reserved for the lowest level, most trusted features of the operating system. Code executed in kernel mode 240 shares a single virtual address space. Thus, the kernel mode driver (eg 200) is isolated from other drivers (eg 205) and the operating system itself. In kernel mode 240, the executing code has access to the underlying hardware (eg, processor 310 described below with reference to FIG. 3). It executes CPU instructions and reference memory addresses.

The processor may switch between the two modes depending on the type of code executing on the processor. For example, application 225 may run in user mode and core operating system components may run in kernel mode 240. The driver may run in kernel mode 240 or user mode 235. In other embodiments, the platform comprises additional or fewer components than those described herein. Similarly, functionality may be distributed among components and/or different entities in a different manner than described herein.

Service 220 refers to a program that runs in the background (similar in concept to a daemon). User mode 235 includes subsystem 230 that executes applications 225 written for many different types of operating systems. While the subsystem 230 in user mode 235 is limited to certain system resources, kernel mode 240 typically has unrestricted access to system memory and external devices. User mode 235 includes a subsystem that can pass I/O requests to the appropriate kernel mode device driver 200 by using I/O manager 120.

The operating system supports a shared library, known as a dynamic link library, which is a code library that can be used by multiple processes with only one copy loaded in memory. For example, NTDLL. DLL 215 exports Windows native APIs (the interfaces used by operating system user mode components that must run without support from Win32 or other API subsystems). NTDLL. The DLL 215 is a file created by an operating system having a description of "NT Layer DLL", and is a file including an NT kernel function. In one embodiment, NTDLL. DLL 215 may be located in the c:\Windows\system32 or c:\winnt\system32 directory, and may be found in the c:\i386 directory.

Kernel mode API 210 interfaces with I/O manager 120 (described above with respect to FIG. 1) and filter manager 125. The kernel mode device driver 200 is a program for operating and controlling a specific type of device attached to the management node 100. The kernel is described above with respect to FIG. Graphics driver 205 refers to software used by the operating system in kernel mode 240 to communicate with a particular graphics device. The hardware abstraction layer is described above with respect to FIG.

In one embodiment, application 225 may include one or more threads of execution. When running on ring 3 (user mode 235), application 225 (thread) may request system services such as WriteFile(). NTDLL. DLL 215 may call the SysEnter x86 instruction, changing the thread's context from user mode 235 to kernel mode 240. A context switch may occur when the kernel scheduler switches the processor (or core) from one thread to another thread. In this case, the thread is only changed from ring 3 to ring 0. It stays on the same processor or core. The higher priority thread may be assigned to the processor of the previous thread (context switch). In one embodiment, a context switch occurs when two threads change state. Interrupts may be generated on other architectures. Each thread has two stacks, one for user mode 235 and one for kernel mode 240. An interrupt is generated and then the thread kernel executes a kernel mode native API 210 such as NtWriteFile() or ZwWriteFile().

In one embodiment, the operating system may create processes for the application 225 when the application 225 executes in the user mode 235. The process provides the application 225 with a private virtual address space and a private handle table. Since the virtual address space of an application is private, one application cannot change the data belonging to another application. Each application 225 runs in isolation and if a user mode application crashes, the crash is limited to that one application. Other applications and operating systems are unaffected by the crash. In one embodiment, each thread in kernel mode 240 shares a single virtual address space. Therefore, all kernel mode threads and user mode threads are visible.

In one embodiment, the processor may provide multiple levels of security. For 32-bit and 64-bit Intel and AMD processors, the kernel 165 may execute in the most privileged ring 0. All user applications 225 run in ring 3 and request kernel services via the dynamic link library (DLL) system. All user mode 235 requests are NTDLL. The DLL 215 is used to modify certain function parameters and SysEnter is used to switch the requesting thread from ring 3 to ring 0. The dispatcher receives the request and passes it to the executive's service. The scheduler rechecks threads that are ready to run. A lower priority thread may be preempted during a privileged mode request from a user that causes a context switch.

Exemplary Filter Manager and Mini Filter Driver FIG. 3 illustrates an exemplary filter manager 125 and mini filter drivers 320, 325, and 330 for real-time detection of malware and protection from malware, according to an embodiment. In other embodiments, the configuration comprises additional or fewer components than those described herein. Similarly, functionality may be distributed among components and/or different entities in a different manner than described herein.

An application 225 or process running in user mode 235 on processor 310 may generate user request 300 (eg, a file operation request such as a file open request). In one embodiment, the process 225 in user mode 235 makes a call to create a file with the Windows API. This call triggers a user request 300 for file I/O (eg, Windows NT API call). Request 300 is NTDLL. Proceed through DLL 215. The I/O manager 120 detects the file operation request 300 initiated by the process 225 executing in the user mode 235. In one embodiment, I/O manager 120 may be part of the Windows operating system. The I/O manager 120 identifies where the target file is located (eg, D:\drive) and determines whether the driver is interested in intercepting the file open request 300. Send the message to 125. The filter manager 125 is attached to a particular file system and a particular volume.

In one embodiment, the filter manager 125 is initialized in kernel mode 240. From the file handle corresponding to the file operation request 300, the filter manager 125 may determine whether the file operation request 300 corresponds to a predetermined operation, such as a file open request. Filter manager 125 is a kernel-mode driver that presents the functionality typically required in file system filter drivers. Mini filter drivers (eg, mini filter driver A320) may be written to use this functionality, thereby creating higher quality, more robust drivers and shortening the development process. A file handle (sometimes called a file descriptor) is an abstract indicator (eg, number) used to access a file or other I/O resource such as a pipe or network socket. When a file is opened, the type of file access required, such as read, write, share, and exclusive is determined. The mini-filter driver A320 or C330 performs the handle addition step. The handle addition step determines whether the file handle is a predetermined one and stores it in the tree. If it's writing the buffer with strong encryption, it's expected. If the handle is not the given one, it can be ignored.

The file operation request 300 is intercepted in response to determining that the file operation request 300 corresponds to a predetermined operation. In one embodiment, the filter manager 125 intercepts the file operation request 300 by determining whether a mini filter driver (eg, mini filter driver A320) is registered to intercept the file operation request. The mini-filter driver A320 may be pre-registered with the filter manager 125 for certain events (eg file open (fopen), read, write, close, rename). In response to determining that the mini filter driver A 320 is registered to intercept the file manipulation request, the filter manager 125 sends a file manipulation request 300 to the mini filter driver A 320.

In one example, the filter manager 125 checks if a mini filter driver (eg, mini filter driver A320) is interested in intercepting the request 300. The filter manager 125 may identify the mini filter driver A320 by a callback. First, the mini-filter driver A320 does registration, which then identifies which event is of interest. The operation may be implemented as follows.

Malware detection analysis is performed on the file buffer associated with the detected file manipulation request 300 to detect behavior indicative of the presence of malware. The minifilter driver in kernel mode 240 performs malware detection analysis on the file buffer to detect unauthorized/suspicious behavior. Malware detection analysis may include Monte Carlo approximation, entropy, and/or sequence coefficient analysis. The analysis includes determining whether the data in the file buffer is encrypted. For example, suspicious write operations may be detected. The minifilter driver may read data directly from the operating system buffer to increase performance and reduce statistical analysis overhead. Malware analysis uses the statistical techniques described above with respect to FIG. 1 to determine if a file is encrypted. The "kernel buffer analysis" step may perform ransomware and malware analysis. Part of the steganographic analysis may be performed. Therefore, steganography may be performed by multiple entities, such as static (scan), dynamic (real-time), firewall, smtp server, etc.

In response to detecting the behavior indicative of the presence of malware, the process 225 responsible for initiating the detected file manipulation request 300 is identified. The mini filter driver A320 performs malware analysis regarding the write operation. The mini-filter driver A320 handles pre-file access operations (file read/write requests). The filter manager 125 sends a call to the mini filter driver A 320, which determines the combination of chi-square, entropy, sequence coefficient correlation, and Monte Carlo pie approximation, which should proceed with the file open operation 300. Decide whether or not. The mini-filter driver A320 can analyze the write as it already has the write data in the operating system kernel I/O buffer. The mini-filter driver A320 analyzes the write buffer for malware state changes. Data is written only when a major malware detection analysis is done and it is determined that the data is not encrypted. If the malware analysis does not show strong encryption, then a successful FileWrite() operation is allowed.

The mini filter driver C330 performs malware analysis regarding reading. The mini filter driver C330 also handles post file access operations. It analyzes the read buffer for malware state changes. There is no state change (write) to the system before the request 300 reaches the mini filter driver C330. If the minifilter driver A320 or C330 detects a state change indicative of malware, they can stop the file operation 330. If the mini-filter driver C330 approves the "fread" operation, the filter manager 215 sends a request to the file system driver 305, which sends the I/O request packet to the storage driver stack 315. send. The file system driver 305 is a file system driver for removable media (for example, a CD-ROM), a file system driver based on the Windows inbox FastFAT file system used as a model for a new file system, a transaction for inspecting data in a file. It may be a compatible file scanner or the like. The minifilter driver C330 is called again to inspect the buffer and send an acknowledgment to the filter manager 125.

When the data is read using the processor 310, the IRP is returned to the filter manager. Minifilter C examines the data at the IRP. For example, if the driver analyzes the write buffer before a write operation, it will allow entropy, chi-square, Monte Carlo Pi approximations, serial correlation coefficients, means, standard deviations, and other statistical values to allow it. Not detect data encryption, data deletion, or suspicious behavior. Minifilter A protects against malware that writes encrypted data to files on disk 155 based on these statistics. Minifilter C helps identify previously encrypted data and builds whitelists and blacklists from the process of reading the data. Minifilter A protects the data from being encrypted, but minifilter C cannot decrypt the encrypted data, so it identifies the process that is using the file. Minifilter A may best be described as pre-write operation detection and minifilter C as post-read operation detection. The system registers to update and maintain its data structure for pre and post operations.

The mini filter driver B325 is a third party driver. The disclosed embodiments may use the minifilter driver B325 to detect malware that attempts to delete files, rename files, or change directories.

A search for the identified process 225 is performed in one or more of the program blacklist and the program whitelist to determine if the identified process 225 is a trusted process. A program blacklist may include known malicious or suspicious programs that should not be authorized to access or execute (execute). These programs typically include malicious software such as viruses, Trojan horses, worms, spyware, keyloggers, and other forms of malware. Programs that are blacklisted also include users, business applications, processes, IP addresses, and organizations known to pose a threat to businesses or individuals.

The program white list may include a list of acceptable entities (software applications, email addresses, users, processes, devices, etc.) that are allowed access to the management node 100. The whitelist may identify the applications 225 based on their filename, size, and directory path. In one embodiment, the whitelist may use a combination of cryptographic hashing techniques and digital signatures associated with the manufacturer or developer of each component or software 225.

In one example, the management node 100 may determine that the identified process 225 is not a trusted process by identifying the identified process 225 on the program's blacklist. The management node 100 sends information describing the malware to the client device. In one example, the management node 100 may determine that the identified process 225 is a trusted process by identifying the identified process 225 on the whitelist of programs. In that case, the mini-filter driver ignores the detected file operation request.

Since minifilter driver A320 and minifilter driver B330 execute in kernel mode 240, they can determine which process is changing the state of the file. If the file is encrypted or a large amount of data has been deleted, the management node 100 may ask the user if he wants to allow the process 225 to change the state of the file system. If the user approves the operation, it is accepted and the SHA256 hash of the processed image is optionally stored in a whitelist. If the process is malware, the SHA256 hash is blacklisted. The driver checks the blacklist when the process is executed and prevents execution if it is blacklisted.

In one embodiment, the management node 100 may determine if the identified process 225 is a trusted process as follows. In response to not identifying the process 225 on the blacklist of programs or the whitelist of programs, the management node 100 may send a request to the client device asking to authorize the identified process. The management node 100 may generate data that causes the prompt to be presented to the client device in order to query whether the process 300 is authorized, eg, the prompt may include CAPTCHA.

In response to sending a request to the client device to authorize the identified process 225, the management node 100 may receive a message from the client device that the identified process 225 is not authorized. In that case, the identified process 225 is added to the program's blacklist for malware detection. In response to receiving from the client device a message that the identified process 225 is authorized, the identified process 225 may be added to the program's whitelist.

In response to determining that the identified process 225 is not a trusted process, a malware modifying action is performed on the identified process 225. Attack details are logged locally. For example, the mini filter driver A 320 may send a message to the filter manager 215 to stop, suspend, or allow the file operation request 300. In one embodiment, similar techniques are used to inspect inbound files inline with firewall 135. Malware analysis is used to prevent malware from passing through firewall 135 to reach router 145 and switch 150 in the network. In-line embodiments may detect steganography. Any suspicious files are logged and quarantined so the user can restore the files if it was a false positive.

Exemplary Components of Volume Shadow Service FIG. 4 illustrates exemplary components of the Volume Shadow Service (VSS) for real-time detection of malware and protection from malware, according to embodiments. The VSS includes a VSS copy service 400, a VSS requestor 405, a VSS writer 410, and VSS providers 415, 420 and 425. In other embodiments, the VSS comprises additional or fewer components than those described herein. Similarly, functionality may be distributed among components and/or different entities in a different manner than described herein.

Ransomware may try to disable VSS to prevent the recovery of infected or encrypted files. The embodiments disclosed herein use specific data recovery APIs to ensure that a useful backup can be restored to prevent data loss. VSS reads and writes to a configuration database that is encrypted to protect against unauthorized modification. VSS analyzes the device and automatically creates an optimal resource configuration for the device based on core and processor type and current workload. Processor information and memory information are used to configure the size of the thread pool.

Events such as malware detection and removal are written to the local log. Local logs are regularly replicated from the management node 100 and the firewall 135 to a central log server specified by the security manager policy.

Exemplary Data Points for Monte Carlo Pi Approximation FIG. 5 is a diagram illustrating exemplary data points for Monte Carlo pie approximation, according to an embodiment. The Monte Carlo pie approximation may be used to distinguish compressed files from encrypted files. Monte Carlo simulation allows measurement of the randomness of the values in the file. One application of Monte Carlo simulation is to approximate the value of Pi(π) based on the data in the file. The more random the values contained in the file, the more accurate the estimated value of π. The value of Pi(π) is calculated by the ratio of the data points 500 in the inscribed unit circle to the total number of data points 510 in the square.

FIG. 5 shows the total number of data points 500 in the inscribed unit circle and data points 510 in the square. The closer the calculated approximation is to the known value of Pi, the better it represents the randomness of the data values. The perfect encryption algorithm will have completely random values, providing an accurate approximation of Pi. In one embodiment, the system makes the following decisions.
Area of circle (AreaCircle)=πr ²
Square area (AreaSquare)=(2r) ² =4r ²

Suppose radius 505 is one unit and point 500 in the circle is given by (x ² +y ² <=1). Area of circle/area of square=(Pi×radius ² )/(4×radius ² )=Pi/4. Therefore, the number of points 500 inside the circle divided by the total number of points 510 is given by Pi/4.

Exemplary Process for Real-Time Detection of Malware and Protection from Malware FIG. 6 illustrates an exemplary process for real-time detection of malware and protection from malware according to an embodiment. In one embodiment, the process of FIG. 6 is performed by management node 100. Other entities (eg, malware analysis module 140) may perform some or all of the steps of the process in other embodiments. Similarly, embodiments may include different and/or additional steps, or the steps may be performed in a different order.

The management node 100 detects 600 a file operation request 300 initiated by the process 225 executing in the user mode 235. The management node 100 may detect the file operation request 300 by determining from the file handle corresponding to the file operation request 300 whether the file operation request 300 corresponds to a predetermined operation.

The management node 100 performs 605 malware detection analysis on the file buffer associated with the detected file operation request 300 to detect a behavior indicating the presence of malware. Malware detection analysis may include a combination of chi-square, entropy determination, sequence coefficient correlation, and Monte Carlo pie approximation.

In response to detecting the behavior indicative of the presence of malware, the management node 100 identifies 610 the process 225 responsible for initiating the detected file operation request 300.

The management node 100 searches 615 the identified process 225 in one or more of the program blacklist and the program whitelist to determine whether the identified process 225 is a trusted process. decide. A program blacklist may include known malicious or suspicious programs that should not be authorized to access or execute (execute). The program white list may include a list of acceptable entities (software applications, email addresses, users, processes, devices, etc.) that are allowed access to the management node 100.

In response to determining that the identified process 225 is not a trusted process, the management node 100 performs 620 a malware remediation action on the identified process 225, providing information describing the malware to the client device. Send to. The malware modification action may include terminating the write operation associated with the detected file operation request. The malware modification action may include terminating the detected file manipulation request by deleting the detected file manipulation request from memory. The malware remediation action may include quarantining the disk file image associated with the identified process.

Portable Executable (PE) File for Real-time Steganography Detection and Protection from Steganography FIG. 7 illustrates an exemplary portable executable (PE) for real-time steganography detection and protection from steganography in kernel mode, according to an embodiment. ) Indicates the components of the file. The PE format is a file format for executable files, object code, DLLs, FON font files, and others used in 32-bit and 64-bit versions of the Windows operating system. The PE format is a data structure that encapsulates the information needed by the Windows OS loader to manage the wrapped executable code.

The PE header 765 includes a DOS executable header 700 that contains relocation information that allows multiple segments to be loaded at any memory address. The DOS stub 705 is a valid application executed in MS-DOS. It is placed at the beginning of the EXE image. Each row of the section table (eg, 715, 720, and 725) is a section header. The section header may have a NULL 730 terminator. Each section (eg, 735, 745, and 755) may have a NULL terminator.

The embodiments disclosed herein relate to methods of using the PE file format shown in FIG. 7 for real-time steganographic detection and protection from steganography in kernel mode. Steganography may be used to hide malware inside the container. The container may be a picture, movie, audio file, or executable file. Steganography may be used to hide information in picture, mp3, or exe files. For example, a 128 byte text message may be hidden within a 4MB picture. An exe file may be hidden inside another exe file (pack). Malware files may be hidden within pkzip files. A virus drive-by download may occur when a user is visiting a website. Malware may also be sent to users. It may then go to each friend on the user's mailing list, etc., for example with a personalized Christmas card. Malware may encrypt files and remove encryption keys over a period of months. Traditional edge firewalls typically cannot detect files with hidden pictures, messages, or malware that are hidden using steganography because attachments are allowed to pass through the firewall.

Detects sending files through a firewall, operating system, or email system. In one embodiment, PE is parsed. While reading and parsing the PE, the structure of Windows EXE, DLLs, fonts, system drivers, and object code is analyzed for suspicious API usage. An example is the allocation of memory sections with read, write, and execute permissions that may allow a malicious program to be copied into the memory sections and executed. In one embodiment, the Windows API is used to open the file using the fully qualified name of the process (FQFN) provided by calling GetModuleFileNameEx() and CreateFile(). A handle to the image on disk is returned to the caller.

In one embodiment, the size of the PE file is determined and compared to the file size of the stored file. This embodiment may be used to detect whether an image contains unauthorized data such as malicious zip files or attached executables. In this embodiment, the last stored hidden information of the PE file format (eg, EXE, DLL, SCR, SYS, DRV, ACM, CPL, SCR, etc.) may be identified. The file is parsed and analyzed to determine the size of the PE file. The file is opened using the file's fully qualified file name. The DOS header 700 of the file is read from the storage device 155. To determine if the file is an executable file, it is determined whether the DOS header 700 begins with "MZ". The magic number is retrieved from the DOS header 700. The magic number is verified to get a pointer to the section header of the file. For each section of the file that begins with the section header, the section name and attributes are verified. The size of the section is determined. The name and size of each section of the file is determined to determine the size of the file and identify non-standard section names that are often used by malware.

In one embodiment, Winnt. The IMAGE_DOS_HEADER structure in the h SDK header file is read from the storage device 155. The DOS header 700 is the first part of the file. This step determines whether the DOS header 700 starts with MZ "xx xx xx". If the DOS header 700 starts with MZ, it may be a DOS or Windows program. If the DOS header 700 does not start with MZ, it is not an executable (eg, it could be JPG, GIF, etc.). This distinction determines which analysis is applied. The purpose of reading the DOS header 700 is to verify that the file was properly formed. The process is looking for incorrect header creation. The DOS header 700 is static (immutable) and contains a date and a time stamp. The purpose of parsing the DOS header 700 is to detect the creation of bad headers that are not in the existing list of known good headers. The illegal header (PE header) has a pointer to the section with the malware code (illegal instruction). The embodiments disclosed herein distinguish between executable and non-executable files because malware can be hidden as a compressed payload in the executable file. File type determination is used to determine the particular analysis used to detect steganography in the file.

The number "MZ" (first few bytes of the file) is the magic number. The pointer obtained by verifying the magic number leads to the part in the file where the information is located. If the file is not a valid PE file, eg JPEG or GIF, it may be malware. In one embodiment, the magic number is retrieved from the e_magic member in IMAGE_DOS_HEADER. The value “xx xx xx” in the DOS header 700 is used to verify the magic number. The value found is compared to Microsoft DOS IMAGE_DOS_SIGNATURE with the value 0x5A4D ("MZ"). If the value does not match the DOS signature, then the file is not a DOS or Windows executable. Additional instructions may be executed to determine what the format of the file may be, eg, DOC, DOCX, PPT, PPTX, XLS, XLSX, MP3, GIF, JPG, PNG, etc. When the magic number is verified, a pointer to the section header is obtained. Now that the DOS magic number has been verified, the e_lfanew member may be used to create a pointer to the Windows PE header. The IMAGE_NT_HEADERS32 pointer is calculated by adding the size of the memory buffer to the e_lfanew value. The pointer to the PE header should be "01 00h". This location contains the PE signature, which should be the number "50 4500h". If this location is not "50 4500" then the file may be suspicious.

In one embodiment, the pointer may be dereferenced and compared to IMAGE_NT_SIGNATURE (0x00004550). If the value of the dereferenced pointer does not match the IMAGE_NT_SIGNATURE signature, then the file is not a Windows executable. Additional instructions may be executed to determine what the file format may be, eg, DOC, DOCX, PPT, PPTX, XLS, XLSX, MP3, GIF, JPG, PNG, etc.

In one embodiment, the location of IMAGE_SECTION_HEADER is determined using the size of IMAGE_NT_HEADERS32. The IMAGE_NT_HEADER member FileHeader is dereferenced to access the IMAGE_FILE_HEADER containing the number of sections in the PE image. A counter variable is initialized to zero so that each section can be analyzed. The process determines if the number of sections is expected. The additional sections are suspicious and may contain malware. For each section, the section name and attributes are verified. The size of the file is determined as the size of the SizeOfRawData member of the section and the pointer. This process may be repeated for each section. The size of the last section is the number of bytes in the SizeOfRawData member. The result is the number of bytes that the PE image should occupy on the storage device. The section by section analysis is used to calculate the overall size of the file.

The stored file size of the file is retrieved from the file system. In one embodiment, the operating system retrieves the file size stored on the disk from the file system using the GetFileSize() API.

The determined size of the file is compared to the stored file size of the file. In one embodiment, the data may be appended to the PE file if the determined size of the file is larger than the stored file size. If the return code indicates that there is no data to append, then the PE size is equal to the stored file size (no data to append to the PE file). This indicates the presence of additional data when the determined file size is larger than the stored file size.

Steganographic detection analysis is performed on the file in response to the determined size of the file being greater than the stored file size of the file. In one embodiment, the appended data is analyzed to determine its file format and whether it is encrypted. The return code indicates that the data has been added, so a defined policy such as quarantine, delete, or remove the added data may be enforced. Steganographic detection analysis involves performing statistical functions (entropy, chi-square, etc.) on a file. The analysis performed depends on the file type. In the case of a GIF file, hidden data hidden in the ZIP file is searched. For EXE files, different analyzes may be performed. Information beyond the end of the exe file is used to perform entropy, chi-square, median, and standard deviation calculations to detect encryption.

In one embodiment, static analysis algorithms are used to detect steganography. The benefit and advantage of this approach is that steganographic detection may be performed without using signature scanning. The presence of hidden information is detected in either inbound or outbound data. A comparison between the determined size of the file and the stored file size is used to determine if a more expensive analysis should be done. The file size comparison determines if there is an attached payload. No expensive analysis is done when the file size comparison shows that the file size is normal. Thus, by detecting steganography in-line with the firewall on the device, dangerous files can be detected, quarantined, and removed before they can release their secret payload. In other embodiments, steganographic detection may be integrated with firewall 135 or email.

Steganographic correction actions are performed in response to the steganographic detection analysis indicating the presence of steganography in the file. Information describing steganography is sent to the client device.

A further benefit and advantage of the embodiment is that the method integrates steganography and ransomware detection at the firewall to check each packet. The method integrates with the email system to scan the content of each email and attachment. The present invention looks for suspicious instruction sets, eg, machine or assembly level language indications, rather than signatures. In one embodiment, the method partially disassembles the file and looks for such suspicious instruction sets.

Processes for Steganography Real-Time Detection and Steganography Protection in Kernel Mode FIG. 8 illustrates an exemplary process for steganography real-time detection and steganography protection in kernel mode, according to an embodiment. In one embodiment, the process of FIG. 8 is performed by management node 100. Other entities (eg, malware analysis module 140) may perform some or all of the steps of the process in other embodiments. Similarly, embodiments may include different and/or additional steps or perform steps in a different order.

The management node 100 detects 800 the transmission of a file through a firewall, operating system, or email system. In one embodiment, PE is parsed. While reading and parsing the PE, the structure of Windows EXE, DLLs, fonts, system drivers, and object code is analyzed for suspicious API usage.

The management node 100 determines 805 the size of the file. File sizing may be used to detect if the image contains unauthorized data such as an attached malicious zip file or executable. For example, the last stored hidden information of the PE file format (eg, EXE, DLL, SCR, SYS, DRV, ACM, CPL, SCR, etc.) may be identified.

The management node 100 retrieves 810 the stored file size of the file from the file system. In one embodiment, the operating system retrieves the file size stored on the disk from the file system using the GetFileSize() API.

The management node 100 compares 815 the determined size of the file to the stored file size of the file. In one embodiment, the data may be appended to the PE file if the determined size of the file is larger than the stored file size. If the return code indicates that there is no data to append, then the PE size is equal to the stored file size (no data to append to the PE file). This indicates the presence of additional data when the determined file size is larger than the stored file size.

In response to the determined size of the file being greater than the stored file size of the file, management node 100 performs 820 a steganographic detection analysis on the file. Steganographic detection analysis involves performing statistical functions (entropy, chi-square, etc.) on a file. The analysis performed depends on the file type. In the case of a GIF file, hidden data hidden in the ZIP file is searched. For EXE files, different analyzes may be performed. Information beyond the end of the exe file is used to perform entropy, chi-square, median, and standard deviation calculations to detect encryption.

In response to the steganographic detection analysis indicating the presence of steganography in the file, the management node 100 performs steganographic correction actions 825 and sends information describing the steganography to the client device. Steganographic correction actions may include terminating the processing and transmission of files attempting to pass through the firewall. Steganographic modification actions may include quarantining the file.
Alternative Embodiments In an alternative embodiment, the methods and systems disclosed herein provide protection and privacy for sensitive data stored locally on the management node 100 or in the cloud (eg, cloud host 105). It may be used to strengthen. These alternative embodiments may be used to detect and/or prevent unauthorized export of sensitive data across preset geographical boundaries. For example, embodiments may be used to tag sensitive data in a particular geographic area and lock the data in place to monitor unauthorized export and/or access of data from that geographic area. And may be prevented. Accordingly, alternative embodiments may provide the user with greater control over the data subject's personal data, the export of personally identifiable information. Alternate embodiments also provide companies with methods to prevent data processing unless done on a legal basis specified by regulation, and efficient reporting of data breaches.
In addition, alternative embodiments allow businesses to provide pseudonymization and/or complete data anonymization when data is stored. In one embodiment, the stored private data may be encrypted such that the resulting private encrypted data cannot be attributed to a particular data subject without the correct decryption key. In one embodiment, tokenization may be implemented, which replaces sensitive data with non-confidential surrogates (tokens) that have no extrinsic or exploitable meaning or value. Tokenization does not change the type or length of data, that is, it can be handled by legacy systems such as databases, which can be sensitive to the length and type of data. The advantage and benefit of this approach is that it requires less computational resources and less storage space than traditional encrypted data. Malware or steganographic attacks on protected data are detected and prevented using the disclosed embodiments, including performing malware or steganographic detection analysis on the files associated with the detected file manipulation request. It is possible to

Exemplary Machine FIG. 9 is a block diagram illustrating components of an exemplary machine capable of reading instructions from a machine-readable medium and executing them on a processor or controller. Specifically, FIG. 9 shows a schematic diagram of a machine in the exemplary form of computer system 900. Computer system 900 is used to execute instructions 924 (eg, program code or software) to cause a machine to perform any one or more of the methodologies (or processes) described herein. It is possible. In alternative embodiments, it operates as a stand-alone device or a connected (eg, networked) device that connects to other machines. In a networked arrangement, the machines may operate as server or client machines in a server/client network environment or as peer machines in a peer-to-peer (or distributed) network environment.

In one embodiment, a non-transitory computer-readable medium stores instructions that, when executed by at least one processor, cause the processor to perform the operations described herein. The machine is a server computer, a client computer, a personal computer (PC), a tablet PC, a set top box (STB), a smartphone, an Internet of Things (IoT) device, a network router, a switch or bridge, or an action performed by the machine. May be any machine capable of executing the instructions 924 (sequential or other form) specifying Further, although only a single machine is shown, the term “machine” refers to a machine that individually or jointly executes instructions 924 implementing any one or more of the methodologies discussed herein. It should be considered to include any set.

Exemplary computer system 900 includes one or more processing units (typically processor 902). The processor 902 may be, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a controller, a state machine, one or more application specific integrated circuits (ASIC), one or more. Multiple Radio Frequency Integrated Circuits (RFICs), or any combination thereof. Computer system 900 also includes a main memory 904. The computer system may include a storage unit 916. Processor 902, memory 904, and storage unit 916 communicate via bus 908.

In addition, computer system 900 can include static memory 906, display driver 910 (eg, driving a plasma display panel (PDP), liquid crystal display (LCD), or projector). Computer system 900 also includes alphanumeric input device 912 (eg, keyboard), cursor control device 914 (eg, mouse, trackball, joystick, motion sensor, or other pointing device), signal generating device 918 (eg, speaker), and , And may also include a network interface device 920 configured to communicate via bus 908.

Storage unit 916 includes a machine-readable medium 922 having instructions 924 (eg, software) stored thereon embodying any one or more of the methodologies or features described herein. Instructions 924 may also reside entirely or at least partially in main memory 904 or processor 902 (eg, in the processor's cache memory) during its execution by computer system 900, and main memory 904 and processor 902 also. Configure a machine-readable medium. The instructions 924 may be sent or received over the network 926 via the network interface device 920.

Although machine-readable medium 922 is shown as a single medium in the exemplary embodiment, the term “machine-readable medium” refers to a single medium or multiple media (eg, centralized media) in which instructions 924 may be stored. Or should be considered to include distributed databases or associated caches and servers). The term “machine-readable medium” also refers to any medium that can store instructions 924 for execution by a machine, causing the machine to perform any one or more of the methodologies disclosed herein. Should be taken to include. The term "machine-readable medium" includes, but is not limited to, data repositories in the form of solid state memory, optical media, and magnetic media.

Additional Considerations Throughout this specification, multiple instances may implement the components, acts, or structures described as a single instance. Although individual acts of the one or more methods are shown and described as separate acts, one or more of the individual acts may occur simultaneously, and the acts need not occur in the order shown. .. Structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements are within the scope of the subject matter herein.

Certain embodiments are described herein as including logic or some component, module, or mechanism, as illustrated and described in FIGS. 1-4, 6-7, and 9, for example. ing. Modules may comprise either software modules (eg, code embodied in a machine-readable medium) or hardware modules. A hardware module is a tangible unit that can perform a specific operation, and may be configured or arranged in a specific manner. In an exemplary embodiment, one or more computer systems (eg, stand-alone, client, or server computer systems), or one or more hardware modules (eg, a processor or group of processors) of a computer system are It may be configured by software (eg, an application or application part) as a hardware module that operates to perform a particular operation as described herein.

In various embodiments, hardware modules may be implemented mechanically or electronically. For example, a hardware module is a dedicated circuit or logic permanently configured as a dedicated processor, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), to perform a particular operation. May be included. A hardware module may also include programmable logic or circuits (eg, contained within a general purpose processor or other programmable processor) temporarily configured by software to perform certain operations. Whether the hardware module is implemented mechanically, in a dedicated permanently configured circuit, or in a temporarily configured circuit (eg, configured by software) costs and It will be appreciated that it may be time sensitive.

Various operations of the exemplary methods described herein may be performed by one or more processors, temporarily (e.g., software) or permanently configured (eg, by software) or permanently configured to perform the operations. At least in part by processor 902. Such a processor, whether configured temporarily or permanently, may constitute a module implemented in a processor that operates to perform one or more operations or functions. .. Modules referred to herein include processor-implemented modules, in some example embodiments.

One or more processors may operate in a “cloud computing” environment or as “software as a service” (SaaS) to support performing the applicable operations, eg, at least some of them. The acts may be performed by a group of computers (as an example of a machine that includes a processor) over the network (eg, the Internet) and at one or more suitable interfaces (eg, an application program interface). (API)).

Execution of a particular operation may be distributed among one or more processors not only residing in a single machine, but distributed across several machines. In some exemplary embodiments, one or more processors or modules implemented with processors may be located in a single geographical location (eg, in a home environment, office environment, or server farm). In other exemplary embodiments, one or more processors or modules implemented in processors may be distributed over several geographic locations.

Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bit or binary digital signals in machine memory (eg, computer memory). These algorithms or symbolic representations are examples of techniques used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an "algorithm" is a consistent sequence of operations or similar process that leads to a desired result. In this context, algorithms and operations include physical manipulations of physical quantities. Typically, though not necessarily, such quantities may take the form of electrical, magnetic, or optical signals that may be stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. .. "Data", "Content", "Bits", "Values", "Elements", "Symbols", "Characters", "Terms", "Numbers", or "Numbers", mainly for reasons of common usage It may be convenient to refer to such signals using words such as. However, these words are only convenient labels and will be associated with the appropriate physical quantity.

Unless stated otherwise, the description herein using terms such as "process," "compute," "calculate," "determine," "present," or "display" refers to one or more memory ( For example, physically (eg, electronically, magnetically, or optically) within volatile memory, non-volatile memory, or combinations thereof, registers, or other machine components that receive, store, send, or display information. ) May refer to a machine (eg, computer) action or process that manipulates or transforms data expressed as a quantity.

As used herein, a reference to "one embodiment" or "an embodiment" is included in at least one embodiment in which a particular element, feature, structure, or characteristic described in connection with the embodiment is included. Means to be The appearances of the phrase "in one embodiment" in various places in this specification are not necessarily all referring to the same embodiment.

Some embodiments may be described using the expressions "coupled" and "connected" with their derivatives. For example, some embodiments may be described using the term "coupled" to refer to two or more elements that are in direct physical or electrical contact. However, the term “coupled” may mean that two or more elements are not in direct contact with each other but cooperate or interact with each other. Embodiments are not limited to this context.

As used herein, the terms "comprising," "comprising," "including," "including," "having," "having," or any other variation thereof, refer to It is intended to include non-exclusive inclusion. For example, a process, method, article, or device that includes a list of elements is not necessarily limited to only those elements, is not explicitly listed, or is unique to such process, method, article, or device. It may include other elements. Further, unless stated to the contrary, "or" refers to inclusive or, not exclusive or. For example, condition A or B is A is true (or present) B is false (or not present), A is false (or not present) B is true (or present) , And both A and B are true (or present).

Also, the use of "a" or "an" is employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the claimed invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

Those of skill in the art will understand, upon reading this disclosure, still additional alternative structure and functional designs for systems and processes for detecting malware through the principles disclosed herein. Thus, while particular embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise constructions and components disclosed herein. Various modifications, changes, and variations in the arrangement, operation, and details of the methods and devices disclosed herein that become apparent to those skilled in the art depart from the spirit and scope defined by the appended claims. May be done without doing.

Claims (40)

A method for real-time detection and protection from malware in kernel mode, comprising:
Detecting a file operation request initiated by a process running in user mode,
Performing a malware detection analysis on a file buffer associated with the detected file manipulation request to detect behavior indicative of the presence of malware;
Identifying the process responsible for initiating the detected file manipulation request in response to detecting the behavior indicative of the presence of the malware;
Performing a search for the identified process in one or more of a program blacklist and a program whitelist to determine if the identified process is a trusted process;
In response to determining that the identified process is not a trusted process,
Performing a malware remediation action on the identified process;
Sending information describing the malware to a client device. The step of detecting the file operation request comprises:
Determining from the file handle corresponding to the file operation request whether the file operation request corresponds to a predetermined operation;
Intercepting the file manipulation request in response to determining that the file manipulation request corresponds to a predetermined action. The step of intercepting the file operation request comprises:
Determining by the filter manager whether the mini filter driver is registered to intercept file operation requests;
Sending the file operation request to the minifilter driver by the filter manager in response to determining that the minifilter driver is registered to intercept the file operation request. The method according to claim 2, wherein The step of performing the malware detection analysis performs one or more of Monte Carlo approximation, entropy determination, sequence coefficient analysis, arithmetic mean determination, chi-square determination, and standard deviation determination to ensure that the data in the file buffer is The method of claim 1 including the step of determining if it is encrypted. The step of determining that the identified process is not a trusted process comprises:
Further comprising identifying the identified process on the blacklist of programs,
The steps of performing the malware remediation action include:
Terminating the write operation associated with the detected file operation request;
Terminating the detected file operation request by deleting the detected file operation request from memory;
Quarantining the disk file image associated with the identified process. The method of claim 1, further comprising ignoring the detected file manipulation request by a minifilter driver in response to identifying the identified process on the whitelist of programs. the method of. The step of determining whether the identified process is a trusted process may be performed by the client device in response to not identifying the process on the blacklist of programs or the whitelist of programs. The method of claim 1, further comprising sending a request to authorize the identified process. The step of determining that the identified process is not a trusted process is responsive to the sending the request to authorize the identified process to the client device. The method of claim 7, further comprising receiving a message that a process is not allowed from the client device. 9. The method of claim 8, further comprising adding the identified process to the blacklist of programs. The method of claim 1, further comprising adding the identified process to the whitelist of programs in response to receiving a message from the client device that the identified process is authorized. The method described in. A non-transitory computer readable medium having instructions stored therein, when the instructions are executed by at least one processor:
Detecting file operation requests initiated by processes running in user mode;
Performing a malware detection analysis on a file buffer associated with the detected file manipulation request to detect behavior indicative of the presence of malware;
Identifying the process responsible for initiating the detected file manipulation request in response to detecting the behavior indicative of the presence of the malware;
Performing a search for the identified process in one or more of a program blacklist and a program whitelist to determine whether the identified process is a trusted process;
In response to determining that the identified process is not a trusted process,
Performing malware remediation actions on the identified process;
A non-transitory computer-readable medium for causing information describing the malware to be transmitted to a client device. The instructions causing the at least one processor to detect the file manipulation request cause the at least one processor to:
Determining from the file handle corresponding to the file operation request whether the file operation request corresponds to a predetermined operation;
The non-transitory computer of claim 11, further comprising instructions for intercepting the file operation request in response to determining that the file operation request corresponds to a predetermined operation. A readable medium. The instruction causing the at least one processor to intercept the file operation request causes the at least one processor to:
Determining by the filter manager whether the mini filter driver is registered to intercept file operation requests;
Causing the filter manager to send the file operation request to the minifilter driver in response to determining that the minifilter driver is registered to intercept the file operation request. The non-transitory computer readable medium of claim 12, further comprising instructions. The instructions that cause the at least one processor to perform the malware detection analysis cause the at least one processor to:
Performing one or more of Monte Carlo approximation, entropy determination, sequence coefficient analysis, arithmetic mean determination, chi-square determination, and standard deviation determination to determine whether the data in the file buffer is encrypted. The non-transitory computer readable medium of claim 11, further comprising instructions for causing: The instructions causing the at least one processor to determine that the identified process is not a trusted process include:
Further comprising instructions causing identification of the identified process on the blacklist of programs,
The instructions causing the at least one processor to perform the malware modifying action cause the at least one processor to:
Terminating the write operation associated with the detected file operation request;
Terminating the detected file operation request by deleting the detected file operation request from memory;
The non-transitory computer readable medium of claim 11, further comprising instructions for causing a disk file image associated with the identified process to be isolated. Said at least one processor, when executed by said at least one processor,
Further storing instructions causing a minifilter driver to ignore the detected file manipulation request in response to identifying the identified process on the whitelist of programs. The non-transitory computer readable medium of claim 11. The instructions causing the at least one processor to determine whether the identified process is a trusted process may cause the at least one processor on the blacklist of programs or the whitelist of programs. 13. The method of claim 11, further comprising instructions for causing the client device to send a request to authorize the identified process in response to not identifying the process in. Non-transitory computer-readable medium. The instructions causing the at least one processor to determine that the identified process is not a trusted process include:
And further instructing the client device to receive a message from the client device that the identified process is not authorized in response to sending the request to authorize the identified process. 18. The non-transitory computer readable medium of claim 17, comprising: Said at least one processor, when executed by said at least one processor,
The non-transitory computer readable medium of claim 18, further storing instructions that cause the identified process to be added to the blacklist of programs. Said at least one processor, when executed by said at least one processor,
Storing further instructions in response to receiving a message from the client device that the identified process has been authorized to cause the identified process to be added to the whitelist of programs. A non-transitory computer-readable medium as recited in claim 11. A method for real-time detection of steganography and protection from steganography in kernel mode, comprising:
Detecting the sending of the file through a firewall, operating system, or email system;
Determining the size of the file,
Retrieving the stored file size of said file from a file system;
Comparing the determined size of the file with the stored file size of the file;
Performing steganographic detection analysis on the file in response to the determined size of the file being greater than the stored file size of the file;
In response to the steganographic detection analysis indicating the presence of steganography in the file,
Performing steganographic correction actions, and sending information describing said steganography to a client device. The step of determining the size of the file comprises:
Obtaining a pointer for a section header of the file, the section header being associated with a plurality of sections of the file;
Determining, for each section of the plurality of sections of the file, a size of the section;
22. Summing the sizes of each section of the plurality of sections of the file to determine the size of the file. The step of obtaining the pointer to the section header of the file comprises:
Opening the file using the file name of the file or the path of the file;
Reading the header of the file,
Extracting the magic number from the header,
23. Validating the magic number to obtain a pointer for the section header of the file. The step of performing the steganographic detection analysis on the file comprises:
Identifying the added payload in the file,
Analyzing the appended payload to determine a file format for the appended payload;
Performing the steganographic detection analysis based on the file format of the appended payload. The step of performing the steganographic detection analysis on the file comprises:
Identifying the added payload in the file,
Perform one or more of Monte Carlo approximation, entropy decision, sequence coefficient analysis, arithmetic mean decision, chi-square decision, and standard deviation decision to determine if the data in the appended payload is encrypted. 22. The method of claim 21, comprising the step of: The step of performing the steganographic detection analysis on the file comprises:
Identifying the added payload in the file,
22. Identifying the presence of unauthorized data in the appended payload. The step of performing the steganographic detection analysis on the file comprises:
Identifying the added payload in the file,
22. Identifying the presence of assembly-level or machine-level instructions within the appended payload. The steps of performing the steganographic correction action include:
Terminating the processing and transmission of the file,
22. Quarantining the file. A non-transitory computer readable medium having instructions stored therein, when the instructions are executed by at least one processor:
Detecting the sending of files through a firewall, operating system, or email system;
Determining the size of the file;
Retrieving the stored file size of said file from the file system;
Comparing the determined size of the file with the stored file size of the file;
Performing steganographic detection analysis on the file in response to the determined size of the file being greater than the stored file size of the file;
In response to the steganographic detection analysis indicating the presence of steganography in the file,
A non-transitory computer-readable medium that causes a steganographic modifying action to be performed and information describing the steganography to be transmitted to a client device. The instructions causing the at least one processor to determine the size of the file cause the at least one processor to:
Obtaining a pointer for a section header of the file, the section header being associated with a plurality of sections of the file;
Determining, for each section of the plurality of sections of the file, a size of the section;
30. The non-transitory computer readable medium of claim 29, further comprising instructions for summing the sizes of each section of the plurality of sections of the file to determine the size of the file. Medium. The instruction causing the at least one processor to obtain the pointer for the section header of the file causes the at least one processor to:
Opening the file using the file name of the file or the path of the file;
Reading the header of the file,
Extracting the magic number from the header,
31. The non-transitory computer-readable medium of claim 30, comprising instructions for verifying the magic number and obtaining a pointer for the section header of the file. The instructions causing the at least one processor to perform the steganographic detection analysis on the file cause the at least one processor to:
Identifying an added payload in the file;
Analyzing the appended payload to determine a file format for the appended payload;
30. The non-transitory computer readable medium of claim 29, including instructions for performing the steganographic detection analysis based on the file format of the appended payload. The instructions causing the at least one processor to perform the steganographic detection analysis on the file cause the at least one processor to:
Identifying an added payload in the file;
Perform one or more of Monte Carlo approximation, entropy decision, sequence coefficient analysis, arithmetic mean decision, chi-square decision, and standard deviation decision to determine if the data in the appended payload is encrypted. 30. The non-transitory computer readable medium of claim 29, including instructions for causing the:. The instructions causing the at least one processor to perform the steganographic detection analysis on the file cause the at least one processor to:
Identifying an added payload in the file;
30. The non-transitory computer readable medium of claim 29, comprising instructions for causing the presence of unauthorized data in the appended payload to be identified. The instructions causing the at least one processor to perform the steganographic detection analysis on the file cause the at least one processor to:
Identifying an added payload in the file;
30. The non-transitory computer-readable medium of claim 29, comprising instructions for identifying the presence of assembly-level instructions or machine-level instructions in the appended payload. The instructions causing the at least one processor to perform the steganographic correction action cause the at least one processor to:
Terminating the processing and transmission of the file,
30. The non-transitory computer readable medium of claim 29, including instructions for causing the file to be quarantined. A computer system,
At least one computer processor,
A non-transitory computer-readable medium storing instructions,
The instructions, when executed by the at least one computer processor, cause the at least one processor to:
Detecting the sending of files through a firewall, operating system, or email system;
Determining the size of the file;
Retrieving the stored file size of said file from the file system;
Comparing the determined size of the file with the stored file size of the file;
Performing steganographic detection analysis on the file in response to the determined size of the file being greater than the stored file size of the file;
In response to the steganographic detection analysis indicating the presence of steganography in the file,
A computer system that causes a steganographic correction action to be performed and to send information describing the steganography to a client device. The instructions causing the at least one computer processor to determine the size of the file cause the at least one computer processor to:
Obtaining a pointer for a section header of the file, the section header being associated with a plurality of sections of the file;
Determining, for each section of the plurality of sections of the file, a size of the section;
38. The computer system of claim 37, including instructions to sum the sizes of each section of the plurality of sections of the file to determine the size of the file. The instructions causing the at least one computer processor to obtain the pointer for the section header of the file cause the at least one computer processor to:
Opening the file using the file name of the file or the path of the file;
Reading the header of the file,
Extracting the magic number from the header,
39. The computer system of claim 38, including instructions for verifying the magic number and obtaining a pointer for the section header of the file. The instructions causing the at least one computer processor to perform the steganographic detection analysis on the file cause the at least one computer processor to:
Identifying an added payload in the file;
Analyzing the appended payload to determine a file format for the appended payload;
38. The computer system of claim 37, including instructions for performing the steganographic detection analysis based on the file format of the appended payload.

Images