IP Library Granted Patent US 10,528,735
Granted Patent B2
US 10,528,735 · App. 15/324,656 · Granted Jan 7, 2020

Malicious code protection for computer systems based on process modification

Inventors: Michael Gorelik (Beer Sheva, IL); Mordechai Guri (Modiin, IL); David Mimran (Tel Aviv, IL); Gabriel Kedma (Omer, IL); Ronen Yehoshua (Matan, IL)
Assignee: Morphisec Information Security 2014 Ltd.
G06F21/566G06F21/52G06F21/54G06F2221/034
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,528,735
App. No.
15/324,656
Granted
Jan 7, 2020
Kind
B2
Abstract

Various approaches are described herein for, among other things, detecting and/or neutralizing attacks by malicious code. For example, instance(s) of a protected process are modified upon loading by injecting a runtime protector that creates a copy of each of the process' imported libraries and maps the copy into a random address inside the process' address space to form a “randomized” shadow library. The libraries loaded at the original address are modified into a stub library. Shadow and stub libraries are also created for libraries that are loaded after the process creation is finalized. Consequently, when malicious code attempts to retrieve the address of a given procedure, it receives the address of the stub procedure, thereby neutralizing the malicious code. When the original program's code (e.g., the non-malicious code) attempts to retrieve the address of a procedure, it receives the correct address of the requested procedure (located in the shadow library).

Claims (64)

1. A method, comprising:

determining that a process loader of an operating system has initiated the creation of a computing process; and

in response to determining that the process loader has initiated the creation of the computing process, injecting code in the computing process that is configured to modify the computing process by:

determining that at least one library module of the computing process is to be loaded into memory;

storing the at least one library module at a first address in the memory;

copying the at least one library module stored at the first address to a second address in the memory that is different than the first address;

modifying the at least one library module stored at the first address into a stub library module;

causing a first procedure call for a procedure in the at least one library module to reference the second address of the at least one library module; and

causing a second procedure call for a procedure in the at least one library module to reference the first address of the at least one library module, the second procedure call originating from malicious code that is injected into the computing process after loading of a binary image, from which the computing process is created, into memory is complete.

2. The method of claim 1 , wherein determining that at least one library module of the computing process is to be loaded into memory comprises:

intercepting a procedure call initiated by the process loader to determine that at least one library module of the computing process is to be loaded into memory, the procedure call identifying the at least one library module of the computing process that is to be loaded.

3. The method of claim 1 , wherein

the first procedure call is included in at least one of the binary image and one or more other library modules imported for the computing process.

4. The method of claim 1 , wherein said causing a first procedure call for a procedure in the at least one library module to reference the second address of the at least one library module comprises:

updating a data structure that stores an address at which the at least one library module is loaded into the memory with the second address of the at least one library module, thereby causing the first procedure call to reference the second address of the at least one library module.

5. The method of claim 4 , wherein the data structure is an import address table.

6. The method of claim 5 , further comprising:

randomizing at least one of the following:

a location at which the import address table is loaded into the memory;

one or more procedure names stored in the import address table; and

one or more indices within the import address table that correspond to the one or more procedure names.

7. The method of claim 1 , wherein modifying the library module stored at the first address into a stub library module comprises:

causing one or more executable portions of the library module stored at the first address to be designated as non-accessible.

8. The method of claim 7 , further comprising:

detecting an exception thrown by the operating system, the exception being thrown as a result of malicious code attempting to access the library module stored at the first address; and

determining that a malicious attack has occurred in response to detecting the exception.

9. The method of claim 1 , further comprising:

randomizing the second address.

10. The method of claim 1 , further comprising:

randomizing at least one of the following:

a location at which an export address table is loaded into the memory, the export address table including one or more addresses of one or more procedures that are exportable by the computing process;

one or more procedure names stored in the export address table; and

one or more indices within the export address table that correspond to the one or more procedure names.

11. The method of claim 1 , further comprising:

randomizing at least one of one or more elements of a first data structure used by the operating system to manage the computing process and one or more elements of a second data structure used by the operating system to manage one or more threads associated with the computing process.

12. The method of claim 11 , wherein the first data structure is a process environment block and the second data structure is a thread environment block.

13. The method of claim 1 , further comprising:

randomizing one or more elements of one or more resource tables including resource information for the computing process.

14. A system, comprising:

one or more processing units; and

