Describing the Components

In this section we describe the functionality and components of CWSandbox in detail. The sandbox itself consists of two different executables: cwsandbox.exe and cwmonitor.dll. The first one is the main application, which starts the malware and controls the whole analysis process, and the second one is a dynamic link library (DLL), which is injected into all monitored processes. During the execution of the malware, the DLL intercepts at each critical API call and informs the main application of it. Depending on the type of system call, it either waits for the sandbox to decide how to continue, delegates control to the originally called API function, or simply returns to the malware with a simulated or error result. Besides monitoring, the DLL also has to ensure that whenever the malware starts a new process or injects code into an already running one, the sandbox is informed of that. In that case a new instance of the DLL is injected into that newly created or already existing process, so that this process also can be monitored. A schematic of this architecture is given in Figure 10.4.

Figure 10.4 CWSandbox Architecture

As mentioned, the monitoring DLL informs the sandbox about each performed API call, which in fact is done by sending a notification to it. These notifications include a lot of information, like the name of the called API function, the used parameters, or the time when the call occurred. Depending on the type of the function, a different TNotification class is used. Subclasses for the following categories exist:

There is a focus on analyzing the network connections and the traffic data. For that reason the transferred data is inspected and an attempt is made to determine the underlying Web protocol. At the moment, the following protocols are understood: Hypertext Transport Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), Internet Relay Chat Protocol (IRC), and the Ident Protocol (IDENT). Connections that use RFC-conform messages and slightly modified versions of them are automatically detected, and all the protocol-dependent data, such as the login information, downloaded Web sites, or performed FTP commands, is extracted. If an SMTP connection is detected, the CWSandbox can be instructed to trick the malware such that only informational requests are sent to the remote SMTP server instead of real mail delivery. That way, the malware thinks it is working with a proper SMTP server. All the information about outgoing e-mail can be monitored, whereas no actual e-mail is sent at all.

Cwmonitor.dll

The cwmonitor.dll is injected into each monitored process by the sandbox application. This is done automatically if the malware starts a new process or if an existing process is infected with malicious code. If a monitored process wants to perform either of these operations, the sandbox application controls this creation/injection as described here. If a new application should be started, the sandbox intercepts directly after creating the process and before executing any single operation of it. Then the monitoring DLL is injected and the newly created process is resumed only if the initialization routine of the DLL has been successfully performed. The infection of an already running process works in an analog way. If a monitored process injects code into an already running one, CWSandbox intercepts this before any single operation of the injected code is allowed to be executed. Then the monitoring DLL is injected and completely initialized. If the initialization of the DLL fails for some reason, the created process or infected thread is terminated automatically without being able to perform any single instruction.

In its initialization routine, the DLL first collects some information about the hosting process, such as username or security context information. Then it sets up an interprocess communication (IPC) object to communicate with the sandbox application. Via this mechanism the collected process information is sent to the sandbox and some configuration settings are received in turn. Then function hooks are installed for all relevant API functions to intercept their calls. The technique used in CWSandbox for realizing the hook functions is called inline code overwriting (see Figure 10.5) and is described in detail later. There are several other approaches, such as Import Address Table (IAT) patching, Export Address Table (EAT) patching, or using proxy DLLs. Every hooking technique has its disadvantages and advantages, but for CWSandbox the currently used one seems to fit best for the moment.

Figure 10.5 Inline Code Overwriting

The inline patching performed in CWSandbox works in the following way: Each Windows API function that is being used in an application is implemented in one of the Windows DLL files like kernel32.dll, advapi32.dll or ntdll.dll. These DLLs are either loaded automatically on process initialization or can be reloaded manually during runtime by one of the functions LoadLibrary, LoadLibraryEx, or LdrLoadDll. No matter how and when the DLL is loaded, at runtime the code of each API function that is called needs to reside in the virtual memory of the calling process. Accordingly, the cwmonitor.dll is able to locate these functions in memory, either by using the API function GetProcAddress or by manually parsing the EAT of the containing Windows DLL module. For catching all calls to the particular function, a JMP instruction is written to its code location as the first operation. This JMP operation is used to reroute the execution to a customized hook function.

