Ransomware mitigation system

Endpoints in a network environment include remote file systems mounted thereto that reference a file system generator that responds to file system commands with deception data. Requests to list the contents of a directory are intercepted, such as while a response is passed up through an IO stack. The response is modified to include references to deception files and directories that do not actually exist on the system hosting the file system generator. The number of the deception files and directories may be randomly selected. Requests to read deception files are answered by generating a file having a file type corresponding to the deception file. Deception files may be written back to the system by an attacker and then deleted.

BACKGROUND

Malware such as file infectors and ransomware attack network files residing on both local disks of endpoints and remote disks mounted on endpoints. This malware encrypts files and makes them unreadable. These types of attacks cause incredible damage and cost millions as companies choose to pay ransoms for their own data.

The systems and methods disclosed herein provide an improved approach for preventing ransomware attacks on endpoint systems.

DETAILED DESCRIPTION

Embodiments in accordance with the invention may be embodied as an apparatus, method, or computer program product. Accordingly, the invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “module” or “system.” Furthermore, the invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

Any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. In selected embodiments, a computer-readable medium may comprise any non-transitory medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

Computer program code for carrying out operations of the invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages, and may also use descriptive or markup languages such as HTML, XML, JSON, and the like. The program code may execute entirely on a computer system as a stand-alone software package, on a stand-alone hardware unit, partly on a remote computer spaced some distance from the computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Referring toFIG. 1, the methods disclosed herein may be practiced in a network environment100including a plurality of domains102a-102c. The domains102a-102cmay be any network division, such as a subnet, local area network (LAN), virtual local area network (VLAN), or the like. The domains102a-102cmay be distributed within a same building or over a large geographic area with interconnecting links including the Internet104. The illustrated domains102a-102cmay represent one or more network components, such as routers, switches, servers, and the like that implement routing of traffic within the domains102a-102cand control traffic flowing into and out of the domains102a-102c

Each domain may include one or more endpoints106a-106g. The endpoints106a-106gare production computing devices that operate as personal computers for users or servers providing production services to other endpoints or to external computers accessing the network environment by way of the internet104. The endpoints106a-106gmay be desktop or laptop computers, mobile phones, tablet computers, server computers, and any other type of computing device. Some endpoints106a-106gmay include internet-enabled devices, i.e. so-called internet of things (IoT) devices that are often a vulnerability.

The endpoints106a-106gare not dedicated honeypots, but rather perform non-decoy functions and process legitimate production data and legitimate production tasks of an enterprise, such as functioning as user computers executing applications such as word processors, browsers, graphics programs etc. The endpoints106a-106gmay also function as web servers, database servers, remote login servers, application servers, and the like.

Some or all of the endpoints106a-106gmay host an operating system implementing a local file system108. The file system108defines and provides an interface to a file system including local disk directory110astored on a local disk112hosted by the same endpoint106a-106g. The file system108may also provide an interface to access remote volume directory110bstored in a remote disk114hosted by a different endpoint106a-106g. In the illustrated embodiment, endpoint106fis a file server hosting remote disk114and the endpoint106amounts that remote disk114as part of its file system108such that some or all of the remote disk114may be accessed through the file system108of endpoint106a.

The local file system108may also mount a remote deception directory110cthat refers to a file system generator116implemented by a BotSink118. The file system generator116generates responses to file system commands and queries that simulate a directory populated with files and directories without actually storing the simulated directory. The operation of the file system generator116is described below with respect toFIGS. 2 through 5.

The remote deception directory110cmay include a plurality of directories mounted within the local file system108in various directories and sub-directories. The remote deception directories110cmay be mounted manually or the endpoints106a-106gmay execute a local application that coordinates with the file system generator116to mount the remote deception directors110cthroughout the local file system108.

In some embodiments, the remote deception directories110care hidden such that they will not appear in a file system browser. For example, WINDOWS provides for the marking of files to be non-browsable using explorer. Accordingly, this function may be invoked for the deception directories110c. The remote deception directories110cmay remain visible in response to queries received from a command line, as remote procedure calls (RPCs), or as file system commands from an application programming interface (API). Remote deception directories may be mounted at locations of a file system that are not accessed by users, such as temporary directories, system directories, or other obscure and non-user-oriented directories.

