Recording the new Immersive Labs podcast gives us a chance to throw around several headline-hitting topics in the threat landscape. Last week we were talking about some of the updates made to popular Android banker, Anubis
Malware writers are subject to the same pressures as traditional software dev teams. This means an obligation to constantly feed customers new functionality, but the painful customer feedback posts also deserve a mention (hack forums can be brutal).
Anubis has been in the spotlight recently for developing some interesting new features. Version 2.5, for example, builds on already advanced banker capabilities to allow the controller to tell if their victim is looking at the screen, enabling illicit actions to be performed more covertly.
This made me curious; with such advanced functionality, how much time was the developer spending to ensure the encrypted traffic was protected – and could it be decrypted? Would it be possible to teach blue teams to analyze network traffic coming from an infected device in their network and extract the data with a lab?
It turns out we could do more than this. Without giving away too much too soon, we not only found that it was easy to capture traffic but also discovered a new vulnerability allowing us to inject JS and compromise the whole C2.
There were obviously two ways to start the research; connecting a real device to a live C2 and doing the pcap that way felt unethical, so we stood up our own version. We did this using a leaked version of 2.5 and, after some work, managed to get a working docker container.
After identifying the C2 portion of the PHP panel code, we quickly realized the developer wasn’t sanitizing traffic from our “infected device” to the control panel database. From here, it was a case of carrying out an XSS attack on the affected portion of code, resulting in full control of the panel.
https://youtu.be/R4Ow5dhQua0
In a live environment, this would give me the ability to take full control of all infected devices, oversee data captured from victims, and even issue an uninstall command to every victim device.
You will notice, however, that we’ve spared the more detailed instructions of how to carry out the attack and are not posting a full POC. We took this decision to stop others misusing the vulnerability, as there are real victims of Anubis and we didn’t want to enable further exploitation.
While we didn’t go through responsible disclosure on this one with the Anubis software development team, we have passed on details to the NCSC and other relevant authorities to help them in their investigations.
As a closing note, while reviewing the source code it was clear the malware author had attempted to protect against this type of issue. However, they failed to correctly implement it, resulting in the vulnerability above. Perhaps, given the right skills development opportunities, they could have used their abilities in a defensive, as opposed to malicious, capacity?