As an example, Figure 10.5 shows an extract of the CreateFileA function from kernel32.dll, which is used to open an existing or create a new file. In the upper part of the figure, the original and unmodified version of this function is shown. The first three instructions are displayed in a light gray box, the following ones in a dark gray box. The operations from the light gray one are those which are overwritten by the JMP instruction when the hook is installed. You can see that in the lower part of the figure the first light gray box is completely missing because it has been overwritten. The following bytes from the dark gray box are not modified at all. At hook installation, before the introducing bytes of a function are overwritten, these have to be saved to some other memory location because they might be needed later to perform the original API function. In the lowest box of the figure, you can see that these bytes are copied to a location called SavedStub. Now, each time the CreateFileA function is called, first the JMP operation is executed and control is delegated (1) to the hook function (shown in the middle box of the lower figure part). If the original API should be called from inside the hook function, first the SavedStub is executed (2) and then control is transmitted back (3) to the original API function. In fact, the operations from the dark gray box, which have not been modified, are then executed. This form of API hooking is the most effective and comfortable one that can be done from user mode. But because it is detectable by the malware application, coming releases of CWSandbox will use some form of kernel mode hooking. It is also possible for an application to not use the Windows API functions at all but to perform the relevant system calls directly. This technique is hard and laborious to implement, so this usually is not done in malware.

WARNING

CWSandbox will deliver no false positives, since all contents of a produced analysis report reflect operations that actually have been performed. In contrast, there always will be the risk of false negatives, since only the explicitly monitored operations will be reported. For example, applications are able to perform system calls directly instead of using the Windows API. Nevertheless, because this process is rather complicated and laborious, nearly all malware uses API calls. Unfortunately, you never can be sure that a program is clean, just because you find no malicious operations in the corresponding analysis report.

The <analysis> Section

Each XML report contains the root element <analysis> and its two child element sections, <calltree> and <processes>:

The attributes of the <analysis> element reveal several pieces of information about the particular analysis run, such as the used CWSandbox version, the date and time of the analysis, and the name of the analyzed executable. The <calltree> section covers a call tree of all monitored processes, where a father-child relationship shows that the father process has created or injected into the child process. This is the calltree for our malware sample:

From that output you can see that the initial malware process, which was created from the binary c:82f78a89bde09a71ef99b3cedb991bcc.exe, starts a new process using the command line C:WINDOWSsystem32arman.exe —install c:82f78a89bde09a71ef99b3cedb991bcc.exe. This new file c:windowssystem32arman.exe most probably was created previously by the initial process. Via the call parameters, we can see that it recently has been installed and also where the original malware file is stored. We will see in detail later what is going on inside this first process. Furthermore, you can see the relative start time points of the two processes: The first one is started only a few hundred milliseconds after the analysis starts, and the second one starts roughly after 2 seconds. From the attribute startreason we know that the first process was started by the sandbox itself and that this process has created the second one by calling a Windows API function for creating new processes, such as CreateProcess. Another possible value for this attribute is InjectedCode, which is used for those processes that were not newly created but that were already running and then injected with malicious code.

Analysis of 82f78a89bde09a71ef99b3cedb991bcc.exe

The <processes> section contains one <process> subsection with detailed information for each participating process. From the attributes of the <process> element we learn some more information about the process itself:

The <process> element always contains several sections, which describe all the actions performed during the execution of this process. For each of the possible TNotification objects, a separate section is included, if such notifications have been monitored during the execution. In the following, some interesting extracts from these sections are shown and explained. Notice that sometimes we have skipped several notifications or left out some of their attributes for better readability.

The upper section gives us information about the loaded modules of the malware process. It starts with the particular malware image file, followed by the Windows standard libraries ntdll.dll and kernel32.dll, which are loaded into each Windows user process. From the information that msvcrt.dll is loaded, we can know (or at least assume) that the malware is written in C, since it is the standard runtime library for Microsoft C applications. As the libraries ws2_32.dll and wininet.dll are loaded, we know that the malware is going to use the Winsock library to set up outgoing or incoming TCP/IP connections. Because the examined malware file is a bot application, this is not amazing. From the fact that pstorec.dll is loaded, we can assume that the malware is going to access the Protected Storage, most probably for stealing some authentication data stored within it. In the next analysis section you can see what we already assumed before: The malware copies itself to the Windows system directory using the destination filename arman.exe:

The following outputs show us that a new process is started from this created arman.exe file. We see that the new process should be created without showing the main window: showwindow=“SW_HIDE”. Furthermore, we are informed that the API function CreateProcessA was used for that purpose. The notification <kill_process> approves the fact that the malware process terminates itself after starting its copy from the Windows system directory.

