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.
Industry analyst firm Gartner predicts that the infrastructure as a service (IaaS) market will grow 38.4% in 2016 to reach $22.4 billion by the end of the year. A new report from the Cloud Security Alliance (download a free copy here) finds that Microsoft is quickly catching up with industry leader Amazon in the race to tap this growing market. Amazon, Google, and Microsoft collectively own 82.0% of the IaaS market today. Even at companies that have a strict “no cloud” philosophy, IT leaders admit that nearly one fifth of their computing workloads will be in the public cloud this year versus their own data centers.
Amazon remains the dominant IaaS provider but Microsoft is closing their gap in market share. IT professionals at 37.1% of companies indicated that Amazon AWS is the primary IaaS platform at their organization. Microsoft Azure is a close second, at 28.4% followed by Google Cloud Platform at 16.5%. Enterprises using public cloud benefit in many ways including greater agility, lower cost of ownership, and faster time to market. IaaS providers, meanwhile, are also benefitting. In April 2016, Amazon reported that AWS is its most profitable division and is growing 64% annually.
IaaS adoption trends
Enterprises are increasingly relying on public cloud infrastructure providers such as Amazon, Microsoft, and Google for their computing resources, rather than managing their own data centers. A plurality of organizations (45.1%) have a “hybrid cloud” philosophy, another 25.1% prefer private cloud, and 21.5% take a predominantly public cloud approach. Just 8.2% of enterprises have a “no cloud” philosophy. Today, 31.2% of an enterprise’s computing resources come from infrastructure as a service (IaaS) providers. IT professionals expect that number to rapidly grow to 41.0% of computing workloads in the next 12 months.
Not surprisingly, companies with a “public cloud” philosophy have more computing in the public cloud. At these companies, nearly one half (47.8%) of computing resides in the public cloud today and IT professionals at these organizations expect a majority of their computing (56.5%) will reside in the public cloud 12 months from now. Even companies with a “no cloud” philosophy estimate that 14.6% of their computing nevertheless resides in the public cloud, and they expect that number will grow to 18.8% in the next 12 months. There is a sizable amount of computing in public cloud IaaS even for organizations that are philosophically opposed to cloud.
There is a clear correlation between company size and IaaS adoption. Companies with fewer employees rely on public IaaS platforms for more of their computing today. Companies with 1-1,000 employees have the largest share of computing workloads in the public cloud (37.1%) versus companies with more than 10,000 employees (22.3%). However, in the next 12 months, companies with more than 10,000 employees are anticipating growing their use of IaaS to 32.9%, which would eclipse companies with 5,000-10,000 employees and would put them roughly on par with companies with just 1,000-5,000 employees. Public IaaS appears to be reaching an inflection point in the enterprise.
Barriers to IaaS projects
Despite the rapid growth of public cloud infrastructure, there are still barriers holding back IaaS adoption. The most common barrier reported by IT professionals is concern about the security of the IaaS platform itself (62.1% of respondents). The next most common roadblock is also security related – 40.5% of respondents indicated that concern about the ability to secure applications deployed on IaaS platforms is a barrier to adoption. The third most common barrier, reported by 37.9% of respondents, is the inability to store data within their country to comply with data privacy laws (e.g. EU General Data Protection Regulation).
Despite concerns, overall confidence in cloud
Despite concerns about security, an overwhelming 61.6% of IT leaders believe that, generally speaking, custom applications they deploy on IaaS platforms are as secure, if not more secure, than applications they deploy in their own datacenter. That may be due in part to the significant investments cloud providers have made in their own security, and in achieving compliance certifications such as ISO 27001 and 27018 to demonstrate their investments. It could also be due to a growing sentiment that cloud companies such as Amazon, Microsoft, and Google can dedicate far more resources to IT security than the average company where IT is not their core business.
Cameron Coles, Director of Product Marketing, Skyhigh Networks
The Cloud Security Alliance (CSA) today announced the availability of a new research brief from the Quantum-Safe Security (QSS) Working Group titled Quantum Random Number Generators, a whitepaper that looks to detail the impact of randomness on security in an effort to develop the building blocks for effective encryption.
Quantum computing, which involves joining the power of atoms and molecules to perform memory and processing tasks, has the potential to perform certain calculations significantly faster than any silicon-based computer. When fully realized, quantum computing will have a far greater capability than today’s modern day supercomputer with performance gains in the billion-fold realm and beyond. With its advent, there is a growing area of concern and attention for businesses and security professionals.
A random number is generated by a process whose outcome is unpredictable, and which cannot be reliably reproduced. Random numbers are foundational to information security and are the building blocks of encryption, authentication, signing, key wrapping, one-time codes, nonces, and other cryptographic applications. The performance and characteristics of random number generators have a strong impact on security. Attackers do not usually attempt to crack encryption, they simply steal or guess keys. Poor quality or insufficient quantity of random numbers make it that much easier, reducing security well below its designed level and making the overall system vulnerable.
Headed up by co-chairs, Bruno Huttner of ID Quantique and Jane Melia of QuintessenceLabs, the QSS – Working Group is focused on stimulating the understanding, adoption, use and widespread application of quantum-safe cryptography to commercial institutions, policy makers, and all relevant government bodies. Using quantum random numbers is one of the strategies recommended by the QSS – WG to protect and future proof data against improvements to computer power, new attack strategies, weak random number generators, and the emergence of quantum computers.
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.
![TechDocs_logo_lrg_final[1]](https://i0.wp.com/researchcenter.paloaltonetworks.com/wp-content/uploads/2016/05/TechDocs_logo_lrg_final1.jpg){kind=logo}
