Monthly Archives: September 2019

Advisory – 2019-129: File Disclosure Vulnerability in Pulse Connect Secure VPN Software

Overview The Australian Signals Directorate’s Australian Cyber Security Centre is aware of a vulnerability that exists in the Pulse Connect Secure Virtual Private Network (VPN) solution. We advise users to ensure their systems are patched and up to date. The Pulse VPN Vulnerability, also known as CVE-2019-11510, was initially disclosed in April 2019 but has resurfaced after multiple reports of exploitation and the disclosure of working exploits available for use on Pastebin and GitHub.

The FireEye OT-CSIO: An Ontology to Understand, Cross-Compare, and Assess Operational Technology Cyber Security Incidents

The FireEye Operational Technology Cyber Security Incident Ontology (OT-CSIO)

While the number of threats to operational technology (OT) have significantly increased since the discovery of Stuxnet – driven by factors such as the growing convergence with information technology (IT) networks and the increasing availability of OT information, technology, software, and reference materials – we have observed only a small number of real-world OT-focused attacks. The limited sample size of well-documented OT attacks and lack of analysis from a macro level perspective represents a challenge for defenders and security leaders trying to make informed security decisions and risk assessments.

To help address this problem, FireEye Intelligence developed the OT Cyber Security Incident Ontology (OT-CSIO) to aid with communication with executives, and provide guidance for assessing risks. We highlight that the OT-CSIO focuses on high-level analysis and is not meant to provide in-depth insights into the nuances of each incident.

Our methodology evaluates four categories, which are targeting, impact, sophistication, and affected equipment architecture based on the Purdue Model (Table 7). Unlike other methodologies, such as MITRE's ATT&CK Matrix, FireEye Intelligence's OT-CSIO evaluates only the full aggregated attack lifecycle and the ultimate impacts. It does not describe the tactics, techniques, and procedures (TTPs) implemented at each step of the incident. Table 1 describes the four categories. Detailed information about each class is provided in Appendix 1.


Table 1: Categories for FireEye Intelligence's OT-CSIO

The OT-CSIO In Action

In Table 2 we list nine real-world incidents impacting OT systems categorized according to our ontology. We highlight that the ontology only reflects the ultimate impact of an incident, and it does not account for every step throughout the attack lifecycle. As a note, we cite public sources where possible, but reporting on some incidents is available to FireEye Threat Intelligence customers only.

Incident

Target

Sophistication

Impact

Impacted Equipment

Maroochy Shire Sewage Spill

(2000)

ICS-targeted

Medium

Disruption

Zone 3

Stuxnet

(2011)

ICS-targeted

High

Destruction

Zones 1-2

Shamoon

(2012)

ICS-targeted

Low

Destruction

Zone 4-5

Ukraine Power Outage

(2015)

ICS-targeted

Medium

Disruption, Destruction

Zone 2

Ukraine Power Outage

(2016)

ICS-targeted

High

Disruption

Zones 0-3

WannaCry Infection on HMIs

(2017)

Non-targeted

Low

Disruption

Zone 2-3

TEMP.Isotope Reconnaissance Campaign

(2017)

ICS-targeted

Low

Data Theft

Zones 2-4

TRITON Attack

(2017)

ICS-targeted

High

Disruption (likely building destructive capability)

Zone Safety, 1-5

Cryptomining Malware on European Water Utility

(2018)

Non-targeted

Low

Degradation

Zone 2/3

Financially Motivated Threat Actor Accesses HMI While Searching for POS Systems

(2019)

Non-targeted

Low

Compromise

Zone 2/3

Portable Executable File Infecting Malware Impacting Windows-based OT assets

(2019)

Non-targeted

Low

Degradation

Zone 2-3

Table 2: Categorized samples using the OT-CSIO

The OT-CSIO Matrix Facilitates Risk Management and Analysis

Risk management for OT cyber security is currently a big challenge given the difficulty of assessing and communicating the implications of high-impact, low-frequency events. Additionally, multiple risk assessment methodologies rely on background information to determine case scenarios. However, the quality of this type of analysis depends on the background information that is applied to develop the models or identify attack vectors. Taking this into consideration, the following matrix provides a baseline of incidents that can be used to learn about past cases and facilitate strategic analysis about future case scenarios for attacks that remain unseen, but feasible.


Table 3: The FireEye OT-CSIO Matrix

As Table 3 illustrates, we have only identified examples for a limited set of OT cyber security incident types. Additionally, some cases are very unlikely to occur. For example, medium- and high-sophistication non-targeted incidents remain unseen, even if feasible. Similarly, medium- and high-sophistication data compromises on OT may remain undetected. While this type of activity may be common, data compromises are often just a component of the attack lifecycle, rather than an end goal.

How to Use the OT-CSIO Matrix

The OT-CSIO Matrix presents multiple benefits for the assessment of OT threats from a macro level perspective given that it categorizes different types of incidents and invites further analysis on cases that have not yet been documented but may still represent a risk to organizations. We provide some examples on how to use this ontology:

  • Classify different types of attacks and develop cross-case analysis to identify differences and similarities. Knowledge about past incidents can be helpful to prevent similar scenarios and to think about threats that have not been evaluated by an organization.
  • Leverage the FireEye OT-CSIO Matrix for communication with executives by sharing a visual representation of different types of threats, their sophistication and possible impacts. This tool can make it easier to communicate risk despite the limited data available for high-impact, low-frequency events. The ontology provides an alternative to assess risk for different types of incidents based on the analysis of sophistication and impact, where increased sophistication and impact generally equates to higher risk.
  • Develop additional case scenarios to foresee threats that have not been observed yet but may become relevant in the future. Use this information as support while working on risk assessments.

