System and method for below-operating system trapping and securing of interdriver communication

• US 8,959,638 B2
• Filed: 03/29/2011
• Issued: 02/17/2015
• Est. Priority Date: 03/29/2011
• Status: Active Grant

• Current Assignee: McAfee, LLC
• Original Assignee: McAfee, Inc. (McAfee, LLC)
• Inventors: Sallam, Ahmed Said
• Primary Examiner(s): Chao, Michael
• Assistant Examiner(s): Gao, Shu Chun
• Application Number:
  US13/075,072
• Publication Number:
  US 20120255000A1
• Time in Patent Office: 1,421 Days
• Field of Search: 726 22- 25
• US Class Current: 726/23
• CPC Class Codes: G06F 21/566 Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities

Abstract

In one embodiment, a system for protecting an electronic device against malware includes a memory, an operating system configured to execute on the electronic device, and a below-operating-system security agent. The below-operating-system security agent is configured to trap an attempted access by a first driver of the operating system of a second driver of the electronic device, access one or more security rules to determine whether the attempted access is indicative of malware, and operate at a level below all of the operating systems of the electronic device accessing the second driver.

Claims

1. A system for protecting an electronic device against malware, comprising:

a memory;

an operating system included in one or more operating systems configured to execute on the electronic device;

a below-operating-system security agent configured to;

trap an attempted access by a first driver of the operating system of a second, different driver of the electronic device, the attempted access including the first driver calling a function of the second driver;

determine and evaluate an identity and security status of the first driver;

determine whether the attempted access includes an attempted direct access of a code section of the second driver by bypassing functions provided by a kernel module of the operating system, the functions for accessing the code section of the second driver;

access one or more security rules to;

determine whether the attempted access is indicative of malware based on a determination that the first driver called the function of the second driver;

determine that the attempted access is indicative of malware based upon a determination that a security status of the first driver is unknown;

determine whether the attempted access is indicative of malware based upon a determination that the second driver attempted to access the code section of the second driver by bypassing functions provided by a kernel module of the operating system for accessing the code section of the second driver; and

take corrective action based upon;

whether the first driver calling the function of the second driver is indicative of malware;

whether the identity of the first driver is unknown; and

whether the second driver attempted to access the code section of the second driver by bypassing functions provided by a kernel module of the operating system for accessing the code section of the second driver and

operate at a level below all operating systems of the electronic device accessing the second driver.

2. The system of claim 1, wherein:

the attempted access includes an attempted installation by the first driver of a callback routine in the second driver by registering the callback routine in a data section of the second driver; and

the below-operating-system security agent is further configured to, based upon installation of the callback routine in the second driver by the first driver;

access the security rules to further determine whether the attempted access, including the attempted installation of the second driver, is indicative of malware; and

trap subsequent access of the callback routine of the first driver.

3. The system of claim 2, wherein the subsequent access of the callback function of the first driver is based upon a determination that the first driver that installed the callback function has an unknown malware status.

4. The system of claim 1, wherein the attempted access includes an attempted access of an address from an export table of the second driver.

5. The system of claim 1, wherein:

the attempted access includes an attempted access of a data section of the second driver by the first driver; and

the below-operating-system security agent is further configured to, based upon an identification of the data section as accessed by the first driver;

access the security rules to further determine whether the attempted access, including the attempted access of the identified data section of the second driver, is indicative of malware; and

prevent the attempted access based upon the determination of whether the attempted access of the identified data section is indicative of malware.

6. The system of claim 5, wherein the attempted access includes an attempted access of information about a third driver communicatively coupled to the second driver.

7. The system of claim 6, wherein the attempted access includes an attempted access of an address from an import table of the second driver, the import table containing information regarding the third driver.

8. The system of claim 1, wherein the attempted access includes an attempted hooking of a function of the second driver.

9. The system of claim 1, wherein:

the attempted access includes an interdriver input-output request packet sent to the second driver from the first driver; and

the below-operating-system security agent is further configured to;

access the security rules to further determine whether the attempted access, including the interdriver input-output request packet sent to the second driver from the first driver, is indicative of malware; and

take corrective action based on a determination that the interdriver input-output request sent to the second driver from the first driver is indicative of malware.

10. The system of claim 1, wherein the attempted access includes an attempted write to a code section of the second driver.

11. A method for protecting an electronic device against malware, comprising:

trapping an attempted access by a first driver of an operating system of a second, different driver of the electronic device, the attempted access including the first driver calling a function of the second driver;

determining an identity and security status of the first driver;

determining whether the attempted access includes an attempted direct access of a code section of the second driver by bypassing functions provided by a kernel module of the operating system, the functions for accessing the code section of the second driver;

accessing one or more security rules;

determining, based on the one or more security rules;

whether the attempted access, including the first driver calling the function of the second driver, is indicative of malware;

that the attempted access is indicative of malware based upon a determination that a security status of the first driver is unknown;

whether the attempted access is indicative of malware based upon a determination that the second driver attempted to access the code section of the second driver by bypassing functions provided by a kernel module of the operating system for accessing the code section of the second driver;

and

taking corrective action based upon;

whether the first driver calling the function of the second driver is indicative of malware;

whether the identity of the first driver is unknown; and

