{ "id": "2460df44-e1f4-44bd-9d1c-e7776daa60e6", "created_at": "2026-04-06T00:16:50.194244Z", "updated_at": "2026-04-10T03:24:29.856339Z", "deleted_at": null, "sha1_hash": "fb1c2c3a6862810a3ba878095c13e10883971e3a", "title": "Xloader deep dive: Link-based malware delivery via SharePoint impersonation", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 10427662, "plain_text": "Xloader deep dive: Link-based malware delivery via SharePoint\r\nimpersonation\r\nBy Sublime Threat Intelligence \u0026 Research,\r\nPublished: 2025-10-22 · Archived: 2026-04-05 21:30:10 UTC\r\nSublime recently prevented a malicious SharePoint impersonation attempting to deliver malware via a link in the\r\nmessage.\r\nOur analysis led us through a complex chain of obfuscation, zip files, AutoIT, shellcode, and multiple rounds of\r\nprocess injection. We believe with high confidence that the final deployed payload is Xloader (Formbook), an\r\ninformation stealer that primarily harvests user credentials, keystrokes and screenshots, and with moderate\r\nconfidence that the initial loading component is related to Trickgate.\r\nIn this post, we’ll walk through the details of our analysis starting with the detection of the SharePoint\r\nimpersonation.\r\nThe message\r\nThis attack starts with the target receiving a message that looks like a legitimate SharePoint share with an Open\r\nfiles link, including the standard “share” logo and the Microsoft brand logo.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 1 of 16\n\nThis message was caught by Sublime after triggering multiple Detection Rules and earning an Attack Score\r\nVerdict of malicious .\r\nThe Open files button led to a .zip file hosted on a non-SharePoint URL. Within a safe environment, we\r\ndownloaded and extracted its contents for further analysis: document.exe .\r\nTo obtain more information on the file, we used Detect It Easy to provide an initial overview and determine how\r\nto proceed with analysis. Detect It Easy was able to recognize the file as AutoIT , which is a scripting language\r\nthat allows for automation of windows tasks and systems management. AutoIT has many legitimate purposes, but\r\nit is often utilized by malicious actors due to its relative simplicity, flexibility, and ability to be turned into\r\nexecutable files.\r\nStandard analysis tools don’t handle AutoIT well, so we grabbed an AutoIT decompiler from GitHub and\r\ndeployed it to our analysis machine. When we decompiled document.exe , we got the original AutoIT script used\r\nto create the binary file. \r\nThe script begins with a large blob of obfuscated text stored in a single parameter.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 2 of 16\n\nAfter the large blob of text is assigned to the $vwcpaypcs variable, the script contains logic to decode the blob as\r\nwell as other smaller obfuscated pieces.  Each piece of obfuscated text contains the string \"eocs29\" repeated\r\nmultiple times for each string. \r\nAfter removing the eocs29 string with find/replace, we determined that the code was a loader for the initial blob\r\nof text. Based on the presence of VirtualProtect and DllCallAddress , we made the safe assumption that it\r\nwas executable code, likely in the form of shellcode.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 3 of 16\n\nClose inspection of the code also revealed that the decoded content executes from an offset of 0x23b0 . This will\r\nbecome more important later when we execute and analyze the code.\r\nNext, we used CyberChef to extract the encoded text and remove any references to eocs29 . This resulted in a\r\nlarge blob of hex characters with initial bytes resembling valid x86 instructions.\r\nWe ran a Disassemble x86 operation to confirm that the hex characters were valid x86 instructions.\r\nWe then saved the resulting data and tried to execute it using the Speakeasy emulator by Mandiant. Speakeasy\r\nconfirmed that the code would execute, but it terminated immediately after calling GetTickCount and Sleep .\r\nThis is a common anti-analysis trick used by malware to defeat emulators and sandboxes.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 4 of 16\n\nAnalysis with Ghidra\r\nSo far, we had identified that document.exe contained a malicious AutoIT script that featured shellcode for\r\nfurther execution. Initial attempts to execute the shellcode inside a sandbox had failed, so we then moved the data\r\ninto Ghidra in order to work out what it was doing and which malware family it might belong to. \r\nStarting at the execution offset of 0x23b0 , we noticed that the code contained numerous stack strings and quickly\r\nredirected the shellcode to an offset of 0 (indicated by FUN_00000000 ).\r\nWe decoded the initial stack string and obtained a character sequence followed by \"lecheries\".\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 5 of 16\n\nFollowing the redirection ( FUN_00000000 ) to the beginning of the shellcode, we saw additional stack strings and\r\nreferences to possible API hashes (a method of locating necessary windows APIs without referencing them\r\ndirectly by name).\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 6 of 16\n\nAPI hashes can be resolved manually, but this is often a significant effort, and largely unnecessary if the same\r\nhashing logic is already documented. Leveraging OSINT sources, we confirmed that these hash values matched\r\nwith a shellcode-based loader (potentially TrickGate).\r\nThe first hash value from our shellcode corresponds to the CRC32 hash of CreateProcessW . This meant that we\r\ncould use the documented values to label our code, and revealed that the hashing is extremely likely to be CRC32.\r\nWe were also able to locate the hashing algorithm within the shellcode, with constant values confirming the\r\nCRC32 usage.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 7 of 16\n\nThe usage of CRC32 alone was not enough to confirm that our malware was the same TrickGate, but the fact that\r\nthese hashes were seen on another shellcode-based file added to the theory that we were looking at a similar\r\nloader or an updated variant. In addition to this, TrickGate has been known to utilize AutoIT and deliver the same\r\npayload (more later in the post).\r\nDebugging\r\nThe process of static reverse engineering with Ghidra is valuable but time consuming, and at this point, not\r\ncompletely necessary since our primary goal was to identify the malware. Our previous analysis suggested that the\r\nshellcode may be a loader designed to deliver the payload onto the system. \r\nIn order to save time and prevent unnecessary analysis, we decided to debug the code and look for any additional\r\nclues as to what we were dealing with. We could always jump back into static analysis if debugging failed. \r\nWe began the dynamic process by loading the extracted shellcode into x32dbg using BlobRunner by OALabs.\r\nThis enabled us to easily view remaining stack strings, which largely contained DLL names later used for\r\nresolving APIs.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 8 of 16\n\nAdditional analysis allowed us to deploy breakpoints at the location of API hashing. This meant that we could\r\napply a logging condition and simply print the resolved hashes to the log window. This is often far easier than\r\nfully reversing the hashes. \r\nHere we have a simple conditional breakpoint that allowed us to monitor all APIs resolved via hashing.\r\nThis revealed many of the APIs that the shellcode was resolving. Of particular interest was the presence of\r\nCreateProcessW , VirtualAlloc and ReadProcessMemory , as well as GetThreadContext and\r\nSetThreadContext . These APIs are commonly associated with process injection and further suggested we were\r\ndealing with a loader and not a final payload. \r\nBelow is a short list of APIs that the shellcode was resolving via hashing. Note the usage of many common\r\ninjection APIs.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 9 of 16\n\nAllowing the code to execute further, we saw attempts to access a \"lecheries\" file located in the users temp\r\ndirectory. This isn’t particularly interesting, but provided a unique string that we could later search to identify the\r\nmalware.\r\nWe also observed attempts to spawn an svchost.exe process via CreateProcessW . Given the presence of\r\ninjection APIs, this is likely the injection target and where we’ll find the next stage of malware. \r\nWe also observed the shellcode attempting to load a second copy of ntdll.dll . This is often performed by\r\nmalware in order to obtain a \"clean\" version for execution and is commonly used to evade detection with variants\r\nof syscalls or DLL unhooking.\r\nContinuing the execution, we observed and investigated the newly spawned svchost , and confirmed a second\r\ncopy of ntdll present in the module listing. There are few legitimate reasons for two ntdll modules to be\r\nloaded, so we knew something strange was going on inside of this svchost .\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 10 of 16\n\nShortly after spawning, the new svchost.exe terminated and spawned a suspicious instance of netsh.exe .\r\nThe netsh was created without any command line parameters, which is unusual and suspicious. So we decided\r\nto investigate the process further.\r\nBy closely inspecting the memory regions of netsh.exe, we noticed a suspicious area of memory with RWX\r\n(read/write/execute) permissions and what appeared to be shellcode.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 11 of 16\n\nDisassembling the region inside of a debugger, we confirmed that the bytes disassembled correctly and followed a\r\nsequence typical of shellcode. Namely, immediately calling a nearby instruction and using a pop to obtain the\r\naddress. \r\nThis typically enables shellcode to determine its position in memory when that position is not predictable. It’s also\r\na sequence that would rarely be seen in legitimate code.\r\nPortions of the code did not execute and raised exceptions, so we decided to perform a more extensive scan of our\r\nanalysis machine using hollows_hunter. Specifically, we wanted to use hollows_hunter to search for indications of\r\nshellcode present in any process that was currently running.\r\nMuch to our surprise, it had flagged explorer.exe as suspicious. This was unusual as there was no obvious new\r\nexecution of explorer.exe .\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 12 of 16\n\nInspecting the explorer.exe process further, we noticed another suspicious area of RWX memory.\r\nLuckily, hollows_hunter had flagged this same section and saved it for analysis.\r\nWe then used Detect It Easy to search for strings in that saved region. We quickly discovered a domain, partial\r\nURL, user agent, and base64 data prepended with the string \"PKT2\". These are all strings that would be expected\r\nin code that is attempting to make an external connection. Since these strings were present in the dump (and\r\nlocated in an RWX section), we suspected that this was linked to our malware.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 13 of 16\n\nSince we were primarily interested in identifying the malware we were dealing with, we investigated the strings\r\nfor any links to documented activity. This led to the strong suggestion that we were dealing with Xloader (aka\r\nFormbook).\r\nC2 communication strings\r\nWhile researching PKT2 malware, we found two blogs specifically detailing Xloader (Zscaler and Baglai Vlad).\r\nThe Zscaler blog calls out Xloader registration packets using base64 appended to the string \"PKT2\", which\r\naligned with the string seen in our extracted data.\r\nWe also saw similarities documented in the Baglai Vlad blog.\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 14 of 16\n\nDouble references to ntdll.dll\r\nThe Baglai Vlad blog also calls out Xloader as utilizing a second copy of ntdll.dll for resolving hashes and\r\nevading detection. This aligned with our observation of the second loading of ntdll.dll inside of our svchost\r\nprocess, as there are few legitimate reasons for two copies to be loaded.\r\nProcess injection \r\nThe Baglai Vlad blog also called out Xloader as utilizing process injection specifically into explorer.exe , after\r\nfirst injecting into another process. This aligned with our observation of injection into svchost.exe, followed by\r\nnetsh.exe and activity inside of explorer.exe .\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 15 of 16\n\nDue to these and other similarities covered within the blogs, we were fairly confident that we were looking at a\r\nsimilar sample.\r\nFinal thoughts\r\nWe believe with moderate confidence that the initial AutoIT and shellcode components are related to Trickgate.\r\nTrickgate has been documented specifically deploying Xloader (Formbook) and utilizing techniques with high\r\nsimilarity to the initial AutoIT component of our sample. \r\nIf you’re interested in checking out Sublime and how we detect and prevent attempts to deliver malware via email\r\noriginating attacks, you can create a free account today or request a demo.\r\nSource: https://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nhttps://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/\r\nPage 16 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://sublime.security/blog/xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation/" ], "report_names": [ "xloader-deep-dive-link-based-malware-delivery-via-sharepoint-impersonation" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434610, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/fb1c2c3a6862810a3ba878095c13e10883971e3a.pdf", "text": "https://archive.orkl.eu/fb1c2c3a6862810a3ba878095c13e10883971e3a.txt", "img": "https://archive.orkl.eu/fb1c2c3a6862810a3ba878095c13e10883971e3a.jpg" } }