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!

Πώς να κάνετε δωρεάν αναβάθμιση στα win10!! video

Αν δεν ξέρετε πώς να κάνετε δωρεάν αναβάθμιση στα 10, ή γνωρίζετε κάποιον που χρειάζεται βοήθεια, δείτε αναλυτικά τη διαδικασία video

Posted by DASOS security info on Thursday, February 13, 2020

Critical Android Bluetooth Flaw Exploitable without User Interaction

By
Ionut Ilascu February 6, 2020 07:44 PM 3






Android users are urged to apply the latest security patches released for the operating system on Monday that address a critical vulnerability in the Bluetooth subsystem.

An attacker could leverage the security flaw, now identified as CVE-2020-0022 without user participation to run arbitrary code on the device with the elevated privileges of the Bluetooth daemon when the wireless module is active.
Short-distance worm

Discovered and reported by Jan Ruge at the Technische Universität Darmstadt, Secure Mobile Networking Lab, the bug is considered critical on Android Oreo (8.0 and 8.1) and Pie (9) because exploiting it leads to code execution.

According to Ruge, attackers could use this security fault to spread malware from one vulnerable device to another, like a worm. However, the transmission is limited to the short distance covered by Bluetooth.

The Android security bulletin notes that CVE-2020-0022 "could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process."

The only prerequisite for taking advantage of the issue is knowing the Bluetooth MAC address. This is not difficult to find, though.

"For some devices, the Bluetooth MAC address can be deduced from the WiFi MAC address," says the researcher on the the blog site of German IT security consultant ERNW.

On Android 10, the severity rating drops to moderate since it all it does is crash the Bluetooth daemon, the researcher says. Android versions earlier than 8.0 may also be affected but the impact on them has not been assessed.
Technical details, PoC to be published

The severity of the issue is what keeps the researcher from disclosing technical details and proof of concept (PoC) code demonstrating the findings.

Despite a patch being available, OEM vendors and mobile carriers also have to push it to user terminals. For devices still under support, it can take weeks until the update rolls out.

If a patch does not become available, Ruge recommends enabling Bluetooth only "if strictly necessary." If you need to activate it, consider keeping the device non-discoverable, a feature that hides it from other gadgets looking for a pair.

Ruge says that a technical report will be available for this vulnerability "as soon as we are confident that patches have reached the end users."

Νέο κύμα του Emotet Malware χακάρει δίκτυα Wi-Fi!

10 Φεβρουαρίου, 2020, 5:36 μμ by Teo Ehc Leave a Comment


Ένα νέο κύμα του malware Emotet με το νέο Wi-Fi Spreader εκμεταλλεύεται το interface wlanAPI για να απαριθμήσει όλα τα δίκτυα Wi-Fi στην περιοχή και να εξαπλωθεί η μόλυνση.

Το Emotet είναι ένα Trojan banking που εντοπίστηκε το 2014 και σχεδιάστηκε για να κλέβει ευαίσθητες και ιδιωτικές πληροφορίες.

Είναι ένα από τα πιο επικίνδυνα malware και είναι σε θέση να αποδώσει payloads βασισμένα σε συγκεκριμένα tasks.

Το Emotet διανέμεται κυρίως μέσω τεχνικών social engineering όπως τα emails με links για να κατέβει το malware.

Με τη νέα καμπάνια Emotet καταφθάνει ένα νέο Wi-Fi Spreader module που μεταφορτώνεται στο σύστημα C:\ProgramData. Το ληφθέν δυαδικό αρχείο περιέχει ένα RAR αυτόματης εξαγωγής που διαθέτει δυο δυαδικά αρχεία (service.exe και worm.exe) για τη διάδοση του μέσω Wi-Fi.



Το worm.exe είναι το εκτελέσιμο αρχείο που χρησιμοποιείται για την εξάπλωση του malware, αφού εκτελείται, αντιγράφει το service.exe σε μια μεταβλητή για τη χρήση του κατά τη διάδοση.

Στη συνέχεια καλεί την κλάση wlanAPI.dll που χρησιμοποιείται από το Native Wi-Fi για τη διαχείριση των προφίλ και των συνδέσεων ασύρματου δικτύου για τη διάδοση του malware σε άλλα δίκτυα.



“Το Worm απαριθμεί όλες τις συσκευές Wi-Fi που είναι επί του παρόντος ενεργοποιημένες στον τοπικό υπολογιστή, το οποίο επιστρέφει σε μια σειρά δομών. Αυτές οι δομές περιέχουν όλες τις πληροφορίες που σχετίζονται με τη συσκευή Wi-Fi, συμπεριλαμβανομένου του GUID και της περιγραφής της συσκευής”, διαβάζουμε στην ανάλυση του worm.


Συγκεντρώνει πιθανές πληροφορίες από όλα τα διαθέσιμα δίκτυα Wi-Fi που υπάρχουν στη λίστα των δικτύων.



Σπάζοντας το αδύναμο δίκτυο Wi-Fi

Μόλις συνδεθεί με το δίκτυο Wi-Fi, απαριθμεί τους χρήστες και επιχειρεί brute-force για όλους τους χρήστες του δικτύου.

Στη συνέχεια, το Service.exe είναι το payload που έχει εγκατασταθεί από το worm.exe στο μηχάνημα, μόλις εγκατασταθεί επικοινωνεί με το server C2 και εκτελεί το δυαδικό ενσωματωμένο στο service.exe.

Προηγουμένως, το Emotet, ο οποίος γνωρίζει ότι διανέμεται μόνο μέσω δικτύων malspam και μολυσμένων δικτύων, με αυτόν τον νέο loader εξαπλώνεται μέσω κοντινών ασύρματων δικτύων που χρησιμοποιούν αδύναμους κωδικούς πρόσβασης.