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 old customers, whose last year I introduced telephony for the call center of the online store. There I installed and configured only and exclusively Asterisk with accompanying packages, the local system administrator was engaged in installing the server and OS (Ubuntu), as well as supporting the system after implementation, and from time to time I was approached with one-time non-trivial tasks that required 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 in turn.
Having agreed on the cost and timing, I set to work. What was my surprise when after turning on the logging of incomplete calls in the CDR, a stream of records a la “UNKNOWN UNKNOWN” with the status “FAILED” started! Moreover, dialing attempts were directed to several Lithuanian numbers in the code +370.
Since the idea of connecting from the outside to the asterisk itself was immediately rejected after verification (all security recommendations were implemented at the implementation stage, there were fail2ban, and sip accounts had a strict ip restriction), and at the same time AMI was disabled, there was only one option - call files. And so it turned out. Clarified with the client: they did not use this technology and, moreover, did not call to Lithuania. Morality? That's right, a trivial hack.
When deleting call-files, they appeared again after some time. Expectedly, nothing extra was found in cron. After scratching my head, I started lsof cyclically - but he could not catch anything interesting in outgoing. Then after a short googling, heavy artillery - inotify_tools - went into battle. A curious picture emerged: something constantly generated the notorious files at a few pieces per second. From which I concluded that I was dealing not with a scheduled task, but with a process or a daemon.
Then it’s simpler: through top and ps, a suspicious process called “backup” was quickly caught and was located in /var/tmp/bkb.d. It turned out to be the simplest script, constantly copying dozens of call files lying in the same place in / var / spool / asterisk / outgoing, containing the initiation of an international call to various Lithuanian numbers. At the same time, what’s most interesting, calls (or rather, dialing attempts) were made through a non-existent trunk, and the call-files did not indicate a connection after dialing with someone else.
Having cut out the malware and made the required modifications to the CDR logic, I informed the client of the estimated time for hacking and expectedly received a separate material gratitude for discovering this fact. What he will do with this further - I do not know, the task of finding a hole through which hacking became possible was not in front of me. Although only SIP, SSH and statistics closed by http-authorization stuck out there (of course, Apache, like the asterisk, did not run from the root), so the choice is small.
Perhaps there was a simpler and quicker solution to search for malware - but I still do not consider myself a linux broad-based admin, and applied what came to my mind and wentogled along the way. However, I still do not understand who, like, and, most importantly, why made such a meaningless hack.
The other day I was approached by one of my rather old customers, whose last year I introduced telephony for the call center of the online store. There I installed and configured only and exclusively Asterisk with accompanying packages, the local system administrator was engaged in installing the server and OS (Ubuntu), as well as supporting the system after implementation, and from time to time I was approached with one-time non-trivial tasks that required 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 in turn.
Having agreed on the cost and timing, I set to work. What was my surprise when after turning on the logging of incomplete calls in the CDR, a stream of records a la “UNKNOWN UNKNOWN” with the status “FAILED” started! Moreover, dialing attempts were directed to several Lithuanian numbers in the code +370.
Since the idea of connecting from the outside to the asterisk itself was immediately rejected after verification (all security recommendations were implemented at the implementation stage, there were fail2ban, and sip accounts had a strict ip restriction), and at the same time AMI was disabled, there was only one option - call files. And so it turned out. Clarified with the client: they did not use this technology and, moreover, did not call to Lithuania. Morality? That's right, a trivial hack.
When deleting call-files, they appeared again after some time. Expectedly, nothing extra was found in cron. After scratching my head, I started lsof cyclically - but he could not catch anything interesting in outgoing. Then after a short googling, heavy artillery - inotify_tools - went into battle. A curious picture emerged: something constantly generated the notorious files at a few pieces per second. From which I concluded that I was dealing not with a scheduled task, but with a process or a daemon.
Then it’s simpler: through top and ps, a suspicious process called “backup” was quickly caught and was located in /var/tmp/bkb.d. It turned out to be the simplest script, constantly copying dozens of call files lying in the same place in / var / spool / asterisk / outgoing, containing the initiation of an international call to various Lithuanian numbers. At the same time, what’s most interesting, calls (or rather, dialing attempts) were made through a non-existent trunk, and the call-files did not indicate a connection after dialing with someone else.
Having cut out the malware and made the required modifications to the CDR logic, I informed the client of the estimated time for hacking and expectedly received a separate material gratitude for discovering this fact. What he will do with this further - I do not know, the task of finding a hole through which hacking became possible was not in front of me. Although only SIP, SSH and statistics closed by http-authorization stuck out there (of course, Apache, like the asterisk, did not run from the root), so the choice is small.
Perhaps there was a simpler and quicker solution to search for malware - but I still do not consider myself a linux broad-based admin, and applied what came to my mind and wentogled along the way. However, I still do not understand who, like, and, most importantly, why made such a meaningless hack.