a memory coupled to the one or more processing units, the memory storing software modules for execution by the one or more processing units, the software modules comprising:

a runtime protector configured to:

load a library module for the computing process at a first address in the memory;

copy the library module stored at the first address to a second address in the memory that is different than the first address, wherein code that accesses the library module stored at the second address is designated as being non-malicious code;

modify the library module stored at the first address into a stub library module, wherein code attempting to access the library module stored at the first address is designated as being malicious code;

cause a first procedure call for a procedure in the library module to reference the second address of the at least one library module; and

cause a second procedure call for a procedure in the library module to reference the first address of the library module, the second procedure call originating from malicious code that is injected into the computing process after loading of a binary image, from which the computing process is created, into memory is complete.

15. The system of claim 14 , wherein the runtime protector is further configured to:

update an import address table that stores one or more addresses at which one or more library modules are loaded into the memory with the second address of the library module, thereby causing code originating from the binary image to access the library module at the second address instead of the first address.

16. The system of claim 14 , wherein the runtime protector is further configured to:

cause one or more executable portions of the library module stored at the first address to be designated as non-accessible.

17. The system of claim 16 , the software modules further comprising:

an exception handler configured to detect an exception thrown by an operating system, the exception being thrown as a result of malicious code attempting to access the library module stored at the first address, the runtime protector further configured to:

determine that a malicious attack has occurred in response to a determination that the exception handler has detected the exception.

18. The system of claim 17 , wherein the runtime protector is further configured to:

randomize a location at which the exception handler is loaded into the memory.

19. The system of claim 14 , wherein the runtime protector is further configured to:

randomize the second address.

20. A computer-readable storage medium having program instructions recorded thereon that, when executed by a processing device, perform a method for modifying a computing process, the method comprising:

loading a library module for the computing process at a first address in the memory;

copying the library module stored at the first address to a second, randomized address in the memory that is different than the first address, wherein code that accesses the library module stored at the second address is designated as being non-malicious code;

modifying the library module stored at the first address into a stub library module, wherein code attempting to access the library module stored at the first address is designated as being malicious code;

causing a first procedure call for a procedure in the library module to reference the second address of the at least one library module; and

causing a second procedure call for a procedure in the library module to reference the first address of the library module, the second procedure call originating from malicious code that is injected into the computing process after loading of a binary image, from which the computing process is created, into memory is complete.

Assignments (8)
SECURITY INTEREST Recorded Oct 1, 2024
From: MORPHISEC INFORMATION SECURITY 2014 LTD
To: HERCULES CAPITAL, INC.
Reel/Frame 068758/0581 →
RELEASE OF SECURITY INTEREST Recorded Oct 13, 2021
From: SILICON VALLEY BANK
To: MORPHISEC INFORMATION SECURITY 2014 LTD.
Reel/Frame 057781/0949 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Nov 11, 2019
From: GORELIK, MICHAEL; GURI, MORDECHAI; MIMRAN, DAVID; KEDMA, GABRIEL; YEHOSHUA, RONEN
To: MORPHISEC INFORMATION SECURITY 2014 LTD.
Reel/Frame 050973/0822 →
INTELLECTUAL PROPERTY SECURITY AGREEMENT Recorded Jul 9, 2019
From: MORPHISEC INFORMATION SECURITY 2014 LTD
To: SILICON VALLEY BANK
Reel/Frame 049706/0331 →
RELEASE OF SECURITY INTEREST Recorded Nov 19, 2018
From: SILICON VALLEY BANK
To: MORPHISEC INFORMATION SECURITY 2014 LTD.
Reel/Frame 047538/0484 →
SECURITY INTEREST Recorded Aug 21, 2017
From: MORPHISEC INFORMATION SECURITY 2014 LTD
To: SILICON VALLEY BANK
Reel/Frame 043343/0860 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 21, 2017
From: GORELIK, MICHAEL; GURI, MORDECHAI; MIMRAN, DAVID; KEDMA, GABRIEL; YEHOSHUA, RONEN
To: MORPHISEC INFORMATION SECURITY LTD.
Reel/Frame 043062/0827 →
SECURITY INTEREST Recorded Feb 7, 2017
From: MORPHISEC INFORMATION SECURITY 2014 LTD
To: SILICON VALLEY BANK
Reel/Frame 041191/0245 →
Continuity (2)
Provisional Application 62080841 · Nov 17, 2014
Related Publication 20170206357A1 · Jul 20, 2017