Viper and ReversingLabs A1000 Integration

A quick blog post about a module that I wrote to interconnect the malware analysis framework Viper and the malware analysis platform A1000 from ReversingLabs.

The module can perform two actions at the moment: to submit a new sample for analysis and to retrieve the analysis results (categorization):

viper sample.exe > a1000 -h
usage: a1000 [-h] [-s] [-c]

Submit files and retrieve reports from a ReversingLab A1000

optional arguments:
-h, --help show this help message and exit
-s, --submit Submit file to A1000
-c, --classification Get classification of current file from A1000
 
viper sample.exe > a1000 -s
[*] Successfully submitted file to A1000, task ID: 393846

viper sample.exe > a1000 -c
[*] Classification
- Threat status : malicious
- Threat name : Win32.Trojan.Fareit dw eldorado
- Trust factor : 5
- Threat level : 2
- First seen : 2018-02-09T13:03:26Z
- Last seen : 2018-02-09T13:07:00Z

The module is available on my GitHub repository.

[The post Viper and ReversingLabs A1000 Integration has been first published on /dev/random]

from Xavier

Advertisements

Developing an effective cyber strategy

The word strategy has its origins in the Roman Empire and was used to describe the leading of troops in battle. From a military perspective, strategy is a top-level plan designed to achieve one or more high-order goals. A clear strategy is especially important in times of uncertainty as it provides a framework for those involved in executing the strategy to make the decisions needed for success.

In a corporate or government entity, the primary role of the Chief Information Security Officer (CISO) is to establish a clear cybersecurity strategy and oversee its execution. To establish an effective strategy, one must first understand, and it is recommended to document, the following:

  • Resources. The most critical component of a successful strategy is the proper utilization of available resources. As such, a CISO must have a clear picture of their annual budget, including operating and capital expenditures. In addition, the CISO must understand not just the number of vendors and full-time employees under their span of control, but also the capabilities and weaknesses of these resources. The CISO must also have an appreciation for the capabilities of key resources that are essential to effective security but not necessarily under their direct supervision, such as server and desktop administrators, the team responsible for patching, etc. One of the most difficult aspects of the CISO job is that to be successful you must positively influence the actions of other teams whose jobs are critical to the success of the security program, and your career, but who are not under your direct control.
  • Business Drivers. At the end of the day, CISOs have a finite amount of resources to achieve goals and cannot apply the same level of protection to all digital assets. To help make resource allocation decisions, the CISO must clearly understand the business they have been charged with protecting. What is most important to the success of the business? Which lines of business produce the most revenue, and which digital assets are associated with those lines? For governments, which services are essential for residents’ health and for maintaining government operations, and which digital assets are associated with those services and functions?
  • Data. Data is the lifeblood of most companies and is often the target of cyber criminals, whether to steal or encrypt for ransom. Once business drivers have been identified, the CISO should inventory the data that is important to the lines of business. This should include documenting the format, volume, and locations of the data and the associated data steward. In large organizations, this can be extremely challenging, but it is essential to have a clear picture of the storage and processing of the entitys crown jewels.
  • Controls. Before formulating a strategy, the CISO must gain an understanding of the status of the safeguards or countermeasures that have been deployed within an environment to minimize the security risks posed to digital assets. These will include controls to minimize risks to the confidentiality, integrity, or availability of the assets. In determining the sufficiency of a control, assess its design and operating effectiveness. Does the control cover all assets or a subset? Is the control effective at reducing the risk to an acceptable level or is the residual risk still high? For example, one control found to be effective in minimizing risk to the confidentiality of data is to require a second factor of authentication prior to granting access to sensitive records. If such a control is implemented, what percentage of users require a second authentication factor before accessing the companys most sensitive data? What is the likelihood that a user will acknowledge a second factor in error as the result of a phishing test?
  • Threats. Identifying the threats to an organization is one of the more difficult tasks in developing a cyber strategy, as cyber threats tend to be asymmetric and constantly evolving. Still, it is important to identify the most likely threat actors and the motivations, tactics, techniques, and procedures used to achieve their goals.

