{ "id": "29eedd47-735d-4af2-98e9-ec069bd6e779", "created_at": "2026-04-06T00:15:05.285514Z", "updated_at": "2026-04-10T03:34:57.696307Z", "deleted_at": null, "sha1_hash": "77d7c17100c18e0df37487beda52593529c8de43", "title": "Technical Analysis: Pacha Group Deploying Undetected Cryptojacking Campaigns on Linux Servers", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 5873404, "plain_text": "Technical Analysis: Pacha Group Deploying Undetected\r\nCryptojacking Campaigns on Linux Servers\r\nBy Ignacio Sanmillan\r\nPublished: 2019-02-28 · Archived: 2026-04-02 11:30:48 UTC\r\nIntroduction\r\nCryptomining malware, also known as cryptojacking or cryptocurrency mining malware, refers to software\r\ndeveloped to take over a computer’s resources and use them for cryptocurrency mining without a user’s explicit\r\npermission.\r\nThere are several reports documenting this newer malware breed and how it has become more popular in the last\r\nfew years.\r\nAntd is a miner found in the wild on September 18, 2018. Recently we discovered that the authors from Antd are\r\nactively delivering newer campaigns deploying a broad number of components, most of them completely\r\nundetected and operating within compromised third party Linux servers. Furthermore, we have observed that\r\nsome of the techniques implemented by this group are unconventional, and there is an element of sophistication to\r\nthem. We believe the authors behind this malware are from Chinese origin. We have labeled the undetected\r\nLinux.Antd variants, Linux.GreedyAntd and classified the threat actor as Pacha Group.\r\nString Reuse from Antd and GreedyAntd\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 1 of 25\n\nTechnical Analysis\r\nInfrastructure Overview:\r\nBased on our findings Linux.GreedyAntd’s operations closely resemble previous cryptojacking campaigns\r\ndeployed by Pacha Group in the past. A resumed overview of the current infrastructure is as follows:\r\nThe attack chain commences by intruding into a given vulnerable server. Based on the services the compromised\r\nservers were publicly exposing, we can assume the attackers opted to launch a brute-force attack against services\r\nlike WordPress or PhpMyAdmin, or used a known exploit for an outdated version of alike services. The following\r\nis an overview of the open services and known vulnerabilities found in one of the compromised systems:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 2 of 25\n\nOnce the attackers are able to break into a given compromised server, they will run a series of stages in their\r\nattack chain.\r\nMain Dropper:\r\nOnce a system is compromised the first implant that will be executed is a UPX packed statically linked stripped\r\nELF.\r\nThis ELF binary is the main component in the intrusion stage and it is worth dedicating a separate section to. We\r\nwill refer to this binary as the ‘first stage’ or ‘main dropper’ throughout the blog.\r\nThis binary is responsible for various tasks. One of the first actions it will take is to assure that the current\r\ncompromised server is not infected by other cryptominers by using a technique similar to that of a ‘bot kill’\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 3 of 25\n\napproach (as known in the DDoS scene) killing any other cryptominer that is currently running in the system. The\r\nfollowing list contains the file names belonging to known foreign cryptominers:\r\nWe recognized that one of the file names in this list is the Korkerds miner reported by TrendMicro as well as other\r\nknown miners such as DDG or XMRig. This reinforces the assumption that the list is indeed a blacklist of file\r\nnames of known miners operating in the wild.\r\nProcesses with a filepath residing in ‘/tmp/’, ‘/usr/tmp’ or ‘/dev/shm’ will be killed. We concluded that the purpose\r\nof this aggressive behavior is intended to discover further miner processes or malware that were not covered in the\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 4 of 25\n\ninitial miner process blacklist.\r\nWe have also noticed that some implants were checking for potential JBOSS compromised servers by attempting\r\nto access specific paths in order to detect and restrict potential operational webshells or dropped binaries by\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 5 of 25\n\nremoving all available file permissions to them. There is a github project called JexBoss regarding JBOSS\r\nserialization vulnerabilities that uses these same paths, suggesting that authors behind other cryptomining\r\ncampaigns could be using it to spread their infrastructures, answering why these paths are being searched for:\r\nAs previously mentioned, evaluation of the current system in order to know if it is already compromised has been\r\naccomplished. Furthermore, there may be a chance that the current system is already compromised by the same\r\ngroup. In order to figure out whether this is the case all process names are checked again with the end goal of\r\nrecognizing any familiar process names used by the same group and if found, the process will terminate. This\r\ncould potentially work as a possible vaccine to be used by some miner-protection solutions against this specific\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 6 of 25\n\nminer:\r\nAfter the first stage has completed an initial reconnaissance for the running processes, it proceeds to create a\r\nrandom string to rename itself. It also overwrites some known memory locations where the original process name\r\nresides and overwrites them with a fake process name (in this case ‘[kworker/1:7]’). An example of such memory\r\nlocations is argv[0]:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 7 of 25\n\nFurthermore it will fork itself and detach from its parent to become an independent process running on a different\r\nsession as a means to create a fresh new process:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 8 of 25\n\nLastly, the current session username is checked and the control flow will diverge accordingly:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 9 of 25\n\nAs demonstrated in the previous screenshot, the main difference is that if the file was executed as root, persistence\r\nmechanisms would be enforced.\r\nPersistence Mechanisms:\r\nThe applied persistence mechanisms consist mainly of a given dropped implant saved as ‘mand’ followed by\r\ninstalling a Systemd service which will grant its persistence in the system. In addition, the timestamp of the\r\ndropped implants will be replaced as for the one of ‘/usr/bin/find’ as a means to make the dropped file unnoticed\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 10 of 25\n\nin the filesystem.\r\nA Systemd unit file will be decoded and dropped as ‘systemd-mandb.service’ masquerading the genuine mandb\r\nservice. The following is the decoded Systemd unit file:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 11 of 25\n\nIt is important to highlight that this persistence measure will make the intrusion harder to spot for the untrained\r\neye since it is not the average cron-job that most Linux malware tend to use. Furthermore we spotted other\r\ncomponents of this campaign dropping and installing initrd scripts as well as the following one:\r\nAfter persistence measures have been enforced, several components will be downloaded to the current\r\ncompromised system to remain with the attack chain:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 12 of 25\n\nMulti-Stage Architecture:\r\nThe following diagram is a simplified version of the various components that make up the malware’s main\r\ninfrastructure:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 13 of 25\n\nWe can assume that the main reason for having such a broad infrastructure involving a large number of\r\ncomponents is to make it more resilient to server shutdowns as well as to provide a factor of modularity.\r\nFurthermore, having this amount of components interconnected with each other also implies to invest a much\r\ngreater effort in order to clean a given compromised system.\r\nThese components will run according to a small protocol involving the main dropper and all remaining\r\ncomponents executed via a shared named pipe. This execution protocol is the following:\r\nThe majority of the secondary stagers create (or just open if it already exists) a named pipe on execution with\r\nwrite permissions in which they write their pid to:\r\nOn the other hand, the main dropper serializes each stager by reading and logging the contents of the named pipe\r\ntherefore retrieving each stager’s pid. This way the main dropper acts as a manager for each active stager in the\r\nsystem:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 14 of 25\n\nThe first stage’s main threat will continue execution attempting to update the available stagers by downloading\r\nthem in intervals on an infinite loop:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 15 of 25\n\nIn addition, a timed routine will be executed by triggering a SIGALRM signal also in intervals, handling this signal\r\nvia sigaction sycall, and therefore pivoting control of execution to its correspondent signal handler intermittently.\r\nThis same technique has been spotted in various components of this malware’s infrastructure:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 16 of 25\n\nThis installed signal handler is mainly used to drop further artifacts using embedded one-liner python scripts such\r\nas the following:\r\nThis script will drop further stages as well as further scripts. The following is an example of such scripts:\r\nGreedyAntD Miner Client\r\nThe deployed miner instance is a XMRig variant. We can confirm this via code reuse:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 17 of 25\n\nWe can also confirm the miner shares code with other components from the same infrastructure, also based on\r\ncode reuse:\r\nIt uses the Stratum mining protocol and connects to a XMRig proxy in order to conduct the mining operation. We\r\nassume the reason to use this specific protocol is to prevent to deploy its clients with encoded configurations\r\ncontaining the target wallet address they will be mining to, instead they connect to already configured proxies:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 18 of 25\n\nThe following are the Proxies that interacts with:\r\nFurthermore, we can also confirm it is using Stratum by sniffing the Miner’s stream to these proxies:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 19 of 25\n\nWe notice that the client and server are exchanging information encoded as json-rpc strings, which is commonly\r\nused in stratum mining protocol.\r\nHighlighted are the different cryptocurrency mining algorithms that the client supports. These names can be seen\r\nin the main XMRig-proxy GitHub repository:\r\nThe following screenshot is a process list view on htop of a compromised system. Highlighted are some of the\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 20 of 25\n\nmalicious processes related to the campaign:\r\nConnections with Linux.HelloBot\r\nAmong the artifacts hosted in GreedyAntd’s servers, we managed to find a single component not related to the\r\nsame cryptojacking operation just previously discussed and leveraged by Pacha Group. This file was hosted on a\r\ncompromised third party server and its main purpose was to drop a xmr-stak json configuration. This json file was\r\nthe following:\r\nWhen we analyzed this binary for code reuse connections we found it shared a significant amount of code with\r\nLinux.HelloBot, a Chinese bot discovered by Intezer along with MalwareMustDie in January 2019:\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 21 of 25\n\nAfter analyzing the code connections we came to the realization that both samples were sharing the same instance\r\nof some static libc implementation:\r\nLibrary similarities tend to not be as relevant in some specific scenarios in regards to finding connections between\r\nthreat actors. However, in this case these library similarities seem to be relevant enough to consider a potential\r\nlink between these two threat actors. Especially since from viewing all different x86 libc versions in our database,\r\nit only matched with Linux.HelloBot’s statically linked libc. In addition, this libc instance has identical code in\r\nboth samples which implies it was compiled with the same compilation flags. This reinforces that the particular\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 22 of 25\n\nlibc instance may be a potential link to connect these binaries with a single author, also taking into account that\r\nboth of them have indicators that suggest they have Chinese origin.\r\nConclusion\r\nThis cryptominer use case is another example of an undetected Linux malware operating in the wild. After\r\nconducting more research we concluded that the approach of interconnecting all second-stagers to a manager (this\r\nbeing the main dropper) via IPCs is successful for anti-dynamic analysis. In order for any of the secondary-stages\r\nto run successfully they will need to be present with the main dropper in a given system. This implies that\r\nbehavior and dynamic analysis will fail if any of the second-stager components are analyzed independently\r\nwithout tampering the original sample. This may explain why the majority of the components in this malware’s\r\ninfrastructure remain practically undetected:\r\nIOCs:\r\n185.165.169.6\r\n185.10.68.100\r\n4d1a6151166048ea066c6b5918fbb02a43ed357e3e7eb75bc73970a97008337e\r\nchn\r\n206287e22445431ccab0a574f3002e28d1aaffa5153ba66f2a754d1f92b90a78\r\nchn.unpacked\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 23 of 25\n\n9119d47ee2b6e7bf94245699fec1432042e30255d9f64289f8e0aca56570eab3\r\nofd\r\n096f8f387200fa70dddb2bfe5a77a50c88acb155d4f296f1fa6cb09109053246\r\nofd.unpacked\r\nee0ab03909ca433deb9161e831512c5bd6c64ffbc9332c3eea14b85b996ba882\r\nrlr\r\n1161fbe0a9ae1c5e0792d23682b602990af31c6847865220cf4f2f91981d426c\r\nrlr.unpacked\r\n3c3379284417070983da222f8ea347a4166c28a2ba3445e19f92b10b9b539573\r\n_j.jpg\r\n9ff1bf60e35912141c74728738c3af105d06ea8fa9c0cbd7a4b196ec1cdc9e22\r\nj.jpg\r\ndafac060867643d27a81e99e3753d155658e5f4a7f359317e0e8609fc7d14373\r\njm\r\n069a87fbd966df854f55d82fc98f89ef394cee59b352fba5fb402887892a4161\r\njm.unpacked\r\n84165c21fc144894c5fe674cfd06edafd4b95d52abf86afef4d61db91099bf8a\r\njpp\r\n544e71e3a7ff1f1f0e902cef00156aa157790f7c3450870ca9272936443e05af\r\njpp.unpacked\r\na9656439d1ac3881c1ba9e0f2fd462b8a4469bf79035233517eae65ed6afafd0\r\njrd\r\ne43d381c43749d7d267d207273ef3b634bfaeb0ff76f8e2cd6e0b27c6e3b07c8\r\njrd.unpacked\r\n3c3379284417070983da222f8ea347a4166c28a2ba3445e19f92b10b9b539573\r\n_j.sh\r\nb6455e0335ad99028656b5b847fd5d530bc079b2524b2ecbf4f06d5e69473e7d\r\nlmmml\r\n39904faf4a620aa3a9e9ece3022f0bced20ef7684e0f352f99267e7c462d227c\r\nlmmml.unpck\r\n910fea37c73fc328522e04c77d1ad555c990f0376960770698bd3590c5b1b485\r\nnvn\r\n81b8860ecf21a73de8663188962fb1dae5a5c17e7b6f4ac41e0198d12497838f\r\nnvn.unpacked\r\n371f52a238d4be6eb8d7fd0130684f4286681f09adb61fbca3bdfacef8c747f7\r\nsds\r\nb72074b6c75b4fe5ea74e2db716f488a356d9d879c6d3aa5e9ed4bb786993761\r\nsds.unpacked\r\n42a423b6107f2186964ac9a1e7882a50f6b5cb9f96926dd2a69b1fc5eaba81d6\r\nlmmml.1\r\ne9a06f7183f7e06d8e414e16caae769a3859fcca20acae735f6744712f84b3e5\r\nsss\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 24 of 25\n\n4f9e77b4e0d80ea74ba861ab54b7360df7b823f24fd9cedb1fd44a29da70b11f\r\nsss.unpacked\r\n0940472a185099df2f814bcedbc1c913a7075168ab90d63249c6301849c1d93f\r\ndld\r\n6ff5e36d2999f8593cc4daa5e7c633abe0f28b0cba9da0339fc8d3cb7f6090a3\r\ndld.unpacked\r\nc70423e5d44cc31df70a69d65e56be1621956bccec2a3a68a69195ecccd4e881\r\n_jj.jpg\r\n452ed9cf53aed0afdc7900ca855f652a7c1585c2b03b27e6f3224fb6204da25a\r\n_jj.sh\r\n6f3add7ec36a710973d09b814082e105b848cd78f2769ba6bbc946f59f463457\r\nldl\r\n045d7afaf53692607e7433a4fe8f19b2e3790414c649c8630086039d88935a02\r\nldl.unpacked\r\n0940472a185099df2f814bcedbc1c913a7075168ab90d63249c6301849c1d93f\r\nolo\r\n6ff5e36d2999f8593cc4daa5e7c633abe0f28b0cba9da0339fc8d3cb7f6090a3\r\nolo.unpacked\r\n7ae8c6c65955fb9340b07afd380bbf3383b5030a92ba204cd61ca21c13a955e8\r\n _z.jpg\r\n9e049a51741f22403a9c08d3d7625ad4761cbfda5a8a051f6e8195e0f6a8e9cd\r\nz.jpg\r\n7ae8c6c65955fb9340b07afd380bbf3383b5030a92ba204cd61ca21c13a955e8\r\n _z.sh\r\n9e049a51741f22403a9c08d3d7625ad4761cbfda5a8a051f6e8195e0f6a8e9cd\r\nz.sh\r\nCceddd7e9a7ddb4991776239cb0b941d061ac21db00b1021a8c45660f52e56b7\r\nE2e07782dbfddeb95661c7360db5113c9b035cfb8e43e038106bd0f537553b36\r\n40d8d89aa19ca4121ab583758692752964402923917da766f39a32cbc8bdd6dd\r\nSource: https://www.intezer.com/blog-technical-analysis-pacha-group/\r\nhttps://www.intezer.com/blog-technical-analysis-pacha-group/\r\nPage 25 of 25\n\n https://www.intezer.com/blog-technical-analysis-pacha-group/ \nLastly, the current session username is checked and the control flow will diverge accordingly:\n Page 9 of 25", "extraction_quality": 1, "language": "EN", "sources": [ "MISPGALAXY", "ETDA", "Malpedia" ], "references": [ "https://www.intezer.com/blog-technical-analysis-pacha-group/" ], "report_names": [ "blog-technical-analysis-pacha-group" ], "threat_actors": [ { "id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2", "created_at": "2022-10-25T16:07:24.471018Z", "updated_at": "2026-04-10T02:00:05.002374Z", "deleted_at": null, "main_name": "Cron", "aliases": [], "source_name": "ETDA:Cron", "tools": [ "Catelites", "Catelites Bot", "CronBot", "TinyZBot" ], "source_id": "ETDA", "reports": null }, { "id": "18bcbaa6-8e7b-43c4-9db7-8b0b315ee5a3", "created_at": "2023-01-06T13:46:39.024086Z", "updated_at": "2026-04-10T02:00:03.184974Z", "deleted_at": null, "main_name": "Pacha Group", "aliases": [], "source_name": "MISPGALAXY:Pacha Group", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "484c5fed-029e-4504-b75a-bbdbc9460595", "created_at": "2022-10-25T16:07:24.529893Z", "updated_at": "2026-04-10T02:00:05.02425Z", "deleted_at": null, "main_name": "Pacha Group", "aliases": [], "source_name": "ETDA:Pacha Group", "tools": [ "Antd", "DDG", "GreedyAntd", "Korkerds", "XMRig" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434505, "ts_updated_at": 1775792097, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/77d7c17100c18e0df37487beda52593529c8de43.pdf", "text": "https://archive.orkl.eu/77d7c17100c18e0df37487beda52593529c8de43.txt", "img": "https://archive.orkl.eu/77d7c17100c18e0df37487beda52593529c8de43.jpg" } }