{
	"id": "60a56d99-9e5f-44ad-a250-9795acefc81c",
	"created_at": "2026-04-06T00:17:03.746694Z",
	"updated_at": "2026-04-10T13:12:53.763907Z",
	"deleted_at": null,
	"sha1_hash": "558a064c9712fb39086440992b8aa804e96be55c",
	"title": "Analysing A Sample Of Arechclient2",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1710856,
	"plain_text": "Analysing A Sample Of Arechclient2\r\nPublished: 2023-02-05 · Archived: 2026-04-05 13:10:27 UTC\r\nIn this post, I will be going over my process of analyzing a sample of ArechClient2. Including initial analysis,\r\ndeobfuscation and unpacking of the loader. Followed by the analysis of the .NET payload revealing its config and\r\nC2 information.\r\nIt began with this tweet by @Gi7w0rm. They mentioned me and a few others asking for help analyzing this\r\nsample. I decided to look into the sample. After publishing some threat intel and a few updates on my re progress\r\non Twitter, I decided to write this report for a more detailed documentation of my analysis. The original sample\r\ncan be found here.\r\nInitial Analysis\r\nThe sample consists of two files, an executable and an a3x file. After some quick research, I found that a3x is a\r\n“compiled” form of AutoIt script. The executables icon is the logo of AutoIt and the copyright information says\r\nit’s AutoIt. This leads me to believe that this executable is the runtime required to execute the a3x file.\r\nI ran the file in a Windows Sandbox, for some quick intel and immediately got a Windows Defender hit for\r\nMSIL:Trojan... which indicates that this AutoIt part is just a loader for a second stage .NET binary. In case you\r\nare not familiar with the terms, “MSIL” stands for Microsoft Intermediate Language, which is the bytecode that\r\n.NET binaries are compiled to.\r\nThe a3x script is human-readable. So after putting it into Visual Studio Code I saw this.\r\nIt looks pretty messy at first but taking a closer look I found something that stuck out: The calls to the function\r\ncalled DoctrineDrama look suspiciously like string decryption. So my next step was to find that function, I used\r\nthe search function to look for it’s name until I found the actual implementation. All functions start with the\r\nkeyword Func and end with the keyword EndFunc , making it easy for us to identify them. I copied the code of\r\nthe DoctrineDrama function to a separate file. The code is obfuscated and seems to contain quite some junk code.\r\nMy first step was to indent the code, for easier readability.\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 1 of 11\n\nLooking at the code, specifically the switch cases inside the loops, I realized that only the branches that use\r\nExitLoop are of importance. Taking a look at the switch conditions confirmed that suspicion. At the beginning of\r\nthe function, the second variable is the loop condition, it’s initialized with a value of 921021 . Looking at the\r\nswitch, it matches the case that exits the loop, meaning the other cases are dead code and can be ignored. I\r\nremoved the dead branches, cleaned up the unnecessary loops and got rid of the unused variables:\r\nAfter cleaning up we are left with this code. Reading this we can deduce some more fitting variable names, the\r\nfirst argument seems to be the encrypted input, and the second argument is the key. The first variable is the\r\nresulting string. So to understand the rest of the code I looked at the documentation of AutoIt, the StringSplit\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 2 of 11\n\nfunction, takes the following arguments: A string, a delimiter char and an optional argument for the delimiter\r\nsearch mode. So the second local variable in DoctrineDrama is an array of strings split from the input. Next, the\r\ncode iterates through all the elements of that array and appends a new character to the output string with every\r\niteration. We see a call to a function called Chr , which according to documentation converts a numeric between\r\n0-255 value to an ASCII character. But something is off, what is going on inside that call to Chr ? subtraction on\r\na string, how does that work? I wondered about that but after a quick web search, I found out that in AutoIt digit\r\nonly strings seem to be auto-converted to a number if you perform any arithmetic operation on them. Once the\r\nloop is finished, the output string is returned.\r\nLooking at this fully cleaned-up version, I reimplemented the decryption routine in C# to build a simple\r\ndeobfuscator.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\nstatic string Decrypt(string input, int key)\r\n{\r\n var buffer = input.Split('h');\r\n var builder = new StringBuilder();\r\n for (int i = 0; i \u003c buffer.Length; i++)\r\n {\r\n builder.Append((char)(Convert.ToInt32(buffer[i]) - key));\r\n }\r\n return builder.ToString();\r\n}\r\nThe deobfuscator uses a simple regex pattern to match every call to DoctrineDrama and replace it with the\r\ndecrypted string. It also outputs a list of all decrypted strings. The full deobfuscator code can be found here.\r\nDumping the payload\r\nAfter deobfuscating all the strings, I searched the string dump for some Windows API function names that I would\r\nexpect from a loader. I found a few hits on NtResumeThread , CreateProcessW and NtUnmapViewOfSection .\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 3 of 11\n\nThese three in combination give a huge hint towards process hollowing. After searching the string dump for\r\n.exe I found the suspected injection target \\Microsoft.NET\\Framework\\v4.0.30319\\jsc.exe , a utility of .NET\r\nFramework 4.x which comes with every standard Windows 10 install.\r\nMy next step was to debug the executable using x64Dbg. I set a breakpoint on CreateProcessW , to ensure we\r\nbreak before the injection process is started. After running past the entry point I was greeted with this nice little\r\nmessage.\r\nThe message box claims I violated a EULA which I never read nor agreed to. I guess we can’t debug the malware\r\nany further how unfortunate. Luckily for us, x64Dbg has a built-in AutoIt EULA bypass, it’s called Hide\r\nDebugger (PEB). You can find it under Debug\u003eAdvanded\u003eHide Debugger (PEB). Make sure to run x64Dbg in\r\nelevated mode.\r\nAfter dealing with the rather simple anti-debug, we let it run. When debugged, the executable spawns a file dialog\r\nasking for an a3x file, when run without a debugger it automatically finds the script file. After pointing it to the\r\nscript file we let it run until the breakpoint for CreateProcessW is hit. At this point, jsc.exe will be started in\r\nsuspended mode. Checking Process Explorer confirms that the decrypted path from the AutoIt script was indeed\r\nthe injection target. We add another breakpoint on NtResumeThread which will break execution after the injection\r\nis finished but before the thread is resumed to execute the malware.\r\nSince we already know the malware is .NET-based I will use ExtremeDumper to get the managed payload from\r\nthe jsc.exe process. Run ExtremeDumper as admin and dump jsc.exe , if it does not show up make sure you\r\nare using the x86 version of ExtremeDumper. At the time of writing the loader does not run anymore but fails with\r\nan error message about Windows updates. Sifting through the string dump I suspect there is some sort of date\r\ncheck that prevents further execution. This was likely implemented to prevent future analysis. Luckily I had\r\ndumped the actual payload before.\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 4 of 11\n\nThe .NET Payload\r\nAfter dumping the loader, I had to deal with the managed payload. The image is heavily obfuscated. I started my\r\nhunt in the \u003cModule\u003e class also referred to as the global type. I start by checking this class since its constructor is\r\ncalled before the managed entry point. Many obfuscators call their runtime protections or functions like string\r\ndecryption here.\r\nMy guess was correct, I found a string decryption method c in \u003cModule\u003e (token 0x06000003 ). The method\r\nreads the encrypted string data from an embedded resource and then performs a single XOR operation decryption\r\non it. The key used for decryption is supplied via parameters, which leads me to believe that each string has a\r\nunique decryption key.\r\nAfter checking references to c it turned out that the decryption relies on flow-dependent variables. The calls to\r\nthe decryption routine have encrypted arguments that are using several opaque predicates and global variables that\r\nare initialized and changed depending on call flow.\r\nThis means we would have to emulate or solve all calculations required to obtain the local variables and global\r\nfields that are used by the expressions that decrypt the arguments of the call to our decryption method c . The\r\nadditional dependency on call flow further increases the effort required since we would need to solve all\r\ncalculations in every method in the correct order. Considering all this I ditched the idea of writing a static string\r\ndecryption tool.\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 5 of 11\n\nSifting through the binary I found quite a few similarities to Redline, both making use of DataContracts and async\r\ntasks for the separate stealer modules.\r\nOne class in particular seemed interesting. After looking for networking related functions I found a class cj\r\ntoken 0x0200010C that connects to a server via .NET’s TcpClient . Looking at the code we can spot the use of\r\nanother class called xj which seems to contain the IP and port number for the TCP connection. See line 155\r\ntcpClient.Connect(xj.c, Convert.ToInt32(xj.a.d)\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 6 of 11\n\nApart from that xj also seems to contain a URL that the malware accesses and downloads a string from, see line\r\n168. Let’s take a closer look at xj token 0x02000107 . It contains quite a few properties but the most interesting\r\nis the constructor.\r\nThis looks like a potential config class. It initializes the properties used for the initial TCP connection and the\r\nstring download we saw in cj , which is a good indicator that we are indeed looking at the malwares config. I\r\nplaced a breakpoint at the end of the constructor. Since the string decryption method was still an issue the easiest\r\nway to get the strings was to run the binary and have it decrypt the strings for me. I debugged the executable using\r\ndnSpy until I hit the breakpoint at the end of the constructor. After the breakpoint hit we can view all the\r\nproperties and fields values in the Locals window by expanding the this parameter.\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 7 of 11\n\nHere we see the C2 IP 77.73.133.83 and port 15647 . We can also see a Pastebin link, that caught my interest:\r\nThe paste contains another IP 34.107.35.186 , potentially a fallback C2.\r\nBefore debugging, I modified the string decryption method by adding a few lines to write every decrypted string\r\nto disk. This modification makes it so that instead of immediately returning the string it’s first passed to\r\nAppendAllText and written to a file of our choice.\r\nThe dump revealed the same values that we found in the Locals window and a few more strings of interest. For\r\nexample, we got a list of the paths that the stealer checks for potential credentials. The main targets of this stealer\r\nseem to be browsers, mail clients and game clients like Steam. This is similar to most mainstream stealers. You\r\ncan view the full-string dump here.\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 8 of 11\n\nSpeaking of strings, I noticed another similarity to Redline, the use of char array to string conversion at runtime.\r\nAlthough Redline in many cases does insert some additional junk into these arrays that is removed from the\r\nconstructed string, using the Replace or Remove method.\r\nDue to the heavy obfuscation and the rather similar behavior to existing stealers, I decided to not investigate this\r\npayload further. We revealed the most important IOCs and got a pretty good understanding of the stealer’s targets.\r\nSummary\r\nWe found that the initial loader was implemented in AutoIt and uses ProcessHollowing to load a .NET-based\r\npayload, we reconstructed the string decryption method enabling us to partially deobfuscate the loader. We\r\ndumped the managed payload using a debugger and ExtremeDumper. We analyzed and debugged the managed\r\npayload to reveal the payload config, containing the C2 information.\r\nAfter analyzing the string dump, I found some indicators that could help with attribution to a certain malware\r\nfamily. Although this sample does look very similar to Redline stealer, it is actually not part of that family. I found\r\nthis blob of data that looked suspiciously like C2 communication:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n{\"Type\":\"ConnectionType\",\"ConnectionType\":\"Client\",\"SessionID\":\"\r\n\",\"BotName\":\"\r\n\",\"BuildID\":\"\r\n\",\"BotOS\":\r\n\"Caption\",\"URLData\":\"\r\n\",\"UIP\":\"\r\n\"}\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 9 of 11\n\nReferencing the above data and the port number to other writeups, like this one from IronNet Threat Research,\r\nrevealed similarities to a different malware family. The screenshot below shows a network capture of an active\r\nArechClient2 sample performed by the researchers from IronNet. Comparing this data we can conclude that our\r\nsample is also part of the ArechClient2 family.\r\nimage source\r\nWith this we have reached the end of our analysis. Below, I have arranged all important IOCs, for the threat intel\r\nfocused readers. I write these reports in my freetime and publish them for free, if you want to support my work\r\nfeel free to sponsor me on GitHub.\r\nIOCs\r\nDescription Indicator\r\nC2 77.73.133.83:15647\r\nPotential Fallback C2 34.107.35.186:15647\r\nURL for fallback C2 https://pastebin.com/raw/NdY0fAXm\r\n.NET payload\r\nTest.exe\r\nSHA256:\r\na835602db71a42876d0a88cc452cb60001de4875a5e91316da9a74363f481910\r\nAutoIt loader 45.exe\r\nSHA256:\r\n237d1bca6e056df5bb16a1216a434634109478f882d3b1d58344c801d184f95d\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 10 of 11\n\nDescription Indicator\r\nAutoIt script S.a3x\r\nSHA256:\r\n8e289b8dfc7e4994d808ef79a88adb513365177604fe587f6efa812f284e21a3\r\nSource: https://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nhttps://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://dr4k0nia.github.io/posts/Analysing-a-sample-of-ArechClient2/"
	],
	"report_names": [
		"Analysing-a-sample-of-ArechClient2"
	],
	"threat_actors": [],
	"ts_created_at": 1775434623,
	"ts_updated_at": 1775826773,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/558a064c9712fb39086440992b8aa804e96be55c.pdf",
		"text": "https://archive.orkl.eu/558a064c9712fb39086440992b8aa804e96be55c.txt",
		"img": "https://archive.orkl.eu/558a064c9712fb39086440992b8aa804e96be55c.jpg"
	}
}