Outlook

FireEye Intelligence's OT-CSIO seeks to compile complex incidents into practical diagrams that facilitate communication and analysis. Categorizing these events is useful for visualizing the full threat landscape, gaining knowledge about previously documented incidents, and considering alternative scenarios that have not yet been seen in the wild. Given that the field of OT cyber security is still developing, and the number of well-documented incidents is still low, categorization represents an opportunity to grasp tendencies and ultimately identify security gaps.

Appendix 1: OT-CSIO Class Definitions

Target

This category comprises cyber incidents that target industrial control systems (ICS) and non-targeted incidents that collaterally or coincidentally impact ICS, such as ransomware.


Table 4: Target category

Sophistication

Sophistication refers to the technical and operational sophistication of attacks. There are three levels of sophistication, which are determined by the analyst based on the following criteria.


Table 5: Sophistication category

Impact

The ontology reflects impact on the process or systems, not the resulting environmental impacts. There are five classes in this category, including data compromise, data theft, degradation, disruption, and destruction.


Table 6: Impact category

Impacted Equipment

This category is divided based on FireEye Intelligence's adaptation of the Purdue Model. For the purpose of this ontology, we add an additional zone for safety systems.


Table 7: Impacted equipment

2019 Flare-On Challenge Solutions

We are pleased to announce the conclusion of the sixth annual Flare-On Challenge. The popularity of this event continues to grow and this year we saw a record number of players as well as finishers. We will break down the numbers later in the post, but right now let’s look at the fun stuff: the prize! Each of the 308 dedicated and amazing players that finished our marathon of reverse engineering this year will receive a medal. These hard-earned awards will be shipping soon. Incidentally, the number of finishers smashed our estimates, so we have had to order more prizes.

We would like to thank the challenge authors individually for their great puzzles and solutions.

  1. Memecat Battlestation: Nick Harbour (@nickaharbour)
  2. Overlong: Eamon Walsh
  3. FlareBear: Mortiz Raabe (@m_r_tz)
  4. DnsChess: Eamon Walsh
  5. 4k demo: Christopher Gardner (@t00manybananas)
  6. Bmphide: Tyler Dean (@spresec)
  7. Wopr: Sandor Nemes (@sandornemes)
  8. Snake: Alex Rich (@AlexRRich)
  9. Reloaderd: Sebastian Vogl
  10. MugatuWare: Blaine Stancill (@MalwareMechanic)
  11. vv_max: Dhanesh Kizhakkinan (@dhanesh_k)
  12. help: Ryan Warns (@NOPAndRoll)

And now for the stats. As of 10:00am ET, participation was at an all-time high, with 5,790 players registered and 3,228 finishing at least one challenge. This year had the most finishers ever with 308 players completing all twelve challenges.

The U.S. reclaimed the top spot of total finishers with 29. Singapore strengthened its already unbelievable position of per-capita top Flare-On finishing country with one Flare-On finisher per every 224,000 persons living in Singapore. Rounding out the top five are the consistent high-finishing countries of Vietnam, Russia, and China.

 

All the binaries from this year’s challenge are now posted on the Flare-On website. Here are the solutions written by each challenge author:

  1. SOLUTION #1
  2. SOLUTION #2
  3. SOLUTION #3
  4. SOLUTION #4
  5. SOLUTION #5
  6. SOLUTION #6
  7. SOLUTION #7
  8. SOLUTION #8
  9. SOLUTION #9
  10. SOLUTION #10
  11. SOLUTION #11
  12. SOLUTION #12

5 Steps to Managing Security Risks Associated with Your Partners & Vendors

Today most businesses find themselves in the position of requiring a strategic partnership with a third-party to address many different business needs and requirements. These partnerships provide a benefit to the primary company typically in the form of cost savings (labor/operational), increased quality of product or service, or an increased speed with which the product or service is delivered. Additionally, partnerships may be used to address deficiencies within the business operation such as a talent shortage. Organizations may even be compelled to partner with a third-party by industry or regulatory compliance mandates as is the case with PCI-DSS or GLBA to name a couple examples.

These strategic partnerships certainly provide a benefit to the primary organization, but also introduce an additional level of risk. A Soha Systems survey indicates 63 percent of all data breaches are linked directly or indirectly to third-party access. From a network and information security stance, an organization’s security posture is only as strong as its weakest link.

We’ve seen headlines in the news that illustrate this time and time again.  Take, for instance, the recent DoorDash breach that exposed the data of 4.9M merchants, customers, and workers as a result of a third-party service provider.  Or the infamous 2013 Target breach in which Target’s corporate network was compromised through a contracted third-party HVAC company, Fazio Mechanical. The attack initiated through a phishing email which led to malware installation on Fazio Mechanical’s systems and continued until the attackers had infected Target’s POS terminals and customer data was stolen. Through relaxed security policies, practices, and implementations with both parties, Target experienced costs to the corporation in the form of an $18.5M lawsuit settlement, damage to the company’s reputation and resulting lost business, as well as the resources expended to significantly improve their security posture to reduce the possibility of future attacks.