Once a CISO has a clear picture of the items discussed above, they can begin formulating a strategy appropriate to the task at hand. There is no one size fits all approach, as each organization is unique, but there are models and frameworks that have proven helpful over time, including those developed by the National Institute of Standards and Technology, Cyber Kill Chain, Center for Internet Security, SANS, and the Australian Signals Directorate, among others. An effective strategy must also consider human and organizational dynamics. For example, employees will typically work around a control that increases the actual, or perceived, amount of effort to perform a given task, especially when they feel that the effort is not commensurate with the threat being addressed.

At Microsoft, we are continuously evaluating the current threats faced by our customers and building products and services to help CISOs execute their strategies. The design of our products not only accounts for the techniques utilized by cyber attackers, but also incorporates features that address the human dynamics within an enterprise and the staff and retention challenges faced by security teams. A few examples of these design principles in practice include building security features and functions within our productivity tools such as Office 365 Advanced Threat Protection, using auto-classification to reduce the workload on end users with Azure Information Protection, and increasing the efficiency and effectiveness of security teams with Windows Defender Advanced Threat Protection.

from Jenny Erie

Feeding TheHive with Emails

TheHive is a great incident response platform which has the wind in its sails for a while. More and more organization are already using it or are strongly considering to deploy it in a near future. TheHive is tightly integrated with MISP to push/pull IOC’s. Such tool must be fed with useful information to be processed by security analysts. TheHive is using other tools from the same team: Hippocampe parses text-based feeds and store. Cortex is a tool to enrich observables by querying multiple services in parallel. Another source of information is, by example, a Splunk instance. There is a Splunk app to generate alerts directly into TheHive. And what about emails?

 

TheHive a nice REST API that allows performing all kind of actions, the perfect companion is the Python module TheHive4py. So it’s easy to poll a mailbox at regular interval to populate a TheHive instance with collected emails. I write a tool called imap4thehive.py to achieve this:

# ./imap2thehive.py -h
usage: imap2thehive.py [-h] [-v] [-c CONFIG]

Process an IMAP folder to create TheHive alerts/cased.

optional arguments:
-h, --help show this help message and exit
-v, --verbose verbose output
-c CONFIG, --config CONFIG
configuration file (default: /etc/imap2thehive.conf)

The configuration file is easy to understand! How does it work? The IMAP mailbox is polled for new (“unread”) messages. If the email subject contains “[ALERT]”, an alert is created, otherwise, it will be a case with a set of predefined tasks. There is a Docker file to build a container that runs a crontab to automatically poll the mailbox every 5 mins.

The script is available here.

 

[The post Feeding TheHive with Emails has been first published on /dev/random]

from Xavier

Overview of Petya, a rapid cyberattack

In the first blog post of this 3-part series, we introduced what rapid cyberattacks are and illustrated how they are different in terms of execution and outcome. Next, we will go into some more details on the Petya (aka NotPetya) attack.

How Petya worked

The Petya attack chain is well understood, although a few small mysteries remain. Here are the four steps in the Petya kill chain:

Figure 1:How the Petya attack worked

  1. Prepare – The Petya attack began with a compromise of the MEDoc application. As organizations updated the application, the Petya code was initiated.
  2. Enter – When MEDoc customers installed the software update, the Petya code ran on an enterprise host and began to propagate in the enterprise.
  3. Traverse – The malware used two means to traverse:
    • Exploitation Exploited vulnerability in SMBv1 (MS17-010).
    • Credential theft Impersonated any currently logged on accounts (including service accounts).
    • Note that Petya only compromised accounts that were logged on with an active session (e.g. credentials loaded into LSASS memory).
  4. Execute – Petya would then reboot and start the encryption process. While the screen text claimed to be ransomware, this attack was clearly intended to wipe data as there was no technical provision in the malware to generate individual keys and register them with a central service (standard ransomware procedures to enable recovery).

Unknowns and Unique Characteristics of Petya:

Although it is unclear if Petya was intended to have as widespread an impact as it ended up having, it is likely that this attack was built by an advanced group, considering the following:

  • The Petya attack wiped the event logs on the system, which is unneeded as the drive was wiped later anyways. This leaves an open question on whether this is just standard anti-forensic practice (as is common for many advanced attack groups) or whether there were other attack actions/operations being covered up by Petya.
  • The supply chain approach taken by Petya requires a well-funded adversary with a high level of investment into attack skills/capability. Although supply chain attacks are rising, these still represent a small percentage of how attackers get into corporate environments and require a higher degree of sophistication to execute.

Petya and Traversal/Propagation

