- Mac Malware Removal
- Malware Utility Mac Download
- Mac Malware Protection
- Malware Utility Mac Os
- Malware On Mac Os
- Malware Utility Mac
HP Utility Malware. HP Utility Malware is a potentially unwanted program (PUP), and is also called as an adware. You must have the base knowledge of adware. Adware is a chafing maker for different kinds of fake advertisements, for example, banner ads, pop-up ads, in. Malwarebytes for Mac Protects you from Mac threats. Detects and removes viruses, ransomware, and other malware in real time with advanced. Removes adware and unwanted programs. Crushes adware and potentially unwanted programs that slow your Mac. Scans the average Mac. By the way, part II: Malwarebytes is a malware/adware protection utility and CleanMyMac is an all-in-one macOS solution designed to keep your Mac clean and to secure space from your computer’s hard drive. The problem: Mac malware in the Library folder; How to fix a corrupted Mac; The problem: Mac malware in the Library folder. Serenity Caldwell writing for iMore in 2017: My father-in-law's MacBook Pro had been running into curious slowdowns for a two-year-old laptop and he kept on seeing weird sites taking over his Safari and Firefox search bars.
Apple’s little known malware removal tool gets a signature update. But what is this new malware family MACOS.35846e4? Find out on this journey inside MRT
We’ve noted before that Apple’s built-in security technologies have been missing some updates of late, and we weren’t the only ones. So, when Apple dropped a couple of updates to MRT and XProtect last week, the macOS community raised a collective eyebrow of interest. With XProtect having hardly seen a significant update since March of 2018, there were high hopes that Apple were finally playing catch-up with the rounds of macOS malware that have appeared since XProtect’s last update.
As it turned out, the updates were underwhelming on the one hand and curious on the other. XProtect merely received a bump for the minimum Flash player plug-in (now, minimum required version is 32.0.0) but otherwise added no new malware families, while MRT only added a single new malware family to its search-and-remove definitions, an item Apple designated
MACOS.35846e4
.The addition to MRT caused some consternation among macOS security enthusiasts as this nomenclature is unfamiliar to the wider macOS research community: what is the mysteriously named MACOS.35846e4? Were Apple discovering new malware and keeping the details from the wider security community? It wouldn’t be the first time they’ve been accused of such.
We decided to take a look at the MRT.app and find out for ourselves.
Inside MRT.app
The Malware Removal Tool (MRT.app) is an Apple application that lives in the CoreServices folder located in
/System/Library
, rather than the Applications or Utilities folders where user level programs are typically located. Despite taking the form of an application bundle, MRT is not supposed to be launched by users.However, it does possess some command line options which allow it to be invoked either as an agent or daemon, and interestingly also may generate an error message related to the mysterious new malware family:
The error message doesn’t give us any clue as to what MACOS.35846e4 is though. Figuring out what MRT looks for requires a couple of different approaches. The first thing we need to do is grab a copy of the binary to play with. Even though we don’t plan to write to the binary and it’s protected by System Integrity Protection (which is designed to prevent modifications), working with a copy of a binary during analysis is just a habit that you should always adopt when reverse engineering. We can grab a copy of the binary by executing
ditto
to write a copy of the binary to the Desktop. sudo ditto MRT ~/Desktop/MRT_COPY
Pulling Strings
The first step in reverse engineering an executable file is usually to dump the plain text ASCII characters embedded in the file. Simply dumping the strings from the binary will often reveal hardcoded file paths. There’s a couple of ways to achieve this, but the built-in macOS utility, conveniently called
strings
, is probably the easiest. The strings
utility contains a stub by default that actually installs the full utility the first time you use it. Pass the -a
flag and the path to the file name, and output the strings to a new file: strings -a ~/Desktop/MRT_COPY > ~/Desktop/MRT_Strings.txt
You can scroll and search through the new file in a text editor of your choice. Note that the output is just a dump of every string in the binary, and there’s no way to automatically determine from this which strings are actually malware definitions and which are just strings used for other purposes in the binary. That said, many are obvious given a little experience, but it’s important to treat the output with caution until or unless you can verify a file path is related to malware from further checks.
Aside from the fact that there’s no intrinsic way to distinguish the strings from one another, there’s another problem: the strings don’t contain all of the definitions. And although we can search through the strings for the family name
MACOS.35846e4
, the output doesn’t give us any clear indication of the malware that it refers to.It’s time to dive a bit deeper.
Static Code Analysis
For this, you need a disassembler like Cutter or Hopper. In this example, we’ll use Hopper because it gives a slightly cleaner and easier to read output.
We begin by searching for references to the string
35846e4
in Hopper’s strings section. From here, we find a reference to the string being loaded into the
rdi
register. That’s interesting! One of the uses of the rdi
register is to hold the first argument in a call to an Objective-C function. Switching to Hopper’s pseudocode view shows us that the string is being loaded into the register from within another function sub_1000ca9a0
, where we find a treasure trove of ASCII characters hidden in byte code. This image shows one collection of 13 characters found in the function, each held in a separate variable:We can do a quick-and-dirty check to see if they’re interesting on the command line:
The string turns out to be
sendLogEvent:
, which looks like an Objective-C method call due to the presence of the colon on the end. That’s enough to peek our interest. Scanning through the rest of the method, we see lots more individual variables holding hex values that map to ASCII character codes. To see what they hold, we’ll just dump the whole function into a text file and do some text manipulation to isolate and translate the hex values. This results in the following strings:We recognize some of these as classic adware strings, so it seems that MACOS.35846e4 is some form of new adware. Let’s check out VirusTotal and see if we get any matches.
Old Adware, New Variant
Fortunately for us in this case, we get a bunch of hits:
This is a family of adware that’s been around a long time but was updated after the release of macOS 10.14 Mojave to take into account Apple’s implementation of new user protections. The adware appears to users under various names like “MacSecurityPlus” and “MacOSDefender”.
There’s a hidden folder at
~/Library/Application Support/.dir
that contains an application called “CompanyUpdater”. A persistence agent in the user’s Library LaunchAgents folder executes a process called “Dock” to ensure the infection is reinstalled if removed. The adware will also try to install browser extensions in Chrome, Firefox and Safari, typically called something like “AnySearch” or “DefaultSearch”. Conclusion
![Malware Utility Mac Malware Utility Mac](https://download.softwsp.com/sites/10/2016/01/linux-lite-005.png)
In this post, we’ve gotten to the bottom of the mystery of Apple’s update to Malware Removal Tool, though not to why Apple tried to obscure this particular detection. It also remains a mystery why Apple are continuing to update MRT while leaving XProtect practically moribund. For users and endpoints, given the amount of new malware that has arisen in the last year that neither XProtect nor MRT recognizes, it remains a wise choice to ensure you have a more robust security solution installed on your Mac computers.
Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.
Read more about macOS Security
Whether it’s a cryptominer looking for low-risk money-making opportunities, adware hijacking browser sessions to inject unwanted search results, or malware designed to spy on a user, steal data or traverse an enterprise network, there’s one thing all threats have in common: the need for a persistent presence on the endpoint. On Apple’s macOS platform, attackers have a number of different ways to persist from one login or reboot to another.
In this post, we review macOS malware persistence techniques seen in the wild as well as highlighting other persistence mechanisms attackers could use if defenders leave the door open. Has your IT team and security solution got them all covered? Let’s take a look.
How To Persist Using a LaunchAgent
By far the most common way malware persists on macOS is via a LaunchAgent. Each user on a Mac can have a LaunchAgents folder in their own Library folder to specify code that should be run every time that user logs in. In addition, a LaunchAgents folder exists at the computer level which can run code for all users that log in. There is also a LaunchAgents folder reserved for the System’s own use. However, since this folder is now managed by macOS itself (since 10.11), malware is locked out of this location by default so long as System Integrity Protection has not been disabled or bypassed.
LaunchAgents take the form of property list files, which can either specify a file to execute or can contain their own commands to execute directly.
Since user LaunchAgents require no privileges to install, these are by far the easiest and most common form of persistence seen in the wild. Unfortunately, Apple took the controversial step of hiding the parent Library folder from users by default all the way back in OSX 10.7 Lion, making it easier for threat actors to hide these agents from unsavvy users.
Users can unhide this library in a couple of different ways for manual checks, but enterprise security solutions should monitor the contents of this folder and block or alert on malicious processes that write to this location, as shown here in this example from the SentinelOne console. The threat is autonomously blocked and the IT team is alerted to the IOCs, with reference to Mitre Att&ck framework, and convenient links to RecordedFuture and VirusTotal detections.
Persistence By LaunchDaemon
LaunchDaemons only exist at the computer and system level, and technically are reserved for persistent code that does not interact with the user – perfect for malware. The bar is raised for attackers as writing a daemon to
/Library/LaunchDaemons
requires administrator level privileges. However, since most Mac users are also admin users and habitually provide authorisation for software to install components whenever asked, the bar is not all that high and is regularly cleared by infections we see in the wild. In this image, the computer has been infected by 3 separate, malicious LaunchDaemons.Because LaunchDaemons run on startup and for every user even before a user logs in, it is essential that your security software is aware of what daemons are running and when any new daemons are written. As with System LaunchAgents, the System LaunchDaemons are protected by SIP so the primary location to monitor is
/Library/LaunchDaemons
.Don’t just assume labels you recognize are benign either. Some legitimate LaunchDaemons point to unsigned code that could itself be replaced by something malicious. For example, the popular networking program Wireshark uses a LaunchDaemon,
/Library/LaunchDaemons/org.wireshark.ChmodBPF.plist
that executes unsigned code at the path:
/Library/Application Support/Wireshark/ChmodBPF/ChmodBPF
Even Apple itself uses a LaunchDaemon that isn’t always cleaned up immediately such as
/Library/LaunchDaemons/com.apple.installer.cleanupinstaller.plist
This points to an executable in the
/macOS Install Data
folder that could be replaced by malicious code.Remember that with privileges, an attacker can either modify the program arguments of these property plists or the executables that they point to in order to achieve stealthy persistence. Since these programs will run with root privileges, it’s important that you or your security solution isn’t just blanket whitelisting code because it looks like it comes from a legitimate vendor.
Persistence with Profiles
Profiles are intended for organizational use to allow IT admins to manage machines for their users, but their potential for misuse has already been spotted by malware authors. As profiles can be distributed via email or a website, tricking users into inadvertently installing them is just another element of social engineering.
Configuration profiles can force a user to use certain browser settings, DNS proxy settings, or VPN settings. Many other payloads are possible which make them ripe for abuse.
Profiles can be viewed by users in System Preferences Profiles pane and by administrators by enumerating the
/Library/Managed Preferences
folder. Be aware that neither the pane nor folder will be present on a system where profiles have never been installed.Cron Still Persists on macOS
The venerable old
cron
job has not been overlooked by malware authors. Although Apple has announced that new cron
jobs will require user interaction to install in 10.15 Catalina, it’s unlikely that this will do much to hinder attackers using it as a persistence method. As we’ve noted before, user prompts are not an effective security measure when the user has already been tricked into installing the malicious software under the guise of something else. There’s overwhelming evidence to suggest that users escape ‘death by dialog’ by simply clicking everything without paying attention to what the dialog alert actually says.Malicious
cron
jobs are used by AdLoad and Mughthesec malware, among others, to achieve persistence.Kexts for Persistence
Kernel extensions are widely used by legitimate software for persistent behavior, and we’ve seen them also used by so-called PUP software like MacKeeper. An open-source keylogger, logkext, has also been around for some years, but in general kexts are not a favoured trick among malware authors as they are comparatively difficult to create, lack stealth, and can be easily removed.
How to Find Persistent Login Items
Changes made by Apple to Login Items have, on the other hand, resulted in more attractive opportunities for malware persistence. Once upon a time, Login Items were easily enumerated through the System Preferences utility, but a newer mechanism makes it possible for any installed application to launch itself at login time simply by including a Login Item in its own bundle. While the intention of this mechanism is for legitimate developers to offer control of the login item through the app’s user interface, unscrupulous developers of commodity adware and PUP software have been abusing this as a persistence trick as it’s very difficult for users to reliably enumerate which applications actually contain a bundled login item.
While it’s not a simple matter for users to enumerate all the Login Items, admins can do so with a little extra work by parsing the following file, if it exists:
~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm
A method of doing so was first written up by security researcher Patrick Wardle, but that still requires some programming skill to implement. A more user-friendly AppleScript version that can be cut and pasted into the macOS Script Editor utility and run more conveniently is available here.
Mac Malware Removal
AppleScript & Friends
While on the subject of AppleScript, Apple’s most useful “swiss army knife” tool somewhat unsurprisingly also has some persistence mechanisms to offer. The first leverages Folder Actions and allows an attacker to execute code that could even be read into memory remotely every time a particular folder is written to. This remarkably clever way of enabling a fileless malware attack by re-purposing an old macOS convenience-tool was first written up by Cody Thomas.
Admins with security solutions that do not have behavioral AI detection should monitor processes executing with
osascript
and ScriptMonitor
in the command arguments to watch out for this kind of threat.An even more wily trick leverages Mail rules, either local or iCloud-based, to achieve persistence by triggering code after sending the victim an email with a specially-crafted subject line. This method is particularly stealthy and will evade many detection tools.
Defenders can manually check for the presence of suspicious Mail rules by parsing the
ubiquitous_SyncedRules.plist
file and the SyncedRules.plist
file for iCloud and local Mail rules, respectively. A quick bash script such as grep -A1 'AppleScript' ~/Library/Mail/V6/MailData/SyncedRules.plist
will enumerate any Mail rules that are calling AppleScripts. If any are found, those will then need to be examined closely to ensure they are not malicious.
Also Ran: Forgotten Persistence Tricks
For those who remember them,
rc.common
and launchd.conf
no longer work on macOS, and support for StartupItems also appears to have been removed after 10.9 Mavericks.Even so, other old “nix tricks” do still work, and while we’ve yet to see any of the following persistence mechanisms used in the wild, they are worth keeping an eye on. These tricks include using
periodics
, loginhooks
, at
jobs, and the emond
service. Periodics As a Means of Persistence
Periodics are system scripts that are generally used for maintenance and run on a daily, weekly and monthly schedule. Periodics live in similarly titled subfolders within
etc/periodic
folder.Malware Utility Mac Download
Listing the contents of each of the subfolders should reveal the standard set of periodics, unless your admins are using their own custom periodic scripts. If not, anything additional found in there should be treated as suspicious and inspected. Notice the unusual “uptime” script here, which will run on a daily basis without user interaction or notification.
Also, be sure to check both
/etc/defaults/periodic.conf
and /etc/periodic.conf
for system and local overrides to the default periodic
configuration.LoginHooks and LogoutHooks
LoginHooks and LogoutHooks have been around for years and are rarely used these days, but are still a perfectly viable way of running a persistence script on macOS Mojave. As the names suggest, these mechanisms run code when the user either logs in or logs out.
It’s a simple matter to write these hooks, but fortunately it’s also quite easy to check for their existence. The following command should return a result that doesn’t have either LoginHook or LogoutHook values:
sudo defaults read com.apple.loginwindow
If, on the other hand, it reveals a command or path to a script, then consider those worthy of investigation.
At Jobs: Run Once, Persist Forever
A much less well-known mechanism is
at
jobs. While these only run once and are not enabled by default, they are a sneaky way to run some code on restart. The single-use isn’t really a problem, since the at
job can simply be re-written each time the persistence mechanism fires, and these jobs are very unlikely to be noticed by most users or indeed many less-experienced admins. You can check whether any
at
jobs are scheduled by enumerating the /var/at/jobs
directory. Jobs are prefixed with the letter a
and have a hex-style name.Emond – The Forgotten Event Monitor
Sometime around OSX 10.5 Leopard, Apple introduced a logging mechanism called
emond
. It appears emond
was never fully developed and development may have been abandoned by Apple for other mechanisms, but it remains available even on macOS 10.14 Mojave. In 2016, James Reynolds provided the most comprehensive analysis to-date of
emond
and its capabilities. Reynolds was not interested in emond
from a security angle, but rather was documenting a little-known daemon from the angle of an admin wanting to implement their own log scanner. Reynolds concludes his analysis with an interesting comment, though:Considering how easy it is to log, run a command, or send an email in a perl script, I can’t see why I’d want to use emond instead of a script.
Mac Malware Protection
This little-known service may not be much use to a Mac admin, but to a threat actor one very good reason would be to use it as a persistence mechanism that most macOS admins probably wouldn’t know to look for.
Detecting malicious use of
emond
shouldn’t be difficult, as the System LaunchDaemon for the service looks for scripts to run in only one place:/private/var/db/emondClients
Remote desktop manager enterprise 5 5 for mac free download.Malware Utility Mac Os
Admins can easily check to see if a threat actor has placed anything in that location.
As
emond
is almost certainly not used in your environment for any legitimate reason, anything found in the emondClient
directory should be treated as suspicious.Conclusion
Malware On Mac Os
As the above mechanisms show, there are plenty of ways for attackers to persist on macOS. While some of the older ways are now defunct, the onus is still very much on defenders to keep an eye on the many possible avenues that code execution can survive a reboot. To lessen that burden, it’s recommended that you move to a next-gen behavioral solution that can autonomously detect and block malware from achieving persistence. If you are not already protected by SentinelOne’s activeEDR solution, contact us for a free demo and see how it can work for you in practice.
Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.