Even if the security risk started with or is wholly due to a service provider’s lax security posture, the primary organization will ultimately bear responsibility for the breach, especially in the mind of the customer. From a legal standpoint, the main organization may often find it difficult to demonstrate that sufficient steps were taken to manage its third-party risk and could be considered liable for the breach and therefore held responsible for the ensuing costs of remediation.

It can be a difficult task to mitigate the inherited risks associated with a company’s security posture over which you have little control. Naturally, how a given organization manages any risk will depend greatly on the business requirements and goals of that organization.

The following are steps any organization can take to begin the process of managing third-party risks:

Step 1: Obtain Executive leadership buy-in and support.

This is essential for any risk management program to succeed.  Leadership support will provide necessary oversight and will stress the importance of this endeavor to the entire organization.

Step 2: Perform a thorough in-house risk and vulnerability assessment to gauge your organization’s security posture.

Implement any needed changes and address any deficiencies to your own organization’s acceptable risk level.

Step 3: Evaluate the security policies, procedures, and implementations of current partners to assess the risk they may pose to your organization.

If deficiencies are discovered, have conversations with the partner organization to address these gaps.  This may involve revisiting current contracts.

Step 4: Prior to contracting with potential vendors, investigate the security practices of these organizations and discuss expectations of how information security will be handled should a partnership be realized.

Due  diligence is vital in evaluating the security posture and risks posed by these potential alliances.

Step 5: To remain successful, implement a risk management program that includes ongoing risk measurement and evaluation through auditing and monitoring.

New risks and vulnerabilities may appear at any time and an organization must be adaptable to these changes.

It’s not all doom and gloom when it comes to third-party partnerships.  After all, they can provide significant value to business operations. The important takeaway is their risks are your risks, and your organization will bear the burden should an accident occur. By implementing a risk management program following the steps above, you can mitigate third-party risk, providing you peace of mind and long-term success.

The post 5 Steps to Managing Security Risks Associated with Your Partners & Vendors appeared first on GRA Quantum.

GRA Quantum Named to 2019 MSSP Alert Top 200 Managed Security Services Providers List

Third Annual List Honors Leading MSSPs, MDR Service Providers & Cybersecurity Companies

