{
	"id": "a26cbef5-88bc-423a-bca4-5f794827f30c",
	"created_at": "2026-04-06T00:14:14.415313Z",
	"updated_at": "2026-04-10T03:22:39.395114Z",
	"deleted_at": null,
	"sha1_hash": "184dc79700c1f49338908858c27f32a96da1920b",
	"title": "N-W0rm analysis (Part 1)-Secuinfra GmbH",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 608754,
	"plain_text": "N-W0rm analysis (Part 1)-Secuinfra GmbH\r\nPublished: 2022-03-31 · Archived: 2026-04-05 16:54:33 UTC\r\nOverview\r\nFirst Stage\r\nStage 2 (RILSXDKOPJHN.TXT)\r\nStage 3\r\nSeries overview\r\nThis article shows our analysis of an N-W0rm sample. This appears to be a relatively new sample and according to Malware\r\nBazaar the first sample was seen on the 18th January 2022.\r\nWe got the sample from Malware Bazaar and hence do not know this sample is delivered. However, according to\r\n@executemalware, N-W0rm is delivered via Email.\r\nhttps://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/\r\nPage 1 of 6\n\nIf you want to follow along you can grab the sample from here:\r\nhttps://bazaar.abuse.ch/sample/1b976a1fa26c4118d09cd6b1eaeceafccc783008c22da58d6f5b1b3019fa1ba4/\r\nOverview\r\nBefore we start analyzing the sample, let’s take a closer look at the architecture of the compromise. The following figure\r\nshows the infection from the first stage to the final payload:\r\nFigure_1: Infection overview\r\nAs you can see in the figure above the infection ends with two 2 .NET binaries being dropped. Today’s article will describe\r\nall the way from the initial infection to that point. The analysis of the two binaries will be covered in our next article.\r\nFirst Stage\r\nThis sample is delivered as a VBS file that uses obfuscation to make static analysis harder and evade signatures. In our first\r\nstep, we will deobfuscate the VBS code and unveil the second stage. Below you will find the full code of the first stage. Line\r\n3 contains a rather long string that contains obfuscated PowerShell. As this long line would destroy the image, we replaced it\r\nfor aesthetic reasons.\r\nFigure_2:Initial VBS Code\r\nAs the original source only contains 5 lines, we can walk through the code line by line.\r\nHere some important strings are scrambled by replacing some chars with other chars and then at runtime reversing this\r\noperation. We can reverse this operation by using the python REPL.\r\nFigure_3: Deobfuscating the first line\r\nSo, the string will be deobfuscated to Wscript.SheLL. This means that this sample will send some commands to the\r\noperating system somewhere later. In the next line nothing interesting is happening, only the Wscript.SheLL object is\r\ncreated. Now line 3 is the interesting part as this line holds a long string containing obfuscated PowerShell code. As in line\r\n4, this code will also be executed, we will need to analyze it to fully understand this malware.\r\nFirst, as we can see in line 3, the full PowerShell Code is in one line. We normally don’t write code like this. To make this at\r\nleast a bit more readable, we need to space this code across multiple lines, like it is usually done. Semicolons (;) are used to\r\nindicate Line-Breaks. To use those to our advantage, we can paste this long line into a text editor and replace all semicolons\r\nwith a line-break (\\n) and a semicolon to keep the syntax.\r\nhttps://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/\r\nPage 2 of 6\n\nFigure_4: Beautified PowerShell Code\r\nThe first that pops into our eye is the IP address at the top. We will come back to it later, but for now, we found an important\r\nIOC.\r\nThis PowerShell snippet defines a function called CHGBGWUCPVSBXIVTHVKR in line 2. This function will be called\r\nin line 10 and the result is executed with IEX in line 11. So based on the call of IEX to the result of the function we can\r\nassume that the function decodes some further PowerShell that is executed. The string that will be deobfuscated is in line 10\r\nwhich is again a very long string, that we have replaced again here. To deobfuscate this string, the probably easiest thing we\r\ncould do is to copy this whole code snippet, replace the IEX in line 11 by echo and execute it in a PowerShell session.\r\nAlternately you could reimplement the function in e.g., Python and execute it there. We opted for the second method and\r\nreimplemented the logic on python. The screenshot below shows the code.\r\nFigure_5: Reimplementation of deobfuscation loop\r\nBy running our Python script to deobfuscate the long string, we get yet again an obfuscated PowerShell command.\r\nFigure_6: Output of the above Python script\r\nAgain, we can either enter this code into a PowerShell session or recreate the Script in e.g., Python, and execute it there.\r\nAgain, we choose to reimplement it in Python. The code can be seen below:\r\nFigure_7: Deobfusaction and output\r\nThis last decoded command brings us back to the beginning. Remember the IP address at the beginning? That’s the content\r\nof the variable $Hx. So, all this decoding only to download the file and execute it.\r\nStage 2 (RILSXDKOPJHN.TXT)\r\nhttps://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/\r\nPage 3 of 6\n\nOh Boy, the second stage looks a bit bulkier than the first one. This sample is fully packed with obfuscated strings and the\r\nusage of the replace function is rather dominant here. As this stage contains a bit more code than the previous one, we will\r\nnot copy-paste every single line here. If you want to truly understand what is happening here, we recommend that you\r\ndownload the sample yourself and follow along.\r\nWe will begin by decoding the first big block of obfuscated string right at the beginning:\r\nFigure_8: First Block of obfuscatated code in the second stage\r\nThe obfuscated string is in the second line. This string is first modified by calling replace() twice on it. Lastly, the string is\r\nthen deobfuscated by the loop in line 3. This loop might look strange at first, but it is rather simple.\r\nThis loop starts by calling -split on the string from line 2, i.e., converting the big string into a list based on a condition. This\r\nRegex-based condition searches for hex-characters and after every second occurrence, it splits. That means our iterate\r\nvariable always contains two hex-chars. These chars are then converted to ASCII and lastly concatenated. If we put all this\r\ntogether, we can again recreate this logic in python.\r\nFigure_9: Python based deobfusaction of the first block\r\nRunning this script yields the following output (I’ve added the variable $A1 from the first line for clearness):\r\nFigure_10: Full first deobfuscated block\r\nWe also get an interesting IOC here. So, the second stage starts by creating the directory\r\nC:\\ProgramData\\YHWZHLCQJHGQRFRHWZLCKSEUZIHLSJYATIODFBQPXTUSLQUEHVXQJENITGNZ,\r\nthen sleeps for 3 seconds.\r\nThe next two lines are important because we get our persistence indicators here. The newly created directory is set as\r\nStartUp, meaning it is executed each time the system is rebooted.\r\nLet’s go back to the code and take a look at the next block.\r\nThe next step is interesting. The Variable\r\n$ZEJOTRZCRVYEGGCGNZPLJDJROGPKEIGINPVGHOQXYSFSXBDOKJATKYHEPRNO will hold what\r\nappears to be HTML content, starting with a scripblock inserting VBScript code.\r\nFigure_11: Beginning of the scriptblock\r\nNow the function var_func() takes no arguments and its only purpose is to deobfuscate multiple strings it contains\r\nIn line 36 we can see that this will be an hta file that will be saved in the following path\r\nC:\\ProgramData\\YHWZHLCQJHGQRFRHWZLCKSEUZIHLSJYATIODFBQPXTUSLQUEHVXQJENITGNZ\\YHWZHLCQJHGQRFRHW\r\nFigure_12: Creation of an HTA file\r\nhttps://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/\r\nPage 4 of 6\n\nAs the content of this hta is only obfuscated by the usage of repeatably calls to replace() we will not show all steps taken to\r\ndeobfuscate but rather only the end result. The decoding ends with the scripts downloading the next stage from\r\nhttp://15.188.246[.]78/Q/SSSSSSHSJSJSA.txt and executing it.\r\nStage 3\r\nThis will be the final stage I promise!\r\nAgain, we are greeted with a bunch of obfuscated code. This time there are two big blocks of obfuscated code. Both strings\r\nstart with 4D5A, i.e., the MZ header.\r\nNext follows a function called vip(). While looking a bit confusing, it only decodes the base64 input.\r\nLastly, the code contains a huge block of obfuscated code, that is passed as input to the vip() function. Let’s pass this big\r\nchunk of code into the vip() function and take a look at what is happening. To make things maybe a bit easier to understand,\r\nI’ve pasted the decoded block below.\r\nFigure_13: Last block of code in third stage\r\nWe can see a new function called HB which takes a single parameter and appears to do some decoding. This function is\r\ncalled in lines 17 and 18. Further down below we recognize some important Strings. E.g., look at like 33 where we see\r\nchunks of .NET code to load binaries into memory. I assume that all the lines up from 19 are only responsible to load the\r\ntwo binaries that are decoded in lines 17 and 18. As for now, I’m not really interested in how the binary is loaded but rather\r\nonly the binaries, let’s dump them to disc by deobfuscating them. As we only really need the two strings that start with\r\n4D5A, the function to deobfuscate them, and then a single call to the function we can write the following code.\r\nFigure_14: Deobfusaction of the two PE’s\r\nRunning that code dumps two .NET binaries which will be analyzed in the next article.\r\nHost-Based Indicators:\r\nC:\\ProgramData\\YHWZHLCQJHGQRFRHWZLCKSEUZIHLSJYATIODFBQPXTUSLQUEHVXQJENITGNZ\\YHWZHLCQJHGQRFRHWZL\r\nMD5 (RILSXDKOPJHN.TXT) = 3d8ff7f298f64d9150a11e61dcbfd87b\r\nMD5 (SSSSSSHSJSJSA.txt) = 9ce8d6f136b95fab140bc8904666003a\r\nhttps://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/\r\nPage 5 of 6\n\nMD5 (1b976a1fa26c4118d09cd6b1eaeceafccc783008c22da58d6f5b1b3019fa1ba4.vbs) =\r\ne04e4cb7e410b885babba54cd59d5ae9\r\nMD5 (first_pe.exe) = 83dc22a1493e609b8b16f732e909418f\r\nMD5 (second_pe.exe) = 08587e04a2196aa97a0f939812229d2d\r\nNetwork-Based Indicators:\r\nhttp://15.188.246.78/Q/SSSSSSHSJSJSA.txt\r\nhttp://15.188.246.78/Q/RILSXDKOPJHN.TXT\r\nSource: https://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/\r\nhttps://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.secuinfra.com/en/techtalk/n-w0rm-analysis-part-1/"
	],
	"report_names": [
		"n-w0rm-analysis-part-1"
	],
	"threat_actors": [
		{
			"id": "08c8f238-1df5-4e75-b4d8-276ebead502d",
			"created_at": "2023-01-06T13:46:39.344081Z",
			"updated_at": "2026-04-10T02:00:03.294222Z",
			"deleted_at": null,
			"main_name": "Copy-Paste",
			"aliases": [],
			"source_name": "MISPGALAXY:Copy-Paste",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434454,
	"ts_updated_at": 1775791359,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/184dc79700c1f49338908858c27f32a96da1920b.pdf",
		"text": "https://archive.orkl.eu/184dc79700c1f49338908858c27f32a96da1920b.txt",
		"img": "https://archive.orkl.eu/184dc79700c1f49338908858c27f32a96da1920b.jpg"
	}
}