That is all for the first process, and this is exactly what we see for the most of these simple bots: On their first start, they simply copy themselves to the Windows directory, then they execute this new copy and terminate the initial application.

Analysis of Arman.exe

Let’s now take an intensive look at the actions of the second process, which promises more interesting results:

We know that this process is created from the same binary, only from a different location. Therefore, the MD5 and the file size have the same values as for the first one. From the values of the attributes parentindex and startreason we know that the execution was initiated by the first process. The terminationreason tells us that this second process did not terminate itself but would have continued to execute if the sandbox application had not terminated it at the end of the analysis.

Here we can see the probable reason for the second command-line parameter of arman.exe: It is used to inform the application where the original malware file can be found for deleting it. We do not know the regular distribution mechanism of this bot. Since it was collected by a honeypot, we can assume that it is usually copied to a remote host after this host has been exploited. Depending on the exploit used, the malware file would be copied to a temporary or application-dependent directory. The existence of an .exe file in such a folder would raise suspicion or it would be deleted automatically due to some system cleanup routine. Therefore, in nearly all cases we have seen, malware first copies itself to the Windows folder and then deletes the initial source file.

Many applications use named mutexes to ensure that only one instance of them is running. The funny thing about this is that very often you can learn more information about the malware from the name of their mutexes. Sometimes you can determine the malware name in the form the author has intended. Also very often you can recognize the malware family by that, since the mutex does not change from version to version or simply uses the same value plus a newer version number. The mutex of our sample probably reveals its intended name:

The malware opens the registry section

HKLMSOFTWAREMicrosoftWindows CurrentVersionRun, whose entries are loaded automatically on system startup. It checks whether an entry for the arman.exe file already exists. Because this is not the case, a new entry is created. After that, the malware checks whether the entry could be created successfully. This modifies the system startup sequence such that arman.exe will be started automatically each time the machine boots up:

Now for the interesting stuff, namely those operations dealing with network connections. Each analysis report for malware that calls at least one Winsock operation contains a <winsock_section>. This has several subsections: one for all UDP connections, one for the incoming TCP connections, one for the allowed outgoing TCP connections, one for the blocked TCP connections, and a last one for all operations for which the underlying protocol and direction could not be determined because no indicating function was called. These latter sections normally are used for the Windows built-in DNS query functions. In our case the Winsock notifications section starts like this:

We can see that the first DNS query did not deliver an IP address. This is because at the moment of the analysis the domain name sexccc.serveftp.com was not connected to a valid IP. In contrast, the second request for sexccc.ath.cx delivers the IP 208.98.19.3, which is the address of the botnet C&C server, as we see here:

The malware initiates an outgoing TCP connection to 208.98.19.3 on port 6666, which can be established successfully. Furthermore, CWSandbox has detected (by inspecting the traffic) that the protocol used in this connection is IRC. Because of that it was able to retrieve all the protocol-dependent IRC data from the traffic stream:

The last entries of the analysis report reveal that the malware opens a backdoor on TCP port 1910, but it is not being connected during the analysis run:

That is it for the second process of this malware analysis. We have seen the most essential operations of such simple bot applications: After it has copied itself to the Windows directory and started, this new instance deletes the original malware file, sets up an autostart registry entry, opens a backdoor, resolves the domain name of its C&C server, connects to this server, and joins the correct channel. Because we did not let the channel topic pass to the malware receiving function, its functionality stops there. An extract of the transformed HTML report of this analysis appears in Table 10.1, showing the analysis only for the second process. Again, some unimportant parts have been removed to reduce its length.

Table 10.1 Extract of a Malware Analysis

How Does the Bot Install?

If we want to check whether a given host already is infected with a particular malware or if we want to clean a host from that parasite, we need information about the locations where the malware installs its files and about the mechanisms it uses to automatically execute at system startup. Finding the answer to the latter question normally also solves the first one, since any autostart mechanism needs the information where to find the process to start. Windows offers many different possibilities to instruct the system to execute a specific application automatically on startup. The great tool AutoRuns^2. shows most of them. Though there are many ways, nearly all malware either uses one of the run sections of the registry or installs a Windows Service application or kernel driver. However, the malware needs to modify a registry setting to set up any form of autostart mechanism. CWSandbox reports all accesses to the registry, so you easily can filter out those accesses. As we already saw, registry accesses are contained in the <registry_section> and the relevant entries are <create_key> and <set_value>. Here are some examples of malware that installs as an autostart process, using different registry sections:

As mentioned, some bots do not install as normal programs but as Windows Service applications. In that case, beside the changes to the registry, the analysis report will contain lines like these:

A very powerful technique for infecting a system is to install a kernel device driver. Once loaded, this driver executes in kernel mode and undergoes no more security restrictions. Because it has full control over all running kernel and user mode processes, it could be very hard to detect such malware. In most cases a kernel driver implements rootkit functions to hide itself and/or to provide system backdoors. CWSandbox can be configured to forbid the installation of kernel drivers completely or to fool the installer by returning a successful error code while suppressing the real installation. In any case, the attempt to load a kernel driver can be detected by the attribute servicetype=“SERVICE_KERNEL_DRIVER” of a <create_service> notification. The analysis report section of the installing process would look like this:

Ultimately, loading of the driver is performed by the Service Control Manager (SCM). This process is hooked automatically and, in its report section, an entry like the following will be given. From the attribute behavior=“SimulateOK” we can see that CWSandbox was configured to only simulate this call and to suppress the real loading.

Finding Out How New Hosts Are Infected

To find new infectable machines, a lot of malware probes remote hosts for known vulnerabilities. There are several strategies for determining which hosts to probe: Some malware generate random IPs, others scan complete (also randomly chosen) IP ranges. There are also applications that use predefined internal or external target lists. Internal lists are contained inside the malware binary; external ones need to be reloaded from one or multiple possible locations from the Internet. After one potential target has been determined, it is probed against one or several vulnerabilities. Since the possible exploits all work in different ways and use several different target services, it is hard to give a standard procedure of how to detect their usage from an analysis report, but some clues will always be there. In any case, a connection to a remote host needs to be established on one or more of the specific possible ports. For some ports, any attempt to establish a connection is a promising hint of an exploitation attempt. For example, although they are really old, malware still searches for known security leaks in the LSASS and the DCOM RPC Service is searched. Therefore, often you will see outgoing connections on TCP ports 135, 139 and 445. Because these ports normally are blocked by CWSandbox by default, the connection establishment attempts will be included in the <connections_outgoing_blocked>. The analysis report would include some outputs like these:

To get more information about these attempts, you should not forbid connections to those ports. Furthermore, you should configure the CWSandbox such that all communication data is logged. Even if this logging is not enabled, the .cab file will contain the content of all TCP packets that are sent or received. By examining this data, you can learn what the malware has intended by these connections.

Often you will also be able to infer the host determination strategy from the reports, especially if you find complete ranges of target IPs that are trying to be connected or pinged, as in this case:

How Does the Bot Protect the Local Host and Itself?

A lot of bots try to protect a new infected host against further exploitation by others. Of course, this is not being done for charitable reasons, rather for the selfish reason of trying to ensue that that no one else can take control of the host. This protection is accomplished by fixing known security leaks or by completely disabling Windows Services that can be exploited. Mostly this is done by removing existing Windows shares. In the following you can see how first all existing shares are enumerated (enum_share) and then deleted (delete_share):

To hide and protect its own existence, most malware performs the following actions on a newly infected system: It searches for known antivirus and security products and stops them or modifies their configuration. When malware tries to detect such running security applications, it normally searches for the commonly known names of their corresponding services, processes, or windows. This can be done by either enumerating all the existing objects and then comparing each found one with the entries of an internal list or by using functions for opening a handle to a named object, providing the known name as a parameter. In the first case, you will find the actions <enum_services/>, <enum_processes/>, or <enum_window/> in your report. In the second case, long lists of actions with the known object names as parameters will appear in the analysis. The following example shows how malware looks for services of antivirus software:

You can see that the bot loops through a long list (the original output has over 50 tests) of hardwired service names. Because most of those applications are not installed on our test system, nothing more is done than just querying for those services. The last actions show us what happens if such a security service could be found: The malware stops and disables the Windows SharedAccess service, which implements the Application Layer Gateway and is the low-level service for controlling network connections. Normally this one is used for the Windows Firewall and for Internet Connection Sharing (ICS), but it also runs if neither of them is enabled. By shutting down this service, the Windows Firewall becomes inactive, but other unforeseen problems could occur.

