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 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: Examples of the present disclosure describe systems and methods for sharing memory using a multi-ring shared, traversable and dynamic database. In aspects, the database may be synchronized and shared between multiple processes and/or operation mode protection rings of a system. The database may also be persisted to enable the management of information between hardware reboots and application sessions. The information stored in the database may be view independent, traversable, and resizable from various component views of the database. In some aspects, an event processor is additionally described. The event processor may use the database to allocate memory chunks of a shared heap to components/processes in one or more protection modes of the operating system.

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 sharing memory using a multi-ring shared, traversable and dynamic database. In aspects, the database may be synchronized and shared between multiple processes and/or operation mode protection rings of a system. The database may also be persisted to enable the management of information between hardware reboots and application sessions. The information stored in the database may be view independent, traversable, and resizable from various component views of the database. In some aspects, an event processor is additionally described. The event processor may use the database to allocate memory chunks of a shared heap to components/processes in one or more protection modes of the operating system.

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 sharing memory using a multi-ring shared, traversable and dynamic database. In aspects, the database may be synchronized and shared between multiple processes and/or operation mode protection rings of a system. The database may also be persisted to enable the management of information between hardware reboots and application sessions. The information stored in the database may be view independent, traversable, and resizable from various component views of the database. In some aspects, an event processor is additionally described. The event processor may use the database to allocate memory chunks of a shared heap to components/processes in one or more protection modes of the operating system.

Abstract: Examples of the present disclosure describe systems and methods for sharing memory using a multi-ring shared, traversable and dynamic database. In aspects, the database may be synchronized and shared between multiple processes and/or operation mode protection rings of a system. The database may also be persisted to enable the management of information between hardware reboots and application sessions. The information stored in the database may be view independent, traversable, and resizable from various component views of the database. In some aspects, an event processor is additionally described. The event processor may use the database to allocate memory chunks of a shared heap to components/processes in one or more protection modes of the operating system.

Abstract: Examples of the present disclosure describe systems and methods for sharing memory using a multi-ring shared, traversable and dynamic database. In aspects, the database may be synchronized and shared between multiple processes and/or operation mode protection rings of a system. The database may also be persisted to enable the management of information between hardware reboots and application sessions. The information stored in the database may be view independent, traversable, and resizable from various component views of the database. In some aspects, an event processor is additionally described. The event processor may use the database to allocate memory chunks of a shared heap to components/processes in one or more protection modes of the operating system.

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: 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 sharing memory using a multi-ring shared, traversable and dynamic database. In aspects, the database may be synchronized and shared between multiple processes and/or operation mode protection rings of a system. The database may also be persisted to enable the management of information between hardware reboots and application sessions. The information stored in the database may be view independent, traversable, and resizable from various component views of the database. In some aspects, an event processor is additionally described. The event processor may use the database to allocate memory chunks of a shared heap to components/processes in one or more protection modes of the operating system.