• Using XMPP for Botnet C&C (Shmoocon Submission)

    by  • December 18, 2010 • Uncategorized

    My idea for Shmoocon didn’t get accepted this time around so I figured I would post it up on the blog. I haven’t done too much with it all, but I have some code for a working plugin if anyone is interested. The code itself does not do everything mentioned below, but it is a good start to build off of. I personally would love to see XMPP added to as a botnet C&C just to see if it were truly beneficial. If anyone has heard of it being used, please shoot me an email or comment.


    Command and Control architectures continue to use older protocols that are easily detected, are often points of failure, and provide limited functionality. Extensible Messaging and Presence Protocol (XMPP) provides communication paths, federated authorization, peer to peer communication, encryption, and numerous other features necessary for a fully functional C&C environment.


    1. Problems with current C&C architectures
      1. Reporting
        • Limited insight into compromised hosts
            • Add geolocation
            • Consult IANA
            • Identification
              • Ports used are easy to spot
                • IRC and other custom ports
              • Poor communications
                • No encryption
              • Communication patterns
                1. Lack of encryption
                2. Limited connectivity back to the server
                3. Not always capable of lateral transmissions
                4. Lack of knowledge share
                5. Lack of file transfer
            • Improvements made over time to C&C architecture
              • Clear communications to encrypted communications
              • Port based C&C to a P2P structure
            • Benefits of XMPP
              1. P2P Server to server and client to client
              2. Encryption
              3. File transfers
              4. Structured XML
                • Extendable
              5. Communications through HTTP/S
                • BOSH
              6. Redundancy
                • XMPP servers
                • BOSH connection managers
                • Database Clustering
              7. Federation
            • XMPP uses within C&C architectures
              1. Encrypted P2P communication and file transfers between compromised clients
                1. Limited out reach to the home servers
                  • One compromised host or a randomly chosen one can talk back home instead of the entire network
                2. Easily notify compromised hosts of updated binaries
                  • Lateral communication reduces outgoing chatter
                3. Lateral communication allowing for multiple paths back home
                  • Compromised hosts can use each other as proxies to get back home
              2. Federated authentication for account
                1. Use other XMPP services (Yahoo and Google or Jabber servers) as a first tier command structure
                  • One username for multiple servers or services
                2. Administration can be a single set of credentials across all servers
                3. Compromised hosts can use public channels for commands or updates through HTTPS
              3. Polling and updates through instant messaging/presence
                1. Send out commands through instant messenger
                  • Send messages to a single bot listener to broadcast
                  • Send individual messages to certain compromised areas
                  • Send messages to individuals using the botnet
                  • Messages queued
                2. View compromised hosts through presence updates (include data of interest)
                  • Extend presence
                  • Identify “who is online” or last checked in
                  • Implement “heartbeat” based on check ins
                3. View compromised hosts within XMPP server portal (extend implementation using API)
                  • Use Java based Openfire
                  • Use Erlang based ejabber
                4. Communicate through public XMPP/Jabber servers
                  • Limited traceback
                  • Many available in other countries
                  • Limited log retention
              4. Extensible protocol to fit needs
                1. Tailor or extend message stanzas or presence information to include additional details
                  • Computer related data
                  • Network data
                  • PII and collection data
              5. Multiple connection methods
                • Connect back to the XMPP server
                • Connect to lateral host
                • Connect to public XMPP server or XMPP service
                • Connect to BOSH server through HTTPS
                • Connect to proxy server (tor)
                • Connect using STUN
            • Demonstration of usage
              1. PoC Java implementation using Openfire
                • Custom view of infected machines based on data sent from compromised host in message/presence payload
                  • Geographic and IANA information added for more context
                • Implementation installed in Amazon EC2
                • Communication start-to-finish
                  1. Host gets compromised
                  2. Host data is collected
                  3. Calls out to Google or XMPP server to send information back home
                  4. Server receives information and interprets it
                  5. Administrator sees new bot in panel with information
                  6. Administrator sends message to compromised host