Some malware does not search for the services. Rather it tries to kill the corresponding processes. In our example, the Windows XP command taskkill is used, for which the parameter /im imagename specifies the filename of the process and /f forces its termination. Again, we present only a short extract of the real analysis report output:

As a further example, we present malware that searches for the main windows of known antivirus scanners. We do not know what would happen if a searched window would be found, but this is not very hard to guess:

Some malware tries to find running debuggers and other activity-monitoring tools, which can be used for malware code analysis, by trying to open their devices. In our example, these are SICE and NTICE (NT version) for the Softice debugger and FileMon^3. and RegMon⁴, the famous tools from www.sysinternals.com. Again, we do not know what would happen if one of the queried devices existed. Most probably the application would crash the system or simply not perform any of its malicious operations in order to not reveal anything.

Sometimes malware does not try to stop found security services but instead to modify their configuration such that the malware is not detected or is enabled to circumvent the security mechanisms. For the Windows Firewall this could be done using the netsh command or by directly modifying the corresponding registry key:

Determining How and Which C&C Servers Are Contacted

Most bots use a central C&C server for communicating with their botherder, and normally they use the standard IRC protocol for that purpose. CWSandbox detects such communication and reacts in two ways: First, all the interesting connection information is extracted from the traffic, and second, all received commands are deleted so that they never arrive at the malware’s receiving function. Some bots use slight modifications of the IRC protocol, and some modified IRC servers do not answer with RFC conforming messages or do not answer at all until the IRC client has authenticated completely. CWSandbox tries to recognize these custom protocols as well, but it is obvious that this is only possible within a certain range of modifications. Often the communications of these modified IRC servers can be read manually if the traffic-logging option is used. If an IRC communication can be detected successfully, an output like the following will be contained in the analysis report:

We see that a TCP connection was established to the host 203.115.204.58 on port 7000. Although port 7000 is not the most well known port associated with IRC (that would be port 6667), it is a common choice, along with 6665 and 6666. After authenticating itself with the username SIS-21920206516 and nickname SIS-21920206516, the client joins the channel #n using the password .n. Some IRC servers are additionally secured with a server password; in that case the value used for that would also be included in the report. Normally after joining an IRC channel, the channel topic is transmitted automatically to the client. In the case of bots, this topic is mostly used to send an initial command to the client, in this case .asc asn1smbnt 200 5 0 -b –r (see Chapter 4 for further description of commonly used bot commands). The last section of this chapter contains detailed information about the results on IRC connections, which we were able to retrieve by analyzing over 1,800 found bot samples.

How Does the Bot Get Binary Updates?

Often the first thing malware does is to retrieve new files or instructions from its operator. This is done to get code updates or actualized configuration data, since the running malware might be an outdated version or might contain the addresses of already shutdown machines. In the case of bots, this configuration data is most often received via their C&C channels, but there are also variants that try to get this data from hardwired URLs. In any case, you will see an outgoing TCP connection and/or DNS requests as evidence of such an update request. If you are lucky, the reloading of code or data is done via HTTP or FTP. In that case the report would contain outputs like this:

As you can see, there are several .exe files downloaded from the same host, 194.187.45.55. In fact, for this particular malware (NOD32 calls it Win32/TrojanDownloader.Adload.NAN Trojaner), a total of 10 (!) different .exe files are reloaded. After the malware has downloaded them to the local disk, they are executed:

Sometimes the malware does not use one of the standard Web protocols to reload data. Then it is harder to determine the fact that something executable or configuration data is retrieved. Again, the CWSandbox feature to log all communication data will help in this case. In any event, you should use the option STORE_CREATED_FILES, by which you will get a copy of each created file, no matter if it is an executable or data file and if it was downloaded, copied, or created completely new. All these created files can be found in the corresponding created_files subfolder inside the .cab archive. Another helpful option is FAIL_ON_ALL_DNS_REQUESTS. When you enable this one, each DNS request will fail and the malware will disclose all its internally stored remote host contact addresses.

What Malicious Operations Are Performed?

The possible malicious operations a bot could perform on the infected host and remote hosts are limited only by the imagination of its developer. It is obvious that the operations mentioned in the preceding sections are malicious as well. However, these operations are only intended to infect and secure a system. They are not intended to do harm. Once the infection process with all its side actions is finished, the bot is free to pursue its real purpose: using the hosting system to perform illegal and criminal operations, directed by its operator. Some examples of these operations are:

In this section we present hints for those operations that can be found in the analysis reports. We start with the detection of mail delivery. In general, an SMTP mail delivery looks like this in the report:

From this output we can learn the SMTP server (68.142.229.41), the used authentication data (username: [email protected], password: vi3tridaz) and the recipient’s mail address (<[email protected]>). Furthermore, we can read the mail body in plain text. Without doubt this is a notification mail, which is used to inform the malware operator about a new infected host. As we have seen, CWSandbox recognizes SMTP traffic and extracts all the relevant data from it. Furthermore, it can be configured to trick the malware by exchanging informational data with the SMTP server but only pretending to send the e-mail. The attribute behavior=“Simulate_And_Log” enables this feature during the malwares execution. There is another feature that constricts the number of allowed SMTP send operations to limit the report size for mass-mailing malware.

Huge botnets often are used to perform DDoS attacks. Commonly known attacks are TCP Syn floods, UDP floods, and ICMP floods. If you find a lot of notifications for such connections in your report that all use the same target IP address, this is an assured evidence of such an attack (or sometimes only of the foolishness of the malware’s developer). The relevant entries could look like the following and would have to occur in a large number:

An analysis report normally contains only one output line for each type of received notification, no matter how often this one was received. Usually a DOS attack is performed using a lot of parallel threads that use a lot of different sockets, so one notification will be reported for each different socket. If, due to bad implementation, the same socket is always used, only one notification would be reported. Therefore, it might be necessary to use the parameter SHOW_QUANTITIES_IN_REPORT. If this attribute is enabled, the quantities for each contained notification are included into the analysis report as well. In that case a (badly implemented) DOS attack would look like one of these:

A lot of malware installs backdoors on the infected host such that its operator (or whomever) is able to connect to this host remotely. The power of such backdoors ranges from simply enabling remote access to the local file system or giving a simple command shell to the attacker to offering a complete graphical interface. Remote access to the file system can easily be set up by creating a new share:

Malware could also try to escalate the security privileges of existing users such that a regular login can be used for much more powerful operations than it was intended to:

Real backdoors bind themselves to a network port and implement complete servers. Evidence for such activity can be found in the section <connections_listening>:

Some malware use the integrated Terminalserver of Windows to allow remote access. They modify the relevant registry settings to allow remote connections in general. In that case, you will find some lines in the report that look like these:

Changing the network routes or hijacking the DNS resolving process is also part of the performed evil operations. That way, the malware either completely blocks accesses to hosts that provide updates for security software or the operating system, or it routes all those requests to infected hosts. This can be performed by modifying the hosts file, which resides in the system32driversetclog directory in the Windows folder. An attempt to do so can be detected by locating an <open_file> action, which refers to that file and requests WRITE access. Some malware completely reroutes all DNS requests to a special host, which is enabled to return different IP addresses dynamically. Such a modification normally takes place in two steps: First the network configuration for the network adapter is modified by changing the relevant registry settings; then the network interface is advised to refresh its configuration. Of course, the second step is only optional. If it is not performed, the modified network configuration is activated on next system startup. The tracks of these actions will look like this:

Finally, a lot of malware tries to steal sensitive data from the local host. This can be done by installing a keylogger or by directly accessing the places where such data is stored. The explicit process of keylogging is not detected by current version of CWSandbox and will be added as a new feature in coming releases. Nevertheless, because some files need to be installed as an autostart application or as a service or driver for that purpose, this will become obvious by examining the report. If the malware tries to read the data directly from its storage location, this could happen in several ways, depending on that location. Examples for retrieving dialup network configuration data and contents of address books for several mail clients are these (note that some malware uses <open_file> and other malware uses <find_file> or even <get_file_attributes> to check for the existence of such files):

In Windows 2000 the Protected Storage Service was introduced. This is a service for storing sensitive data such as passwords or private keys in a protected and encrypted way. It is used to save the passwords that have been entered in Internet Explorer or Microsoft Outlook and Outlook Express, but it also can be used by any other user application to protect its sensitive data. For that reason it is an open treasure chest for each malicious application. CWSandbox detects all accesses to this Protected Storage and reports them in a <pstorage_section>. An example of such a report follows: