{
	"id": "de0f14d7-6a01-46fd-a445-23c02c072a20",
	"created_at": "2026-04-06T01:30:35.776487Z",
	"updated_at": "2026-04-10T13:11:55.304099Z",
	"deleted_at": null,
	"sha1_hash": "3b1884097c8104eed2d803a0d952351398378907",
	"title": "Analysis and Reversing of srvnet2.sys",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1358848,
	"plain_text": "Analysis and Reversing of srvnet2.sys\r\nBy darksys0x\r\nArchived: 2026-04-06 00:20:33 UTC\r\n“srvnet2.sys” is a rootkit that enumerates (usermode) processes, and injects a shell code into a process. The rootkit\r\nlooks up the name of the process while enumerating to avoid injecting into some processes. If the process name\r\nmatches with the list of names in the rootkit, then it will skip the process and look for others, when it finds a process\r\nname that is not blacklisted, then the shell code is injected into the process.\r\nThe rootkit uses XOR encryption to hide strings such as function names which are used to get the function\r\naddresses. The win API functions are not called directly, so they don’t appear in the imports section. There’s a\r\ncustom function in the rootkit that retrieves the addresses of functions at runtime to call them. The following\r\nscreenshot shows an example of such behavior:\r\nNote: The function names of the rootkit in “IDA” for all below figures have been modified for better\r\nunderstanding.\r\nFigure 1: This function is like a wrapper for “KeStackAttachProcess”.\r\nIn Figure 1, “KeStackAttachProcessStr” function is called to get the function name string, then it is passed to\r\n“GetFunctionAddress” call which will return the address. At the end of the screenshot (line 11),\r\n“KeStackAttachProcess” is called by its address.\r\nThe function “KestackAttachProcessStr” uses XOR encryption, refer to Figure 2.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 1 of 26\n\nFigure 2: This function returns a pointer to string “KeStackAttachProcess”.\r\nFigure 3: Decryption of string “KeStackAttachProcess” using XOR algorithm.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 2 of 26\n\nIn figure3 the reversed XOR algorithm as shown in action that the rootkit uses this algorithm all over place to hide\r\nthe strings, although the strings are decrypted at runtime.\r\nFull technical analysis and reverse “srvnet2.sys”\r\nIn this section, the complete behavior of the rootkit is depicted.\r\nThe rootkit initiates by checking whether the safe boot mode is disabled. This check is crucial because the rootkit is\r\nunlikely to function properly in safe boot mode due to the imposed restrictions. If safe boot mode is disabled, the\r\nrootkit proceeds to invoke the “CreateKeThreadForInjectingShellcode” function. This function is responsible for\r\ncreating a kernel thread specifically designed to inject the shellcode into user-mode processes, as illustrated in\r\nFigure 4. By creating a kernel thread dedicated to this task, the rootkit ensures efficient and controlled injection of\r\nthe shellcode across multiple processes in the user-mode space. This injection mechanism enables the rootkit to gain\r\ncontrol and execute arbitrary code within those processes, allowing for various malicious activities or privilege\r\nescalation.\r\nFigure 4: entre point of the rootkit\r\nIn figure 5, the function creates a new thread for the shell code injection. When the thread returns, the handle to the\r\nthread is closed.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 3 of 26\n\nFigure 5: Code of “CreateKeThreadForInjectingShellcode”\r\nIn Figure 6, the “StartRoutine” function serves as the entry point for the new kernel thread. This function\r\nimplements a loop that iterates through all running processes at a 5-second interval, attempting to identify a suitable\r\nprocess ID for injecting the shellcode. The shellcode itself is located in the (.data section) of the rootkit.\r\nFurthermore, in Figure 8, line 24 showcases the “AllocMemWithDataInProcess_0” function. This function is\r\nresponsible for allocating memory on the heap within the target process. It reserves a chunk of memory and then\r\ncopies the shellcode into this allocated memory region. By doing so, the shellcode becomes effectively placed\r\nwithin the target process’s memory space, ready for execution. It’s important to note that the shellcode decryption\r\ntakes place in the “decryptShellCode” function, called at runtime. This function is responsible for decrypting the\r\nshellcode, allowing it to be executed in its original form within the target process.\r\nThe “ExecuteShellCode” function in line 26 will execute the shell code in the target\r\nusermode process.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 4 of 26\n\nFigure 6: The entry point function for the new kernel thread\r\n“GetTargetProcessId” is called in “StartRoutine”, it will enumerate through all running usermode processes, then\r\ncompare the process names with hardcoded names, if any of the name matches, the process is ignored, refer to\r\nFigure 7. The hardcoded process names are:\r\ncsrss.exe\r\nsmss.exe\r\nservices.exe\r\nwinlogon.exe\r\nvmtoolsd.exe\r\nvmware\r\nlsass.exe\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 5 of 26\n\nFigure 7: pseudocode of GetTargetProcessId\r\nIn Figure 8, the hardcoded process names have been decrypted by running their XOR algorithm in IDA. The\r\nprocesses with these names are ignored by the rootkit.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 6 of 26\n\nFigure 8: Decrypted names of process names in the rootkit\r\nAfter making sure the process name does not match with the ignored names, the rootkit will check the SID of the\r\nprocess token, refer to Figure 9. The root looks for process tokens with SID “S-1-5-18” because this SID is for local\r\nsystem account that is used by the operating system. This will give the shellcode full privileges when it is loaded in\r\nthe usermode space. For more details, refer to section “The rootkit act privilege escalation”.\r\nMoreover, the rootkit checks for peb lock and then checks whether the process is critical or not, which means if the\r\nprocess will break on termination or not, and finally, the process id is returned.\r\nFigure 9: code of target processID\r\nIn figure 9, the ExecuteShellCode function has another shell code on the stack, however, it is very small with only a\r\nfew instructions:\r\n- 48 BA 00 00 00 00 00 00 00 00 | mov rdx, 0 \u003c--- second argument (DelayInterval)\r\n- B1 01 | mov c1, 1 \u003c--- first argument (Alertable)\r\n- 48 B8 00 00 00 00 00 00 00 00 | mov rax, 0 \u003c--- address of NtDelayExecution function\r\n- FF D0 | call rax \u003c--- call NtDelayExecution function\r\nThese instructions are used for calling “NtDelayExecution” function:\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 7 of 26\n\nNTSYSAPI NTSTATUS NTAPI NtDelayExecution(\r\nIN BOOLEAN Alertable, // take one byte\r\nIN PLARGE_INTEGER DelayInterval // pointer take 8 bytes\r\n);\r\nThe 8 zeros in the first instruction mov rdx, 0 are replaced by the DelayInterval, and the 8 zeroes in the 3rd\r\ninstruction mov rax, 0 are replaced by the address of “NtDelayExecution” function, moreover, the\r\n‘NtDelayExecution’ function is used to halt a thread in the target usermode process. This will allow the rootkit to\r\nadd an APC ( Asynchronous Procedure Call) to the queue, so the thread can execute it. Find more detailes about\r\nAPC “https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/types-of-apcs”.\r\nFigure 9: Second shell code buffer.\r\nSince the second argument of “NtDelayExecution” is a pointer, it needs an address to a value in usermode space.\r\nThe rootkit will allocate memory in the usermode space of 8 bytes in function “AllocMemWithDataInProcess_0”,\r\nrefer Figure 10.\r\n“SetBufferDataStr” function will first allocate 24 bytes memory in kernel for the shellcode, then the address of the\r\nallocated memory (8 bytes usermode memory) is copied to the shell code buffer and the address of\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 8 of 26\n\n“NtDelayExecution” is also copied to the shellcode, refer Figure 9.\r\nThe memory allocated by “SetBufferDataStr” resides in kernel space, so it cannot be accessed in usermode. The\r\nrootkit will allocate 24 bytes again, but this time it will be allocated in the usermode space of the target process in\r\nfunction “AllocMemWithDataInProcess_0”.\r\nA new thread in suspended state is created in the usermode process in function “CreateThreadInProcess” in order\r\nto execute the 24 byte shellcode later.\r\nFigure 10: Calling “NtDelayExecution” function.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 9 of 26\n\nFigure 11: “allocationAddress” is copied the first 8 bytes, “funcAddress”is copied to the second 8 bytes.\r\nIn function “sub_1400061A8”, the thread handle is used to reference the object, which is later used for initializing\r\nAPC. Refer figure 12.\r\nFigure 12: Fetches the object for a thread by its handle in second argument\r\nIn Figure 13, the “KeInitializeApc” function will initialize the kernel APC since the 7th argument ApcMode is zero\r\nas example: http://www.codewarrior.cn/ntdoc/winnt/ke/KeInitializeApc.htm\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 10 of 26\n\nhttp://pravic.github.io/winapi-kmd-rs/doc/km/basedef/enum.KPROCESSOR_MODE.html\r\nNote: this is not official used in Microsoft Document.\r\nFigure 13: prototype of “KeInitializeApc”.\r\nDepending on the ApcMode, NormalRoutine parameter in “KeInitializeApc” will be either usermode or kernel\r\nmode routine.\r\nenum KPROCESSOR_MODE\r\n{\r\nKernelMode = 0,\r\nUserMode = 1,\r\n}\r\nFurthermore, after the APC is initialized, the “KeInsertQueueApc” function is used to insert the APC into the\r\nqueue. If the insertion is successful, the thread that was previously created in user-mode space will be resumed by\r\ninvoking the “NtResumeThread” function. This action triggers the execution of the 24-byte shellcode within the\r\ntarget process.\r\nSubsequently, the larger shellcode (which is the second argument of the “ExecuteShellCode” function) will be\r\nexecuted by another APC. This occurs through the NormalRoutine APC, denoted as “sub_140006840”, which is\r\npassed to the “KeInitializeAPC” function, as shown in Figure 14. The NormalRoutine APC, when triggered, will\r\nexecute the big shellcode within the target process.\r\nThis sequence of actions allows for the staged execution of the shellcode, starting with the initial 24-byte shellcode\r\nand followed by the larger, more complex shellcode. The use of APCs provides a mechanism to execute code within\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 11 of 26\n\nthe target process while maintaining control and coordination from the user-mode space.\r\nFigure 14: Executing the kernel mode APC\r\nFurthermore, in figure 15, When the kernel APC “sub_140006840” is called, it will initialize the usermode APC,\r\nwhich is the big shellcode and place it in the queue “KeInsertQueueApc”. This shellcode will unpack a .NET\r\nexecutable in memory and execute it. It has anti-debugging code to prevent debuggers from attaching to its process.\r\nFigure 15: The APC function that will add usermode APC to the queue “KeInsertQueueApc”.\r\nThe rootkit act privilege escalation\r\nIn Figure 9, the rootkit checks for token SID “S-1-5-18” since it belongs to local system account which is used by\r\nthe operating system. This allows the rootkit to find a process with full privileges for injecting the shellcode.\r\n“IsProcessSID_S_1_5_18” function will look up the process object by its id, then it calls “SID_S_1_5_18”\r\nfunction as shown in figure 16.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 12 of 26\n\nFigure 16: Check whether the SID of a process token is S-1-5-18\r\nIn Figure 17, the function “IsSID_S_1_5_18” follows these steps:\r\n1. It initializes a Unicode string.\r\n2. The function then calls “GetProcessTokenSID” and passes the address of the Unicode string as the second\r\nargument. This function retrieves the SID (Security Identifier) associated with the process token and stores it\r\nin the Unicode string.\r\n3. After obtaining the process token’s SID, it is compared with the string “S-1-5-18” for a match.\r\nThis comparison is significant because “S-1-5-18” represents the well-known SID for the Local System account in\r\nWindows. By comparing the retrieved SID with this string, the function determines if the current process is running\r\nunder the Local System account. If there is a match, it indicates that the process has elevated privileges and can\r\nperform certain privileged operations or access sensitive resources.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 13 of 26\n\nFigure 17: Get token SID and compare it with string “S-1-5-18”\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 14 of 26\n\nFigure 18: Decrypt of “S-1-5-18” local system account\r\n“GetProcessTokenSID” function first references the primary token, gets a handle to it and calls “GetTokenSID”,\r\nrefer to Figure 19. “GetTokenSID”, as the name indicates, it will query the token information via\r\n“NtQueryInformationToken”, and get the SID, then converts the SID to Unicode string format.\r\nFigure 19: Pseudocode of GetProcessTokenSID and GetTokenSID\r\nMain Shell Code\r\nThe main shellcode is encrypted and resides in the “.data section” of the rootkit. In Figure 6, the “StartRoutine”\r\nfunction is responsible for calling the “decryptShellcode” function, which utilizes the XOR algorithm to decrypt\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 15 of 26\n\nthe shellcode. The address of the encrypted shellcode is passed as the second argument to the “decryptShellcode”\r\nfunction. This allows the function to locate the encrypted shellcode within the .data section and perform the\r\nnecessary decryption process.\r\nvoid __fastcall decryptShellCode(char key, _BYTE *shellcode, unsigned __int64 size)\r\n{\r\nunsigned __int64 i; // [rsp+20h] [rbp-18h]\r\nif ( shellcode \u0026\u0026 MmIsAddressValid(shellcode) \u0026\u0026 size ) {\r\nfor ( i = 0i64; i \u003c size; ++i )\r\nshellcode[i] ^= key;\r\n}\r\n}\r\nThe rootkit decrypts the shellcode by calling executing:\r\ndecryptShellCode(57, shell_code, 0x74344ui64);\r\nThe XOR algorithm utilizes the first argument as the key. The second argument represents the address of the\r\nshellcode within the .data section, while the third argument denotes the size of the shellcode. There are several\r\napproaches to executing this shellcode:\r\n1. Running the rootkit to execute the shellcode.\r\n2. Dumping the shellcode from rootkit file, loading it to a program, decrypting the shellcode, then executing it\r\nby creating a thread.\r\nTo proceed with option 2, where the shellcode is executed by creating a new thread, the shellcode needs\r\nto be extracted and saved to a file. This can be accomplished manually by opening the rootkit file in a hex\r\neditor and searching for the specific starting bytes of the shellcode, as indicated in Figure 20. Once the\r\nshellcode is identified, it can be selected and saved to a separate file for further analysis or execution.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 16 of 26\n\nFigure 20: The shellcode in .data section\r\nThe first 10 bytes of the shellcode can be searched in a hex editor to find the shellcode in the rootkit file.\r\nD1 B9 20 3E 39 B9 20 3E 39 0D\r\nFigure 21: shellcode offsite in the rootkit through HexEdito\r\nFurthermore, the rootkit file has an offset of 0xAC00 for the shellcode. By removing the bytes preceding this offset,\r\nthe modified file can be saved as “srvnet2_block.bin,” where the first byte represents the shellcode. Subsequently, a\r\nprogram needs to be developed to decrypt the shellcode within the newly created file and execute it by spawning a\r\nnew thread.\r\nIn Figure 22, memory is allocated for the shellcode file, then it is loaded into memory using C file functions, the\r\nshellcode in memory is then decrypted using XOR algorithm. A new thread is created by calling “ CreateThread”\r\nfunction.\r\nOn execution of the shellcode, it unpacks a .NET PE file which can be found by searching for the DOS stub string\r\n“This program cannot be” in cheat engine, refer Figure 23. The memory region of this PE file when dumped via\r\nx64dbg can be opened with a hex editor and the bytes before the PE file can be removed. This should allow\r\nexecuting of the PE file, and it can be opened in dnSpy since it’s a .NET PE file.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 17 of 26\n\nFigure 22: Code for running the shellcode\r\nFigure 23: Running the shellcode using the C program and finding the unpacked .NET PE\r\n‘\r\nAnalysis of unpacked .NET PE malware\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 18 of 26\n\nThe dumped .NET PE malware in figure 23 is programmed in C#. the malware contains back door in, moreover, the\r\nmalware listens on multiple IIS site bindings and waits for the attacker to send http requests into the victim\r\nmachine.\r\nHowever, this part will continue brief behavior analysis.\r\nThe malware has full capability such as Download, Upload, “RunDll”, Execute commands in “cmd”. In Figure 24,\r\nthe malware calls the function “Heartreport_they.Jar_avocado_enhance” to get a list of URLs to start listening\r\non.\r\nFigure 24: Entry point of the .NET malware where it starts listening for HTTP requests\r\nThe URL for heartbeat is dynamically generated by invoking the “Heartreport_they.Jar_avocado_enhance”\r\nfunction. In Figure 25, you can observe the code line responsible for creating the URL.\r\nhashSet.Add(string.Format(Heartreport_they.caution_degree(),binding.Protocol,binding.EndPoint.Port,arg).ToLowe\r\nThe function Heartreport_they.caution_degree() will return a URL template in the format “{0}://+:{1}/{2}/”.\r\nThe first argument represents the protocol, the second argument represents the port, and the third argument\r\nrepresents the path name. The URL template can be used to construct URLs such as “http://+:80/someNameHere/”\r\nor “http://+/someNameHere/”.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 19 of 26\n\nFigure 25: Get a list of URLs for HTTPListener\r\nMoreover, once the “HTTPListener” starts listening, upon receiving HTTP requests from the attacker, the callback\r\nfunction “Heartreport_they.Oak_reject_deny” will be called.\r\nFigure 26: HTTPListener callback\r\nIn Figure 27, the callback function calls “Chiefdice” function which calls “ProcessRequest” function. The\r\n“ProcessRequest” function is responsible for handling the packets. It will read the packet and perform the task\r\nspecified in the packet. There are 4 possible capabilities:\r\nCommand\r\nUpload\r\nDownload\r\nRunDll\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 20 of 26\n\nFigure 27: Trace of the callback function used by HTTPListener\r\nIn Figure 28, The “ProecssRequest” function will first check whether the request data is empty or not, then it will\r\ndecrypt the data via “DecrpytPacket” function (Base64 and XOR algorithm). The “wastebuzz” constructor will\r\nparse the header of the data, and all 4 capabilities have the same header. The header looks like this:\r\no 4 bytes: attack request type\r\no 4 bytes: attack request string size\r\no X bytes: attack request string\r\no 4 bytes: request data size\r\no X bytes: request data\r\nThe “attack request type” is an enum, the possible values are:\r\nenum AttackRequestType {\r\nCommand = 1,\r\nUpload = 2,\r\nDownload = 3,\r\nRunDll = 4\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 21 of 26\n\n};\r\nFigure 28: ProcessRequest function for handling HTTPListener callback requests\r\nThe “attack request string” is the name of the capability, for instance, for download capability, it is “Download”.\r\nThe “request data” is the data of the capability. This data will have a different structure depending on the “attack\r\nrequest type”.\r\nCommand capability\r\nIn Figure 29, the parser for command capability is invoked before the “command” function. The structure of the\r\ncode can be represented as follows:\r\nCommand Capability Parser\r\n |\r\n +-- Parse command capability parameters\r\n |\r\n +-- Verify command capability permissions\r\n |\r\n +-- Invoke the \"command\" function with the parsed parameters\r\nCommand Function\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 22 of 26\n\n|\r\n +-- Execute the specified command based on the parsed parameters\r\nIn general, the parser for command capability is responsible for parsing the parameters related to the command\r\ncapability, such as the command name, options, and arguments. It ensures that the provided parameters are valid and\r\nformatted correctly. Once the parameters are parsed, the parser verifies the permissions associated with the\r\ncommand capability. Finally, with the parsed and verified parameters, the parser calls the “command” function,\r\npassing the parsed parameters as arguments. The “command” function then performs the execution of the specified\r\ncommand, utilizing the parsed parameters to carry out the desired functionality.\r\nThis structure enables the rootkit to handle command capabilities effectively, ensuring proper parsing, permission\r\nvalidation, and execution of commands based on the provided parameters.\r\no 4 bytes: file name size\r\no X bytes: file name string\r\no 4 bytes: file arguments size\r\no X bytes: file arguments string\r\nThere are two strings in the command structure: file name and file arguments. By Following the trace of the\r\n“command” function, the function “ExecuteShell” is called, refer Figure 30. The “ExecuteShell” function take two\r\nparameters file name and file arguments, respectively. This function will execute the shell code command supplied\r\nby the attacker.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 23 of 26\n\nFigure 29: Command capability parser\r\nFigure 30: pseudocode of ExecuteShell function\r\nUpload capability\r\nThis capability allows the attacker to upload files to the victim machine. The parser of the upload capability is\r\nshown in Figure 31. The structure looks like this:\r\no 4 bytes: file path size\r\no X bytes: file path string\r\no 4 bytes: file data size\r\no X bytes: file data array\r\nIn Figure 32, the “Upload” function will call the function “WriteAllBytes” which will create the file and write all\r\nbytes to that file on the victim machine.\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 24 of 26\n\nFigure 31: Upload capability parser\r\nFigure 32: Upload function pseudocode\r\nDownload capability\r\nThis capability allows the attacker to download files from the victim machine. This capability doesn’t have a special\r\nparser since the “request data” in the header is the file path string, and it’s used to read the target file from disk via\r\n“RedAllBytes” function and then sent back to the attacker in response, refer Figure 33.\r\nFigure 33: Download capability pseudocode\r\nRundll capability\r\nThis capability allows the attacker to load and run dll files in the memory of the malware process. The dll file is\r\nsupplied in the request data. The structure of this capability is the same as “Upload” capability since the same\r\nfunction is used to parse the request data. The structure looks like this:\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 25 of 26\n\no 4 bytes: file path size\r\no X bytes: file path string\r\no 4 bytes: file data size\r\no X bytes: file data array\r\nIoCs\r\nsrvnet2.sys:\r\nMD5: 4dd6250eb2d368f500949952eb013964\r\nSHA-1: 6802e2d2d4e6ee38aa513dafd6840e864310513b\r\nSHA-256: f6c316e2385f2694d47e936b0ac4bc9b55e279d530dd5e805f0d963cb47c3c0d\r\nhttps://www.virustotal.com/gui/file/f6c316e2385f2694d47e936b0ac4bc9b55e279d530dd5e805f0d963cb47c3c0d\r\nSource: https://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nhttps://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/\r\nPage 26 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://darksys0x.net/Analysis-and-Reversing-of-srvnet2sys/"
	],
	"report_names": [
		"Analysis-and-Reversing-of-srvnet2sys"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439035,
	"ts_updated_at": 1775826715,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3b1884097c8104eed2d803a0d952351398378907.pdf",
		"text": "https://archive.orkl.eu/3b1884097c8104eed2d803a0d952351398378907.txt",
		"img": "https://archive.orkl.eu/3b1884097c8104eed2d803a0d952351398378907.jpg"
	}
}