Trojan Software Update Scenario

You work in the IT security department for a software development company. Your company produces software for industrial control and automation equipment. You receive a call from a federal law enforcement agency that malware was discovered disrupting a control system at a waste treatment plant. The agency informs you that they recently traced the malware to a software update package your company provided to the plant’s IT department. They provide you with the update package filename and version number, the filename of the malware, and the package itself. They are requesting that you determine how this happened, verify if any other packages were affected, and provide a list of customers that received the affected packages. Following the process we introduced earlier in this chapter, you begin by examining the initial data the federal agency provided you:

• The package name is ctrl-drv-upd-2013-q2.exe, and the version number is 4.72.
• The malware filename is pmondrv32.exe.
• The malware was discovered months ago; however, only in the last week was it traced to your company’s software update.

As a good investigator, you always verify what other people tell you—even information from trustworthy sources. The first thing you decide to do is confirm that this package matches the package your company created and sent to the customer. You obtain access to the file share that stores customer deliverables, and you locate a copy of the update package for that customer. You then perform an MD5 checksum on each package and see that they match—the packages are exactly the same. Next, you need to confirm that there is a file named pmondrv32.exe in the package, and that it is malware. You provide the package to a third party for analysis, and they confirm that the file exists and that it appears to be malicious. Throughout this process, you take special care to prevent the accidental execution of any malware (we provide a number of safety tips in Chapter 16).

After confirming there is malware in the update package, you decide that your next objective is to determine how the malware got there. Two theories come to mind—either there is malware in the source code tree for the update package, or someone added the malware after the package was built. You believe it will be more difficult to determine if someone added the malware afterwards, so you decide to look at the source code tree. You do not have access to source code, so you decide to meet with a senior developer and the development team manager to discuss the situation and see if they can help. Based on the information you provide, the software team members examine the source code tree and determine the following:

• A source code file named pmondrv32.c was modified after a code freeze, but just prior to the suspect update package being built. The modifications do not appear to be related to the project.
• Within the same change record, there were modifications to the build and installation script files.
• The change record indicates that a new software developer committed the changes from an IP address that corresponds to his assigned computer system.

The software team members indicate that these changes could explain how the malware was introduced into the package, and subsequently installed on the customer’s system. You ask them to keep this issue quiet for now, until you can determine more facts.

You decide that you need a little more confidence that the suspicious source code file is malicious. Therefore, you provide the source code to the third party that previously analyzed the executable. They indicate, as best as they can tell, that the source code matches the capabilities of the executable. So at this point, you have preliminary evidence that suggests the source code tree was modified to introduce malware into the update package. Based on that conclusion, your software team must move quickly to determine if any other customers were provided update packages based on that code, and if any other part of the source code tree was modified in a similar manner.

Next, your investigation needs to explain the modifications—did the new software developer place malicious code in the source code tree, or is there another explanation? Because the updates were sent from the new developer’s computer, you start there. You remotely perform a live response collection and examine the results. You find that the developer was logged in to his system at the time in question, but you also find that seven minutes prior, there were multiple remote Windows type 3 logons, one of which lasted through the time of the source tree update. Type 3 logons are recorded for events such as accessing Windows shares and scheduling “at” jobs. The logons came from a public-facing web server. Although these logons do not remove suspicion from the developer, it is anomalous activity.

Before pursuing the insider threat theory, you decide to find out more about the web server. After tracking down the system administrator, you learn that the system hosts a web application that is used by third-party contractors. The sysadmin cannot think of a valid reason someone would log in to user desktops from this web server. You think that a closer look at the system may help to explain the connection. As you look through the operating system login events, you find that there are no logins on the date in question. In addition, the connections from the web server to the developer’s computer are not occurring on a regular basis, so you become more suspicious of this activity.

Because the operating system event logs did not indicate someone was logged in at the time of the suspicious activity, you theorize that someone may have exploited the hosted web application to gain access. If the web app is being exploited, there could be evidence in the web server logs. You perform a review of the web server logs that cover the time frame in question and discover that, when compared to other days, there is an unusually large number of requests to a specific URL. You have the application developer review the activity, and he believes the requests indicate a successful exploit of a vulnerability in the Apache Struts framework that the application is built on. Specifically, it seems as though the attacker launched and interacted with a reverse shell.

Based on this new evidence, it does not seem as though the new developer is a party to the malicious activity. However, because the attacker is using the developer’s system, you decide to preserve evidence—live response, memory image, and hard drive image—from his workstation, as well as from the web server. In addition, you preserve evidence from the source code repository, because you will need that data to help determine the full scope of the attacker’s changes to the source code.

Trojan Software Update Scenario—Scoping Gone Wrong

As in the other scenarios, there are many ways this investigation could have been sidetracked. Here are two ways we think this scenario could have played out:

• The Unwise Path Your investigation focuses on tracking down where the malware was injected into the update package. You discover that a new developer is responsible for submitting the changes that contained malicious code. The new developer leaves the company, and management tasks the security team with finding every piece of data the new developer changed so the modifications can be undone. Because the developer left the company, management assumes that person was guilty and initiates legal action. You are tasked with preserving all of that employee’s data. You spend your remaining time helping the software team track down each software package affected so your company can create clean update packages for its customers.

The Problem Although you may have solved the immediate problem, you have not produced evidence that shows how or why the code was modified. The real issue is never discovered, and the attacker continues to inject additional malicious code into your software by using another developer’s credentials.

• The Unwise Path After uncovering the remote IP address associated with the web server exploit, you choose to “hack back” at the attacker. You perform a portscan against the remote IP address, and discover numerous active services—a website, FTP server, and secure shell. You examine the website and notice there are rudimentary pages set up that seem to be for sharing files. You use the sqlmap tool to search for SQL injection vulnerabilities on the login page. You eventually gain administrative access to the system, and set up monitoring, with the hope of “catching the bad guy.” You notice there are many compressed files on the system, and assume they must be related to something the attacker stole from your company. You download copies of all of these files to find out what they are.

The Problem The site you “hacked back” at is a legitimate server run by a small consulting company. The attacker hacked the consulting company’s server and used it to mask his true location and to launch other attacks, including the one against your company. The consulting company is now suing you for unauthorized access, data theft, and wiretapping.