Category: Palo Alto Networks

In Part 5 of our IDAPython blog series, we used IDAPython to extract embedded executables from malicious samples. For this sixth installment, I’d like to discuss using IDA in a very automated way. Specifically, let’s address how we’re going to load files into IDA without spawning a GUI, automatically run an IDAPython script, and extract the results. Using this technique, we’ll be able to process many samples very quickly without needing to manually open each file in a new instance of IDA and run the IDAPython script.

Many may be surprised to learn that IDA can be executed purely on the command-line without spawning a GUI. In order to do so, the user must run the IDA executable with the ‘-A’ switch. This particular switch will instruct IDA to run in autonomous mode, ensuring that no windows or dialog boxes are presented to the user.

The following command-line examples demonstrate this technique being used in both OSX and Microsoft Windows . In these examples, the ‘-c’ switch generates a new IDB file, even in the event one already exists. Additionally, the ‘-S’ switch specifies the IDAPython script that will be run upon execution. We’ll be using these switches later on in the post.

The Scenario

For this example, I’m going to use the Cmstar malware family, previously discussed by Unit 42. For those unfamiliar with this malware family, it is a downloader that will transfer a file hosted at a specific URL over HTTP(S) and execute it on the victim’s system. The URL in question can be de-obfuscated using the following routine.

Knowing this, our next task is to identify where this data resides within a Cmstar sample. Correlating across a few samples, we conclude that two encrypted strings are being stored into a variable using calls to memcpy. One of the strings contains the domain or IP address that the malware will connect to, while the other contains the URI.

We also notice that the same sequence of instructions are executed when this memcpy instruction takes place:

mov esi, [offset]
pop ecx
lea edi, [variable]
rep movsd

Figure 1 Function containing encoded strings in Cmstar

Armed with this information, we can attempt to identify this sequence of instructions using IDAPython. To do so, we’ll iterate through every function IDA identifies, and proceed to ignore any functions marked as a jump function or belonging to a known library. The remaining functions will then be iterated through using a sliding window where we’ll inspect four instructions at a time, seeking the markers previously identified to determine if there are any matches:

In the above example, I’m simply printing out a debug string if I find any matches. Running this code against the sample with an MD5 hash of 4BEFA0F5B3F981E498ACD676EB352D45 in IDA, we get the following output. As we can see below, we’ve successfully identified the addresses of both obfuscated strings.

Figure 2 Running script against Cmstar sample

At this point, we can take the offsets we’ve identified and extract the strings to which they point. These strings can then be decoded using the previously defined decode() function.

Putting this all together, we come up with the following script:

At this stage, we can use the automation technique of running IDA in non-GUI mode and use the above script. This will allow us to run this script against a number of samples without the need for user interaction. We’ll run the script on our OSX machine as follows:

for x in ls; do /Applications/IDA\ Pro\ 6.9/idaq.app/Contents/MacOS/idaq -c -A -S/tmp/script.py $x; done

After a few minutes, we’re treated to the following within /tmp/output.txt, which is where we instructed our script to store results.

Figure 3 Output of /tmp/output.txt

Conclusion

By leveraging both the power of IDAPython, along with IDA’s command-line switches, we’ve successfully automated the extraction of the download location of a number of Cmstar samples. This technique can easily be applied to a larger number of samples, allowing us to execute IDAPython actions without needing to manually open each file in IDA. For those readers who were not aware of this IDA capability, I implore you to investigate it, as it can not only save you time, but also make things much easier when working with a large number of files.

Josh Grunzweig

[Palo Alto Networks Research Center]

(This post is also available in Japanese on our Japan website.)

Over 1,200 people attended Palo Alto Networks Day at the Prince Park Tower in Tokyo yesterday, underscoring how security continues to be a top, strategic priority for organizations and the industry at large in Japan.

The morning session of the conference kicked off with a welcome speech by Hiroshi Alley, chairman and president of Palo Alto Networks K.K.

