{
	"id": "7ef6ae5c-1fed-4e36-b987-d12983e96686",
	"created_at": "2026-04-06T01:29:51.828128Z",
	"updated_at": "2026-04-10T03:21:11.356461Z",
	"deleted_at": null,
	"sha1_hash": "dfc5318f9d658732606cf4ae86924a2f4ad8b921",
	"title": "New BotenaGo Variant Discovered by Nozomi Networks Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1333934,
	"plain_text": "New BotenaGo Variant Discovered by Nozomi Networks Labs\r\nBy Nozomi Networks\r\nPublished: 2023-11-03 · Archived: 2026-04-06 00:21:28 UTC\r\nAccording to AT\u0026T Alien Labs, BotenaGo malware has been deployed with over 30 exploit functions, putting\r\nmillions of IoT devices at risk of potential cyberattacks. BotenaGo is written in “Go”, which is a Google open-source programming language. While the use of open-source programming languages has its benefits, attackers\r\nhave equally taken advantage, using Go to code malicious malware.\r\nOur research highlights Nozomi Networks Labs’ discovery of a new variant of the BotenaGo malware that\r\nspecifically targets Lilin security camera DVR devices. We have named this sample “Lillin scanner” because of\r\nthe name the developers used for it in the source code: /root/lillin.go. Let’s dive deeper into the functionality of\r\nthis sample to show step-by-step how these kinds of scanners work.\r\nFigure 1. BotenaGo source code.\r\nThe source code of the BotenaGo malware (Figure 1) was leaked in October 2021, which led to the creation of\r\nnew variants based on the original. We decided to monitor samples that could have been generated utilizing parts\r\nof the BotenaGo source code. In doing so, we discovered a sample that contained certain similarities of BotenaGo.\r\nAt the time of this research, the sample had not been detected by any malware detection engine in VirusTotal\r\n(Figure 2). Although the sample is quite large (2.8 MB), due to being written in Go, the portion of the actual\r\nmalicious code is quite small and focuses on a single task. Its authors removed almost all of the the 30+ exploits\r\npresent in BotenaGo’s original source code and reused some parts to exploit a different vulnerability that was over\r\ntwo years old. This may be why the sample hasn’t been detected until now.\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 1 of 8\n\nFigure 2. The file is not detected as a threat.\r\nLillin Scanner Functionality\r\nIn order to run, the scanner/exploiter needs a parameter to be passed in the command line. That will be the port\r\nbeing used to connect to each of the IP addresses that the program targets. Lillin scanner differs from BotenaGo in\r\nthat it doesn’t check the banner for the given IPs. It is possible that this tool is chained with another program that\r\nbuilds lists of Lilin devices using services like Shodan or other mass scanning tools.\r\nNext, the sample will iterate over the IP addresses that it receives from the standard input. This portion of the code\r\ncan easily be spotted in the original BotenaGo source code. These instructions will create one Goroutine (a sort of\r\nthread used in Go) per IP address executing the infectFunctionLilinDvr function, which follows the same naming\r\nconvention as in BotenaGo.\r\nFigure 3. A loop creating Goroutines using the input from STDIN.\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 2 of 8\n\nThe presence of strings with the names of the functions and the absence of any protection (many malware families\r\nuse at least the modified version of UPX) means that it isn’t actually trying to protect itself against security\r\nproducts and reverse engineers. It reinforces the theory that this executable might mainly be intended to be used\r\nby attackers in manual mode.\r\nDevice Access and Vulnerability Exploitation\r\nWhen the infectFunctionLilinDvr function receives the IP address to scan, it first checks if the device behind that\r\nIP can be accessed. The Lillin scanner contains 11 pairs of user-password credentials in its code. This is a\r\ndifference from previous malware samples that, reportedly, abused only the credentials root/icatch99 and\r\nreport/8Jg0SR8K50. These credentials are Base64-encoded to be used in the basic authentication needed to\r\nexploit the vulnerability that allows the Remote Code Execution (RCE).\r\nFigure 4. Credentials used for bruteforce access to the DVRs.\r\nFigure 5. Basic authentication attempt.\r\nLillin scanner will loop over the 11 encoded credentials and will sequentially try to access the root directory,\r\nchanging the Base64 string in the Authorization field. When the server response contains the string HTTP/1.1 200\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 3 of 8\n\nor HTTP/1.0 200 it will consider the authentication to be successful and will attempt the exploitation of the\r\nNetwork Time Protocol (NTP) configuration vulnerability.\r\nThis vulnerability, part of a set of security vulnerabilities affecting Lilin DVRs, was discovered in 2020 and was\r\nassigned a CVSS v3.1 score of 10.0 (Critical) by the vendor.\r\nThe scanner will send particularly crafted HTTP POST requests to the URL paths /dvr/cmd and /cn/cmd in order\r\nto exploit a command injection vulnerability in the web interface.\r\nFirst, the scanner attempts to inject some code by submitting a POST request to the URL path /dvr/cmd. If\r\nsuccessful, this request then modifies the NTP configuration of the camera. The modified configuration contains a\r\ncommand that, because of the vulnerability, will attempt to download a file named wget.sh from the IP address\r\n136.144.41[.]169 and then immediately execute its content. If the command injection to /dvr/cmd is not\r\nsuccessful, the scanner attempts the same attack to the endpoint /cn/cmd.\r\nOnce the attack is complete, another request to the same endpoint restores the original NTP configuration.\r\nFigure 6. POST request with the injected wget command.\r\nThe file wget.sh recursively downloads multiple executables for multiple architectures from 136.144.41[.]169.\r\nThe targeted architectures are ARM, Motorola 68000, MIPS, PowerPC, SPARC, SuperH, x86.\r\nFigure 7. The content of wget.sh file.\r\nThe Mirai Malware Family\r\nIn the third stage of this attack, multiple malicious samples for each architecture attempt to execute on the camera.\r\nThese samples belong to the Mirai malware family, which is a widely known threat to IoT devices. All these\r\nsamples have recently been submitted to VirusTotal (at the beginning of March 2022). For example, for the MIPS\r\narchitecture, two samples have been identified as the third stage connected to the Mirai family:\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 4 of 8\n\nae0185189e463c6abddf8865972dac72630b6e515e79d3f7566f0983a0eae295\r\n28f50f24c930b595f88257748f62d985436ecce1330ff52f09cdd13642591450\r\nFigure 8. TVirusTotal graph showing the connection between the two ELF samples and wget\r\nrequest contained in the wget.sh file.\r\nFor x86 architecture, the file 62ef086111b6816d332e298d00ac946c11fac0ed8708fa2668ad3c91ceb96dbf is\r\ndownloaded and executed. An analysis of this sample reveals some typical behaviors of the Mirai malware. For\r\nexample, while scanning new devices, Mirai typically bruteforces the authentication using a list of hardcoded\r\ncredentials. In Figure 9, there is a non-exhaustive list of credentials used for the bruteforce. This list comes from\r\nthe Mirai source code.\r\nFigure 9. Non-exhaustive list of hardcoded credentials used by Mirai malware from the source\r\ncode.\r\nFrom the static analysis of the downloaded sample, we retrieved a list of credentials used in the scanning module,\r\nmany of which are the same as the ones hardcoded in the Mirai source code.\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 5 of 8\n\nFigure 10. A portion of code from sample\r\n62ef086111b6816d332e298d00ac946c11fac0ed8708fa2668ad3c91ceb96dbf using the same\r\ncredentials hardcoded in the source code.\r\nAnother behavior associated with the Mirai botnet is the exclusion of IP ranges belonging to the internal networks\r\nof the U.S. Department of Defense (DoD), U.S. Postal Service (USPS), General Electric (GE), Hewlett-Packard\r\n(HP), and others. Some of them are visible in Figure 11, which is taken from Mirai’s source code.\r\nFigure 11. Some of the IP ranges listed in the source code that are excluded while scanning.\r\nThe same IP ranges are excluded from the scanning procedure in the sample we are analyzing. Moreover, we see\r\nthat the verification of a randomly generated IP follows the same algorithm as the one implemented in Mirai’s\r\nsource code.\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 6 of 8\n\nFigure 12. Portion of the sample code excluding some IP ranges while generating the IPs to scan.\r\nIt seems that this tool has been quickly built using the code base of the BotenaGo malware. It shouldn’t be\r\nconfused with a worm as its main goal is to infect its victims with Mirai executables with a list of IP addresses\r\nprovided as input; it can’t automatically propagate itself.\r\nConclusion\r\nApart from working on completely new projects, attackers also commonly re-use already available code to build\r\nnew malware. Monitoring the evolution of these projects helps create more robust and generic detections that\r\nremain proactive for a longer time, thus providing better protections against modern cyberthreats.\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 7 of 8\n\nSource: https://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nhttps://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/\r\nPage 8 of 8\n\nFigure Lillin scanner 5. Basic authentication will loop over attempt. the 11 encoded credentials and will sequentially try to access the root directory, \nchanging the Base64 string in the Authorization field. When the server response contains the string HTTP/1.1 200\n   Page 3 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.nozominetworks.com/blog/new-botenago-variant-discovered-by-nozomi-networks-labs/"
	],
	"report_names": [
		"new-botenago-variant-discovered-by-nozomi-networks-labs"
	],
	"threat_actors": [],
	"ts_created_at": 1775438991,
	"ts_updated_at": 1775791271,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dfc5318f9d658732606cf4ae86924a2f4ad8b921.pdf",
		"text": "https://archive.orkl.eu/dfc5318f9d658732606cf4ae86924a2f4ad8b921.txt",
		"img": "https://archive.orkl.eu/dfc5318f9d658732606cf4ae86924a2f4ad8b921.jpg"
	}
}