Abstract: Examples of the present disclosure describe systems and methods for restricting access to application programming interfaces (APIs). For example, when a process calls an API, the API call may be intercepted by a security system for evaluation of its trustfulness before the API is allowed to run. Upon intercepting an API call, the process calling the API may be evaluated to determine if the process is known to the security system, such that known processes that are untrusted may be blocked from calling the API. Further, when the security system cannot identify the process calling the API, the security service may evaluate a call stack associated with the call operation to determine if attributes of the call operation are known to the security system. If the call operation is known to the security system as untrusted, the call operation may be blocked from calling the API.

Abstract: The present disclosure relates to systems and methods for identifying highly sensitive modules and taking a remediation or preventative action if such modules are accessed by malicious software. For example, the likelihood that a module is used for an exploit, and is thus sensitive, is categorized as high, medium, or low. The likelihood that a module can be used for an exploit can dictate whether, and to what degree, an application accessing the module is “suspicious.” However, in some instances, a sensitive module may have legitimate reasons to load when used in certain non-malicious ways. The system may also consider a trust level when determining what actions to take, such that an application and/or user having a higher trust level may be less suspicious when accessing a sensitive module as compared to an application or user having a lower trust level.

Abstract: Examples of the present disclosure describe systems and methods for malicious software detection based on API trust. In an example, a set of software instructions executed by a computing device may call an API. A hook may be generated on the API, such that a threat processor may receive an indication when the API is called. Accordingly, the threat processor may generate a trust metric based on the execution of the set of software instructions, which may be used to determine whether the set of software instructions poses a potential threat. For example, one or more call stack frames may be evaluated to determine whether a return address is preceded by a call instruction, whether the return address is associated with a set of software instructions or memory associated with a set of software instructions, and/or whether the set of software instructions satisfies a variety of security criteria.

Abstract: Examples of the present disclosure describe systems and methods for restricting access to application programming interfaces (APIs). For example, when a process calls an API, the API call may be intercepted by a security system for evaluation of its trustfulness before the API is allowed to run. Upon intercepting an API call, the process calling the API may be evaluated to determine if the process is known to the security system, such that known processes that are untrusted may be blocked from calling the API. Further, when the security system cannot identify the process calling the API, the security service may evaluate a call stack associated with the call operation to determine if attributes of the call operation are known to the security system. If the call operation is known to the security system as untrusted, the call operation may be blocked from calling the API.

Abstract: Examples of the present disclosure describe systems and methods for exploit detection via induced exceptions. One embodiment of a method can include generating an inspection point, the inspection point causing an exception when a set of software instructions encounters the inspection point during an execution of the set of software instructions by a processor, registering an exception handler to handle the exception associated with by the inspection point; receiving, in response to the set of software instructions encountering the inspection point, an indication of an exception, accessing a context record associated with the execution of the set of software instructions, evaluating the context record to determine if an exploit is present using the first reputation information, and based on a determination that an exploit is present, performing a corrective action for the exploit.

Abstract: Examples of the present disclosure describe systems and methods for exploit detection via induced exceptions. One embodiment of a method can include generating an inspection point, the inspection point causing an exception when a set of software instructions encounters the inspection point during an execution of the set of software instructions by a processor, registering an exception handler to handle the exception associated with by the inspection point; receiving, in response to the set of software instructions encountering the inspection point, an indication of an exception, accessing a context record associated with the execution of the set of software instructions, evaluating the context record to determine if an exploit is present using the first reputation information, and based on a determination that an exploit is present, performing a corrective action for the exploit.

Abstract: Examples of the present disclosure describe systems and methods for malicious software detection based on API trust. In an example, a set of software instructions executed by a computing device may call an API. A hook may be generated on the API, such that a threat processor may receive an indication when the API is called. Accordingly, the threat processor may generate a trust metric based on the execution of the set of software instructions, which may be used to determine whether the set of software instructions poses a potential threat. For example, one or more call stack frames may be evaluated to determine whether a return address is preceded by a call instruction, whether the return address is associated with a set of software instructions or memory associated with a set of software instructions, and/or whether the set of software instructions satisfies a variety of security criteria.

