{
	"id": "277437d9-6369-400f-adbb-52468a4e388a",
	"created_at": "2026-04-06T00:09:09.299798Z",
	"updated_at": "2026-04-10T13:12:07.632057Z",
	"deleted_at": null,
	"sha1_hash": "2ab03001d627bc5357aa2df1241d46d2007ad40c",
	"title": "Resourceful macOS Malware Hides in Named Fork - SentinelLabs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5733584,
	"plain_text": "Resourceful macOS Malware Hides in Named Fork - SentinelLabs\r\nBy Phil Stokes\r\nPublished: 2020-11-05 · Archived: 2026-04-05 19:44:24 UTC\r\nThroughout 2020, we’ve seen a number of developments in macOS threat actor tactics. These have included shifts\r\nto shell scripts, making use of alternative programming languages like Rust and Go, packaging malware in\r\nElectron apps, and notably, beating Apple’s notarization security checks through the use of steganography. Many\r\nof these techniques have exploited new or recent changes or developments, but one technique we have observed\r\ntakes the opposite tack and leverages a legacy technology that’s been around since Mac OS 9 in order to hide its\r\nmalware payload from both users and file scanning tools on macOS 10.15 and beyond. In this post, we look at\r\nhow a new variant of what appears to be Bundlore adware hides its payload in a named resource fork.\r\nMalware Distribution\r\nThe malware can be found in the wild being distributed on sites that offer “free” versions of popular software. In\r\nthis case, we found the malware being distributed by a site called “mysoftwarefree”, promising users a free copy\r\nof Office 365.\r\nhttps://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nPage 1 of 7\n\nUsers are instructed to remove any current installation of Office, to download the legitimate free trial from\r\nMicrosoft and then to download the “required files” from a button on the malicious site in order to obtain “a full\r\nversion of Office 365 ProPlus, without any limitations”.\r\nOnce the user takes the bait, a file called simply “dmg” is downloaded to the user’s device.\r\nThe Extended Attributes of a Named Resource Fork\r\nInside the mounted disk image, things are far from what the malware site promised the user. No copy of MS\r\nOffice, but what looks pretty much like a typical “Bundlore/Shlayer” dropper.\r\nhttps://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nPage 2 of 7\n\nAs is common with these disk images, there are graphical instructions to help the user bypass the built in macOS\r\nsecurity checks offered by Gatekeeper and Notarization. On macOS Catalina, this bypass will not prevent\r\nXProtect from scanning the code on execution, but this particular code isn’t known to XProtect at the current time.\r\nIf we take a trip to the Terminal to inspect more closely what’s on the disk image, surprisingly it seems like not\r\nmuch.\r\nNote, however, the @ on the permissions listing for the tiny 203 byte Install.command file. That indicates that\r\nthe file has some extended attributes, and that’s where things get interesting.\r\nWe can list the extended attributes using xattr -l . It seems that there is a com.apple.ResourceFork attribute,\r\nwhich at least at the beginning seems like an icon file. This is not unusual. Resource forks like this have been\r\nhttps://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nPage 3 of 7\n\nhistorically used to store things like thumbnail images, for example.\r\nHowever, this resource fork is pretty large. If we scroll down to the bottom, we see it’s about 141744 bytes of\r\nadded data.\r\nhttps://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nPage 4 of 7\n\nMore tellingly, if we inspect the Install.command file itself, we’ll see it’s a simple shell script that gives away the\r\ngame as to what’s really packed inside the resource fork.\r\nStarting at offset 9092, the script pipes the data in the fork through the funzip utility with the password “oZwb”\r\nto decrypt the data, dropping it in the Darwin User TMPDIR with a random name prefixed with “Installer”.\r\nThe file turns out to be a Mach-O with the SHA256 of\r\n43b9157a4ad42da1692cfb5b571598fcde775c7d1f9c7d56e6d6c13da5b35537\r\nA quick look on VirusTotal shows that SentinelOne’s Static AI engine recognizes this as a malicious file, tagged\r\nby some vendors as a Bundlore variant.\r\nhttps://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nPage 5 of 7\n\nSo What’s a Resource Fork and Why Use It?\r\nA resource fork is a kind of named fork, a legacy filesystem technology used to store structured data such as\r\nimage thumbnails, window data and even code. Instead of storing information in a series of bytes at particular\r\noffsets, a resource fork keeps data in a structured record, similar to a database. Interestingly, the resource fork does\r\nnot have a size limit beyond the size of the file system itself, and – as we’ve seen here – the fork is not visible\r\ndirectly in either the Finder or the Terminal, unless we list the file’s extended attributes via either ls -l@ or\r\nxattr -l .\r\nUsing a resource fork to hide malware is a pretty novel trick that we haven’t seen before, but it leaves open a few\r\nquestions as to the actor’s purpose in using this technique. Although the compressed binary file is hidden from the\r\nFinder and from the Terminal in this way, as we saw, it is easily found by anyone looking for it simply by reading\r\nthe Install.command shell script.\r\nHowever, many traditional file scanners will not pick up this technique. Other Bundlore variants have used\r\nencrypted text files within Disk Image containers and application bundles, but scanners can quickly be taught to\r\nfind these. One of the things that gives such files away is the extreme length of obfuscated or encrypted code,\r\ntypically base64, which is anomalous for legitimate software.\r\nBy hiding the encrypted and compressed file in the named resource fork, the actors are clearly hoping to evade\r\ncertain kinds of scanning engines. Although this sample in the wild was not code signed and, therefore, not\r\nsubjected to Apple’s notarization check, in light of the steganography trick used by recent Bundlore variants that\r\ndid bypass Apple’s automated checks, it remains an open-question whether using a resource fork in this way could\r\nalso help threat actors sidestep Notarization checks in future.\r\nhttps://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nPage 6 of 7\n\nConclusion\r\nHiding malware in a file’s resource fork is just the latest trick that we’ve seen macOS malware authors use to try\r\nand evade defensive tools. While not particularly sophisticated and easy to spot manually, it’s a clever way to\r\nevade certain tools that are not supported by dynamic and static AI detection engines.\r\nAddendum: post-publication, we learned that macOS malware researcher @gutterchurl had also previously\r\nwritten up a very similar campaign using a file’s resource fork here.\r\nSample Hashes\r\nDisk Image\r\nSHA1: 06842f098ba7e695a21b6a1a9bd6aee6daeb8746\r\nSHA256: 5673ace10a07905503486f5f4eeb8d45a4d56a2168b0274084750f68eb7a1362\r\nMach-O\r\nSHA1: e978fbcb9002b7dace469f00da485a8885946371\r\nSHA256: 43b9157a4ad42da1692cfb5b571598fcde775c7d1f9c7d56e6d6c13da5b35537\r\nSource: https://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nhttps://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://labs.sentinelone.com/resourceful-macos-malware-hides-in-named-fork/"
	],
	"report_names": [
		"resourceful-macos-malware-hides-in-named-fork"
	],
	"threat_actors": [],
	"ts_created_at": 1775434149,
	"ts_updated_at": 1775826727,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2ab03001d627bc5357aa2df1241d46d2007ad40c.pdf",
		"text": "https://archive.orkl.eu/2ab03001d627bc5357aa2df1241d46d2007ad40c.txt",
		"img": "https://archive.orkl.eu/2ab03001d627bc5357aa2df1241d46d2007ad40c.jpg"
	}
}