The NCSC's weekly threat report is drawn from recent open source reporting.

Council confirms ransomware attack


Earlier this week Redcar and Cleveland Borough Council confirmed its IT servers had been affected by a ransomware attack.

The NCSC has been providing support to the council in the wake of this incident and is advising on how to minimise the risk of such an attack occurring in future.

We’ve recently updated our guidance, Mitigating malware and ransomware attacks, which outlines how organisations can defend their systems. We’d encourage all organisations to read this advice and as an immediate step, ensure offline back-ups of servers are in place.

Further guidance on how to effectively detect, respond to and resolve cyber incidents is also available here on the NCSC website.


Rise in the number of Office 365 phishing scams


Cyber security researchers have uncovered an increase in the number of low-quality phishing scams that aim to trick users into revealing their credentials.

According to a new report from Cofense, there has been a surge in scam attempts using illegitimate and badly created Office 365 credentials update forms.

Potential victims receive an email claiming to be from their organisation’s IT team that tells them their account will expire unless they click the link and update their details.

Cofense note that the criminals behind the scam went to great lengths to appear legitimate. The phishing email originates from a compromised company email account, which allows the scam to bypass basic email security checks.

However, the forms that potential victims are directed to are often littered with grammatical and spelling mistakes.

Phishers use a wide variety of techniques to try and scam users into revealing sensitive data about themselves or the businesses they work for. The NCSC has published guidance on how the public and organisations can defend themselves against such attacks.

The NCSC has also published advice on securely configuring Office 365 to protect against the rise in credential stealing attacks.

I've received a suspicious email The National Cyber Security Centre

If you haven't clicked any links in the email, that's good. Until you're certain that the sender is genuine, you should not follow any links, or reply.

The next thing to do is try and identify whether the email is a scam, or genuine.

Here's some tips on spotting phishing emails
Many phishing emails have poor grammar, punctuation and spelling.
Is the design and overall quality what would you'd expect from the organisation the email is supposed to come from?
Is it addressed to you by name, or does it refer to 'valued customer', or 'friend', or 'colleague'? This can be a sign that the sender does not actually know you, and that it is part of a phishing scam.
Does the email contain a veiled threat that asks you to act urgently? Be suspicious of words like 'send these details within 24 hours' or 'you have been a victim of crime, click here immediately'.
Look at the sender's name. Does it sound legitimate, or is it trying to mimic someone you know?
If it sounds too good to be true, it probably is. It's most unlikely that someone will want to give you money, or give you access to a secret part of the Internet.
Your bank, or any other official source, should never ask you to supply personal information from an email.

Try to check any claims made in the email through some other channel. For example, by calling your bank to see if they actually sent you an email or doing a quick Google search on some of the wording used in the email.


Followed the advice?


The above advice will go a long way to helping you secure yourself online but if you do spot a suspicious email, flag it as Spam/Junk or Suspicious in your email inbox. This will take it out of your inbox, and also tell your email provider you've identified it as potentially unsafe. You can report suspicious emails, phone calls or SMS messages to Action Fraud.

For further information on how to keep yourself secure online, check out our top tips.

10 Yr-Old Facebook Account Take Over Vulnerability Let Hackers Hijack Any One’s Facebook Account – Researcher Rewarded $55,000

By Balaji N - March 1, 2020 0



Exclusive!! Security researcher discovered a critical account takeover Vulnerability in Facebook OAuth Framework let hackers hijack anyone’s Facebook account among billion of Facebook users.

The vulnerability resides in the“Login with Facebook”feature that uses the OAuth 2.0 Authorization Protocol to exchange the tokens between facebook.com and third-party websites.

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006.

By taking advantage of the vulnerability, remote attackers can set up a malicious website to hijack the OAuth flow, and steal the access tokens that help attackers to gain complete access to the target Facebook users’ accounts.

Amol Baikar, An Indian security researcher who reported this vulnerability on December 16, 2019 and fixed this vulnerability within a week, also Facebook confirmed this vulnerability with the Bug Bounty reward of $55,000 which is the highest bounty for a client-side account take over vulnerability.