Salt Lake City, UT., Sept. 24, 2019 — MSSP Alert, published by After Nines Inc., has named GRA Quantum to the Top 200 MSSPs list for 2019 (http://www.msspalert.com/top200). The list and research identify and honor the top 200 managed security services providers (MSSPs) that specialize in comprehensive, outsourced cybersecurity services.

Previous editions of the annual list honored 100 MSSPs. This year’s edition, at twice the size, reflects MSSP Alert’s rapidly growing readership and the world’s growing consumption of managed security services. MSSP Alert’s readership has grown every month, year over year, since launching in May 2017.

The Top 200 MSSP rankings are based on MSSP Alert’s 2019 readership survey combined with aggregated third-party research. MSSPs featured throughout the list and research proactively monitor, manage and mitigate cyber threats for businesses, government agencies, educational institutions and nonprofit organizations of all sizes.

“We’re honored to be recognized in MSSP Alert’s Top 200 MSSPs list after having only launched our Security Operations Center and Managed Security Services in 2018,” said Tom Boyden, President, GRA Quantum. “We pride ourselves in our dedication to offer comprehensive, enterprise-level MSS solutions to small and mid-sized firms.”

“Our technology-agnostic approach sets us apart from most MSS vendors,” added Jen Greulich, Director, Managed Security Services, GRA Quantum. “This allows us to select the best tools for our clients and seamlessly integrate into their existing technologies.”

“After Nines Inc. and MSSP Alert congratulate GRA Quantum on this year’s honor,” said Amy Katz, CEO of After Nines Inc. “Amid the ongoing cybersecurity talent shortage, thousands of MSPs and IT consulting firms are striving to move into the managed security market. The Top 200 list honors the MSSP market’s true pioneers.”

Learn more about GRA Quantum’s Managed Security Services.

 

MSSP Alert: Top 200 MSSPs 2019 – Research Highlights

The MSSP Alert readership survey revealed several major trends in the managed security services provider market. Chief among them:

  • The Top 5 business drivers for managed security services are talent shortages; regulatory compliance needs; the availability of cloud services; ransomware attacks; and SMB customers demanding security guidance from partners.
  • 69% of MSSPs now run full-blown security operations centers (SOCs) in-house, with 19% leveraging hybrid models, 8% completely outsourcing SOC services and 4% still formulating strategies.
  • The Top 10 cybersecurity vendors assisting MSSPs, in order of reader preference, are Fortinet, AT&T Cybersecurity, Cisco Systems, BlackBerry Cylance, Palo Alto Networks, Microsoft, SonicWall, Carbon Black, Tenable and Webroot (a Carbonite company).
  • Although the overall MSSP market enjoys double-digit percentage growth rates, many of the Top 200 MSSPs have single-digit growth rates because they are busy investing in next-generation services – including managed detection and response (MDR), SOC as a Service, and automated penetration testing.

The Top 200 MSSPs list and research are overseen by Content Czar Joe Panettieri (@JoePanettieri). Find the online list and associated report here: http://www.msspalert.com/top200.

About After Nines Inc.

After Nines Inc. provides timeless IT guidance for strategic partners and IT security professionals across ChannelE2E (www.ChannelE2E.com) and MSSP Alert (www.MSSPAlert.com).  ChannelE2E tracks every stage of the IT service provider journey — from entrepreneur to exit. MSSP Alert is the global voice for Managed Security Services Providers (MSSPs).

  • For sponsorship information contact After Nines Inc. CEO Amy Katz, Amy@AfterNines.com
  • For content and editorial questions contact After Nines Inc. Content Czar Joe Panettieri, Joe@AfterNines.com

The post GRA Quantum Named to 2019 MSSP Alert Top 200 Managed Security Services Providers List appeared first on GRA Quantum.

SB220 Nevada Law

The Privacy Security and Risk Conference is next week in Las Vegas. While the conversation will most likely be dominated by the California Consumer Privacy Act (CCPA), there is another privacy law that should probably be on the agenda as well. That’s right, Nevada also has a new privacy law, specifically SB220. This new privacy […]

The post SB220 Nevada Law appeared first on Privacy Ref.

Five Thoughts on the Internet Freedom League

In the September/October issue of Foreign Affairs magazine, Richard Clarke and Rob Knake published an article titled "The Internet Freedom League: How to Push Back Against the Authoritarian Assault on the Web," based on their recent book The Fifth Domain. The article proposes the following:

The United States and its allies and partners should stop worrying about the risk of authoritarians splitting the Internet. 

Instead, they should split it themselves, by creating a digital bloc within which data, services, and products can flow freely, excluding countries that do not respect freedom of expression or privacy rights, engage in disruptive activity, or provide safe havens to cybercriminals...

The league would not raise a digital Iron Curtain; at least initially, most Internet traffic would still flow between members and nonmembers, and the league would primarily block companies and organizations that aid and abet cybercrime, rather than entire countries. 

Governments that fundamentally accept the idea of an open, tolerant, and democratic Internet but that struggle to live up to such a vision would have an incentive to improve their enforcement efforts in order join the league and secure connectivity for their companies and citizens. 

Of course, authoritarian regimes in China, Russia, and elsewhere will probably continue to reject that vision. 

Instead of begging and pleading with such governments to play nice, from now on, the United States and its allies should lay down the law: follow the rules, or get cut off.

My initial reaction to this line of thought was not encouraging. Rather than continue exchanging Twitter messages, Rob and I had a very pleasant phone conversation to help each other understand our points of view. Rob asked me to document my thoughts in a blog post, so this is the result.

Rob explained that the main goal of the IFL is to create leverage to influence those who do not implement an open, tolerant, and democratic Internet (summarized below as OTDI). I agree that leverage is certainly lacking, but I wondered if the IFL would accomplish that goal. My reservations included the following.

1. Many countries that currently reject the OTDI might only be too happy to be cut off from the Western Internet. These countries do not want their citizens accessing the OTDI. Currently dissidents and others seeking news beyond their local borders must often use virtual private networks and other means to access the OTDI. If the IFL went live, those dissidents and others would be cut off, thanks to their government's resistance to OTDI principles.

2. Elites in anti-OTDI countries would still find ways to access the Western Internet, either for personal, business, political, military, or intelligence reasons. The common person would be mostly likely to suffer.

3. Segregating the OTDI would increase the incentives for "network traffic smuggling," whereby anti-OTDI elites would compromise, bribe, or otherwise corrupt Western Internet resources to establish surreptitious methods to access the OTDI. This would increase the intrusion pressure upon organizations with networks in OTDI and anti-OTDI locations.

4. Privacy and Internet freedom groups would likely strongly reject the idea of segregating the Internet in this manner. They are vocal and would apply heavy political pressure, similar to recent net neutrality arguments.

5. It might not be technically possible to segregate the Internet as desired by the IFL. Global business does not neatly differentiate between Western and anti-OTDI networks. Similar to the expected resistance from privacy and freedom groups, I expect global commercial lobbies to strongly reject the IFL on two grounds. First, global businesses cannot disentangle themselves from anti-OTDI locations, and second, Western businesses do not want to lose access to markets in anti-OTDI countries.

Rob and I had a wide-ranging discussion, but these five points in written form provide a platform for further analysis.

What do you think about the IFL? Let Rob and I know on Twitter, via @robknake and @taosecurity.

PROTECTING YOUR SOCIAL MEDIA ACCOUNTS



The Internet has made our lives easier in so many ways. However, you need to know how you can protect your privacy and avoid fraud. With all of the personally identifiable information we share on social sites – Hackers have only become more adept at locating that information and using it to gain access to our accounts.

What’s worse, if you’re on social media while at work and connected to the corporate network and your account gets hacked, you’ve now made your entire company vulnerable.

Social media represents the largest modern threat vector – it has more connectivity (billions of people), it’s more trusted (everyone is your friend) and its less visibility (simply by its nature) than any other communication or business platform.


Security teams need to join their sales, marketing and customer success groups in the digital era, follow social media security best practices and implement risk monitoring and remediation technology around social media to secure their organization’s future.

In the case of social media accounts, you should make absolutely sure the email they are linked to has as much protection as possible. It’s a single point of failure. since everyone gets their password reset emails there. That’s the major way people get in.



Tips for Securing your Social Media Accounts
Create a unique email for social media. If you are compromised, hackers won’t have access to any other valuable information.

Limit Biographical Information. Many social media websites require biographical information to open an account –You can limit the information made available to other social media users.

Enable two-factor authentication. This is one of the best methods for protecting your accounts from unauthorized access.

Close unused accounts. With security, you can’t take the approach of ‘out of sight, out of mind,’ so it’s best to terminate your account altogether if it’s no longer in use.

Update mobile apps regularly. These updates can protect you from threats that have already been identified.

Practice good password hygiene. Pick a “strong” password, keep it secure, change it frequently, and Use different passwords for different accounts.



Monitor your accounts regularly. The sooner you notice suspicious activity, the sooner you can recover your account.

Secure your mobile devices. If your mobile devices are linked to your social media accounts, make sure that these devices are password protected in case they are lost or stolen.

Adjust the default privacy settings. Lock down your account from the start. Select who can see what posts, when and what information is shown on your profile, to who.

Be mindful accessing accounts on public wireless.If you have to connect, log completely out of your account after your session.

Accept friend requests selectively. There is no obligation to accept a “friend” request of anyone you do not know or do not know well. Fake accounts are often used in social engineering.

Use caution with public computers or wireless connections. Try to avoid accessing your social media accounts on public or other shared computers. But if you must do so, remember to log out completely by clicking the “log out” button on the social media website to terminate the online session.

Limit 3rd party app usage. Only authorize legitimate applications, and be sure to read the details of what you are authorizing the particular app to have access to.



What do I do If I’ve Been Hacked?
First things, don’t panic. If possible, log into your account and change your password.
Review the recent activity on the account and delete anything that was not posted by you.

If you find spam, be sure to report it.

Check your bank account and other accounts to ensure that they were not also compromised.

At this point, enable two-factor authentication.

In addition, you should know that Social media provide support to recover your account.

Open Sourcing StringSifter

Malware analysts routinely use the Strings program during static analysis in order to inspect a binary's printable characters. However, identifying relevant strings by hand is time consuming and prone to human error. Larger binaries produce upwards of thousands of strings that can quickly evoke analyst fatigue, relevant strings occur less often than irrelevant ones, and the definition of "relevant" can vary significantly among analysts. Mistakes can lead to missed clues that would have reduced overall time spent performing malware analysis, or even worse, incomplete or incorrect investigatory conclusions.

Earlier this year, the FireEye Data Science (FDS) and FireEye Labs Reverse Engineering (FLARE) teams published a blog post describing a machine learning model that automatically ranked strings to address these concerns. Today, we publicly release this model as part of StringSifter, a utility that identifies and prioritizes strings according to their relevance for malware analysis.

Goals

StringSifter is built to sit downstream from the Strings program; it takes a list of strings as input and returns those same strings ranked according to their relevance for malware analysis as output. It is intended to make an analyst's life easier, allowing them to focus their attention on only the most relevant strings located towards the top of its predicted output. StringSifter is designed to be seamlessly plugged into a user’s existing malware analysis stack. Once its GitHub repository is cloned and installed locally, it can be conveniently invoked from the command line with its default arguments according to:

strings <sample_of_interest> | rank_strings

We are also providing Docker command line tools for additional portability and usability. For a more detailed overview of how to use StringSifter, including how to specify optional arguments for customizable functionality, please view its README file on GitHub.

We have received great initial internal feedback about StringSifter from FireEye’s reverse engineers, SOC analysts, red teamers, and incident responders. Encouragingly, we have also observed users at the opposite ends of the experience spectrum find the tool to be useful – from beginners detonating their first piece of malware as part of a FireEye training course – to expert malware researchers triaging incoming samples on the front lines. By making StringSifter publicly available, we hope to enable a broad set of personas, use cases, and creative downstream applications. We will also welcome external contributions to help improve the tool’s accuracy and utility in future releases.

Conclusion

We are releasing StringSifter to coincide with our presentation at DerbyCon 2019 on Sept. 7, and we will also be doing a technical dive into the model at the Conference on Applied Machine Learning for Information Security this October. With its release, StringSifter will join FLARE VM, FakeNet, and CommandoVM as one of many recent malware analysis tools that FireEye has chosen to make publicly available. If you are interested in developing data-driven tools that make it easier to find evil and help benefit the security community, please consider joining the FDS or FLARE teams by applying to one of our job openings.

ACSC confirms the public release of BlueKeep exploit

The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) is aware of the overnight release of a working exploit for the vulnerability known as BlueKeep (CVE-2019-0708). Australian businesses and users of older versions of Windows should update their systems as soon as practically possible, before hackers further refine their tools and tradecraft in order to fully utilise this exploit.

