Month: November 2015

This is the second in our series of cybersecurity predictions for 2016. Stay tuned for more through the end of the year.

As we look toward 2016, I think there’s good reason to consider several shifts that we’ve seen in tactics used in recent attacks. Developments in several of these areas will play a significant role in mobile workforce security planning strategies for the year to come.

Inverting the Hierarchy of Policy Enforcement

While many organizations are primarily concerned with perimeter security: controlling what people on the outside can do to the organization, there’s still a lot of work to be done about the flip side of the equation: controlling what people on the inside can do to the organization. It is all too common to think of internal security as a matter of what can attach to the network, rather than asking the deeper questions of what those people and devices connected to the network should be able to do.

Twenty years ago, organizations relied on physical security to secure their network (no access unless you can get into the building). This notion started to crumble with wireless networking, in which authentication became the gating factor to control who was on the inside.

In both cases, however, these measures stop short of addressing the questions of what can a person or machine do once connected, and which applications can they access. This is particularly true when looking at the lifecycle of a cyberattack, where compromised endpoints are often employed to conduct lateral movement and exfiltrate information, all because many organizations do not have controls that inspect traffic inside the organization.

Network segmentation provides a part of the answer because compartmentalization can establish borders. However, while segmentation is a good first step, more needs to be done to control what traffic crosses the boundaries between segments.

These changes have been a long time coming, but, in 2016, I foresee significantly more emphasis on these issues, driven by the growing diversity of mobile devices in use. It has never been sufficient to simply allow or block devices from connecting. The next step is making sure we know what these devices are doing, and that’s going to take better enforcement of security policy inside the network.

Attacking the Person Behind the App

When taking a look at some of the attacks employed against mobile devices – such as recent iOS attacks like XcodeGhost and WireLurker – what’s interesting is that the techniques were far more nuanced than they might appear. Instead of just developing a piece of malware, the people behind these attacks customized the delivery system that would get the malware onto the mobile device.

In the case of WireLurker, it was a matter of infecting the owner’s laptop – hijacking the process for synchronizing and backing up the mobile phone’s content. The attacker was able to insert the malicious content into the host and transfer the app via USB onto the mobile device.

In the case of XcodeGhost, the attackers went up the food chain and attacked the app developers themselves by distributing a modified version of the coding tools for building iOS apps. The resulting apps had dormant functionalities inside them that were not immediately visible to either the developer or the end user.

Both attacks were capable of inserting malware into non-jailbroken mobile devices. This is possible because mobile devices do not exist on an island. They are always connected to an interface with a variety of systems, some of which they inherently trust. When attackers are capable of inserting themselves into, and abusing these trusts, new threat vectors emerge.

With this in mind, in 2016, security teams will need to think about what they need to protect (e.g., endpoint, network and mobile devices) in a blended effort, rather than counting on each one separately. This is because the intelligence and protection in one area serves as the compensating control for the other. If it’s unknown whether a mobile device is compromised, then securing network traffic serves as a compensating control to catch malicious behavior. If malicious command and control traffic emerges from an endpoint, then any such traffic from a mobile device should also be closely scrutinized.

Pushing the Boundaries of Gray

Categorically, there is a growing amount of software that isn’t so easily defined as being safe or malicious. These grayware applications fall between the lines because the software typically interacts with a third party, and that third party’s motivations, intent, and even identity may be unknown to the end user. At times, the end user may not know there’s a third party involved at all. One person’s remote desktop application is another person’s remote access tool.

The prevalence of grayware in mobile app stores has weighed toward adware, especially from third-party ad networks. These packages include functions that the end user (and the developer in many cases) does not know about. In the haste to use an app, a user may not scrutinize the permissions given, thus providing advertisers with access to a treasure trove of data. These ad networks slip into the realm of grayware because, even though they may have the permission to access the data, there is no guarantee that the data will be used in an ethical manner.

It’s my belief that more apps will use the cloudy edges of the grayware definition to slip in more malicious activity than advertising. Early signs of this activity can already be felt from the discovery of Gunpoder. When an app store evaluates an app for security risks, it is often done without the full view of the dynamics of how the functionality branches in the real world. In addition, without the context of threat intelligence, other clues about the activity conducted by the third party may not be clear. The only way to truly understand how an app operates is to see what it’s doing on the network in real world conditions when it’s being used, and that’s the role of network security.

 

Brian Tokuyoshi

[Palo Alto Networks Blog]

While researching new, unknown threats collected by WildFire, we discovered the apparent re-emergence of a cyber espionage campaign thought to be dormant after its public disclosure in June 2013. The tools and tactics discovered, while not identical to the previous Dark Seoul campaign, showed extreme similarities in their functions, structure, and tools. In this post, we will provide an overview of the original Dark Seoul campaign in 2013, the similarities and differences in tactics, the malware used, as well as attempt to answer the question of ‘why now’?

Overview

In March 2013, the country of South Korea experienced a major cyberattack, affecting tens of thousands of computer systems in the financial and broadcasting industries. This attack was dubbed ‘Dark Seoul’; it involved wreaking havoc on affected systems by wiping their hard drives, in addition to seeking military intelligence.

The attack was initially thought to be attributed to North Korea, by way of a Chinese IP found during the attack, but no other strong evidence of North Korea’s involvement has been produced since then. In June 2013, McAfee published a report detailing the chronology and variance of the Dark Seoul campaign, but renamed it ‘Operation Troy’. The report analyzed the entirety of the purported attack campaign, beginning in 2009 using a family of tools dubbed ‘Troy’. McAfee further attributed two groups to the campaign: the NewRomanic Cyber Army Team and The Whois Hacking Team; both groups believed to be state sponsored. Since the publication of that report, no other activity involving either group or the tools have been detected or shared publically.

That is, until now.

Dark Seoul Returns 

Using the Palo Alto Networks AutoFocus threat intelligence platform, we identified several samples of malicious code with behavior similar to the aforementioned Operation Troy campaign dating back to June 2015, over two years after the original attacks in South Korea. Session data revealed a live attack targeting the transportation and logistics sector in Europe. The initial attack was likely a spear-phishing email, which leveraged a trojanized version of a legitimate software installation executable hosted by a company in the industrial control systems sector. The modified executable still installs the legitimate video player software it claims to contain, but also infects the system. Based on deep analysis of the Trojan’s behavior, binary code, and previous reports of similar attacks, we have concluded that these samples were the same as the original tools used in the Dark Seoul/Operation Troy attacks. It is likely the same adversary group is involved, although there is currently insufficient data to confirm this conclusion.

Malware Overview

The malicious code was delivered via the following two executable names, packaged together in a zip archive file:

• [redacted]Player_full.exe
• [redacted]Player_light.exe

Both executables present themselves as legitimate installation programs offered by the industrial control systems organization, providing video player software for security camera solutions. When either sample was executed, the malware dropped and subsequently executed the actual video player it disguised itself as.

The new malware variant, which we call TDrop2, proceeds to select a legitimate Microsoft Windows executable in the system32 folder executes it, and then uses the legitimate executable’s process as a container for the malicious code, a technique known as process hollowing. Once successfully executed, the corresponding process then attempts to retrieve the second-stage payload.

The second-stage instruction attempts to obfuscate its activity by retrieving a payload that appears to be an image file, but upon further inspection appears actually to be a portable executable.

The C2 server replaces the first two bytes, which are normally ‘MZ’, with the characters ‘DW’, which may allow this C2 activity to evade rudimentary network security solutions and thus increase the success rate of retrieval.

Once downloaded, the dropper will replace the initial two bytes prior to executing it. This second stage payload will once again perform process hollowing against a randomly selected Windows executable located in the system32 folder. The overall workflow of this malware is visualized below:

The final payload provides the following capabilities to attackers:

Command	Description
1001	Modify C2 URLs
1003	Download
1013	Download/execute malware in other process
1018	Modify wait interval time
1025	Download/execute and return response
Default	Execute command and return results

These commands are encrypted/encoded when transferred over the network, as we can see below.

The malware uses an unidentified cryptographic routine for encryption. Additionally, the following custom alphabet is used for base64 encoding that takes place after the encryption of the data:

3bcd1fghijklmABCDEFGH-J+LMnopq4stuvwxyzNOPQ7STUVWXYZ0e2ar56R89K/

Once decoded and decrypted, we see the following command being provided:

tick 7880
systeminfo & net view & netstat -naop tcp & tasklist & dir /a “%userprofile%\AppData\Local\Microsoft\Outlook” & dir /a “%temp%\*.exe” & dir “%ProgramFiles%” & dir “%ProgramFiles%\Microsoft Office”
1018; 60

The initial ‘tick’ string is hardcoded and must be present for the malware to accept the subsequent command(s). In this case, the initial commands are used to perform basic reconnaissance on the infected host and return the results to the attacker, then initialize a sleep period of 60 seconds.

We will publish more details about the TDrop2 malware variant in a follow up blog.

Malware Similarities

Analysis of the malicious code identified reveals the distinct similarities in behavior and functionality to the original Dark Seoul/Operation Troy toolset.

The use of the custom base64 alphabet was observed in the following twelve samples that were specified within the Operation Troy whitepaper:

2e500b2f160f927b1140fb105b83300ca21762c21bb6195c44e8dc613f7d7b12
353a1288b1f8866af17cd7dffb8b202860f03da8d42e6a76df7b5212b3294632
4a11e0453af1155262775e182e5889fc7141f0fa73f8ac916fd83d2942480437
4df8a104c9d992c6ea6bd682f86c96ddffab302591330588465640eb8a04fa2d
591eb8ce448ab95b28a043943bd9de91489b5ebb1ef4a7b2646742b635fa93f2
8e84f93fd0e00acba0e1c4b1c1cef441fa33ad5c95e7bacbd7261ee262be039a
971fd9ae00ffce5738670ec26bca6cf3ad1a4c47d133cee672470381c559b5a7
a30eb5774fe309044467a6a90355cc69d62843cc946eb9cc568095a053980098
b323d4c3bef99742dda27df3bf07a46941932fec147daaa4863440c13a21ec49
c1a7b065555b833f76d87b54f1dd2ede90bce9268325e8524b372c01f3ef4403
c1cf57f2bdec8c9b650dfaba0427d12c39189330efab8cd9aa4dbfbd6735cf40
dbb0f061dd29b3f69d5fe48e3827e279bd8bdcf584f30fe35b037074c00eb840

The majority of these samples had debug strings that referenced the ‘TDrop’ malware family, which is likely the predecessor to the malware observed in this campaign and the source of the name ‘TDrop2’.

The new variant also uses a distinct string decryption routine, which was also observed in a number of Operation Troy samples.

The same string decryption routine was also observed in 64-bit samples from the Operation Troy campaign. The following samples were found to have this decryption routine present:

486141d174acec27a4139c4593362bd5c51a88f49dfde46d134a987b34896dc2
9d84e173796657162790377be2303b59d3cf680edec73627e209ca975fabe41c
a15aafcc79cc66ce7b45113ceff892261874fad9cf140af5b9fa401a1f06c4a4
bc724f66807e2f9c9cab946a3e97da51ad7a34f692e93d6e2b2db8cf39ae01db

Network communications appeared identical to that described in a Korean blog post written in June 2013 regarding what appears to be a partial analysis of the Dark Seoul attack. The behavior of the analyzed malicious code made references to decoding a PE file from both a .gif and .jpg URL. Additionally, a unique POST separator string is identified (6e8fad908fe13c), which also matches the malware payload observed in TDrop2 samples.

The command and control (C2) servers used in these recent attacks are compromised websites located in South Korea and Europe. It’s not clear what led to the compromise of these four web servers (listed in the IOC section below), but they all appear to use shared hosting providers and operate on out-of-date software that may contain vulnerabilities and/or misconfigurations.

The Attackers

At this time, it is unclear if this attack is attributed to the same two groups previously outlined in McAfee’s 2013 report. There are obvious similarities in the malware used, as well as other tactics, but there are also some obvious differences. The targeting for example, is completely different in that this observed attack is not aimed at military, government, or financial institutions in the South Korea region. In addition, there has been no evidence of destructive functionality in the samples analyzed by Unit 42, although the malware is capable of downloading additional components so those simply may not yet have been observed.

The similarities in tactics however, do seem to outweigh the differences, and it is highly likely this is the same group or groups responsible for the original Dark Seoul/Operation Troy attacks, but with a new target and a new campaign.

Conclusion

It is not uncommon for threat actors to become dormant for some period of time, especially after public unveiling as the groups behind Dark Seoul/Operation Troy experienced. What we do know is that changing infrastructure and toolsets can be challenging, and it is not nearly as common that a very specialized tool developed for specific teams would be shared amongst threat actors.

There is insufficient data at this time to clearly state why Dark Seoul/Operation Troy would resurface at this time, but Unit 42 will continue to monitor the activity as the situation develops.

We have created the AutoFocus tag TDrop2 to identify samples of this new variant and have added known C2 domains and hash values to the Threat Prevention product set. At this time, WildFire is able to correctly identify the samples associated with this campaign as malicious.

IOC List

SHA256 Hashes

52939b9ec4bc451172fa1c5810185194af7f5f6fa09c3c20b242229f56162b0f
1dee9b9d2e390f217cf19e63cdc3e53cc5d590eb2b9b21599e2da23a7a636184
52d465e368d2cb7dbf7d478ebadb367b3daa073e15d86f0cbd1a6265abfbd2fb
a02e1cb1efbe8f3551cc3a4b452c2b7f93565860cde44d26496aabd0d3296444
43eb1b6bf1707e55a39e87985eda455fb322afae3d2a57339c5e29054fb52042

Domains

http://www.junfac[.]com
http://www.htomega[.]com
mcm-yachtmanagement[.]com
http://www.combra[.]eu

URLs

http://www.junfac[.]com/tires/skin/tires.php
http://www.htomega[.]com/rgboard/image/rgboard.gif
mcm-yachtmanagement[.]com/installx/install_ok.php
http://www.combra[.]eu/includes/images/logo.jpg

Bryan Lee and Josh Grunzweig

[Palo Alto Networks Blog]

Palo Alto Networks was at Bloomberg’s The Year Ahead 2016 conference in New York earlier this month where over 250 Business Development Managers and c-level professionals were in attendance.

While we were there, Davis Hake, our Director for Cybersecurity Strategy, was interviewed by Bloomberg Radio to discuss Palo Alto Networks technology, a prevention mindset to cybersecurity, and how companies can make the right investments in training, people and processes by involving the c-suite in the security discussion. Listen to the interview.

Davis also participated on a panel focusing on Cybersecurity and the CEO, discussing some of the hot topics from Navigating the Digital Age, The Definitive Cybersecurity Guide for Directors and Officers which we recently produced in partnership with the New York Stock Exchange. Get a copy of this book and take a look at the photos from the event below.

Anna Lough

[Palo Alto Networks Blog]

There is a lot of information on the web about preventing and recovering from CryptoWall or ransomware attacks in enterprise environments, but most don’t answer this basic question:

“How do I determine which CryptoWall-infected PC encrypted all the documents in one of my network-shared drives? I don’t have audit logging enabled on my file server.”

Although many organizations are working on migrating their document storage to the cloud, most still rely upon individual Microsoft network shares as a document repository for each business department. For example, the financial controller’s office may have a network share dedicated to that department, the HR department has a different one, etc. When a user’s PC in one of these departments becomes infected by CryptoWall, the ransomware iterates through all files on all folders on all local and mapped network drives and encrypts certain file types that the user has permissions to modify.

As a security lead for a hospital network, I created the following CryptoWall response plan specifically to deal with impacted department shared drives:

1. Identify the user account that modified (encrypted) the shared drive files.
2. Identify the infected PC and restrict network access.
3. Create inventory of all network share directories impacted.
4. Restore impacted directories from backup.

Identifying the user account in Step 1 can be challenging if you don’t know where to look. The best way to identify the user account used to encrypt the files is to examine the “owner” attribute of one of the instruction files created by the ransomware. Here are the steps to identify the owner:

1. Right click on the instructions file (i.e., HELP_DECRYPT.txt) created by the ransomware on the network share, and select Properties.

2. Select the Security tab –> Advanced –> Owner, and view the Current Owner attribute. The Current Owner attribute is likely the username used to encrypt the files in the directory.

Once you know the username used to encrypt the files, you can reset the user’s password, attempt to contact the person, and identify the user’s assigned PC in order to block it on the network. Once the PC is blocked, the server team can then identify the impacted directories on the network share (Tip: Use PowerScript to identify directories containing the instructions file). Finally, the Backup team can restore the files in all of the identified directories.

For more information on the latest CryptoWall threat, take a look at a detailed analysis of CryptoWall v3 authored by the Cyber Threat Alliance, cofounded by Palo Alto Networks.

Matt Mellen

[Palo Alto Networks Blog]