Amol Baikar@AmolBaikar



Facebook OAuth Vulnerability.
$55,000 Bounty Awarded by Facebook.

Writeup:https://www.amolbaikar.com/facebook-oauth-framework-vulnerability/ …#Facebook #Security #BugBounty
805
4:32 AM - Mar 1, 2020
Twitter Ads info and privacy
306 people are talking about this



Once the Facebook account will be compromised, the attacker can send a message, publish anything in feed, alter the account details, delete post and more on behalf of the victim.

This critical Facebook Vulnerability could allow to takeover accounts including Facebook, Instagram, Oculus and more Facebook services. at the same time attack can gain access to all third-party websites such as Netflix, Tinder, Spotify. (where Facebook login is implemented), Amol Baikar told Cyber Security News.
Facebook Account Takeover Vulnerability

The Researcher addressed two imported points that mainly responsible for this vulnerability.
Missing the “X-Frame-Options”header. (completely framable flow)
Additionally “window.parent” which itself saves the user interaction to zero. Wasn’t needed to bother with window.open or any button onClick event.

Also, Amol found that cross-domain communication has been exposed and access_token could leak to any origin without victim knowledge which leads to a potential compromises user account.var app_id = '124024574287414', app_domain = 'www.instagram.com'; var exploit_url = 'https://www.facebook.com/connect/ping?client_id=' + app_id + '&redirect_uri=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2F7SWBAvHenEn.js%3Fversion%3D44%23origin%3Dhttps%253A%252F%252F' + app_domain; var i = document.createElement('iframe'); i.setAttribute('id', 'i'); i.setAttribute('style', 'display:none;'); i.setAttribute('src', exploit_url); document.body.appendChild(i); window.addEventListener('OAuth', function(FB) { alert(FB.data.name); }, !1);


Due to the leakage of 1st party graphql tokens that allows querying a mutation call, an attacker can add the new phone number for account recovery and bypassing the permission checks.

It allows attackers to gain full read/write privileges such as messages, photos, videos even if privacy control is set to the “only me”.

Cyber Security News learned some important points to be noted in this vulnerability.


1.All Facebook apps and third-party apps access token could be a leak at the same time. (within Seconds).

2.Leakage of the first party token has full read/write/update/delete permission for the Facebook account. (the attacker can fo anything with Facebook accounts, including adding, phone email which can use later for forgot password) (also tokens can query to read each and each private msgs, photos, videos even if they are set to “only me” privacy control)”.

3. Due to an incorrect post message configuration, someone visiting an attacker-controlled website could have had their first party access tokens stolen for vulnerable apps using Facebook’s Oauth flow.

4.First party tokens are non-expirable. (never expires).

5.First party token remains valid even user changes there Facebook Account password. Attacker still have control over the users account.They can harvest the data even user changes his password.


Facebook users suggested changing their Facebook password and make sure to logout from all the devices for one time, safety purpose. because this bug was live for 10 years, such long term that doesn’t give guarantee bug is exploited or not.

A group of hackers is using the remote desktop ActiveX control in Word documents

By Ionut Ilascu February 28, 2020 02:12 PM 0






A group of hackers is using the remote desktop ActiveX control in Word documents to automatically execute on Windows 10 a malware downloader called Ostap that was seen recently adopted by TrickBot for delivery.

Security researchers have found dozens of files that delivered the first malware payload, indicating a larger campaign.
Starts with phishing

Ostap, extensively analyzed by Bromium researchers, is delivered via a Word document laced with malicious macro code and including an image that allegedly showed encrypted content. This is the ruse to trick victims into enabling macros in the document.

The threat actor delivered the malicious documents via phishing emails disguised as notifications of a missing payment. In the attachment is the fake invoice referred to in the message.



Security researchers at Morphisec analyzed the poisoned docs and noticed that there was an ActiveX control hidden below the embedded image.

