Detecting malware by linking background intelligent transfer service (BITS) and scheduled task service (STS) activities to a source program

Detecting malware by linking Background Intelligent Transfer Service (BITS) and Scheduled Task Service (STS) activities to a source program. Using send Advanced Local Procedure Call (ALPC) messages and receive ALPC messages, source programs that initiate the creation of temporary files and perform defined operations may be identified. If the source programs responsible for the temporary files and defined operations are determined to be malware programs, a security action may be performed on the source programs.

BACKGROUND

The presence of malware on computers and other electronic devices can be difficult to detect. Malware programs abuse downloaders and task schedulers to avoid detection from antivirus programs or malware analysts. Even when malware has been detected on a computer, operating systems such as Windows™ do not offer reliable methods of identifying the program causing the malware to be downloaded or otherwise obtained from the Internet (i.e., the “source program”). It is thus very difficult to link the source program to its downstream effects (e.g., malware files downloaded or scheduled to be executed on a computer).

As a consequence, malware analysts and other programs attempt to look for specific downloader or task scheduler malware activity by searching for traces of malware activity recorded data and logs on an already infected system. These actions are not performed in real-time. This renders it essentially impossible to prevent or remediate an attack in real-time. Moreover, well-crafted malware can infect a computer without leaving any trace for a later analysis, thus precluding identification of the associated source program.

SUMMARY

In one embodiment, a computer-implemented method for detecting malware by linking transfer service activities to source programs may be performed, at least in part by a computing device comprising one or more processors, a memory, and an operating system stored within the memory. The method may include buffering, in a detection buffer within the memory, a plurality of send Advanced Local Procedure Call (ALPC) messages and a plurality of receive ALPC messages created by the operating system when a Background Intelligent Transfer Service (BITS) of the operating system is used to download one or more files to the computing device from a network. The method may also include identifying a first send ALPC message within the plurality of send ALPC messages and a first receive ALPC message within the plurality of receive ALPC messages, wherein the first send ALPC message and the first receive ALPC message have a first common message ID. The method may also include pairing the first send ALPC message and the first receive ALPC message to create a first ALPC message pair, wherein the first ALPC message pair includes: a first timestamp field having a value corresponding to a time of creation of at least one of the first send ALPC message and the first receive ALPC message, a first ALPC source process ID corresponding to a send process ID of the first send ALPC message, a first ALPC source thread ID corresponding to a send thread ID of the first send ALPC message, a first ALPC destination process ID corresponding to a receive process ID of the first receive ALPC message, and a first ALPC destination thread ID corresponding to a receive thread ID of the first receive ALPC message. The method may also include receiving a notification that a temporary file has been created by the BITS, the temporary file being created as part of a file download initiated by the source program. The method may also include determining that (1) the value in the first timestamp field corresponds to a time of creation of the temporary file, and (2) the first ALPC destination process ID corresponds to a process ID of the temporary file, and (3) the first ALPC destination thread ID corresponds to a thread ID of the temporary file. The method may also include evaluating the first ALPC source process ID to identify the source program responsible for initiating the creation of the temporary file. The method may also include determining, based at least in part on the temporary file, that the source program is a malware program. The method may also include performing a security action on the source program.

In some embodiments, the method may further include receiving a notification that the BITS has renamed the temporary file using a new file name and assigning the new file name to the source program.

In some embodiments, the method may further include identifying a second send ALPC message within the plurality of send ALPC messages and a second receive ALPC message within the plurality of receive ALPC messages, wherein the second send ALPC message and the second receive ALPC message have a second common message ID. In these embodiments, the method may also include pairing the second send ALPC message and the second receive ALPC message to create a second ALPC message pair, wherein the second ALPC message pair includes: a second timestamp field having a value corresponding to a time of creation of at least one of the second send ALPC message and the second receive ALPC message, a second ALPC source process ID corresponding to a send process ID of the second send ALPC message, a second ALPC source thread ID corresponding to a send thread ID of the second send ALPC message, a second ALPC destination process ID corresponding to a receive process ID of the second receive ALPC message, and a second ALPC destination thread ID corresponding to a receive thread ID of the second receive ALPC message. In these embodiments, the method may also include receiving a notification that a temporary file has been created by the BITS, the temporary file being created as part of a file download initiated by the source program. In this embodiment, the method may also include determining that (1) the value in the second timestamp field does not correspond to a time of creation of the temporary file, or (2) the second ALPC destination process ID does not correspond to a process ID of the temporary file, or (3) the second ALPC destination thread ID does not correspond to a thread ID of the temporary file. In these embodiments, the method may also include discarding the second ALPC message pair.

