{
	"id": "74f80107-e589-4053-95af-f28f69beaf53",
	"created_at": "2026-04-06T00:06:37.952095Z",
	"updated_at": "2026-04-10T13:12:38.632133Z",
	"deleted_at": null,
	"sha1_hash": "42281f8d269b82f5bb7b77ee1bea2518bd2813b1",
	"title": "OSX.XLoader hides little except its main purpose: What we learned in the installation process",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 174592,
	"plain_text": "OSX.XLoader hides little except its main purpose: What we\r\nlearned in the installation process\r\nBy Thomas Reed\r\nPublished: 2021-07-25 · Archived: 2026-04-05 16:28:55 UTC\r\nLast week, Check Point Research described a new Mac variant of malware they call XLoader. It was identified as\r\nbeing the successor of something called Formbook, a very prevalent threat in the Windows world. According to\r\nCheck Point, the Mac version of the malware is being “rented” as part of a malware-as-a-service program, at the\r\nprice of $49 for one month or $99 for three months.\r\nUnfortunately, Check Point was a bit vague on the details of how the Mac version behaves, leaving folks unsure of\r\nexactly how to protect themselves against this malware. Fortunately, more details have since come to light.\r\nHow XLoader gets installed\r\nXLoader appears to be distributed within a .jar – or Java archive – file. Such a file contains code that can be\r\nexecuted by Java, dropping the malware on the system. One major advantage, for the attacker, of using Java is that\r\nthe “dropper” (the file responsible for installing the malware) can be cross-platform.\r\nHowever, this file format has a very significant disadvantage for the attacker, which is that macOS does not, by\r\ndefault, include Java, and has not for quite some time. Back around 2011 to 2012, there was a flood of multiple\r\ndifferent pieces of malware designed to infect Macs via vulnerabilities in Java, which at the time was installed on\r\nevery Mac out of the box. This meant that all Macs were vulnerable, and to make matters worse, despite updates\r\nfrom Oracle (Java’s owner), more vulnerabilities kept being found and exploited.\r\nApple responded by ripping Java out of the system. Since then, the only way Java can be on a system is if the user\r\nhas installed it, which most users won’t. This means that Java is no longer a very useful means of attack on\r\nmodern macOS systems.\r\nThere can be a couple reasons why a JAR file might be used on macOS. One is unfamiliarity with modern\r\nmacOS, from a malware developer who has Java on their system but doesn’t understand this is non-standard for\r\nsome reason. This is something often seen with more amateurish malware, and there are definitely some\r\nindications of that with this malware.\r\nHowever, another reason is that the malware is targeted at specific individuals who are known to have Java\r\ninstalled. These could be Java developers, for example, at a particular company, or perhaps employees at a\r\ncompany that uses Java-based tools. A source at ESET reported that they had detected this malware back in\r\nJanuary, with the JAR file being distributed via email. This points to a targeted campaign.\r\nThe installation process\r\nhttps://blog.malwarebytes.com/mac/2021/07/osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-process/\r\nPage 1 of 5\n\nThe dropper – named Statement SKBMT 09818.jar in this case – would need to be opened by the user. The good\r\nnews is that, if it was downloaded from an email client or browser that uses modern file system code, it will be\r\nmarked with a “quarantine” flag. This means that the Gatekeeper feature of macOS will not allow it to execute by\r\ndefault.\r\nThere are ways that Mac users can bypass this and open the file anyway, but not without seeing a similar warning\r\nfirst.\r\nStill, a significant amount of Mac malware droppers in the last year or so have been unsigned, and have given\r\nusers instructions on what to expect and how to open the file. In such cases, users can and do bypass these\r\nwarnings and open the malicious installers successfully.\r\nIn the event that the user downloads the JAR file using an email client that does not use the right file system code,\r\nand thus does not set a quarantine flag, the file will immediately open when double-clicked, without any\r\ncomplaints. The same will also be true if the file is copied onto a non-Mac drive before being opened, such as a\r\nWindows network share, where the quarantine flag will be lost.\r\nhttps://blog.malwarebytes.com/mac/2021/07/osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-process/\r\nPage 2 of 5\n\nOnce opened, the JAR file will infect the system, and strangely, will also open a .ico (icon) file containing a\r\nMicrosoft word icon image.\r\nIt’s unknown why this is done. It’s not uncommon for malware to open a “decoy document.” In such cases, when\r\nthe malware pretends to be a document (as in this case, where the malware is pretending to be a statement of some\r\nkind), it will then open a document for the user to look at, to assuage suspicions the user would have if no\r\ndocument ever opened, while it’s doing bad stuff behind the scenes.\r\nIs this a really badly botched attempt to open a decoy document? Or is it possible that this wasn’t meant as a\r\npublic release, and the file being opened is a placeholder? Either would be a reasonable explanation, but we don’t\r\nknow which is true.\r\nWhile the user is looking in confusion at this wonderful icon, the JAR code will install the malware in the\r\nbackground. On my test machine, the malware installed the following items:\r\n~/._p1pxXl0Fz4/I8ppUnip.app\r\n~/kIbwf02l\r\n~/NVFFY.ico\r\n~/LaunchAgents/com._p1pxXl0Fz4.I8ppUnip.plist\r\nThe launch agent .plist file is used to load the app from the hidden folder ( ._p1pxXl0Fz4 ) found in the user\r\nfolder. The\r\nkIbwf02l\r\nfile is an exact copy of the Mac mach-o executable file found inside the app, but it’s unclear why this is left there,\r\nas it isn’t actually used. It’s a suspiciously-named file that will be visible to the user and thus may raise suspicions,\r\nso its presence is odd.\r\nThe NVFFY.ico file is the Microsoft Word icon file opened by the malware as a “decoy.”\r\nhttps://blog.malwarebytes.com/mac/2021/07/osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-process/\r\nPage 3 of 5\n\nA closer look at the Java code\r\nExtracting the Java code from the JAR file was a painless task, and the code is not obfuscated in any way. The\r\ncode is quite simple, but is able to drop a payload on either Windows or Mac. If you’re not interested in looking at\r\ncode, feel free to skip ahead.\r\nThe filenames are hard-coded in the JAR file, as seen here.\r\nprivate static String get_crypted_filename(final int pt) { final String exe_ = \"fI4sWHkeeeee\";\r\nIt’s a bit of a stretch to call these filenames “encrypted,” as the only thing that has been done to them is that a\r\nspecific letter has been added to the end, repeating a varying number of times. (What letter is used depends on the\r\nstring in question, and is also hard-coded.) These characters are stripped off to get the filenames, resulting in the\r\nmach-o filename of kIbwf02l and the “display” document filename of\r\nNVFFY\r\n.\r\nThe malware has quite simple code for determining the system it’s running on:\r\npublic static int _GetOS() { final String OS = System.getProperty(\"os.name\").toLowerCase(); i\r\nFrom there, the malware reads encrypted data from within the JAR file and writes it out to the desired location on\r\nthe system (in this case, the kIbwf02l file).\r\nprivate byte[] getFileFromResource(final String name) throws Exception { try (final InputStream i\r\nFrom there, the malware launches the malicious process and opens the decoy document (aka “displayFile”).\r\n if (osFile != null \u0026\u0026 osFile.length != 0) { final String absolutePath = userPath\r\nThe malicious application\r\nThe malicious Mac application, dropped and executed by the JAR file, is heavily obfuscated, making it hard to\r\nlearn more about what it does. According to analysis done by SentinelOne, one of the app’s main goals appears to\r\nbe harvesting credentials.\r\nThe app itself is not code signed in any way. However, since it was created by the JAR and not downloaded from\r\nanywhere, it can be executed without Gatekeeper examining it or asking for user consent to run it. The launch\r\nagent .plist file is used to ensure the app is launched at startup, but explicitly does not try to keep the process alive.\r\nThis means that if anything terminates the malicious process, it will not re-open until the next reboot.\r\nhttps://blog.malwarebytes.com/mac/2021/07/osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-process/\r\nPage 4 of 5\n\nThe app itself has been marked as an LSUIElement, which is done to prevent its icon from showing on the Dock\r\nwhenever it is running. This is a feature intended to be used by apps responsible for managing some user interface\r\nelement – such as a menu bar icon – but that do not have a user interface of their own and thus can’t be interacted\r\nwith directly. This prevents the Dock from being littered with these kinds of apps, but is a common technique used\r\nto prevent malicious apps from appearing in the Dock.\r\nTL;DR\r\nTo sum up, this malware is likely to be used for targeted attacks against intended victims who are known to have\r\nJava installed. Attackers may also have knowledge that something in the victims’ environment will enable users to\r\neasily open a JAR file without being blocked by Gatekeeper.\r\nThe dropper itself is completely unsophisticated, with barely an attempt to hide anything, while the mach-o\r\nexecutable used in the malicious application installed on the system is quite well protected against prying eyes.\r\nThis may be an indication that the two components of the malware were developed by different individuals.\r\nThis malware will be detected by Malwarebytes for Mac as OSX.XLoader. However, as of yet, data shows that\r\nMalwarebytes has not detected a single instance of this malware in the wild.\r\nAbout the author\r\nHad a Mac before it was cool to have Macs. Self-trained Apple security expert. Amateur photographer.\r\nSource: https://blog.malwarebytes.com/mac/2021/07/osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-proc\r\ness/\r\nhttps://blog.malwarebytes.com/mac/2021/07/osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-process/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/mac/2021/07/osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-process/"
	],
	"report_names": [
		"osx-xloader-hides-little-except-its-main-purpose-what-we-learned-in-the-installation-process"
	],
	"threat_actors": [],
	"ts_created_at": 1775433997,
	"ts_updated_at": 1775826758,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/42281f8d269b82f5bb7b77ee1bea2518bd2813b1.pdf",
		"text": "https://archive.orkl.eu/42281f8d269b82f5bb7b77ee1bea2518bd2813b1.txt",
		"img": "https://archive.orkl.eu/42281f8d269b82f5bb7b77ee1bea2518bd2813b1.jpg"
	}
}