Category: #IT/CYBER/TECHNOLOGY

The challenge of APTs targeting Industrial Control Systems continues to evolve and escalate.  It is true that a number of the ICS-specific attacks in the years immediately following Stuxnet (e.g. Duqu, Flame, Shamoon) are not so interesting as derivatives of Stuxnet or in how they utilize more general, IT-centric exploits.  However, 2014 was a milestone year in that we saw two APTs that uniquely expanded on the initial methods used by Stuxnet:  Energetic Bear/Dragonfly (Havex) and Sandworm (Black Energy campaign). 

The most recent campaigns from these APTs have upped the bar in terms of “craftiness” with techniques combining more sophisticated social engineering, ICS protocol exploits, and exploits to automation-specific HMI software.  In the case of the APT attack to the German steel mill, also disclosed in 2014, we are reminded of potentially destructive cyberphysical effects that could occur when ICS systems are breached. (In this case, the destruction of a blast furnace.)

The “people, process, technology” discussion around security is very relevant here.  As always, the human element involved in social engineering is a particularly difficult challenge.  Most advanced attacks will employ some form of social engineering.  Education goes a long way in terms of mitigating the issue but motivated attackers will always find a way to trick a targeted individual into opening the malicious email attachment, loading and infected file on the free USB thumb drive, or visiting a seemingly innocent website housing drive-by malware, unknowingly initiating the APT attack.

To add, on the technology front, these attacks by well resourced actors like nation states and cybercriminal organizations typically use both known attacks and zero-day exploits and/or malware which conventional methods cannot detect nor prevent.  Combine social engineering and zero days, and you have a very effective methodology for establishing a beachhead for an ICS attack whether it is first into the IT side of the house or directly in the OT side.

Is APT Prevention a Holy Grail?

Many organizations assume they will breached, and think preventing advanced attacks is not feasible.  Hence, they try their best to isolate the SCADA/ICS network and stop known threats.  Capabilities to stop more advanced threats are typically non-existent or just starting to be deployed by some more forward-thinking organizations. Considering the high costs to organizations that are breached and the people and safety concerns associated with cyberphysical processes going awry in critical infrastructure, an inability to stop advanced threats should be something asset owners take seriously and address.

At Palo Alto Networks we believe that preventing attacks from APTs is possible.  No security solution is ever 100% effective, but we have a strong platform that makes it extremely hard for the bad guys, even the very sophisticated ones behind APTs, to successfully implement their attacks.  It is based on a platform approach that combines the power of the next-generation firewall, our threat intelligence cloud and advanced endpoint protection to prevent attacks and provide increased automation of security functions while providing correlated threat intelligence and logs.

Get up to Speed on APTs in ICS

We take a closer look at APTs in ICS and methods for protecting your organization against them using a platform approach in an upcoming webinar co-hosted by Mike Assante, Director of ICS at the SANS Institute, and myself.  Join us on Wednesday, July 22, to learn more about:

• The evolution of APTs in ICS from the original Stuxnet to the recent Black Energy
• The model of the APT attack lifecycle with a focus on the different phases and associated “kill points” which are critical to understand from a defensive standpoint
• Best practices and technologies that help organizations better protect themselves from such attacks, particularly those using zero-day techniques

Register for the webinar at this link.  Thanks, and we hope to see you there!

Del Rodillas

[Palo Alto Networks Blog]

Executive Summary

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:

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.

IOCs

domain	ff.whitebirchpaper[.]com
domain	visionresearch[.]com
domain	betawebservices.ntnonline[.]com
domain	staff.shasta[.]com
hostname	extranet.qualityplanning[.]com
hostname	secure.hgl[.]com
hostname	illuminatistudios[.]net
ip	103.254.16.168
ip	103.226.132.7
ip	122.228.193.115
md5	01039a95e0a14767784acc8f07035935
md5	0f9534b63cb7af1e3aa34839d7d6e632
md5	2e64131c0426a18c1c363ec69ae6b5f2
md5	70f5574e4e7ad360f4f5c2117a7a1ca7
md5	1dd593ad084e1526c8facce834b0e124
md5	42ffc84c6381a18b1f6d000b94c74b09
md5	719cf63a3922953ceaca6fb4dbed6584
md5	f415470b9f0edc1298b1f6ae75dfaf31
md5	ca770a4c9881afcd610aad30aa53f651
md5	24083e6186bc773cd9c2e70a49309763
md5	b0a9a175e2407352214b2d005253bc0c
md5	b55628a605a5dfb5005c44220ae03b8a
md5	26bd36cc57e30656363ca89910579f63
md5	a9c045c401afb9766e2ca838dc6f47a4
md5	f8cb10b2ee8af6c5555e9cf3701b845f
md5	c8b49b42e6ebb6b977ce7001b6bd96c8
md5	030da7510113c28ee68df8a19c643bb0
md5	e07ef8ffe965ec8b72041ddf9527cac4
md5	4cbd9a0832dcf23867b092de37c10d9d
md5	3a04a5d7ed785daa16f4ebfd3acf0867
md5	9018fa0826f237342471895f315dbf39
md5	98613ecb3afde5fc48ca4204f8363f1d
md5	e00bf9b8261410744c10ae3fe2ce9049
md5	51ea28f4f3fa794d5b207475897b1eef
md5	3195110045f64a3c83fc3e043c46d253
md5	1dd593ad084e1526c8facce834b0e124
url	connectads[.]com
url	kane-consulting[.]net
url	edadmin.kearsney[.]com
url	redbluffchamber[.]com

Sources

[1] https://securelist.com/blog/research/69731/the-cozyduke-apt/
[2] http://www.symantec.com/connect/blogs/forkmeiamfamous-seaduke-latest-weapon-duke-armory
[3]http://www.theregister.co.uk/2015/04/22/cozyduke_hackers_white_house_state_dept_malware/
[4] http://researchcenter.paloaltonetworks.com/2015/07/unit-42-technical-analysis-seaduke/

Brandon Levene, Robert Falcone and Richard Wartell

[Palo Alto Networks Blog]

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.

MD5	A25EC7749B2DE12C2A86167AFA88A4DD
SHA1	BB71254FBD41855E8E70F05231CE77FEE6F00388
SHA256	3EB86B7B067C296EF53E4857A74E09F12C2B84B666FC130D1F58AEC18BC74B0D
Compile Timestamp	2013-03-23 22:26:55
File type	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.

• sys.path.append(r”%s”)
• del sys.path[:]
• import sys
• PYTHONHOME
• PYTHONPATH
• Error in command: %s
• sys.path.append(r”%s?%d”)
• _MEI%d
• INTERNAL ERROR: cannot create temporary directory!
• WARNING: file already exists but should not: %s
• Error creating child process!
• Cannot GetProcAddress for PySys_SetObject
• PySys_SetObject

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:

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:

Figure 5. Base64-encoded / ZLIB compressed data

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:

1. Persistence via PowerShell
2. Persistence via the Run registry key
3. 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).

EBJhZTlKiqN8nYWejKh7UpDycPlcrGMEcTE=

The resulting decoded data is shown below.

\x10\x12ae9J\x8a\xa3|\x9d\x85\x9e\x8c\xa8{R\x90\xf2p\xf9\\\xacc\x04q1

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.

Josh Grunzweig

[Palo Alto Networks Blog]