{
	"id": "10dea1c9-b039-4dfc-bf9b-102c3a480d53",
	"created_at": "2026-04-06T00:09:23.17385Z",
	"updated_at": "2026-04-10T13:12:42.156874Z",
	"deleted_at": null,
	"sha1_hash": "32054571e93dbab573614595ed27bc301bef9df5",
	"title": "Middle East Cyber-Espionage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1645309,
	"plain_text": "Middle East Cyber-Espionage\r\nArchived: 2026-04-05 20:48:00 UTC\r\nMiddle East Cyber-Espionage\r\nanalyzing WindShift's implant: OSX.WindTail (part 1)\r\nDecember 20, 2018\r\nOur research, tools, and writing, are supported by “Friends of Objective-See”\r\nToday’s blog post is brought to you by:\r\n📝 👾 Want to play along?\r\nI’ve shared various OSX.WindTail samples (password: infect3d) …don’t infect yourself!\r\nIn this blog post, we’ll analyze the WindShift APT group’s 1st-stage macOS implant: OSX.WindTail (likely\r\nvariant A )\r\nSpecifically we’ll detail the malware’s:\r\ninitial infection vector\r\nmethod of persistence\r\ncapabilities\r\ndetection and removal\r\nBackground\r\nA few months ago, Taha Karim (head of malware research labs, at Dark Matter) presented some intriguing\r\nresearch at Hack in the Box Singapore.\r\nIn his presentation, “In the Trails of WindShift APT”, he detailed a new APT group (WindShift), who engaged in\r\nhighly-targeted cyber-espionage campaigns. A Forbes article “Hackers Are Exposing An Apple Mac Weakness In\r\nMiddle East Espionage” by Thomas Brewster, also covered Karim’s research, and noted that:\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 1 of 14\n\n“[the APT] targeted specific individuals working in government departments and critical infrastructure\r\nacross the Middle East”\r\nTo me, besides WindShift’s targets, the most intriguing aspect of this APT group was (is?) their use of macOS\r\nvulnerabilities and custom macOS implants (backdoors). In his talk, Karim provided a good overview of the\r\ntechnique utilized by WindShift to infect macOS computers, and the malware they then installed\r\n( OSX.WindTail.A , OSX.WindTail.B , and OSX.WindTape ). However, my rather insatiable technical cravings\r\nweren’t fully satisfied, so I decided to dig deeper!\r\nFrom the details Karim’s talk, I was able to replicate WindShift’s macOS exploitation capabilities:\r\nMy blog post, “Remote Mac Exploitation Via Custom URL Schemes”, describes the technical details of how\r\nWindShift (ab)used custom URL schemes to infect macOS systems. The image below provides a illustrative\r\noverview.\r\n…however, as the malware samples discussed in Karim’s talk were never publicly shared, a full-technical analysis\r\nwas never available…until now!\r\nAnalyzing OSX.WindTail\r\nEarlier today, Phil Stokes, uncovered an interesting application on VirusTotal. He noted that in Karim’s talk, one\r\nof the slides contained a file name: Meeting_Agenda.zip …which was identified as by Karim as malware:\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 2 of 14\n\nOn VirusTotal, if we search for files with this name, we find what appears to be a match!\r\nThe sample (SHA-1: 4613f5b1e172cb08d6a2e7f2186e2fdd875b24e5 ) is currently only detected by two anti-virus\r\nengines:\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 3 of 14\n\nUsing the similar-to: search modifier, I uncovered three other samples, that are not flagged as malicious by\r\nany anti-virus engine!\r\nNPC_Agenda_230617.zip1\r\nSHA-1: df2a83dc0ae09c970e7318b93d95041395976da7\r\nScandal_Report_2017.zip\r\nSHA-1: 6d1614617732f106d5ab01125cb8e57119f29d91\r\nFinal_Presentation.zip\r\nSHA-1: da342c4ca1b2ab31483c6f2d43cdcc195dfe481b\r\nIf we download and extract these applications, the uses Microsoft Office icons, likely to avoid raising suspicion:\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 4 of 14\n\nIn his talk, Karim notes, “[the WindShift] attackers gave a backdoor a realistic look by mimicking an Excel sheet\r\nicon”.\r\n…the fact that our samples all similarly utilize Microsoft Office icons, is the first (of many) characteristics that\r\nlead us to confidently tie these samples to the WindShift APT group.\r\nVia the WhatsYourSign utility, we can confirm that indeed they are applications (not documents):\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 5 of 14\n\nMoreover the utility indicates that the application (i.e. Final_Presentation.app ) is neither fully signed and that\r\nits signing certificate has been revoked. We can confirm this with the codesign and spctl utilities:\r\n$ codesign -dvvv Final_Presentation.app\r\nExecutable=Final_Presentation.app/Contents/MacOS/usrnode\r\nIdentifier=com.alis.tre\r\nFormat=app bundle with Mach-O thin (x86_64)\r\n...\r\nAuthority=(unavailable)\r\nInfo.plist=not bound\r\nTeamIdentifier=95RKE2AA8F\r\nSealed Resources version=2 rules=12 files=4\r\nInternal requirements count=1 size=204\r\n$ spctl --assess Final_Presentation.app\r\nFinal_Presentation.app: CSSMERR_TP_CERT_REVOKED\r\nThe fact that the signing certificate(s) of all the samples are revoked ( CSSMERR_TP_CERT_REVOKED ) means that\r\nApple knows about about this certificate…and thus surely this malware as well. …yet the majority of the samples\r\n(3, of 4) are detected by zero anti-virus engines on VirusTotal.\r\nDoes this mean Apple isn’t sharing valuable malware/threat-intel with AV-community, preventing the creation of\r\nwidespread AV signatures that can protect end-users?! 🤔\r\nNarrator: yes*\r\n*of course sometimes they may not have permission (if the information was sourced from elsewhere).\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 6 of 14\n\nBefore diving into reversing/debugging these samples, let’s take quick peak at their application bundles:\r\nFirst, note the main executable is named usrnode . This is also specified in the application’s Info.plist file\r\n( CFBundleExecutable is set to usrnode ):\r\n$ cat /Users/patrick/Downloads/WindShift/Final_Presentation.app/Contents/Info.plist\r\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\r\n\u003cplist version=\"1.0\"\u003e\r\n\u003cdict\u003e\r\n ...\r\n \u003ckey\u003eCFBundleExecutable\u003c/key\u003e\r\n \u003cstring\u003eusrnode\u003c/string\u003e\r\n ...\r\n \u003ckey\u003eCFBundleIdentifier\u003c/key\u003e\r\n \u003cstring\u003ecom.alis.tre\u003c/string\u003e\r\n ...\r\n \u003ckey\u003eCFBundleURLTypes\u003c/key\u003e\r\n \u003carray\u003e\r\n \u003cdict\u003e\r\n \u003ckey\u003eCFBundleURLName\u003c/key\u003e\r\n \u003cstring\u003eLocal File\u003c/string\u003e\r\n \u003ckey\u003eCFBundleURLSchemes\u003c/key\u003e\r\n \u003carray\u003e\r\n \u003cstring\u003eopenurl2622007\u003c/string\u003e\r\n \u003c/array\u003e\r\n \u003c/dict\u003e\r\n \u003c/array\u003e\r\n ...\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 7 of 14\n\n\u003ckey\u003eLSMinimumSystemVersion\u003c/key\u003e\r\n \u003cstring\u003e10.7\u003c/string\u003e\r\n ...\r\n \u003ckey\u003eNSUIElement\u003c/key\u003e\r\n \u003cstring\u003e1\u003c/string\u003e\r\n\u003c/dict\u003e\r\n\u003c/plist\u003e\r\nOther interesting keys include LSMinimumSystemVersion which indicates the (malicious) application is\r\ncompatible with OSX 10.7 (Lion), and NSUIElement key which tells the OS to execute the application without a\r\ndock icon nor menu (i.e. hidden).\r\nHowever the most interesting key is the CFBundleURLSchemes (within the CFBundleURLTypes ). This key holds an\r\narray of custom URL schemes that the application implements (here: openurl2622007 ). In the aforementioned\r\nblog post “Remote Mac Exploitation Via Custom URL Schemes”, we described how WindShift (ab)used custom\r\nURL schemes to infect macOS systems…in exactly this manner! Yet another data point tying our samples to\r\nWindShift.\r\nThe OSX.WindTail.A sample described by Karim used a similarly named custom URL scheme:\r\nopenurl2622015\r\nOk, let’s dive in to look at some disassembly!\r\nLoading the main binary usrnode into a disassembler (I used Hopper), we start at the main() function:\r\nint main(int arg0, int arg1, int arg2, int arg3, int arg4, int arg5) {\r\n \r\n r12 = [NSURL fileURLWithPath:[[NSBundle mainBundle] bundlePath]];\r\n rbx = LSSharedFileListCreate(0x0, _kLSSharedFileListSessionLoginItems, 0x0);\r\n \r\n LSSharedFileListInsertItemURL(rbx, _kLSSharedFileListItemLast, 0x0, 0x0, r12, 0x0, 0x0);\r\n ...\r\n rax = NSApplicationMain(r15, r14);\r\n return rax;\r\n}\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 8 of 14\n\nThe LSSharedFileListInsertItemURL API is documented by Apple. Just kidding: “No overview available”:\r\nSo what does the LSSharedFileListInsertItemURL API do? It adds a login item, which is mechanism to gain\r\npersistence and ensure that the (malicious) application will be automatically (re)started everytime the user logs in.\r\nThis is visible via System Preferences application:\r\n…not the stealthiest persistence mechanism, but meh, gets the job done!\r\nThe main() function invokes the NSApplicationMain method, which in turn invokes the\r\napplicationDidFinishLaunching method:\r\n-(void)applicationDidFinishLaunching:(void *)arg2 {\r\n r15 = self;\r\n r14 = [[NSDate alloc] init];\r\n rbx = [[NSDateFormatter alloc] init];\r\n [rbx setDateFormat:@\"dd-MM-YYYYHH:mm:ss\"];\r\n r14 = [[[[rbx stringFromDate:r14] componentsSeparatedByCharactersInSet:\r\n [NSCharacterSet characterSetWithCharactersInString:cfstring____]]\r\n componentsJoinedByString:@\"\"] stringByReplacingOccurrencesOfString:@\" \" withString:@\"\"];\r\n rcx = [[NSBundle mainBundle] resourcePath];\r\n rbx = [NSString stringWithFormat:@\"%@/date.txt\", rcx];\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 9 of 14\n\nrax = [NSFileManager defaultManager];\r\n rdx = rbx;\r\n if ([rax fileExistsAtPath:rdx] == 0x0) {\r\n rax = arc4random();\r\n rax = [NSString stringWithFormat:@\"%@%@\", r14,\r\n [[NSNumber numberWithInt:rax - (rax * 0x51eb851f \u003e\u003e 0x25) * 0x64,\r\n (rax * 0x51eb851f \u003e\u003e 0x25) * 0x64] stringValue]];\r\n rcx = 0x1;\r\n r8 = 0x4;\r\n rdx = rbx;\r\n rax = [rax writeToFile:rdx atomically:rcx encoding:r8 error:\u0026var_28];\r\n if (rax == 0x0) {\r\n r8 = 0x4;\r\n rax = [NSUserDefaults standardUserDefaults];\r\n rcx = @\"GenrateDeviceName\";\r\n rdx = 0x1;\r\n [rax setBool:rdx forKey:rcx, r8];\r\n [[NSUserDefaults standardUserDefaults] synchronize];\r\n }\r\n }\r\n [r15 read];\r\n [r15 tuffel];\r\n [NSThread detachNewThreadSelector:@selector(mydel) toTarget:r15 withObject:0x0];\r\n return;\r\n}\r\nPulling apart the above code, we can see: 1. The (malicious) application generates the current date/time, and\r\nformats it. 2. Builds a path to date.txt in it’s application bundle ( Contents/Resources/date.txt ) 3. If this file\r\ndoesn’t exist, write out the (formatted) date and a random number 4. If this fails, set the GenrateDeviceName (sic)\r\nuser default key to true 5. Read in the data from the date.txt file 6. invoke the tuffel method 7. Spawn a\r\nthread to execute the mydel method\r\nClearly steps 1-5 are executed to generate, then load, a unique identifier for the implant.\r\nLet’s observe this happening (via the fs_usage utility):\r\n# fs_usage -w -filesystem | grep date.txt\r\n00:38:09.784384 lstat64 /Users/user/Desktop/Final_Presentation.app/Contents/Resources/date.txt usrn\r\n00:38:09.785711 open F=3 (R_____) /Users/user/Desktop/Final_Presentation.app/Contents/Re\r\n...\r\n# cat ~/Desktop/Final_Presentation.app/Contents/Resources/date.txt\r\n2012201800380925\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 10 of 14\n\nThe tuffel method is rather involved (and we’ll expand upon in an update to this blog post). However, some of\r\nit’s main actions include:\r\n1. Moving the (malicious) application into the /Users/user/Library/ directory\r\n2. Executing this persisted copy, via the open command\r\n3. Decrypting embedded strings that relate to file extensions of (likely) interest\r\nWe can observe step #2 (execution of the persisted copy) via my open-source process monitor library, ProcInfo:\r\nprocInfo[915:9229] process start:\r\npid: 917\r\npath: /usr/bin/open\r\nuser: 501\r\nargs: (\r\n open,\r\n \"-a\",\r\n \"/Users/user/Library/Final_Presentation.app\"\r\n)\r\nStep #3, (string decryption) is interesting as it both reveals the capabilities of the malware as well as (again) helps\r\nidentify the (malicious) application as OSX.WindTail . The yoop method appears to be the string decryption\r\nroutine:\r\n-(void *)yoop:(void *)arg2 {\r\n rax = [[[NSString alloc] initWithData:[[yu decode:arg2] AESDecryptWithPassphrase:cfstring__] encoding:0x1] s\r\n return rax;\r\n}\r\nSpecifically it invokes a decode and AESDecryptWithPassphrase helper methods. Looking closer at the call to\r\nthe AESDecryptWithPassphrase method, we can see it’s invoked with a variable named cfstring__ (at address\r\n0x100013480 ). This is the (hard-coded) AES decryption key:\r\ncfstring___100013480:\r\n 0x000000010001c1a8, 0x00000000000007d0,\r\n 0x000000010000bc2a, 0x0000000000000010 ; u\"æ$\u0026łŁńŚŽ~Ę?|!~\u003cŒ\",\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 11 of 14\n\nInterestingly this is the exact same key as Karin showed in his slides, for OSX.WindTail.A:\r\nTo see what the (malicious) application is decrypting, we can simply set a breakpoint within the yoop method,\r\nand then dump the (now) decrypted strings:\r\n(lldb) b 0x000000010000229b\r\nBreakpoint 8: where = usrnode`___lldb_unnamed_symbol6$$usrnode + 92, address = 0x000000010000229b\r\n(lldb) po $rax\r\nhttp://flux2key.com/liaROelcOeVvfjN/fsfSQNrIyxeRvXH.php?very=%@\u0026xnvk=%@\r\nIt’s rather easy to break ‘AES’ when you have the key 🤣\r\nOther strings that are decrypted (as noted) relate to file extensions of (likely) interest such as doc , pdf , db ,\r\netc. Makes sense that a cyber-espionage implant would be interested in such things, ya?\r\nMoving on the myDel method appears to attempt to connect to the malware’s C\u0026C servers. Of course these are\r\nencrypted, but again, by dynamically debugging the malware, we can can simply wait until it invokes the AES\r\ndecryption routine, then dump the (now) plaintext strings:\r\n(lldb) x/s 0x0000000100350a40\r\n0x100350a40: \"string2me.com/qgHUDRZiYhOqQiN/kESklNvxsNZQcPl.php\r\n...\r\n(lldb) x/s 0x0000000100352fe0\r\n0x100352fe0: \"http://flux2key.com/liaROelcOeVvfjN/fsfSQNrIyxeRvXH.php?very=%@\u0026xnvk=%@\r\nThe C\u0026C domains ( string2me.com and flux2key.com ) are both WindShift domains, as noted by Karim in an\r\ninterview with itWire\r\n“the domains string2me.com and flux2key.com identified as associated with these attacks”\r\nThese domains are currently offline:\r\n$ ping flux2key.com\r\nping: cannot resolve flux2key.com: Unknown host\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 12 of 14\n\n$ nslookup flux2key.com\r\nServer: 8.8.8.8\r\nAddress: 8.8.8.8#53\r\n** server can't find flux2key.com: SERVFAIL\r\n…thus the malware appears to remain rather inactive. That is to say, (in a debugger), it doesn’t do much - as it’s\r\nlikely awaiting commands from the (offline) C\u0026C servers.\r\nHowever, a brief (static) triage of other methods found within the (malicious) application indicate it likely\r\nsupports ‘standard’ backdoor capabilities such as file exfiltration and the (remote) execution of arbitrary\r\ncommands. I’ll keep digging and update this post with any new findings!\r\nConclusion\r\nWindShift is an intriguing APT, selectively targeting individuals in the Middle East. Its macOS capabilities are\r\nrather unique and make for a rather interesting case study!\r\nToday, for the first time, we publicly shared samples of a malicious application that I’m highly confident is\r\nOSX.WindTail.A (or is some variant thereof). This claim is based upon naming-schemes, unique infection\r\nmechanism, shared AES-decryption key, and some off-the-record insight.\r\nIn this blog post, we analyzed the OSX.WindTail to reveal its:\r\ninitial infection vector\r\nmethod of persistence\r\ncapabilities\r\ncommmand \u0026 control servers\r\nAll that’s left is to talk about detection an removal.\r\nFirst, good news, Objective-See’s tools such as BlockBlock and KnockKnock are able to both detect and block\r\nthis malware with no a priori knowledge 🔥\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 13 of 14\n\n…since current anti-virus engines (at least those found on VirusTotal) currently do not detect these threats, it’s\r\nprobably best to stick to tools (such as BlockBlock and KnockKnock) that can heuristically detect malware.\r\nThough a tool such as KnockKnock is the suggested way to detect an infection, you can also manually check if\r\nyou’re infected. Check for a suspicious Login Item via the System Preferences application, and/or for the\r\npresence of suspicious application in your ~/Library/ folder (likely with a Microsoft Office icon, and perhaps\r\nan invalid code signature). Deleting any such applications and Login Item will remove the malware.\r\nHowever if you were infected (which is very unlikely, unless you’re a government official in a specific Middle\r\nEastern country), it’s best to fully wipe your system and re-install macOS!\r\nLove these blog posts \u0026 tools? You can support them via my Patreon page!\r\nSource: https://objective-see.com/blog/blog_0x3B.html\r\nhttps://objective-see.com/blog/blog_0x3B.html\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://objective-see.com/blog/blog_0x3B.html"
	],
	"report_names": [
		"blog_0x3B.html"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "6bd4ed50-e116-494c-bb70-9587876663f1",
			"created_at": "2023-01-06T13:46:39.004062Z",
			"updated_at": "2026-04-10T02:00:03.178044Z",
			"deleted_at": null,
			"main_name": "WindShift",
			"aliases": [
				"Windy Phoenix"
			],
			"source_name": "MISPGALAXY:WindShift",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "68f12936-2361-4720-87e1-b79a4fdbf1a0",
			"created_at": "2022-10-25T16:07:24.409855Z",
			"updated_at": "2026-04-10T02:00:04.978227Z",
			"deleted_at": null,
			"main_name": "WindShift",
			"aliases": [
				"G0112",
				"Windy Phoenix"
			],
			"source_name": "ETDA:WindShift",
			"tools": [
				"WindTail"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "ada9e5d3-1cb2-4b70-a3c8-96808c304ac8",
			"created_at": "2022-10-25T15:50:23.6515Z",
			"updated_at": "2026-04-10T02:00:05.352078Z",
			"deleted_at": null,
			"main_name": "Windshift",
			"aliases": [
				"Windshift",
				"Bahamut"
			],
			"source_name": "MITRE:Windshift",
			"tools": [
				"WindTail"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434163,
	"ts_updated_at": 1775826762,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/32054571e93dbab573614595ed27bc301bef9df5.pdf",
		"text": "https://archive.orkl.eu/32054571e93dbab573614595ed27bc301bef9df5.txt",
		"img": "https://archive.orkl.eu/32054571e93dbab573614595ed27bc301bef9df5.jpg"
	}
}