In some embodiments, the source program may be determined to be a malware program by evaluating the temporary file and determining that the temporary file is a malware file. In some embodiments, the security action may be quarantining the source program. In some embodiments, the security action may be deleting the source program.

In another embodiment, a computer-implemented method for detecting malware by linking scheduled task activities to source programs may be performed, at least in part by a computing device comprising one or more processors, a memory, and an operating system stored within the memory. The method may include buffering, in a detection buffer within the memory, a plurality of send Advanced Local Procedure Call (ALPC) messages and a plurality of receive ALPC messages created by the operating system when a Scheduled Task Service (STS) of the operating system is used to schedule a task to be performed by the operating system. The method may also include identifying a first send ALPC message within the plurality of send ALPC messages and a first receive ALPC message within the plurality of receive ALPC messages, wherein the first send ALPC message and the first receive ALPC message have a first common message ID. The method may also include pairing the first send ALPC message and the first receive ALPC message to create a first ALPC message pair, wherein the first ALPC message pair includes: a first timestamp field having a value corresponding to a time of creation of at least one of the first send ALPC message and the first receive ALPC message, a first ALPC source process ID corresponding to a send process ID of the first send ALPC message, a first ALPC source thread ID corresponding to a send thread ID of the first send ALPC message, a first ALPC destination process ID corresponding to a receive process ID of the first receive ALPC message, and a first ALPC destination thread ID corresponding to a receive thread ID of the first receive ALPC message. The method may also include receiving a notification that the STS has performed a defined operation, the STS performing the defined operation while being used by the source process. The method may also include determining that (1) the value in the first timestamp field corresponds to a time period when the defined operation was performed, and (2) the first ALPC destination process ID corresponds to a process ID of the STS involved in performing the defined operation, and (3) the first ALPC destination thread ID corresponds to a thread ID of the STS involved in performing the defined operation. The method may also include evaluating the first ALPC source process ID to identify the source program responsible for performing the defined operation. The method may also include determining, based at least in part on the defined operation, that the source program is a malware program. The method may also include performing a security action on the source program.

In some embodiments, the defined operation may correspond to creation of a file in a defined path. In these embodiments, the method may further include parsing the file in order to determine one or more tasks created by the source program. In these embodiments, the method may alternatively include parsing the file to determine one or more commands, which will execute the one or more tasks created by the source program.

In some embodiments, the defined operation may correspond to creation of new entry in a defined registry path.

In some embodiments, the method may further include identifying a second send ALPC message within the plurality of send ALPC messages and a second receive ALPC message within the plurality of receive ALPC messages, wherein the second send ALPC message and the second receive ALPC message have a second common message ID. In these embodiments, the method may also include pairing the second send ALPC message and the second receive ALPC message to create a second ALPC message pair, wherein the second ALPC message pair includes: a second timestamp field having a value corresponding to a time of creation of at least one of the second send ALPC message and the second receive ALPC message, a second ALPC source process ID corresponding to a send process ID of the second send ALPC message, a second ALPC source thread ID corresponding to a send thread ID of the second send ALPC message, a second ALPC destination process ID corresponding to a receive process ID of the second receive ALPC message, and a second ALPC destination thread ID corresponding to a receive thread ID of the second receive ALPC message. In these embodiments, the method may also include receiving a notification that the STS has performed a defined operation, the STS performing the defined operation while being used by the source process. In these embodiments, the method may also include determining that (1) the value in the second timestamp field does not correspond to a time period when the defined operation was performed, or (2) the second ALPC destination process ID does not correspond to a process ID of the STS involved in performing the defined operation, or (3) the second ALPC destination thread ID does not correspond to a thread ID of the STS involved in performing the defined operation. In these embodiments, the method may also include discarding the second ALPC message pair.

