CHAPTER
5
Malware Dependencies
A malware’s main purpose is to execute effectively on the target system to achieve its directive. If it is not able to do this, then it has failed. This is what you want. You want the malware to fail. This is why there are many safeguards in place to prevent, detect, and respond to malware attack. Organizations invest money in different security products and security teams to make sure that malware will fail if it ever finds itself on the target system.
But when it comes to malware analysis, the opposite is desired. You want the malware to function as intended by the attacker. You want it to execute all the functions it has. The more functions or capabilities the malware exhibits during execution, the better it is for malware analysts and researchers. The more successful the malware is at executing on a target system, the more data that can be gathered, which leads to understanding the malware’s behavior and main directive. All of this of course must happen in a controlled environment.
But this is not a perfect world. Malware is not perfect. Although malware is designed to execute (and even if you want it to execute), it might not be able to do so because of some factors. Malware, after all, is software. Like other software, it can have flaws or bugs that might prevent it to execute all or some of its functions. A flawed malware is useless and usually not analyzed further. A malware that is buggy is the same thing and not analyzed further. Although it is tempting to try to fix a buggy malware to see how it works, it is a debatable task. In the industry, the consensus is that this is unethical.
For malware that does not work because of flaws and bugs, it is often named with the DAM or INT extension, such as W32/MalwareFamily.DAM or W32/MalwareFamily.INT. DAM stands for damaged, while INT stands for INTENDED. DAM is usually used for flawed malware because the malware design itself is the main culprit of why it does not work; hence, it is damaged from the get-go. INT, on the other hand, is used for buggy malware. The malware is intended to function in a certain way, but because of a bug or bugs in its code, it is not able to do so.
NOTE
The distinction between DAM and INT is not always followed in detection names. In most cases, all flawed and buggy malware is just given a DAM extension.
Malware that does not have flaws and bugs may not run perfectly in the target system. There can be other impediments for malware to execute or function properly as intended by the attackers. In some cases, malware execution can stall or proceed only in parts, meaning that only a few functions execute while the rest do not. And in malware analysis, you want the malware to execute all functions.
The reason for non-execution or partial execution of malware is known as malware dependencies. Just like any other software, malware has dependencies for it to function properly. Think of scanning software that has all the bells and whistles to enable a user to scan from any printer or from a mobile device camera, with the scanned object saved directly to a computer. Without the main drivers that enable it to communicate with the hardware used for scanning, the software will not function as intended. Another example is a script that reads social media messages and then displays the messages on a customized user interface. Even if the script is flawlessly written but executed in a system without the library to support the social media protocol, it will not work. This is true for malware, as well. Without the presence of its dependencies, it will not function normally.
In this chapter, I will discuss the different malware dependencies that influence the successful execution of malware. Understanding these dependencies is key to creating an effective, controlled environment for malware dynamic analysis.
Dependency Types
Malware, like any other software, has dependencies for it to function properly. The more sophisticated the malware is, the more dependencies it has. This is true especially for malware used for targeted attacks. For example, a malware that will be used to attack Organization A will be designed to run only in endpoints present in Organization A. The malware is able to accomplish this by adding a dependency that is present only in Organization A’s endpoints. An example dependency is a logged-in username. If the username is preceded by ORGA and has the format ORGAusername, then the malware assumes that it is running in an endpoint in Organization A and thus will function according to plan.
NOTE
Malware dependencies can be intended or unintended. They are intended if the attacker needs them as conditions or triggers, and they are unintended if the attacker designed the malware in a controlled lab and failed to take into consideration that not all the dependencies the malware needs to run are present in a target system.
Malware dependencies can range from the system’s characteristics, as discussed earlier, to user-driven events. They are divided into the following:
Environment dependencies
Program dependencies
Event dependencies
User dependencies
File dependencies
Environment Dependencies
If all the systems in the world had uniform environments, malware analysis would be easy. Then again, it would be easy for the attackers too. The way a malware operates is confined within the environment’s digital physics. This is true for all software as well. Each environment has its own rules of digital physics. As a consequence of this, a malware written for one environment will not function in another environment. It is as simple as that.
NOTE
Most malware writers design their malware to be environment-agnostic by piggybacking on popular programs used across different environments such as a multi-platform web browser.
Therefore, for a malware to successfully execute, it must be running in the right environment. Dependency on the system environment is the most critical dependency of all. Violate this and the malware is useless. This is why static malware handling and storage are often done in an environment in which the malware will not run.
Environment dependencies include the following:
Operating system
System settings
Virtualization
Operating System
The operating system (OS) is the link between applications and system hardware. It is a software platform that manages hardware, peripherals, and any other resources the system uses. Without it, no application would be able to run or communicate with any hardware resources such as the keyboard, mouse, and monitor. For an application to function properly in a system, it must be written to run in the operating system that is present on the system. Malware is an application, so it must be written, therefore, to run in the operating system that is running on the target system.
An operating system dependency is quite self-explanatory. The malware has to be executed in the operating system it was written for. But it is important to remember that operating systems are not static; they are dynamic. This means there will be bugs discovered that need to be fixed or features that need to be added to improve the operating system’s functionalities. These fixes and improvements come in the form of service packs (SPs).
TIP
Get the latest service pack or update for Windows from http://windows.microsoft.com/en-us/windows/service-packs-download#sptabs=win8other.
Different Windows versions can have different service pack levels. In some cases, a malware will run on a Windows system only with the latest service pack, or in the case of older malware, they might run properly only with older service packs installed. This is because service packs introduce several updates and bug fixes that might impact or close the holes that malware exploits to execute properly. Service packs also modify some system structure that renders old malware to be useless because the new structure is unsupported by the malware code. For example, disabling autorun, which is covered under the Security Advisory (SA) 967940 update, has contributed to a decline in the autorun capability exploiting malware and having sandboxes with this update installed will not be able to properly see the autorun capabilities of these types of malware. Therefore, it is important to be mindful of service pack changes that might affect malware execution.
TIP
Always keep different OS flavors and service packs on hand. You never know when you will need them.
An executable written for a specific operating system will have a format specific to that operating system. Only the operating system it is written for will be able to understand that specific file format and thus execute the file. This is a good way to determine whether a certain executable will run in a target system. There are lots of tools that can be used to determine an executable’s file format. This enables you to know whether the file is worth analyzing in the first place. For example, an executable file determined to be a Linux executable is of no interest to you if you are concentrating on Windows executable files. If this is the case, you do not need to analyze the file further.
In automated malware analysis systems, this is an important process in weeding out files. Executable files or any other file format that is not supported by the automated malware analysis system will not be submitted anymore. These files will be discarded, which saves sandbox resources. Say a system receives 100,000 samples a day, but 30 percent of those samples are unsupported. If each file is processed for 30 seconds in the sandbox, then weeding out those files saves the system 900,000 seconds, or 250 hours.
System Settings
System settings are another important aspect of successfully executing malware. A restrictive setting might not be a good idea when it comes to providing malware with an environment to properly run on. Although some malware is designed to circumvent even the most restrictive settings, it is still a good idea to make a malware test environment more malware friendly. This also includes a more relaxed setting for other key programs that malware utilizes, such as Internet browsers.
TIP
In some cases, malware will expect a more restrictive setting, especially if it is written for targeted attacks. If this is the case, always keep environment images with restrictive settings.
You can find the Windows 7 security settings in the Control Panel, as shown in Figure 5-1.
Figure 5-1 Windows 7 security settings.
If you want malware to connect freely to the network resources it needs, you will have to turn off or deactivate the network firewall. If you want the malware to do what it needs to do in the host, you need to disable virus protection, spyware, unwanted software protection, and Windows Defender, among others. User Account Control (UAC) will need to be disabled as well so the malware can make whatever changes it needs to the system during installation or infection.
Virtualization
You can implement a malware test environment in two ways: virtualized and bare metal. Most implementations are virtualized because those implementations are cheaper (one machine can host multiple guest OSs) and faster to restore. But with the rise of virtualization-aware malware, they are not always the best choice unless the analyst knows beforehand that the malware being analyzed is not virtualization-aware or virtual-aware.
Virtualization-aware, virtual-ware, and VM-aware all mean the same thing.
Although there are tricks that can be employed to fool the malware that it is not running in a virtualized environment, it takes only a short amount of time for the malware writers to circumvent this, especially if the trick is already public. If it is already in the public domain, chances are the malware writers are already working for a solution to undermine that specific trick. Therefore, it is always advisable to have a bare-metal system ready when the need arises.
TIP
When people ask me which implementation I prefer, I always tell them that I run an unknown malware in a virtualized environment first, and when nothing happens, then I use my bare-metal environment.
Program Dependencies
Malware that has specific functions most of the time has program dependencies. Some malware utilizes specific programs for it to achieve its directive. The programs or applications the malware depends on are usually common on systems that are used regularly but not in dynamic analysis systems. This is the reason why malware runs successfully in a victim system but not in a test environment. To mitigate this, the test environment or malware analysis system must mimic a system that is used for everyday computing. Familiarizing yourself with the often-used program utilized by malware will help you in setting up a test environment that is as close to a real-world computing system that is being used regularly.
For example, most mass-mailing worms need the presence of an e-mail client. If no e-mail client is installed, they will not work. The malware will not be able to send copies of itself through e-mail. The most common e-mail client that is often abused by malware is Outlook. Having Outlook installed in a target system will help in satisfying this program dependency. But simply having Outlook may not be enough. In most cases, a mass-mailer malware will need to read an existing address book to know where to send copies of itself. An empty address book will not work; the address book must have entries.
TIP
Put entries in the address book of a malware test environment that point to e-mails that you control. This will help you determine whether the mass-mailer is a success and what kind of e-mail is being sent. This is good for formulating an anti-spam solution.
Attackers understand that not all target systems will have Outlook, especially those systems that are owned by home users. If this is the case, mass-mailers will often utilize Outlook Express, which comes with Windows. To make sure that the malware can successfully utilize it, Outlook Express must be configured, and the address book must be populated. Take note that newer versions of Windows do not have Outlook Express anymore, but if the test environment uses a flavor of Windows with Outlook Express, it must be configured to make the system more malware friendly.
Another popular program that malware is often dependent on is the Internet browser. Everybody who owns or has access to a computer, be it a desktop or mobile device, will always use an Internet browser. This is why the browser is also arguably the most abused program. It is not only used as a dependency but also used as an infection vector for malware. An Internet browser is also a good candidate for exploitation by the attackers, especially if it has lots of vulnerabilities. An attacker can exploit any of the Internet browser’s known vulnerabilities and deploy a malware to a target system.
The presence of vulnerabilities is not the only reason why Internet browsers are important to attackers. Going back to program dependency, Internet browsers are our windows to the Internet. Browsers enable all of us to access web-based services such as webmail and social networks. A malware that wants to minimize program dependency on something that is already installed on a possible target system that almost everybody uses finds Internet browsers an attractive candidate. For example, a malware that wants to spam e-mails can hook into an Internet browser so that every time a user logs in to a webmail service, the malware can take over and send spammed copies of itself to the contact lists of the compromised user and even reply automatically to new e-mails that are received. It is therefore important to have an analysis system where malware like this is submitted to have an Internet browser running and logged in to an active and controlled webmail account.
Another example of a malware that finds Internet browsers useful is one that uses social networks as an infection vector. These types of malware rely on a user to be logged in to a certain social network for the malware to function properly. For example, the Trojan known as Febipos takes advantage of a victim’s Facebook account once it compromises the target machine. As described by Microsoft, it performs several social network–related tasks such as liking a page, sharing a post, posting messages, joining a group, inviting friends to a group, commenting on posts, and sending messages and links via chat. For malware with similar behavior, it is important to fire up an Internet browser first and then log in to a controlled social network account on the analysis system before the malware is executed.
Aside from e-mail clients and Internet browsers, Portable Document Format (PDF) readers, chat software, and file-sharing programs are among the programs that malware utilizes for its own malicious purpose.
TIP
Always keep a collection of different versions of often-exploited programs just in case they aren’t available for download anymore.
Having familiarity with how malware uses the different programs it is dependent on ensures that it will execute as intended in the malware analysis system. A good malware test environment must have all or some of these programs installed to increase the chance of the malware executing properly and the analyst collecting data from the dynamic malware.
Timing Dependencies
Timing is everything. This is also true for malware. Depending on the attack, a malware might go dormant for a significant amount of time before striking, or it can strike immediately after it has taken hold of a target system.
Timing dependencies usually have to do with a malware payload. A malware payload is a malware function that reveals what it really is. It can be considered a malware’s main directive. For example, a malware with a payload of deleting all files in the system can be considered a Trojan because of its destructive directive. It is important to determine what a malware’s payload is because it enables researchers and analysts to come up with preventive measures and solutions to mitigate it.
Execution of a malware payload can be instant, or it can be based on a specific condition such as date and time, which is known as a time trigger. A malware might wait for a certain time in the day to execute its payload. For example, a malware might trigger its information-stealing function every 3 a.m. when nobody is around. Or the malware might wait for a specific date to activate its payload. The Conficker worm actually grabbed headlines years ago that it was going to trigger some mysterious payload on April 1. Nothing happened. April 1 is April Fool’s Day after all.
TIP
To check whether a system is infected by Conficker, use the Conficker Eye Chart located at www.confickerworkinggroup.org/infection_test/cfeyechart.html.
A timing dependency can also mean dormancy, where the malware sleeps or does nothing for a certain amount of time. This can range from minutes to even months. This is a common evasive technique against automated malware analysis systems. An analysis system gives malware only a limited time to execute. It is usually 30 seconds to 3 minutes. Because of this timing dependency, the malware will not execute, and therefore no malware activity will be recorded. This is why it is wise to have a manually driven analysis system for special malware such as malware with a timing dependency.
A telltale sign that a malware might have a timing dependency is a function that enables it to determine the local system time. In the old days, it was easy to manipulate malware that had timing dependencies. A simple change in the system date and time to coincide with the malware’s trigger usually did the trick. Obviously, the malware writers were aware of this. The malware writers knew that system date and time could be manipulated, especially in malware-testing environments. To mitigate this, the attackers programmed their malware to check Network Time Protocol (NTP) servers to determine the real current date and time. NTP synchronizes the time across computer systems. Of course, malware checking NTP servers works only if the compromised system is online.
Event Dependencies
As I discussed in the previous section, the execution of a malware payload can depend on timing. It can be instant, or it might take a longer period of time. The exact time or length of time before a malware executes its function or payload is called a time trigger. But this is not the only trigger there is. There is also another that is based on a specific condition. This condition can be an event or series of events. It is called an event trigger.
An event can be anything that goes on inside the system. Some examples are pressing a key, clicking the mouse, moving the mouse pointer to a certain location, putting the system to sleep, shutting down, and starting up. These events can trigger a malware payload. For example, On Windows, a key press combination of Alt+Prtscrn is used to capture the active window as an image in the clipboard. An information stealer malware might use this as an event trigger to save the current clipboard for later exfiltration. A more complex event can be the execution of an Internet browser followed by a series of keystrokes that spells out an online banking site. This event can trigger a keylogger, desktop capturer, or memory scraper with the purpose of stealing banking credentials.
An event can also be outside the system. For example, a social media or website update can be considered an event. If a certain monitored social media site or website posts something that triggers a malware to act, then that posting is considered a malware trigger event. This is especially useful for botnets that are utilized for spamming jobs. A botnet agent can simply monitor a specific product’s website for an announcement, and once an announcement is done, the botnet sends out its spam e-mails that could be carrying malware. For example, if the botnet wants to send spam about a new Apple product, it can simply monitor Apple’s website for any announcement of a new product and then trigger its spam to potential victims announcing that they have won that new product and all the user needs to do is to click a link to claim the prize or download or double-click an attachment.
Malware that has event dependencies is challenging when submitted to an automated analysis system. The only time an automated analysis system will succeed in executing the malware is when all of the events are satisfied and thus triggering the malware. In actual practice, malware with event dependencies is often analyzed manually to fully understand its capabilities. Only then will those events be added to an automated analysis system.
Spotting malware that has event dependencies depends on the functions it exhibits. Malware that has functions monitoring any system events or external resource such as online feeds will likely have a payload that is event-triggered.
User Dependencies
Some malware depends on targeted users to achieve its directives. It takes advantage of users in two ways, as follows:
Compromise accomplice
Roles and access
Compromise Accomplice
As much as possible, malware writers want their malware to be able to compromise a target without any form of user interaction. The more silent and hidden the malware is, the less chance it has of being detected. But there are cases where malware needs the user to accomplish its task, and as a result, the users become accomplices to the infection of their own systems.
Users being used by malware as unwitting accomplices to its initial stage of compromise is nothing new. Some malware has always been dependent upon the users to do what the malware cannot do such as bypassing security features that only the user can disable. This is especially true when malware needs the user to click buttons for the malware installation to proceed. Scareware such as fake AV malware is notorious for this. Since it has disguised itself as a legitimate security product to fool the user, the user simply clicks whatever the malware wants the user to click to have the fake AV malware installed on the system. This is a good method of bypassing Windows UAC. Socially engineering the user to grant the malware administrator rights is one sure way of getting the malware installed on the target system. For this type of user dependency to be successful, the malware must be able to fool users through social engineering or scare tactics, which are techniques used by scareware, and get them to do anything that the malware or disguised malware wants them to do.
Roles and Access
Malware user dependency is not confined to users clicking buttons or being victims of malware social engineering tactics. Sometimes malware infects a target system based on user roles or a user’s position in the company. In this case, a malware targets a system based on what kind of user has access to that system.
NOTE
The attackers also use personnel roles to gauge the gullibility of a user. The higher up the person is in the food chain, the more knowledgeable that person is when it comes to security, so utmost care and a much more sinister social engineering technique is often employed.
The following are the common types of users found in an enterprise:
Executives and senior management
Technical users
HR and finance
Marketing and sales
Non-critical users
Executives and Senior Management Systems used by people with high positions within the company such as executives and senior management can contain the most sensitive data about the company. Plus, these users or the systems they use have access to servers that hold lots of information that is vital to the company’s business. This can include data that has future company strategy, a release road map of a flagship product, or confidential correspondence with partners, business contacts, and people within the company. Since executives and senior management are the people responsible for steering the company to success through their decision making based on various company or competitor data they have, theft or tampering of these data can be detrimental to the company’s business.
Executives and senior management are so important that there is a specific phishing attack geared toward them. It is known as whale-phishing. The attack consists of specially crafted e-mails or any correspondence to mislead these head honchos to act on it. The action can result in credential theft or malware installation. It results in credential theft because the content of the whale-phishing e-mail is convincing enough to trick the executives and senior management officials into divulging information such as logon credentials or any other access credentials that will give the attackers access to systems that are reserved for the executives and senior management team only. It results in malware installation because the whale-phishing e-mail can be used as a deployment technology that carries the malware itself or points to a uniform resource locator (URL) where a visit can result in malware installation.
In most organizations that hold sensitive information, executives and the senior management team undergo periodic security training. In some cases, even their immediate family members are briefed about the risk of security and posting information online via social media. For example, say a CEO’s daughter posts this in her social media account: “Party at our place. Mom is attending a conference in Vegas.” An attacker can use this information to send a whale-phishing attack to the CEO. The e-mail might contain something like, “Thank you for attending our conference in Vegas. As a token of our appreciation, please download the certificate attached in this e-mail.” Here is another variation: “Thank you for attending our conference in Vegas. We would really appreciate it if you can provide us with your feedback. Please click the link to take you to the survey. After completing the survey, we will send you a $100 certificate that you can use for next year’s conference.” There are two things that can happen here. The attachment that claims to be a certificate is malware, and the link that is being passed as a survey is a drive-by download site.
Another way of taking advantage of the information posted by the daughter is through snail mail. Instead of sending a whale-phishing e-mail, a letter is sent through the postal service with a certificate and a note requesting the CEO to visit a certain URL. Another variation of this is that instead of a URL, a USB stick is included as a sign of appreciation for attending, but unknown to the CEO, this USB stick contains malware.
For some reason, most people trust postal mail more than e-mail, prompting the attackers to take advantage of this human behavior.
Technical Users Technical users are attractive targets because they have access to the company’s goodies. The research and development department, for example, has access to the most valuable intellectual property of the company such as new concept research, source code, or detailed information about a product’s technology. These users also are the ones who get their hands dirty because they are accessing systems with sensitive data all the time. Just think of the following roles in this group, to name a few:
Researcher
Analyst
Developer
Quality assurance
Architect
Engineer
Database administrator
The amount of data these roles have access to can be attractive to attackers, especially if the attack is company espionage.
Another group of technical users is the IT department. This is probably the most important group in this role, especially if the attack is about network compromise and planting a backdoor for long-term access. IT personnel have access to information and details about the organization’s network infrastructure. They also have access to other credentials that serve as keys to the kingdom. This makes it attractive to attackers because it enables them to compromise not only systems within the company but also systems of partner organizations if the credentials are available.
HR and Finance Information about company employees resides in systems that human resources (HR) personnel have access to. The information in these systems can include salaries, benefits, performance ratings, and other job-related information. But most importantly, these systems contain personal private information (PPI) that is associated with each employee. Some of the PPI that can be found in an employee information database are Social Security numbers, parents’ full names, birthdays, government ID numbers, and any sensitive information that is unique to the employee. The misuse of this sensitive and private information can lead to identity theft. PPI can also be used to blackmail an employee and become the attacker’s inside connection to the company. For example, instead of planning for sophisticated malware deployment technology, the attacker can simply ask the blackmailed employee to execute a malicious binary in the company’s network.
The financial data of a company reflects how financially healthy the company is. It can also include financial statements that potential investors might be interested in. Financial data is attractive to attackers because it can be used by a competing organization to gauge its competitor’s financial capability and plan around it. It can also be leaked publicly, which could be detrimental to the company, especially if there are anomalies found in it.
In some organizations, HR and financial data resides in the same system. Other data that can be useful to attackers consists of the employees’ bank accounts, especially those who conduct direct deposit of their salaries. Although it’s not common, an attacker can manufacture forged checks using an employee’s checking account number and routing information and make it payable as cash.
Marketing and Sales Systems that are used by marketing and sales contain information about customers. Aside from the customer name, customer information can also contain company name, position in the company, address, e-mail, phone number, and fax number. Attackers can use this information in so many ways; some of them are the following:
Phishing attack targets Attackers can use the e-mail addresses as recipients of spam, and depending on the person’s position, a whale-phishing attack can be conducted.
Spoofed e-mail address Attackers can use the e-mail addresses in the From field of their spam campaign.
For sale Attackers can sell the information to third-party marketing entities or to competing organizations.
Aside from customer information, the systems used by marketing and sales can also contain customer leads and marketing strategy. Customer leads are important because they have the potential to become customers. A good way for organizations to get potential customers is through conferences. An organization might offer something for free such as a shirt or stress ball in exchange for scanning the customer’s conference badge. A conference badge contains information such as name, company, role, e-mail, and phone number. After the conference, these potential customers will get phone calls or e-mails following up whether their company is interested in buying whatever product or service that organization is offering. As you can see, one conference badge scan can cost the organization a shirt, which if bought in bulk is roughly $8 to $10 each. This is how much the data from one potential customer costs the organization. Ten thousand customer leads can cost $80,000 to $100,000. An attacker who steals this kind of information can sell it for cheap to a competing organization. The competing organization will not only have a copy of the list of potential customers but also save time, effort, and money if the competing organization were to acquire potential customer leads itself through conferences and other means.
Other important information that may be valuable to a competing entity is marketing strategy. This information can be found in systems accessed by marketing and sales.
Non-critical Users Non-critical users are those who have limited access to any data within an organization. The only data these users have access to is data considered to be in the lowest spectrum of sensitivity. This is something the company does not mind leaking to the public because it has little value or will not affect the company’s business in anyway if it gets stolen. One example of a non-critical user is a front-desk employee, who has access only to scheduling data. Attacking this role may lead only to systems with minimal sensitive data or no sensitive data at all. The danger is only when the system’s non-critical users use or have access to a network that has systems connected to it that contain sensitive data.
File Dependencies
Malware that steals information, also known as information stealers, is the most common type of malware that has file dependencies, especially malware designed to steal documents. This type of information stealer functions by enumerating files inside the Documents folder or any folder where documents are saved. It then proceeds to compare the names of the documents to keywords that the malware has coded in its code or found in a configuration file that the malware is using. A few example keywords are financial, salary, report, employee, incentive, and so on. If a file matches any of these keywords, the malware will send copies of the matching document to a drop zone that is controlled by the attacker.
Another method of picking which documents to steal is through filename extensions. An information stealer, instead of using keywords, will just send copies of all documents that have extensions of .DOC, .DOCX, .XLS, .XLSX, .PPT, .PPTX, .PNG, .JPG, .TIF, and so on. Attackers understand that these files are data heavy, which is why exfiltration of stolen information is sometimes done not in bulk but in a staggered way. The only drawback of this is that once the malware is found and stopped, the attacker is left with corrupted data.
Information stealers also target graphic files, especially if the attack is against a publication company.
In most cases, this behavior of information stealers can be triggered only by the presence of these files. It is therefore important to have documents and graphic files present in a sandbox environment to entice information stealers to activate their file-stealing capabilities. But be mindful of document sizes also; most information stealers have a checking mechanism. The checking mechanism has to do with size. If the files have 0 bytes, nothing will happen. So, it is important for these dummy files to have dummy information inside them.
During analysis, if the dummy files suddenly disappear, it means that the information stealer has a destructive functionality. This functionality is activated once a copy of the stolen file has been exfiltrated. The information stealer deletes the files from the compromised machine, leaving the victim with nothing.
Recap
In this chapter, I discussed the different malware dependencies and how each affects the successful execution of malware. They are as follows:
Environment dependencies
Program dependencies
Timing dependencies
Event dependencies
User dependencies
File dependencies
Knowing a malware’s dependencies is critical to ensuring that it is able to execute all of its intended function in a controlled environment. This is key when extracting information during dynamic analysis. A malware that is running successfully in a controlled environment enables you to capture more data to understand the malware’s main directive.