{ "id": "e3888e95-d981-4812-afe3-c9bb6d365e01", "created_at": "2026-04-06T00:10:39.338785Z", "updated_at": "2026-04-10T13:12:42.48706Z", "deleted_at": null, "sha1_hash": "8efea1b6898cfbce38cecf5a0092b333bb6c77ea", "title": "Discovering Linux ELF beacon of Cobalt Strike tool", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 88789, "plain_text": "Discovering Linux ELF beacon of Cobalt Strike tool\r\nBy Anonymous\r\nPublished: 2021-09-19 · Archived: 2026-04-05 14:51:24 UTC\r\n This post was authored by Fareed.\r\nIntroduction\r\nCobalt Strike is a tool used for red teaming and penetration testing to demonstrate the cyber attack. Cobalt Strike\r\nis a commercial, full-featured, remote access tool that bills itself as \"adversary simulation software designed to\r\nexecute targeted attacks and emulate the post-exploitation actions of advanced threat actors\". Cobalt Strike’s\r\ninteractive post-exploit capabilities cover the full range of ATT\u0026CK tactics, all executed within a single,\r\nintegrated system.\r\nNowadays, real attackers and cyber threat actors have been used this tool a lot in their operations to conduct a\r\ncyber-attack against their target. Today, we see another evolution of Cobalt Strike where the threat actor has\r\ndeveloped a Linux version of a payload of Cobalt Strike where it gets 0 detection in the VirusTotal and remains\r\nstealthy in our client premises for more than 3 months.\r\nGraph flow\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 1 of 8\n\nFigure 1: Graph flow of the malware\r\nBased on figure 1, the malware has a simple function routine. The core function of this malware is to make the\r\nbeacon connection to the attacker Cobalt Strike server via DNS using the Cobalt Strike Malleable C2 config\r\nembedded in the malware. The other interesting part when reversing this malware is how they decrypt strings and\r\ndata in the heap and parse those data to set up the DNS request.\r\nTechnical analysis findings\r\nInitial assessment\r\nBased on the THOR scanner’s result given to the Netbytesec team, the hashes of the malware are as follows:\r\n3db3e55b16a7b1b1afb970d5e77c5d98\r\nc5718ec198d13ef5e3f81cecd0811c98\r\nThe YARA rule that matched with the THOR scanner detection is “CobaltStrike_C2_Encoded_Config_Indicator”\r\nwhich creates the first bad indicator of this malicious file.\r\nThe Netbytesec analyst try to run the malware in our malware analysis lab using Ubuntu 20.04 OS but the\r\nmalware giving an error related to library dependencies. \r\nTested on Ubuntu distro\r\nAfter verifying the infected server’s OS which is CentOS 7, the Netbytesec team runs the program in CentOS 7 to\r\nmimic the real infected infrastructure of the malware executed. As a result, the malware successfully runs in\r\nCentOS 7 without any error unlike in the Ubuntu OS. The Netbytesec team believes that the malware was\r\ncustomized to run only in RedHat Distribution as the Netbytesec experimenting to run the malware in Debian and\r\nUbuntu and give us the same error result.\r\nTested on CentOS 7\r\nOur first initial assessment is to check for any detection from the Anti-Virus engine in the VirusTotal as our client\r\nhas uploaded the malware into the VirusTotal. The malware has zero detection in VirusTotal as shown in figure 2\r\nwhich is quite interesting to reverse this binary.\r\nFigure 2: VirusTotal result\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 2 of 8\n\nWhile in the Joe Sandbox, the file was detected as malicious with 48 scores per 100. In the sandbox result, the\r\nmalware was detected as highly malicious only because of the YARA signatures that detect Cobalt Strike C2\r\nencoded profile config instead of malicious behavior activity.\r\nFigure 3: Joe Sandbox result\r\nFigure 4: YARA signature in Joe Sandbox\r\nTo verify the Cobalt Strike C2 profile, the Netbytesec analyst manually analyzed the Linux program without\r\ndepending only on the YARA signature as it can be false positive. The Netbytesec analyst parses the profile config\r\nto extract the information of the Cobalt Strike config. As shown in figure 5 below, the information about the\r\nCobalt Strike C2 config profile can be read include the C2 server DNS and other details.\r\nFigure 5: CS config information\r\nBased on figure 5, the beacon type of this malware will be deliver using DNS. Thus, DNS beaconing will be\r\nperformed when the malware is executed. Also, we can see the “PublicKey_MD5” value. Once the beacon is\r\nexecuted, the beacon then needs to communicate with the Team Server. Whenever a beacon checks in to the\r\nCobalt Strike Team Server destination, it sends an encrypted metadata blob. The metadata blob is encrypted using\r\nthis RSA public key, extracted from the stager which is the malware. The other interesting information about the\r\nconfig is how the data communication request headers include GET and POST requests between the infected\r\nmachine and the Cobalt Strike team server will be communicated after the malware run.\r\nThe malware used two C2 server domains which are update.microsoftkernel.com and update.microsofthk.com.\r\nInspecting both domains showing that the domains resolved to IP address 160.202.163.100 and last seen was in\r\n2021-09-06. From the result above, the Netbytesec team conduct OSINT research on both domains and found a\r\ntweet about it from the year 2019. Based on the tweet shown in the figure below, this is another strong indicator\r\nthat the author of the malware uses the Cobalt Strike tool as part of the cyberattack on our client-server\r\ninfrastructure.\r\nFigure 6: A tweet containing both C2 server domains\r\nReverse engineering analysis\r\nFocusing on the malware inner code itself, once the malware is executed, it will run in the background silently\r\nwithout giving any output on the screen as the first code of the main function of the malware is calling the daemon\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 3 of 8\n\nfunction at line 8 shown in the decompiler screenshot below. (Most of the function has been renamed to ease our\r\nanalysis).\r\nFigure 7: The first part of the main function\r\nAt the address 4035F3 (line 9), the malware will execute a subroutine renamed as “wrap_sys_getid” which will be\r\nused to get thread ID (TID) or the Process ID (PID) of the running malware. This called function will return the\r\nnumber of the TID and serve the number into function “j_srand” to generate an integer number.\r\nOn the next line at the address 4035FF which is renamed as “wrap_decryption”, the malware calls this subroutine\r\nfunction that will be used to decrypt and parse most of the encrypted strings and data in the malware executable to\r\nbe used to create network request to the attacker infrastructure. In figure 8 below, the decryption routine of the\r\nXOR encoded Cobalt Strike config using XOR key 0x69.\r\nFigure 8: Decryption algorithm of encoded CS config\r\nMoreover, in the function renamed as “wrap_decryption”, the malware also includes a function to read resolver\r\nconfiguration files which are used to configure DNS name servers in Linux OS.\r\nFigure 9: Read resolve.conf\r\nWhen debugging a part of “wrap_decryption”, there is a part where the program will parse out the C2 domains\r\nfrom the config allocated in memory previously explained. The parsed C2 domains is made at the line shown in\r\nFigures 10.\r\nFigure 10: Parsing the first C2 domain from config\r\n \r\nThe below figure shows some of the strings that have been decrypted and parsed in memory after the function\r\n“wrap_wrap_decryption” finished execute. These strings did not appear if the program are not running. Thus,\r\ndynamic analysis or execution is required to dump the strings from the memory. These strings then will be used to\r\nbuild and create C2 communication in a function renamed as “wrap_connection_c2” explain later.\r\nFigure 12: In-memory strings\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 4 of 8\n\nBesides that, another interesting function to investigate is a function renamed as\r\n“wrap_enumeration_and_createb64”. In the subroutine function, it will enumerate and get the infected host’s\r\ninformation.\r\nFigure 13: Subroutine wrap_enumeration_and_createb64 decompiled code\r\nFor example, in the following figure, the malware tries to get the process ID and uname.\r\nFigure 14: Function getpid and wrap_uname get the call\r\nOther than that, the information that the malware enumerates is the PID of the process, IP address of the host,\r\nUID, hostname, and kernel info. All this info will be appended and save in the heap. This collected host\r\ninformation will be encrypted using the public RSA key then encoded using base64. The construction of the\r\nbase64 string in the malware is located at function address 0x40C53B.\r\nFigure 15: Base64 construction\r\nThe generation of the base64 is using the base64 BIO filter function from the OpenSSL crypto library. This is a\r\nfilter BIO that base64 encodes any data written through it and decodes any data read through it. The base64 will\r\nbe saved in the heap that will be used as part of communication in the DNS beaconing.\r\nThe last part of the malware’s core functionality is the C2 connection and sleep function shown in the red box as\r\nfollows:\r\nFigure 16: While loop of the C2 beacon connection\r\nThe function “wrap_connection_c2” is a switch case that contains 6 cases. The most important and interesting\r\ncase is case 2 where all the beacon connections are created and make to communicate with the C2 server.\r\nFigure 17: Part of case 2 code\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 5 of 8\n\nIn the sub_40D440 subroutine function, the Netbytesec team analyst discovers the IP address of the Cobalt Strike\r\nas it appends the IP address to the request header “Host: ”. As seen in the figure below, IP address\r\n160.202.163.100 is matching with the PCAP communication. This IP address is matching with the previous\r\nOSINT research result on both domains.\r\nFigure 18: IP address append to host\r\nOSINT research on this IP found that the IP has a historical record of the Cobalt Strike server using port 80.\r\n \r\nFigure 19: https://github.com/fox-it/cobaltstrike-extraneous-space/blob/master/cobaltstrike-servers.csv\r\nAlso, the passive DNS of the IP is matched with the DNS found early which are microsoftkernel.com and\r\nmicrosofthk.com. The IP was also flagged as malicious which has communicated with a malicious file recently.\r\nFigure 20: Virustotal result of the malicious IP\r\nFinally, the connection is officially create using the function BIO_s_connect(). This is a wrapper around the\r\nplatform's TCP/IP socket connection routines. The connection is created and set up using the strings and data like\r\nURL and cookies append along with the GET request headers to complete the connection to the attacker\r\ninfrastructure.\r\nFigure 21: Function BIO_s_connect called by the malware\r\nDNS beaconing\r\nThe figure below shows the malware requesting tasks via DNS which response using the TXT channel.\r\n \r\nFigure 25: Pcap capture of the TXT query and response\r\nThe result of the TXT query is encoded in base64 and encrypted in AES contains the task from the Team Server.\r\nFor example:\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 6 of 8\n\nFigure 26: Pcap capture of the TXT query and response\r\nAs explained from the CS blog, when Cobalt Strike’s DNS server gets the request, it checks if any tasks are\r\navailable for that Beacon instance. If no tasks are available, it returns a response that tells Beacon to go to sleep. If\r\na task is available, the Cobalt Strike DNS server returns an IP address. The compromised system then connects to\r\nthat IP address and makes an HTTP GET request to download its tasks. The tasks are encrypted. That's why we\r\nsee there is HTTP GET request construction in the code. This is the hybrid communication model. The idea here is\r\nthat DNS requests on a regular interval are less likely to get noticed than, say, HTTP requests on a regular interval.\r\nTo track the compromise events, the NetByteSec Splunk analyst discovers that a few servers of our client's have\r\nmade the DNS beaconing to the Cobalt Strike since April 2021.\r\n \r\nFigure 27: Splunk detection on the IP\r\nConclusion\r\nThe attacker has dropped their malicious software in the servers and run the malware. The malware has the ability\r\nto run in the background and create a DNS beacon connection to the Cobalt Strike C2 server hosted on IP\r\n160.202.163.100. Before the malware is set up and creates the connection, the malware will decrypt a lot of\r\nstrings and data include Cobalt Strike config, and then parse and append it to the function that will make the\r\nconnection function. Most of the findings of OSINT research of the found IP address and Domain tell that these\r\nIOCs are positive belong to an attacker that is using the Cobalt Strike tool to conduct the attack. The Netbytesec\r\nteam believes that this cyber attack was conducted by an actor who were able to tweak and port the Cobalt Strike\r\npayload to Linux's based version and remain stealthy after compromised our client.\r\nIndicator of Compromises \r\nIP address\r\n160.202.163.100\r\nDomains\r\nmicrosoftkernel.com\r\nmicrosofthk.com\r\nSubdomains\r\nupdate.microsoftkernel.com\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 7 of 8\n\nupdate.microsofthk.com\r\nHash\r\n3db3e55b16a7b1b1afb970d5e77c5d98\r\nc5718ec198d13ef5e3f81cecd0811c98\r\nSource: https://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nhttps://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://notes.netbytesec.com/2021/09/discovering-linux-elf-beacon-of-cobalt_18.html" ], "report_names": [ "discovering-linux-elf-beacon-of-cobalt_18.html" ], "threat_actors": [ { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434239, "ts_updated_at": 1775826762, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8efea1b6898cfbce38cecf5a0092b333bb6c77ea.pdf", "text": "https://archive.orkl.eu/8efea1b6898cfbce38cecf5a0092b333bb6c77ea.txt", "img": "https://archive.orkl.eu/8efea1b6898cfbce38cecf5a0092b333bb6c77ea.jpg" } }