IP Library Granted Patent US 11,146,572
Granted Patent B2
US 11,146,572 · App. 16/040,021 · Granted Oct 12, 2021

Automated runtime detection of malware

Inventors: Satya V. Gupta (Dublin, CA); Raymond F. DeMeo (Pleasanton, CA)
Assignee: Virsec Systems, Inc.
H04L63/1416G06F21/54G06F21/566H04L63/145
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 11,146,572
App. No.
16/040,021
Granted
Oct 12, 2021
Kind
B2
Abstract

One example method and correspond apparatus extracts a model of a computer application during load time and stores the model of the computer application in a database. This example method and corresponding apparatus also inserts instructions into the computer application to collect data at runtime. This example method and corresponding apparatus then analyzes the data collected at runtime against the stored model of the computer application to detect one or more security events and tracks the one or more security events using a state machine.

Claims (47)

1. A computer-implemented method comprising:

prior to executing a module of a computer application and before the module is loaded into memory, verifying integrity of the module as the module of the computer application is being loaded into the memory by adding instructions into an execution pipeline, wherein the instructions are added into the execution pipeline as the module is being loaded into the memory and the instructions are configured for:

computing a checksum of the module;

comparing the computed checksum against a valid checksum stored in memory for the module; and

generating at least one security event if the computed checksum does not match the valid checksum, the at least one security event triggering at least one remedial action related to the computer application.

2. The method of claim 1 , further comprising:

if the computed checksum does match the valid checksum:

extracting code sections of the module during load time;

analyzing data collected at runtime against the extracted code sections; and

generating one or more security events based on the analysis, the one or more security events triggering one or more remedial actions related to the computer application.

3. The method of claim 2 , wherein a remedial action is one of: terminating the computer application, terminating one or more threads of the computer application, unbinding or releasing a socket on one or more threads of the computer application, unblocking sockets associated with a server socket of the computer application, generating notifications to a user, and ignoring a security event.

4. The method of claim 2 , wherein a security event is processed in one of: monitor mode, paranoid mode, or learning mode, and wherein each mode provides different processing of the security event.

5. The method of claim 4 , wherein in the monitor mode:

generating a notification to a user in response to the security event; and

triggering the one or more remedial actions by the user.

6. The method of claim 4 , wherein in the paranoid mode:

automatically triggering the one or more remedial actions in response to the security event.

7. The method of claim 4 , wherein in the learning mode:

collecting information associated with the security event; and

based on the collected information, building criteria for automatically generating future security events and triggering remedial actions in response to the future security events.

8. The method of claim 1 , wherein the computing of the checksum is performed by a checksum verification service.

9. The method of claim 1 , wherein the comparing of the computed checksum determines whether the module is corrupted with malware prior to being loaded to memory.

10. A computer system comprising:

prior to executing a module of a computer application and before the module is loaded into memory, verifying integrity of the module as the module of the computer application is being loaded into the memory by:

a client configured to add instructions into an execution pipeline, wherein the instructions are added into the execution pipeline as the module is being loaded into the memory and the instructions are configured to:

compute a checksum of the module; and

compare the computed checksum against a valid checksum stored in memory for the module; and

an analysis engine configured to:

generate at least one security event if the computed checksum does not match the valid checksum, the at least one security event triggering at least one remedial action related to the computer application.

11. The system of claim 10 , wherein:

the client further configured to:

if the computed checksum does match the valid checksum, extract code sections of the module during load time; and

the analysis engine further configured to:

analyze data collected at runtime against the extracted code sections; and

generate one or more security events based on the analysis, the one or more security events triggering one or more remedial actions related to the computer application.

12. The system of claim 11 , wherein a remedial action is one of: terminating the computer application, terminating one or more threads of the computer application, unbinding or releasing a socket on one or more threads of the computer application, unblocking sockets associated with a server socket of the computer application, generating notifications to a user, and ignoring a security event.

13. The system of claim 11 , wherein the analysis engine is configured to process a security event in one of: monitor mode, paranoid mode, or learning mode, and wherein each mode provides different processing of the security event.

14. The system of claim 13 , wherein in the monitor mode, the analysis engine is configured to:

generate a notification to a user in response to the security event; and

trigger the one or more remedial actions by the user.

15. The system of claim 13 , wherein in the paranoid mode, the analysis engine is configured to:

automatically trigger the one or more remedial actions in response to the security event.

16. The system of claim 13 , wherein in the learning mode, the analysis engine is configured to:

collect information associated with the security event; and

based on the collected information, build criteria for automatically generating future security events and triggering remedial actions in response to the future security events.

17. The system of claim 10 , wherein the computing of the checksum is performed by a checksum verification service.

18. The system of claim 10 , wherein the comparing of the computed checksum determines whether the module is corrupted with malware prior to being loaded to memory.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 25, 2018
From: GUPTA, SATYA VRAT; DEMEO, RAYMOND F.
To: VIRSEC SYSTEMS, INC.
Reel/Frame 046454/0289 →
Continuity (3)
Continuation 14916066
Provisional Application 61960209 · Sep 12, 2013
Related Publication 20180324195A1 · Nov 8, 2018
Cited By (3)
US 12,511,374 US 12,579,257 US 12,632,551