Systems and methods for countering persistent malware
The system constructs entity maps of interrelated software entities to detect and combat persistent malware by updating maps during system restarts and access events, addressing the challenge of complex cyber threats that evade conventional detection.
Patent Information
- Authority / Receiving Office
- HK · HK
- Patent Type
- Applications
- Current Assignee / Owner
- BITDEFENDER IPR MANAGEMENT
- Filing Date
- 2026-05-06
- Publication Date
- 2026-07-17
AI Technical Summary
Conventional malware detection methods struggle to identify sophisticated malware that distributes malicious activities across multiple software agents, evading detection by separating actions over long periods, and existing systems fail to reconstruct complex cyber threats that persist across multiple computing sessions.
A computer system and method that constructs entity maps of interrelated software entities, updating these maps during system restarts and access events, and uses a malware detection engine to determine malware presence based on these maps, incorporating behavior analysis and signature matching.
Effectively detects and combats persistent malware by reconstructing malicious chains across multiple entities and sessions, enhancing the resilience of computer systems against advanced cyber threats.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202480056331.9 (22) Application Date 2024.08.27 (30) Priority Data 18 / 461,134 2023.09.05 US (85) PCT International Application Entering National Phase Date 2026.03.03 (86) PCT International Application Application Data PCT / EP2024 / 073954 2024.08.27 (87) PCT International Application Publication Data WO2025 / 051589 EN 2025.03.13 (71) Applicant: Bitvane Intellectual Property Management Ltd. Address: Nicosia, Cyprus (72) Inventors: Radu-Marian Portase G.F. Hasmasan A. Hajimasan (74) Patent Agency: Beijing Lvmeng Intellectual Property Agency Co., Ltd. 11287 Patent Attorney: Zhang Shijun (51) Int.Cl. G06F 21 / 56 (2006.01) G06F 21 / 55 (2006.01) (54) Invention Title: System and Method for Combating Persistent Malware (57) Abstract: Some embodiments construct an entity map describing a group of interrelated entities and determine whether a computing device includes malware based on the corresponding entity map. The entity map includes worker entities (e.g., processors) and resource entities (e.g., files) accessed by the corresponding worker entities. Some entity maps are persistently stored and restored in response to a restart, thereby enabling complete reconstruction of the kill chain even when malicious activity is distributed across multiple entities and multiple computing sessions. Some implementations detect infection by comparing the current entity mapping with a signature mapping that describes at least one fragment of a known attack.Claims 3 pages, Description 20 pages, Drawings 16 pages, CN 121773419 A 2026.03.31 CN 1 21 77 34 19 A 1. A computer system comprising at least one hardware processor configured to execute an entity mapping manager and a malware detection engine connected to the entity mapping manager, wherein: the entity mapping manager is configured to construct entity maps specifying groups of interrelated software entities, and is further configured to: selectively retrieve the entity map from a mapping repository based on a specification of whether the entity map contains the resource entity in response to a restart of the computer system and in response to a worker entity currently executing on the computer system attempting to access a resource entity stored on a non-volatile storage device of the computer system; and update the entity map by adding the specification of the worker entity to the entity map, wherein the entity map further includes the specification of another worker entity that was executing on the computer system prior to the restart and a specification of the relationship between the other worker entity and the resource entity; and the malware detection engine is configured to determine whether the computer system contains malware based on the updated entity map. 2. The computer system of claim 1, wherein the resource entity is selected from a group consisting of computer files and operating system registry entries. 3. The computer system of claim 1, wherein the entity map manager is further configured to add the specification of the other resource entity to the entity map in response to another attempt by the worker entity to access the other resource entity. 4. The computer system of claim 1, wherein the entity map manager is configured to, in response to the attempt by the worker entity to access the resource entity: identify the other entity map based on whether the other entity map contains the specification of the worker entity; and, in response, merge the entity map with the other entity map. 5. The computer system of claim 1, wherein the entity map manager is configured to, in response to detecting that a parent worker entity has created a child worker entity: determine whether the parent worker entity has accessed the resource entity; and, in response, if so, add the specification of the child worker entity and the specification of the relationship between the child worker entity and the resource entity to the entity map. 6. The computer system of claim 1, wherein: the specification of the worker entity includes a security flag; the entity mapping manager is configured to set the security flag in response to the worker entity's attempt to access the resource entity; and the malware detection engine is configured to select a detection model from a plurality of detection models based on the current value of the security flag to determine whether the worker entity is malicious.7. The computer system of claim 1, wherein: the specification of the resource entity includes a security flag; and the entity mapping manager is configured to, in response to an attempt to overwrite the content of the resource entity: set the security flag; selectively retrieve the other entity mapping from the mapping repository based on whether the other entity mapping contains the specification of the resource entity; and, in response, delete the other entity mapping. Claims 1 / 3 Page 2 CN 121773419 A 8. The computer system of claim 6, wherein the entity mapping manager is further configured to add the resource entity to the entity mapping in response to the attempt to overwrite the content of the resource entity, in another example. 9. The computer system of claim 1, wherein the entity mapping manager is further configured to save the updated entity mapping to the mapping repository. 10. The computer system of claim 1, wherein the malware detection engine is configured to determine whether the computer system includes malware based on a comparison of the entity mapping with a signature mapping describing a malicious group of mutually related entities. 11. The computer system of claim 1, wherein the malware detection engine is configured to determine whether the computer system contains malware based on a malware indicative score associated with the entity map and collectively characterizing all members of an entity group identified according to the entity map, wherein the score is determined based on the behavior of at least one member of the entity group. 12. A computer security method comprising employing at least one hardware processor to execute an entity map manager and a malware detection engine connected to the entity map manager, wherein: the entity map manager is configured to construct entity maps of specified interrelated groups of software entities; executing the entity map manager comprises employing the at least one hardware processor to: selectively retrieve the entity map from a map repository based on a specification of whether the entity map contains the resource entity, in response to a restart of the computer system and in response to a worker entity currently executing on the computer system attempting to access a resource entity stored on a non-volatile storage device of the computer system; and update the entity map by adding the specification of the worker entity to the entity map, wherein the entity map further includes the specification of another worker entity that was executing on the computer system prior to the restart and a specification of the relationship between the other worker entity and the resource entity; and performing the malware detection comprises employing the at least one hardware processor to determine whether the computer system contains malware based on the updated entity map. 13. The method of claim 12, wherein the resource entities are selected from a group consisting of computer files and operating system registry entries.14. The method of claim 12, wherein executing the entity map manager further comprises adding the specification of the other resource entity to the entity map in response to another attempt by the worker entity to access the other resource entity. 15. The method of claim 12, wherein executing the entity map manager further comprises, in response to the attempt by the worker entity to access the resource entity: identifying the other entity map based on whether the other entity map contains the specification of the worker entity; and, in response, merging the entity map with the other entity map. 16. The method of claim 12, wherein executing the entity map management further comprises, in response to detecting that a parent worker entity has created a child worker entity: determining whether the parent worker entity has accessed the resource entity; and, in response, if so, adding the specification of the child worker entity and the specification of the relationship between the child worker entity and the resource entity to the entity map. 17. The method of claim 12, wherein: the specification of the worker entity includes a security flag; executing the entity map manager further includes setting the security flag in response to the attempt by the worker entity to access the resource entity; and executing the malware detection engine further includes selecting a detection model from a plurality of detection models based on the current value of the security flag to determine whether the worker entity is malicious. 18. The method of claim 12, wherein: the specification of the resource entity includes a security flag; and executing the entity map manager further includes, in response to an attempt to overwrite the contents of the resource entity: setting the security flag, selectively retrieving the other entity map from the map repository based on whether the other entity map contains the specification of the resource entity, and, in response, deleting the other entity map. 19. The method of claim 18, wherein executing the entity map manager further includes another example of adding the resource entity to the entity map in response to the attempt to overwrite the contents of the resource entity. 20. The method of claim 12, wherein executing the entity mapping manager further comprises saving the updated entity mapping to the mapping repository. 21. The method of claim 12, wherein executing the malware detection engine comprises determining whether the computer system contains malware based on a comparison of the entity mapping with a signature mapping describing a malicious group of mutually related entities.22. The method of claim 12, wherein executing the malware detection engine includes determining whether the computer system contains malware based on a malware indicative score associated with the entity map and collectively characterizing all members of an entity group identified according to the entity map, wherein the score is determined based on the behavior of at least one member of the entity group. 23. A non-transitory computer-readable medium storing instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to form an entity mapping manager and a malware detection engine connected to the entity mapping manager, wherein: the entity mapping manager is configured to construct entity maps of specified interrelated groups of software entities, and is further configured to: selectively retrieve the entity map from a mapping repository based on whether the entity map contains a specification of the resource entity, in response to a restart of the computer system and in response to a worker entity currently executing on the computer system attempting to access a resource entity stored on a non-volatile storage device of the computer system; and update the entity map by adding a specification of the worker entity to the entity map, wherein the entity map further includes a specification of another worker entity that was executing on the computer system prior to the restart and a specification of the relationship between the other worker entity and the resource entity; and the malware detection engine is configured to determine whether the computer system contains malware based on the updated entity map. Claims 3 / 3 Page 4 CN 121773419 A Systems and Methods for Combating Persistent Malware Background Art
[0001] This invention relates to computer security, and more particularly, to the detection of malware and intrusion.
[0002] Malware, also known as malware, affects a large number of computer systems worldwide. Malware, in various forms (e.g., computer viruses, worms, Trojans, unsolicited adware, ransomware, and spyware), poses a serious risk to millions of computer users, making them vulnerable to ransomware, loss of data and sensitive information, identity theft, and loss of productivity, among other things. Malware can further display content that some users consider obscene, excessively violent, harassing, or otherwise unpleasant. The explosive growth of mobile computing only exacerbates the exposure and associated risks, with millions of devices (e.g., smartphones and tablets) constantly connecting to the Internet and becoming potential targets of malware.
[0003] Security software can be used to detect malware that infects a user's computer system and, in addition, remove such malware or prevent its execution. Several malware detection techniques are known in the art.Some rely on matching code snippets from malware agents against a malware indicative signature library. Other conventional methods detect indicative malware behavior, such as specific sequences of actions performed by malware agents. Recent methods use artificial intelligence (AI) techniques (e.g., various artificial neural networks) to analyze software behavior for malware detection.
[0004] However, some advanced malware manages to evade detection. One detection avoidance strategy involves dividing malicious activity across multiple software agents, where each agent performs a separate set of actions that, when isolated from the actions of other agents, do not specifically indicate malice. An exemplary approach to addressing such threats is described in U.S. Patent No. 10,706,151 B2, entitled "Systems and Methods for Tracking Malicious Behavior Across Multiple Software Entities," by G. Hajmasan et al., which proposes grouping entities related by branch and / or code injection relationships together so that the actions of individual group members can be attributed to the entire group.
[0005] More sophisticated malware attacks may occur in stages, where some of the actions constituting a malicious chain may be separated by relatively long periods of time, such as weeks or even months. In one such instance, an unsuspecting user could download a file containing malicious code by clicking a link embedded in an email message. The malicious code could remain dormant on the user's computer until it is invoked by another software agent and / or remotely activated by a malicious command and control server.
[0006] Conventional monitoring tools may be unable to detect this malware. Therefore, there has been ongoing interest in developing robust and efficient computer security systems and methods capable of addressing complex cyber threats. Summary of the Invention
[0007] According to one aspect, a computer system includes at least one hardware processor configured to execute an entity mapping manager and a malware detection engine connected to the entity mapping manager. The entity mapping manager is configured to construct entity maps of specified interrelated groups of software entities. The entity mapping manager is further configured to selectively retrieve the entity mapping from the mapping repository based on whether the entity mapping contains the resource entity, and to update the entity mapping by adding the specifications of the worker entity described in the specification to the entity mapping, in response to a restart of the computer system and in response to a worker entity currently executing on the computer system attempting to access a resource entity stored on the non-volatile storage device of the computer system.The entity map further includes specifications of another worker entity that was running on the computer system prior to the restart and specifications of the relationship between the other worker entity and the resource entity. The malware detection engine is configured to determine whether the computer system contains malware based on the updated entity map.
[0008] According to another aspect, a computer security method includes employing at least one hardware processor to execute an entity map manager and a malware detection engine connected to the entity map manager. The entity map manager is configured to construct entity maps specifying groups of interrelated software entities. Executing the entity map manager includes employing the at least one hardware processor to selectively retrieve the entity map from a map repository based on whether the entity map contains specifications of the resource entity in response to a restart of the computer system and in response to a worker entity currently running on the computer system attempting to access a resource entity stored on a non-volatile storage device of the computer system, and to update the entity map by adding specifications of the worker entity to the entity map. The entity map further includes specifications of another worker entity that was running on the computer system prior to the restart and specifications of the relationship between the other worker entity and the resource entity. Performing the malware detection includes employing the at least one hardware processor to determine whether the computer system contains malware based on the updated entity map.
[0009] According to another aspect, a non-transitory computer-readable media storage instruction, when executed by at least one hardware processor of a computer system, causes the computer system to form an entity map manager and a malware detection engine connected to the entity map manager. The entity map manager is configured to construct entity maps specifying groups of interrelated software entities. The entity map manager is further configured to selectively retrieve the entity map from a mapping repository based on a specification of whether the entity map contains the resource entity, and to update the entity map by adding the specification of the worker entity to the entity map, in response to a restart of the computer system and in response to a worker entity currently executing on the computer system attempting to access a resource entity stored on a non-volatile storage device of the computer system. The entity map further includes the specification of another worker entity that was executing on the computer system before the restart and the specification of the relationship between the other worker entity and the resource entity. The malware detection engine is configured to determine whether the computer system contains malware based on the updated entity map.
[0010] The foregoing aspects and advantages of the invention will be better understood after reading the following detailed description and referring to the accompanying drawings, in which:
[0011] FIG1 illustrates multiple client devices protected against malware according to some embodiments of the invention.
[0012] FIG2 illustrates exemplary software executed on a client device according to some embodiments of the invention.
[0013] FIG3 illustrates exemplary components of a computer security module according to some embodiments of the invention.
[0014] FIG4 illustrates a general exemplary entity mapping interconnecting worker entities and resource entities according to some embodiments of the invention.
[0015] FIG5-A illustrates an exemplary actual entity mapping according to some embodiments of the invention.
[0016] FIG5-B illustrates another exemplary entity mapping according to some embodiments of the invention.
[0017] FIG6 illustrates exemplary computer-readable encoding of an entity mapping according to some embodiments of the invention.
[0018] FIG7 illustrates an exemplary sequence of steps performed by an entity mapping manager module according to some embodiments of the invention. Specification 2 / 20 pages 6 CN 121773419 A
[0019] FIG8 shows another exemplary sequence of steps performed by an entity mapping manager according to some embodiments of the present invention.
[0020] FIG9 shows another exemplary sequence of steps performed by an entity mapping manager according to some embodiments of the present invention.
[0021] FIG10 shows yet another exemplary sequence of steps performed by an entity mapping manager according to some embodiments of the present invention.
[0022] FIG11 illustrates an exemplary merging of two entity maps according to some embodiments of the present invention.
[0023] FIG12 shows another exemplary sequence of steps performed by an entity mapping manager according to some embodiments of the present invention.
[0024] FIG13 illustrates an exemplary entity map signature matching according to some embodiments of the present invention.
[0025] FIG14 shows an exemplary computer-readable encoding of a map signature according to some embodiments of the present invention.
[0026] FIG15 shows an exemplary sequence of steps performed by an entity mapping manager for checking map signature matching according to some embodiments of the present invention.
[0027] FIG16 illustrates an exemplary sequence of steps performed by a detection engine according to some embodiments of the present invention.
[0028] Figure 17 illustrates an exemplary hardware configuration of a computer system programmed to perform some of the methods described herein. Detailed Description
[0029] In the following description, it should be understood that all referenced connections between structures may be direct valid connections or indirect valid connections through intermediate structures. A set of elements comprises one or more elements. It should be understood that any reference to an element refers to at least one element. Multiple elements comprise at least two elements. Any use of 'or' signifies non-exclusive or.Unless otherwise required, any method steps described need not necessarily be performed in the specific order stated. A first element derived from a second element (e.g., data) encompasses a first element equal to the second element, as well as a first element generated by processing the second element and optionally other data. Making a decision based on parameters encompasses making a decision based on parameters and optionally other data. Unless otherwise specified, some quantity / data indicators may be the quantity / data itself or indicators different from the quantity / data itself. A computer program is a sequence of processor instructions that performs a task. The computer program described in some embodiments of the invention may be a separate software entity or sub-entity (e.g., subroutine, library) of other computer programs. Unless otherwise specified, a process is an example of a computer program and is characterized by having at least one thread of execution and a virtual memory space assigned to it, wherein the contents of the corresponding virtual memory space contain executable code. The term 'reboot' refers to a restart of a computer or an operating system running on a corresponding computer. In this document, a computational session includes computations performed between consecutive reboots. In this document, a database refers to any organized, searchable collection of data. In this document, a predicate represents a statement whose truth value varies depending on the value of its variable. Evaluating predicates involves determining the truth value of the corresponding predicate. In this document, a graph represents multiple nodes interconnected by edges. A subgraph of a graph is another graph formed by a subset of the nodes and edges of the corresponding graph. In this document, two graphs A and B are said to be isomorphic if there is a one-to-one mapping between nodes of A and nodes of B, where neighboring nodes of A map to neighboring nodes of B. Computer-readable media encompasses non-transitory media (e.g., magnetic, optical, and semiconductor storage media (e.g., hard disk drives, optical discs, flash memory, DRAM)) and communication links (e.g., conductive cables and fiber optic links). Volatile media (e.g., DRAM) retain their contents only when powered, compared to non-volatile media (e.g., magnetic hard disk drives, flash memory) whose contents persist even when power is lost. According to some embodiments, the present invention particularly provides a computer system comprising hardware (e.g., one or more processors) programmed to perform the methods described herein and computer-readable media encoded with instructions for performing the methods described herein.
[0030] The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation.
[0031] FIG1 shows multiple client devices 12a to d protected from malware according to some embodiments of the invention.Exemplary client devices 12a to d include personal computer systems, enterprise mainframes, mobile computing platforms (e.g., laptops, tablets, smartphones), entertainment devices (e.g., TVs, game consoles), wearable devices (e.g., smartwatches, fitness trackers), home appliances (e.g., thermostats, refrigerators), and any other electronic device including a processor, memory, and a communication interface enabling the respective device to communicate with other devices / computer systems. In some embodiments, each client device 12a to d includes a security module configured to detect malware. The security module may be embodied as a set of connected computer programs executing on the processor of the respective device.
[0032] Exemplary client devices 12a to d are connected to a communication network 15, which may include a local area network (e.g., a home network, an enterprise network, etc.), a wide area network, and / or the Internet. Network 15 generally represents a set of hardware (physical layer) and software interfaces that enable data to be transferred between devices 12a to d and other entities connected to network 15.
[0033] FIG1 further illustrates a security server 14 connected to communication network 15. Server 14 generally represents a group of communicationally coupled computer systems that may or may not be physically close to each other. In some embodiments described below, a security module executing on each client device 12a to d may cooperate with server 14 to protect each respective device. In other words, computer security activities may be divided between the components of the respective device and server 14. For example, server 14 may confirm a preliminary malicious determination provided by a local example of the computer security module executing on each respective device 12a to d, as further described below. Server 14 may protect multiple client devices 12a to d, for example, according to a service agreement / subscription, etc.
[0034] FIG2 illustrates exemplary software executing on client device 12, which generally represents any of the client devices 12a to d in FIG1. Operating system (OS) 22 provides an interface between the hardware of client device 12 and other computer programs, such as a set of software applications 24 executing on the respective device. Exemplary operating systems include, in particular, Windows®, Linux®, iOS®, and Android®. Software application 24 generally refers to any computer program, such as word processing, image processing, spreadsheets, calendars, games, social media, web browsers, and electronic communication applications, as well as others.
[0035] In some embodiments, computer security module 30 protects client device 12 from computer security threats, such as malware and intrusions. The following description will focus on exemplary embodiments in which module 30 includes a set of computer programs (i.e., software executing on the processor of client device 12).However, those skilled in the art will recognize that the invention description may be adapted to alternative embodiments in which module 30 is implemented in hardware or a combination of hardware and software without affecting the scope of the invention. Module 30 may form part of a larger security suite that also provides traffic control (e.g., firewall, parental controls) and spam control services, as well as other security features.
[0036] In some embodiments, computer security module 30 is configured to monitor the behavior of a set of software entities executing on client computing device 12 and determine whether such behavior indicates malice. Hereinafter, monitoring software behavior includes detecting a set of events resulting from the execution of the respective software and analyzing the respective events, as shown in detail below. Exemplary monitored software entities include individual processes belonging to OS 22 and / or software application 24. A single example of security module 30 may be configured to concurrently monitor multiple (e.g., hundreds) target entities.
[0037] FIG3 illustrates exemplary components of computer security module 30 according to some embodiments of the invention. Module 30 includes a detection engine 40 configured to selectively apply multiple available detection models 42 to determine whether client device 12 contains malware. The exemplary detection model 42 can output a provisional judgment (e.g., clean / malicious) or a numerical score indicating the likelihood that a corresponding target entity or group of entities is malicious. Some embodiments of the detection engine 40 can aggregate the malware indicative scores output by multiple detection models 42 and determine whether a corresponding entity or group of entities is malicious by comparing the resulting total score with a predetermined threshold.
[0038] Model 42 can implement any malware detection method known in the art. For example, model 42 can embody a set of malware detection heuristics, i.e., several sets of rules for determining whether a target software entity / group is malicious. If an entity performs a specific action or sequence of actions, such as reading a file, encrypting its contents, and storing the encrypted contents on a disk, then the exemplary heuristic can determine that the entity is malicious. Other exemplary heuristics can evaluate various security predicates based on the characteristics of the target entity or based on events caused by the execution of the target entity. For example, an exemplary heuristic can determine whether the path of a file accessed by the target entity coincides with the location of the Chrome® password file, etc. Dissimilarity model 42 may correspond to dissimilarity heuristic. In another instance, each model 42 may include an artificial intelligence (AI) system, such as a set of pre-trained artificial neural networks configured to receive a set of characteristic features of a target entity and determine whether the entity is malicious based on said characteristics.
[0039] In some embodiments, dissimilarity detection model 42 may be applicable to dissimilar types of monitored entities. For example, Microsoft Word® macros may be monitored using a detection model that is dissimilar to another model used for monitoring conventional portable executables.In some embodiments, multiple detection models 42 may exist for the same type of entity. However, the respective models may differ in terms of the actual malware detection methods employed and / or the computational costs involved in the monitoring. In one such example, detection engine 40 may use a relatively simple set of heuristics (i.e., the initial detection model 42) to monitor a target entity / group, and switch to a more computationally expensive set of heuristics (i.e., another detection model 42) in response to the output of the initial model indicating suspected malicious activity or in response to signature matching described below. In some embodiments, detection profile 44 may store data that associates detection model 42 with entity type and / or entity behavior patterns, as well as configuration parameter values, such as score values and increments, detection thresholds and flags, and others. The contents of profile 44 may differ between client devices 12a to d and / or between different users on each respective device. The operation of detection model 42 and detection engine 40 will be further detailed below.
[0040] In a behavior-oriented embodiment, the detection model 42 receives input indicating a set of behavioral characteristics of the monitored entity / group, which characterize actions of the corresponding entity / group, such as opening a file, changing access permissions, starting a subprocess, injecting code into another software entity, sending electronic communications (e.g., HTTP requests to remote resources), etc. Such behavior can be detected via a set of computational events caused by the execution of the corresponding entity.
[0041] In some embodiments, computational events are detected by an event processing infrastructure (FIG. 3) including a set of event detectors 32, a set of event processors 34, and an event dispatcher 36 connected to the event detectors 32 and the event processors 34. The event processing infrastructure may include any implementation of a messaging system. For example, components 32-34-36 may register callbacks to be notified whenever a specific event occurs on the client device 12, and further associate each event with the software entity that caused the corresponding event.
[0042] The event detectors 32 include hardware and / or software devices configured to detect various events occurring on the client device 12 during software execution. Some detectors 32 can specifically detect certain types or categories of events. Exemplary detected events include application installation, uninstallation and updates, process / application startup and termination, child process creation (e.g., forking), dynamic loading / unloading of libraries, execution of specific processor instructions (e.g., system calls), file events (e.g., file creation, writing, deletion, etc.), and setting of various OS parameters (e.g., Windows® Registry events, permission / privilege changes), as well as others.Other exemplary detected events may include receiving requests to access peripheral devices (e.g., hard drives, SD cards, network adapters, microphones, cameras), receiving incoming communications (e.g., short message service - SMS messages), requests to access remote resources (e.g., Hypertext Transfer Protocol - HTTP requests to access a specific URL, attempts to access a document repository via a local network), requests defined in a specific Uniform Resource Identifier scheme (e.g., mailto: or ftp: requests), and attempts to send electronic messages (e.g., email, SMS, etc., on page 5 / 20 of the specification, CN 121773419 A), and others. Other exemplary events include moving the user interface / window of the target application 24 into and / or out of focus / foreground.
[0043] Some embodiments of the event detector 32 may further detect various time-related events, such as inactive periods, i.e., time intervals between events and / or time intervals when the corresponding client device is idle, has no registered user activity, or is only performing internal system tasks. This inactive period may be further divided into short time intervals (e.g., on the order of seconds) and long time intervals (e.g., on the order of minutes to hours). Other time-related events may include, for example, rapidly occurring sequences of events / bursts of activity.
[0044] Exemplary events specific to or particularly related to the security of mobile devices include screen switching (on / off), changes to application labels / names / icons, and screen captures. Other examples include granting specific types of permissions (e.g., administrator privileges, accessibility), dynamically requested permissions (i.e., during various execution phases, not at installation time), and requests to grant persistence (e.g., foreground services dynamically initiated by the corresponding application). Other examples include attempts to prevent the uninstallation of the corresponding application and displaying an overlay on top of the OS settings interface (this overlay may deceive unsuspecting users into granting unnecessary permissions to the corresponding application).
[0045] This event detection may be device-type specific. In an instance where the client device 12 is a personal or laptop computer, after detecting the creation of the target entity, the event detector 32 registers the corresponding entity and / or its associated set of processes with the event log service of OS 22 (e.g., Event Tracking-ETW in Windows®, Syslog in UNIX®). In response, the event detector 32 can receive notifications of various events occurring during the execution of the corresponding process, either in real time or in log form. Event logging tools typically generate a list of event descriptors containing a timestamp for each event, a numeric code identifying the event type, a type indicator of the process or application that generated the event, and other event parameters. In such embodiments, the detector 32 can detect the occurrence of a target event by parsing the corresponding event log.
[0046] In another instance, a dedicated event detector 32 can modify a set of native functions of OS 22 by inserting redirection instructions (also known as hooks or patches). In this way, when a process executing on client device 12 calls a corresponding OS function, execution is redirected to a callback routine that notifies detector 32 of the attempt to execute the corresponding OS function. When the hooked function is active in a monitored event (e.g., file creation, process startup, etc.), the attempt to call the corresponding function can serve as an indicator that the corresponding event has occurred.
[0047] In yet another instance of event detection, electronic communications sent by a corresponding client device can be detected by installing a dedicated event detector 32 as a proxy module configured to intercept Domain Name Service (DNS) queries and / or HTTP requests transmitted by client device 12.
[0048] Some operating systems (e.g., operating systems running on smartphones, wearable devices, etc.) may not allow such manipulation. However, other tools can be used to detect the occurrence of various events. For example, some operating systems expose application programming interfaces (APIs) that enable the registration of callbacks for different notifications, inspection of network traffic, SMS / MMS manipulation, detection of access to storage devices (e.g., SD cards), etc. Some embodiments of the event detector 32 use the functionality of the accessibility API to access content on the screen and detect user interactions with the corresponding device and / or application.
[0049] In some embodiments, the event detector 32 notifies the event dispatcher 36 in response to the occurrence of a corresponding event, for example by transmitting an event indicator 35a (FIG. 3). The dispatcher 36 is configured to centralize event notifications from the detector 32 and distribute this information or otherwise make this information accessible to other components of the computer security module 30. The dispatcher 36 is further configured to maintain a mapping / association between each detected event and the target software entity that caused the corresponding event. Data that associates each event with the target entity may be provided by the event detector 32 and / or the event processor 34. In some embodiments, the dispatcher 36 stores and / or manages individual events as data structures containing fields / attributes that can be strings, integers, booleans, or flag bitmaps.
[0050] In some embodiments, events can be organized at several semantic levels. Some event detectors 32 may only provide low-level, raw, and / or unstructured data. In some embodiments, a set of event processors 34 are configured to analyze and / or summarize this primary data to infer the occurrence of higher-level events. Thus, event processors 34 may receive event indicators 35b via the dispatcher 36 and provide additional event notifications 35c to the dispatcher 36 (FIG. 3). In one instance, event processors 34 may add attribute values / metadata to events detected by detectors 32.For example, when event indicator 35b conveys the receipt of an SMS, an exemplary event processor may determine whether the corresponding SMS contains a hyperlink and return this information in the updated event indicator 35c. In a more complex instance, event processor 34 may use artificial intelligence (e.g., natural language processing, computer vision, etc.) or other methods of analyzing the content displayed on the screen to determine whether the corresponding target entity is displaying a login form, payment interface, advertisement, etc. In yet another instance, some event processors 34 may combine information about multiple events to determine whether an aggregated higher-level event has occurred.
[0051] Event processors 34 may be organized into multiple layers such that the output of one layer is further fed to event processors in another layer. Such a hierarchical event processing architecture can efficiently and characterize detected events with customizable granularity and complexity. In some embodiments, disparate event processing layers may correspond to different event semantic levels. For example, disparate processing layers may respond substantially to different questions (e.g., how a target entity performs a specific action, what specific action the target entity performs, and why the target entity performs a specific action). In one such instance, the event handling infrastructure of security module 30 is configured to detect events including copying files to the Windows® Startup folder. To do this, the target entity may, for example:
[0052] A. call the CopyFile function of the Windows® API
[0053] B. use a sequence of file read and write commands to copy chunks of the corresponding file.
[0054] C. use the COM object IFileOperation::CopyItem to copy the file.
[0055] Event detector 32 may signal the occurrence of low-level events, such as attempts to execute CopyFile instructions (case A), individual file reads and / or writes (case B), or COM calls to IFileOperation (case C). A set of event handlers 34 may consume such low-level events to determine whether they indicate higher-level file copy events. For example, in case B, some handlers 34 may aggregate multiple detected read / write events and determine whether they involve chunks of the same file. When so, the corresponding event handler may transmit an event indicator 35c to notify the event dispatcher of the occurrence of the file copy event. Another event processor 34 may then ingest the file copy event and determine whether it indicates an attempt to copy the file to the startup folder, and if so, generate another event indicator to notify the distributor 36 accordingly.
[0056] In some embodiments, to save computing resources, some event processors 34 may be selectively activated and / or deactivated, for example, depending on the type of the target entity being monitored. Selected processors 34 may also be deactivated, for example, when no other event processor or detection model 42 is currently using its output.Some embodiments may use event handler profile 39 to specify interdependencies between event handlers 34 and / or to specify which event handlers 34 should be active / inactive based on each type of target entity. Profile 39 may be developed using any data specification standard known in the art, such as in Extensible Markup Language (XML) or JavaScript® Object Notation (JSON) versions.
[0057] The manner in which event information is distributed to event handlers 34 and / or other components of module 30 may differ between embodiments and event types. Exemplary distribution mechanisms include, for example, fast distribution, synchronous distribution, and / or asynchronous distribution. In fast distribution, events are submitted directly to event handlers 34 without locking or additional memory allocation. Examples include distributing data received from network traffic sensors registered with the Windows® Filtering Platform. Event handlers 34 that ingest fast-distributed events are typically pre-registered with their associated event detectors and cannot be dynamically activated or deactivated. In synchronous distribution, the process / thread that causes the corresponding event (page 7 / 20, CN 121773419 A) is paused while the event is submitted to the event handler for analysis and resumes after the analysis is complete. Thread locking and additional memory allocation further allow the event handler 34 to be dynamically activated / deactivated. In asynchronous distribution, the process / thread that causes the corresponding event is allowed to continue execution, and the event notification is added to a queue ingested by a dedicated processor thread pool. Some event handlers 34 and / or detectors 32, such as handlers for Windows Event Tracing (ETW) data, may require asynchronous distribution.
[0058] In some embodiments, the computer security module 30 (FIG. 3) may further include an entity map manager 38 connected to the event dispatcher 36 and the detection engine 40, the manager 38 being configured to construct and maintain a set of entity maps 50 that identify and describe groups of mutually related monitored software entities. FIG. 4 illustrates an exemplary general entity map 50 according to some embodiments of the invention. Mapping 50 includes a computer-readable representation of entity group 51, and includes a description of individual group members (entity 52) and pairwise relationships 54 between such entities. In some embodiments, mapping 50 includes a directed graph with entities 52 as nodes and relationships between entities as directed edges, as illustrated in FIG4.
[0059] Entity group 51 includes a set of worker entities, shown as circles in FIG4. Worker entities include computer programs (e.g., individual processes) that may or may not be currently executing on the corresponding client device. For example, entity group 51 may include a subset of active entities currently loaded into the volatile memory (e.g., RAM) of client device 12 and a subset of entities that were previously executing on device 12 and are currently terminated.In an instance where a parent process spawns a child process and then exits, the entity group may include both the parent process and the child process.
[0060] Entity group 51 may further include a set of resource entities shown as triangles in FIG. 4. Compared to worker entities, resource entities represent static assets stored on non-volatile computer-readable media (e.g., a hard disk used by client device 12) that are invoked or otherwise accessed by at least one worker entity of group 51. Exemplary resource entities include files and OS registry entries, among others. To illustrate the difference between worker entities and resource entities running on the Microsoft Windows® platform in the exemplary embodiments, the executing portable executable (PE) is a worker entity, while its disk image (.EXE file) is a resource entity.
[0061] Entity map 51 further includes a set of inter-entity links 54, represented as arrows in FIG. 4. Such links / graph edges represent relationships between corresponding endpoint entities. In some embodiments, the relationship between a pair of entities represents an action performed by one member of the pair on the other member. The directional links / edges shown as arrows in FIG. 4 indicate the direction of the corresponding action, such as which entity performs the corresponding action. Some embodiments distinguish multiple relationship types. Exemplary relationships between worker entities include, in particular, branching (a parent entity creating a child entity via spawning, forking, etc.), code injection (i.e., one process writing data to a memory area currently used by another process), an action in which one entity reads the contents of memory belonging to or used by another entity, an action in which one entity enumerates objects (e.g., libraries) loaded by another entity, an action in which one entity suspends the execution of another entity, and an action in which one entity kills / terminates another entity. Exemplary relationships between worker entities and resource entities include write / set, modify, read, load, execute, and delete, as well as others.
[0062] A worker entity may also be associated with a resource entity due to the actions of its parent entity. Some examples occurring on the Windows® platform are given below. In one such example, the parent process first registers a service by setting a specific OS registry key (resource entity). The parent then instructs the Service Manager to start the service, thus creating a child entity. The child can be configured to start automatically after a restart or can be explicitly started via the Service Manager API.
[0063] In another instance, the parent process registers the child process as a task by using the task scheduler API or by simply writing to a task configuration file (resource entity). The parent then instructs the task scheduler to start the child. The child entity can be configured to start at a specific time or automatically after a restart.
[0064] In another example, the parent entity can enable the debugger service to automatically start a child entity in response to the creation of any process by setting a specific OS registry key (resource entity). Other examples may use the Windows Management Specification (WMI) event notification facility. The parent process can register event consumers and filters with WMI via script files (resource entities), thereby enabling the WMI engine to automatically start a child entity in response to the occurrence of a certain type of event.
[0065] All process creation mechanisms described above can be maliciously manipulated, for example, for privilege escalation or to mask the source of an attack. Therefore, from a computer security perspective, it may be beneficial not only to associate the parent entity with the child entity, but also to associate the child entity with the resource entity that facilitated the creation of the corresponding child. For example, when the parent entity reads or writes selected resource entities (registry keys, script files, configuration files, etc.) before creating the child entity, some embodiments may connect the corresponding resource entity to both the parent entity and the child entity within the corresponding entity mapping. Such cases are further described below with reference to Figure 8.
[0066] Two real-world examples of entity mapping according to some embodiments of the present invention are shown in Figures 5-A to 5-B. Entity mapping 50a in Figure 5-A illustrates an exemplary case in which a user uses an example of the File Explorer® application (worker entity 52a) to navigate to and open an example of Microsoft Outlook® (worker entity 52b), and then uses the corresponding email client to download a file attached to an email message (resource entity 52f). At a later time, the user launches an example of the Microsoft Word® word processing application (worker entity 52c) and loads the downloaded file. Entity 52f includes executable code in the form of a macro that, when executed by the corresponding example of Word®, causes entity 52c to download and write a malicious executable file (resource entity 52e) to the local disk. The macro code further causes worker entity 52c to set a specific Windows® registry key (resource entity 52h) to point to the recently downloaded entity 52e. The malicious macro code within resource entity 52f then causes Word® to launch an example of the OS utility (worker entity 52d), which in turn reads the value of resource entity 52h, thus achieving a secret privilege escalation—a known type of malicious manipulation designed to take over the corresponding host. Worker entity 52d then launches a new process (worker entity 52g) that loads resource entity 52e and, as part of its malicious payload, sets another Windows® registry key (resource entity 52j) that causes the new example of malicious entity 52g to start automatically upon reboot.The described attack attempts to continuously infect the user's computer via resource entities 52e and 52j. If it survives even after a reboot, malicious entity 52g can then perform any activity, such as parsing the user's keystrokes to obtain passwords, PINs, etc., and transmitting them to a remote server.
[0067] Entity mapping 50b in Figure 5-B illustrates another exemplary case where a user launches a web browser (worker entity 52m) via Windows File Explorer® (worker entity 52k) and then navigates to a malicious webpage, which triggers a remote code execution vulnerability in the browser, causing it to download a malicious library (resource entity 52n) to a specific disk location used by a local example of a Microsoft OneDrive® cloud-hosted client. Subsequent execution of the OneDrive® client (worker entity 52q, starting with worker entity 52p) will then load the malicious library, which, upon execution, will cause the OS management tool (worker entity 52r) to launch. Entity 52r can then carry out ransomware attacks, such as encrypting and / or deleting various user files. The illustrated case demonstrates another instance of persistent malware that can survive a reboot via resource entity 52n. However, in some embodiments of the invention, as detailed below, entity map manager 38 is configured to restore map 50b in response to a reboot, thereby enabling reliable detection of persistent malware.
[0068] Entity map 50, including entities currently executing on the corresponding client device 12, may be stored in volatile memory. Map manager 38 may dynamically create, edit, and delete entity maps. Editing a map may include adding entities to and / or removing entities from existing entity groups, as well as setting / changing various entity and / or relationship properties. Some entity maps may also be persistently stored on non-volatile media (e.g., the storage device shown below with respect to FIG. 17). In some such embodiments, map 50 may be stored in map repository 26 (FIG. 3), which includes a record database that can be selectively retrieved according to various criteria. The format of the stored entity maps may vary. The exemplary embodiment includes a record and specification of a relational database, 9 / 20 pages, 13 CN 121773419 A, representing a set of attribute value pairs in a version of Extensible Markup Language (XML) or Javascript® Object Notation (JSON) and other representations. The relational database embodiment of the mapping repository 26 can maintain the association between each entity mapping and its member entities, enabling selective retrieval of entity mappings based on the identity and / or characteristics of the members.
[0069] Figure 6 illustrates an exemplary computer-readable specification of an entity mapping 50c according to some embodiments of the present invention. The illustrated format includes a hierarchical data structure containing a set of attribute value pairs characterizing the respective entity mapping.The entity mapping 50c specification includes a section listing the members of the respective entity groups item by item and another section listing the pairwise relationships between entities item by item, as illustrated. Those skilled in the art will appreciate that the chosen formats, selections, and attribute naming are illustrative only and not intended to be limiting. Each worker entity can be characterized by attributes such as the identifier of the corresponding process (e.g., process ID, memory image hash, etc.), the location / path of the executable used to launch the corresponding entity, and an entity type indicator (e.g., portable executable, shell script, etc.). Among other things, worker entities can be further characterized, particularly by an indicator of the version of the corresponding program and a set of timestamps indicating, for example, the start and / or termination time of the corresponding entity.
[0070] Resource entities can be characterized by exemplary attributes such as resource type (e.g., Word® document, portable document format - PDF file, portable executable, dynamic link library - DLL, OS registry key, etc.), the location of the corresponding entity (local path, network address, Uniform Resource Locator - URL, etc.), and a set of timestamps indicating the creation and / or last modification time of the corresponding entity.
[0071] In some embodiments, entities may be further characterized by a set of security flags, such as exemplary flags 56a to b in FIG. 6. Such flags may indicate, for example, whether the corresponding worker entity is executing code from a source outside the corresponding client device or whether the content of the corresponding resource entity has changed since being added to the corresponding entity map. Such flags may be used by the detection engine 40 to determine whether the client device 12 contains malware. For example, the engine 40 may use knowledge that a file has been downloaded from the Internet to flag a worker entity loading a corresponding file as potentially malicious. In some embodiments, security flags 56a to b may be set by the entity map manager 38 and / or the detection engine 40 in response to various events associated with the corresponding entity and / or in response to map signature matching, as shown in more detail below.
[0072] In some embodiments illustrated in FIG. 6, the map 50c further includes a specification of relationships between entities, characterized by attributes such as relationship type (e.g., write, discard, read, set, load, execute, etc.) and an indicator of the direction of each corresponding relationship.
[0073] Figures 7 to 10 and 12 illustrate exemplary sequences of steps performed by the entity mapping manager 38 to implement various entity mapping management operations according to some embodiments of the present invention. For example, mapping management operations such as creating, updating, and deleting entity mappings typically occur in response to various computational events detected by the event processing infrastructure described above with respect to Figure 3. In step 102 (Figure 7), the mapping manager module 38 may listen for event notifications from the event dispatcher 36. If the current event belongs to the mapping update trigger category (step 104 returns YES), in step 106, a mapping update may be selectively implemented according to the type of the corresponding event.Figures 8 to 12 illustrate several such exemplary scenarios.
[0074] Figure 8 shows an exemplary mapping update procedure executed in response to the occurrence of an event indicative of the creation of a worker entity / process. For example, a new worker entity is created when a user double-clicks an executable file or when a parent entity generates a child through a fork. Step 122 receives a notification of the corresponding event. Another step 124 may analyze the detected event to identify the parent entity that caused the creation of the new worker. In step 126, some embodiments may determine whether the identified parent entity had accessed a resource entity, such as an OS registry key or a disk file, before creating the current worker. This access may indicate that the corresponding parent entity may be involved in a malicious action chain. Step 126 may include, for example, parsing a set of security flags associated with the parent entity (e.g., see flag 56a in Figure 6).
[0075] When step 126 returns No, in step 128, manager 38 may identify all available entity maps containing the corresponding parent entity, including active (in memory) entity maps and persistently stored entity maps. Some embodiments rely on the observation that the stored entity maps may describe worker entities that are no longer executing and therefore may differ from the identified parent entity in at least some characteristics (e.g., process ID and others). Therefore, when searching the map repository 26, manager 38 may look for entity maps containing entities that match at least some of the characteristics of the identified parent entity. Some embodiments may require precise matching of selected attributes, such as entity type, version / build, and executable location, without requiring precise matching of other attributes, such as security flags and others.
[0076] When no entity map has attributes that match the identified parent entity (step 130 returns No), in step 132, manager 38 may initialize a new entity map and add the newly created worker entity to it. Step 132 may include creating a data object (or specification) describing the new worker entity, determining a set of attribute values characterizing the corresponding entity, and populating the created data object with the corresponding attribute values. For exemplary attributes of a work system entity, please refer to the description above regarding Figure 6.
[0077] If step 128 identifies at least one existing entity map with a member entity that matches the identified parent entity (step 130 returns Yes), then in step 134, the map manager 38 may add the newly created worker entity to each of these entity maps. Step 134 may include adding data characterizing the new worker entity (e.g., attribute values) and data characterizing the relationship between the new worker entity and the identified parent entity to the specification of each entity map identified in step 128.
[0078] In some embodiments, when step 126 returns Yes, step 136 may identify all entity maps containing resource entities previously accessed by the parent entity identified in step 124.Step 136 may include searching for active entity maps and persistent entity maps. As described above, the search may involve finding entity maps of resource entities that contain at least some selected attributes that match the entities identified in step 126. Some embodiments may require an exact match of attributes (e.g., the location of the corresponding resource) but not an exact match of other attributes (e.g., security flags and others). Another step 138 may add the newly created worker entity to all entity maps identified in step 134. Thus, step 138 may include a specification for adding the new worker entity and a specification for the relationship connecting the new worker entity to the corresponding resource entity. The relationship specification may indicate that the corresponding worker entity is connected to the resource entity due to an existing relationship between the corresponding resource entity and the parent entity of the new worker entity. In implementing step 138, some embodiments rely on the observation that the situation described herein, where a parent generates a child in response to reading or writing a specific registry key, can enable various malicious manipulations, such as privilege escalation and masquerading as persistent malware, and is therefore of informational value from a computer security perspective. By adding child entities to an entity map in response to an action of their parent entity, some embodiments thus mark the corresponding child entities as potential participants in a suspicious or more complex kill chain.
[0079] Figure 9 illustrates an exemplary sequence of steps performed by the map manager 38 in response to an event indicating code injection. Step 142 receives a notification of the corresponding event via an event distribution infrastructure. In another step 144, the manager 38 may analyze the corresponding event to determine the source entity performing the code injection and the target entity receiving the corresponding injected code. Step sequences 146 to 148 may then identify all entity maps containing worker entities that match the source entity and add the target entity to all such identified entity maps. Step 148 may include defining the specification of the target entity and the specification of the code injection relationship connecting the target entity to the source entity, and adding the corresponding specification to a data object describing the corresponding entity map. Exemplary entity and relationship specifications are shown, for example, in Figure 6.
[0080] Figure 10 illustrates an exemplary sequence of steps performed by the mapping manager 38 in response to an event instructing access to a resource entity (e.g., a file, OS registry key, etc.), wherein access herein encompasses reading, loading, and executing the contents of the corresponding entity. In step 152, the occurrence of the event is notified to the manager 38. Another step 154 analyzes the detected event to determine the identity of the worker entity attempting to access the corresponding resource entity. Step 156 performs a lookup to identify all entity mappings (active and persistent) containing the corresponding resource entity. In step 158, the mapping manager 38 then adds the worker entity identified in step 154 (page 11 / 20 of specification, CN 121773419 A) to all entity mappings identified in step 156.Adding a worker entity may include determining the specifications of the corresponding worker entity and the specifications of the relationship between the corresponding worker and the resource entity, and adding the specifications to the identified entity map.
[0081] In some cases, the corresponding resource entity forms part of a persistently stored entity map, wherein at least some of the members of the group of entities described by the corresponding entity map are no longer active. In the example illustrated in FIG5-B and described above, library 52n is written to disk (and thus added to the corresponding entity map) during a previous computing session separated by a restart of the corresponding client device and subsequent access by worker entity 52q. In other words, at the moment when entity 52q attempts to load entity 52n, both worker entities 52k-m have been terminated. In such cases, in response to identifying the stored entity map, some embodiments of the map manager 38 may restore the stored entity map by instantiating a new active entity map and populating it with the contents of the stored entity map. The worker entity attempting to access the corresponding resource entity may then be added to the restored entity map. In some embodiments, the map manager 38 may use special attributes, flags, etc., to mark the terminated worker entities of the corresponding map.
[0082] There may also be cases where a worker entity attempting to access a corresponding resource entity is already included in at least one other entity map managed by the mapping manager 38. In such cases, some embodiments merge the entity map containing the resource entity with another entity map containing the worker entity identified in step 154. FIG11 illustrates an exemplary merging of a pair of exemplary entity maps 50d-e into an aggregate entity map 50f. The illustrated merging may occur in response to a worker entity 52t of entity map 50e attempting to access the contents of resource entity 52s of entity map 52d. Merging two entity maps may include, for example, copying the contents of the first entity map into the second entity map, adding edge / link specifications, and deleting the first entity map.
[0083] In some embodiments, merging two entity maps further includes rearranging and / or simplifying the aggregate entity map to remove redundant information. In the example of FIG11, entity map 50f is further processed to produce a simplified entity map 50g, and then it is determined that worker entities 52u-v have the same characteristics and that the relationship between entities 52u-z has the same type as the relationship between entities 52v-t.
[0084] Figure 12 illustrates an exemplary sequence of steps performed by the entity mapping manager 38 in response to an event indicating an attempt to create or overwrite a resource entity (e.g., a file, an OS registry key). Step 162 receives a notification of the corresponding event from the event dispatcher 36. In another step 164, the manager 38 may process the event notification to identify the resource entity currently being written to / modified.Step 164 further identifies all entity maps (active and persistent) containing the corresponding resource entity, i.e., all maps containing resource entities that match the characteristics of the corresponding resource entity. When such an entity map does not exist (step 166 returns no), indicating that the current resource entity has just been discarded / created / set, step 168 identifies the worker entity attempting the current write operation. Step 170 may identify all entity maps containing entities that match the characteristics of the identified worker entity. Another step 172 may then add the corresponding resource entity to all entity maps identified in step 170. In this document, adding a resource entity may include defining the specifications of the resource entity and the specifications of the relationship between the identified worker entity and the resource entity, and adding the corresponding specifications to each identified entity map.
[0085] When step 166 returns yes, indicating that the corresponding resource entity is currently being overwritten / reset, in step 174, some embodiments of the manager 38 modify the active entity map identified in step 170 to indicate that the corresponding entity has been overwritten. Such modification may include changing the value of a security flag characterizing the corresponding resource entity (e.g., see flag 56b in FIG. 6).
[0086] Step 176 may add a new example of the corresponding resource entity to all active entity maps identified in step 164. A security flag associated with the new example may then be set to indicate that the corresponding example of the resource entity has not been overwritten or reset. Steps 174-176 ensure that information about obsolete resource entities that may have been used in the past to transfer malicious data between members of the corresponding entity map is preserved, at least as long as there is at least one active worker entity that can utilize this data.
[0087] In some embodiments, in another step 178, the manager 38 may delete all persistent storage entity maps containing the corresponding entity based on the observation that any malicious payload carried by the corresponding entity when the resource entity is overwritten or reset is likely to be lost and therefore cannot contaminate any future worker entities. In an alternative embodiment, step 178 may remove the corresponding resource entity from all persistent storage entity maps.
[0088] In addition to the exemplary method of managing entity mappings illustrated in Figures 7 to 12, some embodiments of the mapping manager 38 may implement memory and resource management strategies that affect the number of entity mappings permanently stored in the repository 26 and the duration for which they are held on the storage media of the respective client devices. Some embodiments limit the bit size and / or count of records stored in the mapping repository 26 to a predetermined upper limit threshold. New records (e.g., entity mappings) may be freely added to the repository 26 until the limit is reached, and some records may be deleted thereafter to maintain storage quotas. Various mapping removal strategies may be implemented.For example, each entity stored in repository 26 may have an associated priority indicator; lower priority entities are then removed before higher priority entities. In another instance, each entity stored in mapping repository 26 may have an associated timestamp indicating the last time the corresponding entity mapping was accessed. Manager 38 may then determine which mappings to delete based on the corresponding timestamp. For example, entity mappings that have not been accessed for a period exceeding a predetermined threshold may be automatically deleted. In another exemplary strategy, entity mappings that are rarely accessed may be deleted before other entity mappings that are accessed more frequently.
[0089] Returning to FIG7, in response to updating any relevant entity mapping, as detailed above, in step 108, manager 38 may check for signature matching of the updated entity mapping. Some embodiments store a set of secure signatures in mapping repository 26 and / or other non-transitory computer-readable media communicatively coupled to the corresponding client device. FIG13 illustrates an exemplary secure signature 60 and signature matching according to some embodiments of the present invention.
[0090] Signature 60 includes a signature mapping and an indicator of an action to be performed in response to a match. In this document, a signature map includes a description of multiple interrelated entities comprising worker and / or resource entities, for example in the form of a graph illustrated in Figure 13. A signature map typically contains a relatively small group of entities that are interrelated in a manner relevant to computer security. An example includes Microsoft Outlook® saving a received file as an email attachment. This signature map may contain worker entities that have the characteristics of the Outlook® example and are connected to resource entities of file types.
[0091] As shown above with respect to entity maps managed by map manager 38, various computer-readable codes can be used to specify secure signatures. Figure 14 illustrates exemplary codes according to some embodiments of the invention. An exemplary signature 60a includes portions specifying each entity in the corresponding signature map and portions specifying each pair of relationships between entities. Entities and relationships may be specified by a set of attribute value pairs or any other data format known in the field. In some embodiments, selected worker entities of the signature map are designated as the root node 63 of the corresponding signature; this designation facilitates signature matching by selecting a starting point in the signature matching procedure.
[0092] In some embodiments, checking whether a secure signature matches a target entity map includes determining whether the corresponding target entity map contains a corresponding signature map, i.e., whether the signature map is a subgraph of the target entity map. In other words, the target entity map matches a signature if each entity in the signature map has a matching corresponding portion within the target entity map (i.e., the entity has the characteristics described in the corresponding secure signature), and further, if the matching corresponding portion entities are cross-correlated in the manner of the corresponding signature map. In the example of FIG13, target entity map 50 matches signature 60.
[0093] In some embodiments illustrated in FIG14, the entity specification of signature 60a includes a set of predicates 62 relating to various entity attributes, such as entity type, version, location, timestamp, security flag, etc. Signature matching may then include evaluating the corresponding predicates based on the attribute values of the members of the target entity map. In one such example illustrated in FIG14, determining whether the target entity map matches signature 60a may include searching in the target entity map for worker entities whose “ExecutablePath” attribute value contains the string “Outlook.exe”. Other exemplary predicates may include other string operators (e.g., “BeginsWith”), regular expressions, Boolean operators, and various mathematical operators (e.g., <, >, various hash functions, etc.).
[0094] Signature matching may require all signature predicates to evaluate to true. Alternative embodiments may allow partial or fuzzy matching, for example, determining that a signature matches the target entity map when at least 80% of the predicates cited in the corresponding signature evaluate to true.
[0095] Signature matching can be performed according to any graph processing algorithm known in the art. For example, some embodiments may search for subgraphs isomorphic to the signature map in the target entity map. (In the example illustrated in FIG13, the emphasized subgraph of the target entity map 50 is isomorphic to the signature map of the signature 60).
[0096] In some embodiments, signature matching may be performed in parallel with the map update process, for example, in response to a specific map update triggering event. In one such example, the map manager 38 may maintain a partial matching list, which includes a database that associates monitored software entities with signatures 60 of nodes containing characteristics that match the corresponding entities. The signatures 60 listed in the list thus partially match at least one current entity map because their corresponding signature map contains at least one entity within the corresponding entity map that has a matching portion. In some embodiments, the partial matching list associates a software entity with a signature of its root node that matches the corresponding entity (see root node 63 of the exemplary signature 60a in FIG14). The data format and specification of the partial matching list may vary depending on the implementation. Exemplary register entries may include tuples {E, M, S, δ}, where E includes the identifier of the currently monitored entity, M identifies the entity map with entity E as a node, S identifies a secure signature whose root node matches the property of entity E, and δ represents an indicator of the extent / degree to which signature S matches entity map M. The exemplary matching degree indicator may include a number varying between a lower bound (e.g., 0 = no match) and an upper bound (e.g., 1 = perfect match), where a value between 0 and 1 indicates that currently only a portion of signature S or its subgraph matches map M.In some embodiments, δ can be expressed as another tuple, where and respectively identify the entity / node and relation / edge of the currently matching signature S in the mapping M. For example, assuming S represents the signature illustrated in FIG14, e1 can represent the entity "worker 1" and r1 can represent the relationship between the entities "worker 1" and "resource 1". The roster entries described above can be selectively retrieved according to various criteria (e.g., entity identifier, mapping, signature, etc.). In some embodiments, there may be multiple roster entries associated with the same entity E, each roster entry identifying a distinct partially matching signature 60.
[0097] An exemplary signature matching procedure is illustrated in FIG15. In step 180, the mapping manager 38 may detect the addition of a new entity to the entity mapping. Such additions may occur in various cases, as described above with respect to FIG8 to 12. In step 182, the mapping manager 38 may initialize a new partially matching roster entry for the new entity. Additionally, steps 184-186 populate new roster entries by identifying entity mapping 50 containing the new entity and its root node matching the security signature 60 of the new entity. Some embodiments may set an initial value for δ, which indicates that the identified signature matches the identified entity mapping only at the root node.
[0098] Another step 188 may determine whether the new entity is a “destination” node of the corresponding entity mapping, i.e., whether the corresponding entity mapping has any edges pointing to the new entity. Exemplary destination nodes include child entities and entities that have received injected code from other entities. When step 188 returns yes, step 190 may identify the “source” entity within the corresponding entity mapping that is connected to the new entity. Exemplary source entities include parent entities and code injector entities, as well as others. In step 190, the mapping manager 38 further retrieves partially matching roster entries associated with the corresponding source entity.
[0099] The sequence of steps 192-194-196 may then iterate through all roster entries of the source entity (i.e., all signatures whose root nodes match the source entity). Step 194 determines whether the new entity further matches the corresponding signature, that is, whether the corresponding signature mapping has candidate nodes with characteristics that match the new entity and whether the candidate nodes are connected to the root node through a relationship of the same type as the relationship between the new entity and the source entity in the corresponding entity mapping. When the new entity does indeed extend the match between the current entity mapping and the signature of the corresponding specification page 14 / 20 18 CN 121773419 A (step 194 returns yes), step 196 increments the matching degree indicator δ accordingly.
[0100] In some embodiments, steps 192-194-196 may be recursively repeated, moving up the current entity mapping from the current source entity to the source entity of the current source entity, etc., until all lineages of the newly added entity have been traversed.Using the exemplary entity mapping illustrated in Figure 5-A and assuming that step 180 has detected the addition of worker entity 52g, steps 192-194-196 can be performed on source entity 52d, followed by repeating for source entities 52c and 52a. At each of these levels within the entity mapping, the mapping manager 38 can determine whether the newly added entity (i.e., worker entity 52g) expands the match of the selected security signature, as indicated by a set of partially matching roster entries associated with the current source entity.
[0101] When all relevant roster entities have been analyzed (step 192 returns no), in step 198, the mapping manager 38 can determine whether any signature 60 fully matches the current entity mapping, for example by looking up the roster δ value. If yes, step 200 can return the identifier of the matching signature. In some embodiments, another step 202 can free up computing resources by deleting any roster entries associated with fully matching signatures.
[0102] When a signature match is detected (step 110 in FIG. 7 returns "Yes"), in step 112, the mapping manager 38 may perform a set of actions based on the corresponding matching signature. In some embodiments illustrated in FIG. 14, the signature specification may include an action indicative portion 64 indicating the action to be taken in response to a signature match. Such actions may target specific entities and / or relationships between entities. Exemplary actions include modifying the entity mapping that matches the corresponding signature by updating the entity specification and / or the specification of the relationship between two members of the corresponding entity mapping. In one such example illustrated in FIG. 14, the action indicative portion 64 instructs the mapping manager 38 to set a security flag indicating that the corresponding resource entity has an external origin (i.e., downloaded from the Internet). Other exemplary actions performed in response to a signature match may include, in particular, determining that a specific member (and / or the entire entity group) of an entity group is malicious and activating or deactivating a specific detection model 42, as described below.
[0103] In some embodiments illustrated by section 64 of signature 60a (FIG. 14), another type of action performed in response to a signature match includes persistently storing entity maps that match the corresponding signature (step 114 in FIG. 7). For example, map manager 38 may save all entity maps that match the corresponding signature to map repository 26 stored on non-volatile media (e.g., hard disk drives) that are communicatively coupled to the corresponding client device. Section 64 may further indicate various storage parameters, such as the storage location, duration, and priority of the corresponding entity map.
[0104] In step 114, some embodiments of map manager 38 further cooperate with detection engine 40 to persistently store a set of current malware indicative scores, such as group scores and / or individual entity scores. Such scores are described in detail below. Scores may be appended to the corresponding entity map as metadata along with a timestamp indicating when the corresponding map and score were saved.
[0105] Persistent storage of selected entity mappings can facilitate the detection of persistent malware. For example, as shown in Figure 5-B, a security signature can describe an example of Windows Internet Explorer® placing an executable library on a local disk. The corresponding signature can instruct the mapping manager 38 to persistently store any entity mappings containing entities and relationships of the corresponding type. When the mapping manager 38 detects an active entity mapping matching a corresponding signature (e.g., a mapping that connects entity 52m to entity 52n, as illustrated in Figure 5-B), it can then save the corresponding mapping to persistent storage. The corresponding entity mapping can then be restored in response to a restart, thereby preserving the malicious action chain.
[0106] In some embodiments, the detection engine 40 maintains a data structure that tracks the behavior of various software objects executing on the corresponding client device. This tracking can be implemented via a system of malware indicative scores that are dynamically updated based on the behavior of the corresponding monitored software. A decision regarding whether a corresponding client device contains malware can then be made by comparing the score with a predetermined threshold. The threshold can vary depending on user preferences, security policies, subscription or service level agreements, and others.
[0107] In one exemplary embodiment, the first set of scores includes individual entity scores, each entity score being associated with an individual worker entity currently or previously executed on the corresponding client and indicating whether the corresponding entity is malicious. The second set of scores may include collective group scores, each of which is associated with an entity group identified by the mapping manager 38 and indicating whether the corresponding entire entity group is malicious. Group scores may vary depending on the actions of individual members of the corresponding group, and therefore, such scores facilitate the detection of complex malware in which malicious activity is segmented among group members. In some embodiments, each group score is uniquely associated with an entity map that identifies the corresponding interrelated entity group as described above. To accurately manage entity and group scores, the detection engine 40 may receive information from the entity mapping manager 38 (see FIG. 3), such as the current group composition.
[0108] In some embodiments, a set of entity-specific or group-specific detection models 42 are used to perform malicious detection and assessment on each worker entity and / or entity group. Model 42 can be selected, for example, based on entity type (e.g., some models 42 may only apply to the example of Microsoft Word®, while other models 42 may apply indiscriminately to all executables). In a simple instance where detection model 42 represents an individual malware heuristic, each entity can be monitored using a subset of entity-specific heuristics. Monitoring may include applying the detection model to the corresponding entity, for example, determining whether the corresponding entity meets a specific set of conditions, whether the corresponding entity has performed a specific action, etc.Some detection models 42 are configured to output a score increment, such as 1, when the corresponding model indicates that the corresponding entity is malicious, otherwise outputting 0. The detection engine 40 may then increment the entity score and / or group score based on the output of the model 42.
[0109] In some embodiments, the score increment determined by the selected detection model 42 may vary depending on various characteristics of the corresponding entity. For example, if the worker entity includes verified code, then the action of accessing user files may produce a score increment, otherwise it may produce another relatively larger score increment. Furthermore, the output of some detection models may vary during the lifetime of the monitored entity, because various characteristics of the corresponding entity may change over time. Using the above examples, the score increment may change in response to the corresponding entity receiving injected code or loading a specific resource entity.
[0110] In some embodiments, the selection of the detection model 42 assigned to each entity / group may change over time, for example, in response to the actions of the corresponding entity and / or in response to changes in the selection of the characteristics of the corresponding entity. In other words, the engine 40 may start by using a first set of detection models 42 to monitor an entity and later switch to using other detection models 42 for the same entity. Switching can be caused, for example, by a change in the value of a selected security flag within an entity map containing the corresponding monitored entity, as shown in more detail below.
[0111] Figure 16 illustrates an exemplary sequence of steps performed by the detection engine 40 according to some embodiments of the invention. Step 212 may listen for events via the event processing infrastructure described above with respect to Figure 3. Step 214 analyzes the corresponding notification to determine whether it is behaviorally indicative, for example, whether it indicates an action, such as opening a file, accessing a URL, etc. If so, step 216 identifies the entity that caused the corresponding event. Some embodiments further use current entity map information maintained by the map manager 38 to identify a group of entity groups / maps containing the identified entities.
[0112] In another sequence of steps 218-220, the engine 40 may identify the detection model 42 currently assigned to the entity and / or group of entities identified in step 216 and apply the corresponding detection model. Step 220 may include, for example, evaluating a set of heuristics / rules, calculating a set of inputs, feeding them into an artificial neural network, and performing corresponding neural computations, etc. In some embodiments, the output of each model 42 includes a score and / or a score increment determined based on the corresponding event. In such cases, step 220 may further include updating the malware indicative scores for the entities and / or groups of entities identified in step 216.
[0113] Another step 222 may determine whether the current score corresponding to an entity and / or group indicates that the client device includes malware, for example by comparing each of the corresponding scores with a threshold. In some embodiments, when at least one malware indicative score exceeds a corresponding threshold, the corresponding client is considered malicious / infected.When step 222 returns "yes", some embodiments transmit a preliminary security determination to the confirmation module 46 (FIG. 3). Module 46 may then perform additional evaluations, which may include transmitting the determination and / or other security-related data to the security server 14. The confirmation module 46 may then output a merged security determination 56, indicating whether the corresponding client device is malicious. Determination 56 may be communicated to users, system administrators, etc., either displayed or otherwise.
[0114] The detection engine 40 may also receive notifications from the mapping manager 38 regarding changes in the composition of various entity groups and / or changes in the specifications / attributes (e.g., security flag settings) of various entities. When step 226 recognizes this notification, another step 228 determines whether there is an entity mapping update. If yes, in another step 230, the engine 40 may update its scoring objects according to the current entity mapping changes. When a new entity is created and added to an existing entity map / group, some embodiments may initialize a new entity score for the corresponding entity and further associate the new entity with its corresponding group, such that the corresponding group score can be updated in response to further activity of the new entity. Similarly, in response to the creation of a new entity group / map, engine 40 may initialize a new group score and associate it with the newly created entity group. In some embodiments, when an entity map is restored from persistent storage in response to a system restart, the restored entity map further includes a set of scores computed for the corresponding entity group and / or individual entities in a previous computing session. In such cases, some embodiments may update the current score based on the restored score.
[0115] In response to an attribute change of an individual entity (when step 232 returns yes), in another step 234, engine 40 may determine whether such a change warrants any change in the detection strategy for the corresponding entity and / or group. For example, step 234 may cause a switch from using some detection models to using other detection models. In some embodiments, step 234 may include evaluating a set of model-specific activation predicates and activating the corresponding model 42 when the corresponding predicate evaluates to true. An example of a model activation predicate includes determining whether a specific security flag for the corresponding entity is currently set (see exemplary security flags 56a to b in FIG. 6). Detection model 42 can be similarly deactivated / disabled, for example, by evaluating a set of deactivation predicates.
[0116] In some embodiments, step 234 includes changing various parameters of the current detection model 42 in response to a change in the characteristics of the monitored entity. For example, the value of the output of the corresponding model (e.g., a score increment) may change in response to a reset of the security flag.
[0117] FIG. 17 illustrates an exemplary hardware configuration of a computer system 80 programmed to perform some of the methods described herein. Computer system 80 generally represents any of the client devices 12a to d in FIG. 1.The computing device described is a personal computer; other devices such as servers, mobile phones, tablet computers, and wearable devices may have slightly different configurations.
[0118] Processor 82 includes physical means (e.g., a microprocessor formed on a semiconductor substrate, a multi-core integrated circuit) configured to perform computations and / or logical operations with a set of signals and / or data. Such signals or data may be encoded in the form of processor instructions (e.g., machine code) and passed to processor 82.
[0119] Memory unit 84 may include volatile computer-readable media (e.g., dynamic random access memory - DRAM) that stores data / signals / instruction codes accessed or generated by processor 82 during operation. Input device 86 may include a computer keyboard, mouse, microphone, and others, including corresponding hardware interfaces and / or adapters that allow users to introduce data and / or instructions into computer system 80. Output device 88 may include display devices (e.g., monitors, speakers, and others) and hardware interfaces / adapters (e.g., graphics cards) that enable the respective computing device to communicate data to the user. In some embodiments, input and output devices 86-88 share common hardware (e.g., a touchscreen). Storage device 92 includes a computer-readable medium that implements non-volatile storage, retrieval, and writing of software instructions and / or data. Exemplary storage devices include magnetic disks and optical disks and flash memory devices, as well as removable media such as CDs and / or DVDs and drives. Network adapter 94 enables computer system 80 to connect to an electronic communication network (e.g., network 15 in FIG. 1) and / or other devices / computer systems. Specification 17 / 20 pages 21 CN 121773419 A
[0120] Controller hub 90 generally refers to multiple systems, peripheral devices, and / or chipset buses and / or all other circuitry that enables communication between processor 82 and the remaining hardware components of computer system 80. For example, controller hub 90 may include memory controllers, input / output (I / O) controllers, and interrupt controllers. Depending on the hardware manufacturer, some of these controllers may be incorporated into a single integrated circuit and / or integrated with processor 82. In another instance, the controller hub 90 may include a northbridge connecting the processor 82 to the memory 84 and / or a southbridge connecting the processor 82 to devices 86, 88, 92, and 94.
[0121] The exemplary systems and methods described above enable efficient detection of sophisticated malware, particularly malware attempting to evade detection by segmenting its malicious activity across multiple entities and / or multiple computing sessions. Some advanced malware can persist on the respective machine and survive multiple reboot events.In one example illustrated in Figure 5-B, a legitimate program (e.g., a Microsoft OneDrive® client) becomes a delivery vehicle for malware in response to loading a malicious library placed on the local disk by another legitimate program in a previous computing session. In this instance, the restart event effectively disrupts the sequence of malicious activity, also known in the field as a kill chain. Conventional security solutions typically only analyze data derived from the current computing session, such as monitoring only currently executing software entities, and therefore are unaware of at least a portion of the kill chain.
[0122] Compared to such conventional anti-malware systems, some embodiments of the present invention persistently retain structured security information, enabling security software to recover and integrate this historical security data across multiple computing sessions. In some embodiments, an entity map manager constructs and maintains a set of entity maps, each describing a distinct group of interrelated software entities. An exemplary entity map includes a directed graph connecting members of the respective entity groups. This entity group may include worker entities (e.g., processes) and resource entities (e.g., files and OS registry entries), and others. Worker entities may be associated with branching (parent-child) and code injection, and other related mechanisms. When a worker entity accesses (reads, writes, sets, etc.) a corresponding resource entity, the worker entity is associated with the resource entity.
[0123] Entity maps may be stored in persistent storage, such as in a mapping repository / database stored on a non-volatile computer-readable medium connected to the corresponding computing device. Some embodiments rely on the observation that sophisticated malware can use persistent assets (e.g., files and registry entries) to survive after a reboot. Therefore, embodiments of the present invention retain and use information about such persistent assets. However, retaining structured security information in the form of entity maps goes far beyond simply identifying potential malicious persistent assets. In response to detecting an attempt to access a file or a specific OS registry entry, some embodiments parse the stored mapping repository to determine whether the corresponding asset appears in any stored entity map, and if so, merge the stored map with the current entity map containing the entity that attempted to access it. Thus, some embodiments are able to reconstruct and fully characterize the entire kill chain across multiple computing sessions.
[0124] Some embodiments persistently store only a selected subset of entity maps, such as maps containing known segments of a kill chain, worker entities known to be used as carriers of malware, and specific resource entities typically used in an attack (e.g., selected OS registry entries). To efficiently select entity maps for persistent storage, some embodiments assemble a set of secure signatures and determine whether the current entity map matches any of the signatures in the set. The secure signature itself may contain a description of the signed entity map.This signature map can describe a documented attack strategy, such as a sequence of actions and entity types used for privilege escalation, ransomware attacks, data breaches, and others. Such signatures can be defined by computer security professionals and distributed to client computers as part of software updates or as part of a security subscription. For example, determining whether a target entity map matches a signature may include determining whether the target entity map contains a signed entity map as a subgraph.
[0125] In some embodiments, the security signature may further include an indicator of an action to be taken in response to a match between the corresponding signature and the current entity map. Exemplary actions include, in particular, determining that the corresponding client computer is infected with malware and setting a security flag associated with selected entities of the target entity map. Based on the observation that a signature match may indicate malicious suspicion, such security flags may influence the evaluation of selected entities or the entire corresponding group of entities.
[0126] In some embodiments, the detection engine calculates a set of dynamic malware indicative scores. Some scores may be attached to individual entities, while other scores may be attached to the entire group of entities identified by the entity map, as described above. Scores can vary based on the behavior of the corresponding software entities. The actions of individual entities can also affect group scores, thereby allowing for efficient detection of distributed malware.
[0127] The detection engine can selectively apply a set of detection models to determine malware indicative scores. The choice of models can depend on entity type, malware type, etc. The choice of models can be further influenced by the behavior of the corresponding entities and / or whether the entity mapping matches a specific security signature. In one such example, the entity mapping manager can set a security flag when the entity mapping matches a selected signature. The setting of the corresponding flag can be interpreted by the detection engine as a trigger to switch from one detection model to another. In one such example, the detection engine can use a default detection model comprising a compact set of minimal heuristics to evaluate the currently monitored group of entities. The detection engine can then switch to a more computationally expensive detection model in response to the activation of a security flag attached to the corresponding entity group. The corresponding flag can be set by the entity mapping manager in response to signature matching, as described above. By dynamically adjusting detection criteria based on current behavior and the previous history of the entity group, some embodiments of the present invention manage efficient detection of malware with minimal computational cost.
[0128] Specific instances of malware targeted by some embodiments of the present invention include recently discovered exploits of OS print spooler services that allow attackers to run arbitrary code in a spooler context, or even remotely (from another machine). In some client devices and operating systems, the print spooler loads a set of configuration data, such as printer drivers, from a set of local libraries.The corresponding configuration data prepares the background program to perform a specific print job, and can be printer-specific, user-specific, and / or job-specific. Malicious actors can exploit this mechanism by deliberately creating a corresponding library to contain malicious code or by secretly inserting the corresponding code into a currently used library. Loading the malicious DLL then causes the background program service to be used as an infection vector. Conventional security software that only monitors the behavior of the background program may have difficulty detecting such attacks. In contrast, some embodiments of the present invention can maintain an entity mapping that includes worker entities from the background program service and further includes configuration DLLs as resource entities. The mapping manager can then monitor attempts to access the configuration DLL, thereby detecting any suspicious modifications made by entities other than the background program service itself. In some embodiments, the use of entity mapping thus enables security software to distinguish between legitimate and potentially illegitimate use of the same process or service. The detection engine can then use a minimal set of heuristics to monitor the behavior of the print background program and switch to a more complex detection model only in response to the mapping manager detecting suspicious modifications to the configuration library. By flexibly adjusting the detection method according to the current situation, computational costs are minimized without sacrificing performance.
[0129] Persistently storing various entity mappings can also benefit other aspects of computer security. Some sophisticated attacks (such as the recent hack of the SolarWinds® Orion® platform) are not detected and fully described until much later, such as months after the actual attack. When the target is popular software with a potentially large customer base, many customers naturally want to know if their own computer systems have been affected and if any data breaches have occurred. However, retrospectively answering this question is notoriously difficult because malicious actors responsible for the attack often try to erase their footprints. By storing historical security data in the form of entity maps, some embodiments enable thorough forensic investigations into the previous behavior of computer systems. Once such intrusion indicators (IOCs) become available, such investigations can resolve the persistently stored set of entity maps to find various IOCs. Some IOCs can then be encoded as secure signatures containing the signed entity maps described herein.
[0130] Persistently stored entity maps and other structured security data further enable proactive research into attack methods. A specification, pages 19 / 20, 23 CN 121773419 A. Some embodiments can collect various entity maps from various client devices and analyze the entity map set to identify attack types specific to each type of device, OS, etc. and / or identify unknown kill chains, privilege escalation methods, and covert methods, etc.
[0131] The use of indicative signatures for malware is known in the field of computer security.Conventional signatures can be static (e.g., known malicious code segments, malicious instruction patterns, etc.) or behavioral (e.g., known malicious action sequences). However, in conventional anti-malware, signature matching is only used as a malicious indicator. Therefore, its occurrence is not logged and will not be reused in any way later. In contrast, in some embodiments of the present invention, signature matching typically triggers an update of the entity map first, which then only indirectly affects the scoring and detection of malware. In other words, some embodiments intentionally persist security information associated with selected signature matches, such as in the form of various metadata, security flags, scores, etc., thereby annotating the corresponding entity map. Persistently storing this data along with the associated entity map allows for a significantly richer interpretation and understanding of potential kill chains encoded within the corresponding stored entity map.
[0132] Those skilled in the art will understand that the above embodiments can be modified in many ways without departing from the scope of the invention. Therefore, the scope of the invention should be determined by the appended claims and their legal equivalents.Instruction manual 20 / 20 pages 24 CN 121773419 A Figure 1 Figure 2 Instruction manual drawing 1 / 16 pages 25 CN 121773419 A Figure 3 Instruction manual drawing 2 / 16 pages 26 CN 121773419 A Figure 4 Instruction manual drawing 3 / 16 pages 27 CN 121773419 A Figure 5-A Instruction manual drawing 4 / 16 pages 28 CN 121773419 A Figure 5-B Instruction manual drawing 5 / 16 pages 29 CN 121773419 A Figure 6 Instruction manual drawing 6 / 16 pages 30 CN 121773419 A Figure 7 Instruction manual drawing 7 / 16 pages 31 CN 121773419 A Figure 8 Figure 9 Instruction manual drawing 8 / 16 pages 32 CN 121773419 A Figure 10 Instruction manual drawing 9 / 16 pages 33 CN 121773419 Figure 11. Appendix to the instruction manual, page 10 / 16, 34 CN 121773419 Figure 12. Appendix to the instruction manual, page 11 / 16, 35 CN 121773419 Figure 13. Appendix to the instruction manual, page 12 / 16, 36 CN 121773419 Figure 14. Appendix to the instruction manual, page 13 / 16, 37 CN 121773419 Figure 15. Appendix to the instruction manual, page 14 / 16, 38 CN 121773419 Figure 16. Appendix to the instruction manual, page 15 / 16, 39 CN 121773419 Figure 17. Appendix to the instruction manual, page 16 / 16, 40 CN 121773419 Figure 18.
Claims
1. A computer system comprising at least one hardware processor configured to execute an entity mapping manager and a malware detection engine connected to the entity mapping manager, wherein: the entity mapping manager is configured to construct an entity mapping that specifies a group of interrelated software entities, and is further configured to: in response to a reboot of the computer system and in response to an attempt by a worker entity currently executing on the computer system to access a resource entity stored on a non-volatile storage device of the computer system, selectively retrieve the entity mapping from a mapping store according to whether the entity mapping includes a specification of the resource entity, and update the entity mapping by adding to the entity mapping a specification of the worker entity, wherein the entity mapping further includes a specification of another worker entity that had executed on the computer system prior to the reboot and a specification of a relationship between the another worker entity and the resource entity; and the malware detection engine is configured to determine whether the computer system includes malware according to the updated entity mapping.
2. The computer system of claim 1, wherein the resource entity is selected from a group consisting of a computer file and an operating system registry entry.
3. The computer system of claim 1, wherein the entity mapping manager is further configured to add to the entity mapping a specification of another resource entity in response to another attempt by the worker entity to access the another resource entity.
4. The computer system of claim 1, wherein the entity mapping manager is configured to, in response to the attempt by the worker entity to access the resource entity: identify another entity mapping according to whether the another entity mapping includes a specification of the worker entity; and in response, merge the entity mapping with the another entity mapping.
5. The computer system of claim 1, wherein the entity mapping manager is configured to, in response to detecting that a parent worker entity created a child worker entity: determine whether the parent worker entity has accessed the resource entity; and in response, if so, add to the entity mapping a specification of the child worker entity and a specification of a relationship between the child worker entity and the resource entity.
6. The computer system of claim 1, wherein: the specification of the worker entity includes a security flag; the entity mapping manager is configured to set the security flag in response to the attempt by the worker entity to access the resource entity; and the malware detection engine is configured to select a detection model from a plurality of detection models according to a current value of the security flag to determine whether the worker entity is malicious.
7. The computer system of claim 1, wherein: the specification of the resource entity includes a security flag; and the entity mapping manager is configured to, in response to an attempt to overwrite contents of the resource entity: set the security flag, retrieving the other entity mapping selectively from the mapping repository according to whether the other entity mapping contains the specification of the resource entity, and in response, deleting the other entity mapping.
8. The computer system of claim 6, wherein the entity mapping manager is further configured to add another instance of the resource entity to the entity mapping in response to the attempt to overwrite the contents of the resource entity.
9. The computer system of claim 1, wherein the entity mapping manager is further configured to save the updated entity mapping to the mapping repository.
10. The computer system of claim 1, wherein the malware detection engine is configured to determine whether the computer system includes malware according to results of comparing the entity mapping to a signature mapping that describes a malicious group of interrelated entities.
11. The computer system of claim 1, wherein the malware detection engine is configured to determine whether the computer system includes malware according to a malware-indicative score associated with the entity mapping and collectively characterizing all members of a group of entities identified according to the entity mapping, wherein the score is determined according to behavior of at least one member of the group of entities.
12. A computer security method comprising employing at least one hardware processor to execute an entity mapping manager and a malware detection engine connected to the entity mapping manager, wherein: the entity mapping manager is configured to construct an entity mapping that specifies a group of interrelated software entities; executing the entity mapping manager comprises employing the at least one hardware processor to: in response to a restart of the computer system and in response to an attempt by a worker entity currently executing on the computer system to access a resource entity stored on a non-volatile storage device of the computer system, selectively retrieve an entity mapping from a mapping repository according to whether the entity mapping contains a specification of the resource entity, and update the entity mapping by adding a specification of the worker entity to the entity mapping, wherein the entity mapping further contains a specification of another worker entity that had executed on the computer system prior to the restart and a specification of a relationship between the another worker entity and the resource entity; and executing the malware detection comprises employing the at least one hardware processor to determine whether the computer system includes malware according to the updated entity mapping.
13. The method of claim 12, wherein the resource entity is selected from the group consisting of a computer file and an operating system registry entry.
14. The method of claim 12, wherein executing the entity mapping manager further comprises adding a specification of another resource entity to the entity mapping in response to another instance of the attempt by the worker entity to access the another resource entity.
15. The method of claim 12, wherein executing the entity mapping manager further comprises, in response to the attempt by the worker entity to access the resource entity: identifying another entity mapping according to whether the other entity mapping includes the specification of the worker entity; and in response, merging the entity mapping with the other entity mapping.
16. The method of claim 12, wherein performing the entity mapping management further comprises, in response to detecting a parent worker entity creating a child worker entity: determining whether the parent worker entity has accessed the resource entity; and in response, if so, adding to the entity mapping a specification of the child worker entity and a specification of a relationship between the child worker entity and the resource entity.
17. The method of claim 12, wherein: the specification of the worker entity includes a security flag; performing the entity mapping manager further comprises setting the security flag in response to the attempt by the worker entity to access the resource entity; and performing the malware detection engine further comprises selecting a detection model from a plurality of detection models according to a current value of the security flag to determine whether the worker entity is malicious.
18. The method of claim 12, wherein: the specification of the resource entity includes a security flag; and performing the entity mapping manager further comprises, in response to an attempt to overwrite content of the resource entity: setting the security flag, selectively retrieving another entity mapping from the mapping repository according to whether the other entity mapping includes the specification of the resource entity, and in response, deleting the other entity mapping.
19. The method of claim 18, wherein performing the entity mapping manager further comprises, in response to the attempt to overwrite the content of the resource entity, adding another instance of the resource entity to the entity mapping.
20. The method of claim 12, wherein performing the entity mapping manager further comprises saving the updated entity mapping to the mapping repository.
21. The method of claim 12, wherein performing the malware detection engine comprises determining whether the computer system includes malware according to a result of comparing the entity mapping to a signature mapping that describes a malicious group of interrelated entities.
22. The method of claim 12, wherein performing the malware detection engine comprises determining whether the computer system includes malware according to a malware-indicative score associated with the entity mapping and collectively characterizing a group of entities identified according to the entity mapping, wherein the score is determined according to behavior of at least one member of the group of entities.
23. A non-transitory computer-readable medium storing instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to form an entity mapping manager and a malware detection engine connected to the entity mapping manager, wherein: the entity mapping manager is configured to construct an entity mapping that specifies a group of interrelated software entities, and is further configured to: in response to a restart of the computer system and in response to a worker entity currently executing on the computer system attempting to access a resource entity stored on a non-volatile storage device of the computer system, selectively retrieving an entity map from a map repository according to whether the entity map includes a specification of the resource entity, and updating the entity map by adding a specification of the worker entity to the entity map, wherein the entity map further includes a specification of another worker entity that has executed on the computer system prior to the restart and a specification of a relationship between the another worker entity and the resource entity; and the malware detection engine is configured to determine whether the computer system includes malware according to the updated entity map.