Announcing Task For Pwn 0 (TFP0): Operation #FreeTheSandbox

Announcing Task For Pwn 0 (TFP0): Operation #FreeTheSandbox

Win Bounties even for soon-to-be-Patched Bugs

By Zuk Avraham

Following the recent disclosures by Google Project Zero of iPhone mass-targeting in the wild, the need to investigate iOS attacks is becoming of critical importance to the DFIR community. This is not the first time iPhones are actively being attacked, and definitely not the last one either.

The challenge starts when an iOS device is confirmed or suspected as compromised. Remarkably, Google Project Zero Team observed  messages that were sent in plain text, however usually sophisticated threat operators would rarely make such mistakes. Moreover, even when phones are confirmed to be infected,  if the exploit is not available, the device has to be hacked in order to extract the payload. 

Two years ago, my iOS device was exposed to two failed attack attempts. Without disclosing sensitive information that would tip off the attackers, the first failed attack was a trigger to a security mitigation and the second failed attack was a failed execution of non-signed binary in a system path. The binary that was tampered with was CommCenterMobileHelper which is the binary that is in charge of baseband / cellular communication.

At that time, I could only deduce that a device was attacked, I knew the exact path but I couldn’t extract the payload. Skipping the full details, I was only able to perform filesystem extraction about a month later once GP0 released a Local Privilege Escalation (LPE) for that version. In an era when even non-sophisticated malware implement time-bombs to avoid detection, it was undoubtedly way too long from the moment of the attack.

