Connect with us

Security

Turla turns PowerShell into a weapon in attacks against EU diplomats

Published

on

Attacks have dropped dramatically since 2015: Is hacktivism dead?
Hacktivist scene collapses as Anonymous hacker collective dies a slow death.

A cyberespionage group believed to be from Russia is once again striking political targets, and this time, PowerShell scripts have been weaponized to increase the power of their attacks.

Turla, also known as Snake or Uroburos, has been active since at least 2008. The advanced persistent threat (APT) group was previously linked to a backdoor implanted in Germany’s Federal Foreign Office for the purposes of data exfiltration in 2017, alongside attacks against the US military, a defense contractor, and a variety of European government entities.

The Russian hacking group is rarely quiet for long, and now, the APT has returned with a fresh wave of attacks against diplomatic entities in Eastern Europe.

screenshot-2019-05-30-at-11-52-23.png

Previous attacks believed to be the work of Turla.


Kaspersky Labs

According to researchers from ESET, Turla has recently employed PowerShell scripts. The scripts allow “direct, in-memory loading and execution of malware executables and libraries,” the team says, which can also help them circumvent discovery on victim machines when a malicious executable is dropped on to a disk.

The use of PowerShell is not completely foreign to Turla. Last year, Kaspersky Labs said the APT was experimenting with PowerShell in-memory loads to bypass security protections, in the form of a customized open-source PoshSec-Mod system.

Turla’s loader was based on the legitimate PoshSec-Mod software, but in 2018, the custom code was considered flawed and would often crash due to bugs.

ESET says that now, a year later, it seems most of the cracks in the system have been smoothed over.

Turla has now improved its use of PowerShell and is using scripts to load an array of malware. However, the scripts in question are not considered simple droppers as they are able to “persist on the system as they regularly load into memory only the embedded executables,” according to ESET.

The PowerShell loader uses both a Windows Management Instrumentation (WMI) event subscription and alters the PowerShell profile (profile.ps1 file) to maintain persistence on an infected system.

In total, two WMI event filters and two WMI event consumers are created, of which the consumers are simple command lines to load PowerShell into the Windows registry.

See also: Cybersecurity 101: Protect your privacy from hackers, spies, and the government

When it comes to decrypting payloads stored in the registry, the 3DES algorithm is used. Once decrypted, a PowerShell reflective loader then comes into play.

“The executable is hardcoded in the script and is loaded directly into the memory of a randomly chosen process that is already running on the system,” the researchers say.

However, the selection process is not completely random as some processes, including avp.exe, avpsus.exe, klnagent.exe and vapm.exe, are excluded. These processes specifically refer to legitimate Kaspersky anti-virus protection software, which may indicate exclusion to avoid detection.

In some samples, ESET also found that Turla’s PowerShell script had been modified to bypass the Antimalware Scan Interface (AMSI), a Windows feature which permits the OS to integrate with antivirus products. Ithe script is also able to patch the AmsiScanBuffer process, which prevents the antivirus product from being able to perform any malware scans.

TechRepublic: How WannaCry is still launching 3,500 successful attacks per hour

The PowerShell loader is used to launch malware including a backdoor based on the RPC protocol which is able to exfiltrate data, facilitates the execution of commands, and support plugins for additional malware modules.

“Many variants of this RPC backdoor are used in the wild,” ESET says. “Among some of them, we have seen local proxies (using upnprpc as the endpoint and ncalrpc as the protocol sequence) and newer versions embedding PowerShellRunner to run scripts directly without using powershell.exe.”

A PowerShell backdoor is also available for download. Known as PowerStallion, the lightweight backdoor uses cloud storage — such as Microsoft OneDrive — as a form of command-and-control (C2) server. The researchers believe the backdoor is included as a recovery access tool for the major Turla backdoor.

CNET: Amazon’s new Alexa features put more emphasis on privacy

Earlier this month, the company discovered the existence of another major backdoor used by Turla. Dubbed LightNeuron, the malware has been specifically designed for Microsoft Exchange email servers and works as a mail transfer agent (MTA).

ESET says that while the PowerShell scripts have been used against political targets in Eastern Europe, the cybersecurity firm believes “the same scripts are used more globally against many traditional Turla targets in Western Europe and the Middle East.”

Previous and related coverage


Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0


Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Security

Security Tools Help Bring Dev and Security Teams Together

Published

on

Software development teams are increasingly focused on identifying and mitigating any issues as quickly and completely as possible. This relates not only to software quality but also software security. Different organizations are at different levels when it comes to having their development teams and security teams working in concert, but the simple fact remains that there are far more developers out there than security engineers.

Those factors are leading organizations to consider security tooling and automation to proactively discover and resolve any software security issues throughout the development process. In the recent report, “GigaOm Radar for Developer Security Tools,” Shea Stewart examines a roundup of security tools aimed at software development teams.