whether the second driver attempted to access the code section of the second driver by bypassing functions provided by a kernel module of the operating system for accessing the code section of the second driver;

wherein the trapping of the attempted access and determining whether the attempted access is indicative of malware are conducted at a level below all operating systems of the electronic device accessing the second driver.

12. The method of claim 11, wherein:

the attempted access includes an attempted installation of a callback routine by the first driver of a callback routine in the second driver by registering the callback routine in a data section of the second driver; and

the method further includes, based upon installation of the callback routine in the second driver by the first driver;

accessing the security rules to further determine whether the attempted access, including the attempted installation of the second driver, is indicative of malware; and

trapping subsequent access of the callback routine of the first driver.

13. The method of claim 11, wherein the attempted access includes an attempted access of an address from an export table of the second driver.

14. The method of claim 11, wherein:

the attempted access includes an attempted access of a data section of the second driver by the first driver; and

the method further includes, based upon an identification of the data section as accessed by the first driver;

accessing the security rules to further determine whether the attempted access, including the attempted access of the identified data section of the second driver, is indicative of malware; and

preventing the attempted access based upon the determination of whether the attempted access of the identified data section is indicative of malware.

15. The method of claim 14, wherein the attempted access includes an attempted access of information about a third driver communicatively coupled to the second driver.

16. The method of claim 15, wherein the attempted access includes an attempted access of an address from an import table of the second driver, the import table containing information regarding the third driver.

17. The method of claim 11, wherein the attempted access includes an attempted hooking of a function of the second driver.

18. The method of claim 11, wherein:

the attempted access includes an interdriver input-output request packet sent to the second driver from the first driver; and

the method further includes;

accessing the security rules to further determine whether the attempted access, including the interdriver input-output request packet sent to the second driver from the first driver, is indicative of malware; and

taking corrective action based on a determination that the interdriver input-output request sent to the second driver from the first driver is indicative of malware.

19. The method of claim 11, wherein the attempted access includes an attempted write to a code section of the second driver.

20. An article of manufacture, comprising:

a non-transitory computer readable medium; and

computer-executable instructions carried on the non-transitory computer readable medium, the instructions readable by a processor, the instructions, when read and executed, for causing the processor to;

trap an attempted access by a first driver of an operating system of a second driver of the electronic device, the attempted access including the first driver calling a function of the second driver, the electronic device including one or more operating systems;

determining an identity and security status of the first driver;

determining whether the attempted access includes an attempted direct access of a code section of the second driver by bypassing functions provided by a kernel module of the operating system, the functions for accessing the code section of the second driver;

access one or more security rules to determine whether the attempted access is indicative of malware;

determine, based on the one or more security rules, whether the first driver calling the function of the second driver is indicative of malware;

determine, based on the one or more security rules, that the attempted access is indicative of malware based upon a determination that a security status of the first driver is unknown;

determine, based on the one or more security rules, whether the attempted access is indicative of malware based upon a determination that the second driver attempted to access the code section of the second driver by bypassing functions provided by a kernel module of the operating system for accessing the code section of the second driver;

and

take corrective action based upon;

whether the first driver calling the function of the second driver is indicative of malware;

whether the identity of the first driver is unknown; and

whether the second driver attempted to access the code section of the second driver by bypassing functions provided by a kernel module of the operating system for accessing the code section of the second driver;

wherein the processor is configured to conduct the trapping of the attempted access and determining whether the attempted access is indicative of malware at a level below all operating systems of the electronic device accessing the second driver.

21. The article of claim 20, wherein:

the attempted access includes an attempted installation of a callback routine by the first driver of a callback routine in the second driver by registering the callback routine in a data section of the second driver; and

the article further includes instructions to, based upon installation of the callback routine in the second driver by the first driver;

access the security rules to further determine whether the attempted access, including the attempted installation of the second driver, is indicative of malware; and

trap subsequent access of the callback routine of the first driver.

22. The article of claim 20, wherein the attempted access includes an attempted access of an address from an export table of the second driver.

23. The article of claim 20, wherein:

the attempted access includes an attempted access of a data section of the second driver by the first driver; and

the article further includes instructions to, based upon an identification of the data section as accessed by the first driver;

access the security rules to further determine whether the attempted access, including the attempted access of the identified data section of the second driver, is indicative of malware; and

prevent the attempted access based upon the determination of whether the attempted access of the identified data section is indicative of malware.

24. The article of claim 23, wherein the attempted access includes an attempted access of information about a third driver communicatively coupled to the second driver.

25. The article of claim 24, wherein the attempted access includes an attempted access of an address from an import table of the second driver, the import table containing information regarding the third driver.

26. The article of claim 20, wherein the attempted access includes an attempted hooking of a function of the second driver.

27. The article of claim 20, wherein the attempted access includes an input-output request packet sent to the second driver.

28. The article of claim 20, wherein:

the attempted access includes an interdriver input-output request packet sent to the second driver from the first driver; and

the article further includes instructions to;

access the security rules to further determine whether the attempted access, including the interdriver input-output request packet sent to the second driver from the first driver, is indicative of malware; and

take corrective action based on a determination that the interdriver input-output request sent to the second driver from the first driver is indicative of malware.