At ZecOps we decided to change the odds in favor of DFIR community. By promoting #FreeTheSandbox we believe that DFIR community should be empowered to analyze every sandboxed device (especially the ones that have a microphone), without requiring to use an LPE exploit, and especially if users have a physical access + a pin code to their device. Currently, accessing plain text passwords and messages is allowed, but TFP0 / Read-Only access to file system is not. iOS DFIR is currently a constant Catch 22: even if you have an LPE exploit, you’re facing a challenge: as a white-hat hacker you want to report such vulnerabilities, but if they are patched, you can’t analyze infected devices anymore.

For the first competition, we’re willing to pay even for bugs that other bounties would consider worthless LPEs. For example, vulnerabilities that are already known to be patched in iOS 13 / 13.1 and are still working on iOS 12.4.1. We’re announcing our first Task For Pwn Zero competition:
We’ll use disclosed bugs for defensive purposes in order to analyze infected devices.

FREQUENTLY ASKED QUESTIONS: 

1. What type of access are you looking for?

Vulnerabilities / POCs that provide Task For PID 0 (TFP0) and kernel ProcStructAddr for the current process. Please include in your submission email to task_for_pwn@zecops.com:

  1. A short explanation of the vulnerability
  2. POC (without full exploit code)
  3. Proof for the POC (crash or other)
  4. Which devices can you support? Does it work with PAC?
  5. Was this vulnerability disclosed to Apple? Is it patched on iOS 13/iOS 13.1?
  6. Will you include a write-up (yes/no)

PGP Public Key is available below.

2. What’s the starting point? Do I need a full chain?

Full chain is not required! The vulnerability should work as an app. Our goal is to extract malicious payloads and to analyze persistent and non-persistent payloads on devices. We are only interested in LPEs. We install the app manually on suspected devices, WITH user’s permission. The app won’t be in the App Store.

3. How much will ZecOps pay?

We’ll pay up to $40k if the vulnerabilities were already patched in iOS 13 / iOS 13.1. 
The parameters that would provide the maximal bounty includes:

  1. Number of devices that this vulnerability can obtain access on (A8~A12 are preferred) 
  2. PAC Bypass
  3. Write up

Additional Bonuses:

  • We’ll pay more than the maximum bounty for vulnerabilities that are not patched yet in iOS 13 / 13.1. 
  • We’ll also pay more if Apple doesn’t know about the vulnerability, and we are the first to disclose it to them.
  • Although unlikely, an additional bonus will be provided if Apple will provide us a bounty.  In any way, we guarantee that the payout will be more than $50k if Apple will provide us with any bounty due to the disclosure. $50k is the price Apple listed for LPEs in the latest bug bounty program so it’s more beneficial to share it with us first.

4. How many vulnerabilities will you purchase?

Although it may change, as a starting point, one for each version. The one with most devices coverage will win. If another vulnerability was not purchased, and it’s still unpatched after an update, we’ll prioritize it for the following version. We will not disclose any vulnerabilities we didn’t purchase, without written permission.

5. Will you share the vulnerability with Apple?

Yes
, we’re white-hats. Although this situation is ridiculous, and we hope Apple will fix it, if this vulnerability not previously responsibly disclosed to Apple (please elaborate in the submission), we will. Although we do not anticipate to receive any bounty this time as a result, we’ll provide a bonus to the sender if we receive any bounty and the final outcome will be higher than the entire bounty.

6. Do you require exclusivity?

No
, you can do whatever you want with this vulnerability.

7. Do you require a write-up?

No,
but as part of our internal bounty evaluation, we will provide you with an additional $5k bonus which will help to achieve the maximum payout.

8. Will you share the vulnerability with other parties?

Currently not
. We do not plan to share the vulnerability except for ZecOps customers and partners when devices were found to be suspicious. Down the road, we may share with other companies for defensive purposes only, under a strict agreement that does not allow to resell this vulnerability. If we ever share an exploit, it will only be one that we ended up purchasing, and following a responsible disclosure to Apple.

Once the vulnerability is patched, we will share a blog post with the details and the POC.

9. Does Apple new Research Program helps iOS  DFIR analysts? Unfortunately no. Although it’s a good step in the right direction, it’s far from sufficient and it won’t help any iOS DFIR analysts. Even if receive access to a device with root & ssh access, it only help to investigate that particular device. It does not help to analyze suspected devices – even in examples such as the attack disclosed last week where the device was communicating in plain text.

