{
	"id": "7833f7e9-0de0-47bc-a493-7ee0d7e23189",
	"created_at": "2026-04-06T00:20:53.626713Z",
	"updated_at": "2026-04-10T03:31:18.992713Z",
	"deleted_at": null,
	"sha1_hash": "443fa7ca237589301fca5a1ac5a934b604547195",
	"title": "An analysis of a spam distribution botnet: the inner workings of Onliner Spambot",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1577525,
	"plain_text": "An analysis of a spam distribution botnet: the inner workings of Onliner\r\nSpambot\r\nBy mpeintner\r\nPublished: 2019-07-29 · Archived: 2026-04-05 17:29:16 UTC\r\nSuccessful cybercrime campaigns make use of different elements working together to achieve their common goal. In the\r\ncase of Onliner, the spambot appears to be a key piece of the puzzle in the distribution process. Many malware campaigns\r\nhave been successful because the spamming process was so effective.\r\nBlueliv’s Head of Threat Intelligence, Jose Miguel Esparza, delivered a talk at Botconf explaining the inner workings of a\r\nspam distribution botnet. We discussed internal details of different modules, its Command and Control panel, how it checks\r\nand misuses stolen credentials and the threat actors operating and selling it.\r\nThis blog covers in-depth each of these Onliner modules: their goals, similarities, operating and communication processes\r\nwith the C2 and encryption methods.  \r\nModular Design\r\nOnliner Spambot is built in a modular way, allowing us to classify certain components according to their purpose. We can\r\ndistinguish between different modules based on their functionalities within the overall spamming process. More precisely,\r\nwe analyze the following components:\r\n1. Worker: module aimed at registering new bots and download and execute new modules.\r\n2. Checker SMTP: module aimed at retrieving and validating SMTP credentials for future use in the spamming\r\nprocess.\r\n3. Mailer: module aimed at conducting the spam. This would be the spambot itself, focused on sending emails using\r\npreviously validated SMTP accounts.\r\nIn the past, the Worker module did not exist as a stand-alone executable, but the built in functionality within Onliner\r\nSpambot included the process of downloading the different modules. The procedure was quite simple, if a given DLL\r\nexisted in the C2 then that was downloaded and executed, giving the bot the module functionality. Due to this change, the\r\nOnliner Spambot author separated the module loading from the core, giving more flexibility to the botnet administrators.  \r\nWorker Module\r\nThe Worker component is responsible for registering the bot and following C2 orders. This includes the download,\r\nexecution and update of new modules. We call this module ONLINERWORKER. The sample we are going to analyze in\r\nthis write up was chosen because of its unique nature. The binary comes packed in order to make it harder to reverse and\r\nuses custom encryption methods to communicate with its C2 and decipher new modules.\r\nOverview\r\nStatic analysis tools show this sample was written in Microsoft Visual C++ 8 and has the following compilation date:\r\n03/05/2018 17:01:20. The AV industry detects this malicious threat fairly well. Table T-1.0 summarizes basic attributes from\r\nthis malware sample:\r\nName app07.exe\r\nType PE32 executable (GUI) Intel 80386, for MS Windows\r\nSHA256 110aac69e6c480414d3c924d88087c976c61a311f9d6ed32838fd8888516a450\r\nVirusTotal https://www.virustotal.com/file/110aac69e6c480414d3c924d88087c976c61a311f9d6ed32838fd8888516a450/analysis\r\n(49/67)\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 1 of 16\n\nPEiD\r\nSignature Microsoft Visual C++ 8\r\nCompilation\r\nDate\r\n03/05/2018 17:01:20\r\nT-1.0 Basic attributes from Onliner Spambot Worker component  \r\nWorker Module Analysis (Loader)\r\nThe Onliner Spambot Worker module analyzed acts as an initial dropper. Upon initialization, it creates two copies of the\r\noriginal sample under C:\\Windows with names “sacuqwiwa.exe” and “waitwwswa.exe”.  Subsequently, it tries to run\r\n“sacuqwiwa.exe” as a service. The creation and execution of the service is performed by the use of the well-known API\r\ncalls: OpenSCManager, CreateService, OpenService and StartService.\r\nIf we follow the execution of the first service “sacuqwiwa.exe”, we will see that after an initial sleep loop, it will try to\r\ndecrypt the C2 server.  \r\nOnliner Spambot custom encoding\r\nOnliner Spambot uses a custom encoding algorithm to decode its C2 and to generate keys for module decryption purposes.\r\nThis algorithm will add and subtract values to the actual characters from an initial encoded string to decode it.\r\nMore precisely, it consists of one round loop where all characters from an encoded string are processed only once. A series\r\nof single arithmetic operations (additions and subtractions) are performed on the encoded buffer, one operation per character\r\nuntil the whole string has been processed.\r\nThe following figure shows the encoding routine disassembled. Each of those big blocks is responsible of the addition and\r\nsubtraction operations respectively.\r\nFigure 1. Onliner Spambot custom encoding routine  \r\nHere we have an excerpt of how arithmetic operations are calculated against the original encoded buffer so that we get\r\nsomething closer to the real C2.\r\nInitial String Operation Result\r\nr -2 p\r\ne +3 h\r\nt -4 p\r\n, +2 .\r\np -3 m\r\n` +4 d\r\nc -2 a\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 2 of 16\n\n, +3 /\r\nk -4 g\r\nm +2 o\r\no -3 l\r\n+ +4 /\r\n4 -2 2\r\n0 +3 3\r\n5 -4 1\r\nT-2.0 Onliner Spambot custom encryption breakdown  \r\nWhen the arithmetic operations loop finishes, we end up with the following string as C2:\r\nEncoded C2 After arithmetic operations\r\nret,p`c,kmo+405,320/4/10;,38spve php.mda/gol/231.06.201.49//:ptth\r\nT-3.0 Encoded C2 after initial string finishes arithmetic operations loop  \r\nAfter resolving the first encoding layer, we will get the C2 in reverse order. After this, the malware iterates over a loop\r\nreconstructing the final C2. Figure 2 shows an example of this routine:\r\nFigure 2. Onliner Spambot C2 reverse routine  \r\nOnliner Custom Decoding algorithm\r\nThis custom encoding routine from Onliner uses an array of operators (in this case there are 3 different operators: numbers\r\n2, 3 and 4). For every character, it is going to apply an arithmetic operation (as noted, it is going to consist of sequential\r\nadditions and subtractions for each of those operators).\r\nAn equivalent implementation for this encoding routine can be found here. However, in the malware code they are not using\r\nmodulo operation. Instead, they manage the loop logic with conditional if statements (which are less efficient and readable).\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 3 of 16\n\nFigure 3. Onliner Spambot custom encoding routine decompiled\r\ndef decode(s):\r\n \"\"\"\r\n Onliner SpamBot decoding routine\r\n \"\"\"\r\n result = ''\r\n sign = 1\r\n position = 0\r\n operations = [2,3,4]\r\n \r\n for char in s:\r\n \r\n original_num = ord(char)\r\n if sign \u003e 0:\r\n # We must substract\r\n final_num = original_num - operations[position]\r\n \r\n else:\r\n # We must add\r\n final_num = original_num + operations[position]\r\n sign *= -1\r\n position = (position + 1) % 3\r\n result += '{}'.format(chr(final_num))\r\n # Sort C2\r\n result = result[::-1]\r\n \r\n return result\r\n \r\nAlthough most Onliner Worker modules have configured only one Command and Control server, we have found some of\r\nthem having built a big array of possible C2s. In this case, each C2 is encoded with the same algorithm.\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 4 of 16\n\nThe module will enter in an infinite loop where it will try to register the new Bot and to receive tasks for it using different\r\nC2s that it has configured. These samples may use more than 200 possible C2. An example of how this array is built can be\r\nseen in the next figure. This is from Onliner Worker sample\r\n64be105d1e5d6e3a9399ebdb30acf18371b1e06e2a26fe5e95c4aeab8ff8a9c8.\r\nFigure 4. Onliner Spambot building C2 array  \r\nWorker Module Analysis (Core)\r\nOnce the Command and Control server is decoded and sorted, this module tries to reach its C2 server by registering the bot.\r\nThis way the C2 can manage and send tasks to it. This would be an example where a Worker module tries to register Bot\r\nwith id 606461253:\r\nFigure 5. Onliner Spambot registering new bot\r\nIf the Bot registration was carried out successfully, we would receive a response with orders for the Bot to follow. In this\r\ncase, the Worker module will have to ask for “0405mail.dll” and “smtp0205.dll”, which stands for Onliner Spambot\r\nMailer and Checker SMTP modules respectively.\r\nFor every task that is downloaded and executed, a new process “waitwwswa.exe” (which as discussed is actually a copy of\r\nthe binary itself) is executed. This new process is executed with the URL to download as its first argument before finally\r\nentering into an infinite sleep loop. In summary, it will launch a different ‘waitwwswa.exe‘ instance for every task. Executed\r\ntasks:\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 5 of 16\n\n1. C:\\Windows\\waitwwswa.exe hxxp://194[.]247[.]13[.]178/0405mail.dll\r\n2. C:\\Windows\\waitwwswa.exe hxxp://94[.]102[.]60[.]132/smtp0205.dll\r\nExecuting the worker module along with one of those arguments results in trying to download and execute the module.\r\nAnalyzing this sample, we got “HTTP/1.1 403 Forbidden” when asking for the Mailer module but got a “HTTP/1.1 200\r\nOK” when asking for the Checker SMTP module. If the download is successful, the malware will try to execute it in a new\r\nthread. One thread for each module. Here you can see the response from the C2, delivering an encrypted module.\r\nFigure 6. Onliner Spambot downloading a XORed module\r\nThis module is XOR-encrypted and the malware will actually need to decrypt it before execution. At first, we thought that\r\nthe malware would parse the module and find the XOR key inside, which would be used to decrypt and execute the\r\ncomponent. In this manner, the malware would be able to decrypt any of those files regardless of their key. In fact, it would\r\nonly need to search for the first sequence of bytes delimited at the beginning and at the end with a NULL byte (0x00).\r\nHowever, the malware uses a hardcoded string to generate the final XOR key using the custom encoding method mentioned\r\nbefore and also making use of MD5 hashing algorithm.\r\nHere we can see an extract from the disassembled decryption routine that is going to use the XOR key to decrypt the\r\nretrieved modules.\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 6 of 16\n\nFigure 7. Onliner Spambot decrypting XORed component\r\nThe initial string “|u|dvbfc8ll5lf=bvgddnfic” comes hardcoded and is used to generate the final XOR key. To do so, it uses\r\nthe same custom encoding method described before and, in addition, it uses MD5 hash function.\r\nIn summary, the initial hardcoded string is transformed using arithmetic operations. Following this, the string is sorted and\r\nused as input for MD5 hash function. The result of this hashing algorithm will be the first half of the XOR key. Then,\r\ncalculating again the MD5 (using as input the result of the previous operation) and adding a NULL byte, we get the last half\r\nof the key. If we concatenate them, we will have the final XOR key.\r\nInitial String After arithmetic operations Sorted\r\nu|dvbfc8ll5lf=bvgddnfic zxxfsfdf4ni9ji9dskbgjhfg gfhjgbksd9ij9in4fdfsfxxz\r\nMessage MD5 digest (First half of the key)\r\nGfhjgbksd9ij9in4fdfsfxxz 72DE4E536F5B27961CCDA70C209782FD\r\nMessage MD5 digest + \\x00 (Last half of the key)\r\n72DE4E536F5B27961CCDA70C209782FD D514C467D79D0993803519C32AF73040+\\x00\r\n  XOR KEY:\r\n72DE4E536F5B27961CCDA70C209782FDD514C467D79D0993803519C32AF73040\\x00\r\nT-4.0 Breakdown from the initial hardcoded string to the final XOR key:  \r\nOnliner Custom XOR key generation algorithm\r\nAs mentioned previously, Onliner Worker is going to download and execute modules sent by its C2. These modules can be\r\nXOR encrypted. In those cases, the malware must be able to know how to decrypt them.\r\nWe now know that Onliner does not recognize the XOR key checking for patterns and that it is not able to decrypt any XOR\r\nencrypted file by guessing the key; instead it is designed to decrypt files with a hardcoded XOR key that comes encoded in\r\nthe binary. This means that these modules have been crafted to work for those encrypted modules.\r\nOnce decryption takes place, it will check if the module is properly decrypted before executing it by looking at the PE\r\nheader and magic number 0x4d5a (which stands for ‘MZ’). The next figure shows these previous validations before actually\r\nexecuting the downloaded module.\r\nFigure 8. Onliner Spambot checking decrypted module before execution\r\nIn our analysis, only the Checker SMTP component was available from the C2 and so only one main working thread was\r\ncreated aimed to execute this module. We can see that the malware received the “smtp0205.dll” module successfully.  \r\nChecker SMTP Module\r\nThe Checker SMTP module is responsible for retrieving huge lists of SMTP credentials (by asking to its C2), checking\r\nthem and keeping track of valid ones to use them for Spamming purposes later.  \r\nOverview\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 7 of 16\n\nStatic analysis tools show this sample was written in Microsoft Visual C++ 8 and has the following compilation date:\r\n23/04/2018 10:46:16. As with the Onliner Spambot Worker module, the AV industry detects this malicious threat reasonably\r\nwell. Table T-5.0 summarizes basic attributes from this malware sample:\r\nName b86b2da3e6f693c83af625a215c398057fba9dc2beea8e5a696bd9ad4d62d786\r\nType PE32 executable (GUI) Intel 80386, for MS Windows\r\nSHA256 b86b2da3e6f693c83af625a215c398057fba9dc2beea8e5a696bd9ad4d62d786\r\nVirusTotal https://www.virustotal.com/file/b86b2da3e6f693c83af625a215c398057fba9dc2beea8e5a696bd9ad4d62d786/analysis/\r\n(45/67)\r\nPEiD\r\nSignature Microsoft Visual C++ 8\r\nCompilation\r\nDate\r\n23/04/2018 10:46:16\r\nT-5.0 Basic attributes from Onliner Spambot Checker SMTP component  \r\nChecker SMTP Module analysis (Load)\r\nThe sample analyzed comes packed. Upon execution, it will do a lot of dummy/unnecessary initialization calls for strings,\r\nlibraries, procedures etc. Once initialized, it loads the real Checker SMTP payload. Everything is done in the same process;\r\nno RunPE/Process Hollowing, DLL injection, or similar is performed. Checker SMTP will only use threads to balance and\r\nmake its functionality modular. For instance, the main thread (which has been executing this sample until now), is only\r\naimed to act as a packer and finally create two threads (which are going to carry out the main job) and wait in an infinite\r\nsleep loop.\r\nBefore any attempt to contact the C2 is made, this module will need to decode the string where the C2 is stored. It will use\r\nthe same method described before in Onliner Spambot Worker module, adding and subtracting values for every character.\r\nOnce C2 is decoded, the Checker SMTP component will start to build the first GET requests that is going to send. In this\r\ncontext, the module will try to download from its C2 the following necessary files before executing its payload: ssleay32.dll,\r\nlibeay32.dll and 7z.dll.\r\nOnliner Spambot uses different GET and POST requests to share information with base64 encoded parameters as an\r\nobfuscated way to communicate with its C2. It needs three different files to properly operate, or else is not going to conduct\r\nmalicious activity. To ask for those files Checker SMTP has to specify it by using the parameter “f1” in a GET request. Upon\r\nsuccessful download, these files are written into %TEMP% directory. Ssleay32.dll is loaded and finally Checker SMTP\r\nmodule starts its core functionality\r\nFigure 9. Onliner Spambot retrieving necessary file to operate: ssleay32.dll  \r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 8 of 16\n\nChecker SMTP Module analysis (Core)\r\nThe first step is to make C2 aware of our Checker SMTP Bot by sending a GET request with parameter 1001=2. Parameter\r\n1001 indicates which is the module that is generating the request and allows the C2 to know how to operate with these. For\r\ninstance, “1000=2” it refers to the Checker SMTP module.\r\nFigure 10. Onliner Spambot retrieving Checker SMTP orders and information\r\nMost relevant parameters in this conversation can be summarized here (BOT, C2):\r\nParameter\r\nname\r\nDescription\r\n1\r\nBot id. Used to identify the bot. Id generated and registered in the Worker\r\ncomponent.\r\n99 Worker Version\r\n2 File Version\r\n74 Control account\r\n77 Mask.zip\r\n78 MD5 digest from the mask.zip file\r\n79 Compressed mask.zip file size (in bytes)\r\n80 Base.zip\r\n81 MD5 digest from the base.zip file\r\n82 Compressed base.zip file size (in bytes)\r\nT-6.0 GET and POST parameters overview for initial Checker SMTP communications  \r\nOnliner Spambot has different mechanisms to protect wrong component versions from trying to establish a communication\r\nwith the C2. Parameters like “WV”, and “\u00262” are aimed to control payload and module versions and to stop communication\r\nwhen these parameters do not comply with the expected values. For instance, “WV” stands for “Worker Version” and “\u00262”\r\nwould refer to a File Version (used for the different components). Load Average at the Server level is also used as a\r\nmechanism to stop communications if the Server Load passes a configured threshold.\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 9 of 16\n\nFigure 11. Onliner Spambot checking Server load and Worker Version\r\nFigure 12. Onliner Spambot checking File Version POST parameter\r\nFigure 13. Onliner Spambot checking Worker Version POST parameter\r\nThe following figure shows C2 rejecting Bot communications because the file version sent in POST parameter “2”, is not\r\nthe one configured in the Command and Control server side.\r\nFigure 14. Onliner Spambot rejecting communication after checking File Version (“2” GET parameter)\r\nIf the initial request was successful, the response from the C2 would include a control account in parameter ‘\u002674‘ (as\r\nexplained in Table T3.0). This is going to be used to ensure that the spamming process works. Validated SMTP credentials\r\nwould be sent to this control account and further used in the Mailer component. The Base64 decoded control account stands\r\nfor:\r\nat***[@]***[.]ca,at***[@]***[.]ca,0**5,smtp.pr***us[.]ca:995\r\nIf all checks have been successfully passed, the Bot will ask for some files necessary to conduct the malicious behavior. It\r\nwill ask for “mask.zip”, and “base.zip” files. These files are necessary to validate credentials and finally send spam. Firstly,\r\nmask.zip is a compressed file containing: “masks.txt”, “dns.txt”, “sub.txt”. The second .zip file contains only one text file\r\nnamed “base.txt”. This last one consists of a huge credentials list with the form of “username:password” from SMTP\r\naccounts that are going to be checked. This list does not include SMTP servers, as this is found in masks.txt, which is used to\r\nknow where to login when checking SMTP credentials.\r\nThe other files tell Checker SMTP module which DNS server should be used when performing DNS requests and\r\nsubdomains to take into account.\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 10 of 16\n\nFigure 15. Onliner Spambot retrieving “mask.zip” to check for SMTP servers\r\nAfter the parsing process finishes, the module will create a thread pool aimed to validate the credentials found in these files.\r\nUpon successful authentication, an email is sent to the control account including the valid address in the “MAIL FROM:”\r\nfield. This field gets parsed automatically in the C2 Server side so that validated SMTP credentials can be properly tracked.\r\nFinally, Checker SMTP module keeps looping infinite and retrieving “mask.zip” and “base.zip” files from its C2. This way\r\nit can check and validate SMTP credentials for further use.\r\nFigure 16. Onliner Spambot sending validated SMTP credential to control account  \r\nMailer Module\r\nThe Mailer component is responsible for sending spam, using SMTP credentials previously validated by the Checker SMTP\r\nmodule.\r\nOverview\r\nStatic analysis tools show this sample was written in Delphi and has the following compilation date: 19/06/1992 22:22:17\r\n(Delphi common compilation date). The AV industry detects this malicious threat quite well. Table T-5.0 summarizes basic\r\nfile attributes from this malware sample:\r\nName 01mail.exe\r\nType PE32 executable (GUI) Intel 80386, for MS Windows\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 11 of 16\n\nSHA256 eef5327bc9db78065840f4f7a95f64f7950a6c84ac2cccc81b92eedc6d4484b6\r\nVirusTotal https://www.virustotal.com/file/eef5327bc9db78065840f4f7a95f64f7950a6c84ac2cccc81b92eedc6d4484b6/analysis/1\r\n(46/66)\r\nPEiD\r\nSignature\r\nBobSoft Mini Delphi -\u003e BoB / BobSoft\r\nCompilation\r\nDate\r\n19/06/1992 22:22:17\r\nT-7.0 Basic file attributes from Onliner Spambot Mailer component  \r\nMailer Module analysis (Load)\r\nThe sample analyzed comes unpacked. Upon execution, it makes a call to one of its exported functions called\r\n“ModuleStart” and after this, enters into an infinite sleep loop.\r\nEverything is done in the same process, like the Checker SMTP module: neither injections nor process creations occur. The\r\nMailer component will rely on thread creation to balance its work.\r\nIn order to carry out the spamming process, it will first need to ask for some necessary files (like we saw before) and so\r\n“ssleay32.dll”, “libeay32.dll” and “7z.dll” are necessary for the Bot to start executing its payload (note that every request\r\nchanges the User-Agent string). We need to decode the C2 before asking for those files obviously and, to do so, Mailer\r\ncomponent uses the same custom encoding algorithm explained before. Once C2 is decoded, the Bot will ask for necessary\r\nfiles before conducting further action:\r\nFigure 17. Onliner Spambot Mailer module asking for necessary files\r\nNote that the Bot is now requesting everything with a different value in the first parameter. As we saw before with “1001=2”\r\nin the Checker SMTP module, now the Mailer uses “1001=4” to identify the module.  \r\nMailer Module analysis (Core)\r\nAfter retrieving all necessary files, it will ask for a group of credentials to start the spamming process. The analyzed sample\r\ncould not communicate properly with the C2 because it was using a wrong number for the file version (parameter “2” from\r\nthe GET request). Mailer module also has checks against this, although no “Worker Version” checks have been found like in\r\nthe Checker SMTP component.\r\nThe following figure shows a proper initial communication between the Mailer module and its C2:\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 12 of 16\n\nFigure 18. Onliner Spambot Mailer module retrieving orders and information\r\nThe most relevant parameters in this conversation can be summarized here (BOT, C2):\r\nParameter\r\nname\r\nDescription\r\n1\r\nBot id. Used to identify the bot. Id generated and registered in the Worker\r\ncomponent.\r\n2 File Version\r\n4 Status\r\n15 Domain Set (C2)\r\n1\r\nBot id. Used to identify the bot. Id generated and registered in the Worker\r\ncomponent.\r\nEt Error Text\r\n26 Control account\r\nT-8.0 GET and POST parameters overview for initial Mailer communications   The Base64 decoded control account stands\r\nfor:\r\nwj[.]te***s.50[@]g***l[.]com\r\nAfter this initial communication, the bot will ask for files needed for spamming purposes. As we explained before, files\r\nneeded to operate are requested using parameter “f1”, but files directly related to malicious activity are requested using\r\nparameter “f2”. Mailer Bots will retrieve two compressed files from its C2. The first one is a list of mail addresses and the\r\nsecond one contains multiple files that are going to be used as a templating for the spamming purpose. In this example, the\r\nsample is downloading a compressed file containing:\r\n1. txt: Message text for the email\r\n2. txt: To set as email sender to disguise\r\n3. txt: To set as email subject\r\n4. txt: Full Spam Mail templating\r\nOnce both files are available for the Bot, only one last thing is needed: valid credentials to send spam. This is how the\r\nMailer component operates: it retrieves support files and valid credentials to accomplish the spamming process. After those\r\nfiles have been retrieved, a new request is made by the Bot. Note that GET parameter “898” is used to specify how many\r\nvalid accounts we want to retrieve (C2 will always try to send us half of the number we asked):\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 13 of 16\n\nFigure 19. Onliner Spambot asking for valid SMTP credentials\r\nWith this information, the Bot can now send mails using valid credentials. The information downloaded in the previous\r\ncompressed files is necessary, as these are templates needed to generate valid mails for the campaign and a list of mail\r\naddresses to send spam to.\r\nThe returned information was following the next format:\r\n\u003cmail_account\u003e,\u003cpassword\u003e,\u003csmtp_server\u003e:\u003cport_number\u003e\r\nThe following figure shows how Mailer module uses the first valid credential received from its C2 to send an email to the\r\ncontrol account. In this way the Mailer module ensures that the overall spamming process works.\r\nFigure 20. Onliner Spambot Mailer component sending Spam to control account\r\nThe following Figure shows how a normal mail for Spamming purposes would look like. In this case, it is sending the mail\r\nwith one of the first valid retrieved SMTP credentials we saw before.\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 14 of 16\n\nFigure 21. Onliner Spambot Mailer component sending Spam (I)\r\nFigure 22. Onliner Spambot Mailer component sending Spam (II)\r\nAfter sending Spam, the Bot will report back its results and ask for more valid credentials to continue operating. Reporting\r\ntakes into consideration the number of successful emails sent and error code. All this information is inserted into Database\r\nfor control purposes at the C2 side. Here is an example:\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 15 of 16\n\nFigure 23. Onliner Spambot Mailer reporting back results from the spamming process  \r\nThe results are base64 encoded and stored in the POST parameter “20”. The result of the decoding would be a list where\r\nevery line refers to a valid credential (previously offered by the C2) and extra information pipe-separated, regarding error\r\ncode and number of successful sent mails with those credentials. It would follow the next format:\r\n\u003cemail_account\u003e,\u003cpassword\u003e,\u003csmtp_server\u003e:\u003cport\u003e|\u003cerror_code\u003e|\u003csuccessful sent\u003e\r\nConclusion\r\nWe have seen that cybercriminals use different methods to distribute malware. This may include malicious advertisements,\r\nexploit kits, loaders or spam campaigns. Unless an attack is really targeted, the bad guys will try to infect as many\r\ncomputers as possible (which often requires a level of automation to achieve it).\r\nIt is well-known that Spam botnets are being used for malware distribution campaigns, and an interesting part of the\r\ncybercrime ecosystem. Tracking spam-distribution botnets offers a lot of insights for threat intelligence: payloads, target\r\ngeolocation, relationship between threat actor groups, etc.\r\nFor more details about how we reverse engineer and analyze malware, visit our targeted malware module page.  \r\nIOCs\r\nHashes\r\n110aac69e6c480414d3c924d88087c976c61a311f9d6ed32838fd8888516a450 (Onliner Worker module)\r\nc2264eaedabde8819dca307975fb8c8682e8579d053165ccd741d6cdf55b6724 (Onliner Worker module with C2 array)\r\nb86b2da3e6f693c83af625a215c398057fba9dc2beea8e5a696bd9ad4d62d786 (Onliner Checker module)\r\neef5327bc9db78065840f4f7a95f64f7950a6c84ac2cccc81b92eedc6d4484b6 (Onliner Mailer module)\r\nIPs\r\n92[.]102[.]60[.]132\r\n194[.]247[.]13[.]178\r\nURLs\r\nhxxp://94[.]102[.]60[.]132/sea/indexh.php\r\nhxxp://94[.]102[.]60[.]132/log/adm.php\r\nhxxp://94[.]102[.]60[.]132/smtp0205.dll (Encrypted Onliner Checker module)\r\nhxxp://194[.]247[.]13[.]178/0405mail.dll (Encrypted Online Mailer module)\r\nReferences\r\nA journey inside Gozi campaign\r\nSpambot safari #2 – Online Mail System\r\nFrom Onliner Spambot to millions of email’s lists and credentials\r\n  This blog post was authored by Alberto Marín and other members of the Blueliv Labs team.\r\nAbout the Author\r\nAlberto leads the Reverse Engineering team at Outpost24's KrakenLabs department. He has been working in cybersecurity\r\nsince 2014, focusing on malware research, reverse engineering, and Sandbox development for automated malware analysis. \r\nSource: https://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nhttps://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://outpost24.com/blog/an-analysis-of-a-spam-distribution-botnet"
	],
	"report_names": [
		"an-analysis-of-a-spam-distribution-botnet"
	],
	"threat_actors": [
		{
			"id": "67bf0462-41a3-4da5-b876-187e9ef7c375",
			"created_at": "2022-10-25T16:07:23.44832Z",
			"updated_at": "2026-04-10T02:00:04.607111Z",
			"deleted_at": null,
			"main_name": "Careto",
			"aliases": [
				"Careto",
				"The Mask",
				"Ugly Face"
			],
			"source_name": "ETDA:Careto",
			"tools": [
				"Careto"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f5bf6853-3f6e-452c-a7b7-8f81c9a27476",
			"created_at": "2023-01-06T13:46:38.677391Z",
			"updated_at": "2026-04-10T02:00:03.064818Z",
			"deleted_at": null,
			"main_name": "Careto",
			"aliases": [
				"The Mask",
				"Ugly Face"
			],
			"source_name": "MISPGALAXY:Careto",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434853,
	"ts_updated_at": 1775791878,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/443fa7ca237589301fca5a1ac5a934b604547195.pdf",
		"text": "https://archive.orkl.eu/443fa7ca237589301fca5a1ac5a934b604547195.txt",
		"img": "https://archive.orkl.eu/443fa7ca237589301fca5a1ac5a934b604547195.jpg"
	}
}