Fleeting malware
I am a freelancer, and my main specialization is Asterisk-based IP telephony solutions.
The other day, I was approached by one of my rather long-standing customers, who last year introduced a telephony for the call center of an online store. There, I installed and configured only Asterisk with accompanying packages, installing the actual server and OS (Ubuntu), as well as supporting the system after implementation, was handled by the local sysadmin, and occasionally I was approached with one-time nontrivial tasks that require more than simple qualifications. editing contexts in dialplan. This time they needed to change the logic of the CDR in terms of statistics of received calls by queues.
Having agreed on the cost and timing, I set to work. What was my surprise when after switching on the logging of incomplete calls to the CDR a stream of records a la "UNKNOWN UNKNOWN" with the status "FAILED" began! Moreover, attempts to dial were sent to several Lithuanian numbers in the code +370.
')
Since the thought of connecting from the outside to the asterisk itself was dropped immediately after checking (all security recommendations were implemented at the implementation stage, there was fail2ban, and sip accounts had a hard ip restriction), and the AMI was disabled, there was only one option - call-files. So it turned out. I clarified with the client: they did not use this technology and, moreover, did not call to Lithuania. Morality? Correct, banal hacking.
When deleting call-files, they appeared again after some time. Expectedly, nothing was found in cron. Scratching the back of my head, I ran lsof cyclically - but he could not catch anything interesting outgoing. Then, after a short googling, heavy artillery went - inotify_tools. The picture loomed curious: something constantly generated the notorious files of several pieces per second. From which I concluded that I am not dealing with a scheduled task, but with a process or a demon.
Further, it is simpler: through top and ps, a rather suspicious process was quickly caught, called “backup” and located in /var/tmp/bkb.d. It turned out to be the simplest script that constantly copied to / var / spool / asterisk / outgoing there were a dozen of call-files lying there, which contained the initiation of an international call to various Lithuanian numbers. At the same time, what is most interesting is that calls (more precisely, dialing attempts) were made via a non-existent trunk, and the call-files did not contain an indication of a connection after dialing with someone else.
Having drunk off the malware and having made the required modifications of the CDR logic, I informed the client about the estimated time of the hacking and, as expected, I received a separate financial thanks for discovering this fact. I don’t know what he will do next - I don’t know, the task of finding a hole through which hacking became possible did not stand in front of me. Although only SIP, SSH and the statutory webmord's http-authorization statistics stuck out there (of course, the Apache, like the asterisk, was not launched from under the root), so the choice is small.
It may have been a simpler and faster solution to finding the malware — but I still don’t consider linux to be a broad profile administrator, and applied what came to my mind and googled along the way. However, it is still incomprehensible to me who, like, and most importantly, why he made such a meaningless hack.
The other day, I was approached by one of my rather long-standing customers, who last year introduced a telephony for the call center of an online store. There, I installed and configured only Asterisk with accompanying packages, installing the actual server and OS (Ubuntu), as well as supporting the system after implementation, was handled by the local sysadmin, and occasionally I was approached with one-time nontrivial tasks that require more than simple qualifications. editing contexts in dialplan. This time they needed to change the logic of the CDR in terms of statistics of received calls by queues.
Having agreed on the cost and timing, I set to work. What was my surprise when after switching on the logging of incomplete calls to the CDR a stream of records a la "UNKNOWN UNKNOWN" with the status "FAILED" began! Moreover, attempts to dial were sent to several Lithuanian numbers in the code +370.
')
Since the thought of connecting from the outside to the asterisk itself was dropped immediately after checking (all security recommendations were implemented at the implementation stage, there was fail2ban, and sip accounts had a hard ip restriction), and the AMI was disabled, there was only one option - call-files. So it turned out. I clarified with the client: they did not use this technology and, moreover, did not call to Lithuania. Morality? Correct, banal hacking.
When deleting call-files, they appeared again after some time. Expectedly, nothing was found in cron. Scratching the back of my head, I ran lsof cyclically - but he could not catch anything interesting outgoing. Then, after a short googling, heavy artillery went - inotify_tools. The picture loomed curious: something constantly generated the notorious files of several pieces per second. From which I concluded that I am not dealing with a scheduled task, but with a process or a demon.
Further, it is simpler: through top and ps, a rather suspicious process was quickly caught, called “backup” and located in /var/tmp/bkb.d. It turned out to be the simplest script that constantly copied to / var / spool / asterisk / outgoing there were a dozen of call-files lying there, which contained the initiation of an international call to various Lithuanian numbers. At the same time, what is most interesting is that calls (more precisely, dialing attempts) were made via a non-existent trunk, and the call-files did not contain an indication of a connection after dialing with someone else.
Having drunk off the malware and having made the required modifications of the CDR logic, I informed the client about the estimated time of the hacking and, as expected, I received a separate financial thanks for discovering this fact. I don’t know what he will do next - I don’t know, the task of finding a hole through which hacking became possible did not stand in front of me. Although only SIP, SSH and the statutory webmord's http-authorization statistics stuck out there (of course, the Apache, like the asterisk, was not launched from under the root), so the choice is small.
It may have been a simpler and faster solution to finding the malware — but I still don’t consider linux to be a broad profile administrator, and applied what came to my mind and googled along the way. However, it is still incomprehensible to me who, like, and most importantly, why he made such a meaningless hack.
Source: https://habr.com/ru/post/175959/
All Articles