A closer look revealed that the threat actor used the MsRdpClient10NotSafeForScripting class, which is used for remote control. Windows 10 is the minimum supported client and Windows Server 2016 is the minimum supported server.

ActiveX controls can be added to text or drawing layers in Word documents to make them interactive.
Clever delivery and execution

In a report today, Michael Gorelik of Morphisec writes that the JavaScript code for Ostap downloader is present in the document in font that has the same color as the background, making it invisible to the human eye.



Another interesting finding is that the attackers did not populate the "server" field in the MsRdpClient10NotSafeForScripting class, needed to establish a connection with a remote desktop server.



This was not a lapse from the attackers as the error that occurs helps execute their malicious code at a later time, thus evading detection.

When inspecting the macro, the researchers found that the "_OnDisconnected" function acts as a trigger but only after an error is returned for failing to connect to a non-existent server.


"The OSTAP will not execute unless the error number matches exactly to "disconnectReasonDNSLookupFailed" (260); the OSTAP wscript command is concatenated with a combination of characters that are dependent on the error number calculation." - Michael Gorelik, Morphisec

The backdoor is then executed immediately after taking the form of a .BAT file and the document form is closed.

Gorelik told BleepingComputer that this actor is not the only one relying on ActiveX control to execute malware. Other actors seen in January used the OnConnecting method that is easier to detect.

By contrast, the OnDiconnected method needs a specific return value and there is also a delay while the DNS lookup completes. This works to the attacker's advantage because scanners may miss the malicious activity and mark the file as benign.

[Update 02/28/2020, 16:01 EST]: Article updated to reflect a correction from Morphisec about misidentifying Ostap downloader with Griffon backdoor that is typically used by FIN7 threat actor.

Android Trojan xHelper uses persistent re-infection tactics: here’s how to remove

Posted: February 12, 2020 by Nathan Collier
Last updated: February 13, 2020


We first stumbled upon the nasty Android Trojan xHelper, a stealthy malware dropper, in May 2019. By mid-summer 2019, xHelper was topping our detection charts—so we wrote an article about it. After the blog, we thought the case was closed on xHelper. Then a tech savvy user reached out to us in early January 2020 on the Malwarebytes support forum:

“I have a phone that is infected with the xhelper virus. This tenacious pain just keeps coming back.”

“I’m fairly technically inclined so I’m comfortable with common prompt or anything else I may need to do to make this thing go away so the phone is actually usable!”

— forum user misspaperwait, Amelia

Indeed, she was infected with xHelper. Furthermore, Malwarebytes for Android had already successfully removed two variants of xHelper and a Trojan agent from her mobile device. The problem was, it kept coming back within an hour of removal. xHelper was re-infecting over and over again.
Photo provided by Amelia

If it wasn’t for the expertise and persistence of forum patron Amelia, we couldn’t have figured this out. She has graciously has allowed us to share her journey.
All the fails

Before we share the culprit behind this xHelper re-infection, I’d like to highlight the tactics we used to investigate the situation, including the many dead ends we hit prior to figuring out the end game. By showing the roadblocks we encountered, we demonstrate the thought process and complexity behind removing malware so that others may use it as a guide.
Clean slate

First off, Amelia was clever enough to do a factory reset before reaching out to us. Unfortunately, it didn’t resolve the issue, though it did give us a clean slate to work with. No other apps (besides those that came with the phones) were installed besides Malwarebytes for Android, thus, we could rule out an infection by prior installs (or so we thought).

We also ruled out any of the malware having device admin rights, which would have prevented our ability to uninstall malicious apps. In addition, we cleared all history and cache on Amelia’s browsers, in case of a browser-based threat, such as a drive-by download, causing the re-infection.
The usual suspect: pre-installed malware

Since we had a clean mobile device and it was still getting re-infected, our first assumption was that pre-installed malware was the issue. This assumption was fueled by the fact that the mobile device was from a lesser-known manufacturer, which is often the case with pre-installed malware. So Amelia tested this theory by going through the steps to run Android Debug Bridge (adb) commands to her mobile device.

