Optimizing business risks associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise is a key component in an enterprise’s ability to create value. This will allow the enterprise to reach the main objectives and it will most likely result in expansion.
Optimizing IT risks not only requires key practices of the company governance, such as the definition of risk appetite and policies, but also a continuous management process to identify, analyze, evaluate and treat IT risks covering the whole enterprise end-to-end.
However, a frequent issue is that organizations are limited in essential resources for IT risk management—for example, staff-related gaps (quantity and skills), lack of automated tools, restricted budget, incomplete inventories of IT assets and absence of historical data of loss events related with IT risks.
Although all these limitations are solvable, the solution may not come up immediately. As a result, an organization would still be exposed to unidentified IT risk scenarios that could overcome the established appetite or even the capacity to resist losses, compromising the sustainability of the company.
Therefore, the priority is to start as soon as possible by defining valid criteria to identify the IT risk scenarios and determine an optimized scope for the IT risk management process depending on the resources and capabilities available. To start the primary identification of the risk scenarios, the following eight steps are suggested:
Consider internationally recognized standards and guidance, such as:
MAGERIT—includes numerous threats for each type of assets/resources with their corresponding safeguards
Additional documents from ISACA on topics such as big data, cloud computing, vendor management and social media
Analyze business objectives of the organization to identify IT-related risks that could jeopardize its success.
Collect the know-how of the experts within the organization scope (e.g., CISO, DBA and CTO) to engage them in the process of IT risk management.
Assess news of vulnerabilities of the IT assets/resources adopted by the company.
Apply “reverse engineering” over controls required by the ongoing regulations to infer/detect possible threats from those controls.
Analyze the events of operational risk loss database to detect materialized IT risk scenarios.
Once you have collected a considerable universe of scenarios, the organization´s possible scope of analysis should be formally defined. This will require a formal approval from the relevant bodies (e.g., risk committee).
Approved register of IT risk scenarios should be enriched periodically, depending on: what actually happened about threats, updates of standards, new technological developments and improvement of the capacity level of the facilitators required for risk management.
Once the registry of risk scenarios is formally approved, the universe of assets/IT resources to analyze could be defined assigning priority to the most critical ones in terms of their support for the business processes. After this, the phase of IT risk analysis within the company could already be started with the most appropriate scope.
Unit 42 has uncovered a new campaign from the CozyDuke threat actors, aka CozyCar [1], leveraging malware that appears to be related to the Seaduke malware described earlier this week by Symantec. [2]
This campaign, which began on July 7, 2015, appears to be targeted at government organizations and think-tanks located in democratic countries [3], and utilizes compromised, legitimate websites for spear phishing and command and control activity.
Unit 42 discovered the extent of this attack using the Palo Alto Networks AutoFocus service, which allows analysts to quickly find correlations among malware samples analyzed by WildFire. All files referenced throughout the analysis are contained in the IOC table at the end of this blog.
Figure 1. Sample decoy presented to a user while downloader runs. Researchers discovered 6 unique decoys in use with similar lures targeting pro-democratic organizations.
Malware Details
The Initial Droppers: Decoy and Downloader
The current CozyCar campaign includes spear phishing emails that deliver the payload from either by a link to a .zip file on a compromised website or by direct delivery as an attachment to the phish.
At the time of our analysis, the phishing link was no longer active. When a user opens the attached file a poorly detected executable file [VT 1/54] is extracted. The initial dropper is a self-extracting archive (SFX). Upon execution, this executable file will drop two files in the %TEMP% directory: a decoy .wav file and the secondary dropper.
The CozyDuke group commonly uses legitimate media files to trick users. In reality, while the media — a .wav file with a female voice claiming to be a reporter looking for commentary — is played, the secondary dropper executes in the background. The secondary dropper requests a .swf file using SSL as illustrated in the HTTP traffic below.
As of this writing, the domain extranet.qualityplanning[.]com resolved to 64.244.34[.]200.
The secondary dropper then cleans up after itself with a simple vbs script (md5:0d132ee171768dc30d14590ed2dbadd1) that leaves only the decoy multimedia file behind. But what did the dropper do with the .swf file?
The Real Payload
While the player.swf file downloaded by the second stage dropper does contain media, it is, again, a decoy.
The actual flash component of this file is roughly 16kb, leaving approximately 200kb of the file unaccounted for. The second stage dropper contains decoding routines that decode the arbitrary binary data into an executable file.
The executable file is dropped in %appdata%/Roaming and appears to try and emulate legitimate software names: TimbuktuDaemon, SearchIndexer, RtkAudioService64, dirmngr, o2flash, and usbrefs64. This file was not observed on VirusTotal until July 9 and has extremely low detection rates [VT: 3/54].
It appears that the authors of this particular iteration of the CozyCar group’s malware internally call it “miniDionis” according to pdb strings left in the binary (c:\BastionSolution\Shells\Projects\miniDionis4\miniDionis\obj\Release\miniDionis.pdb). It also appears to be an iteration on the “forkmeimfamous” aka Seaduke malware analyzed by Unit 42 in a previous blog [4].
The malware stores 2 files in the %temp% directory: a configuration file and a secondary dll. The configuration file’s name matches the final characters of the bot_id that is contained within as per the sample below:
Figure 2. .net disassembly of the primary payload shows the author’s name for the project, “miniDionis”.
Analysis of the secondary dll file (name matches [A-Z0-9]{1}\.tmp) indicates that its primary function is to serve as a cleanup mechanism for the dropped binary. This is likely an attempt to thwart forensic investigations.
Further examination of memory dumps taken following the execution of miniDionis reveals some clues into the beaconing activity exhibited. The malware stores configuration values in memory as key:value pairs:
“user_agent”:“Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko”
}
The configuration of miniDionis is a JSON blob with several important sections, which are described in the table below:
Key
Functionality
autoload_settings
dictionary containing values which control the malware’s behavior when executing via persistence mechanisms
app_name
subkey of autload_settings, defines the value to be used as the malware’s name
delete_after
subkey of autload_settings, boolean value that defines whether the executable is to be deleted after exectuing
exe_name
subkey of autload_settings, defines the value to be used as the exectuable file’s name
cookie_name
defines the value in which cookie data will be stored
enable_autoload
boolean value which controls persistence
first_run_delay
time in seconds to delay initial beaconing after execution
host_scripts
dictionary containing the location of C2s
key_id
equivalent to the bot_id; also used to derive values in C2 comms
keys
dictionary containing an AES key and AES IV
aes
aes value
aes_iv
aes_iv
user_agent
HTTP User-Agent header to be used when communicating with a C2
Table 1. ‘miniDionis’ configuration keys
Network Communications
The functional payload of this Trojan starts by creating a Mutex by splitting the “bot_id” value in the configuration on the hyphen (“-“) and using the second portion of the split string (specifically, “01MRLXW” in the case of this configuration).
From a functionality standpoint, the Trojan uses the concept of tasks that are processed and completed using a pool of threads. To obtain tasks, the Trojan will issue an HTTPS request to the C2 server (“host_scripts” in the configuration) that resembles the following example beacon:
The Trojan manually creates the cookie in this HTTP request. The cookie contains ciphertext that the Trojan creates based on the “bot_id” in the JSON configuration. The Trojan compresses the “bot_id” string using zlib and then encrypts it using the RC4 algorithm using a generated key. The generated key is a SHA1 hash of two randomly created strings: the first of which is between 2 and 8 bytes long and the second is between 1 and 7 characters in length.
The ciphertext of the “bot_id” is then based64 encoded and finally the appended to the “cookie_name” (“SSID=”) in the configuration and sent within the HTTP request to the C2 server.
Unit 42 did not observe the first random string (between 2 and 8 characters in length) sent to the C2 in the first beacon, which would be required by the C2 to reproduce the exact SHA1 hash used as a key to generate the ciphertext in the cookie. Upon further examination we believe that the C2 will not be able to decrypt the cookie in the first beacon. Instead, the C2 will respond to the first beacon with data that the Trojan will use to extract a string, using a function named TrExtractKey seen in Figure 3, to replace the first random string used to generate the SHA1 hash.
Once the C2 and Trojan have synchronized using this string, the C2 will be able to decrypt subsequent network beacons because the Trojan includes the random string between 1 and 7 characters that makes up the second half of the SHA1 hash within the cookie field before the ciphertext.
Figure 3. TrExtractKey Function Used by MiniDionis to Obtain String from C2 to Synchronize Keys
The C2 communications, and several of the commands we will discuss in this blog, include a rather interesting technique to manually handle HTTP redirection, such as the HTTP 301 Moved Permanently and HTTP 302 Found status codes.
The technique used to handle these redirections involves checking for the presence of a “Location” field within the HTTP headers of the server response, then using regular expressions to parse the HTML within server response to find the appropriate URL.
The code contains three regular expressions to parse the HTML to locate the URL, the first of which is “<a.*?>.*?</a>” that locates all of the tags associated with link within the HTML.
The second regular expression of “onclick=\”Accept();\”” locates only links within the HTML with a specific “onclick” action.
The last regular expression of “href\\s*=\\s*(?:[\”‘](?<1>[^\”‘]*)[\”‘]|(?<1>\\S+))” to obtain the correct URL to interact with as the C2 server.
Command handler
Once the C2 and Trojan have synchronized and can decrypt their network communications the C2 server will begin responding to beacons from the Trojan with JSON blobs.
Unit 42 has not received any JSON blobs from an active C2 server, but based on static analysis of the Trojan determined the JSON would look as follows:
The Trojan takes this JSON blob and adds each task in the list into a pool for processing. Separate worker threads access this pool of tasks and process the commands and perform the necessary activities.
Unit 42 analyzed the Trojan’s command handler and found several commands, as seen in Table 2, which allows the threat actors to carry out a full range of activities on the system.
Command
Sub-Command
Description
cmd
Checks for subcommands within the ‘data’ section, if not it attempts to run the ‘data’ using “cmd /c <data>’
cd
Changes directory
pwd
Returns current working directory
cdt
Change to temporary directory
:set_update_interval
Sets the timeout between network beacons
:proxy
Configures proxy information
:exit
Exits the Trojan and responds to the C2 server with “Bye!”
:wget
Downloads a file from a specified URL
:uploadto
Uploads a file to a specified URL
exec
Launches an application and waits for it to exit
execw
Launches an applications and does not wait for it to exit
upl
Uploads or downloads from a list of files to or from the C2 server
srv
Sends system information from the compromised system to the C2 server
Table 2. Available Commands within MiniDionis’ Command Handler
Conclusion
The actors behind the CozyDuke framework are highly sophisticated, motivated, and have become increasingly bold in their campaigns.
We recommend that other security practitioners review the included Indicators of Compromise (IoCs) to ensure they have not been targets in this campaign, and add the appropriate security controls to prevent future attacks.
This group is reliant on social engineering, and thus, user education remains of paramount importance.
Palo Alto Networks customers using WildFire were protected from this campaign. All known elements of this campaign have been accurately identified by WildFire as malicious.
Earlier this week Symantec released a blog post detailing a new Trojan used by the ‘Duke’ family of malware. Within this blog post, a payload containing a function named ‘forkmeiamfamous’ was mentioned. While performing some research online, Unit 42 was able to identify the following sample, which is being labeled as ‘Trojan.Win32.Seadask’ by a number of anti-virus companies.
PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed
Our analysis has turned up more technical details and indicators on the malware itself that aren’t mentioned in Symantec’s post. Here are some of our observations:
First Layer of Obfuscation
Once the UPX packer is removed from the malware sample, it becomes quickly apparent that we’re dealing with a sample compiled using PyInstaller. This program allows an individual to write a program using the Python scripting language and convert it into an executable for the Microsoft Windows, Linux, Mac OSX, Solaris, or AIX platform. The following subset of strings that were found within the UPX-unpacked binary confirms our suspicions.
Because the sample was written in Python originally, we’re able to extract the underlying code. A tool such as ‘PyInstaller Extractor’ can be used to extract the underlying pyc files present within the binary.
Figure 1. Extracted Python files from Seaduke
We can then use a tool such as uncompyle2 to convert the Python byte-code into the original source code. Once this process is completed, we quickly realize that the underlying Python code has been obfuscated.
Figure 2. Obfuscated Python code
Second Layer of Obfuscation
Tracing through the obfuscated code, we identify an ‘exec(ZxkBDKLakV)’ statement, which will presumably execute some Python code. Tracing further, we discover that this string is generated via appending a number of strings to the ‘ZxkBDKLakV’ variable. Finally, we find that after this string is created, it is base64-decoded and subsequently decompressed using the ZLIB library.
Figure 3. Second layer of obfuscation identified
The following simple Python code can be used to circumvent this layer of obfuscation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
import sys,re,base64,zlib
iflen(sys.argv)!=2:
print“Usage: python %s [file]”%__file__
sys.exit(1)
f=open(sys.argv[1],‘rb’)
fdata=f.read()
f.close()
# Set this accordingly
variable=“ZxkBDKLakV”
regex=“%s \+= ([a-zA-Z0-9]+)\n”%variable
out=“”
forxinre.findall(regex,fdata):
regex2=“%s = \”([a-zA-Z0-9\+\/]+)\””%x
forx1 inre.findall(regex2,fdata):
out+=x1
o=base64.b64decode(out)
print zlib.decompress(o)
The remaining Python code still appears to be obfuscated, however, overall functionality can be identified.
Final Payload
As we can see below, almost all variable names and class names have been obfuscated using long unique strings.
Figure 4. Obfuscation discovered in final payload
Using a little brainpower and search/replace, we can begin identifying and renaming functionality within the malware. A cleaned up copy of this code can be found on GitHub. One of the first things we notice is a large blob of base64-encoded data, which is additionally decompressed using ZLIB. Once we decode and decompress this data, we are rewarded with a JSON object containing configuration data for this malware:
This configuration object provides a number of clues and indicators about the malware itself. After this data is identified, we begin tracing execution of the malware from the beginning. When the malware is initially run, it will determine on which operating system it is running. Should it be running on a non-Windows system, we see a call to the infamous ‘forkmeiamfamous’ method. This method is responsible for configuring a number of Unix-specific settings, and forking the process.
Figure 6. Main execution of malware
Continuing along, we discover that this malware has the ability to persist using one of the following techniques:
Persistence via PowerShell
Persistence via the Run registry key
Persistence via a .lnk file stored in the Startup directory
The malware copies itself to a file name referenced in the JSON configuration.
Figure 7. Persistence techniques
After the malware installs itself, it begins making network requests. All network communications are performed over HTTP for this particular sample; however, it appears to support HTTPS as well. When the malware makes the initial outbound connection, a specific Cookie value is used.
Figure 8. Initial HTTP request made
In actuality, this Cookie value contains encrypted data. The base64-encoded data is parsed from the Cookie value (padding is added as necessary).
The underlying data has the following characteristics.
Figure 9. Cookie data structure
XORing the first single character against the second character identifies the length of the random string. Using the above example, we get the following.
First Character : ‘\x10′
Second Character : ‘\x12′
String Length (16 ^ 18) : 2
Random String : ‘ae’
Encrypted Data : ‘9J\x8a\xa3|\x9d\x85\x9e\x8c\xa8{R\x90\xf2p\xf9\\\xacc\x04q1′
Finally, the encrypted data is encrypted using the RC4 algorithm. The key is generated by concatenating the previously used random string with the new one, and taking the SHA1 hash of this data.
This same key is used to decrypt any response data provided by the server. The server attempts to mimic a HTML page and provides base64-encoded data within the response, as shown below.
Figure 10. Server response
Data found within tags in the HTML response is joined together and the white space is removed. This data is then base64-decoded with additional characters (‘-_’) prior to being decrypted via RC4 using the previously discussed key. After decryption occurs, the previous random string used in key generation is updated with the random string. In doing so, the attackers have ensured that no individual HTTP session can be decrypted without seeing the previous session. If the decrypted data does not produce proper JSON data, Seaduke will discard it and enter a sleep cycle.
Otherwise, this JSON data will be parsed for commands. The following commands have been identified in Seaduke.
Command
Description
cd
Change working directory to one specified
pwd
Return present working directory
cdt
Change working directory to %TEMP%
autoload
Install malware in specified location
migrate
Migrate processes
clone_time
Clone file timestamp information
download
Download file
execw
Execute command
get
Get information about a file
upload
Upload file to specified URL
b64encode
Base64-encode file data and return result
eval
Execute Python code
set_update_interval
Update sleep timer between main network requests
self_exit
Terminate malware
seppuku
Terminate and uninstall malware
In order for the ‘self_exit’ or ‘seppuku’ commands to properly execute, the attackers must supply a secondary argument of ‘YESIAMSURE’.
Conclusion
Overall, Seaduke is quite sophisticated. While written in Python, the malware employs a number of interesting techniques for encrypting data over the network and persisting on the victim machine. WildFire customers are protected against this threat. Additionally, Palo Alto Networks properly categorizes the URL used by Seaduke as malicious.
Enterprises, governments and service providers are struggling to secure their networks against a growing number of sophisticated attacks. A multitude of security functions such as IPS, DLP, AV, URL filtering, strung across corporate networks and on endpoints (including mobile devices) is the traditional approach. But in practice, this isn’t an integrated strategy – this is a conga line of security deployments that are nearly impossible to manage, unable to communicate with each other and, let’s be honest, creating a growing number of security holes as a result of complexity.
Let’s look at why this is so and why other consolidative approaches, such as unified threat management (UTM), aren’t solving the core problem.
The security holes mentioned above are a direct result of disparate security technologies not communicating with each other, multiple security rule bases, lots of manual management, and other management challenges.
These conga lines form from reactive security thinking. Stop me if you’ve heard any of these before:
“The most common ports used in our company are the following – let’s block the other ports with a firewall.”
“Web-based attacks are most frequent – we should deploy a proxy.”
“The company next door had a data breach – we need a DLP solution.”
Security deployed this way is not only incredibly difficult to manage and maintain with multiple security rule-bases, but also creates enormous strains on network resources because every individual deployment conducts its analysis without sharing information with another. It is very hard to reconcile policies to find security holes that may be present in the network – but it’s these holes that are leaving organizations open to attack.
What we commonly think of as “unified threat management,” or UTM, doesn’t solve the problem because UTM is really conga line in disguise. While offering streamlined deployment within a single piece of hardware, the basic concept of the technology conga line still holds true with the same inefficient in-series analysis of traffic, with individual defenses activated based on needs but without interacting with each other.
Truth be told, today’s and tomorrow’s cybersecurity starts with complete application control regardless of port. Cybercriminals are utilizing applications as the vehicles to infiltrate networks, and once on the network, common applications such as netbios, ftp, webdav are used to steal your data. They also employ port-hopping capabilities, leaving standard, port-based controls found in traditional firewalls useless.
Palo Alto Networks Security Platform provides powerful security by identifying all applications, regardless of port, checking all content contained, and connecting these applications to users by names. These capabilities provide valuable context that can be used to exert more granular control over the network and prevent threat activity.
We determine the application irrespective of port, the content within the application, whether it is malicious or not and the user in a single pass, eliminating the need for the conga-line approach to security, whether UTM or not. Technologies can learn from each other due to the close integration, enabling more powerful, granular control over the entire network.
The fact that all of this can be done with a single security rule base further reduces policy complexity and the risk for errors (holes) in that security rule base. Palo Alto Networks allows you to strike an appropriate balance between blocking all traffic and allowing all traffic with firewall policies that use business-relevant elements, described above, as a more meaningful way to control network access and grow your business. You can build firewall policies that are based on application/application feature, users and groups, and content, as opposed to port, protocol and IP address.
Learn more about Palo Alto Networks next-generation security platform and our single pass architecture here.