In some embodiments, the source program is determined to be a malware program by evaluating the defined operation and determining that the defined operation is a malware operation. In some embodiments, the security action is quarantining or deleting the source program.

It is to be understood that both the foregoing summary and the following detailed description are explanatory and are not restrictive of the invention as claimed.

DETAILED DESCRIPTION

Disclosed herein are systems and methods for detecting malware by linking BITS or STS activities to a source program. The disclosed systems and methods leverage existing Application Programming Interfaces (APIs) in a novel manner to enable real time matching to a source program of files downloaded by a transfer service or tasks scheduled for execution by a task service. This enables “linking” the downloaded/scheduled files to malware source programs despite the loose connection between them. The method may scrutinize all activity occurring on a monitored computer or only that activity not already known to be legitimate, i.e., untrusted activity. Because such activity will typically be reported in in real time, an antivirus program can responsively remediate or prevent the system from becoming infected.

In one embodiment the method is implemented on computers configured with a Windows™ operating system. In this case the system leverages the download and scheduling services native to Windows™; that is the Background Intelligent Transfer Service (BITS) for downloading/running files from any uniform resource identifier URI path and the Scheduled Task Service (STS) for running processes. In order to investigate the effect of a program's activity on the BITS/STS, multiple tools and techniques are utilized. For example, Windows™ provides several tools to monitor the activities associated with a process. For example, Process Monitor may be used track process activities such as File Creation/Rename, and Microsoft™ Message Analyzer (MMA) may be used to track Event Tracing for Windows™ messages, which are related to various Advanced Local Procedure Call (ALPC) message types (e.g., ALPC_Receive_Message and ALPC_Send_Message). The use of tools such as these in the manner described herein enables identification of the source process responsible for the downloading of particular files by BITS and/or the scheduling of tasks by the STS.

Thus, the disclosed method implements an efficient tracking method that matches the files created by BITS, or tasks scheduled by STS, to the real source process by analyzing associated data in real time. This provides the linkage needed for malware detection.

For example, in one embodiment, a computer-implemented method for detecting malware by linking transfer service activities to source programs is disclosed. This computer-implemented may include buffering, in a detection buffer within a memory of the computing device, a plurality of send ALPC messages and a plurality of receive ALPC messages created by the operating system when a BITS of the operating system is used to download one or more files to the computing device from a network. This method may also include identifying a send ALPC message within the plurality of send ALPC messages and a receive ALPC message within the plurality of receive ALPC messages that have common message IDs. The send ALPC message may be paired with the receive ALPC message to create a ALPC message pair. This ALPC message pair may include: a timestamp field having a value corresponding to a time of creation of at least one of the send ALPC message and the receive ALPC message, an ALPC source process ID corresponding to a send process ID of the send ALPC message, an ALPC source thread ID corresponding to a send thread ID of the send ALPC message, an ALPC destination process ID corresponding to a receive process ID of the receive ALPC message, and an ALPC destination thread ID corresponding to a receive thread ID of the receive ALPC message. A notification may be received that a temporary file has been created by the BITS as part of a file download initiated by the source program. A determination may be made that (1) the value in the timestamp field corresponds to a time of creation of the temporary file, and (2) the ALPC destination process ID corresponds to a process ID of the temporary file, and (3) the ALPC destination thread ID corresponds to a thread ID of the temporary file. The ALPC source process ID may then be evaluated to identify the source program responsible for initiating the creation of the temporary file and a determination may be made that the source program is a malware program. Finally, a security action may be performed on the source program.

In another embodiment, a computer-implemented method for detecting malware by linking scheduled task activities to source programs is disclosed. This computer-implemented may include buffering, in a detection buffer within a memory of the computing device, a plurality of send ALPC messages and a plurality of receive ALPC messages created by the operating system when an STS of the operating system is used to schedule a task to be performed by the operating system. This method may also include identifying a send ALPC message within the plurality of send ALPC messages and a receive ALPC message within the plurality of receive ALPC messages that have common message IDs. The send ALPC message may be paired with the receive ALPC message to create a ALPC message pair. This ALPC message pair may include: a timestamp field having a value corresponding to a time of creation of at least one of the send ALPC message and the receive ALPC message, an ALPC source process ID corresponding to a send process ID of the send ALPC message, an ALPC source thread ID corresponding to a send thread ID of the send ALPC message, an ALPC destination process ID corresponding to a receive process ID of the receive ALPC message, and an ALPC destination thread ID corresponding to a receive thread ID of the receive ALPC message. A notification may be received that the STS has performed a defined operation while being used by the source process. A determination may be made that (1) the value in the timestamp field corresponds to a time period when the defined operation was performed, and (2) the ALPC destination process ID corresponds to a process ID of the STS involved in performing the defined operation, and (3) the ALPC destination thread ID corresponds to a thread ID of the STS involved in performing the defined operation. The ALPC source process ID may then be evaluated to identify the source program responsible for performing the defined operation and a determination may be made that the source program is a malware program. Finally, a security action may be performed on the source program.

Attention is now directed toFIG.1, which is an example computer system that may be employed in detecting malware by linking BITS or STS activities to a source program. In some embodiments, the computer system100may be, for example, a desktop computer, a client computer, a server computer, a mobile phone, a laptop computer, a smartphone, a smartwatch, a tablet computer, a portable music player, a networking device, or any other computer system. Computer system100may be capable of communicating over a network. As shown, computer system100includes a multicore central processing unit (“CPU”)102having a plurality of cores104a-104n, system memory114, disk storage120, data port(s)122, graphics processing unit (GPU)124, audio card126, and network card(s)128connected by system bus130.

The CPU102may include any suitable special-purpose or general-purpose computer, computing entity, or processing device including various computer hardware or software applications and may be configured to execute instructions stored on any applicable computer-readable storage media. For example, the CPU102may include a microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a Field-Programmable Gate Array (FPGA), or any other digital or analog circuitry configured to interpret and/or to execute program instructions and/or to process data, or any combination thereof. In some embodiments, the CPU102may interpret and/or execute program instructions and/or process data stored in the memory114and/or a file system. In some embodiments, the CPU102may fetch program instructions from a file system and load the program instructions into the memory114. After the program instructions are loaded into the memory114, the CPU102may execute the program instructions. In some embodiments, the instructions may include the CPU102performing one or more of the actions of the methods disclosed herein.

System bus130may include a memory bus or memory controller, a peripheral bus, and a local bus, and may utilize any of a various known bus architectures. Network card(s)128may provide an Ethernet, Wi-Fi, GSM, Bluetooth or other wired, wireless, or cellular network interface for connecting computer system100to a network. The network may include any wired or wireless network, or combination of multiple networks, configured to send and receive communications between systems and devices. In some embodiments, the network may include a Personal Area Network (PAN), a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Storage Area Network (SAN), a cellular network, the Internet, or some combination thereof.

Data port122may be any data port as is known in the art for interfacing with an external accessory using a data protocol such as RS-232, USB, or Firewire. Disk storage120may be a conventional read/write memory such as a magnetic disk drive, floppy disk drive, compact-disk read-only-memory (CD-ROM) drive, digital video disk (DVD) read or write drive, transistor-based memory or other computer-readable memory device as is known in the art for storing and retrieving data.

The system memory114may include computer-readable storage media for carrying or having stored thereon computer-executable instructions or data structures. Such computer-readable storage media may be any available non-transitory media that may be accessed by a general-purpose or special-purpose computer, such as the CPU102. By way of example, and not limitation, such computer-readable storage media may include non-transitory computer-readable storage media including Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage media which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and which may be accessed by a general-purpose or special-purpose computer. Combinations of the above may also be included within the scope of computer-readable storage media. Computer-executable instructions may include, for example, instructions and data configured to cause the CPU102to perform a certain operation or group of operations, such as one or more of the actions of the methods disclosed herein. These computer-executable instructions may be included, for example, in the operating system148, in one or more applications, or in some combination thereof.

In one embodiment, system memory114may include a read-only memory (ROM)140and random access memory (RAM)142. The ROM140generally stores a basic input/output system (BIOS), which contains foundational routines to convey information between components of computer system100. RAM142stores an operating system148(OS), such as, for example, Windows™, Linux™ or another type of OS. In the case of Windows™, the operating system148includes a Background Intelligent Transfer Service (BITS)150, a Scheduled Task Service (STS)154, and various APIs155. Various source programs156(each referred to herein as a “Source Program”) operative to utilize, via the APIs155, the BITS150, and/or the STS154may also be stored in RAM142.

System memory114also stores a specially configured antivirus application or monitor program158disposed to link Source Programs to files downloaded by BITS150or tasks scheduled by the STS154. The antivirus application or monitor program158includes a BITS/STS detection buffer160, a source process identification module161and a malware detection module162. The antivirus application or monitor program158may be one or more computer-readable instructions stored on one or more non-transitory computer-readable media, such as the memory114or the disk storage120, that, when executed by the CPU102, is configured to perform one or more of the actions of the methods disclosed herein. In some embodiments, the antivirus application or monitor program158may be part of the operating system148or may be part of an application of the computer system100, or may be some combination thereof.

CPU102communicates with a plurality of peripheral equipment. Additional peripheral equipment may include a display163, manual input device164and microphone166. Display163may be a visual display such as a liquid crystal display (LCD) screen, touch-sensitive screen, or other monitors as are known in the art for visually displaying images and text to a user. Manual input device164may be a conventional keyboard, keypad, mouse, trackball, or other input device as is known in the art for the manual input of data. Microphone166may be any suitable microphone as is known in the art for providing audio signals to CPU102. In addition, a speaker170may be attached for reproducing audio signals from CPU102. It is understood that microphone166and speaker170may include appropriate digital-to-analog and analog-to-digital conversion circuitry as appropriate.

Modifications, additions, or omissions may be made to the computer system100without departing from the scope of the present disclosure. For example, any of the components of the computer system100may include multiple similar components that function collectively and are communicatively coupled. Further, although illustrated as a single computer system, it is understood that the computer system100may include multiple physical or virtual computer systems that are networked together, such as in a cloud computing environment, a multitenancy environment, or a virtualization environment.

As indicated above, the embodiments described herein may include the use of a special purpose or general purpose computer (e.g., the CPU102) including various computer hardware or software applications, as discussed in greater detail below. Further, as indicated above, embodiments described herein may be implemented using computer-readable media (e.g., the memory114) for carrying or having computer-executable instructions or data structures stored thereon.

In some embodiments, the different components and applications described herein may be implemented as objects or processes that execute on a computing system (e.g., as separate threads). While some of the methods described herein are generally described as being implemented in software (stored on and/or executed by general purpose hardware), specific hardware implementations or a combination of software and specific hardware implementations are also possible and contemplated.

Attention is now directed toFIG.2, which illustrates a method for information flow and data collection configured for detecting malware by linking BITS or STS activities to a source program, which may be implemented by the antivirus application or monitor program158. In the Windows™ operating system, the BITS can be used by legitimate programs (e.g., Windows™ Update or Chrome Update) to facilitate the “transfer” of files from the Internet, but may also be used by malicious programs to facilitate such transfers (stage202). This can be done using documented Windows™ APIs to create an asynchronous job. In a similar way, the STS is used to execute programs (stage202).

Both services (BITS and STS) are located in svchost.exe, a process that can host from one to many Windows™ Services, can be the same process or not, and the jobs are executed by a thread pool located in the same process (the thread pool can be used by multiple services if they are loaded in the same svchost.exe) (stages206,210). As noted above, we will call the process that initiates a BITS or STS job the Source Program156. When a file is downloaded using BITS or a scheduled task is created using STS, many ALPC messages are sent from the Source Program156to the svchost.exe where the BITS or STS are loaded. For each of those ALPC messages an Event Tracing for Windows™ (ETW) message is also dispatched by kernel (stages202,206).

When a BITS job is created by Source Program156, it is allocated to a random thread from the thread pool. When the BITS job is started, a temporary file (named BIT????.tmp, where “?” is a hexadecimal character) will be created by the BITS150. After the file is downloaded, the BITS150will rename the temporary file with the name requested by the Source Program156(stage214). When a Schedule Task is created, a file is added to the folder: Windows\System32\Tasks (stage218).

