Fake Airplane Mode: A mobile tampering technique to maintain connectivity

Jamf Threat Labs

Author: August 17, 2023 by Jamf Threat Labs

Source: https://www.jamf.com/blog/fake-airplane-mode-a-mobile-tampering-technique-to-maintain-connectivity/

Research led by Hu Ke and Nir Avraham.

Has your Airplane Mode been tampered with?

As the name suggests, Airplane Mode is designed to allow passengers to safely use a mobile device during flight, turning off the wireless cellular features to avoid interference with critical flight equipment.

However, the use of Airplane Mode has expanded beyond travel and is used by some to preserve battery, and for others as a way to disconnect from our always connected world. It has even been suggested as a meditation technique.

For those with cyber-paranoia and technophobia, putting your phone on Airplane Mode may be a useful psychological trick to help achieve peace of mind and a feeling of additional privacy.

But should you use Airplane Mode to protect your security and privacy?

Today we’re going to dive into the technology underlying Airplane Mode on iOS to demonstrate an approach that would allow a malicious actor to maintain a cellular network connection for an application, even when the user believes they have enabled Airplane Mode.

The underlayer

We start by analyzing how Airplane Mode works. Two daemons carry the main task of switching Airplane Mode. SpringBoard takes care of changes on the UI, and CommCenter is responsible for operating the underlying network interface. Note that CommCenter is also responsible for managing the feature that allows users to “Block cellular data access for specific apps”.

As you can see, under normal conditions, when the user turns on Airplane Mode, the network interface pdp_ip0 (cellular data) will no longer display IPv4/IPv6 IP addresses. The cellular network is disconnected and unusable, at least to the user space level.

Creating an artificial Airplane Mode

In this section, we’ll show how we created an artificial Airplane Mode, keeping UI changes while preserving cellular connectivity for a selected application (which in an attack scenario would be the attacker’s malware they installed as part of a device exploit).

We start by following the console logs. Notice that when you switch on the Airplane Mode, the earliest relevant log appears to be the one found below, “#N User airplane mode preference changing from…”

We use this string to locate the code that references it in the disassembler. It’s a symbol-less C++ function found here:

Hoping that this function was early enough in the chain of calls that enable Airplane Mode, we successfully hooked and replaced it with an empty/do nothing function. The result was a fake Airplane Mode. Now, when the user turns on Airplane Mode, the device will not be disconnected from the cellular network and internet access will be uninterrupted.

Preserving the expected user experience

Additional UI tweaks are required to make the attack look like the typical Airplane Mode experience. One small example was to dim the cellular icon and to prevent the user from interacting with it.

To accomplish this, we hooked two Objective-C methods and injected a piece of code that adjusts the cellular icon to pull off the intended effect. –[SBStatusBarStateAggregator _noteAirplaneModeChanged] and -[CCUIModularControlCenterOverlayViewController _beginPresentationAnimated:interactive:]

Appearing to disconnect the internet

After enabling Airplane Mode without a Wi-Fi connection, users would expect that opening Safari would result in no connection to the internet. The typical experience is a notification window that prompts a user to “Turn Off Airplane Mode”. To achieve this effect, we will utilize the aforementioned CommsCenter feature to “Block cellular data access for specific apps,” and disguise it as Airplane Mode through the hooked function below.

The screenshots below show the spoofed user experience with the message that normally occurs from the “Block cellular data access for specific apps” feature on the left, and the result of hooking the notification window to look like the typical Airplane Mode message on the right.

Replacing the alert window is one thing, but how did we disconnect the internet for Safari without actually turning on airplane mode and affecting the entire device? After all, this is the most significant sign that airplane mode is on.

How does the “Cellular Data is Turned Off” alert window work?

Similar to the earlier icon manipulation, we discovered that the system UI Manager SpringBoardprompted the alert window after being notified by the CommCenter. Looking one step deeper, we concluded that CommCenter was notified by the kernel through a registered observer/callback function.

CommCenter`CellularUsagePolicyController::createNEConfigurationStore_sync

-> NetworkExtension.framework`-[NEPathEventObserver initWithQueue:eventHandler:]

