Prospective client identification using malware attack detection
US-9027135-B1 · May 5, 2015 · US
US11790079B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-11790079-B2 |
| Application number | US-202218089038-A |
| Country | US |
| Kind code | B2 |
| Filing date | Dec 27, 2022 |
| Priority date | May 20, 2019 |
| Publication date | Oct 17, 2023 |
| Grant date | Oct 17, 2023 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Disclosed herein are systems and methods for enabling the automatic detection of executable code from a stream of bytes. In some embodiments, the stream of bytes can be sourced from the hidden areas of files that traditional malware detection solutions ignore. In some embodiments, a machine learning model is trained to detect whether a particular stream of bytes is executable code. Other embodiments described herein disclose systems and methods for automatic feature extraction using a neural network. Given a new file, the systems and methods may preprocess the code to be inputted into a trained neural network. The neural network may be used as a “feature generator” for a malware detection model. Other embodiments herein are directed to systems and methods for identifying, flagging, and/or detecting threat actors which attempt to obtain access to library functions independently.
Opening claim text (preview).
What is claimed is: 1. A system for code detection, the system comprising: one or more computer readable storage devices configured to store a plurality of computer executable instructions; and one or more hardware computer processors in communication with the one or more computer readable storage devices and configured to execute the plurality of computer executable instructions in order to cause the system to: instrument an import address table (IAT) entry of a monitored symbol, the instrumenting of the TAT entry comprising: replacing a monitored symbol address within the TAT entry of the monitored symbol with a modified address; executing a first code upon a call of the modified address to detect and validate a call of the monitored symbol; and redirecting the call of the modified address to the monitored symbol address; instrument one or more functions, the instrumenting of the one or more functions comprising: modifying the one or more functions to return values that lead to the code; detouring execution of the monitored symbol to a second code to detect and validate a call of the monitored symbol; and redirecting the call of the monitored symbol to the monitored symbol address; monitor the first code and the second code of the monitored symbol to determine if calls from an executable comprise a static call, a dynamic call, or a local call, wherein determination of whether the calls from the executable comprise a local call comprises monitoring the second code to determine if a return address is located in the same executable as the monitored symbol; and if the system determines that at least one call from the executable does not comprise a static call, dynamic call, or a local call, flag the executable as suspicious or malicious. 2. The system of claim 1 , wherein the system is further caused to, if the system determines that the at least one call does not comprise a static call, dynamic call, or local call, classify the at least one call as an independent call. 3. The system of claim 1 , wherein the system is further caused to, if the system determines that the calls comprise a static call, dynamic call, or local call, classify the calls as benign calls. 4. The system of claim 1 , wherein the system is further caused to, if the system determines that the calls comprise a static call, dynamic call, or local call, classify the executable as benign. 5. The system of claim 1 , further comprising: A hooking engine comprising the first code and the second code; and one or more call databases configured to store data related to the calls. 6. The system of claim 1 , wherein the dynamic call comprises an attempted retrieval of the monitored symbol address during execution of the executable. 7. The system of claim 1 , wherein the static call comprises an attempted retrieval of the monitored symbol address during initialization of the executable. 8. The system of claim 1 , wherein the one or more functions comprise one or both of GetModuleHandle or GetProcAddress. 9. The system of claim 1 , wherein the at least one call is initiated by the executable using metadata retrieved from a module comprising the monitored symbol. 10. The system of claim 1 , wherein the at least one call is initiated by the executable using data retrieved from a Loader internal record. 11. The system of claim 1 , wherein the at least one call is initiated by the executable by calling the monitored symbol without triggering the trampoline code. 12. A computer implemented method for code detection, the method comprising: instrumenting, by a computer system, an import address table (IAT) entry of a monitored symbol, the instrumenting of the TAT entry comprising: replacing a monitored symbol address within the IAT entry of the monitored symbol with a modified address; executing a first code upon a call of the modified address to detect and validate a static call of the monitored symbol; and redirecting the call of the modified address to the monitored symbol address; instrumenting, by the computer system, one or more functions, the instrumenting of the one or more functions comprising: modifying the one or more functions to return values that lead to the first code; detouring the execution of the monitored symbol to a second code to detect and validate a call of the monitored symbol; and redirecting the call of the monitored symbol to the monitored symbol address; monitoring, by the computer system, the first code and the second code of the monitored symbol to determine if calls from an executable comprise a static call, a dynamic call, or a local call, wherein determination of whether the calls from the executable comprise a local call comprises monitoring the second code to determine if a return address is located in the same executable as the monitored symbol; and if the computer system determines that at least one call from the executable does not comprise a static call, dynamic call, or a local call, flagging, by the computer system, the executable as suspicious or malicious, wherein the computer system comprises a computer processor and an electronic storage medium. 13. The method of claim 12 , further comprising, if the computer system determines that the at least one call does not comprise a static call, dynamic call, or local call, classifying the at least one call as an independent call. 14. The method of claim 12 , further comprising, if the computer system determines that the calls comprise a static call, dynamic call, or local call, classifying the calls as benign calls. 15. The method of claim 12 , further comprising, if the computer system determines that the calls comprise a static call, dynamic call, or local call, classifying the executable as benign. 16. The method of claim 12 , wherein the first code and the second code comprise one or more portions of a hooking engine, the hooking engine connected to a call database configured to store data related to the calls. 17. The method of claim 12 , wherein the dynamic call comprises an attempted retrieval of the monitored symbol address during execution of the executable. 18. The method of claim 12 , wherein the static call comprises an attempted retrieval of the monitored symbol address during initialization of the executable. 19. The method of claim 12 , wherein the at least one call is initiated by the executable using metadata retrieved from a module comprising the monitored symbol. 20. A computer implemented method for code detection, the method comprising: instrumenting, by a computer system, one or more functions, the instrumenting of the one or more functions comprising: modifying the one or more functions to return values that lead to a first code; detouring the execution of a monitored symbol to a second code to detect and validate a call of the monitored symbol; and redirecting the call of the monitored symbol to the monitored symbol address; monitoring, by the computer system, the first code and the second code of the monitored symbol to determine if calls from an executable comprise a static call, a dynamic call, or a local call, wherein determination of whether the calls from the executable comprise a local call comprises monitoring the second code to determine if a return address is located in the same executable as the monitored symbol; and if the computer system determines that at least one call from the executable does not comprise a static call, dynamic call, or a local call, flagging, by the computer system, the executable as su
by adding security routines or objects to programs · CPC title
Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities · CPC title
Test or assess software · CPC title
by virus signature recognition · CPC title
Assessing vulnerabilities and evaluating computer system security · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.