The BotSink120may further implement any of the method methods for detecting and engaging malicious code disclosed in the following applications (herein after “the incorporated applications”), which are hereby incorporated herein by reference in their entirety:

U.S. application Ser. No. 14/549,112, filed Nov. 20, 2014, and entitled METHOD FOR DIRECTING MALICIOUS ACTIVITY TO A MONITORING SYSTEM;

An attacker system120may infiltrate an endpoint106a-106gand attempt to infect some or all of the directories110a-110c. In a typical attack, files are encrypted and written back to the file system108. The attacker than attempts to extort a ransom in order to decrypt them.

Referring toFIG. 2, an operating system200of an endpoint106a-106gmay receive file system commands from legitimate applications202executing on the endpoint106a-106gas well as from an attacker tool204that has infiltrated the endpoint106a-106gor is remotely accessing the endpoint106a-106g.

File system commands may include commands to read a file, write to a file, delete a file, create a directory, delete a directory, move a file from one directory to a different directory, or list contents of a directory. The files and directories referenced by a file system command may be stored in the local disk112, a remote disk114, or a deception directory referencing the BotSink118.

As discussed in greater detail below, upon receiving a file system command, the BotSink118may process the file system commands within an operating system206that may execute in the context of one of a plurality of virtual machines executed by the BotSink118. File system commands may be received in an input/output (IO) stack of the operating system206including one or more layers208a-208c. The file system stack may execute file system commands with respect to a local disk210hosted by the BotSink118. The file system generator116may intercept commands and/or responses to commands at some point in the stack.

For example, in a WINDOWS operating system, commands from a user application are received by an IO manager, which passes the command to a mini filter driver, which then passes the command to a file system driver. In one embodiment, where the file system command is a request to view contents of a directory, a response from the file system driver may be intercepted by the file system generator116and then populated with references to deception directories and files that do not actually exist.

For example, where the operating system is LINUX-based, the I/O stack may include, starting immediately below an application, a system call interface, VFS (virtual file system) layer, extended file system layer (ext4), LVM (logical volume layer), block device interface, and device drivers. Accordingly, the file system generator116may intercept commands passing down through the stack and responses passing up through the stack at any of these layers and modify the command or response as outlined herein to reference deception files and/or directories. Other operating systems may include a similar stack and may similarly be integrated with the file system generator116to intercept and modify commands and responses passing through the stack.

Referring toFIG. 3, the illustrated method300may be executed by the BotSink118, particularly the file system generator116. The method300may include receiving302a list command by the operating system206.

The list command may be received302from an endpoint106a-106goperating system200receiving the FindFirstFile function, where the operating system206is a WINDOWS operating system. This results in a system call to the operating system200. When this system call reaches the kernel mode of the operating system206of the BotSink118, the IO manager may generate an IRP (IO request packet), specifically IRP_MJ_DIRECTORY_CONTROL, and provides the IRP to the file system to execute.

The IO stack then receives304and executed the IRP. In WINDOWS, the mini filter driver may fulfill the IRP, but in most cases it is transmitted to a lower layer in the IO stack for processing, e.g., the file system driver. The file system driver may retrieve306a list of files referenced by the directory referenced in the IRP and passes308the list back up through the IO stack, i.e. to the mini filter driver and IO manager.

The file system generator116intercepts310the list as it is passed up through the IO stack. For example, the file system generator116may intercept the list output by the file system driver before it is passed to the mini filter driver. In some embodiments, the BotSink may modify the mini filter driver such that it is operable to perform the interception of commands and responses to commands as well as perform conventional functions of a mini filter driver.

The file system generator116then replaces any files or directories in the list with references to deception files and directories that do not exist on the directory that was queried. The number of files and the number of directories may be selected according to one or more random numbers, such as output from a pseudo random number generator or some other means. Likewise, the names of the files and directories may be random strings or may be selected from a database of file names and a database of directory names. The selection from the databases may be random. The names of files added to the list may include file types (.doc, .pdf, .xls, .ppt, etc.), which may also be randomly selected for a given file name or may be part of the file name in the database.