-> libnetwork.dylib`network_config_cellular_blocked_observer_create

These network_config_* functions internally call socket()/ioctl() to interact with the kernel:

network_config_cellular_blocked_observer_create

-> network_config_policy_observer_create

-> __network_config_policy_observer_create_block_invoke

-> network_config_setup_policy_event_watcher

-> socket(32, 3, 1)

-> ioctl(…)

We leveraged `fsevents`, and observed that the CommCenter daemon also manages a SQL database file /private/var/wireless/Library/Databases/CellularUsage.db. This database records the cellular data access status of each app.

The value of “flags” will be set to 8 if an application is blocked from accessing cellular data. This is useful as we can read a list of application bundle IDs from this SQL database file and obtain their preset value.

Using this database of installed application bundle IDs we can now selectively block or allow an app to access Wi-Fi or cellular data using the following code. When combined with the other techniques outlined above, the fake Airplane Mode now appears to act just as the real one, except that the internet ban does not apply to non-application processes such as a Backdoor Trojan.

Watch a demo of this exploit in this video made by Jamf Threat Labs researchers.

Jamf Executive Threat Protection can identify sophisticated attacks to keep your users safe.

by Pieter Beckmann

Jamf protects against JokerSpy malware

Jamf Threat Labs

Author: June 30, 2023 by Jamf Threat Labs

Source: https://www.jamf.com/blog/jamf-protects-against-jokerspy-malware/

Bitdefender researchers and Elastic Security Labs discovered an intrusion targeting a cryptocurrency exchange in Japan. The intrusion involved the use of custom back door and open source macOS tools. Threat actors used various back doors to deploy spyware on victims’ systems in order to perform reconnaissance and for command and control.

Threat: JokerSpy

Effects:

According to Elastic Security Labs researchers, the threat actor attempted to bypass Transparency, Consent, and Control (TCC) permissions on macOS by creating their own TCC database and replacing the existing one. They also deployed a Python backdoor called sh.py, which loaded its configuration from a specific file and allowed for various commands and actions on the infected system. In their investigation, Elastic Security Labs researchers reported that the once the attackers gained access to the system with the JokerSpy back door, the attackers executed an instance of SwiftBelt, which is a known open source macOS post-exploitation reconnaissance toolset designed for red teaming.

Jamf Threat Labs has been effectively blocking JokerSpy malware since its initial public disclosure, demonstrating our dedicated focus on Apple platforms. The recent revelation of SwiftBelt usage in the attack also highlights Jamf’s capacity to quickly analyze new tools, create custom blocking rules, and keep pace with the evolution of new threats. Importantly, Jamf Protect has had custom rules to block SwiftBelt for over two years. This proactive approach distinguishes us from multi-platform vendors, who typically lag in addressing new Apple exploitation tools until they’ve been seen in active malware campaigns. This underscores our firm commitment to delivering the most comprehensive and up-to-date macOS security.

Prevented by:

Jamf Protect tracks this malware campaign and custom threat prevention rules block its execution as of June 19, 2023.

Additionally, Jamf Protect generically detects and alerts on the creation of counterfeit TCC databases (as seen in this attack) via the behavioral analytic: “TCC Database File Manually Created”. The TCC database keeps track of which applications a user has granted special permissions to such as Full Disk Access or access to their Contacts. Historically, exploits for this security feature have often required an attacker to create their own modified TCC.db file on disk and then convince the operating system to use that TCC.db file instead of the database created by macOS.

IOCs (as published by Bitdefender and Elastic):

Malicious URLs (as published by Bitdefender and Elastic):

Malware is nothing to laugh at — stay protected with Jamf.

by Pieter Beckmann

BlueNoroff APT group targets macOS with ‘RustBucket’ Malware

Jamf Threat Labs

Author: April 21, 2023 by Jamf Threat Labs

Source: https://www.jamf.com/blog/bluenoroff-apt-targets-macos-rustbucket-malware/

By Ferdous Saljooki and Jaron Bradley

Jamf Threat Labs has discovered a macOS malware family that communicates with command and control (C2) servers to download and execute various payloads. We track and protect against this malware family under the name ‘RustBucket’ and suspect it to be attributed to a North Korean, state-sponsored threat actor. The APT group called BlueNoroff is thought to act as a sub-group to the well-known Lazarus Group and is believed to be behind this attack. This attribution is due to the similarities noted in a Kaspersky blog entry documenting an attack on the Windows side. These similarities include malicious tooling on macOS that closely aligns with the workflow and social engineering patterns of those employed in the campaign.

Stage-One

The stage-one malware (0be69bb9836b2a266bfd9a8b93bb412b6e4ce1be) was discovered while performing normal hunting routines for compiled AppleScript applications that contained various suspicious commands. Among our results, we identified a suspicious AppleScript file titled main.scpt contained within an unsigned application named Internal PDF Viewer.app. It should be noted that we have no reason to believe this application is allowed to execute without the user manually overriding Gatekeeper.

The directory structure for the stage-one dropper is shown below. As with all compiled AppleScript applications, the primary app code is within the main.scpt file, located within the /Contents/Resources/Scripts/ directory.

Although the AppleScript was compiled, we were able to extract its contents by loading it into the macOS Script Editor application. When launched, the dropper executes the code seen below:

The stage-one simply executes various do shell script commands to download the stage-two from the C2 using curl. The malware writes and extracts the contents of the zip file to the /Users/Shared/ directory and executes the stage-two application also named Internal PDF Viewer.app. By breaking up the malware into several components or stages, the malware author makes analysis more difficult, especially if the C2 goes offline. This is a clever but common technique used by malware authors to thwart analysis.

At the time of our analysis, both the stage-one and stage-two components of this malware were undetected on VirusTotal.

Stage-Two

Although the stage-two (ca59874172660e6180af2815c3a42c85169aa0b2) application name and icons look very similar to stage-one, the directory structures are different and there is no use of AppleScript in the latter. The application version, size and bundle identifier — com.apple.pdfViewer — are also notably different, masquerading as a legitimate Apple bundle identifier. This application is signed with an ad-hoc signature as well.

The application layout is that of a much more traditional app and is written in Objective-C.

When the Internal PDF Viewer application is launched, the user is presented with a PDF viewing application where they can select and open PDF documents. The application, although basic, does actually operate as a functional PDF viewer. A task that isn’t overly difficult using Apple’s well-built PDFKit Framework.

Upon execution, the application does not perform any malicious actions yet. In order for the malware to take the next step and communicate with the attacker, the correct PDF must be loaded. We were able to track down a malicious PDF(7e69cb4f9c37fad13de85e91b5a05a816d14f490) we believe to be tied to this campaign, as it meets all the criteria in order to trigger malicious behaviors.

For example, when the malicious PDF is double-clicked from within Finder the user will see the following:

This minimal message informs the user that they must open the PDF using the necessary application in order to see the full details.

When opened within the malicious PDF viewer, the user will see a document (9 pages in total) that shows a venture capital firm that is interested in investing in different tech startups. From what we can tell, the PDF was created by taking the website of a small but legitimate venture capital firm and putting it into PDF format.

It should be noted here that earlier, the stage-one dropper reached out to cloud[.]dnx[.]capital, thus keeping on theme with the disguise of a venture capital firm.

This PDF viewer technique used by the attacker is a clever one. At this point, in order to perform analysis, not only do we need the stage-two malware but we also require the correct PDF file that operates as a key in order to execute the malicious code within the application.

So, how is the malware displaying a different PDF than the one loaded by the user?

To answer this, we take a closer look into some of the functions within the app. Most notably, we see one titled viewPDF as part of the PEPWindow class. This function seeks to a specific offset within the loaded PDF to check for a specific blob of data. If the expected data is present, a function called _encrypt_data is invoked, which, ironically runs code to decrypt the blob and produce a new PDF. It does this using a hardcoded 100-byte XOR key which can be found in the __CONST data of the executable.

This newly decrypted PDF is then displayed to the user in the application, providing the illusion that this app was truly necessary in order to view the full details of the PDF.

Since the embedded PDF file is loaded directly into the viewer, it is never written to the disk. Using a disassembler — such as Hopper — we can extract it by placing a breakpoint on the return in the encrypt_data function.

If analyzing the ARM executable (as opposed to the Intel executable), we can print the $x0 register which gives us all the bytes of the decrypted blob. Saving these bytes into a file will also reveal the inner PDF file.

Stage-Two Communication

So far we’ve decoded the PDF file that is embedded within the original PDF file, but as we stated earlier, this is the point where the malware will also phone home to the attacker. Much like the inner PDF document, the attacker’s C2 is also XOR encoded within the original PDF. This is why we see the encrypt_data function run a second time. The following bytes are passed to it which can be found towards the bottom of the original PDF document.

This time when the encrypt_data function runs using the same hardcoded XOR key as before, it returns the following:

After the embedded PDF has been displayed to the user and the URL has been de-obfuscated, the malware then calls a function titled _downAndExecute and makes a POST request to a C2 server to presumably retrieve and execute a stage-three payload.

In the _downAndExecute function shown below, we can see the various parameters being set in order to initiate an HTTP request.

The malware also creates a new thread and sleeps before making the POST request again in a loop until an HTTP 200 response is returned.

Unfortunately, at the time of our analysis, the server was not responding with the necessary message.

We have however managed to discover a new URL on the same domain that is hosting a Mach-O executable that we believe to be the new location of the final payload.

If the stage-two dropper succeeds in downloading the stage-three payload, we can view the next actions within the downAndExecute_block_invoke.

The aforementioned image shows the following steps taking place if the C2 responds:

  1. The malware creates a temporary directory and writes the received file to that temporary directory. The name of that malicious file will be the current mach timestamp (the number of seconds since midnight January 1st, 2001). An example file path would look like this:<strong>/</strong>var/folders/g6/w3s4hg8n57sgfjl4xgrhjs_w0000gn/T/703517604263
  2. Executable permissions are assigned to the new file.
  3. The program arguments are set and the file is executed. The set argument is that of the attacker C2 decoded from this stage two payload. The stage-three will go on to use this value.

Stage-Three

The stage-three payload (182760cbe11fa0316abfb8b7b00b63f83159f5aa) is an ad-hoc signed trojan written in Rust and weighing in at a sizable 11.2MB. It’s a universal binary that holds both ARM and x86 architectures. Upon initial execution, it performs a handful of system recon commands.

One of the earliest used modules is titled webT::getinfo. Within this module is the ability to look at the basic info about the system, process listing, current time and whether or not it’s running within a VM. The functions are named accordingly.

Running this malware results in communication to the URL provided as the first argument passed at execution time. The WebT::send_request function is responsible for sending the initial message to the C2 server. When placing a breakpoint on it, we can step over it resulting in a call to the server.

This payload allows the attacker to carry out further objectives on the system, but perhaps a deep dive on stage-three is best saved for another blog post.

At a High Level

We dove fairly deeply into some of the different actions of this malware. At a higher level, the workflow looks like the following:

Connections to BlueNoroff

There are a few signs that this malware is tied to BlueNoroff. First and foremost is the domain used in the stage-one dropper: cloud[.]dnx[.]capital. This domain was reported as being used by the attackers in a writeup done by Proofpoint. In the previously mentioned Kaspersky blog, it was reported that the attackers had created numerous fake domains impersonating venture capital firms and banks in a campaign Kaspersky titled ‘SnatchCrypto’. This aligns with the social engineering schemes discovered in the PDF document. The Windows malware also used the “decoy document” approach which clearly worked well for the attacker. The earliest submission of the “Internal PDF Viewer” we could find on VirusTotal was uploaded in January 2023 and we’ve observed the attackers continuing to host it.

While many different PDF payloads exist that work on Windows, so far only one PDF has been discovered that will result in a call to the attacker on macOS. We do suspect more than just this one PDF exists. It’s worth noting that the XOR key found within the malware can also be found within a variety of malicious PDF files. However, when loaded into the Viewer application, these files do not result in a properly decoded URL. We suspect a different variant of the malicious viewer (or perhaps a different platform) is capable of loading the XOR key from within the PDF instead of the attackers hardcoding it in the malicious app.

Conclusion

The malware used here shows that as macOS grows in market share, attackers realize that a number of victims will be immune if their tooling is not updated to include the Apple ecosystem. Lazarus group, which has strong ties to BlueNoroff, has a long history of attacking macOS and it’s likely we’ll see more APT groups start doing the same.

Jamf Protect defends against the malicious components of this malware and blocks the malicious domains. Jamf Threat Labs will continue to monitor BlueNoroff’s activity on this campaign.

A shout out to Patrick Wardle for his collaboration on some of the analysis here. If you’re looking to learn more about the analysis of macOS malware, check out the free online book: The Art of Mac Malware.

Indicators of Compromise

References:

Ensure your macOS endpoints are protected from current and novel Mac-centric threats.

Don’t just take Jamf’s word for it, put Jamf Protect to the test today.

by Pieter Beckmann

The web of connections with iOS 16.4.1

Jamf Threat Labs

Author: April 19, 2023 by Jamf Threat Labs

Source: https://www.jamf.com/blog/the-web-of-connections-with-ios-16-4-1/

Key Findings

  • Detailed analysis of changes in iOS 16.4.1 indicates that this may not be Apple’s first attempt at resolving exploits in this area of iOS
  • Correlating Jamf’s findings with research from Citizen Labs and Microsoft suggests that this fix may address zero-click exploits utilized by QuaDreams going back to iOS 14

Background

On April 7, Apple released iOS 16.4.1, which includes a fix for two vulnerabilities that Apple believes may have been actively exploited in the wild. The first vulnerability is related to IOSurfaceAccelerator, identified by CVE-2023-28206. The second vulnerability is related to WebKit, identified by CVE-2023-28205.

According to Apple, the IOSurfaceAccelerator vulnerability is an out-of-bounds write issue that was resolved through improved input validation. Jamf Threat Labs conducted an analysis of the IOSurfaceAccelerator vulnerability. This post includes the technical details from our investigation of CVE-2023-28206.

Our research identified six functions (highlighted in the screenshot below) that we believe have been altered as part of the security fixes in iOS 16.4.1.

Three of these functions have added a size check and the remaining functions have undergone offset changes. We believe this is directly related to CVE-2023-28206.

IosaColorManagerMSR8::getHDRStats_gatedContext

M2ScalerScalingASEControl::getASEStats_gatedContext

M2ScalerScalingASEControlMSR10::getASEStats_gatedContext

As part of our investigation, we have confirmed that ZecOps zero day detections identify the exploit of this vulnerability and we will alert impacted customers should it be triggered. Our team has not observed this exploit in the wild.

Our investigation also revealed connections to QuaDream’s one-click browser exploit, which matches the WebKit vulnerability and a kernel vulnerability that was patched with iOS 16.4.1. According to the CitizenLab blog, QuaDream’s spyware targeted iOS 14 devices.

Our analysis of iOS 14.4 and iOS 14.5 show that Apple introduced two size checks to IosaColorManagerMSR8::getHDRStats_gatedContext to prevent oob write.

On April 9, two days after the release of iOS 16.4.1, LinusHenze published a PoC for CVE-2023-28206, triggering an oob memmove in IosaColorManagerMSR8::getHDRStats_gatedContext. This exploit running successfully on iOS 16.4 shows that the patches Apple applied in iOS 14.5 did not completely resolve the IosaColorManagerMSR8::getHDRStats_gatedContext vulnerability.

Further investigation of our analysis of iOS 16.4.1 show that Apple reinforced IosaColorManagerMSR8::getHDRStats_gatedContext by incorporating an additional size check. This evidence suggests that Apple has enhanced the initial patch and we can confirm that the PoC code from LinusHenze fails to execute on iOS 16.4.1.

Summary

The release of iOS 16.4.1 is Apple’s latest attempt to patch kernel vulnerabilities that we believe have been exploited since iOS 14.4. As always, it is essential to update to the latest version of Apple’s software as soon as possible to ensure that your device is protected against these vulnerabilities.

The threat intelligence gathered by Jamf Threat Labs is powerful.

Protect your Apple fleet against current and novel mobile threats today and tomorrow!

by Pieter Beckmann

Jamf in the News: 2023 highlights so far

Jamf Threat Labs

Author: April 18, 2023 by Aleena Kaleem

Source: https://www.jamf.com/blog/Jamf-up-to-date-security-byod-innovations/

We’ve been seeing a lot about Jamf in the news lately. There are stories discussing our role in promoting employee choice programs. Stories about how we can help organizations block applications with security issues like TikTok, as well as the top threats facing organizations today. Stories about how businesses can make BYOD programs a reality.

Jamf Threat Labs also released critical threat research, reporting the discovery of Mac cryptomining malware in pirated copies of Final Cut Pro. This had wide media coverage including reports on: Fox News, 9to5 Mac, Dark Reading, Bleeping Computer and more.

Check out the latest on our Industry News page.

Jamf Industry News

Read on for a recap of some of our recent news highlights.

Jamf in the news highlights

“We know the demand is accelerating because, as Jamf CEO Dean Hager once told me, “Technology isn’t just part of the employee experience, it is the entire employee experience. So employers are going to want to make it a good one.” The momentum Apple has built in the enterprise has spawned a vast ecosystem of enterprise-friendly solutions providers who can help integrate its kit into existing deployments. Cisco even spoke at Jamf’s annual JNUC event to explain how it supports Macs across its business.” (You can watch Cisco’s JNUC video here.)

News featuring Jamf Threat Labs cryptomining malware story:

  1. Crypto-mining malware attacking Apple Mac with pirated software – Fox NewsPirated copies of the popular video editing software, Final Cut Pro, have been altered to contain a malicious instruction that takes over an infected Mac or MacBook, forcing it to act as a cryptocurrency mining machine for a hacker. Worse, this latest malware disguised as legit Final Cut Pro can bypass and shut down some of the security processes running on an infected device. Investigative sleuthing by security professionals at Jamf Threat Labs led to tracing the malicious Final Cut Pro copies back to a known bad actor with a history of uploading and spreading viruses. Since 2019, this same hacker is responsible for seeding multiple dangerous malware attacks hidden inside pirated copies of both Final Cut Pro and Logic Pro X.
  2. Well-hidden Mac cryptomining malware found in pirate copies of Final Cut Pro – 9to5 MacCybersecurity company Jamf Threat Labs has found Mac cryptomining malware in pirate copies of Final Cut Pro. The firm says that the cryptojacking malware was particularly well hidden, and not detected by most Mac security apps. Jamf also warned that the power of Apple Silicon Macs is going to make them increasingly popular targets for cryptojacking – where malware uses your machine’s considerable processing power to mine cryptocurrencies for the benefit of attackers.
  3. It’s not just Windows that gets malware – Tech HQSeemingly immune for so long, here’s a reminder that MacOS and Linux need to protect themselves against malware too. Security researchers at Jamf have found that torrents on The Pirate Bay, claiming to contain Final Cut Pro, are instead distributing cryptojacking malware to Macs. On installation of the pirated version of “Final Cut Pro,” users will see a message saying that the file is damaged and can’t be opened. Behind the scenes, the Mac is covertly mining cryptocurrency on behalf of cybercriminals, using up CPU cycles.

Security news

  • Why TikTok’s future has never been so cloudy – The VergeThe parent company of TikTok thought it had a deal with the government in August. Then came the bans– and a spying scandal. The movement to ban the app spread to Congress, and now TikTok is forbidden from being installed on devices owned by the federal government.

    “Jamf, which sells software to organizations to enable filtering and security measures on iPhones and other Apple devices, said its government customers have increasingly blocked access to TikTok since the middle of this year. About 65% of attempted connections to TikTok have been blocked this month on devices managed by Jamf’s public sector customers worldwide, including school districts and various other agencies, up from 10% of connections being blocked in June, the company said.” – Paresh Dave at Reuters

  • US National Cyber Strategy allays fears over liability for open source vulnerabilities – IT ProSoftware vendors will be held accountable for product vulnerabilities under new plans outlined by the Biden administration.

“The idea of taking NIST standards and suggesting companies out of compliance are negligent and liable for privacy breaches is interesting. The devil will be in the details, but a GDPR-like liability regime tied to real, pragmatic set of baseline control expectations will be a welcome change.” – Aaron Kiemele, Jamf CISO

  • Social engineering remains the top threat for enterprises – Beta NewsThe latest Annual Trends Report from Jamf, based on a sample of 500,000 devices protected by the company’s technology, looks at the threats impacting devices used in the modern workplace and finds social engineering tops the list.

“It’s important that users are made aware of the threat. We’re at a time where we’re hearing a lot about passwordless technologies. We’re seeing a lot of adoption in the consumer space of biometrics, and yet social engineering is still top for entities and organizations that are using compute and distributing it to their workers. And so for me, there’s a real call to action, that I hope comes out of this report, that continues to beat the drum around educating workers around phishing and modernizing that education program. I think so many are still stuck with focusing their phishing education around corporate email, but times have changed. Phishing is coming across in SMS and compromised ads and social media apps, I think it’s time that we make sure that workers are aware of all these different threat vectors.” – Michael Covington, VP, Jamf Portfolio Strategy

“With technology now firmly embedded in the student experience, there is a growing need for digital safety across all devices to eliminate cyberattacks and prevent students from accessing unsafe content. Jamf’s solutions historically have been built for the Apple ecosystem, but our goal has always been to empower safe student learning from whichever device they have access to. With Jamf’s best-in-class network threat prevention and a vast content-filtering database, students can now safely learn online from anywhere, whether they are using Apple devices or Chromebooks. We are excited about the continued partnership with Google to help keep students safe.” – Suraj Mohandas, Jamf VP of Strategy

“Organizations should update information protection policies to ensure that the types of applications that are acceptable handlers of confidential data are well documented. Controlling that flow of information begins with a well-documented and informed policy. Additionally, organizations should be exploring how they can utilize these new technologies to improve their businesses in a thoughtful way. Don’t shy away from these services out of fear and uncertainty but dedicate some staffing to explore new tools that show potential so you can understand the risks early and ensure adequate protections are in place when early end-user adopters want to start using the tools.” – Michael Covington, Jamf VP of Portfolio Strategy

“Personal data stolen from healthcare organizations normally ends up being bought and sold on the dark web for a high price. Healthcare providers in the US are a particularly popular target for threat actors as data usually commands a higher price due to the country’s affluence and economy. Healthcare providers are constantly adding new endpoints such as tablets, laptops and other interconnected devices to their networks, which exposes them to new attack vectors. With more devices connected to the network, it widens the attack surface, and ultimately, makes it harder to maintain visibility across the network, leaving gaps for threat actors to exploit.” – Adam Mahmud, Jamf Senior Product Marketing Manager

Network access news

“The failure to offer a bring-your-own-device (BYOD) option is a completely missed opportunity for businesses looking to improve employee experience, cut costs on device training/distribution, and ensure employees’ data privacy. In fact, a recent report by Cisco found that BYOD improves employees’ creativity, productivity and pride in their workplace, and also offers companies cost savings of an average of $350 per year, per employee.” – Michael Covington, Jamf VP of Portfolio Strategy

“The ultimate IT admin and end-user experience can be unlocked when you find a set of solutions that can integrate and holistically deliver all of these pillars. A holistic approach to trusted access can ensure that end-user interruption is minimized while streamlining administration to deliver maximum performance and functionality as product capabilities evolve. Additionally, end users can have the intended powerful technology experience without having to interface with various applications interrupting them with reauthentication prompts and disjointed alerts.” – Dean Hager, Jamf CEO

Equity in tech industry news

Linh Lam, CIO at Jamf, said that her curiosity led her to the point she is now at: “I didn’t set out to be a CIO. My career (that I love) was a product of my curiosity in problem solving and technology. When girls are young, we need to expose them to science, technology and the fun career opportunities in tech, so they know it’s not just a possibility, it’s reality.”

  • IWD 2023: Embracing equity starts with backing yourself – Channel Life AUMelissa Antonie, Senior Manager of Customer Success APAC at Jamf, wrote about the importance of backing yourself and the struggles she faced with imposter syndrome. She shared how her team at Jamf supported and vouched for her to become one of Jamf’s APAC business leaders.

Stay tuned…

And that’s just a small sampling! We look forward to sharing more news coverage about exciting new developments at Jamf as the rest of the year unfolds.

Learn more about Jamf!

by Pieter Beckmann

Threat advisory: Mobile spyware continues to evolve

Jamf Threat Labs

Author: April 17, 2023 by Jamf Threat Labs

Source: https://www.jamf.com/blog/threat-advisory-mobile-spyware-continues-to-evolve/

Introduction

Jamf Threat Labs has been studying the ongoing use of sophisticated spyware, including indicators previously attributed to NSO Group’s Pegasus, to target iPhones used by high-risk individuals. Over a period of six months, Jamf Threat Labs investigated multiple mobile devices belonging to different individuals and organizations that showed unique indicators of compromise (IOCs) and evidence of active spyware campaigns.

This advisory is intended to highlight the active use of spyware against workers in a variety of regions and to share research with the security community that can help with the ongoing monitoring of these exploits.

To protect the organizations and individuals that have been targeted, we have anonymized certain details, but that does not change the findings; all other findings remain intact for analysis.

What we know

  • Targeted spyware has been identified in attacks around the globe
    • Users in multiple regions have been impacted by spyware over the past six months
    • The instances have each involved individuals at high risk of targeted attacks
    • Each attack scenario has yielded unique indicators of compromise
    • Variations in the compromised hardware and software indicate that new exploits continue to be discovered as security patches are issued, expanding the population of vulnerable devices
  • Apple is actively monitoring devices for compromise
    • Apple notified one of the compromised users working with Jamf Threat Labs and confirmed unusual activity on the device
    • Not all users impacted by spyware have been contacted by Apple, illustrating the challenges with maintaining a comprehensive list of IOCs and with extracting relevant data remotely
  • High-risk individuals and organizations do not consistently execute full investigations as a result of threat indicators or user-reported issues
    • Some organizations pursue complete investigations in response to threat indicators to confirm attacks
    • Some organizations decide to wipe devices upon seeing initial IOCs without performing a full analysis on the device
    • Inconsistent investigations and data collection hinders timely and comprehensive research on emerging attacks

Verifying a mobile spyware infection

The first device we will examine is an iPhone 12 Pro Max that was used as the daily communications tool by a human rights activist based in the Middle East. We will subsequently refer to this as the Middle East iPhone.

A known IOC

Analysis from Jamf Threat Labs revealed traces of the “libtouchregd” process. According to Amnesty International, this process name is an IOC associated with the Pegasus spyware.

While another threat actor purposefully reusing the same process name for misattribution can never be entirely ruled out, it is unlikely in the case of the Middle East iPhone for the following reasons:

  • Another threat actor would not want to name their processes the same name since this can lead to an unwanted discovery of an attack and destroy the exploit chain used in the attack.
  • Jamf Threat Labs has determined that the attack on the device from the Middle East happened three months before the publication of Amnesty International’s IOCs. Therefore, the chances of a third party mimicking the process identified in the Amnesty report prior to publication is reduced significantly.

Therefore, our analysis strongly suggests that the same threat actor that was described by the Amnesty International blog is behind the attack on the Middle East iPhone.

Indicator of possible exploitation via crash log analysis

The Middle East iPhone also yielded additional indicators of compromise via subsequent analysis of the com.apple.CrashReporter.plist file.

The com.apple.CrashReporter.plist file is located within a root folder on iOS (/private/var/root/Library/Preferences/). This plist serves as a configuration file for the system daemon, ReportCrash.

Under normal operating conditions, applications are not granted permission to access or modify this file. Alteration of this file could potentially impede the reporting of crash report logs to Apple. Additionally, the existence of the file is rare for normal users.

In rare cases that this file exists legitimately, it will keep state for urgentSubmission crash reports and have contents similar to the following example. This example illustrates that there have been 5 crash logs classified as urgentSubmission, with the last submitted on Thursday, March 9, 2023 (19425 days since Jan 1 1970).

The system daemon ReportCrash defines urgentSubmission. On Beta versions of iOS all crash logs are considered urgentSubmission. Otherwise, ReportCrash reserves its usage for the reporting of rare and critical events (see below).

Analysis of the ReportCrash daemon on iOS 16.2 leads us to believe that only crash logs that meet a strict set of criteria will be classified as urgentSubmission. These conditions include:

  • Special types of reports, such as probGuard and quarantine.
  • Undefined behavior detected by the UBSan, a tool utilized by LLVM to detect issues at runtime.
  • A specific snapshot error code, as the snapshot mechanism is utilized to maintain the integrity of the file system.
  • Various overflow alerts from the libsystem_c library.

Ultimately, Jamf Threat Labs treats the existence of these urgent submission reports as an indicator of exploitation requiring follow-on device analysis.

Official notification

In late 2022, the targeted user of the Middle East iPhone received a threat notification from Apple, notifying them of a potential attack and recommending that the device be updated to iOS 16.2. Following the update, the user engaged with security researchers to better understand the attack timeline and details.

Upon investigation, the Middle East iPhone proved to be a treasure trove for our analysis given the compounded set of compromise indicators and the clear association with Pegasus. These findings have allowed Jamf Threat Labs to build a more robust profile on a device with “proven” compromise status.

Analyzing spyware targeting older iPhones

The second device we will showcase is an iPhone used by a journalist in Hungary working for a global news agency. We will subsequently refer to this as the Hungary iPhone. It is noteworthy that this device was an iPhone 6s, a device that is no longer supported with the latest iOS version.

Screenshot of all iPhones compatible with iOS 16, including iPhone 14, 13, 12, 11, Xs, Xr, X, 8, and SE second gen or later

New IOC discovery via filesystem analysis

Like the Middle East iPhone, the Hungary iPhone showed evidence of critical system crashes as indicated by the existence of a com.apple.CrashReporter.plist file discussed in detail above.

Even more suspiciously, the Hungary iPhone included files found at an atypical location within iPhone’s strict filesystem. Furthermore, at least one file at this location is clearly masquerading as a built-in binary: /private/var/containers/appconduitd_helper. Based on this path and filename, we have strong reason to believe this may be a new indicator that can be used to assess if a device has been targeted by this threat actor. We have also notified Apple of this potential new indicator.

While we have seen similar activities across other targeted devices, we cannot conclusively determine that the Hungary iPhone was compromised by a specific threat actor. Based on previous infections by a threat actor that shares striking similarities, we estimate that the Hungary iPhone was targeted using a commercial tool.

iPhone 6s and Unsupported Devices

The continued targeting of older devices, such as the iPhone 6s, serves as a reminder that malicious threat actors will exploit any vulnerabilities in an organization’s infrastructure, attacking wherever possible.

Apple occasionally releases updates to prior iOS versions to back-port critical security fixes to older devices. iOS 15.7.5 was released on April 10, 2023, which is the latest iOS version available for iPhone 6s at the time this blog was published. It is important to note that not all vulnerabilities are addressed on prior iOS versions for legacy devices, and newer security mitigations may not be back-ported either. Additionally, these security patches often trail updates issued for current OS versions (iOS 15.7.5 contained security fixes that Apple patched three days earlier in iOS 16.4.1). As a result, threat actors can continue to exploit unpatched vulnerabilities that have been patched on newer supported devices, potentially giving attackers more time and more information to gain remote access to targeted devices.

As a general best practice, we strongly recommended upgrading outdated devices to newer iPhone or iPad models that are running the latest available updates and operating system versions.

Recommended actions

Modern spyware is very advanced and, as evidenced by the continued evolution of commercial spyware, continues to leverage zero-day vulnerabilities in both old and new devices to ensure any user can be effectively targeted.

Though the attacks through commercial spyware are expensive to operate, any individual or organization with mobile devices that are used to access sensitive data should take action to implement a layered set of defenses to insulate from attack.

Jamf Threat Labs recommends that organizations:

  • Ensure all devices are running the most current operating system and have all available security patches applied.
  • Keep all applications, both business oriented and personal, up-to-date and fully patched; mobile application vulnerabilities are easily exploited and frequently overlooked by security teams.
  • Run security software to monitor for suspicious activity and report alongside all other endpoint monitoring dashboards, ensuring that mobile devices are treated with the same attention and urgency as desktops, laptops and servers.
  • Monitor communications for suspicious downloads, command & control indicators and data exfiltration; utilize automated policy controls to block known bad activity before it can cause further damage.
  • Educate high-risk users about the symptoms of spyware, which can include performance issues and frequent crashes. Encourage them to reach out to their security team if they observe any of these issues to maximize the extraction of IOCs from their device.
  • Encourage high-risk users to use Lockdown Mode, which is designed to protect devices against extremely rare and highly sophisticated cyber attacks.
  • Implement a security monitoring process that includes mobile telemetry analysis and stay up-to-date on known IOCs related to mobile spyware.

Learn more about how you can engage Jamf Threat Labs within your organization.

by Pieter Beckmann