Our observation was that Petya spread more by using identity impersonation techniques than through MS17-010 vulnerability exploitation. This is likely because of the emergency patching initiatives organizations followed to deploy MS17-010 in response to the WannaCrypt attacks and associated publicity.

The Petya attacks also resurfaced a popular misconception about mitigating lateral traversal which comes up frequently in targeted data theft attacks. If a threat actor has acquired the credentials needed for lateral traversal, you can NOT block the attack by disabling execution methods like PowerShell or WMI. This is not a good choke point because legitimate remote management requires at least one process execution method to be enabled.

Figure 2:How the Petya attack spreads

Youll see in the illustration above that achieving traversal requires three technical phases:

1st phase: Targeting Identify which machines to attack/spread to next.

Petyas targeting mechanism was consistent with normal worm behavior. However, Petya did include a unique innovation where it acquired IPs to target from the DHCP subnet configuration from servers and DCs to accelerate its spread.

2nd phase: Privilege acquisition Gain the privileges required to compromise those remote machines.

A unique aspect of Petya is that it used automated credential theft and re-use to spread, in addition to the vulnerability exploitation. As mentioned earlier, most of the propagation in the attacks we investigated was due to the impersonation technique. This resulted in impersonation of the SYSTEM context (computer account) as well as any other accounts that were logged in to those systems (including service accounts, administrators, and standard users).

3rd phase: Process execution Obtain the means to launch the malware on the compromised machine.

This phase is not an area we recommend focusing defenses on because:

  1. An attacker (or worm) with legitimate credentials (or impersonated session) can easily use another available process execution method.
  2. Remote management by IT operations requires at least one process execution method to be available.

Because of this, we strongly advise organizations to focus mitigation efforts on the privilege acquisition phase (2) for both rapid destruction and targeted data theft attacks, and not prioritize blocking at the process execution phase (3).

Figure 3:Most Petya propagations were due to impersonation (credential theft)

Because of the dual channel approach to propagation, even an organization that had reached 97% of their endpoints with MS17-010 patching was infected enterprise-wide by Petya. This shows that mitigating just one vector is not enough.

The good news here is that any investment made into credential theft defenses (as well as patching and other defenses) will directly benefit your ability to stave off targeted data theft attacks because Petya simply re-used attack methods popularized in those attacks.

Attack and Recovery Experience: Learnings from Petya

Many impacted organizations were not prepared for this type of disaster in their disaster recovery plan. The key areas of learnings from real world cases of these attacks are:

Figure 4:Common learnings from rapid cyberattack recovery

Offline Recovery Required Many organizations affected by Petya found that their backup applications and Operating System (OS) deployment systems were taken out in the attack, significantly delaying their ability to recover business operations. In some cases, IT staff had to resort to printed documentation because the servers housing their recovery process documentation were also down.

Communications down Many organizations also found themselves without standard corporate communications like email. In almost all cases, company communications with employees was reliant on alternate mechanisms like WhatsApp, copy/pasting broadcast text messages, mobile phones, personal email addresses, and Twitter.

In several cases, organizations had a fully functioning Office 365 instance (SaaS services were unaffected by this attack), but users couldnt access Office 365 services because authentication was federated to the on premises Active Directory (AD), which was down.

More information

To learn more about rapid cyber attacks and how to protect against them, watch the on-demand webinar: Protect Against Rapid Cyberattacks (Petya, WannaCrypt, and similar).

Look out for the next and final blog post of a 3-part series to learn about Microsoft’s recommendations on mitigating rapid cyberattacks.

from Jenny Erie

Example of Ransomware As A Service

A few days ago, I wrote a diary for the SANS ISC about a ransomware as a service found on the Darknet. Today, I found an occurrence of “RaaSberry” which is a known platform. It is available in the wild for a few months. The service is available through Tor and looks professional. How does it work?

  1. You create an account
  2. Your transfer some BTC to your account
  3. Your order a package corresponding to your needs
  4. You get a unique malware sample

The entry-level package is sold 0.00519977BTC (~37.32€ with the current price). I took some screenshots to give you an overview of the service:

RaaS Welcome Page

RaaS Registration

RaaS Dashboard

RaaS Wallet

RaaS Support

RaaS Packages

 

[The post Example of Ransomware As A Service has been first published on /dev/random]

from Xavier