With adb command line installed and the mobile device plugged into a PC, we used the workaround of uninstalling system apps for current user. This method renders system apps useless even though they still technically reside on the device.

Starting with the most obvious to the least, we systematically uninstalled suspicious system apps, including the mobile device’s system updater and an audio app with hits on VirusTotal, a potential indicator of maliciousness. Amelia was even able to grab various apps we didn’t have in our Mobile Intelligence System to rule everything out. After all this, xHelper’s persistence would not end.
Photo provided by Amelia of xHelper running on mobile device
Triggered: Google PLAY

We then noticed something strange: The source of installation for the malware stated it was coming from Google PLAY. This was unusual because none of the malicious apps downloading on Amelia’s phone were on Google PLAY. Since we were running out of ideas, we disabled Google PLAY. As a result, the re-infections stopped!

We have seen important pre-installed system apps infected with malware in the past. But Google PLAY itself!? After further analysis, we determined that, no, Google PLAY was not infected with malware. However, something within Google PLAY was triggering the re-infection—perhaps something that was sitting in storage. Furthermore, that something could also be using Google PLAY as a smokescreen, falsifying it as the source of malware installation when in reality, it was coming from someplace else.

In the hopes that our theory held true, we asked Amelia to look for suspicious files and/or directories on her mobile device using a searchable file explorer, namely, anything that started with com.mufc., the malicious package names of xHelper. And then…eureka!

Photos provided by Amelia
The culprit

Hidden within a directory named com.mufc.umbtts was yet another Android application package (APK). The APK in question was a Trojan dropper we promptly named Android/Trojan.Dropper.xHelper.VRW. It is responsible for dropping one variant of xHelper, which subsequently drops more malware within seconds.

Here’s the confusing part: Nowhere on the device does it appear that Trojan.Dropper.xHelper.VRW is installed. It is our belief that it installed, ran, and uninstalled again within seconds to evade detection—all by something triggered from Google PLAY. The “how” behind this is still unknown.

It’s important to realize that unlike apps, directories and files remain on the Android mobile device even after a factory reset. Therefore, until the directories and files are removed, the device will keep getting infected.
How to remove xHelper re-infections

If you are experiencing re-infections of xHelper, here’s how to remove it:
We strongly recommend installing Malwarebytes for Android (free).
Install a file manager from Google PLAY that has the capability to search files and directories.
Amelia used File Manager by ASTRO.
Disable Google PLAY temporarily to stop re-infection.
Go to Settings > Apps > Google Play Store
Press Disable button
Run a scan in Malwarebytes for Android to remove xHelper and other malware.
Manually uninstalling can be difficult, but the names to look for in Apps info are fireway, xhelper, and Settings (only if two settings apps are displayed).
Open the file manager and search for anything in storage starting with com.mufc.
If found, make a note of the last modified date.
Pro tip: Sort by date in file manager
In File Manager by ASTRO, you can sort by date under View Settings
Delete anything starting with com.mufc. and anything with same date (except core directories like Download):

Re-enable Google PLAY
Go to Settings > Apps > Google Play Store
Press Enable button
If the infection still persists, reach out to us via Malwarebytes Support.
Mobile malware hits a new level

This is by far the nastiest infection I have encountered as a mobile malware researcher. Usually a factory reset, which is the last option, resolves even the worst infection. I cannot recall a time that an infection persisted after a factory reset unless the device came with pre-installed malware. This fact inadvertently sent me down the wrong path. Luckily, I had Amelia’s help, who was as persistent as xHelper itself in finding an answer and guiding us to our conclusion.

This, however, marks a new era in mobile malware. The ability to re-infect using a hidden directory containing an APK that can evade detection is both scary and frustrating. We will continue analyzing this malware behind the scenes. In the meantime, we hope this at least ends the chapter of this particular variant of xHelper.

Stay safe out there!