Crowdstrike, Inc.

Mandiant Corporation

Aaron LeMasters

Ion-Alexandru Ionescu

Cameron Gutman

Timo Kreuzer

A bus filter driver and security agent components configured to retrieve and analyze firmware images are described herein. The bus filter driver may attach to a bus device associated with a memory component and retrieve a firmware image of firmware stored on the memory component. The bus filter driver may also retrieve hardware metadata. A kernel-mode component of the security agent may then retrieve the firmware image and hardware metadata from the bus filter driver and provide the firmware image and hardware metadata to a user-mode component of the security agent for security analysis. The security agent components may then provide results of the analysis and/or the firmware image and hardware metadata to a remote security service to determine a security status for the firmware.

Firmware retrieval and analysis

A plug-and-play (PnP) driver associated with a security agent is described herein. The PnP driver attaches to device stacks of enumerated bus devices of a computing device as upper-device or lower-device filters based on the device classes of the enumerated bus devices. For example, the PnP driver may attach to the device stack of a hub or controller device as an upper-device filter and to device stacks of other devices as lower-device filters. Either while attaching or after attachment, the PnP driver may take action to alter, limit, or otherwise block functionality of an enumerated bus device. The PnP driver may also perform a system inventory of enumerated bus devices connected to the computing device and create fingerprints for one or more of the computing devices. Additionally, the PnP driver may create and remove control device objects (CDOs) to enable communication with user-mode processes or threads.

Security component for devices on an enumerated bus

Drivers in different functional paths can use different types of identifiers for the same hardware device, such that the drivers may not be able to natively coordinate their actions related to the hardware device due to incompatible identifier types. However, a driver at a file system layer of one functional path can obtain a volume Physical Device Object (PDO) identifier at a volume layer and find a disk PDO identifier at a disk layer that is associated with the same device number. The driver can also find a parent device instance identifier from the disk PDO identifier, and use the parent device instance identifier as a plug-and-play (PnP) identifier for the hardware device during communications with a second driver in a PnP functional path.

Identifying and correlating physical devices across disconnected device stacks

Some example computing systems herein include two modules, e.g., drivers. A first can instantiate an interface associated with a service routine, receive, by the service routine, a verification message; and send, in response, a confirmation message via the interface. A second can locate the interface; open a handle to the interface; send the verification message via the handle, the verification message identifying at least an interface type or a version; and receive, via the handle, the confirmation message associated with the verification message. In some examples, the first driver is a Plug and Play driver. In some examples, the first module can receive, by the service routine, a command associated with the interface; determine that the command is a valid command based at least in part on stored command data; and send, via the interface, a response to the command.

Verified inter-module communications interface

In some examples, a processing unit can install a second driver to an installed-driver backing store on a non-volatile (nonV) memory, and replace a first driver in a driver store of the nonV memory with the second driver without replacing the first driver in the volatile memory with the second driver. The processing unit can, subsequently, determine that the second driver has been loaded into the volatile memory, and write, by the second driver loaded into the volatile memory, a driver-configuration entry in a configuration datastore. An example computing system can include the first driver in volatile memory, and the nonV memory. The nonV memory can include a driver-configuration file, a driver store holding a first copy of the second driver, and an installed-driver backing store holding a second copy of the second driver. Some examples can roll back failed installation operations.

Device driver non-volatile backing-store installation

A security agent implemented on a monitored computing device is described herein. The security agent is configured to receive one or more event notifications respectively associated with one or more kernel-mode events. Based on the one or more event notifications, the security agent determines that the one or more kernel-mode events are associated with user-mode processing of a request message by a RPC-utilizing process of the monitored computing device. The security agent then retrieves the request message based on information included in one or more RPC data structures and based on the one or more event notifications and identifies an originator of the request message based on metadata of the request message.

Tracing system operations across remote procedure linkages to identify request originators

A method to circumvent malicious software via a system configured to bypass a device driver stack and, consequently, also bypass the malicious software that may be adversely affecting the device driver stack by using an alternative stack such as a crash dump I/O stack. The crash dump I/O stack is poorly documented relative to the device driver stack and functions independently from the device driver stack.

Growing community of inventors

New York, NY, United States of America

Aaron LeMasters