{ "id": "da5e0f6d-5cbf-4a1f-a1ca-fb491127bcfa", "created_at": "2026-04-06T00:18:01.790529Z", "updated_at": "2026-04-10T03:35:26.515282Z", "deleted_at": null, "sha1_hash": "8c9252f924326d9fa21ab27dc14dbf34d3ed8f5f", "title": "Analytics", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2711229, "plain_text": "Analytics\r\nBy Positive Technologies\r\nPublished: 2019-10-31 · Archived: 2026-04-02 12:20:21 UTC\r\nThe PT Expert Security Center first took note of Calypso in March 2019 during threat hunting. Our specialists\r\ncollected multiple samples of malware used by the group. They have also identified the organizations hit by the\r\nattackers, as well as the attackers' C2 servers. The primary goal of the group is theft of confidential data. Main\r\ntargets are governmental institutions in Brazil, India, Kazakhstan, Russia, Thailand, and Turkey.\r\nContents\r\nCalypso APT\r\nInitial infection vector\r\nLateral movement\r\nAttribution\r\nAnalyzing Calypso RAT malicious code\r\nDropper\r\nInstallation BAT script\r\nShellcode x86: stager\r\nModules\r\nCommands\r\nNetwork code\r\nShellcode x64: stager (base backdoor)\r\nModules\r\nCommands\r\nNetwork code\r\nOther options\r\nDropper-stager\r\nHussar\r\nInitialization\r\nModules\r\nFlyingDutchman\r\nConclusion\r\nIndicators of compromise\r\nNetwork\r\nFile indicators\r\nDroppers and payload\r\nDroppers with the same payload\r\nPayload without dropper\r\nHussar\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 1 of 33\n\nFlyingDutchman\r\nMITRE ATT\u0026CK\r\nCalypso APT\r\nThe PT Expert Security Center first took note of Calypso in March 2019 during threat hunting. Our specialists\r\ncollected multiple samples of malware used by the group. They have also identified the organizations hit by the\r\nattackers, as well as the attackers' C2 servers.\r\nOur data indicates that the group has been active since at least September 2016. The primary goal of the group is\r\ntheft of confidential data. Main targets are governmental institutions in Brazil, India, Kazakhstan, Russia,\r\nThailand, and Turkey.\r\nOur data gives reason to believe that the APT group is of Asian origin 1.\r\nInitial infection vector\r\nThe attackers accessed the internal network of a compromised organization by using an ASPX web shell. They\r\nuploaded the web shell by exploiting a vulnerability or, alternately, guessing default credentials for remote access.\r\nWe managed to obtain live traffic between the attackers and the web shell.\r\nFigure 1. Part of the recorded traffic\r\nThe traffic indicates the attackers connected from IP address 46.166.129.241. That host contains domain\r\ntv.teldcomtv.com, the C2 server for the group's trojan. Therefore the hackers use C2 servers not only to control\r\nmalware, but also to access hosts on compromised infrastructures.\r\nThe attackers used the web shell to upload utilities 2 and malware, 3 execute commands, and distribute malware\r\ninside the network. Examples of commands from the traffic are demonstrated in the following screenshot.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 2 of 33\n\nFigure 2. Commands sent to the web shell\r\nLateral movement\r\nThe group performed lateral movement by using the following publicly available utilities and exploits:\r\nSysInternals\r\nNbtscan\r\nMimikatz\r\nZXPortMap\r\nTCP Port Scanner\r\nNetcat\r\nQuarksPwDump\r\nWmiExec\r\nEarthWorm\r\nOS_Check_445\r\nDoublePulsar\r\nEternalBlue\r\nEternalRomance\r\nOn compromised computers, the group stored malware and utilities in either C:\\RECYCLER or C:\\ProgramData.\r\nThe first option was used only on computers with Windows XP or Windows Server 2003 with NTFS on drive C.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 3 of 33\n\nThe attackers spread within the network either by exploiting vulnerability MS17-010 or by using stolen\r\ncredentials. In one instance, 13 days after the attackers got inside the network, they used DCSync and Mimikatz to\r\nobtain the Kerberos ticket of the domain administrator, \"passing the ticket\" to infect more computers.\r\nFigure 3. Obtaining account data via DCSync\r\nUse of such utilities is common for many APT groups. Most of those utilities are legitimate ones used by network\r\nadministrators. This allows the attackers to stay undetected longer.\r\nAttribution\r\nIn one attack, the group used Calypso RAT, PlugX, and the Byeby trojan. Calypso RAT is malware unique to the\r\ngroup and will be analyzed in detail in the text that follows.\r\nPlugX has traditionally been used by many APT groups of Asian origin. Use of PlugX in itself does not point to\r\nany particular group, but is overall consistent with an Asian origin.\r\nThe Byeby trojan 4 was used in the SongXY malware campaign back in 2017. The version used now is modified\r\nfrom the original. The group involved in the original campaign is also of Asian origin. It performed targeted\r\nattacks on defense and government-related targets in Russia and the CIS countries. However, we did not find any\r\nclear-cut connection between the two campaigns.\r\nWhen we analyzed the traffic between the attackers' server and the web shell, we found that the attackers used a\r\nnon-anonymous proxy server. The X-Forwarded-For header passed the attackers' IP address (36.44.74.47). This\r\naddress would seem to be genuine (more precisely, the first address in a chain of proxy servers).\r\nFigure 4. Headers of requests to the web shell\r\nThe IP address belongs to China Telecom. We believe the attackers could have been careless and set up the proxy\r\nserver incorrectly, thus disclosing their real IP address. This is the first piece of evidence supporting the Asian\r\norigins of the group.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 4 of 33\n\nFigure 5. Information on the discovered IP address\r\nThe attackers also left behind a number of system artifacts, plus traces in utility configurations and auxiliary\r\nscripts. These are also indicative of the group's origin.\r\nFor instance, one of the DoublePulsar configuration files contained external IP address 103.224.82.47, presumably\r\nfor testing. But all other configuration files contained internal addresses.\r\nFigure 6. IP address found in the DoublePulsar configuration\r\nThis IP address belongs to a Chinese provider, like the one before, and it was most likely left there due to the\r\nattackers' carelessness. This constitutes additional evidence of the group's Asian origins.\r\nFigure 7. Information on the discovered IP address\r\nWe also found BAT scripts that launched ZXPortMap and EarthWorm for port forwarding. Inside we found\r\nnetwork indicators www.sultris.com and 46.105.227.110.\r\nFigure 8. Network indicators found in the BAT scripts\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 5 of 33\n\nThe domain in question was used for more than just tunneling: it also served as C2 server for the PlugX malware\r\nwe found on the compromised system. As already mentioned, PlugX is traditionally used by groups of Asian\r\norigin, which constitutes yet more evidence.\r\nTherefore we can say that the malware and network infrastructure used all point to the group having an Asian\r\norigin.\r\nAnalyzing Calypso RAT malicious code\r\nThe structure of the malware and the process of installing it on the hosts of a compromised network look as\r\nfollows:\r\nFigure 9. Malware structure and installation process\r\nDropper\r\nThe dropper extracts the payload as an installation BAT script and CAB archive, and saves it to disk. The payload\r\ninside the dropper has a magic header that the dropper searches for. The following figure shows an example of the\r\npayload structure.\r\nFigure 10. Structure of the payload hard-coded in the dropper\r\nThe dropper encrypts and decrypts data with a self-developed algorithm that uses CRC32 as a pseudorandom\r\nnumber generator (PRNG). The algorithm performs arithmetic (addition and subtraction) between the generated\r\ndata and the data that needs to be encrypted or decrypted.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 6 of 33\n\nFigure 11. Dropper with original encryption and decryption algorithm\r\nNow decrypted, the payload is saved to disk at %ALLUSERSPROFILE;\\TMP_%d%d, where the last two\r\nnumbers are replaced by random numbers returned by the rand() function. Depending on the configuration, the\r\nCAB archive contains one of three possibilities: a DLL and encrypted shellcode, a DLL with encoded loader in the\r\nresources, or an EXE file. We were unable to detect any instances of the last variant.\r\nInstallation BAT script\r\nThe BAT script is encoded by substitution from a preset dictionary of characters; this dictionary is initialized in a\r\nvariable in the installation script.\r\nFigure 12. Example of installation script obfuscation\r\nIn the decoded script, we can see comments hinting at the main functions of the script:\r\nREM Goto temp directory \u0026 extract file (go to TEMP directory and extract files there)\r\nREM Uninstall old version (uninstall the old version)\r\nREM Copy file (copy file)\r\nREM Run pre-install script (run the installation BAT script)\r\nREM Create service (create a service launching the malware at system startup)\r\nREM Create Registry Run (create value in the registry branch for autostart)\r\nAt the beginning of each script we can see a set of variables. The script uses these variables to save files, modify\r\nservices, and modify registry keys.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 7 of 33\n\nFigure 13. Initializing variables in deobfuscated script\r\nIn one of the oldest samples, compiled in 2016, we found a script containing comments for how to configure each\r\nvariable.\r\nFigure 14. Early version of the script with comments\r\nShellcode x86: stager\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 8 of 33\n\nIn most of the analyzed samples, the dropper was configured to execute shellcode. The dropper saved the DLL and\r\nencrypted shellcode to disk. The shellcode name was always identical to that of the DLL, but had the extension\r\n.dll.crt. The shellcode is encrypted with the same algorithm as the payload in the dropper. The shellcode acts as a\r\nstager providing the interface for communicating with C2 and for downloading modules. It can communicate with\r\nC2 via TCP and SSL. SSL is implemented via the mbed_tls library.\r\nInitial analysis of the shellcode revealed that, in addition to dynamically searching for API functions, it runs one\r\nmore operation that repeats the process of PE file address relocation. The structure of the relocation table is also\r\nidentical to that found in the PE file.\r\nFigure 15. Shellcode relocations\r\nSince the process of shellcode address relocation repeats that of the PE file, we can assume that initially the\r\nmalware is compiled into a PE file, and then the builder turns it into shellcode. Debugging information found\r\ninside the shellcode supports that assumption.\r\nFigure 16. Debugging information inside the shellcode\r\nAPI functions are searched for dynamically and addresses are relocated, after which the configuration hard-coded\r\ninside the shellcode is parsed. The configuration contains information about the C2 server address, protocol used,\r\nand connection type.\r\nFigure 17. Example of shellcode configuration\r\nNext the shellcode creates a connection to C2. A random packet header is created and sent to C2. In response the\r\nmalware receives a network key, saves it, and then uses it every time when communicating with C2. Then the\r\ninformation about the infected computer is collected and sent to C2.\r\nNext three threads are launched. One is a heartbeat sending an empty packet to C2 every 54 seconds. The other\r\nprocesses and executes commands from C2. As for the third thread, we could not figure out its purpose, because\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 9 of 33\n\nthe lines implementing its functionality were removed from the code. All we can tell is that this thread was\r\nsupposed to \"wake up\" every 54 seconds, just like the first one.\r\nModules\r\nWe have not found any modules so far. But we can understand their functionality by analyzing the code\r\nresponsible for communication between the shellcode and the modules. Each module is shellcode which is given\r\ncontrol over the zero offset of the address. Each module exists in its own separate container. The container is a\r\nprocess with loaded module inside. By default, the process is svchost.exe. When a container is created, it is\r\ninjected with a small shellcode that causes endless sleep. This is also hard-coded in the main shellcode, and more\r\nspecifically in JustWait. pdb, most likely.\r\nThe module is placed inside with an ordinary writeprocess and is launched either with NtCreateThreadEx or, on\r\npre-Vista operating systems, CreateRemoteThread.\r\nTwo pipes are created for each module. One is for transmitting the data from the module to C2; the other for\r\nreceiving data from C2. Quite likely the modules do not have their own network code and instead use the pipes to\r\ncommunicate with external C2 through the main shellcode.\r\nFigure 18. Creating pipes for modules\r\nEach module has a unique ID assigned by C2. Containers are launched in different ways. A container can be\r\nlaunched in a specific session open in the OS or in the same session as the stager. In any particular session, the\r\ncontainer is launched by getting the handle for the session token of a logged-in user, and then launching the\r\nprocess as that user.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 10 of 33\n\nFigure 19. Creating container process in a different session\r\nCommands\r\nThe malware we studied can process 12 commands. All of them involve modules in one way or another. Here is a\r\nlist of all IDs of commands found in the malware, along with those that the malware itself sends in various\r\nsituations.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 11 of 33\n\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 12 of 33\n\nNetwork code\r\nNetwork communication is initialized after the network key is received from C2. To do that, the malware sends a\r\nrandom sequence of 12 bytes to C2. In response the malware also expects 12 bytes, the zero offset of which must\r\ncontain the same value (_DWORD) as prior to sending. If the check is successful, four bytes at offset 8 are taken\r\nfrom the response and decrypted with RC4. The key is four bytes sent previously, also located at offset 8. This\r\nresult is the network key. The key is saved and then used to send data.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 13 of 33\n\nAll transmitted packets have the following structure.\r\nstruct Packet{\r\n struct PacketHeader{\r\n _ DWORD key;\r\n _ WORD cmdId;\r\n _ WORD szPacketPayload;\r\n _ DWORD moduleId;\r\n};\r\n _ BYTE [max 0xF000] packetPayload;\r\n};\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 14 of 33\n\nA random four-byte key is generated for each packet. It is later used to encrypt part of the header, starting with the\r\ncmdld field. The same key is used to encrypt the packet payload. Encryption uses the RC4 algorithm. The key\r\nitself is encrypted by XOR with the network key and saved to the corresponding field of the packet header.\r\nShellcode x64: stager (base backdoor)\r\nThis shellcode is very similar to the previous one, but it deserves a separate description because of differences in\r\nits network code and method of launching modules. This shellcode has basic functions for file system interaction\r\nwhich are not available in the shellcode described earlier. Also the configuration format, network code, and\r\nnetwork addresses used as C2 by this shellcode are similar to code from a 2018 blog post by NCC Group about a\r\nGh0st RAT variant. However, we did not find a connection to Gh0st RAT.\r\nThis variant of the shellcode has only one communication channel, via SSL. The shellcode implements it with two\r\nlegitimate libraries, libeay32.dll and ssleay32.dll, hard-coded in the shellcode itself.\r\nFirst the shellcode performs a dynamic search for API functions and loads SSL libraries. The libraries are not\r\nsaved to disk; they are read from the shellcode and mapped into memory. Next the malware searches the mapped\r\nimage for the functions it needs to operate.\r\nThen it parses the configuration string, which is also hard-coded in the shellcode. The configuration includes\r\ninformation on addresses of C2 servers and schedule for malware operation.\r\nFigure 20. Sample of configuration string\r\nAfter that the malware starts its main operating cycle. It checks if the current time matches the malware\r\noperational time. If not, the malware sleeps for about 7 minutes and checks again. This happens until the current\r\ntime is the operational time, and only then does the malware resume operation. Figure 20 demonstrates an\r\nexample in which the malware remains active at all times on all days of the week.\r\nWhen the operational time comes, the malware goes down the list of C2 servers specified in the configuration and\r\ntries to connect. The malware subsequently interacts with whichever of the C2 servers it is able to successfully\r\nconnect to first.\r\nThen the malware sends the information on the infected computer (such as computer name, current date, OS\r\nversion, 32-bit vs. 64-bit OS and CPU, and IP addresses on network interfaces and their MAC addresses). After\r\nthe information on the infected computer is sent, the malware expects a response from C2. If C2 returns the\r\nrelevant code, sending is deemed successful and the malware proceeds. If not, the malware goes back to\r\nsequentially checking C2 addresses. Next it starts processing incoming commands from C2.\r\nModules\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 15 of 33\n\nEach module is a valid MZPE file mapped in the address space of the same process as the shellcode. Also the\r\nmodule can export the GetClassObject symbol, which receives control when run (if required).\r\nEach module has its own descriptor created by a command from C2. The C2 server sends a byte array (0x15)\r\ndescribing the module. The array contains information on the module: whether the module needs to be launched\r\nvia export, module type (in other words, whether it needs pipes for communicating with C2), module size, entry\r\npoint RVA (used if there is no flag for launching via export), and module data decryption key. The key is, by and\r\nlarge, the data used to format the actual key.\r\nFigure 21. Module decryption\r\nWe should also point out that decryption takes place only if modKey is not equal to the 7AC9h constant hard-coded in the shellcode. This check affects only the decryption process. If modKey does equal the constant, the\r\nmalware will immediately start loading the module. This means the module is not encrypted.\r\nEach module is launched in a separate thread created specially for that purpose. Launching with pipes looks as\r\nfollows:\r\nThe malware creates a thread for the module, starts mapping the module, and gives it control inside the\r\nnewly created thread.\r\nThe malware creates a new connection to the current working C2.\r\nThe malware creates a pipe with the name derived from the following format string: \\\\.\\\r\npipe\\windows@#%02XMon (%02X is replaced by a value that is received from С2 at the same time as the\r\ncommand for launching the module).\r\nThe malware launches two threads passing data from the pipe to C2 and vice versa, using the connection\r\ncreated during the previous step. Two more pipes, \\\\.\\pipe\\windows@#%02Xfir and\r\n\\\\.\\pipe\\windows@#%02Xsec, are created inside the threads. The pipe ending in \"fir\" is used to pass data\r\nfrom the module to C2. The pipe ending in \"sec\" is used to pass data and commands from C2 to the\r\nmodules.\r\nThe second thread processing the commands from C2 to the modules has its own handler. This is described in\r\nmore details in the Commands section. For now we can only say that one of the commands can start a local\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 16 of 33\n\nasynchronous TCP server. That server will accept data from whoever connects to it, send it to C2, and forward it\r\nback from C2. It binds to 127.0.0.1 at whichever port it finds available, starting from 5000 and trying possible\r\nports one by one.\r\nCommands\r\nThe following is a list of IDs for commands the malware can receive, along with commands the malware itself\r\nsends in various situations.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 17 of 33\n\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 18 of 33\n\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 19 of 33\n\nNetwork code\r\nEach packet has the following structure:\r\nStruct Packet{\r\n Struct Header{\r\n _ DWORD rand _ k1;\r\n _ DWORD rand _ k2;\r\n _ DWORD rand _ k3;\r\n _ DWORD szPaylaod;\r\n _ DWORD protoConst;\r\n _ DWORD packetId;\r\n _ DWORD unk1;\r\n _ DWORD packetKey;\r\n};\r\n _ BYTE [max 0x2000] packetPayload;\r\n};\r\nEach packet has a unique key calculated as szPayload + GetTickCount() % hardcodedConst. This key is saved in\r\nthe corresponding packetKey header field. It is used to generate another key for encrypting the packet header with\r\nRC4 (encryption will not occur without the packetKey field). RC4 key generation is demonstrated in the following\r\nfigure.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 20 of 33\n\nFigure 22. Generating RC4 key for the header\r\nThen yet another RC4 key is generated from the encrypted fields szPayload, packetId, protoConst, and rand_k3.\r\nThis key is used to encrypt the packet payload.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 21 of 33\n\nFigure 23. Generating RC4 key for the packet payload\r\nNext the shellcode forms the HTTP headers and the created packet is sent to C2. In addition, each packet gets its\r\nown number, indicated in the URL. Modules may pass their ID, which is used to look up the connection\r\nestablished during module launch. Module ID 0 is reserved for the main connection of the stager.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 22 of 33\n\nFigure 24. Forming HTTP headers\r\nOther options\r\nAs we noted, the dropper may be configured to launch not just shellcode, but executable files too. We found the\r\nsame dropper-stager but with different payloads: Hussar and FlyingDutchman.\r\nDropper-stager\r\nThe main tasks of this dropper are unpacking and mapping the payload, which is encoded and stored in resources.\r\nThe dropper also stores encoded configuration data and passes it as a parameter to the payload.\r\nFigure 25. Unpacking the payload\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 23 of 33\n\nHussar\r\nIn essence Hussar is similar to the shellcodes described earlier. It allows loading modules and collecting basic\r\ninformation about the computer. It can also add itself to the list of authorized applications in Windows Firewall.\r\nInitialization\r\nTo start, the malware parses the configuration provided to it by the loader.\r\nFigure 26. Configuration sample\r\nConfiguration structure is as follows:\r\nStruct RawConfig{\r\n _ DWORD protocolId;\r\n _ BYTE c2Strings [0x100];\r\n};\r\nThe protocolId field indicates the protocol to be used for communicating with C2. There are a total of three\r\npossibilities:\r\nIf protocolId equals 1, a TCP-based protocol will be used.\r\nIf protocolId equals 2, the protocol will be HTTP-based.\r\nIf protocolId equals 3, it will be HTTPS-based.\r\nThe time stamp is calculated from the registry from the key SOFTWARE\\Microsoft\\Windows\\\r\nCurrentVersion\\Telephony (Perf0 value). If reading the time stamp is impossible, \"temp\" is added to the computer\r\nidentifier.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 24 of 33\n\nFigure 27. Generating computer ID\r\nNext Hussar creates a window it will use for processing incoming messages.\r\nFigure 28. Creating dispatcher window\r\nThen the malware adds itself to the list of authorized applications in Windows Firewall, using the INetFwMgr\r\nCOM interface.\r\nTo complete initialization, Hussar creates a thread which connects to C2 and periodically polls for commands. The\r\nfunction running in the thread uses the WSAAsyncSelect API to notify the window that actions can be performed\r\nwith the created connection (socket is \"ready for reading,\" \"connected,\" or \"closed\").\r\nFigure 29. Communication between the open socket and the window\r\nIn general, for transmitting commands, the malware uses the window and Windows messaging mechanism. The\r\nwindow handle is passed to the modules, and the dispatcher has branches not used by the stager, so we can assume\r\nthat the modules can use the window for communication with C2.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 25 of 33\n\nModules\r\nEach module is an MZPE file loaded into the same address space as the stager. The module must export the\r\nGetModuleInfo function, which is called by the stager after image mapping.\r\nFlyingDutchman\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 26 of 33\n\nThe payload provides remote access to the infected computer. It includes functions such as screenshot capture,\r\nremote shell, and file system operations. It also allows managing system processes and services. It consists of\r\nseveral modules.\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 27 of 33\n\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 28 of 33\n\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 29 of 33\n\nConclusion\r\nThe group has several successful hacks to its credit, but still makes mistakes allowing us to guess its origins. All\r\ndata given here suggests that the group originates from Asia and uses malware not previously described by\r\nanyone. The Byeby trojan links the group to SongXY, encountered by us previously, which was most active in\r\n2017.\r\nWe keep monitoring the activities of Calypso closely and expect the group will attack again.\r\nIndicators of compromise\r\nNetwork\r\n23.227.207.137\r\n45.63.96.120\r\n45.63.114.127\r\nr01.etheraval.com\r\ntc.streleases.com\r\ntv.teldcomtv.com\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 30 of 33\n\nkrgod.qqm8.com\r\nFile indicators\r\nDroppers and payload\r\nC9C39045FA14E94618DD631044053824\r\nE24A62D9826869BC4817366800A8805C\r\nF0F5DA1A4490326AA0FC8B54C2D3912D\r\nCB914FC73C67B325F948DD1BF97F5733\r\n6347E42F49A86AFF2DEA7C8BF455A52A\r\n0171E3C76345FEE31B90C44570C75BAD\r\n17E05041730DCD0732E5B296DB16D757\r\n69322703B8EF9D490A20033684C28493\r\n22953384F3D15625D36583C524F3480A\r\n1E765FED294A7AD082169819C95D2C85\r\nC84DF4B2CD0D3E7729210F15112DA7AC\r\nACAAB4AA4E1EA7CE2F5D044F198F0095\r\nDroppers with the same payload\r\n85CE60B365EDF4BEEBBDD85CC971E84D\r\n1ED72C14C4AAB3B66E830E16EF90B37B\r\nCB914FC73C67B325F948DD1BF97F5733\r\nPayload without dropper\r\nE3E61F30F8A39CD7AA25149D0F8AF5EF\r\n974298EB7E2ADFA019CAE4D1A927AB07\r\nAA1CF5791A60D56F7AE6DA9BB1E7F01E\r\n05F472A9D926F4C8A0A372E1A7193998\r\n0D532484193B8B098D7EB14319CEFCD3\r\nE1A578A069B1910A25C95E2D9450C710\r\n2807236C2D905A0675878E530ED8B1F8\r\n847B5A145330229CE149788F5E221805\r\nD1A1166BEC950C75B65FDC7361DCDC63\r\nCCE8C8EE42FEAED68E9623185C3F7FE4\r\nHussar\r\n43B7D48D4B2AFD7CF8D4BD0804D62E8B\r\n617D588ECCD942F243FFA8CB13679D9C\r\nFlyingDutchman\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 31 of 33\n\n5199EF9D086C97732D97EDDEF56591EC\r\n06C1D7BF234CE99BB14639C194B3B318\r\nMITRE ATT\u0026CK\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 32 of 33\n\n1. See the section \"Attribution.\"\r\n2. See the section \"Lateral movement.\"\r\n3. See the section \"Analyzing Calypso RAT malicious code.\"\r\n4. unit42.paloaltonetworks.com/unit42-threat-actors-target-government-belarus-using-cmstar-trojan/\r\n5. nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2018/april/decoding-network-data-from-a-gh0st-rat-variant/\r\nSource: https://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nhttps://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/\r\nPage 33 of 33\n\n https://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/ \nThe payload provides remote access to the infected computer. It includes functions such as screenshot capture,\nremote shell, and file system operations. It also allows managing system processes and services. It consists of\nseveral modules. \n Page 27 of 33", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "references": [ "https://www.ptsecurity.com/ww-en/analytics/calypso-apt-2019/" ], "report_names": [ "calypso-apt-2019" ], "threat_actors": [ { "id": "e6c64ba5-12e1-4f04-97d5-077d83da95e1", "created_at": "2024-10-08T02:00:04.466964Z", "updated_at": "2026-04-10T02:00:03.724238Z", "deleted_at": null, "main_name": "SongXY", "aliases": [], "source_name": "MISPGALAXY:SongXY", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "3c5b0e7e-2388-4b63-9b97-6b027bec4bf7", "created_at": "2023-01-06T13:46:39.068694Z", "updated_at": "2026-04-10T02:00:03.202867Z", "deleted_at": null, "main_name": "Calypso", "aliases": [ "BRONZE MEDLEY" ], "source_name": "MISPGALAXY:Calypso", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "13d9c5fc-af82-4474-90dd-188c4e40a399", "created_at": "2022-10-25T16:07:23.435079Z", "updated_at": "2026-04-10T02:00:04.601572Z", "deleted_at": null, "main_name": "Calypso", "aliases": [ "Bronze Medley" ], "source_name": "ETDA:Calypso", "tools": [ "Agent.dhwf", "Byeby", "Calypso RAT", "DCSync", "Destroy RAT", "DestroyRAT", "DoublePulsar", "EternalBlue", "EternalRomance", "FlyingDutchman", "Kaba", "Korplug", "LOLBAS", "LOLBins", "Living off the Land", "Mimikatz", "NBTscan", "OS_Check_445", "PlugX", "Quarks PwDump", "RedDelta", "SAMRID", "Sogu", "SysInternals", "TCP Port Scanner", "TIGERPLUG", "TVT", "Thoper", "Whitebird", "Xamtrav", "ZXPortMap", "nbtscan", "netcat" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434681, "ts_updated_at": 1775792126, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8c9252f924326d9fa21ab27dc14dbf34d3ed8f5f.pdf", "text": "https://archive.orkl.eu/8c9252f924326d9fa21ab27dc14dbf34d3ed8f5f.txt", "img": "https://archive.orkl.eu/8c9252f924326d9fa21ab27dc14dbf34d3ed8f5f.jpg" } }