Following recent high-profile breaches and vulnerabilities like Heartbleed, organizations around the world are becoming increasingly aware and interested in their cyber defense strategies. However, risky behavior is still rampant. In the first of a Threat Geek series on real-world examples of risky behavior, Ryan Vela describes the riskiest behavior he has seen: ignoring security vulnerabilities and threats and discusses ways organizations can overcome these behaviors.
When a company ignores security vulnerabilities, it is usually a result of an organizational culture where, for whatever reason, potential problems are not reported properly. I have seen this culture in effect during - and prior to - every breach case I’ve worked in the past decade. I have found the following scenarios all too common in many organizations. Caveat: I am not talking about situations where security personnel are not aware of vulnerabilities or threats. This is an entirely different situation and arguably equally as risky.
Risk: Security personnel do not report vulnerabilities or threats because they want to show that everything is under control and addressed during normal patch schedules.
Solution: Never, ever assume that you have every vulnerability and threat under control. Never, ever assume that your patch schedule will adequately address threats.
For the past 15 years I have been doing cyber incident response in both the public and private sectors. While serving as follower, leader, coordinator, liaison, consultant, and advisor on countless small, medium, and large incidents, I have come to learn that there is a small set of rules that apply to every single incident response and to every single person serving as part of an incident response team. If you are a cyber incident responder, then you may know all of this already. However, I will explain why these ten rules are necessary.
1. Do no harm
Do not perform any action or cause inaction that will cause injury or endanger the life of another human being. As a second priority, do not perform any action or cause inaction that will lead to risk of harm to animals, the environment, or property. The act of doing or not doing harm is often considered in terms of legal acceptability. While the laws of the jurisdiction are important, they may not protect all of the people all of the time.
2. Always act ethically
Act in a manner that is good and just. In deciding how to act, use empathy to place yourself in another affected person’s shoes. Be honest, respectful, and open to alternative opinions on ethical outcomes.
3. Always act and present yourself professionally
Do unto others as you would have them do unto you. If you expect to be treated as a professional, then treat others professionally. Likewise, present yourself in a manner befitting someone who is worthy of respect.
4. Always maintain operational security
Do not allow unauthorized people or tools to gain visual, physical, or auditory access to case data. Do not leave documents, notes, or drawings open for unauthorized viewing. Properly encrypt communication, data in transit, and data at rest. Secure all data in a controlled manner when not in possession. Ensure that colleagues are following proper operational security.
5. Never release confidential information
Loose lips sink ships. Do not talk about what work you are doing to anyone who has no need to know – releasing information about an incident can tip-off adversaries and move the cyber event into a less controlled situation. Additionally, releasing information to the public arena can hurt an organization’s reputation and brand.
In the past 10 years of working on cyber breach incident responses, I have learned that while no two incident responses are the same there are critical mistakes that many IR firms and in-house security staff make. All too often my teams are called in to replace an existing IR firm that isn’t doing the job properly. Here are four pitfalls that I see unecessarily creating anxiety, increasing costs, and leaving companies without the necessary information to protect their network in the future.
1. Do not jump to eradicate without containment. In several breaches, the client started immediately deleting malware. Like stepping on a mound, the ants scattered and started mounds all over the place. In one case, the actors could not get in from their main backdoor, so they activated another backdoor and planted multiple additional hidden backdoors. The goal should be to ensure as much containment as possible so that when eradication occurs, you get all of the ants in one stomp. Of course, this is easier said than done because you may never know all of the backdoors on your network; especially if the backdoors are custom. The bottom line is never start eradication with partial containment. Don’t lose your element of surprise and let the investigation get the information it needs to secure the network.
That being said, containment and eradication should be coordinated. The goal is to secure the network and disrupt attack activity. The two efforts are dependent upon one another in that a) containment measures such as network monitoring should be used to verify eradication measures, and b) eradication measures should be built upon evidence found during containment measures such as network monitoring and scanning file systems for artifacts.
If an organization performs containment with eradication as a second thought, then the actors will twist and turn around containment measures. In one breach case, the actors used the same backdoors that were dormant on the network for months. While containment monitored the actors actions, the actors were still able to penetrate the network at will. In another breach case, eradication started even before my team could get on scene; the IT staff was deleting malware from the web servers ad hoc. By the time my team arrived, the actors had successfully edited security logs, turned of logging on some servers, deleted their malware, deleted their aggregation files, and successfully wiped their tracks. At this point we were unable to determine the full impact of the breach.
During large breaches coordinating both containment and eradication can take a huge effort, but I have learned that there has to be a single leader in charge of coordinating the activities of both. This person’s sole responsibility is to ensure that containment is progressing at a pace equal to the effectiveness of eradication. The individuals performing both containment and eradication must receive and adhere to orders from this coordinating leader. No unilateral actions should be taken without first reviewing it through the coordinating leader.
The breaches I am using as examples were large in scope. When doing containment and eradication for large breaches, actions cannot typically be made within seconds. Careful planning and thorough action steps should be established prior to pressing any buttons. And therein lays the rub: how do you react quickly while trying to be effective? The answer is efficiency and experience. Organizations should ensure that they are partnering with a cybersecurity firm that has the experience in working large breaches. There are plenty of firms out there that have experience working on many small or medium breaches, but only a very small handful that have consistently worked very large cyber breaches. My organization is one who has worked some of the largest cyber breaches ever.
2. Do not over manage your technical staff. During two large breaches of the past 18 months, I sat as the IR advisor for the company affected and the IR third party hired to do the containment, investigation, and eradication. The two breaches demonstrated two very distinct methods of managing the IR third party and internal security staff. One method was good and one was bad.
The bad method was where the upper management (i.e. Director of IT and Senior Manager of IT Security) would hold daily meetings with all of the IR staff, leverage a project manager to list all IR tasks being performed by anyone and everyone, and request daily status reports from every task group (there were over 8 task groups for the IR). The result was an IR staff that spent 75% of their day either in meetings or preparing for meetings. The productivity of the group plummeted to lows I had never seen before with an administrative document file share with thousands of documents: probably only about 15 documents, but 100 versions of each document or updates to each document.
I realized that the management either a) did not trust their staff or the third party – least likely, or b) felt that because their jobs (right or wrong) were on the line, they should know everything at all times and micromanage the entire process – most likely. During the first hours and days of an IR, time is of the essence. To the detriment of efficiency and ultimately effectiveness of containment, the upper management performed poorly.
The good method was a case where the upper management had a long standing relationship with the IR third party and trusted them to get the job done. The IR third party had a single leader for the engagement who met with the Director of IT once per day for about 30 minutes. During the daily meeting, the third party leader would give the Director of IT an update on what occurred over the past 24 hours, what the teams were doing today, and what we expect over the next 24 hours. The meetings were exceedingly efficient and the Director of IT took notes. These notes would then be put into a report that the Director of IT could take to her superiors on a weekly basis.
Using what I call the good method above, the breach engagement took only a couple months to contain, investigate and eradicate. Under the bad method above, the breach engagement required over 6 months to contain and eradiate. Six months should be unacceptable by anyone’s standards.
Yesterday, we posted Fidelis Threat Advisory #1013 detailing a phishing campaign utilizing a remote access trojan (RAT) known as Unrecom. Over the past two weeks, we have observed an increase in attack activity against the U.S. state and local government, technology, advisory services, health, and financial sectors associated with this campaign. Attacks have also been observed against the financial sector in Saudi Arabia and Russia.
We consider this phishing campaign important because:
The targets we have observed are in the U.S. state and local government, technology, advisory services, health and financial sectors.
The attached malware is known as Unrecom, a comprehensive multi-platform Java-based RAT.
Unrecom has evolved from previous high-profile RATs such as Adwind and Frutas. Both of these have been observed in threat activity in the Middle East.
The Unrecom samples that we have analyzed are detected by a very small set of AntiVirus and antimalware products.
The samples that we have analyzed clearly share command-and-control infrastructure with malware such as DarkComet and Arcom RAT, observed in other campaigns. Significantly, these malware families have been observed in large volumes in the Middle East.
In the past two weeks, we have observed an increase in attack activity against the U.S. state and local government, technology, advisory services, health, and financial sectors through phishing emails with what appears to be a remote access trojan (RAT) known as Unrecom. The attack has also been observed against the financial sector in Saudi Arabia and Russia.
As Unrecom is a comprehensive multi-platform Java-based remote access tool, currently not detected by most AntiVirus products, it presents a risk to a large number of potential victims, regardless of operating system. The following is a screenshot of the Unrecom RAT v.2.0 (Version in Spanish):
Over time, various reports in the community have documented the evolution of this tool. This evolution is to be expected, but its low detection rate, recent use this month through phishing emails campaigns against multiple sectors in the U.S. and association with past campaigns involving a variety of RATs captured our attention. The evolution of Unrecom RAT dates from its beginnings as a tool known as Frutas RAT, subsequently branded as Adwind RAT, and now Unrecom RAT.
In 2013, it was reported that Frutas RAT was used in phishing email campaigns against high profile companies in Europe and Asia in sectors such as finance, mining, telecom, and government.
Unrecom RAT provides the attacker with full control over the compromised system, once infected. It has some of the following capabilities:
Collection of System Information (e.g. IP, OS version, memory RAM information, Java version, Computer Name, User account compromised, etc.)
Upload & Execute additional malware, typically exploiting vulnerabilities derived from collected system information
Capture Webcam and Microphone, without user notification
Remote Desktop to watch user activity
File Manager allowing access to files in the context of the current user
Browser Password theft
Keylogging to capture passwords otherwise obscured from viewing
In the past, variants of the DarkComet and AcromRAT malware have also been observed beaconing to the same Command & Control (CnC) servers used by the Unrecom RAT in this campaign.
This document will provide information about the recent phishing campaigns observed with this RAT and some of the network indicators.