Stewart identified three critical criteria to bear in mind when evaluating developer security tools. These include:

  • Vendors providing tools to improve application security can and should also enhance an organization’s overall security posture.
  • The prevailing “shift-left” mindset doesn’t necessarily mean the responsibility for reducing risk should shift to development, but instead focusing on security earlier in the process and continuing to do so throughout the development process will reduce risk and the need for extensive rework.
  • Security throughout the entire software development lifecycle (SDLC) is critical for any organization focused on reducing risk.

Figure 1. How Cybersecurity Applies Across Each Stage of the Software Development Lifecycle *Note: This report focuses only on the Developer Security Tooling area

Individual vendors have made varying levels of progress and innovation toward enhancing developer security. Following several acquisitions, Red Hat, Palo Alto Networks, and Rapid7 have all added tooling for developer security to their platforms. Stewart sees a couple of the smaller vendors like JFrog and Sonatype as continuing to innovate to remain ahead of the market.

Vendors delving into this category and moving deeper into “DevSecOps” all seem to be taking different approaches to their enhanced security tooling. While they are involving security in every aspect of the development process, some tend to be moving more quickly to match the pace of the SDLC. Others are trying to shore up existing platforms by adding functionality through acquisition. Both infrastructure and software developers are now sharing toolsets and processes, so these development security tools must account for the requirements of both groups.

While none of the 12 vendors evaluated in this report can provide comprehensive security throughout the entire SDLC, they all have their particular strengths and areas of focus. It is therefore incumbent upon the organization to fully and accurately assess its SDLC, involve the development and security teams, and match the unique requirements with the functionality provided by these tools. Even if it involves using more than one at different points throughout the process, focus on striking a balance between stringent security and simplifying the development process.

Read more: Key Criteria for Evaluating Developer Security Tools, and the Gigaom Radar for Developer Security Tool Companies.

The post Security Tools Help Bring Dev and Security Teams Together appeared first on Gigaom.

Continue Reading

Security

Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA)

Published

on

Cybersecurity is a multidisciplinary practice that not only grows in complexity annually but evolves nearly as quickly. A survey of the security landscape today would reveal concerns ranging from the classic compromised servers to the relatively new DevSecOps practices aimed at securing the rapid deployment of new code and infrastructure. However, some things remain constant no matter how much change is introduced. While technology evolves and complexity varies, there is almost always a human component in
risks presented to an organization.

User Behavior Analysis (UBA) was designed to analyze the actions of users in an organization and attempt to identify normal and abnormal behaviors. From this analysis, malicious or risky behaviors can be detected. UBA solutions identify events that are not detectable using other methods because, unlike classic security tools (an IDS or SIEM for example), UBA does not simply pattern match or apply rule sets to data to identify security events. Instead, it looks for any and all deviations from baseline user activity.

As technology advanced and evolved, and the scope of what is connected to the network grew, the need to analyze entities other than users emerged. In response, entity analysis has been added to UBA to create UEBA or User and Entity Behavior Analysis. The strategy remains the same, but the scope of analysis has expanded to include entities involving things like daemons, processes, infrastructure, and so on.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA) appeared first on Gigaom.

Continue Reading

Security

GigaOm Radar for Developer Security Tools

Published

on

As we learned in the associated GigaOm report, “Key Criteria for Evaluating Developer Security Tools,” the most cost-effective method for reducing risk in software development is to identify and fix issues as close to the developer as possible. As the number of software developers continues to vastly outnumber the number of security professionals allocated to any software project, organizations need to invest in security tooling and automation that can help software developers consider and mitigate security risks in a proactive manner.

Add to this situation an appreciation for how the role of the developer has changed vastly over the last few years: Developers aren’t just responsible for software components; they can write infrastructure components, security controls, automations/integrations, and so forth. This has blended the worlds of the traditional software developers and the infrastructure and operations teams responsible for the environments that software components are deployed to. A much wider range of job titles can be incorporated into the developer role now, which requires the same security tooling and process oversight as does traditional software development.

As we consider how to evaluate vendors for developer security tools, we need to take these points into account:

  • All vendors involved in improving application security can contribute to an organization’s overall enhanced security posture.
  • “Shift-left” mindsets do not imply that the work of reducing risk is simply shifted to the developer, but rather that adding a focus on security early in the process will reduce risk and rework as software moves through the delivery pipeline.
  • Security throughout the entire software development lifecycle (SDLC) is key for any organization that is focused on reducing risk.

In this report we have identified a number of vendors that address the specific need to catch and remediate security issues earlier in the software development lifecycle, which we articulate in the report as table stakes, key criteria, and evaluation metrics. While we review 12 vendor solutions here, we ruled out many more, including several offering capabilities focused on runtime protection, which merit review in upcoming GigaOm Key Criteria and Radar Reports.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post GigaOm Radar for Developer Security Tools appeared first on Gigaom.

Continue Reading

Trending