{
	"id": "4b592d2b-0b8e-46d0-909d-725706f38d1e",
	"created_at": "2026-04-10T03:21:02.644829Z",
	"updated_at": "2026-04-10T03:22:19.190431Z",
	"deleted_at": null,
	"sha1_hash": "c30ca5549a0d6b3c988912c7db9070ea31e0d649",
	"title": "Amadey Bot Malware Analysis - Static Analysis and C2 Extraction With Ghidra and x64Dbg",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 10758064,
	"plain_text": "Amadey Bot Malware Analysis - Static Analysis and C2 Extraction\r\nWith Ghidra and x64Dbg\r\nBy Matthew\r\nPublished: 2023-04-10 · Archived: 2026-04-10 02:24:11 UTC\r\nDeep-dive analysis of a packed Redline Stealer sample. Utilising manual analysis and semi-automated string\r\ndecryption to extract C2 information and ultimately identify the malware.\r\nIn this write-up, we intentionally try to touch on as many concepts as possible in order to demonstrate practical\r\napplications and hopefully provide a better learning experience for the reader.\r\nNote that we have now added a second post covering analysis of the C2 server from this sample.\r\nQuick Caveat\r\nWe realized after the initial post that this sample is actually Amadey Bot. The analysis and RE\r\ntechniques remain equally relevant, but the sample is not actually Redline as the title suggests :)\r\n(There is a second file in the .cab which contains Redline Stealer, which may explain why the initial file\r\nwas semi-incorrectly marked as Redline)\r\nWe were able to determine this by researching the decrypted strings that are detailed at the end of the\r\npost.\r\nIf you're interested in how to use decrypted strings to identify or confirm a malware family. Jump to the\r\nbonus section \"Utilising Decrypted Strings To Identify the Malware Family\" of this blog.\r\nObtaining The Malware Sample\r\nThe initial file can be downloaded from Malware Bazaar with SHA256: .\r\n449d9e29d49dea9697c9a84bb7cc68b50343014d9e14667875a83cade9adbc60\r\nAnalysis Summary\r\nFeel free to jump to certain sections if you are already comfortable with some of these concepts.\r\nSaving the file and extracting the initial .exe\r\nUsing Entropy to identify that the initial .exe is packed\r\nUsing a debugger to manually unpack the first payload\r\nInitial analysis of the unpacked payload\r\nIdentifying interesting strings and imports\r\nStatic Analysis to establish the context of interesting strings and imports\r\nUtilising a debugger to analyse the String Decryption function\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 1 of 45\n\nAutomating the String Decryption using X32dbg\r\nUtilising Decrypted strings to identify the malware family.\r\nActual Analysis\r\nThe analysis can kick off by downloading the above file and transferring it into a safe analysis machine. (We\r\nstrongly recommend and personally use FLARE-VM for analysis)\r\nThe file can be extracted with the password infected .\r\nUnzipping the file with the password \"infected\"\r\nAfter successful extraction - detect-it-easy can be used to perform an initial analysis of the file.\r\nThis reveals that the file is a 32-bit executable. Which, in this case, is actually a Microsoft Cabinet file.Microsoft\r\nCabinet file This is essentially a .zip that can be executed as a .exe file.\r\nInitial Malware Analysis using Detect-it-easy\r\nThe file is similar enough to .zip that 7-zip is able to extract the contents of the file just like a regular zip file.\r\nWe were able to use 7zip to extract the contents, creating two new exes in the process. These are si684017.exe\r\nand un007241.exe in the screenshot below.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 2 of 45\n\nAdditional files after extracting initial .cab. \r\nFor now, I'll focus on the si684017.exe file.\r\nInitial Executable File\r\nThe initial is file recognized as a 32-bit exe file by detect-it-easy .\r\nInterestingly - it was not a .NET as most Infostealers generally are. This means that the usual DnSpy won't be\r\napplicable here.\r\n(Check out my analysis of dcrat for tips on using Dnspy)\r\nInitial file analysis using Detect-it-easy\r\nDuring initial analysis, we always want to determine if the file is potentially a packed loader rather than a final\r\npayload. If we have reason to suspect a packed payload, we typically focus on unpacking rather than strings or\r\nother static analysis.\r\nA packed sample will typically contain areas of significantly high entropy.\r\nTo determine areas of entropy - we utilized the Entropy Graph feature within Detect-it-easy.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 3 of 45\n\nMalware Entropy Analysis Using Detect-it-easy\r\nThis revealed a very area of high entropy within the file. This is a strong indication that the file is a packed loader\r\nand not the final payload.\r\nIn situations like this - we proceed to focus on unpacking the file.\r\nSince this is a \"regular\" exe file and not a .NET-based file - we proceeded to unpack the file using X32dbg.\r\nUnpacking Using X32dbg\r\nWhen a standard loader unpacks a file, it typically uses a combination of VirtualAlloc , VirtualProtect and\r\nCreateThread . These functions allow the malware to allocate new sections of memory that can be used to store\r\nand execute the unpacked payload.\r\nAdvanced malware will heavily obfuscate these functions and/or avoid using them completely. But in\r\n90% of cases - the previously mentioned functions are relevant.\r\n(Check out my blog on API hashing for how this obfuscation can be done)\r\nIn most malware - We can set breakpoints on the VirtualAlloc and VirtualProtect function calls and monitor\r\nthe results using Hardware Breakpoints . This will alert when the newly allocated buffer is accessed, from there it\r\nis generally simple to obtain the decoded payload.\r\nTo summarise this:\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 4 of 45\n\nIdentify a Function of Interest (In this case VirtualAlloc )\r\nCreate a breakpoint to monitor VirtualAlloc\r\nObtain the Memory Buffer created by VirtualAlloc\r\nUse a Hardware Breakpoint - to alert when the new memory buffer is accessed\r\nAllow the malware to execute until the buffer is filled\r\nSave the buffer to a file\r\nI've previously written a thread on how to use Hardware Breakpoints to unpack Cobalt Strike Loaders. You can\r\ncheck it out here.\r\nLoading the File into X32dbg\r\nTo initiate this process - we dragged the file into a debugger (x32dbg) and allowed the file to execute until the\r\nEntry Point. This can be done by loading the file and once clicking the F9 button.\r\nViewing the Entrypoint using a Debugger (x32dbg)\r\nCreating The Breakpoints\r\nBreakpoints were then required in order to inspect the appropriate VirtualAlloc function.\r\nNote that in this case - the primary interest is in the output (or return value) of VirtualAlloc . The\r\nrelevance of this is that we care about the data at the \"end\" of the breakpoint, and not at the moment\r\nwhere the breakpoint is hit.\r\nIf that's confusing then let's just see it in action (it's always confusing the first dozen times)\r\nSet two breakpoints using the following commands\r\nbp VirtualAlloc , bp VirtualProtect\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 5 of 45\n\nSetting a breakpoint on VirtualAlloc using x32dbg\r\nHit F9 (Continue) again, allowing the malware to execute until a breakpoint is hit.\r\nA breakpoint is immediately hit on the VirtualAlloc function\r\nTriggering a breakpoint on VirtualAlloc\r\nThe primary purpose of VirtualAlloc is to allocate memory and return an address to the newly allocated buffer.\r\nThis newly allocated memory is contained in the EAX register when the function is completed.\r\nTLDR: Since we're only interested in that buffer - we utilized the Execute Until Return or CTRL+F9 to jump\r\nstraight to the end of the function and obtain the result.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 6 of 45\n\nHow to \"Execute Until Return\" using x32dbg\r\nAllowing the malware to Execute Until Return - provides an EAX register containing the address of the memory\r\nbuffer to be used by the malware.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 7 of 45\n\nViewing the memory buffer returned by VirtualAlloc\r\nThere is nothing particularly special about EAX, it is just the standard register used for returning the\r\nresults of a function.\r\nTo learn more about EAX and calling conventions - there's a great video on that from OALABS.\r\nTo monitor the buffer returned by VirtualAlloc , Right-click on the returned address 02250000 address and\r\nselect Follow in Dump .\r\nThis will cause the bottom-left window to display the newly allocated memory.\r\nThe buffer of memory currently contains all 00 's, as nothing has been used or written to the buffer yet.\r\nUsing x32dbg (Follow In Dump) to view the contents of a memory buffer\r\nIt is important to be notified when that buffer of 00 's is no longer a buffer of 00 's.\r\nTo achieve this - A hardware breakpoint can be applied on the first byte of the newly allocated buffer.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 8 of 45\n\nSetting a Hardware Breakpoint Using x32dbg\r\nSuccessful creation of a Hardware Breakpoint\r\nOnce the hardware breakpoint is set - the malware can continue to execute using the F9 button.\r\nThe Hardware Breakpoint will immediately be triggered.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 9 of 45\n\nTriggering a Hardware Breakpoint using X32dbg\r\nOnce this happens, use CTRL+F9 (Execute Until Return, aka \"just finish what you're doing now, but don't do\r\nanything else\") to allow the malware to continue writing to the buffer without actually executing it.\r\n(Utilising CTRL+F9 will cause the malware to stop at the end of the current function - preventing the execution of\r\nthe rest of the malware)\r\nOnce the current function is finished - the buffer will look something like this.\r\nIdentifying a Memory Buffer containing Shellcode\r\nUnfortunately - the first buffer does not contain an unpacked PE file. It does contain a large buffer of shellcode\r\nwhich is used to unpack the next section using another VirtualAlloc .\r\nIf the file was successfully unpacked - it would typically look something more akin to this\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 10 of 45\n\nIdentifying an unpacked PE file in a memory buffer\r\nIn this case, there is only shellcode in the buffer. You can typically determine that the buffer is shellcode by the\r\npresence of the EB (jmp) byte. You can also confirm the suspected shellcode by inspecting the instructions using\r\nRight-Click -\u003e Follow in Disassembler .\r\nIf the code disassembles without errors (No glaring red sections) - it is highly likely to be shellcode.\r\nUsing x32dbg to validate shellcode contained in a memory buffer\r\nAt this stage - the shellcode could be dumped into a file for further analysis.\r\nHowever, it is often better to allow the shellcode to execute. The malicious actions taken by the shellcode will\r\noften trigger the same breakpoints intended for the \"original\" malware.\r\nObtaining The Unpacked Payload\r\nHitting F9 (Continue) to allow the malware to execute - another breakpoint is hit on VirtualAlloc\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 11 of 45\n\nViewing VirtualAlloc function in a debugger (x32dbg)\r\nUsing the same trick of Execute Until Return , Select EAX and Right-Click -\u003e Follow in Dump , the\r\nsecond allocated buffer can be obtained.\r\nUsing x32dbg to locate another memory buffer returned by VirtualAlloc\r\nAnother Hardware Breakpoint will need to be set at the start of the buffer.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 12 of 45\n\nCreating another Hardware Breakpoint on the memory address\r\nAllowing the malware to continue to execute - the hardware breakpoint is hit. This time containing a promising\r\nM . (First half on an MZ header)\r\n(Side note that my debugger suddenly crashed here and had to be restarted - hence the slight change of address in\r\nfuture screenshots)\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 13 of 45\n\nMemory buffer - potentially containing an unpacked pe-file payload\r\nAllowing the malware to continue to execute - A complete MZ/PE file can be found. At this point, the unpacked\r\nfile has been successfully loaded into memory.\r\nA complete Pe-file written to the memory buffer\r\nSaving the Unpacked File\r\nTo save the unpacked file - Right-Click on the start address and select Follow in Memory Map\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 14 of 45\n\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 15 of 45\n\nHow to save a memory buffer using x32dbg\r\nThis will reveal the location where the buffer was allocated. The entire memory buffer can then be saved by using\r\nRight-Click and Dump Memory to File\r\nUsing Memory Map to save a specific memory section in x32dbg\r\nThe final button used to dump the memory to a file using x32dbg\r\nThe file can now be saved as unpacked.bin (or any other file name of choosing)\r\nSpecifying a name for the unpacked file\r\nInitial Analysis - Unpacked Payload\r\nThe file is a 32-bit executable with no (recognized) packers or obfuscation.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 16 of 45\n\nInitial analysis of suspected unpacked payload using detect-it-easy\r\nThe entropy graph does not contain any areas of significantly high or flat entropy - suggesting that the file is not\r\npacked and does not contain any additional payloads.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 17 of 45\n\nAdditional Entropy Analysis - Suggesting no hidden payloads - No significant areas of entropy\r\nSince this was potentially a final payload - we checked the strings for any unobfuscated information.\r\nThis revealed some base64 encoded data - but we weren't able to successfully decode it.\r\nThe base64 encoding has likely been combined with additional obfuscation.\r\nBase64 Encoded Strings contained within the malware file\r\nFailing to decode the \"base64\"\r\nCyberchef - Failure to decode the base64 strings - signs of additional obfuscation\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 18 of 45\n\nImport Analysis\r\nImported functions are an additional valuable source of information. Especially for suspected unpacked files.\r\nThe imported functions referenced capability that suggested the file can download data and make internet\r\nconnections.\r\nSince these functions need C2 information in order to work, this is a good sign that the C2 config may be\r\ncontained within this file.\r\nMalware Import Analysis Using Detect-it-easy\r\nGhidra Analysis\r\nAt this point, we decided to analyze the file further using Ghidra . My plan was to utilise Ghidra to gather more\r\ninformation on the suspicious imports related to c2 connections InternetReadFile , InternetConnectA ,\r\nHttpSendRequestA etc.\r\nIn addition to this - we wanted to investigate the suspicious \"base64\" strings identified with detect-it-easy.\r\nTo investigate both - we intended to utilise cross references or X-refs to observe where the strings and imports\r\nwere used throughout the code. From here we hoped to find arguments passed to the internet functions (hopefully\r\ncontaining a C2), or to find the logic behind the function that accesses the base64 encoded strings.\r\nTo Summarise - My plan was to Utilise Ghidra to...\r\nInvestigate the suspicious strings - which function are they passed to? what does that function do with\r\nthem? Can we trace the input and output of that function?\r\nInvestigate Suspicious Imports - Check where the imports were used, and what arguments were being\r\npassed. Can we set a breakpoint and view the decrypted C2s?\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 19 of 45\n\nString Searching with Ghidra\r\nWe took the first approach, using Ghidra to search for strings within the file.\r\nSearching for Strings Using Ghidra\r\nBy filtering on == , we were quickly able to narrow the results down to the previously identified base64 strings.\r\nThis was not all relevant strings, but it was a solid starting point.\r\nLocating base64 strings using Ghidra\r\nWe double-clicked on one of the larger strings, taking me to its reference within the file.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 20 of 45\n\nFrom here we could hit CTRL+SHIFT+F to find references to this string. Alternatively, you could Right Click -\u003e\r\nReferences -\u003e Show References to Address\r\nUsing Ghidra to locate Cross-references from strings\r\nClicking on the one available reference - reveals an undefined function acting upon the string.\r\nEncountering an Undefined Function in Ghidra\r\nBy clicking on the first address of the function and hitting F , we can define a function at the current address.\r\nDefining a Function in Ghidra\r\nAfter defining a function - the decompiler output now looks much cleaner.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 21 of 45\n\nViewing a new function in Ghidra - an obfuscated string can be seen\r\nWe can enter the function at FUN_00414550 and investigate.\r\nThe function contains a bunch of C++-looking junk, which was difficult to analyse - so we decided to take a\r\nslightly different approach.\r\nViewing a suspicious function using Ghidra\r\nWe checked the number of cross-references on the FUN_00414550 function. A high number of cross-references\r\nwould indicate that the function is responsible for decoding more than just this encoded string.\r\nIf the same function is used for all string-related decryption, then perhaps a debugger and a breakpoint are the\r\nbetter approach.\r\nAt minimum - a debugger will at least confirm the theory that this function is related to string decryption.\r\nString Decryption Via X32dbg\r\nWe decided to investigate the string decryption using X32dbg.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 22 of 45\n\nTo do this - we would need to set a breakpoint on the function that we suspected was responsible for string\r\ndecryption.\r\nAttempting to copy and paste the address directly from Ghidra will likely result in an error as the addresses may\r\nnot align.\r\nSyncing Addresses with Ghidra and X32dbg\r\nTo Sync the Addresses between Ghidra and X32dbg. We need to find the base of our current file. This can be\r\nfound in the memory map and in this case is 003e0000 . Although it may be different for you.\r\nHow to identify a base address in a debugger (x32dbg)\r\nFrom here we can select the memory map within Ghidra.\r\nHow to use Ghidra to Sync a Memory Address\r\nThen select the Home button\r\nUsing Ghidra to Sync memory address with x32dbg\r\nand set the base address according to what was obtained with x32dbg.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 23 of 45\n\nUsing Ghidra to sync a memory address with x32dbg\r\nFrom here, the address of the suspected string decryption function will be updated accordingly and be in sync with\r\nx32dbg.\r\nString Decryption Function in Ghidra with Updated Memory Address\r\nThe new function address is 003f4550 . This value can be used to create a breakpoint inside of x32dbg.\r\nUpdated Memory Address in Ghidra\r\nCommand for creating a breakpoint on a known suspicious function\r\nThe breakpoint is then hit with an argument of j hl#A\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 24 of 45\n\nBeginning of a suspicious function in x32dbg\r\nAllowing the malware to Execute Until Return will retrieve the result of the function. In this case, it was a\r\nlarge hex string that was pretty uninteresting.\r\nEnd of a suspicious function - viewing the returned value - possible decoded string\r\nHowever, Clicking F9 or Continue will cause the Decryption code to be hit again.\r\nSadly, this again revealed some largely uninteresting strings\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 25 of 45\n\nWe eventually realised that this function was not used to decode the final strings. But was rather to obtain copies\r\nof the same base64 obfuscated strings that were previously found.\r\nAt this point, we experimented with the Suspicious imports but could not reliably trace them back to a function\r\nthat would obtain the decrypted C2 .\r\nHowever - we did get lucky and was able to locate an interesting function towards the main malware function of\r\nthe code.\r\nThis function was located at 003d29b0 .\r\nLocating Main\r\nWe were able to locate main by browsing to the EntryPoint.\r\nAttempting to locate the main function in Ghidra - Starting from Entry Point\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 26 of 45\n\nAttempting to locate the main function using Ghidra\r\nSuccessfully finding the main function within Ghidra\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 27 of 45\n\nIdentifying a possible string decryption function in Ghidra\r\nWhen this function is executed - a base64 encoded value is passed as an argument.\r\nBase64 Function Arguments viewed in a debugger. \r\nExecuting until the end of the function - A value is obtained, which the malware used to create a folder in the\r\nuser's temp directory.\r\nObtaining a decoded value using x32dbg\r\nThe next call to this function - took a base64 encoded argument and returned a file name that the malware was\r\ncopied into.\r\nA second encoded value in eax- viewed in x32dbg\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 28 of 45\n\nA decoded filename - located using return addresses in x32dbg\r\nAt a location of 003e9870 - was a function responsible for checking the location of the current running file.\r\nIf the location did not match C:\\\\users\\\\\u003cuser\u003e\\\\appdata\\\\local\\\\temp\\\\595f021478\\\\oneetx.exe - then the\r\nmalware would terminate.\r\nHere we can see the return value from the function.\r\nAs well as the outgoing function calls in the Ghidra Function Tree.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 29 of 45\n\nViewing the Function Tree Using Ghidra\r\nAfter the directory check is performed - the malware enters FUN_003e7b70 attempts to create a mutex with a\r\nvalue of 006700e5a2ab05704bbb0c589b88924d\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 30 of 45\n\nBy breaking on CreateMutexA - The value of 006700e5a2ab05704bbb0c589b88924d can be seen as an argument.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 31 of 45\n\nIf the mutex creation returned a value of 0xb7 (Already Exists) - then the malware would terminate itself.\r\nBypassing Anti-Something Checks\r\nThese two checks on the file path and Mutex can function as pseudo-anti-debug checks. To continue analysis, they\r\nneeded to either be patched or bypassed.\r\nTo bypass the file path check - we allowed the malware to execute inside the analysis VM and copy itself to the\r\ncorrect folder. we then opened the new file inside the debugger.\r\nAlternatively - we could have patched or nop'd the function. but we found that just moving it to the\r\nexpected folder worked fine.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 32 of 45\n\nOnce the new file was loaded - we updated the base address in Ghidra to match the new address in x32dbg.\r\nOnce we updated the base address - we set a breakpoint on CreateMutexA and the suspected decryption function\r\nFUN_XXXX29b0\r\nOnce we hit the breakpoint on CreateMutexA - we stepped out of the function using Execute Until Return and\r\nthen Step Over twice.\r\nThis allowed me to see the return value of b7 from the GetLastError function. When we allowed the malware\r\nto continue to run - it quickly terminated itself without hitting the decryption breakpoint.\r\nTo fix this - we used Edit to patch the return value to be B6 instead.\r\nPatching a return value using X32dbg\r\nUpon running the malware - The decryption function was hit again.\r\nFollowing the return of the decryption function using Exeute Until Return revealed a pretty boring \\\\\r\ncharacter.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 33 of 45\n\nBut allowing it to hit a few more times - it eventually returned a value of Startup which was pretty interesting.\r\nHitting again revealed a registry path of\r\nSOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\User Shell Folders\r\nEventually some more interesting values were returned. Including a partial command likely used to create\r\npersistence.\r\nAs well as some possible signs of enumeration\r\nEventually - The names of some security products was also observed. Likely the malware was scanning for the\r\npresence of these tools.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 34 of 45\n\nEventually, the constant breakpoint + execute until the return combination got tiring.\r\nAllowing the decryption function to continue to execute and hit our breakpoint. We can eventually observe C2\r\ninformation.\r\nAutomating the Decryption - Kinda\r\nEventually, the constant breakpoint + execute until the return combination got tiring. So we decided to try and\r\nautomate it using a Conditional Breakpoint and Log.\r\nTo do this - we allowed the malware to execute until the end of a decryption function.\r\nAnd then created a Conditional Breakpoint that would log any string contained at eax, then continue execution.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 35 of 45\n\nSettiing a Conditional Breakpoint (and logging a value) using X32dbg\r\nAllowing the malware to continue to execute. We could observe the decoded values printed to the log menu of\r\nx32dbg.\r\nSuccessfully using conditional breakpoints to decode a malware sample. \r\nThis revealed some c2 information - referencing an IP with 1/87 detections as of 2023/04/10\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 36 of 45\n\nThe full list of decoded strings can be found here.\r\n \u0026\"SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\User Shell Folders\"\r\n \u0026\"SYSTEM\\\\CurrentControlSet\\\\Control\\\\ComputerName\\\\ComputerName\"\r\n \u0026\"SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\"\r\n \u0026\"abcdefghijklmnopqrstuvwxyz0123456789-_\"\r\n \u0026\"/Create /SC MINUTE /MO 1 /TN \"\r\n \u0026\"/plays/chapter/index.php\"\r\n \u0026\"GetNativeSystemInfo\"\r\n \u0026\"cred.dll|clip.dll|\"\r\n \"77[.]91[.]124[.]207\"\r\n \"Panda Security\"\r\n \"AVAST Software\"\r\n \"Kaspersky Lab\"\r\n \"ProgramData\\\\\"\r\n \"ComputerName\"\r\n \"CurrentBuild\"\r\n \"kernel32.dll\"\r\n \"Bitdefender\"\r\n \"Doctor Web\"\r\n \"https://\"\r\n \"Plugins/\"\r\n \"SCHTASKS\"\r\n \"http://\"\r\n \" /TR \\\"\"\r\n \"Startup\"\r\n \"Comodo\"\r\n \"Sophos\"\r\n \"Norton\"\r\n \"Avira\"\r\n \"\\\" /F\"\r\n L\"\\\\¬=\"\r\n \"POST\"\r\n \"\u0026vs=\"\r\n \"3.70\"\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 37 of 45\n\n\"\u0026sd=\"\r\n \"\u0026os=\"\r\n \"\u0026bi=\"\r\n \"\u0026ar=\"\r\n \"\u0026pc=\"\r\n \"\u0026un=\"\r\n \"\u0026dm=\"\r\n \"\u0026av=\"\r\n \"\u0026lv=\"\r\n \"\u0026og=\"\r\n \"ESET\"\r\n \"dll\"\r\n \"\u003cc\u003e\"\r\n \"id=\"\r\n \"AVG\"\r\n ???\r\nThe first link contains IOCs from an Amadey Bot sample, which aligns closely with the sample analysed in this\r\nblog.\r\nThis section was not in the original blog, but was later added when we were informed by another\r\nresearcher that the malware might not be Redline.\r\nWe then revisited my analysis and determined that the sample was Amadey Bot.\r\nWe were able to determine this mostly by researching (googling) the decrypted strings.\r\nWe thought it would be useful for others to see what this process looked like :)\r\nDecrypted strings are not just useful for C2 information. They are equally as useful for identifying the malware\r\nthat you are analyzing.\r\nUnless you are analyzing the latest and greatest APT malware, your sample has likely been analyzed and\r\npublically documented before. You'd be surprised how much you can determine using Google and the \"intext\"\r\noperator. (Essentially it forces all search results to contain your query string, significantly reducing unrelated\r\ncontent)\r\nFrom decrypted strings, try to pick something specific.\r\nFor example, the following decrypted string \u0026\"cred.dll|clip.dll|\" can be used to craft a Google query of\r\nintext:clip.dll intext:cred.dll malware .\r\nThis returns 7 results that reference a combination of Redline Stealer and Amadey Bot.\r\nThe first link contains IOCs from an Amadey Bot sample, which aligns closely with the sample analysed in this\r\nblog.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 38 of 45\n\nIn the second link - An additional Amadey sample is analysed with the exact same filename as this one. Albeit\r\nwith a different C2 server.\r\nAt this point - we would have moderate confidence that the sample is Amadey Bot.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 39 of 45\n\nFor additional confirmation, we would typically Google this family and see if any TTPs are the same or at least\r\nsimilar.\r\nWe googled Amadey Bot Analysis and discovered this blog from AhnLab.com.\r\nThe Ahnsec blog details an extremely similar installation path and strings.\r\nThe Ahnsec Blog also references a list of AV products that are enumerated by Amadey Bot.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 40 of 45\n\nCoincidentally, almost all of those strings were contained in our sample\r\nThe Ahnsec blog also references specific parameters that are sent in POST requests made by Amadey Bot.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 41 of 45\n\nCoincidentally, almost all of those same fields (first column) are referenced in our decrypted strings.\r\nSince POST request parameters are pretty specific - we were confident my sample was actually Amadey bot.\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 42 of 45\n\nWe also reviewed a second blog from Blackberry. Which confirmed much of the same analysis as AhnSec.\r\nWe were now comfortable re-classifying the malware as Amadey bot.\r\n(We also learned not to blindly follow tags from Malware Repositories)\r\nConclusion and Recommendations\r\nAt this point, we're going to conclude the analysis, as we have successfully located the C2 information and\r\nidentified the malware family. In a real-life situation, this analysis could serve multiple purposes.\r\nDecrypted strings can be googled to aid in malware identification.\r\nDecrypted strings contain commands and process names that can be used for process-based hunting\r\nDecrypted Strings contain a URL structure that can used to hunt or develop detection rules for proxy logs.\r\nDecrypted Strings contain an IP that could be used to identify infected machines.\r\nDecrypted Strings can be used to enhance a Ghidra or IDA database - enhancing the decompiler output and\r\nleading to better RE analysis.\r\nBetter automation could be used to make a config extractor - useful for a threat intel/analysis pipeline.\r\n(Replacing x32dbg with Dumpulator would be a great way to do this)\r\n+ lots of fun :D\r\nVirustotal\r\nAt the time of this analysis (2023/04/10) - There is only 1/87 detections for the C2 on Virustotal\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 43 of 45\n\nDecoded Strings\r\nA full list of strings obtained using the log function of x32dbg.\r\n(Noting that these are in order of length and not location of occurrence.)\r\n \u0026\"SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\User Shell Folders\"\r\n \u0026\"SYSTEM\\\\CurrentControlSet\\\\Control\\\\ComputerName\\\\ComputerName\"\r\n \u0026\"SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\"\r\n \u0026\"abcdefghijklmnopqrstuvwxyz0123456789-_\"\r\n \u0026\"/Create /SC MINUTE /MO 1 /TN \"\r\n \u0026\"/plays/chapter/index.php\"\r\n \u0026\"GetNativeSystemInfo\"\r\n \u0026\"cred.dll|clip.dll|\"\r\n \"77[.]91[.]124[.]207\"\r\n \"Panda Security\"\r\n \"AVAST Software\"\r\n \"Kaspersky Lab\"\r\n \"ProgramData\\\\\"\r\n \"ComputerName\"\r\n \"CurrentBuild\"\r\n \"kernel32.dll\"\r\n \"Bitdefender\"\r\n \"Doctor Web\"\r\n \"https://\"\r\n \"Plugins/\"\r\n \"SCHTASKS\"\r\n \"http://\"\r\n \" /TR \\\"\"\r\n \"Startup\"\r\n \"Comodo\"\r\n \"Sophos\"\r\n \"Norton\"\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 44 of 45\n\n\"Avira\"\r\n \"\\\" /F\"\r\n L\"\\\\¬=\"\r\n \"POST\"\r\n \"\u0026vs=\"\r\n \"3.70\"\r\n \"\u0026sd=\"\r\n \"\u0026os=\"\r\n \"\u0026bi=\"\r\n \"\u0026ar=\"\r\n \"\u0026pc=\"\r\n \"\u0026un=\"\r\n \"\u0026dm=\"\r\n \"\u0026av=\"\r\n \"\u0026lv=\"\r\n \"\u0026og=\"\r\n \"ESET\"\r\n \"dll\"\r\n \"\u003cc\u003e\"\r\n \"id=\"\r\n \"AVG\"\r\n ???\r\nUseful Links\r\nAhnSec Labs - Blog on Amadey Stealer\r\nBlackberry Blog - Amadey Bot Analysis\r\nMandiant - Repo for Flare VM Install\r\nX32dbg Documentation - Conditional Breakpoints in X32dbg\r\nSource: https://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nhttps://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/\r\nPage 45 of 45\n\n https://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/  \nAttempting to locate the main function using Ghidra\nSuccessfully finding the main function within Ghidra\n   Page 27 of 45\n\nx32dbg. Successfully using conditional breakpoints to decode a malware sample.\nThis revealed some c2 information-referencing an IP with 1/87 detections as of 2023/04/10\n  Page 36 of 45 \n\n  https://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/    \nCoincidentally, almost all of those same fields (first column) are referenced in our decrypted strings.\nSince POST request parameters are pretty specific -we were confident my sample was actually Amadey bot.\n   Page 42 of 45  \n\n+ lots of Virustotal fun :D    \nAt the time of this analysis (2023/04/10) -There is only 1/87 detections for the C2 on Virustotal\n   Page 43 of 45",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://embee-research.ghost.io/redline-stealer-basic-static-analysis-and-c2-extraction/"
	],
	"report_names": [
		"redline-stealer-basic-static-analysis-and-c2-extraction"
	],
	"threat_actors": [],
	"ts_created_at": 1775791262,
	"ts_updated_at": 1775791339,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c30ca5549a0d6b3c988912c7db9070ea31e0d649.pdf",
		"text": "https://archive.orkl.eu/c30ca5549a0d6b3c988912c7db9070ea31e0d649.txt",
		"img": "https://archive.orkl.eu/c30ca5549a0d6b3c988912c7db9070ea31e0d649.jpg"
	}
}