10. How can Apple (& Google) help to fight malicious actors? 

Devices must be inspectable by device owners, without tipping of the attackers and without tampering with evidence (flashing a new kernel / unlocking bootloader just to enable inspection is tampering with evidence). Even compromised devices cannot be inspected hence malware/payloads/exploits cannot be easily extracted on latest versions. 

In order to extract persistent malware we need to have read-only filesystem access. In order to extract non-persistent, in-memory, malware, we need TFP0 on iOS or equivalent on Android (non-sandboxed, root process). 

Android Device Bridge (ADB) user is not sufficient for that purpose too and attackers can use the sandbox limitations to hide from iOS and Android DFIR analysts. 

We understand it will be a bit hard to swallow at first, but if the vendors will hear us out they will understand it makes total sense. We can start with SSH access with physical connection and pin code. Secrets like plain-text passwords are available simply with pincode / facial recognition – full analysis of devices should be achieved in exactly the same way.

What’s the value to Apple and Google? They will have an army of hundreds of thousands of Android and iOS DFIR analysts finding persistent and non-persistent attacks on their devices. Making the platform much more secure. Win-Win to everybody.

We would love to maintain an open communication with Apple and Google to achieve proper analysis capabilities.

11. I support the cause, what can I do to help?

  1. Fill your name and address here and we’ll send you free #FreeTheSandbox stickers. Spread the word, together we will make it happen!
  2. Spread the word with the hashtag #FreeTheSandbox



Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment

Ransomware is a global threat targeting organizations in all industries. The impact of a successful ransomware event can be material to an organization - including the loss of access to data, systems, and operational outages. The potential downtime, coupled with unforeseen expenses for restoration, recovery, and implementation of new security processes and controls can be overwhelming. Ransomware has become an increasingly popular choice for attackers over the past few years, and it’s easy to understand why given how simple it is to leverage in campaigns – while offering a healthy financial return for attackers.

In our latest report, Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment, we discuss steps organizations can proactively take to harden their environment to prevent the downstream impact of a ransomware event. These recommendations can also help organizations with prioritizing the most important steps required to contain and minimize the impact of a ransomware event after it occurs.

Ransomware is commonly deployed across an environment in two ways:

  1. Manual propagation by a threat actor after they’ve penetrated an environment and have administrator-level privileges broadly across the environment:
    • Manually run encryptors on targeted systems.
    • Deploy encryptors across the environment using Windows batch files (mount C$ shares, copy the encryptor, and execute it with the Microsoft PsExec tool).
    • Deploy encryptors with Microsoft Group Policy Objects (GPOs).
    • Deploy encryptors with existing software deployment tools utilized by the victim organization.
  2. Automated propagation:
    • Credential or Windows token extraction from disk or memory.
    • Trust relationships between systems – and leveraging methods such as Windows Management Instrumentation (WMI), SMB, or PsExec to bind to systems and execute payloads.
    • Unpatched exploitation methods (e.g., EternalBlue – addressed via Microsoft Security Bulletin MS17-010).

The report covers several technical recommendations to help organizations mitigate the risk of and contain ransomware events including:

  • Endpoint segmentation
  • Hardening against common exploitation methods
  • Reducing the exposure of privileged and service accounts
  • Cleartext password protections

If you are reading this report to aid your organization’s response to an existing ransomware event, it is important to understand how the ransomware was deployed through the environment and design your ransomware response appropriately. This guide should help organizations in that process.

Read the report today.

*Note: The recommendations in this report will help organizations mitigate the risk of and contain ransomware events. However, this report does not cover all aspects of a ransomware incident response. We do not discuss investigative techniques to identify and remove backdoors (ransomware operators often have multiple backdoors into victim environments), communicating and negotiating with threat actors, or recovering data once a decryptor is provided.

SharPersist: Windows Persistence Toolkit in C#

Background

PowerShell has been used by the offensive community for several years now but recent advances in the defensive security industry are causing offensive toolkits to migrate from PowerShell to reflective C# to evade modern security products. Some of these advancements include Script Block Logging, Antimalware Scripting Interface (AMSI), and the development of signatures for malicious PowerShell activity by third-party security vendors. Several public C# toolkits such as Seatbelt, SharpUp and SharpView have been released to assist with tasks in various phases of the attack lifecycle. One phase of the attack lifecycle that has been missing a C# toolkit is persistence. This post will talk about a new Windows Persistence Toolkit created by FireEye Mandiant’s Red Team called SharPersist.

Windows Persistence

During a Red Team engagement, a lot of time and effort is spent gaining initial access to an organization, so it is vital that the access is maintained in a reliable manner. Therefore, persistence is a key component in the attack lifecycle, shown in Figure 1.


Figure 1: FireEye Attack Lifecycle Diagram

Once an attacker establishes persistence on a system, the attacker will have continual access to the system after any power loss, reboots, or network interference. This allows an attacker to lay dormant on a network for extended periods of time, whether it be weeks, months, or even years. There are two key components of establishing persistence: the persistence implant and the persistence trigger, shown in Figure 2. The persistence implant is the malicious payload, such as an executable (EXE), HTML Application (HTA), dynamic link library (DLL), or some other form of code execution. The persistence trigger is what will cause the payload to execute, such as a scheduled task or Windows service. There are several known persistence triggers that can be used on Windows, such as Windows services, scheduled tasks, registry, and startup folder, and there continues to be more discovered. For a more thorough list, see the MITRE ATT&CK persistence page.


