This past week, Palo Alto Networks hosted our very first Intern Tech Week to give our interns the chance to connect with teams from different branches of the company. It was an opportunity to not only learn more about Palo Alto Networks products but also see how they are made.
We kicked off the week last Monday with a deep dive from the creative minds behindAutoFocus. Scott Simkin, Senior Threat Intelligence Manager; Bilal Malik, Senior Product Manager; and Farshad Rostamabadi, Software Engineering Manager, discussed how they worked as a team to create a game-changing product that provides actionable threat intelligence to businesses and governments.
Tuesday began with a field trip to Flex to discover how our products are made. Vonnie French, Vice President, Supply Chain Operations, and her team provided an overview of the manufacturing organization and took the interns on a tour of the factory to see the entire cycle, from where the products are built to how they’re packaged and shipped to our customers.
The interns then met up with their hiring managers at Baylands Park to enjoy some good eats and fun outdoor games.
On Thursday, we got to find out what goes on in the mind of a hacker! Bryan Lee from Unit 42 stopped by to discuss what motivates hackers and what the future looks like for the cybersecurity industry. Ashwin Dewan, an intern from Product Management, learned a few new things from Bryan. “The presentation from the Unit 42 researcher helped me understand the company mission and vision,” he said. “Palo Alto Networks exists because hackers do, and understanding what a hacker is, and does, is as important as understanding any particular part of the platform.”
We ended the week with a great talk by our InfoSec Team. Rinki Sethi, Senior Director, Information Security, led a presentation with Lucas Moody, CISO, and other Information Security experts. This engaging panel discussed how they work to protect our brand and people using our best-in-class products. They also led the interns through an exercise of thinking through risk assessments, giving them a glimpse of what our customers do on a daily basis.
One of the main goals of our Summer Intern Program is to provide our interns with experiences that offer them a meaningful connection with our business. By hosting this Tech Week, we wanted our interns to learn more about the company and our products and get a glimpse into what our culture is truly like.
We think we achieved this because, as the week wrapped up, Channel Operations Intern, Jennifer Lu, said, “Seeing all the different people that made time for us interns, from Nir [Zuk] to Unit 42 to the InfoSec team, I really felt like I was part of Palo Alto Networks. I could clearly see the incredibly supportive, humble, and collaborative culture from every person I met at Tech Week! We are thankful for all of the great speakers we had this week and we already can’t wait for next year!”
Unit 42 recently identified a variant of MNKit-weaponized documents being used to deliver LURK0 Gh0st, NetTraveler, and Saker payloads. The documents were delivered to targets involved with universities, NGOs, and political/human rights groups concerning Islam and South Asia. Reuse of this MNKit variant, sender email addresses, email subject lines, attachment filenames, command and control domains, XOR keys, and targeted recipients show a connection between the different payload families delivered.
MNKit is the name given to a builder that generates CVE-2012-0158 exploit documents. The documents are in MHTML format and install a malicious payload on the compromised host. We believe MNKit is privately shared between multiple attack groups, but is not widely available.
Information about previous attack campaigns using MNKit is available in the following reports:
Typical MNKit MHTML files have used User123 or User323 as the Author and LastAuthor element values within their DocumentProperties sections and C:/2673C891/Doc1.files/ as a file directory location. The samples discussed in this blog use User323 and User426 as Author and LastAuthor element values and C:/23456789/Doc1.files/ as a file directory location.
LURK0 Delivery
LURK0 is a family of remote access trojans derived from Gh0st RAT. It has been used by attack groups for years, as discussed by CitizenLab in a publication from 2012 on Tibet-related information operations and has been fairly well analyzed in publicly available reporting. Contained within a subset of the MNKit exploit documents were malicious SFX PE files that delivered LURK0 implants. These PE files were encoded using a decrementing XOR function with the key beginning at 127. Within each SFX are five files:
1
2
3
4
5
RasTls.exe
RasTls.dll
MemoryLoad.dump
BTFly.dump
IconConfigBt.DAT orIconConfigBty.DAT
The execution of the self-extracting zips side-loading of LURK0 payloads is identifiable by the registry key they create
http://www.amerikauyghur[.]top and dge.123nat[.]com are two command and control domains resolved by the malware. The first domain was previously mentioned by Arbor Networks in a report detailing the targeting of Tibetan, Hong Kong, and Taiwanese interests in their report, The Four-Element Sword Engagement. A subdomain of 123nat[.]com, manhaton.123nat[.]com, was also referenced in Arbor’s report as a LURK0 command and control domain. Below shows theLURK0 string used in the first five bytes of an implant beacon.
Saker Delivery
Saker, often also called ‘Xbox’ and ‘Mongall’, is a malware family used by targeted attack groups who have also deployed NetTraveler and Gh0stRAT.
Two of the sending addresses used to distribute the above LURK0 samples,dolkun2015@gmail[.]com and duqdiniishlari@gmail[.]com, were also used to distributed other types of malware. By observing overlaps in the sending and receiving email addresses as well as the filenames of attachments, we were able to identify additional MNKit exploit documents that also included self-extracting PE files. These PE files were again XOR encoded in the attached documents using the same decrementing key (beginning with 127). These additional SFX PE files are password protected using one of the following passwords:
1
2
3
aurhuhkdsf!.xlas
^elqwiajdsfile!
Ieafsdisdlflei!dsa
Instead of including RasTls.exe to sideload payloads (as the LURK0 payloads did), within each of the embedded PEs is a single DLL file named msdis.dll which exports a function namedJustTempFun. The recently compiled and deployed msdis.dll files’ SHA256 hashes and compile timestamps follow:
Saker samples construct strings during execution. One such string is the origin of the malware’s name.
The Saker PEs also contain a user agent strings (also constructed manually during execution) of Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; .NET CLR 1.1.4531) and Mozilla/6.0 (compatible; MSIE 9.0; Wis NT 8.1; .NET CLR 2.13431). This second user agent is similar to the user agent, <code>Mozilla/4.0 (compatible; MSIE 6.0; Wis NT 5.0; .NET CLR 1.1.4322), as outlined by FireEye in 2014.
The command and control locations for the Saker samples delivered via MNKit follow:
1
2
3
bsnl[.]wang
www.amerikauyghur[.]top
www.onebook[.]top
amerikauyghur[.]top overlaps with the LURK0 samples previously mentioned. Bothonebook[.]top (registered with a registrant email address of interestbook@sina.com and bsnl.wang (registered with a registrant email address of jgjop@yahoo.com) have resolved previously to 103.232.222[.]20.
Using AutoFocus, we were able to locate additional samples that resolved to these domains. The samples are a mix of LURK0, Saker, and PlugX. Their hashes follow:
NetTraveler is a backdoor used to install other malware, steal information, and provide remote control of a compromised system. The targets previously mentioned by Kaspersky Lab of the NetTraveler operators aligns closely with the recipients of a new set of samples.
Three additional MNKit documents were located as MNKit exploit attachments. Unfortunately, we were unable to locate emails the attachments were sent with. These three samples also included SFX PE files encoded using the same decrementing XOR. Within each PE are three files which side-load NetTraveler. The files are named:
1
2
3
fsguidll.exe
fslapi.dll
fslapi.dll.gui
The hashes and compile timestamps for each fslapi.dll follow:
The fslapi.dll files load their accompanying fslapi.dll.gui files that are XOR encoded. The decoded fslap.dll.gui DLLs include the following embedded URLs, the first of which was previously documented by Unit 42 as a red herring within NetTraveler samples.
The fslapi.dll files contain an overlay that is used to decode the real C2 as documented in the same Unit 42 NetTraveler blog. The decoded command and control URLs include:
Tassnews[.]net was registered with a registrant email address of ghjksd@gmail[.]com and info-spb[.]com was registered with a registrant email address of kefj0943@yahoo[.]com.Riaru[.]net was registered with a registrant email address of fjknge@yahoo[.]com on 29 March 2016, which also registered one other domain name, yandax[.]net, on 16 June 2016 using the same authoritative DNS servers and registrar. Interfaxru[.]com was registered with a registrant email address of ganh@gmail[.]com on 18 April 2016 using the same registrar and authoritative DNS servers as riaru[.]net and yandax[.]net. Only one domain name is currently registered byganh@gmail[.]com, however it would be no surprise if an additional domain is registered by this registrant in the near future.
Putting it All Together
While MNKit has been associated with multiple different groups the reuse of domain names, IPv4 addresses, phishing themes, XOR schemes, and email accounts are strong evidence for linkage between these new attacks and the previously documented ones. The change in PE SFX contents over the three sets of SFX PE files between February 2016 to March 2016, March 2016 to April 2016, and April 2016 to June 2016 time frames show a slight deviation is payload but consistencies in delivery methods. The best defense against MNKit is to ensure your systems are patched for CVE-2012-0158, but in situations where this isn’t possible, exploit mitigation technology like Traps is warranted.
While attribution is a challenging art, it’s likely whoever is behind these recent attacks is, through infrastructure, malware families and delivery techniques, somehow related to the previously reported attacks. The attackers have been active for years, will likely continue to be active, and seem to prefer to change tactics only subtly.
AutoFocus users can track the malware discussed above using the following tags:
Last week I had the good fortune to attend the 2016 Honeywell Users Group Americas event in San Antonio, Texas. At this annual event, Honeywell customers from around the world come together to solve common problems in SCADA/ICS and attend keynote speeches and roundtable discussions on topics such as the industrial internet of things (IIoT), cybersecurity, alarm management, and more.
It also served as the first public exhibit of the results of the partnership we announced with Honeywell in February to jointly develop industrial cybersecurity solutions. As described in Honeywell’s keynote address, Honeywell has integrated Palo Alto Networks Next-Generation Firewall technology into their industrial cybersecurity solution, Risk Manager, to provide advanced network traffic inspection. With our next-generation firewall technology, Honeywell’s industrial control customers will have much more insight into who is using which applications on the network, what assets and data they are accessing, and what threats may be trying to breach or pivot around the OT network. With that information, customers can take a more proactive approach to industrial cybersecurity, even protecting their networks from previously unknown attack methodologies.
In addition to our next-generation firewall technology, Honeywell is offering the Palo Alto Networks WildFireWF-500 zero-day, on-premises sandboxing device to augment theirHoneywell Managed Industrial Cyber Security Services offering. Designed to provide cybersecurity consulting services to customers who don’t have the required expertise in-house, the services offering uses WildFire to provide Honeywell’s security experts with the latest threat intelligence in real time.
Ariel Cohen of Palo Alto Networks at the 2016 Honeywell Users Group. The monitor displays a diagram of Honeywell’s industrial cybersecurity reference solution featuring Palo Alto Networks Next-Generation Firewall technology.
If you’d like to learn more about Honeywell’s integration of Palo Alto Networks next-generation security technology, you can download this solution brief.
For more information about cybersecurity and the IIoT, take a moment to read some other blog posts I’ve authored on the subject.
Managing how firewalls operate in your network can be complex, especially if their locations and functions affect the settings you configure. Firewalls in one country might communicate with a different DNS server than firewalls in another country. Operations center firewalls might have different administrators than branch office firewalls. At the same time, maybe all your firewalls use the same roles for those administrators. You can simplify management by using a Panorama template to configure the settings that are common to all the firewalls in a particular location or functional group. However, if you have to manage both common and unique settings across many firewall groups, templates would be even more useful if you could modularize and reuse a few (building-block templates) to create many combinations. Template stacks make this not only possible, but easy.
Assigning firewalls to a template stack eliminates the need to configure common settings in each template because the firewalls inherit the settings from all the building-block templates in the stack. You can reduce both the number of templates and the number of settings in each by modularizing: create one template with common settings and function- or location-specific templates with unique settings. This approach is a lot less work than configuring all the common and unique settings in each template for each firewall group.
How Do I Configure a Template Stack?
The following infographic describes how to configure a template stack. The steps are:
Plan the templates and their priority order. If multiple templates have the same settings, the settings in higher priority templates override lower priority templates.
Create the templates.
Create the template stack and assign templates (in the desired priority order) and firewalls to the stack.
Unit 42 published a blog at the beginning of May titled “Prince of Persia,” in which we described the discovery of a decade-long campaign using a formerly unknown malware family, Infy, that targeted government and industry interests worldwide.
Subsequent to the publishing of this article, through cooperation with the parties responsible for the C2 domains, Unit 42 researchers successfully gained control of multiple C2 domains. This disabled the attacker’s access to their victims in this campaign, provided further insight into the targets currently victimized in this operation, and enabled the notification of affected parties.
Post Publication
In the week following the publication of the original blog, we observed no unusual changes to the C2 infrastructure. Existing domains did move to new IP addresses, as we had previously seen periodically. Some new install domains were added, adhering to naming conventions of current domains (see appendix for new IOCs).
The attackers developed a new version (31), and we observed this deployed against a single Canadian target.
The file descriptions remained essentially the same (“CLMediaLibrary Dynamic Link Library V3”). Most importantly, there was no change to the encoding key (now using offset 20, and offset 11 for second pass against URL encoding) that we had observed being used for the entire decade-long campaign, and documented in our previous blog. From this we conclude that the attackers were unaware of our initial report.
Sinkhole
Through cooperation with the parties responsible for the C2 domains, we took control of all but one of them, transferring the A records to a server we controlled. This prevented the attackers from being able to subsequently make any further changes to the domain configurations, issue commands to victims, or capture any further data for the majority of victims. An analysis of connections after transfer suggests that the attackers may have used a third-party service to try to understand why they had suddenly lost almost all of their traffic. Figure 1 shows that tool, a geographic representation of victim-C2 traffic, with all but one at that time now communicating with our sinkhole server.
Figure 1 Graphical representation of victim traffic to C2
We were able to analyze victim C2 traffic to understand who were victims of the Infy campaign. We identified 456 malware agents installed on 326 victim systems, in 35 countries. Figure 2 shows a geographical breakdown of victim locations. We noted in our original blog the large amount of targeting of Iranian citizens in this campaign, we observed almost one-third of all victims to be Iranian. Also of note was the low overall volume of victims, compared to, for example, crimeware campaigns.
Figure 2 Geographic location of victims. Please note that New Zealand has been omitted from this map only because we observed no victim activity there.
Versions
In our original blog, we noted two distinct primary variants of the Infy malware. In addition to the original “Infy” variant, we also see the newer, more sophisticated, interactive, and fuller-featured “Infy M” variant deployed against apparently-higher-value targets. Overall, 93% of all victims were infected with Infy, and 60% with Infy “M” (Figure 3). Combined with the low total number of victims, this suggests a great deal of care given to each individual campaign target. The large number of victims with both variants may relate to their complimentary feature set, or represent an “upgrade” path on victims from the original variant infection, later adding the “M” variant as targets appeared more compelling to the attackers.
Figure 3 Breakdown of Infy vs. Infy “M” infections
For the Infy “M” variant, we note that the majority of targets are using the latest version (7.8), and that none are using the older 6.x versions at all (Figure 4). This suggests that these higher-value targets are paid much more attention, being kept up-to-date with the latest version.
In contrast, for the more basic original Infy variant, we note a full spectrum of versions installed (Figure 5), with many victims on older versions – including the original, decade-old V1 – suggesting much less concern is paid to these individual targets (note that we did observe a small number of the older 6.x versions but these do not announce their version when connecting).
Figure 4 Infy “M” Victim versions
Figure 5 Infy”Original” Victim versions
Game Over
Shortly after the takedown, as well as a new Infy version (31), we also observed the registration of multiple domains using a previously-seen pattern, against known campaign IP addresses. Almost every domain in the pattern-range box4035[.]net – box4090[.]net (138.201.0.134). These were not observed in any sample C2 lists however. Bestwebstat[.]com was sinkholed by another operator.
Some victims infected with Infy versions 15-24 still used the C2 server us1s2[.]strangled[.]net, which remained in the hands of the attacker. In early June the attackers used this C2 to issue instructions to download new Infy “M” version 8.0 from us1s2[.]strangled[.]net/bdc.tmp. This was the first time we had observed an Infy variant being directly updated to Infy “M”. This used camouflage name “Macromedia v4”, changed from “v3” seen in Infy v31. They also removed the voice recording capability in this version.
uvps1[.]cotbm[.]com was used for data exfiltration, previously at 138.201.47.150, after publishing of our original blog moving to 144.76.250.205. It was also hosting malware updates at /themes/u.php.
They also added a curious C2 entry “hxxp://box” (note: defanged for publishing). It’s unclear how this should function; possibly a compromised victim intranet device, or the attackers have modified the HOSTS file on the victim computer.
After the take-down, the attackers began to add server IP addresses as well as domain names to their malware C2 list. They also slightly modified their ZIP password from “Z8(2000_2001ul” to “Z8(2000_2001uIEr3”. Their new malware version added antivirus checks for Kaspersky Labs, Avast, and Trend Micro. The malware data capture now searches for file extensions:
The malware continued to use the identical decryption key seen over the entire history of this campaign.
Mid-June, through cooperation with the parties responsible for the C2 domains and law enforcement, we were able to get the remaining C2 domains null-routed and the directly-IP-addressed server disabled. This is the end of a decade-long campaign, though we naturally expect to see this actor back in some other guise before long.
Thanks to the Malware research team – Yaron Samuel, Artiom Radune, Mashav Sapir, Netanel Rimer – for assistance in the takedown.
Appendix 1 – Exfiltration Algorithm
The malware uses a different algorithm than that used for encrypting the malware strings to encrypt the exfiltration data, including:
Keylogger data + language.
Malware logs – installation time, DLL path and name, log path, number of downloads, number of successful/failed connections.
Information about the victim computer: Time zone, list of drives and types, running processes, disk info.
First the malware adds 1 to all bytes, then an encryption key is initialized based on the victim computer name (the offset in the key is calculated by sum of the computer name letters %key length). Then the key is used to encrypt the data (see decrypt function). The encrypted data is then base64 encoded.
