{
	"id": "a285d463-5a07-4e00-9141-e99bc422ad7c",
	"created_at": "2026-04-06T00:11:11.060861Z",
	"updated_at": "2026-04-10T03:25:09.158181Z",
	"deleted_at": null,
	"sha1_hash": "7b3757391a41b013fc481e60e1a80d6eec372065",
	"title": "A detailed analysis of ELMER Backdoor used by APT16 – CYBER GEEKS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 8378597,
	"plain_text": "A detailed analysis of ELMER Backdoor used by APT16 – CYBER\r\nGEEKS\r\nPublished: 2021-01-25 · Archived: 2026-04-05 23:36:52 UTC\r\nSummary\r\nIn this blog post, we’re presenting a detailed analysis of a backdoor known as ELMER that was used by the Chinese\r\nactor identified as APT16. This group targeted Japanese and Taiwanese organizations in industries such as high-tech,\r\ngovernment services, media and financial services.\r\nThe malware is encrypted with a custom algorithm and it’s written in Delphi. This sample is capable of detecting\r\nproxy settings on the local machine and exfiltrating information such as the hostname and IP address of the machine\r\nto the Command and Control server. The process uses a custom decryption algorithm that consists of AND, XOR,\r\nand ADD operations in order to decrypt relevant strings during runtime. It implements 8 different commands\r\ndepending on the response from the C2 server, including: file uploads and downloads, process execution, exfiltration\r\nof file names/sizes and directory names, exfiltration of processes/process IDs. Data exfiltration is performed using an\r\nHTML document that contains the information encoded using the NOT operator.\r\nThis sample is using a custom encryption algorithm, that we will describe below. For this analysis, we have also\r\ncreated a python script that can be used to facilitate the decryption process, which can be found at\r\nhttps://github.com/Rackedydig/string_decode_algorithm_apt16.\r\nTechnical analysis\r\nSHA256: BED00A7B59EF2BD703098DA6D523A498C8FDA05DCE931F028E8F16FF434DC89E\r\nIt’s important to mention that a part of the malicious code is encrypted, and we’ll explain using a step-by-step\r\napproach how to decrypt it. The process is scanning the memory in order to find the magic number “MZ” which\r\ncorresponds to EXEs (DLLs), and then it’s extracting the first word of the PE header and compares it with “PE” as\r\nfollows:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 1 of 35\n\nFigure 1\r\nThe following picture contains a part of the bytes that will be transformed as we’ll see in the next paragraphs:\r\nFigure 2\r\nThe first 16 bytes are reordered as follows: [byte1, byte5, byte9, byte13], [byte2, byte6, byte10, byte14], [byte3,\r\nbyte7, byte11, byte15], [byte4, byte8, byte12, byte16]:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 2 of 35\n\nFigure 3\r\nNow there is a buffer of 16 bytes, which represents a “key” in the upcoming operations:\r\nFigure 4\r\nAn XOR operation is performed between the corresponding positions of the 2 buffers mentioned above:\r\nFigure 5\r\nThe first 4 bytes of the buffer remain in their current positions, however, the last 12 bytes are reordered, as shown in\r\nfigure 6:\r\nFigure 6\r\nEach byte is replaced by a byte that can be found at the position 0x671911EC+current_byte, as explained in the next\r\nfigure:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 3 of 35\n\nFigure 7\r\nAfter this transformation, the buffer becomes the following one:\r\nFigure 8\r\nThere is a second XOR decryption step, but this time the key is changing:\r\nFigure 9\r\nAfter the XOR operation is complete, the current buffer has been changed, as shown below:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 4 of 35\n\nFigure 10\r\nA few more operations will be performed, including shl cl, 1 (shift left by 1) and xor cl, 1B (xor with 0x1B). Let’s\r\ntake, for example, byte 0x90 from the buffer which is left shifted by 1 (0x20) and then XORed with 0x1B -\u003e 0x3B.\r\nByte 0x3B is left shifted by 1 and becomes 0x76 (no XOR is performed) and one more time, 0x76 is left shifted by 1\r\nand becomes 0xEC. The confirmation that all of these operations are accurate:\r\nFigure 11\r\nNow the values from this buffer are XORed together (0x90 XOR 0x76) XOR 0xEC and then the result (0xa) is\r\nXORed with other results from similar operations. After all operations are done, the buffer will be the following:\r\nFigure 12\r\nThe sample performs the steps presented above 10 times, and the buffer looks like in the next figure:\r\nFigure 13\r\nThe buffer is reordered and copied in the location displayed in figure 2, as follows:\r\nFigure 14\r\nThe algorithm applied for the first 16 bytes is repeated 2078 times. The new buffer is the decrypted version of the\r\nfirst one:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 5 of 35\n\nFigure 15\r\nThe malicious process loads multiple DLLs and retrieves the address of export functions using LoadLibraryA and\r\nGetProcAddress APIs:\r\nFigure 16\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 6 of 35\n\nThe list of DLLs to be loaded + the export functions:\r\nkernel32.dll\r\nDeleteCriticalSection, LeaveCriticalSection, EnterCriticalSection, InitializeCriticalSection, VirtualFree, VirtualAlloc,\r\nLocalFree, LocalAlloc, GetTickCount, QueryPerformanceCounter, GetVersion, , GetCurrentThreadId,\r\nGetThreadLocale, GetStartupInfoA, GetLocaleInfoA, GetLastError, GetCommandLineA, FreeLibrary, ExitProcess,\r\nWriteFile, UnhandledExceptionFilter, SetEndOfFile, RtlUnwind, RaiseException, GetStdHandle, GetFileSize,\r\nGetFileType, CreateFileA, CloseHandle, TlsSetValue, TlsGetValue, GetModuleHandleA, lstrcmpiA,\r\nWaitForSingleObject, Sleep, SetFilePointer, ReadFile, GetProcAddress, GetModuleFileNameA, GetFileAttributesA,\r\nGetCurrentDirectoryA, FindNextFileA, FindFirstFileA, FindClose, FileTimeToLocalFileTime, CreateThread,\r\nCreateProcessA\r\nuser32.dll\r\nGetKeyboardType, MessageBoxA\r\nadvapi32.dll\r\nRegQueryValueExA, RegOpenKeyExA, RegCloseKey\r\noleaut32.dll\r\nSysFreeString, SysReAllocStringLen\r\nws2_32.dll\r\nWSAGetLastError, gethostname, gethostbyname, socket, setsockopt, send, recv, inet_ntoa, inet_addr, htons, connect,\r\nclosesocket, WSACleanup, WSAStartup\r\ndnsapi.dll\r\nDnsRecordListFree, DnsQuery_A\r\nThe process passes the execution flow to the unencrypted code as illustrated in the next figure:\r\nFigure 17\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 7 of 35\n\nIn order to also perform static analysis on the binary, we have to dump the memory of this process using\r\nOllyDumpEx plugin of x32dbg debugger:\r\nFigure 18\r\nThe problem is that the IAT (Import address table) hasn’t been populated as expected and contains only 2 functions\r\nthat were also present in the original binary:\r\nFigure 19\r\nWe have to use another plugin of x32dbg called Scylla. This plugin is used to find the IAT entries in the process\r\nmemory, and then it can fix our dropped binary:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 8 of 35\n\nFigure 20\r\nWe’ve successfully fixed the IAT in our dropped binary, and this operation is useful because it reveals different API\r\ncalls which have to be analyzed:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 9 of 35\n\nFigure 21\r\nNow we will analyze the decrypted binary. It initiates the use of Winsock DLL by calling the WSAStartup function:\r\nFigure 22\r\nDuring the entire execution, the process decrypts relevant strings by using a custom algorithm that can be described\r\nshortly: If m is the encrypted buffer and key is the decryption key, the result of the algorithm is (m[i] AND 0xF)\r\nXOR (key[i] AND 0xF) + (m[i] AND 0xF0), as presented below:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 10 of 35\n\nFigure 23\r\nAfter these operations are finished, the result represents the C2 server and the corresponding port number:\r\nFigure 24\r\nThe malware opens the “Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings” registry key by calling the\r\nRegOpenKeyExA API:\r\nFigure 25\r\nThe “ProxyEnable” value is extracted using the RegQueryValueExA function, and it’s compared with 1. This action\r\nhas the purpose of verifying if the current machine is using a proxy for network communications:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 11 of 35\n\nFigure 26\r\nIf “ProxyEnable” is equal to 1, the malware proceeds and extracts the value of “ProxyServer” (hostnames/IPs of the\r\nproxy server on the network), as displayed in the next figure:\r\nFigure 27\r\nThe gethostname function is used to retrieve the host name for the local machine:\r\nFigure 28\r\nThe function result from above is used as a parameter for the gethostbyname function, which can be used to retrieve\r\nhost information corresponding to the local machine, as shown in figure 29:\r\nFigure 29\r\nThe inet_ntoa function is utilized to convert the IP address of the host into an ASCII string (dotted-decimal format):\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 12 of 35\n\nFigure 30\r\nThere is some sort of reverse operation done by the malware because it’s using the inet_addr function to convert the\r\nstring representation of the IP address into a proper address for the IN_ADDR structure:\r\nFigure 31\r\nThe hostname and the IP address of the machine represented as a decimal number are combined into a string that will\r\nbe used in the upcoming network communications with the C2 server:\r\nFigure 32\r\nThe malicious process uses the same decryption algorithm described before in order to decrypt important strings. The\r\nfunction is highlighted in the next picture:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 13 of 35\n\nFigure 33\r\nAn example of how the algorithm performs is displayed below, where EAX represents the encrypted string and the\r\nkey is moved into the EDX register:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 14 of 35\n\nFigure 34\r\nBy placing a breakpoint after the operation is supposed to end, we can observe that the string was successfully\r\ndecrypted:\r\nFigure 35\r\nAfter a few more operations are performed, we can distinguish other interesting strings, like the User Agent that will\r\nbe used in the communications with the Command and Control server:\r\nFigure 36\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 15 of 35\n\nThe sample builds an HTML document that contains the infected hostname and the IP address corresponding to the\r\nlocal machine. This form will be used in a POST request as we’ll see later on:\r\nFigure 37\r\nThe socket function is used to create a socket, and the following parameters are passed to the function call: 0x2\r\n(AF_INET – IPv4 address family), 0x1 (SOCK_STREAM – provides sequenced, reliable, two-way streams with an\r\nOOB data transmission mechanism) and 0 (the protocol is not specified). The function call is shown below:\r\nFigure 38\r\nThe setsockopt API is used to set a socket option. The following parameters can be highlighted – 0xFFFF\r\n(SOL_SOCKET – socket layer), 0x8 (SO_KEEPALIVE – enable keep-alive packets for a socket connection):\r\nFigure 39\r\nThe second setsockopt call has different parameters – 0xFFFF (SOL_SOCKET – socket layer), 0x1006\r\n(SO_RCVTIMEO – receive timeout), 0x15f90 = 90000ms = 90s (optval parameter):\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 16 of 35\n\nFigure 40\r\nThe third setsockopt call is different than the second one because it sets the send timeout to 90 seconds:\r\nFigure 41\r\nThe port number 0x1BB is converted from TCP/IP network byte order to host byte order (little-endian on Intel\r\nprocessors) by using a ntohs function call:\r\nFigure 42\r\nThe malware is using the inet_addr function to transform the C2 IP address into a proper address for the IN_ADDR\r\nstructure:\r\nFigure 43\r\nThere is a network connection established to the C2 server using the connect function. The following elements can be\r\nhighlighted in the sockaddr structure: 0x2 (AF_INET – IPv4 address family), 0x1BB = 443 (port number),\r\n0x797FF94A (the C2 server represented as a hex value). The function call is represented in the next figure:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 17 of 35\n\nFigure 44\r\nThe sample performs a GET request to the C2 server with the user agent that was decrypted earlier: “User-Agent:\r\nMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1)”. The data is sent using the send function:\r\nFigure 45\r\nThe malware reads the response from the server using the recv function, byte-by-byte (the length parameter is 1). It\r\nstops when the result contains “\\x0d\\x0a\\x0d\\x0a” (2 new lines characters in Windows) and it checks to see if the\r\nresponse contains “200 OK”, which means that the connection was successfully established:\r\nFigure 46\r\nThere is also a second comparison between the response and the “!!” string (if the result doesn’t contain “!!”, then the\r\nprocess performs a closesocket API call):\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 18 of 35\n\nFigure 47\r\nThe hostname and the IP address of the local machine are exfiltrated to the C2 server using a POST request. The\r\nSessionID parameter is randomly generated:\r\nFigure 48\r\nAs before, there are multiple recv function calls following the POST request, and the process expects the response to\r\ncontain “200 OK” and “Success”. If it doesn’t, then there is a Sleep call for 90 seconds and it tries again. A new\r\nthread is created using the CreateThread function:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 19 of 35\n\nFigure 49\r\nThread activity\r\nSome parameters used in the network communications like “id” and “SessionID” are generated by a function called\r\n“Randomize”:\r\nFigure 50\r\nIt’s important to mention that some HTTP headers are just decrypted before the network communication is performed\r\nusing the algorithm described in the first paragraphs. The sample performs another GET request using the send\r\nfunction:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 20 of 35\n\nFigure 51\r\nThe file reads the response from the server using the recv function, byte-by-byte. It expects again a “200 OK” string\r\nand as opposed to before, it expects the response not to contain “!!” (if it does, the malware exits):\r\nFigure 52\r\nThe process parses the response from the C2 server for an integer corresponding to a command that has to be\r\nexecuted. It implements 8 different commands, as shown in figure 53:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 21 of 35\n\nFigure 53\r\nCase 1 – EAX = 0\r\nThe process sends a POST request to the server that contains a similar HTML document, however the exfiltrated\r\ninformation is different. The following bytes can be highlighted: CF 83 CD 83 CF 83, on which we can apply a NOT\r\noperation and obtain 30 7C 32 7C 30 7C (0|2|0|):\r\nFigure 54\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 22 of 35\n\nThe reponse from the server is received using the recv function. If the connection was successful, the process expects\r\na “200 OK” string and also “Success”, as shown below:\r\nFigure 55\r\nThere is another GET request to the CnC server performed by the malicious process:\r\nFigure 56\r\nThe response from the server is expected to be larger this time (0x1000 = 4096 bytes):\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 23 of 35\n\nFigure 57\r\nThe response from the server is written to a file specified by a handle transmitted by the C2 server (in our case, this\r\nwas 0 because we’re trying to emulate the C2 server communications). The WriteFile API call is presented below:\r\nFigure 58\r\nThe process announces the C2 server that the write operation was successful by issuing a POST request (NOT (CF 83\r\nCE 83 CF 83) = 30 7C 31 7C 30 7C = “0|1|0|”):\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 24 of 35\n\nFigure 59\r\nIf the write operation failed, the request is changing (NOT (CF 83 CF 83 CF 83) = 30 7C 30 7C 30 7C = “0|0|0|”):\r\nFigure 60\r\nAn identical GET request, as presented before, is sent to the server and the malware jumps back to the switch\r\nstatement (this applies to each case).\r\nCase 2 – EAX = 1\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 25 of 35\n\nIn this case, we have 2 subcases depending on the response from the server. In the first one, the only thing that is\r\nexfiltrated to the CnC server is the current directory, which can be obtained by applying a NOT operation:\r\nFigure 61\r\nIn the second subcase, the malware scans the current directory using the FindFirstFileA and FindNextFileA\r\nfunctions:\r\nFigure 62\r\nEach file time is extracted and converted to a local file time by using the FileTimeToLocalFileTime API:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 26 of 35\n\nFigure 63\r\nThe process constructs the next buffer for every file: 1|File name|dwHighDateTime (high-order 32 bits of the file\r\ntime) in decimal|File size in decimal|. An example of such buffer is presented in the next picture:\r\nFigure 64\r\nAfter the process succeeds in applying the algorithm for every file in the current directory, the final buffer looks like\r\nthe following:\r\nFigure 65\r\nThe buffer is encoded using the NOT operator and is exfiltrated to the C2 server via a POST request:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 27 of 35\n\nFigure 66\r\nCase 3 – EAX = 2\r\nBy parsing the response from the server to obtain the command line to be executed, there is a new process created\r\nusing the CreateProcessA function:\r\nFigure 67\r\nIf the new process was successfully created, the following request is made to the CnC server (NOT (CD 83 CE 83 CF\r\n83) = 32 7C 31 7C 30 7C = “2|1|0|”):\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 28 of 35\n\nFigure 68\r\nWhether any error occurred during the process creation, the POST request is different (NOT (CD 83 CF 83 CF 83) =\r\n32 7C 30 7C 30 7C = “2|0|0|”):\r\nFigure 69\r\nCase 4 – EAX = 3\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 29 of 35\n\nWe have only observed a POST request performed by the malware (NOT (CC 83 CE 83 CF 83) = 33 7C 31 7C 30 7C\r\n= “3|1|0|”):\r\nFigure 70\r\nCase 5 – EAX = 4\r\nThe server provides a file name to be opened by the malicious process. This action might indicate that the attacker\r\ntries to exfiltrate the content of targeted files:\r\nFigure 71\r\nA POST request is performed by the file, the user agent is the same as in every network communication:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 30 of 35\n\nFigure 72\r\nThe process reads the content of the specified file by using a ReadFile function call:\r\nFigure 73\r\nThe content of the targeted file is exfiltrated to the CnC server using the send function:\r\nFigure 74\r\nCase 6 – EAX = 5\r\nWe believe that this command is responsible for downloading other malware payloads. There is only a GET request\r\nto the same C2 server:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 31 of 35\n\nFigure 75\r\nCase 7 – EAX = 6\r\nThe CreateToolhelp32Snapshot API is utilized to take a snapshot of the processes, the first parameter being 0x2\r\n(TH32CS_SNAPPROCESS – all processes in the system):\r\nFigure 76\r\nAll running processes on the system are retrieved by using the Process32First and Process32Next functions:\r\nFigure 77\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 32 of 35\n\nThe list of processes is exfiltrated to the CnC server. By decoding the encoded information, we can observe the\r\nfollowing string in the beginning “6|1|System Idle Process|0|System|4|smss.exe|500|csrss.exe|604|” (note the process\r\nname and the process ID in the buffer):\r\nFigure 78\r\nCase 8 – EAX = 7\r\nThe GetFileAttributesA API is used to retrieve file system attributes for the current directory, as shown in figure 79:\r\nFigure 79\r\nThe current directory name is sent to the CnC server in the following form “7|1|Directory name|”:\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 33 of 35\n\nFigure 80\r\nIf EAX \u003e 7, the process performs a few recv function calls and jumps back to the switch instruction.\r\nReferences\r\nDecryption algorithm: https://github.com/Rackedydig/string_decode_algorithm_apt16\r\nFireEye APT groups: https://www.fireeye.com/current-threats/apt-groups.html\r\nFireEye report: https://www.fireeye.com/blog/threat-research/2015/12/the-eps-awakens-part-two.html\r\nMSDN: https://docs.microsoft.com/en-us/windows/win32/api/\r\nFakenet: https://github.com/fireeye/flare-fakenet-ng\r\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/bed00a7b59ef2bd703098da6d523a498c8fda05dce931f028e8f16ff434dc89e/detection\r\nINDICATORS OF COMPROMISE\r\nC2 IP address: 121.127.249.74\r\nSHA256: BED00A7B59EF2BD703098DA6D523A498C8FDA05DCE931F028E8F16FF434DC89E\r\nSHA256: 44DD6A777F50E22EC295FEAE2DDEFFFF1849F8307F50DA4435584200A2BA6AF0\r\nURLs: https[:]//121.127.249.74/cxpid/submit.php?SessionID=\u003cdecimal number\u003e\r\nhttps[:]//121.127.249.74/send.php?id=\u003cdecimal number\u003e\r\nhttps[:]//121.127.249.74/query.php?id=\u003cdecimal number\u003e\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 34 of 35\n\nhttps[:]//121.127.249.74/cxgid/\u003cHostname\u003e/\u003cIP address in decimal\u003e/\u003cIP address in decimal\u003e0/index.php\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)\r\nSource: https://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nhttps://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/\r\nPage 35 of 35\n\nFigure 43 There is a network connection established to the C2 server using the connect function. The following elements can be\nhighlighted in the sockaddr structure: 0x2 (AF_INET -IPv4 address family), 0x1BB = 443 (port number),\n0x797FF94A (the C2 server represented as a hex value). The function call is represented in the next figure:\n   Page 17 of 35   \n\nFigure 58 The process announces the C2 server that the write operation was successful by issuing a POST request (NOT (CF 83\nCE 83 CF 83) = 30 7C 31 7C 30 7C = “0|1|0|”): \n   Page 24 of 35",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://cybergeeks.tech/a-detailed-analysis-of-elmer-backdoor-used-by-apt16/"
	],
	"report_names": [
		"a-detailed-analysis-of-elmer-backdoor-used-by-apt16"
	],
	"threat_actors": [
		{
			"id": "2608db3e-7f7a-42c0-922b-4c9cb22c7ce9",
			"created_at": "2023-01-06T13:46:38.278691Z",
			"updated_at": "2026-04-10T02:00:02.90849Z",
			"deleted_at": null,
			"main_name": "APT16",
			"aliases": [
				"SVCMONDR",
				"G0023"
			],
			"source_name": "MISPGALAXY:APT16",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "fed3d66d-1721-43b0-b5e1-d35931dc6e71",
			"created_at": "2022-10-25T15:50:23.72724Z",
			"updated_at": "2026-04-10T02:00:05.411885Z",
			"deleted_at": null,
			"main_name": "APT16",
			"aliases": [
				"APT16"
			],
			"source_name": "MITRE:APT16",
			"tools": [
				"ELMER"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434271,
	"ts_updated_at": 1775791509,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7b3757391a41b013fc481e60e1a80d6eec372065.pdf",
		"text": "https://archive.orkl.eu/7b3757391a41b013fc481e60e1a80d6eec372065.txt",
		"img": "https://archive.orkl.eu/7b3757391a41b013fc481e60e1a80d6eec372065.jpg"
	}
}