In some instances, the list command may include a filter criteria such as *.docx, which requests only MICROSOFT WORD documents, or *.pdf, which requests only PDF (portable document format) files. Accordingly, in this case, the references to deception files may be selected or generated to all include the .pdf file extension.

The modified list is returned312to the operating system, such as to the mini filter driver or whichever layer of the IO stack above the layer from which the list was intercepted. This layer above then processes the modified list in the conventional manner. In the case of WINDOWS, the mini filter driver passes the modified list to the IO manager, which then returns the modified list to a source of the IRP. The modified list is then returned by the operating system206to the operating system200of the endpoint106a-106gthat invoked performance of the method300with the list command received at step302.

Note that the method300described intercepting a response to a list command as it is being passed up through the IO stack. In other embodiments, a list command may be intercepted310as it is being passed down through the IO stack and a list including deception data may then be passed up through the IO stack, thereby bypassing any lower layers of the IO stack.

Referring toFIG. 4, the illustrated method400may be executed by the BotSink118, particularly the file system generator116, in response to a file system command referencing a directory name that has previously been returned, such as according to the method300. In some instances, lists of files and directories returned at step312of the method300may be temporarily stored by the file system generator116. In this manner, file system commands referencing the names of directories that have been previously returned may be detected and processed according to the method400. In other embodiments, any request to list the contents of directory will be processed according to the method300regardless of whether the directory has previously been returned in response to a list command.

The method400may include receiving402a list request for a deception directory, i.e. a directory referenced during a previous iteration of the method400or the method300. The request may be intercepted404while passing through the IO stack, i.e. while the list request is being passed down through the IO stack or a response to the list request is being passed up through the IO stack. In some cases, since the directory included in the list request matches a previously-stored deception directory name, the list request may be intercepted404prior to passing to the IO stack and determined to be a request for a deception directory in response to detecting the match.

In either case, the response to the list command will be populated with references to a collection of deception directories and files and returned406to the endpoint that generated the list request. The deception directories and files may be generated in the same manner as for step312of the method300. In some embodiments, the references to a collection of deception directories and files may be compared to previously returned references and only those references that they are not repetitive will be returned. Step312and step406preferably always include a reference to at least one deception directory. In this manner, the probing of a directory structure will never end and an attacker tool204will be distracted from infecting production files.

In some embodiments, the method400may further include deleting ancestor deception data. This data may include previously stored listings of deception files and directories, e.g. for an ancestor of the deception directory that is the subject of the method400. In this manner, the BotSink118does not run out of storage despite providing an apparently infinite file system to the attacker tool204.

As described below with respect toFIG. 5, deception files may also be returned to the attacker tool204. These deception files may be written back to the BotSink118by the attacker tool204in encrypted form. These encrypted files may then be deleted at step408, e.g. those encrypted files in ancestor directories of the directory that is the subject of the method400. In this manner, the encrypted files do not accumulate and deplete available storage of the BotSink118.

Referring toFIG. 5, the illustrated method500may be executed in response to a file system command. In particular, a command to read a deception file will be a commonly executed command by ransomware.

The method500may include receiving502a read request including a reference to a deception file returned in a previous iteration of the method300or method400. As for the method300, previously-returned listings may be stored in order to detect when a file command is received that includes a previously-returned reference to a deception file.

The method500may include intercepting504the read request either while being passed down through the IO stack, while a response to the read request is being passed up through the IO stack, or prior to passing the read request to the IO stack. For example, upon receiving a read request from an endpoint106a-106g, the BotSink118may compare the file reference in the read request and compare it to previously-returned references to deception files. If there is a match, then the read request may be processed according to steps506-510. If not, then the read request may be passed to the IO stack and processed in the conventional manner.

The method500may include processing the intercepted read request by generating506a deception file corresponding to the reference included in the read request. For example, if the file reference in the read request refers to a MICROSOFT WORD document (.doc), then the deception file may have a format corresponding to a MICROSOFT WORD document. Likewise, other file types may be simulated such as .pdf, .rtf, .xls, or the like. The simulated file may be generated from a template corresponding to the file type, which is then populated with random data (text, numbers, etc.) corresponding to the file type.

The file type corresponding to the file referenced in the read request may be included in the read request or may be determined by reviewing the list of previously-returned references to deception files, which may also store the file type corresponding to each reference.

