{
	"id": "70ce9193-1f16-4f31-90d7-d29f3540070a",
	"created_at": "2026-04-06T00:14:22.240038Z",
	"updated_at": "2026-04-10T03:33:22.335501Z",
	"deleted_at": null,
	"sha1_hash": "2844e1df21eaab3a0e899dc85bdd5dc4390f2815",
	"title": "Analyzing APT19 malware using a step-by-step method – CYBER GEEKS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6305160,
	"plain_text": "Analyzing APT19 malware using a step-by-step method – CYBER\r\nGEEKS\r\nPublished: 2020-12-26 · Archived: 2026-04-05 13:11:51 UTC\r\nSummary\r\nIn this blog post we’re presenting a full analysis of a DLL backdoor also reported publicly as Derusbi. This particular\r\npiece of malware is associated with the actor known as APT19 (Codoso, C0d0so, Sunshop Group).\r\nAPT19, also known as C0d0so or Deep Panda, is allegedly a Chinese-based threat group that targeted a lot of\r\nindustries in the past. FireEye reported that APT19 was active in 2017 when they used 3 different methods to\r\ncompromise targets: CVE-2017-0199 vulnerability, macro-enabled Microsoft Excel (XLSM) documents and an\r\napplication whitelisting bypass to the XLSM documents.\r\nThe malware registers itself as a service if it has run with administrator privileges, otherwise, it establishes\r\npersistence via the “Run” registry key. The main purpose of the malicious DLL is to gather information about the\r\nvictim’s environment such as username, hostname, IP address of the host, the CPU architecture, the default language\r\nfor the local system, the amount of physical memory, the amount of physical memory currently available, the\r\nprocessor name, the width and the height of the screen of the primary display monitor. The exfiltrated data is\r\nencrypted using a XOR operation (the 1-byte key seems to be randomly-chosen), and then encoded using the Base64\r\nalgorithm. There is a lot of network communication performed by the malware, however, due to the fact that the C2\r\nserver seems to be sinkholed now, we were not able to retrieve the file that was intended to be downloaded by the\r\nprocess.\r\nTechnical analysis\r\nSHA256: DE33DFCE8143F9F929ABDA910632F7536FFA809603EC027A4193D5E57880B292\r\nThe file analyzed in this blog post is a DLL that has the following export functions:\r\nFigure 1\r\nDebugCreate and DebugConnect entries have the same address and represent the starting point of the malicious\r\nactivity. The process computes a random string of 3 characters using GetTickCount API calls and the algorithm\r\nshown in figure 2:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 1 of 28\n\nFigure 2\r\nIt tries to delete a file/directory called \u003c3 random chars generated earlier\u003e.dll from System32 directory as shown\r\nbelow:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 2 of 28\n\nFigure 3\r\nBecause the file doesn’t exist at this time, it’s created using CreateFileA API and then deleted using DeleteFileA API.\r\nThis technique is used to confirm that it has enough rights to write files in the System32 directory:\r\nFigure 4\r\nThe malicious process retrieves process privilege details by calling GetTokenInformation with parameter type 0x14\r\n(TokenElevation):\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 3 of 28\n\nFigure 5\r\nMalware running with admin privileges\r\nNow it queries the “HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Svchost\\netsvcs”\r\nregistry value using RegQueryValueExA function:\r\nFigure 6\r\nThe list of services retrieved earlier is shown in the next figure:\r\nFigure 7\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 4 of 28\n\nThere is another service called WinHelpSrv that is added to this list. The “netsvcs” value is modified to reflect the\r\nchange by calling RegSetValueExA API:\r\nFigure 8\r\nThe file creates a new service named WinHelpSrv (Windows Helper Service) as follows:\r\nFigure 9\r\nThe description of the service is set to “This is windows helper service. Include windows update and windows error”:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 5 of 28\n\nFigure 10\r\nThe malicious DLL is registered as a service by adding the “ServiceDll” value that points to its location to the newly\r\ncreated service registry keys:\r\nFigure 11\r\nThe confirmation that the operation was successful:\r\nFigure 12\r\nThe process creates a batch file called \u003c10 random chars\u003e.bat (the same algorithm utilized before to generate the\r\nrandom letters is used):\r\nFigure 13\r\nThe content of the .bat file is presented below:\r\n@echo off\r\nnet start %1\r\ndel %0\r\nThe malicious file sets the priority class 0x100 (REALTIME_PRIORITY_CLASS) for the current process (this\r\nmeans that the current process has the highest possible priority):\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 6 of 28\n\nFigure 14\r\nAfter this operation, there is a call to SetThreadPriority that sets the priority 15\r\n(THREAD_PRIORITY_TIME_CRITICAL) for the current thread:\r\nFigure 15\r\nNow there are 2 SHChangeNotify API calls with the following parameters: 0x4 (SHCNE_DELETE), 0x5\r\n(SHCNF_PATH), the 3rd parameter is the path to rundll32.exe (because the dll was run using rundll32) and the name\r\nof the batch file, respectively, and the 4th parameter is 0. These calls have the purpose of notifying the system if\r\nrundll32.exe or the batch file is deleted:\r\nFigure 16\r\nThe batch file is executed using the WinExec function. Basically, it starts the WinHelpSrv service, and then the batch\r\nfile is deleted:\r\nFigure 17\r\nNow we’ll talk a bit about the ServiceMain export function that is called when the new service starts. The process\r\nregisters a function to handle service control requests by calling the RegisterServiceCtrlHandlerA function:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 7 of 28\n\nFigure 18\r\nThere is a call to SetServiceStatus function using the following SERVICE_STATUS structure: 0x10\r\n(SERVICE_WIN32_OWN_PROCESS), 0x2 (SERVICE_START_PENDING), 0 (no controls are accepted), 0\r\n(dwWin32ExitCode), 0 (dwServiceSpecificExitCode), 0x1 (dwCheckPoint) and 0xbb8 (3000 ms, the amount of time\r\nthat the service expects an operation to take before the next status update):\r\nFigure 19\r\nThe malicious process creates an unnamed event object by calling the CreateEvent function:\r\nFigure 20\r\nNow it follows another SetServiceStatus call by using the following SERVICE_STATUS structure: 0x10\r\n(SERVICE_WIN32_OWN_PROCESS), 0x4 (SERVICE_RUNNING), 0x1 (SERVICE_ACCEPT_STOP), 0\r\n(dwWin32ExitCode), 0 (dwServiceSpecificExitCode), 0 (dwCheckPoint) and 0 (dwWaitHint):\r\nFigure 21\r\nThe final operation of this section is to create a new thread using the CreateThread function. The same action will be\r\nperformed even if the process hasn’t run with admin privileges, as we’ll see later on:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 8 of 28\n\nFigure 22\r\nMalware running without admin privileges\r\nThe malware uses an anti-analysis technique by comparing the image path of the executable with rundll32.exe. It is\r\ndone to ensure that the file is not executed by a sandbox/analyst (it exits if that’s the case):\r\nFigure 23\r\nThe malware is made persistent by adding a new value called WinHelpSrv under the “Run” registry key. In our case,\r\nthis value points to the location of rundll32.exe because the DLL was run using this executable:\r\nFigure 24\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 9 of 28\n\nThe confirmation that the persistence was successfully established:\r\nFigure 25\r\nAs written before, a new thread is created to execute the same function mentioned when the malware has run with\r\nadministrator privileges. CreateThread API call is displayed in the next picture:\r\nFigure 26\r\nThere is a call to GetMessage API to retrieve messages from the thread’s message queue. If the message is 0x10\r\n(WM_CLOSE), 0x11 (WM_QUERYENDSESSION) or 0x16 (WM_ENDSESSION) the current function terminates\r\nits execution:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 10 of 28\n\nFigure 27\r\nThread activity – StartAddress address\r\nDuring the entire execution, the internet is emulated using Fakenet. We’ve observed multiple MultiByteToWideChar\r\nfunction calls used to convert character strings to UTF-16 (wide character) strings. One such call is shown below:\r\nFigure 28\r\nThe malware uses the WinHttpOpen function to initialize the use of WinHTTP functions. The user agent is hardcoded\r\nin the DLL file:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 11 of 28\n\nFigure 29\r\nThere is a call to WinHttpSetTimeouts function in order to set time-outs involved in HTTP transactions.\r\nnResolveTimeout, nConnectTimeout, nSendTimeout and nReceiveTimeout are set to 0x1D4C0 (120.000ms = 120\r\nseconds):\r\nFigure 30\r\nThe initial target server of an HTTP request is set to 106.185.43.96 on port 0x50 (80). The WinHttpConnect API call\r\nis displayed in figure 31.\r\nFigure 31\r\nThe process performs a GET request to the server mentioned above, with the target resource being /user/atv.html. The\r\npwszReferrer parameter is set to “http://www.google.com” and dwFlags is set to 0x100\r\n(WINHTTP_FLAG_BYPASS_PROXY_CACHE):\r\nFigure 32\r\nAfter the WinHttpOpenRequest call there is a WinHttpSendRequest function call. The HTTP request is intercepted by\r\nFakenet, and it replies with a fake response:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 12 of 28\n\nFigure 33\r\nNow the process is awaiting a response to the HTTP request by calling the WinHttpReceiveResponse function:\r\nFigure 34\r\nAfterward, the malicious file retrieves header information using WinHttpQueryHeaders API with 0x16\r\n(WINHTTP_QUERY_RAW_HEADERS_CRLF) parameter – receives all the headers returned by the HTTP server:\r\nFigure 35\r\nThere is a second WinHttpQueryHeaders API call with 0x20000013\r\n(WINHTTP_QUERY_FLAG_NUMBER|WINHTTP_QUERY_STATUS_CODE) parameter – the status code\r\nreturned by the HTTP server. It expects a status code of 200 (OK):\r\nFigure 36\r\nThe process uses the WinHttpQueryDataAvailable function to see how many bytes are available to be read with\r\nWinHttpReadData:\r\nFigure 37\r\nNext, there is a call to the WinHttpReadData function that is used to read data returned by the server:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 13 of 28\n\nFigure 38\r\nThe malicious process uses the WSAStartup function with 0x202 parameter (wVersionRequired) in order to use the\r\nWinsock DLL. The current directory for the process is changed to the location of the current executable\r\n(rundll32.exe):\r\nFigure 39\r\nGetAdaptersInfo API is utilized to find adapter information for the local machine. The function call is presented in\r\nthe next figure.\r\nFigure 40\r\nThe malware opens the “Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings” registry key by calling the\r\nRegCreateKeyExA function:\r\nFigure 41\r\nNow the user agent is extracted from the local host by calling the RegQueryValueExA function, as follows:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 14 of 28\n\nFigure 42\r\nThe GetNetworkParams function is utilized to obtain network parameters for the local machine. This information will\r\nbe exfiltrated as we’ll see later on:\r\nFigure 43\r\nGetComputerNameW and GetUserNameW APIs are used to retrieve the NetBIOS name of the local computer and the\r\nname of the user associated with the thread, respectively:\r\nFigure 44\r\ngethostname and gethostbyname functions are used to get the standard host name for the local machine and host\r\ninformation corresponding to the local host, respectively:\r\nFigure 45\r\nThe process verifies the operating system version by calling GetVersionExA function and then it checks if the process\r\nis running on a 64-bit machine by calling GetCurrentProcess and IsWow64Process APIs (this information is stored in\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 15 of 28\n\nthe buffer along with the hostname and username). The malware retrieves the default locale for the OS by calling\r\nGetLocaleInfoA function with the following parameters: 0x800 (LOCALE_SYSTEM_DEFAULT), 0xb\r\n(LOCALE_IDEFAULTCODEPAGE). The result is OEMCP 437 for English ( United States ) that is converted to hex\r\nand copied in the buffer that will be exfiltrated:\r\nFigure 46\r\nThere is a call to the GlobalMemoryStatusEx function in order to retrieve information about the physical and virtual\r\nmemory. The amount of physical memory and the amount of physical memory currently available are saved as 32-\r\nbits values to the buffer which will be exfiltrated. Also, the processor name is retrieved using a few cpuid instructions\r\n(“AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx”) and then copied to the same buffer. The malicious process\r\nextracts the width and the height of the screen of the primary monitor (in pixels) via 2 GetSystemMetrics calls, as\r\nfollows (these are copied to the same buffer as before):\r\nFigure 47\r\nAgain 12 random chars are generated via the same algorithm as presented before, and then the following URI is\r\nconstructed (data=12 random chars): “/money/ofcom-fines-nuisance-calls?0023528461146965\u0026data=qgvuclxxlgip”.\r\nThe function WinHttpOpen is called using the user agent extracted earlier from registry, “Mozilla/4.0 (compatible;\r\nMSIE 8.0; Win32)”:\r\nFigure 48\r\nAs before, the file calls the WinHttpSetTimeouts function using the parameters set as 120 seconds, and then it tries to\r\nconnect to the C2 server (www.microsoft-cache[.]com) on port 443:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 16 of 28\n\nFigure 49\r\nThe process performs a GET request using WinHttpOpenRequest and WinHttpSendRequest APIs:\r\nFigure 50\r\nIf the request is not successful, the process sleeps for 180 seconds, and then it tries again. The process retrieves\r\nheader information by calling WinHttpQueryHeaders with 0x16 (WINHTTP_QUERY_RAW_HEADERS_CRLF)\r\nparameter:\r\nFigure 51\r\nAs before, the malware extracts the status code and checks if it’s equal to 200 by calling WinHttpQueryHeaders API\r\nwith 0x20000013 (WINHTTP_QUERY_FLAG_NUMBER|WINHTTP_QUERY_STATUS_CODE) parameter:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 17 of 28\n\nFigure 52\r\nNow there is a call to the WinHttpQueryDataAvailable function, and then it reads the data returned by the C2 server\r\nusing WinHttpReadData API:\r\nFigure 53\r\nThe buffer containing the information that will be exfiltrated is XORed byte-by-byte with a one-byte key. The\r\nfollowing information belongs to the buffer: the C2 server address, hostname, username, IP address represented as\r\nhex values, 01 constant because the process is running on a 64-bit environment, the result of GetLocaleInfoA call\r\n(0x1b5 = 437 in our case), the amount of physical memory represented as a 32-bit value, the amount of physical\r\nmemory currently available represented as a 32-bit value, the processor name, the width of the screen of the primary\r\ndisplay monitor represented as a 32-bit value (0x780 = 1920 in our case) and the height of the screen of the primary\r\ndisplay monitor represented as a 32-bit value (0x438 = 1080 in our case):\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 18 of 28\n\nFigure 54\r\nAfter the operation is complete, the buffer looks like in the following picture:\r\nFigure 55\r\nThe malware developers have written their implementation of the Base64 algorithm rather than relying on Windows\r\nAPIs. The following picture presents a part of the assembly code corresponding to it:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 19 of 28\n\nFigure 56\r\nThe encrypted buffer is encoded with the Base64 algorithm:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 20 of 28\n\nFigure 57\r\nAs before, there is a WinHttpOpen API call (same user agent as the last time) followed by a WinHttpSetTimeouts\r\nfunction call, and then it tries to connect to www.microsoft-cache[.]com on port 443 using WinHttpConnect API. The\r\nmalware performs a POST request by calling the WinHttpOpenRequest function (as before, the data parameter\r\ncontains randomly-generated characters):\r\nFigure 58\r\nThe encrypted + encoded buffer is exfiltrated to the C2 server via a WinHttpWriteData function call, as shown below:\r\nFigure 59\r\nThe malicious process performs 2 WinHttpQueryHeaders function calls: 1st one has 0x16\r\n(WINHTTP_QUERY_RAW_HEADERS_CRLF) parameter and the 2nd one has 0x20000013\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 21 of 28\n\n(WINHTTP_QUERY_FLAG_NUMBER|WINHTTP_QUERY_STATUS_CODE) parameter. It checks out the status\r\ncode and ensures that it’s 200. The thread continues by calling WinHttpQueryDataAvailable and WinHttpReadData\r\nAPIs to retrieve the server’s response. The malware performs another GET request to the C2 server:\r\nFigure 60\r\nThe same steps as before are repeated one more time: 2 WinHttpQueryHeaders calls followed by\r\nWinHttpQueryDataAvailable and then WinHttpReadData in order to read the data sent by the server. As mentioned in\r\nthe Unit42 article at https://unit42.paloaltonetworks.com/new-attacks-linked-to-c0d0s0-group/, the server’s response\r\nshould contain a “background-color” parameter followed by “#” and an offset. The offset is read, converted to an\r\ninteger using the atoi function, and then divided by 100, as shown in figure 61:\r\nFigure 61\r\nThe idea is that the malware reads the data found at the position equal to offset/100. In our case, we’ve modified the\r\nresponse to contain “#28300” which translates to an offset of 28300 (the position will be 28300/100 = 283). The\r\nfollowing picture reveals the fact that the process reads the data found at that specific position (0x11b = 283):\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 22 of 28\n\nFigure 62\r\nAccording to the same article, the first 4 bytes represent the total length, and the remaining data would be Base64-\r\nencoded. Indeed we were able to identify the function where the server’s response is Base64-decoded:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 23 of 28\n\nFigure 63\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 24 of 28\n\nFigure 64\r\nAt the time of analysis, no live response has been provided by the C2 server. According to the Unit42 article, the\r\nserver would respond with a DLL file with 4 exports: StartWorker, StopWorker, WorkerRun and DllEntryPoint. Even\r\nif we didn’t receive a valid response from the server, we were able to find out that the malicious process allocates a\r\nnew memory area in order to write the DLL code inside:\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 25 of 28\n\nFigure 65\r\nThe new area of memory has to be executable because the potential DLL has to run, and that’s why the malware uses\r\nVirtualProtect in order to change the protection of the area:\r\nFigure 66\r\nAfter the malicious code would be written in the new memory location, the process would pass the execution flow to\r\nthe new DLL file, as shown in the figure below:\r\nFigure 67\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 26 of 28\n\nReferences\r\nUnit42 report: https://unit42.paloaltonetworks.com/new-attacks-linked-to-c0d0s0-group/\r\nVirusTotal link:\r\nhttps://www.virustotal.com/gui/file/de33dfce8143f9f929abda910632f7536ffa809603ec027a4193d5e57880b292/detection\r\nMSDN: https://docs.microsoft.com/en-us/windows/win32/api/\r\nFakenet: https://github.com/fireeye/flare-fakenet-ng\r\nFireEye: https://www.fireeye.com/current-threats/apt-groups.html#apt19\r\nINDICATORS OF COMPROMISE\r\nC2 domain: www.microsoft-cache[.]com\r\nC2 IP address: 106.185.43.96\r\nSHA256: DE33DFCE8143F9F929ABDA910632F7536FFA809603EC027A4193D5E57880B292\r\nURLs: 106.185.43.96/user/atv.html\r\nwww.microsoft-cache[.]com:443/money/ofcom-fines-nuisance-calls?0023528460592137\u0026data=\u003c12 random chars\u003e\r\nwww.microsoft-cache[.]com:443/world/video/shrien-dewani-arrives-uk-murder-trial-collapses-video?\r\n0023528461146965\u0026data=\u003c12 random chars\u003e\r\nwww.microsoft-cache[.]com:443/lifeandstyle/marmalade-paddington-sales-up-making-drinking?\r\n0023528460592137\u0026data=\u003c12 random chars\u003e\r\nYara rules for detecting the threat\r\nrule APT19_1 {\r\n meta:\r\n author = \"CyberMasterV\"\r\nDate = \"2020-12-26\"\r\n strings:\r\n$s1 = \"http://www.google.com\" wide ascii\r\n$s2 = \"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Chro\r\n$s3 = \"%s?%016I64d\u0026data=%s\"\r\n$s4 = \"DebugCreate\"\r\n$s5 = \"DebugConnect\"\r\n condition:\r\n4 of them\r\n}\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 27 of 28\n\nrule APT19_2 {\r\n meta:\r\n author = \"CyberMasterV\"\r\n Date = \"2020-12-26\"\r\n strings:\r\n $s1 = \"DbgEng.Dll\" wide ascii\r\n $s2 = \"Windows Helper Service\"\r\n $s3 = \"WinHelpSrv\"\r\n$s4 = \"KBKBKBKBKBKB\"\r\n condition:\r\n 3 of them\r\n}\r\nSource: https://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nhttps://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/\r\nPage 28 of 28",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://cybergeeks.tech/analyzing-apt19-malware-using-a-step-by-step-method/"
	],
	"report_names": [
		"analyzing-apt19-malware-using-a-step-by-step-method"
	],
	"threat_actors": [
		{
			"id": "1f3cf3d1-4764-4158-a216-dd6352e671bb",
			"created_at": "2022-10-25T15:50:23.837615Z",
			"updated_at": "2026-04-10T02:00:05.322197Z",
			"deleted_at": null,
			"main_name": "APT19",
			"aliases": [
				"APT19",
				"Codoso",
				"C0d0so0",
				"Codoso Team",
				"Sunshop Group"
			],
			"source_name": "MITRE:APT19",
			"tools": [
				"Cobalt Strike"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "64ca1755-3883-4173-8e0a-6e5cf92faafd",
			"created_at": "2022-10-25T15:50:23.636456Z",
			"updated_at": "2026-04-10T02:00:05.389234Z",
			"deleted_at": null,
			"main_name": "Deep Panda",
			"aliases": [
				"Deep Panda",
				"Shell Crew",
				"KungFu Kittens",
				"PinkPanther",
				"Black Vine"
			],
			"source_name": "MITRE:Deep Panda",
			"tools": [
				"Mivast",
				"StreamEx",
				"Sakula",
				"Tasklist",
				"Derusbi"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "0639667a-fb3f-43d9-a38c-6c123fd19c7f",
			"created_at": "2022-10-25T16:07:23.335869Z",
			"updated_at": "2026-04-10T02:00:04.547702Z",
			"deleted_at": null,
			"main_name": "APT 19",
			"aliases": [
				"APT 19",
				"Bronze Firestone",
				"C0d0so0",
				"Checkered Typhoon",
				"Codoso",
				"Deep Panda",
				"G0009",
				"G0073",
				"Operation Kingslayer",
				"Red Pegasus",
				"Sunshop Group",
				"TG-3551"
			],
			"source_name": "ETDA:APT 19",
			"tools": [
				"Agentemis",
				"C0d0so0",
				"Cobalt Strike",
				"CobaltStrike",
				"Derusbi",
				"EmPyre",
				"EmpireProject",
				"Fire Chili",
				"PowerShell Empire",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "46a151bd-e4c2-46f9-aee9-ee6942b01098",
			"created_at": "2023-01-06T13:46:38.288168Z",
			"updated_at": "2026-04-10T02:00:02.911919Z",
			"deleted_at": null,
			"main_name": "APT19",
			"aliases": [
				"DEEP PANDA",
				"Codoso",
				"KungFu Kittens",
				"Group 13",
				"G0009",
				"G0073",
				"Checkered Typhoon",
				"Black Vine",
				"TEMP.Avengers",
				"PinkPanther",
				"Shell Crew",
				"BRONZE FIRESTONE",
				"Sunshop Group"
			],
			"source_name": "MISPGALAXY:APT19",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "f2ce5b52-a220-4b94-ab66-4b81f3fed05d",
			"created_at": "2025-08-07T02:03:24.595597Z",
			"updated_at": "2026-04-10T02:00:03.740023Z",
			"deleted_at": null,
			"main_name": "BRONZE FIRESTONE",
			"aliases": [
				"APT19 ",
				"C0d0s0",
				"Checkered Typhoon ",
				"Chlorine ",
				"Deep Panda ",
				"Pupa ",
				"TG-3551 "
			],
			"source_name": "Secureworks:BRONZE FIRESTONE",
			"tools": [
				"9002",
				"Alice's Rabbit Hole",
				"Cobalt Strike",
				"Derusbi",
				"PlugX",
				"PoisonIvy",
				"PowerShell Empire",
				"Trojan Briba",
				"Zuguo"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434462,
	"ts_updated_at": 1775792002,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2844e1df21eaab3a0e899dc85bdd5dc4390f2815.pdf",
		"text": "https://archive.orkl.eu/2844e1df21eaab3a0e899dc85bdd5dc4390f2815.txt",
		"img": "https://archive.orkl.eu/2844e1df21eaab3a0e899dc85bdd5dc4390f2815.jpg"
	}
}