Mark McLaughlin, chairman, president CEO of Palo Alto Networks, then delivered his keynote on protecting our way of life in the digital age and our prevention-based approach to doing so.

Other speakers include René Bonvanie, chief marketing officer and executive vice president of Palo Alto Networks and Heizo Takenaka, Director of the Global Security Research Institute at Keio University, and Japan’s former Minister for Internal Affairs & Communications and Minister of Economic/Fiscal Policy. Rene talked about the Palo Alto Networks Next-Generation Security Platform as well as recent enhancements made to Global Protect, updates to WildFire and AutoFocus and PAN-OS Panorama 7.1 release.

Professor Takenaka delivered a keynote speech on how the economy – global and in Japan – is interconnected and only security can make them robust and successful.

Check out some of the pictures below from the successful event, which also featured William Saito, Vice Chairman, Palo Alto Networks K.K., and Mihoko Matsubara, CSO, Japan, Palo Alto Networks.

Last, don’t forget to follow Palo Alto Networks Japan and Unit 42 on social media!

Facebook
Twitter
Unit 42 日本拠点ブログ
Unit 42 Twitter

* Event photos taken by Tsugunori Sugawara from Palo Alto Networks, and Hiroshi Haneda, official photographer for Palo Alto Networks Day 2016. 

Martina Schulze-Warnecke

[Palo Alto Networks Research Center]

Del Rodillas, our solution lead for SCADA & Industrial Control Systems, recently appeared in Electric Light & Power to discuss ransomware as an emerging threat for Operational Technology environments. With ransomware on everyone’s mind these days, Del shares insights from the recent report published by Unit 42 and instructs ICS owners and operators on how they can prepare their organizations to defend critical systems against ransomware.

As Del writes, “It is in every ICS owner’s and operator’s best interest to act now to prepare their organization from this rising threat. Education is the first step…”

Read Del’s full article in Electric Light & Power, and check out an infographic below.

Learn more:

• Download the Unit 42 Ransomware report
• Palo Alto Networks solutions for ICS/SCADA
• Palo Alto Networks solutions for Electric Utilities
• Palo Alto Networks solutions for Oil & Gas

Chad Berndtson

[Palo Alto Networks Research Center]

This is the second part of a two-part blog post for understanding Angler exploit kit (EK). The first part covered EKs in general. This blog focuses on the Angler EK.

Angler is currently one of the most advanced, effective, and popular exploit kits in the cyber criminal market. It generally uses the most recent exploits based on the latest vulnerabilities. Like most leading EKs, the authors behind Angler use Software as a Service (SaaS) as their business model, and Angler can be rented in the cyber underground for a few thousand dollars a month.

History

Angler EK was discovered in 2013, and it began appearing more frequently later that year. Angler grew in popularity sometime after Russian authorities arrested malware kingpin “Paunch”, the alleged creator and distributor of Blackhole EK. As Blackhole EK disappeared, other EKs like Angler began filling the void.

However, Angler is not the criminal’s name for this EK. Security researchers used the term “Angler” because of a picture of an Anglerfish in advertisements from late 2013.

Based on control panels found on Angler EK servers in 2015, the author’s name for Angler is “XXX”. Based on the copyright date in the control panel, Angler EK might have been around in some form as early as 2010.

Figure 1: Control panel for Angler EK with “XXX” from the Malware Don’t Need Coffee Blog.

Growth in Angler EK Traffic

Security researchers saw an increase Angler EK-related traffic during 2014. After a short lull,Angler EK has been relatively prominent since March 2015. Today, Angler accounts for the majority of EK traffic we find.

Angler EK Exploits

In 2015, Angler EK began focusing on exploits targeting three applications: Flash player, Internet Explorer, and Silverlight. Angler is often one of the first EKs to use new exploits targeting these applications.

