Back in January I made a post about a talk I submitted to Shmoocon. You can check it out here, but basically it was proposing and demonstrating the use of XMPP as a command and control channel instead of something like plain HTTP or IRC. I list the benefits in the outline along with some other details, so I won’t focus on them here. Instead I want to provide a glimpse into the basic work I have done thus far with the XMPP bots and post the code I have so others can begin thinking about this issue.
There are a bunch of different XMPP servers you can go with when choosing your solution, but I ended up choosing openfire. I hate the Java aspect to it, but the interface is extremely clean, robust and it has a lot of support for plugins. With that said, plugins come in different forms and implementations making it difficult to know which fits your environment best. To be honest, I wanted to go the easiest route and that sounded like an internal component for openfire. This meant grabbing the openfire source, looking at a couple other plugins and building off those. I was able to get some plugins to work in a basic form, but troubleshooting was a nightmare, the API wasn’t too clear and the development environment seemed to just be an ANT script made for building everything out; no other fancy hooks or tools to assist in the creation.
I took a step back from my design and thought about what I needed from a command and control perspective. Ideally what I need is a bot to be up at all times, queue messages, accept incoming connections, parse out commands and persist data in some fashion. Sounds easy enough and after googling around I was able to find a nice python bot class that allowed for easy expansion through inheritance. The source code for the bot was only 500 lines, so I was quickly able to go through the code, make some slight changes and have it installed. It should be noted here that with this class, I would decouple the bot from the actual XMPP server installation making it portable to any server, not just openfire. The bot would be completely self-contained and act as a user on the system rather than a part of the system itself.
With this change comes disadvantages though:
- Harder to control the server operations since you are not native
- Building your own interface to display data instead of plugging into existing architecture
- Ensuring the bot is always running and that the process doesn’t die
- Adding in support to handle additional features or getting them to work with the existing server
With the infrasturctue laid out it was time to spin up some quick bot code to handle a simple task that could show the power these bots have. One of the tasks I find myself doing on a regular basis is comparing bulk data blobs with the malware domain list to indentify if any destination address matches an IP from the list. For this I had a quick python script called uma that would download the list, for through all the addresses, check the blob and let me know if there were any matches. Because the bot is already python and the script it small, I decided to take all the functions and just throw them into the bot.
Here is the code below:
I won’t dive into too much detail of what is going on, but this screenshot should provide a decent idea of how the bot could be useful.
For the exmaple I took a small list of IP addresses I had seen as destination address on the network and fed them to the bot using the scan command. As the bot did the task it let me know where it was in the process and ended up telling me that two of the five addresses I sent were found on the MDL list. What should be taken away from this little bot is that one could easily modify the contents to add more commands and actions. I am currently in the process of putting together a bot will function more like current IRC bots where commands could be sent to perform more functions, persist data and allow for querying remote machines.
In the next post I will cover using the bots in a C&C example which would include:
- federated users (google accounts, public XMPP servers)
- foreign gateways for bonding
- sending data through multiple channels (federated clients, http/s, direct server connections)
- sending and reciving data form end-users