Abstract: The present disclosure relates to systems and methods for identifying highly sensitive modules and taking a remediation or preventative action if such modules are accessed by malicious software. For example, the likelihood that a module is used for an exploit, and is thus sensitive, is categorized as high, medium, or low. The likelihood that a module can be used for an exploit can dictate whether, and to what degree, an application accessing the module is “suspicious.” However, in some instances, a sensitive module may have legitimate reasons to load when used in certain non-malicious ways. The system may also consider a trust level when determining what actions to take, such that an application and/or user having a higher trust level may be less suspicious when accessing a sensitive module as compared to an application or user having a lower trust level.

Abstract: The present disclosure relates to systems and methods for identifying highly sensitive modules and taking a remediation or preventative action if such modules are accessed by malicious software. For example, the likelihood that a module is used for an exploit, and is thus sensitive, is categorized as high, medium, or low. The likelihood that a module can be used for an exploit can dictate whether, and to what degree, an application accessing the module is “suspicious.” However, in some instances, a sensitive module may have legitimate reasons to load when used in certain non-malicious ways. The system may also consider a trust level when determining what actions to take, such that an application and/or user having a higher trust level may be less suspicious when accessing a sensitive module as compared to an application or user having a lower trust level.

Abstract: Examples of the present disclosure describe systems and methods for malicious software detection based on API trust. In an example, a set of software instructions executed by a computing device may call an API. A hook may be generated on the API, such that a threat processor may receive an indication when the API is called. Accordingly, the threat processor may generate a trust metric based on the execution of the set of software instructions, which may be used to determine whether the set of software instructions poses a potential threat. For example, one or more call stack frames may be evaluated to determine whether a return address is preceded by a call instruction, whether the return address is associated with a set of software instructions or memory associated with a set of software instructions, and/or whether the set of software instructions satisfies a variety of security criteria.

Abstract: Examples of the present disclosure describe systems and methods for exploit detection via induced exceptions. In an example, one or more inspection points are generated by a threat processor. For instance, an inspection point may be generated by altering aspects of one or more APIs, setting a process or hardware breakpoint, and/or modifying permissions of one or more memory pages, among other examples. The threat processor may register one or more exception handlers corresponding to the generated inspection points. As a result, when a set of software instructions encounters an inspection point and throws an exception, the threat processor may catch the exception and process a context record associated with software execution according to identify the presence of an exploit. Accordingly, inspection points ensure that the software execution state is preserved, such that the call stack, registers, and other context information is available for analysis by the threat processor.

Abstract: Examples of the present disclosure describe systems and methods for restricting access to application programming interfaces (APIs). For example, when a process calls an API, the API call may be intercepted by a security system for evaluation of its trustfulness before the API is allowed to run. Upon intercepting an API call, the process calling the API may be evaluated to determine if the process is known to the security system, such that known processes that are untrusted may be blocked from calling the API. Further, when the security system cannot identify the process calling the API, the security service may evaluate a call stack associated with the call operation to determine if attributes of the call operation are known to the security system. If the call operation is known to the security system as untrusted, the call operation may be blocked from calling the API.

Abstract: The present disclosure relates to systems and methods for identifying highly sensitive modules and taking a remediation or preventative action if such modules are accessed by malicious software. For example, the likelihood that a module is used for an exploit, and is thus sensitive, is categorized as high, medium, or low. The likelihood that a module can be used for an exploit can dictate whether, and to what degree, an application accessing the module is “suspicious.” However, in some instances, a sensitive module may have legitimate reasons to load when used in certain non-malicious ways. The system may also consider a trust level when determining what actions to take, such that an application and/or user having a higher trust level may be less suspicious when accessing a sensitive module as compared to an application or user having a lower trust level.

Abstract: Examples of the present disclosure describe systems and methods for restricting access to application programming interfaces (APIs). For example, when a process calls an API, the API call may be intercepted by a security system for evaluation of its trustfulness before the API is allowed to run. Upon intercepting an API call, the process calling the API may be evaluated to determine if the process is known to the security system, such that known processes that are untrusted may be blocked from calling the API. Further, when the security system cannot identify the process calling the API, the security service may evaluate a call stack associated with the call operation to determine if attributes of the call operation are known to the security system. If the call operation is known to the security system as untrusted, the call operation may be blocked from calling the API.

Abstract: The present disclosure relates to systems and methods for identifying highly sensitive modules and taking a remediation or preventative action if such modules are accessed by malicious software. For example, the likelihood that a module is used for an exploit, and is thus sensitive, is categorized as high, medium, or low. The likelihood that a module can be used for an exploit can dictate whether, and to what degree, an application accessing the module is “suspicious.” However, in some instances, a sensitive module may have legitimate reasons to load when used in certain non-malicious ways. The system may also consider a trust level when determining what actions to take, such that an application and/or user having a higher trust level may be less suspicious when accessing a sensitive module as compared to an application or user having a lower trust level.

Abstract: Examples of the present disclosure describe systems and methods for executable memory protection. In an example, calls to a memory API may be monitored to identify protection attributes of the associated memory. If software requests access to memory that is both executable and writeable, different protection attributes may be used to limit the availability of memory that is both executable and writeable. Subsequently, if software attempts to access the memory in a way not permitted by the different protection attributes, a resulting memory exception may be evaluated to determine whether to modify the memory protection attributes. In examples, the memory protection attributes may be updated accordingly (e.g., to be made executable but not writeable, writeable but not executable, etc.) and execution of the set of software instructions may resume. Thus, memory that is both executable and writeable may be reduced or eliminated; decreasing the likelihood of exploitation by malicious software.

Abstract: Examples of the present disclosure describe systems and methods for exploit detection via induced exceptions. In an example, one or more inspection points are generated by a threat processor. For instance, an inspection point may be generated by altering aspects of one or more APIs, setting a process or hardware breakpoint, and/or modifying permissions of one or more memory pages, among other examples. The threat processor may register one or more exception handlers corresponding to the generated inspection points. As a result, when a set of software instructions encounters an inspection point and throws an exception, the threat processor may catch the exception and process a context record associated with software execution according to identify the presence of an exploit. Accordingly, inspection points ensure that the software execution state is preserved, such that the call stack, registers, and other context information is available for analysis by the threat processor.

Abstract: Examples of the present disclosure describe systems and methods for malicious software detection based on API trust. In an example, a set of software instructions executed by a computing device may call an API. A hook may be generated on the API, such that a threat processor may receive an indication when the API is called. Accordingly, the threat processor may generate a trust metric based on the execution of the set of software instructions, which may be used to determine whether the set of software instructions poses a potential threat. For example, one or more call stack frames may be evaluated to determine whether a return address is preceded by a call instruction, whether the return address is associated with a set of software instructions or memory associated with a set of software instructions, and/or whether the set of software instructions satisfies a variety of security criteria.

Abstract: Examples of the present disclosure describe systems and methods for executable memory protection. In an example, calls to a memory API may be monitored to identify protection attributes of the associated memory. If software requests access to memory that is both executable and writeable, different protection attributes may be used to limit the availability of memory that is both executable and writeable. Subsequently, if software attempts to access the memory in a way not permitted by the different protection attributes, a resulting memory exception may be evaluated to determine whether to modify the memory protection attributes. In examples, the memory protection attributes may be updated accordingly (e.g., to be made executable but not writeable, writeable but not executable, etc.) and execution of the set of software instructions may resume. Thus, memory that is both executable and writeable may be reduced or eliminated; decreasing the likelihood of exploitation by malicious software.

Abstract: Examples of the present disclosure describe systems and methods for restricting access to application programming interfaces (APIs). For example, when a process calls an API, the API call may be intercepted by a security system for evaluation of its trustfulness before the API is allowed to run. Upon intercepting an API call, the process calling the API may be evaluated to determine if the process is known to the security system, such that known processes that are untrusted may be blocked from calling the API. Further, when the security system cannot identify the process calling the API, the security service may evaluate a call stack associated with the call operation to determine if attributes of the call operation are known to the security system. If the call operation is known to the security system as untrusted, the call operation may be blocked from calling the API.