For example, in June 2015 a previously unknown Flash vulnerability (later identified as CVE-2015-5119) was part of some 400 gigabytes of data dumped on the Internet as part of the infamous Hacking Team breach. A Flash exploit based on CVE-2015-5119 was integrated into Angler EK hours after the data dump was publicly available. It was a zero-day exploit at least 24 hours in the wild before Adobe issued a patch for it.

By August 2015, Angler EK implemented an exploit for Internet Explorer (IE) vulnerability CVE-2015-2419 that Microsoft had patched the previous month.

In February 2016, exploits for Silverlight based on CVE-2016-0034 found their way into Angler EK a little more than a month after Microsoft issued a patch for the vulnerability.

Angler EK Payloads

Different campaigns use Angler EK to distribute different types of malware.

The most prominent type of payload from campaigns using Angler EK appears to be ransomware. In 2015, the ransomware was most often CryptoWall. By the start of 2016, it was primarily TeslaCrypt. In mid-April 2016, the usual ransomware changed from TeslaCrypt toCryptXXX ransomware. We have seen CryptXXX primarily from actors behind the pseudo-Darkleech campaign.

But ransomware is not the only payload sent by Angler EK. EITest is another campaign that uses Angler EK to distribute other types of malware. In addition to ransomware, EITest Angler EK includes banking Trojans like Tinba, information stealers like Vawtrak, and other malware families including Andromeda, Ursnif, or Zeus.

Fileless Infection to Avoid Detection

In August 2014, Angler EK introduced a “fileless” infection technique to avoid detection by executing the payload from memory instead of storing it to disk. This technique is most often associated with Bedep payloads. Such fileless infections leave no artifacts from Bedep on the infected system’s disk. Fortunately, any post-infection activity usually leaves clues, since follow-up malware must be stored somewhere on the system in order to stay persistent and survive a reboot.

Angler EK and CryptXXX

In April 2016, the pseudo-Darkleech campaign started using Angler EK to send Bedep, and Bedep followed up with CryptXXX ransomware. Bedep also downloads click-fraud malware that generates web traffic behind-the-scenes (click-fraud is a fraudulent method used by criminal groups to increase advertising revenue). This click-fraud traffic is invisible to the end user, but it is noticeable when monitoring network traffic generated by the infected host.

Proofpoint and others reported details of CryptXXX and Bedep when this particular combination first appeared. Sometime during the second week of May 2016, the pseudo-Darkleech campaign stopped using Bedep and began sending CryptXXX only.

Figure 2: An example of Angler EK sending Bedep then Bedep sending CryptXXX on 2016-04-22.

Figure 3: An infected Windows desktop after Angler EK sent CryptXXX.

Conclusion

Angler EK will no doubt continue to evolve. We expect the EK to continue implementing improvements to avoid detection. As a payload of Angler EK, Bedep malware has recently changed and is much more capable of detecting virtual environments used by security researchers. CryptXXX ransomware is a growing menace that also has information stealing capabilities, and it appears to be moving to other campaigns that formerly spread TeslaCrypt ransomware.

How can people protect themselves against Angler EK? As stated in part 1 of this blog post, use a layered defense. First, make sure your operating system and applications are patched and up-to-date. Like any other EK, Angler takes advantage of outdated browser-based applications to infect vulnerable Windows hosts.

Network monitoring and endpoint protection are additional components of a layered defense. Palo Alto Networks Next-Generation Security Platform can help security teams monitor their network to detect the constantly changing indicators of Angler EK. Endpoint solutions like Palo Alto Networks Traps can help protect an organization’s assets against malicious executables, data files or network-based exploits before any malicious activity can successfully run.

Domains, IP addresses, and other indicators associated with Angler EK and its associated payloads are constantly changing. We continue to investigate this activity for applicable indicators to inform the community and further enhance our threat prevention platform.

Brad Duncan

[Palo Alto Networks Research Center]

