{
	"id": "182d4b11-5f18-4493-9268-76b4f271bf9b",
	"created_at": "2026-04-06T01:30:38.249615Z",
	"updated_at": "2026-04-10T03:21:19.953809Z",
	"deleted_at": null,
	"sha1_hash": "c5e8824a5c21ad3c073a398e009e467b5804134f",
	"title": "Remcos RAT - Malware Analysis Lab",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 10460390,
	"plain_text": "Remcos RAT - Malware Analysis Lab\r\nPublished: 2023-05-21 · Archived: 2026-04-06 00:59:09 UTC\r\nOverview\r\nPart 1: Preliminary Static Analysis of Starting Binary\r\nTaking a malicious executable which has been categorised as a trojan with the name ‘MSIL/AgentTesla’ and\r\n‘TR/AD.Remcos’ on VirusTotal, we can explore it further.\r\nSource: MalwareBazaar\r\nSource: VirusTotal.com\r\nFirst off obtain the sample with a particular SHA256 hash:\r\nStarting IOC (SHA256): 7a1bb4fe0f62425fdd2e163ea17d84465323c4f2df8aabb8a50b1433e7d42a9f\r\nAnalysis in pestudio reveals this is a .NET, 32-bit executable with timestomped Debugger and Compiler\r\ntimestamps. It also had an original name during development of ‘tocehi.exe’; however, this may also have been\r\ntampered with.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 1 of 44\n\nExamining the resources section there is a resource with exceptionally large entropy which indicates it likely\r\ncontains compressed or encrypted data. There’s also a repeating theme of bytes spelling out ‘PAD’ which may\r\nindicate junk data has been added as padding to the binary to make it more challenging to analyse.\r\nExamining the imports shows this is likely dynamically invoking and loading assembly into memory in addition\r\nto possibly performing string reversal operations.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 2 of 44\n\nPart 2: Decompiling Binary\r\nOpening in dnSpyEx, by right clicking the executable and using ‘Go to Entry Point’ this takes us to the start of our\r\nbinary where it runs a new instance of Form1.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 3 of 44\n\nExamining this shows what looks to be decoy code and an instance of the form component being initialized. Of\r\ninterest is that this form uses the System.Reflection class which is unusual and signifies reflective loading of code\r\nwill likely occur.\r\nExamining this shows a lot of form initialization which seems innoculous at first; however, at one point it gets a\r\nstring stored within a resource object called “CFD” within the class ‘Form11’, replaces all instances of “$” with\r\n“E”, and reverses it before convering this to base16 (Hex) and loading it in as raw assembly.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 4 of 44\n\nBy copying the resource CFD into CyberChef and performing these operations, it’s revealed this is likely a PE file\r\nbeing loaded into memory.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 5 of 44\n\nSaving this to a file, a new SHA256 hash can be obtained which has been seeen by VirusTotal and is flagged as a\r\n‘spreader’ and ‘injector’.\r\nIOC (SHA256): 280001013946838a651abbdee890fa4a4d49c382b7b5e78b7805caef036304e2\r\nOf interest is that when this instance is created it is passing an object array called ‘ext’ which is defined from\r\nForm1.EXT. This is defined as a string array containing the entries “71474C547242”, “69786F”,\r\n“DoanHQTCSDL” all 3 of which are essential for later analysis.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 6 of 44\n\nPart 3: Examining Embedded 1st Stage Payload (Pend.dll)\r\nOpening up in pestudio shows this had an internal name of ‘Pend.dll’ during development, is likely obfuscated\r\nusing the SmartAssembly .NET obfuscator, and was compiled on May 3rd, 2023 at 04:45:48 UTC which seems\r\nfar more plausible to be legitimate given the time this sample was found in the wild.\r\nUsing de4dot the binary can be deobfuscated automatically.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 7 of 44\n\nLooking at the main method of this binary shows more decoy code and then a call to a method named ‘xp’,\r\npassing in 3 strings string_0, string_1, string_2.\r\nIt should be noted that these 3 strings are the 3 strings seen in our original binary which were passed to this DLL\r\nupon instantiation.\r\nThis method instantiates an instance of what’s returned from the ‘oJ’ method, specifically of type\r\n‘Munoz.Himentater’.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 8 of 44\n\nExamining this reveals an overly large byte array which is being GZip decompressed back into a MemoryStream\r\nto be loaded.\r\nBy changing our decompiler back into Common Intermediate Language language (IL) and examining method ‘oJ’\r\nagain, the full array bytes can be located within a defined structure, and the instructions seem similar to what was\r\nseen before, specifically defining a byte array of size 14340.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 9 of 44\n\nBy copying this array into CyberChef, removing whitespace and line breaks, and converting from hex, it is then\r\nidentified as a Gzip file.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 10 of 44\n\nSaving this and using a tool such as 7-zip allows it to be decompressed, noting that there’s data appended to this\r\nmemory stream.\r\nPart 3: Examining Embedded 2nd Stage Payload (Cruiser.dll)\r\nExamining this new binary in pestudio reveals it is also likely obfuscated using SmartAssembly .NET obfuscator,\r\nand had a name of ‘Cruiser.dll’. It was also likely compiled on Monday April 10th 2023 at 10:01:02 UTC which\r\nseems plausible given it’s before the injector binary was compiled.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 11 of 44\n\nIOC (SHA256): 40C050C20D957D26B932FAF690F9C2933A194AA6607220103EC798F46AC03403\r\nExamining this on VirusTotal it is flagged as a trojan with the name ‘tedy/vsntdh23’.\r\nRepeating the same process with de4dot and decompiling this shows that it has the namespace ‘Munoz’ which\r\ncontains the class ‘Himentater’ amongst others which is specifically what we’re looking for. If we consider the\r\nfirst stage of this malware which ran the method ‘xp’, we can see that it was using the method ‘CasualitySource’,\r\nand is first passing in string_0 (“71474C547242”) before string_1 (“69786F”).\r\nExamining CasualitySource reveals it is a simple string operator which converts hex given to its raw ASCII format\r\nwhich results in the values ‘qGLTrB’ and ‘ixo’.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 12 of 44\n\nPart 3: Examining Embedded Steganography Binary\r\nThe next part of code involves looking at multiple binaries together and gets a bit involved. The chain of events\r\nare as follows:\r\nReturn a bitmap through a method called ‘jR’ via a class called ‘sZ’ from within the namespace ‘TN’ which\r\nis inside of the 1st stage payload. By using the variables string_0 (qGLTrB) and string_2\r\n(DoanHQTCSDL), make up the targeted resource (DoanHQTCSDL.Properties.Resources.qGLTrB) and\r\nstore this into a byte array after subtracting 150 pixels from its height and width.\r\nConvert the returned bitmap into a byte array through a method called ‘sZ’ via a class called ‘sZ’ from\r\nwithin the namespace ‘TN’ which is inside of the 1st stage payload.\r\nPerform operations using the ‘SearchResult’ method from within the 2nd stage payload to convert the byte\r\narray using the term variable string_1 (ixo).\r\nLoad the deobfuscated byte array as an assembly into memory\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 13 of 44\n\nAlthough these operations can be manually reversed, it’s a bit tedious and complicated. Instead we can run the\r\noriginal binary in dnspyEx to get the final product. To do this:\r\nOpen the original executable in dnSpyEx and create a breakpoint on mscorlib.dll within the Sleep function\r\nstatement checking if the AppDomainPauseManager is paused.\r\nRun the binary until the breakpoint is hit and use Step Out (Shift + 11) to land at the start of the\r\ndecompiled 1st stage binary (Pend.dll).\r\nCreate breakpoints at the operations which are retrieving the 3rd stage payload and observe the Local\r\nvariable window to see the modifications occurring.\r\nAt the third breakpoint observe the 3rd stage binary in memory which can now be saved to disk.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 14 of 44\n\nPart 4: Examining 3rd Stage Payload (Discompard.dll)\r\nThis new binary crashes pestudio, and examining it in dnSpyEx shows it is posing as software from the company\r\n‘Citroen’, has the name ‘Plant Scientist’, and is apparently copyrighted to the 2004 Citroen C5…righteo then. The\r\nbinary hasn’t been seen by VirusTotal either; however, we still have luck using de4dot which detects an unknown\r\nobfuscator has been used, cleans it up and gives us something pestudio can analyse.\r\nIOC (SHA256): ACB4301D445B5C125A8CEDD00427D6F89EC89A1F01A9D7D4E7CC183D017F984D\r\nThe binary appears to have had an internal name of ‘Discompard.dll’, and was possibly compiled on May 3rd,\r\n2023 at 06:40:48 UTC almost 2 hours after the 1st stage was compiled.\r\nExamining this in dnSpyEx shows a number of unknown methods and types without any clear entry point.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 15 of 44\n\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 16 of 44\n\nLocating Method To Be Invoked\r\nDespite this we know that the binary was being dynamically loaded into memory through reflection and that it\r\nwas looking for the 20th element in the returned assembly types. Reflectively loading this module into memory\r\nwe can store this in an object and examine it.\r\n$malware=$([System.Reflection.Assembly]::Load(([byte[]]@(Get-Content \"C:\\Users\\Barry\\Downloads\\stage3.dll\" -Enc\r\n$malware.GetMethods()[29]\r\nIn the above we have an issue. Although it looks like a correct method to invoke has been pulled, the method isn’t\r\nmarked static so can’t be invoked like was seen to be occurring when examining the 1st stage malware. Looking at\r\nthe methods available there’s 9 different ones which can be found with the following:\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 17 of 44\n\n$malware.GetMethods() | ? {$_.IsStatic -eq \"True\" -AND $_.IsPublic -eq \"True\"} | Select -exp Name\r\nBased on what was seen in the 1st stage malware, there’s 2 parameters being passed to the invoke method, one of\r\nwhich is the object this is being run on, the other of which are parameters being passed. As the methods are static\r\nthe object field is ignored. The parameters on the other hand are not, so this tells us that no parameters are to be\r\npassed to the method being invoked. By cross-correlating the methods that were seen to be static with those shown\r\nin dnspyEx, it’s seen that there’s only 2 methods this could be ‘T4Z5pBPufA’ or ‘uqH5vT69wm’.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 18 of 44\n\nA glance at ‘T4Z5pBPufA’ shows a single line which sets an integer to 0 and nothing more, whereas\r\n‘uqH5vT69wm’ seems far more promising. In particular ‘uqH5vT69wm’ has a reference to the ApplicationData\r\ndirectory which is suspicious, isn’t called by any other method unlike ‘T4Z5pBPufA’ and to top it all off, it’s\r\nmethod number 29 in the dnSpyEx hierarchy which is the number that was being invoked in the 1st stage payload.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 19 of 44\n\nIt’s currently unclear why the order in dnSpyEx shows correctly, but when dynamically loading into memory\r\nusing PowerShell this order is scrambled and fails. It’s likely due to multiple methods being retrieved from other\r\nDLLs upon reflectively loading, but alas we’re on the right path again.\r\nDebugging The Binary\r\nThe binary itself is highly obfuscated and has a number of string building operations which makes manually\r\nanalysing every component of it tedious; however, the main functions can be seen by stepping through this by\r\ndebugging it in dnSpyEx. Breaking at line 360 of class ‘TVmkvjWsJHbPcmFjgw’ shows the method\r\n‘uqH5vT69wm’ evaluating what looks to be the original binary being run, and a hardcoded executable name in the\r\nRoaming AppData folder which may indicate a copy of the malware is going to be placed there.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 20 of 44\n\nBreaking at line 14 of the class ‘KIpLLvYdUNjv6s5VFsq’ shows the method ‘J4GMnwe6t’ returning\r\ndeobfuscated instructions which confirm this suspicion as shown clearly in variables on the stack. This is also\r\nreflected in the local variables by breaking on the ‘copy’ method inside of the ‘System.IO.File’ class.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 21 of 44\n\nBreaking at line 109 of the class ‘TVmkvjWsJHbPcmFjgw’ shows the method ‘zJ45fVOtms’ setting permissions\r\nand file attributes on the malware which was copied into the AppData folder. Specifically it obtains the user\r\ndetails of who ran the binary and sets it so they only have Read, ReadAndExecute, and ReadData permissions to\r\nthe malware on disk. It also sets the malware to not be indexed by Windows, and sets it to be Hidden and a seen as\r\na critical system, binary to make it even more hidden by default.\r\nAt the end of this method it is seen that the permissions are successfully applied to the malware.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 22 of 44\n\nBreaking at line 13 of the class ‘CRSlWTd5bfbCGtYKOR’ shows the method ‘J4GMnwe6t’ returning a base64\r\nstring. It’s important to note that there’s a large number of classes each with a different method called\r\n‘J4GMnwe6t’ used for deobfuscating strings.\r\nBreaking at line 132 of the class ‘TVmkvjWsJHbPcmFjgw’ shows the method ‘Qle573GMuP’ having base64\r\ndecoded the string in local variables. We can also base64 decode it ourselves in something like CyberChef to show\r\na XML configuration schema for a scheduled task. Of note is that the UserId field is set as [USERID] and isn’t\r\nfilled in.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 23 of 44\n\nBreaking at line 135 of the same class shows the same method having now deobfuscated the user identity to be\r\nused. It also has built a string to a temporary file location.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 24 of 44\n\nStepping through a couple more instructions shows that a file is written to the identified temporary file containing\r\nthe complete scheduled task XML. It should be noted this has a hardcoded IOC of the scheduled task registration\r\ntime being spoofed.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 25 of 44\n\nIOC Scheduled Task Date: 2014-10-25 14:27:44:8929027\r\nStepping over a few more functions shows strings building out the value ‘schtasks.exe’. Breaking at line 145 of\r\nthe class ‘TVmkvjWsJHbPcmFjgw’ shows the method ‘Qle573GMuP’ returning a commandline which will be\r\nused with schtasks.exe to register a scheduled task and establish persistence with the task name\r\n‘Updates\\ALKgmyycVaEjJx’.\r\nBreaking at line 64 of the class ‘iY9VXx99XrYI4WaMs1’ shows the method ‘kHZWDDrKNw’ returning yet\r\nanother binary which is retrieved and deobfuscated from a resouce which can be saved for analysis.\r\nStepping through a little further it appears that this is being injected into a surrogate process in method\r\n‘Er95CrvjJc’ of class ‘TVmkvjWsJHbPcmFjgw’, so we can now move onto stage 4.\r\nPart 5: Examining 4th Stage Payload (Remcos RAT)\r\nThe 4th stage payload is the most promising yet. Examining it in pestudio shows it was likely compiled on\r\nDecember 20th, 2022 at 21:35:57 UTC, is created in a completely different language to the previous injectors (3\r\ninjected DLLs plus the initial injector wrapper), and it is created in C++ as opposed to .NET.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 26 of 44\n\nIOC SHA256: 94a4e5c7a3524175c0306c5748c719a940a7bfbe778c5a16627193a684fa10f0\r\nChecking this binary on VirusTotal it has been categorised as a trojan with the name ‘remcos’ on VirusTotal and\r\nhas a significant detection rate. This means we’ve likely finally hit the final stage payload of remcos. Further to\r\nthis by examining the resources sections there is a ‘SETTINGS’ resource which is a known indicator of Remcos\r\nRAT. IT also has a high entropy level indicating it is likely compressed or encrypted.\r\nDecrypting the Remcos RAT Configuration Resource\r\nLeveraging a post from the team at Morphisec who have analysed a different sample in the past highlighted how\r\nRemcos RAT uses rc4 encryption on the ‘SETTINGS’ resource to encrypt to malware configuration. Specifically\r\nit uses the first byte in this resource to define the key length, the next amount of bytes up to that key length is the\r\nkey, and the rest of it is the encrypted data.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 27 of 44\n\nUsing this in CyberChef provides what looks to be a configured C2 server and port, in addition to what may be a\r\nunique identifier and a number of other fields.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 28 of 44\n\nIOC C2 Domain: gdyhjjdhbvxgsfe[.]gotdns[.]ch\"\r\nIOC Port: 2718\r\nIOC Host Identifier: Rmc-JQX1JF\r\nA publicly avaialble decoder by kevthehermit provides extra insight into this configuration file and what data it\r\nmay contain.\r\nRebasing and Dynamically Resolving Imported Functions\r\nGiven the RAT is created in C++, leveraging x32dbg and Ghidra is a great way to uncover how it works at\r\ndifferent parts of the program. Specifically if the base address between these are synced then it’ll make the\r\nanalysis process that much smoother. After opening in x32dbg the base address can be seen and copied in the\r\nMemory Map.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 29 of 44\n\nOpening the memory map in Ghidra, this can be rebased by using the house icon.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 30 of 44\n\nA quick and dirty way of getting context on what may be resolved from or sent to a particular API is to create a\r\nconditional breakpoint which logs the address information of all registers whenever an API call of interest is\r\nmade. Breaking on LoadLibraryExW and LoadLibraryA in x32dbg by running the below command can be used as\r\na starting point.\r\nbp LoadLibraryExW\r\nbp LoadLibraryA\r\nThese can then be edited to include ‘Log Text’ similar to the below.\r\nLoadLibraryExW: eax:{a:eax} ebx:{a:ebx} ecx:{a:ecx} edx:{a:edx} ebp:{a:ebp} esp:{a:esp} esi:{a:esi} edi:{a:edi}\r\nLoadLibraryA: eax:{a:eax} ebx:{a:ebx} ecx:{a:ecx} edx:{a:edx} ebp:{a:ebp} esp:{a:esp} esi:{a:esi} edi:{a:edi}\r\nBy running the program, every time the breakpoint is hit, x32dbg will log the registers. Although it may seem\r\nnoisy, this approach can quickly gain useful information. In this sample ‘LoadLibraryA’ appears to be used to get a\r\nhandle on and load a number of functions at run time such as ‘GetComputerNameExW’, and ‘GetSystemTimes’\r\nwhich are not explicitly imported by the RAT.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 31 of 44\n\nExamining Entry and Editing WinMain Function in Ghidra Decompiler\r\nExamining the entrypoint in Ghidra shows 2 functions, ‘__security_init_cookie’ and ‘__scrt_common_main_seh’\r\nwhich are part of C and C++ initialisation code.\r\nThe main remcos method exists inside of ‘__scrt_common_main_seh’ and can be examined. Using Ghidra the\r\nfunction call tress can be shown which at a high level reveals 2 custom functions of interest; however, only one\r\ndoesn’t contain a single line and has substantial subfunctions ‘FUN_0040db10’.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 32 of 44\n\nGlancing at this function in Ghidra makes it apparent that this is the WinMain function given it is running all\r\nsubfunctions; however, the Ghidra decompiler has failed to identify this, and it is reporting only 3 parameters\r\nbeing passed to the function ‘0x400000’, ‘0’, and ‘pcVar7’. By right clicking and editing the function this can be\r\ncleaned up.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 33 of 44\n\nGoing through each datatype, this function can be fixed to more accurately replicate the WinMain function\r\nsignature shown below.\r\nint WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR lpCmdLine, int nCmdShow)\r\nThe end result is as follows:\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 34 of 44\n\nSaving this and returning to the decompiled code shows something which makes a lot more sense. The instance is\r\ngetting a handle to the current executable’s DOS Header, passed parameeters are being retrieved by\r\n‘__get_narrow_winmain_command_line’, and whether or not to show this application window is being retrieved\r\nfrom ‘__get_show_window_mode’.\r\nA quick look at what’s retrieved for the show window value shows this will always return 0.\r\nInitial Analysis of WinMain Function in Ghidra\r\nCombing over WinMain shows a large number of functions are present. The first function ‘FUN_0041ae1a’ at a\r\nglance looks like it is dynamically importing libraries to be used at runtime based on its API calls.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 35 of 44\n\nExamining the function confirms these suspicions, and also provides more context to the imported functions\r\nwhich were seen during dynamic analysis.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 36 of 44\n\nThis can be renamed to something more meaningful such as ‘FUN_Load_Imports’.\r\nDecrypting SETTINGS Resource in Ghidra and x32dbg\r\nExamining the next function ‘FUN_0040e4a3’, shows it immediately makes a call to ‘FUN_004199a9’ which\r\nappears to be getting the SETTINGS resource using FindResourceA and LoadResource, and is storing this into a\r\nbyte stream to be used.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 37 of 44\n\nThere’s also mention of FID_conflict which occurs from the ‘Function ID’ Ghidra analyser which has found\r\nmultiple functions which match a computed hash during analysis. This can be resolved by using a plugin such as\r\nAndrew Strelsky’s ResolveFidScript\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 38 of 44\n\nUsing x32dbg, a breakpoint can be set at the address ‘0040E4E3’ (offset 0xE4E3). Once run, it’s shown in the\r\nmemory dump of register EBX that this was in fact retrieving the RC4 key from the SETTINGS resource.\r\nAt this point the Base Pointer Register (EBP) is also set to 76 which is the RC4 key length.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 39 of 44\n\nFinally the entire contents of the SETTINGS resource is stored within the Destination Index Register (EDI).\r\n‘FUN_004199a9’ can now be renamed to ‘FUN_Load_Config’ in Ghidra. Creating breakpoints on each function\r\ncall and running the program in x32dbg gives some idea of later functions. Specifically only minor operations\r\noccur until ‘FUN_0040644c’ at address ‘0040E53B’ (offset 0xE53B). At this call the Source Index Register points\r\nto memory containing the RC4 encrypted content, and EBX contains the RC4 key.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 40 of 44\n\nLooking into this function it runs a couple of other functions, but of particular interest is function\r\n‘FUN_004063b0’ which is performing some sort of iterative looping operation with a noted array of 256 integers\r\nhaving been defined which is being used in subsequent XOR operations.\r\nKnowing how RC4 works makes identifying this function as the Pseudo-random generation algorithm (PRGA)\r\nmuch easier. Comparing the pseudocode to Ghidra’s decompiled output these operations can mostly be seen.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 41 of 44\n\nThe function immediately prior to the PRGA function is part of a necessary Key-scheduling algorithm (KSA) that\r\ntakes place during RC4 encryption and decryption (FUN_0040632b), and can be noted by the use of 0x100 (256)\r\nwhich is the max keylength that is defined in an array used in ‘FUN_004063b0’. At a glance it’s more difficult to\r\ndetermine what is occurring here based solely on Ghidra’s decompiled interpretation; however, the function graph\r\nhelps to see common looping trends.\r\nJumping over to x32dbg, a breakpoint can be placed at address ‘0040643A’ (offset 643A) to see how this impacts\r\nthe RC4 encrypted data on the stack. On first run it can be seen that the first byte changes to a ‘g’ in ascii.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 42 of 44\n\nBreaking outside of this loop at address ‘0040642B’ (offset 0x642B) shows the decrypted content on the stack.\r\nFrom this ‘FUN_0040644c’ can be renamed to ‘FUN_RC4_PRGA’, ‘FUN_0040632b’ can be renamed to\r\n‘FUN_RC4_KSA’ and ‘FUN_0040e4a3’ can be renamed to ‘FUN_Load_Decrypt_Config’ in Ghidra.\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 43 of 44\n\nWrapping up / Continued Work\r\nThe next major operation which occurs is a comparison checking to see whether ‘-l’ is being passed to Remcos as\r\npart of a string comparison at address 0040DB76 (offset 0xDB76)\r\nSource: https://www.jaiminton.com/reverse-engineering/remcos#\r\nhttps://www.jaiminton.com/reverse-engineering/remcos#\r\nPage 44 of 44\n\nthe object field is passed to the method ignored. The parameters being invoked. on the other By cross-correlating hand are not, the methods so this tells us that were seen that no parameters to be static are to with those be shown\nin dnspyEx, it’s seen that there’s only 2 methods this could be ‘T4Z5pBPufA’ or ‘uqH5vT69wm’.\n   Page 18 of 44 \n\n  https://www.jaiminton.com/reverse-engineering/remcos#     \nStepping through a couple more instructions shows that a file is written to the identified temporary file containing\nthe complete scheduled task XML. It should be noted this has a hardcoded IOC of the scheduled task registration\ntime being spoofed.       \n   Page 25 of 44",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.jaiminton.com/reverse-engineering/remcos#"
	],
	"report_names": [
		"remcos#"
	],
	"threat_actors": [],
	"ts_created_at": 1775439038,
	"ts_updated_at": 1775791279,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c5e8824a5c21ad3c073a398e009e467b5804134f.pdf",
		"text": "https://archive.orkl.eu/c5e8824a5c21ad3c073a398e009e467b5804134f.txt",
		"img": "https://archive.orkl.eu/c5e8824a5c21ad3c073a398e009e467b5804134f.jpg"
	}
}