Welcome to the next episode of the Xopero Security Center. This time we are taking a closer look into the Z0Miner malware case – a new threat against unpatched ElasticSearch and Jenkins servers. MS Exchange servers are under attack too. Remember the four new zero-day vulnerabilities discovered a few weeks ago? They have got a fancy name now – ProxyLogon exploits – and very effective [DearCry] ransomware which is targeting vulnerable devices. What’s next? There is also a novel phishing attack that uses fake Google reCAPTCHA to swipe Microsoft 365 credentials. There were also some problems with the GitHub logging mechanism. Details can be found below.
Unpatched ElasticSearch and Jenkins servers are now easy prey for z0Miner botnet
A cryptomining botnet discovered last year is now taking control of Jenkins and ElasticSearch servers to mine for Monero (XMR) cryptocurrency.
z0Miner spotted in November 2020 by the Tencent Security Team, has been infecting thousands of servers by exploiting a Weblogic security vulnerability. Now, the attackers have upgraded the malware to scan for and attempt to infect new devices by exploiting remote command execution (RCE) vulnerabilities impacting ElasticSearch and Jenkins servers:
ElasticSearch RCE vulnerability tracked as CVE-2015-1427
and an older RCE impacting Jenkins servers.
After compromising a server, the malware will first download a malicious shell script, starts hunting for and killing previously deployed cryptominers. Next, it sets up a new cron entry to periodically grab and execute malicious scripts from Pastebin. The next stage of the infection flow involves downloading a mining kit containing an XMRig miner script, a config file, a starter script, and starting to mine cryptocurrency in the background.
Last year attackers were able to compromise and took over 5,000 servers. After a short break, z0Miner botnet activity has started picking up again during mid-January.
Specialists recommend ElasticEearch and Jenkins users to check their systems and update them in time, check for abnormal processes and network connections, and monitor and block irrelevant IP and URLs.
Novel phishing attack uses fake Google reCAPTCHA to swipe your Microsoft 365 credentials
The phishing emails pretend to be automated emails from victims’ unified communications tools, which say that they have a voicemail attachment. For instance, one email tells users that “(503) ***-6719 has left you a message 35 second(s) long on Jan 20” along with a lone attachment that’s titled “vmail-219.HTM.” Another tells email recipients to “REVIEW SECURE DOCUMENT.”
When the victims click on the attachment, they then encounter the fake Google reCAPTCHA screen, which contains a typical reCAPTCHA box
The emails first take recipients to a fake Google reCAPTCHA system page. Google reCAPTCHA is a service that helps protect websites from spam and abuse, by using a Turing test to tell humans and bots apart (through asking a user to click on a fire hydrant out of a series of images, for instance).
Once victims “pass” the reCAPTCHA test, they are then redirected to a phishing landing page, which asks for their Office 365 credentials. Attackers have done their homework and are customizing their phishing landing pages to fit their victims’ profile, in order to make the attack appear more legitimate. In this step, victims are asked to input their credentials into the system. Once they do so, a message tells them that the validation was successful. Users are then shown a recording of a voicemail message that they can play, allowing threat actors to avoid suspicion.
Who is the main target?
This time attackers are aiming to Vice President and Managing Director who are likely to have a higher degree of access to sensitive company data. According to researchers, at least 2,500 such emails have been sent to senior-level employees in the banking and IT sector, over the past three months.
New DearCry ransomware now attacks Microsoft Exchange servers with ProxyLogon exploits
Week ago we pushed you to urgently patch four critical zero-day flaws in Microsoft Exchange. Unfortunately, last week fears became a reality and threat actors are using those named ProxyLogon vulnerabilities to install the DearCry ransomware.
According to Michael Gillespie, the creator of the ransomware identification site ID-Ransomware, starting on March 9, users began submitting a new ransom note and encrypted files to his system.
Microsoft has confirmed that the DearCry ransomware is installed in human-operated attacks on Microsoft Exchange servers using the ProxyLogon vulnerabilities.
MalwareHunterTeam was able to find three samples of this ransomware on VirusTotal, all of which are MingW-compiled executables.
When launched, the DearCry ransomware will attempt to shut down a Windows service named ‘msupdate.’ It is not known what this service is, but it does not appear to be a legitimate Windows service. The ransomware will now begin to encrypt the files on the computer. When encrypting files, it will append the .CRYPT extension to the file’s name.
Gillespie told that the ransomware uses AES-256 + RSA-2048 to encrypt the files and prepends the ‘DEARCRY!’ string to the beginning of each encrypted file.
When done encrypting the computer, the ransomware will create a simple ransom note named ‘readme.txt’ on the Windows desktop. For at least one of the victims, the ransomware group demanded a $16,000 ransom.
Unfortunately, the ransomware does not appear to have any weaknesses that would allow victims to recover their files for free. For now, the only option is to recover data from a backup – that is why it is so important to have proven data backup software.
According to new data shared by Palo Alto Networks, tens of thousands of Microsoft Exchange servers have been patched over the last days – experts admit that they have never seen patch rates this high for any system before. Unfortunately, the company states that there are still approximately 80,000 older servers that cannot directly apply the recent security updates.
All organizations are strongly advised to apply the patches as soon as possible!
GitHub fixes bug causing users to log into other accounts
On the night of March 8/9, GitHub automatically logged out many users by invalidating their GitHub.com sessions to protect user accounts against a potentially serious security vulnerability.
Earlier this month GitHub had received a report of anomalous behavior from an external party. It stemmed from a rare race condition vulnerability in which a GitHub user’s login session was misrouted to the web browser of another logged-in user, giving the latter an authenticated session cookie of and access to the former user’s account. So GitHub signed out all users that were logged in prior to March 8th, 12:03 UTC in the final step taken to patch the bug.
The vulnerability, according to GitHub, could be exploited in extremely rare circumstances when a race condition would occur during the backend request handling process. In such a case, the session cookie of a logged-in GitHub user would be sent to the browser of another user, giving the latter access to the former user’s account.
The company states that the underlying bug was present on GitHub.com for a cumulative period of under two weeks at certain points in time between February 8th and March 5th, 2021. There is no evidence that other GitHub.com assets or products such as GitHub Enterprise Server were impacted as a result of this bug.
GitHub states that fewer than 0.001% of authenticated sessions on GitHub.com occured misrouting. Accounts owners affected by this issue were contacted by GitHub with additional information and guidance.
0,001% seems insignificant but considering GitHub gets over 32 million active visitors (authenticated or not) in a month it could be tens of thousands of accounts.
Authentication vulnerabilities like these if exploited by adversaries can pave the way for covert software supply-chain attacks. While GitHub proved itself as a very reliable code hosting platform, problems are inevitable to all service providers. Code as intellectual property might be the most valuable asset within your organization – make sure it is well protected and consider a third-party GitHub backup.
Such as Xopero ONE for GitHub – sign up to beta tests.
About Version 2 Limited
Version 2 Limited is one of the most dynamic IT companies in Asia. The company develops and distributes IT products for Internet and IP-based networks, including communication systems, Internet software, security, network, and media products. Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 Limited offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
Xopero began in 2009, founded as a company serving primarily SMB users. Our goal was to create more accessible and affordable secure data protection solution for any businesses. In 2015, Xopero started cooperation with QNAP Inc. – one of the key global NAS providers. This addition expanded our portfolio to include a true backup appliance, In 2017, Xopero fully extended into global market thanks to cooperation with ESET. Our company took the place previously occupied by StorageCraft in the ESET Technological Alliance.