There’s been a longstanding belief that IT and security teams are at odds with each other. This is because their measures for performance are, on the surface, almost contradictory with one another. IT must find ways to provide the applications that the business needs. But business conditions change rapidly, and the applications the organization needs can shift on a dime. IT organizations must be agile and quick in response to new business drivers because no CIO wants to be the bottleneck in the boardroom for business change. Thus, IT tends to favor technologies that accelerate change, such as the rapid adoption of virtualized business workloads to the cloud.

Security, on the other hand, operates on a different set of benchmarks and priorities. Security’s foremost concern is the protection of data by eliminating avenues of risk. As such, the general inclination of security tends to be conservative and values consistency over change. Introducing new applications and emerging technologies opens up new vectors for risk and data loss, which are precisely the opposite of what they’re tasked to minimize.

Despite having a healthy appreciation for each other’s work, both sides feel conflicted. IT does not want to forsake security, and security does not want to slow down IT. Yet, it’s not uncommon to see IT and security teams working in completely different parts of the organization due to their conflicting missions.

I found this recent article in Dark Reading interesting: “How Security and IT Teams Can Get Along,” in that there is precedent for change. It discusses several areas where change is occurring, including where new roles are emerging. For example, DevOps groups bridge the gap that traditionally separated application development (constructing new applications) and operations (keeping existing applications running at all times). When thinking about how a similar divide exists with IT and security, perhaps the first step will come through shifts in the expectations on what each group should do.

The article goes into depth about how to make a difference when bringing the teams together, and one area is the problem of measuring goals when the metrics are not meaningful. I agree, because there is a major risk of losing sight of the goals when your metrics are based on the symptom rather than the problem. For instance, incidence response teams that work on investigating alerts often face a Sisyphus’s stone amount of work. There is no shortage of red alerts being generated throughout the organization, and quantity of alerts is seldom a good measure to determine the severity of the problem. The more patient attacker will not draw attention, but how do you find the events on which to focus? And how do you correlate that activity across systems that are traditionally unrelated to one another?

One area that I think is particularly promising is the decoupling of security controls from the application. Phrased in a different way, the reason that I see IT and security competing, at times, is that there’s been no shortage of evidence showing what can happen if you deploy an application first and then bolt the security on afterwards, typically with a one-off point product. It’s seldom going to be as secure or easily managed as if it was designed to be deployed together with the application in the first place. The policy will certainly be fragmented, with a different control point for every point product deployed. And it will almost certainly create the issue described above, where every point product generates red alerts with no correlation on what to prioritize.

That’s why I believe that the Palo Alto Networks Next-Generation Security Platform provides the security controls that bridge the intersection between the interests of IT, Security and DevOps. It does this because it positions critical security functions as the common denominator to all applications: the network. By seeing all traffic, and extending that visibility across all users, applications and devices, the organization can set up the underlying security that applies to all the applications that IT wants to deploy. The critical security controls for stopping an attack are in place ahead of the application, rather than trailing it.

It’s important to note that “network,” in this sense, does not solely mean the traditional perimeter because the platform extends to the mobile user (through GlobalProtect), the public cloud (through VM-Series on AWS and Azure) and the virtualized data center/private cloud. These baseline principles set the foundation for additional controls that the organization deploys along with the application.

Operationally, the use of the platform helps organizations get contextual views of network activity that bears investigation (through AutoFocus) as well as a deeper level of control through the enforcement of policy on the next-generation firewall.

These principles deliver upon the premise of prevention first, while breaking the lifecycle of an attack across all stages, because the protection is inherently baked into the platform rather than bolted onto the application. It’s been designed to do this from the ground up.

I think that, in the years ahead, there will be even greater discussion on how IT and security teams align in new ways, and every organization should be preparing for this conversation. Fortunately, the principles of the Next-Generation Security Platform can help pave the way.

Brian Tokuyoshi

[Palo Alto Networks Research Center]