Attention is now directed toFIG.3, which illustrates a data collection and basic data merging process configured for detecting malware by linking BITS or STS activities to a source program, which may be implemented by the antivirus application or monitor program158. Pursuant to the method300, detailed data is collected and merged in order to detect that a particular program (e.g., a “malware” program) was the program responsible for initiating a BITS transfer. In order to detect malicious code that uses downloaders and schedulers, the antivirus application or monitor program158may be configured to collect the following data in parallel:1. Process ID (PID) for BITS150and STS154(stage302).2. Temporary files created by BITS150along with the thread ID and the kernel time of creation (stage306).3. Rename operations executed by BITS146from temporary file in the file name requested by Source Program156along with thread ID and the kernel time of rename (stage310).4. Files that are created by STS154in the C:\Windows\System32\Tasks path along with the thread ID and the time of creation.5. ALPC_Send_Message events along with the message ID, process ID, thread ID, and the time of event (stage314a,314b).6. ALPC_Receive_Message events along with the message ID, process ID, thread ID and the time of event (stage318a,318b).7. Process IDs for all processes (stage322).

Attention is now directed toFIG.4, which illustrates a flowchart configured for detecting malware by linking BITS activities to a source program. In one embodiment the antivirus application or monitor program158implements the method400by performing the following operations:1. Each ALPC_Receive_Message is paired by the antivirus application or monitor program158with a previous ALPC_Send_Message that have the same message ID. This pair may be called an ALPC message. In one embodiment an ALPC message contains 5 fields:a. Timestamp—contains the time of ALPC_Receive_Message event.b. SourceProcessId—contains the process ID from ALPC_Send_Message event.c. SourceThreadId—contains the thread ID from ALPC_Send_Message event.d. DestinationProcessId—contains the process ID from ALPC_Receive_Message event.e. DestinationThreadId—contains the thread ID from ALPC_Receive_Message event. All ALPC messages that don't have SourceProcessId/DestionationProcessId equal to BITS Service process IDs may be dropped.2. Upon being notified that the BITS Service created a temporary file, the antivirus application or monitor program158searches for an ALPC message that has the timestamp in the same time period as the temporary file creation and the DestinationProcessId and DestinationThreadId are the same as the process ID and thread ID that created the temporary file. After finding such an ALPC message, the process that started the file download can be identified by examining the SourceProcessId field. There is an ALPC message for each file from a BITS job (there can be more files in same job).3. Upon being notified that the BITS Service renamed a temporary file, the antivirus application or monitor program158gets the new file name and assigns it to the Source Program. Now the antivirus application or monitor program158knows which files have been downloaded from the Internet by the Source Program156using BITS150. If what is of interest is simply knowing if a program used BITS150, then step3can be ignored.

Since in one embodiment everything is asynchronous, ALPC messages can be received after the temporary file creation or even after the temporary file rename if a small file is downloaded. The ALPC messages are typically received before temporary file creation but that is not guaranteed, so in one embodiment everything is added to the detection buffer160to ensure that all ALPC messages relevant to a particular event (e.g., file creation, temporary file rename, etc.) are received prior to processing and evaluation of the event.