The method500may further include generating508deception metadata to include with the deception file, this metadata may include a data created, date modified, date last opened, author, or any other metadata describing the creation and revision of the deception file. The deception metadata may be chosen according to randomly generated numbers such that the dates of creation modification, opening, and/or the dates of any revisions are different from a date of creation of the deception file. In this manner, files appear to be organically generated production files rather than deception files.

The deception file and metadata as generated at steps506and508may then be returned510to the endpoint106a-106gfrom which the read request was received.

The typical operation of ransomware is to then encrypt the file and write it back to its original location. Accordingly, the method500may be followed by a write request including an encrypted version of the deception file returned during the method500. This write request may be determined to include a reference to a deception file based on comparison to a list of previously-returned references. In response to this determination, the write request may be ignored and a simulated acknowledgment that the write request has completed may be returned to the endpoint106a-106gthat generated the write request.

In other embodiments, write requests may be executed in a conventional manner, which would include transmitting an acknowledgment. Inasmuch as the directory in which the deception file is made to appear to be in does not exist, if the write request is executed it may be performed in an actual directory stored in the local disk210of the BotSink118. For example, deception directories may be created as, or processed as, aliases for an actual directory such that all write requests to a deception directory will be written to the actual directory. Data written to this actual directory may then be deleted periodically in order to avoid running out of storage space.

FIG. 6is a block diagram illustrating an example computing device600which can be used to implement the system and methods disclosed herein. The endpoints106a-106g, BotSink118, and attacker system120may also have some or all of the attributes of the computing device600. In some embodiments, a cluster of computing devices interconnected by a network may be used to implement any one or more components of the invention.

Computing device600may be used to perform various procedures, such as those discussed herein. Computing device600can function as a server, a client, or any other computing entity. Computing device can perform various monitoring functions as discussed herein, and can execute one or more application programs, such as the application programs described herein. Computing device600can be any of a wide variety of computing devices, such as a desktop computer, a notebook computer, a server computer, a handheld computer, tablet computer and the like.

Computing device600includes one or more processor(s)602, one or more memory device(s)604, one or more interface(s)606, one or more mass storage device(s)608, one or more Input/Output (110) device(s)610, and a display device630all of which are coupled to a bus612. Processor(s)602include one or more processors or controllers that execute instructions stored in memory device(s)604and/or mass storage device(s)608. Processor(s)602may also include various types of computer-readable media, such as cache memory.

Memory device(s)604include various computer-readable media, such as volatile memory (e.g., random access memory (RAM)614) and/or nonvolatile memory (e.g., read-only memory (ROM)616). Memory device(s)604may also include rewritable ROM, such as Flash memory.

Mass storage device(s)608include various computer readable media, such as magnetic tapes, magnetic disks, optical disks, solid-state memory (e.g., Flash memory), and so forth. As shown inFIG. 6, a particular mass storage device is a hard disk drive624. Various drives may also be included in mass storage device(s)608to enable reading from and/or writing to the various computer readable media. Mass storage device(s)608include removable media626and/or non-removable media.

I/O device(s)610include various devices that allow data and/or other information to be input to or retrieved from computing device600. Example I/O device(s)610include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image capture devices, and the like.

Display device630includes any type of device capable of displaying information to one or more users of computing device600. Examples of display device630include a monitor, display terminal, video projection device, and the like.

Interface(s)606include various interfaces that allow computing device600to interact with other systems, devices, or computing environments. Example interface(s)606include any number of different network interfaces620, such as interfaces to local area networks (LANs), wide area networks (WANs), wireless networks, and the Internet. Other interface(s) include user interface618and peripheral device interface622. The interface(s)606may also include one or more user interface elements618. The interface(s)606may also include one or more peripheral interfaces such as interfaces for printers, pointing devices (mice, track pad, etc.), keyboards, and the like.

Bus612allows processor(s)602, memory device(s)604, interface(s)606, mass storage device(s)608, and I/O device(s)610to communicate with one another, as well as other devices or components coupled to bus612. Bus612represents one or more of several types of bus structures, such as a system bus, PCI bus, IEEE 1394 bus, USB bus, and so forth.