Figure 2: Persistence equation

SharPersist Overview

SharPersist was created in order to assist with establishing persistence on Windows operating systems using a multitude of different techniques. It is a command line tool written in C# which can be reflectively loaded with Cobalt Strike’s “execute-assembly” functionality or any other framework that supports the reflective loading of .NET assemblies. SharPersist was designed to be modular to allow new persistence techniques to be added in the future. There are also several items related to tradecraft that have been built-in to the tool and its supported persistence techniques, such as file time stomping and running applications minimized or hidden.

SharPersist and all associated usage documentation can be found at the SharPersist FireEye GitHub page.

SharPersist Persistence Techniques

There are several persistence techniques that are supported in SharPersist at the time of this blog post. A full list of these techniques and their required privileges is shown in Figure 3.

Technique

Description

Technique Switch Name (-t)

Admin Privileges Required?

Touches Registry?

Adds/Modifies Files on Disk?

KeePass

Backdoor KeePass configuration file

keepass

No

No

Yes

New Scheduled Task

Creates new scheduled task

schtask

No

No

Yes

New Windows Service

Creates new Windows service

service

Yes

Yes

No

Registry

Registry key/value creation/modification

reg

No

Yes

No

Scheduled Task Backdoor

Backdoors existing scheduled task with additional action

schtaskbackdoor

Yes

No

Yes

Startup Folder

Creates LNK file in user startup folder

startupfolder

No

No

Yes

Tortoise SVN

Creates Tortoise SVN hook script

tortoisesvn

No

Yes

No

Figure 3: Table of supported persistence techniques

SharPersist Examples

On the SharPersist GitHub, there is full documentation on usage and examples for each persistence technique. A few of the techniques will be highlighted below.

Registry Persistence

The first technique that will be highlighted is the registry persistence. A full listing of the supported registry keys in SharPersist is shown in Figure 4.

Registry Key Code (-k)

Registry Key

Registry Value

Admin Privileges Required?

Supports Env Optional Add-On (-o env)?

hklmrun

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

Yes

Yes

hklmrunonce

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

Yes

Yes

hklmrunonceex

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx

User supplied

Yes

Yes

userinit

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Userinit

Yes

No

hkcurun

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

No

Yes

hkcurunonce

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

No

Yes

logonscript

HKCU\Environment

UserInitMprLogonScript

No

No

stickynotes

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

RESTART_STICKY_NOTES

No

No

Figure 4: Supported registry keys table

In the following example, we will be performing a validation of our arguments and then will add registry persistence. Performing a validation before adding the persistence is a best practice, as it will make sure that you have the correct arguments, and other safety checks before actually adding the respective persistence technique. The example shown in Figure 5 creates a registry value named “Test” with the value “cmd.exe /c calc.exe” in the “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” registry key.


Figure 5: Adding registry persistence

Once the persistence needs to be removed, it can be removed using the “-m remove” argument, as shown in Figure 6. We are removing the “Test” registry value that was created previously, and then we are listing all registry values in “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” to validate that it was removed.


Figure 6: Removing registry persistence

Startup Folder Persistence

The second persistence technique that will be highlighted is the startup folder persistence technique. In this example, we are creating an LNK file called “Test.lnk” that will be placed in the current user’s startup folder and will execute “cmd.exe /c calc.exe”, shown in Figure 7.


Figure 7: Performing dry-run and adding startup folder persistence

The startup folder persistence can then be removed, again using the “-m remove” argument, as shown in Figure 8. This will remove the LNK file from the current user’s startup folder.


Figure 8: Removing startup folder persistence

Scheduled Task Backdoor Persistence

The last technique highlighted here is the scheduled task backdoor persistence. Scheduled tasks can be configured to execute multiple actions at a time, and this technique will backdoor an existing scheduled task by adding an additional action. The first thing we need to do is look for a scheduled task to backdoor. In this case, we will be looking for scheduled tasks that run at logon, as shown in Figure 9.


Figure 9: Listing scheduled tasks that run at logon

Once we have a scheduled task that we want to backdoor, we can perform a dry run to ensure the command will successfully work and then actually execute the command as shown in Figure 10.


Figure 10: Performing dry run and adding scheduled task backdoor persistence

As you can see in Figure 11, the scheduled task is now backdoored with our malicious action.


Figure 11: Listing backdoored scheduled task

A backdoored scheduled task action used for persistence can be removed as shown in Figure 12.


Figure 12: Removing backdoored scheduled task action

Conclusion

Using reflective C# to assist in various phases of the attack lifecycle is a necessity in the offensive community and persistence is no exception. Windows provides multiple techniques for persistence and there will continue to be more discovered and used by security professionals and adversaries alike.

This tool is intended to aid security professionals in the persistence phase of the attack lifecycle. By releasing SharPersist, we at FireEye Mandiant hope to bring awareness to the various persistence techniques that are available in Windows and the ability to use these persistence techniques with C# rather than PowerShell.