Attention is now directed toFIG.5, which illustrates a flowchart configured for detecting malware by linking STS activities to a source program. In one embodiment the antivirus application or monitor program158implements the method500by performing the following operations:1. The antivirus application or monitor program158operates in the same manner as the BITS detection method400discussed above with reference toFIG.4, with the except that in the method500the program158drops all ALPC messages that do not have SourceProcessId/DestinationProcessId equal to STS process ID.2. Upon being notified that the STS154created a file in the C:\Windows\System32\Tasks path, the antivirus application or monitor program158searches for an ALPC message that (i) has the timestamp in the same time period as the file creation and (ii) for which the DestinationProcessId and DestinationThreadId are the same as the process ID and thread ID that created the file.3. The created file is an XML file and by parsing it the antivirus application or monitor program158can find the exact command that will be executed. (See, e.g., https://docs.microsoft.com/en-us/windows/win32/taskschd/task-scheduler-schema). At this point the antivirus application or monitor program158knows what tasks are created by Source Program and what command will execute the scheduled task.

As an alternative to the above step2in this technique, the antivirus application or monitor program158could monitor new entries in the registry path: \REGISTRY\MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Schedule\TaskCache\Tree that is also added when a new task is created. Note that since everything is asynchronous, the antivirus application or monitor program158may receive an ALPC message after the file creation. Although ALPC messages are generally received before file creation, this is not guaranteed. Accordingly, in one embodiment everything is added to the detection buffer160to ensure that all ALPC messages relevant to a particular event are received prior to processing and evaluation of the event.

FIGS.6A and6Billustrate a flowchart of an example method600for detecting malware by linking BITS activities to a source program. The method600may be performed, in some embodiments, by a device or system, such as by the antivirus application or monitor program158. In these and other embodiments, the method600may be performed by one or more processors based on one or more computer-readable instructions stored on one or more non-transitory computer-readable media. The method300will now be described in connection withFIGS.1-5.

The method600may include, at action602, buffering, in a detection buffer within the memory, a plurality of send Advanced Local Procedure Call (ALPC) messages and a plurality of receive ALPC messages created by the operating system when a Background Intelligent Transfer Service (BITS) of the operating system is used to download one or more files to the computing device from a network.

The method600may include, at action604, identifying a first send ALPC message within the plurality of send ALPC messages and a first receive ALPC message within the plurality of receive ALPC messages, wherein the first send ALPC message and the first receive ALPC message have a first common message ID.

The method600may include, at action606, pairing the first send ALPC message and the first receive ALPC message to create a first ALPC message pair, wherein the first ALPC message pair includes: a first timestamp field having a value corresponding to a time of creation of at least one of the first send ALPC message and the first receive ALPC message, a first ALPC source process ID corresponding to a send process ID of the first send ALPC message, a first ALPC source thread ID corresponding to a send thread ID of the first send ALPC message, a first ALPC destination process ID corresponding to a receive process ID of the first receive ALPC message, and a first ALPC destination thread ID corresponding to a receive thread ID of the first receive ALPC message.

The method600may include, at action608, receiving a notification that a temporary file has been created by the BITS, the temporary file being created as part of a file download initiated by the source program.

The method600may include, at action610, determining whether (1) the value in the first timestamp field corresponds to a time of creation of the temporary file, and (2) the first ALPC destination process ID corresponds to a process ID of the temporary file, and (3) the first ALPC destination thread ID corresponds to a thread ID of the temporary file.

If (1) the value in the first timestamp field does not correspond to a time of creation of the temporary file, or (2) the first ALPC destination process ID does not correspond to a process ID of the temporary file, or (3) the first ALPC destination thread ID does not correspond to a thread ID of the temporary file, then the method600may include, at action612, discarding the first ALPC message pair.

However, if it is determined that (1) the value in the first timestamp field corresponds to a time of creation of the temporary file, and (2) the first ALPC destination process ID corresponds to a process ID of the temporary file, and (3) the first ALPC destination thread ID corresponds to a thread ID of the temporary file, then the method600may include, at action614, evaluating the first ALPC source process ID to identify the source program responsible for initiating the creation of the temporary file.

The method600may include, at action616, determining, based at least in part on the temporary file, that the source program is a malware program. A determination that the source program is a malware program may be made, for example, by determining that the temporary file is also malware or infected. For example, a determination that the temporary file is malware or infected may be made by through regular signature and/or cloud scan. In another example, a determination that the temporary file is malware or infected may be made if the source program downloads the temporary file from a blacklisted server.

The method600may include, at action618, performing a security action on the source program. This security action may include quarantining and/or deleting the source program.

FIGS.7A and7Billustrate a flowchart of an example method700for detecting malware by linking STS activities to a source program. The method700may be performed, in some embodiments, by a device or system, such as by the antivirus application or monitor program158. In these and other embodiments, the method700may be performed by one or more processors based on one or more computer-readable instructions stored on one or more non-transitory computer-readable media. The method300will now be described in connection withFIGS.1-5.

The method700may include, at action702, buffering, in a detection buffer within the memory, a plurality of send Advanced Local Procedure Call (ALPC) messages and a plurality of receive ALPC messages created by the operating system when a Scheduled Task Service (STS) of the operating system is used to schedule a task to be performed by the operating system.

The method700may include, at action704, identifying a first send ALPC message within the plurality of send ALPC messages and a first receive ALPC message within the plurality of receive ALPC messages, wherein the first send ALPC message and the first receive ALPC message have a first common message ID.

The method700may include, at action706, pairing the first send ALPC message and the first receive ALPC message to create a first ALPC message pair, wherein the first ALPC message pair includes: a first timestamp field having a value corresponding to a time of creation of at least one of the first send ALPC message and the first receive ALPC message, a first ALPC source process ID corresponding to a send process ID of the first send ALPC message, a first ALPC source thread ID corresponding to a send thread ID of the first send ALPC message, a first ALPC destination process ID corresponding to a receive process ID of the first receive ALPC message, and a first ALPC destination thread ID corresponding to a receive thread ID of the first receive ALPC message.

The method700may include, at action708, receiving a notification that the STS has performed a defined operation, the STS performing the defined operation while being used by the source process.

The method700may include, at action710, determining whether (1) the value in the first timestamp field corresponds to a time period when the defined operation was performed, and (2) the first ALPC destination process ID corresponds to a process ID of the STS involved in performing the defined operation, and (3) the first ALPC destination thread ID corresponds to a thread ID of the STS involved in performing the defined operation.

If (1) the value in the first timestamp field does not correspond to a time period when the defined operation was performed, or (2) the first ALPC destination process ID does not correspond to a process ID of the STS involved in performing the defined operation, or (3) the first ALPC destination thread ID does not correspond to a thread ID of the STS involved in performing the defined operation, then the method700may include, at action712, discarding the first ALPC message pair.

However, if it is determined that (1) the value in the first timestamp field corresponds to a time period when the defined operation was performed, and (2) the first ALPC destination process ID corresponds to a process ID of the STS involved in performing the defined operation, and (3) the first ALPC destination thread ID corresponds to a thread ID of the STS involved in performing the defined operation, then the method700may include, at action714, evaluating the first ALPC source process ID to identify the source program responsible for performing the defined operation.

The method700may include, at action716, determining, based at least in part on the defined operation, that the source program is a malware program. A determination that the source program is a malware program may be made, for example, by determining that the defined operation is also malware or the tasks that it schedules are malicious. For example, a determination that the defined operation is malware or malicious may be made by through regular signature and/or cloud scan.

The method700may include, at action718, performing a security action on the source program. This security action may include quarantining and/or deleting the source program.

The methods600and700may thus be employed, in some embodiments, to detect malware by linking transfer service and scheduled task activities to source programs. Because BITS and STS are used to identify malware source programs, the identification of this malware may be performed in real time and a security action can be taken before these source programs are able to have significant downstream effects.

Although the actions of the methods600and700are illustrated inFIGS.6A,6B,7A, and7B as discrete actions, various actions may be divided into additional actions, combined into fewer actions, reordered, expanded, or eliminated, depending on the desired implementation.

Further, it is understood that the methods600and700may improve the functioning of a computer system itself. For example, the functioning of computing system100ofFIG.1may itself be improved by the methods600and700. Specifically, by identifying malware source programs quickly and performing a security action, downstream effects on the computing system may be avoided. These downstream effects may include a variety of functions such as stealing, encrypting, or deleting sensitive data on the computing system100. These downstream effects may also include altering or hijacking core functions of the computing system100and monitoring a user's activity. Allowing a computing system to run malware source programs may ultimately render the computing system inoperable.

As used herein, computer program products comprising computer-readable media including all forms of computer-readable medium except, to the extent that such media is deemed to be non-statutory, transitory propagating signals.

It is understood that the specific order or hierarchy of steps or stages in the processes and methods disclosed are examples of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention as claimed to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described to explain practical applications, to thereby enable others skilled in the art to utilize the invention as claimed and various embodiments with various modifications as may be suited to the particular use contemplated.