Introducing LDAP C2 for C3

Introduction

WithSecure are pleased to announce that C3 now supports C2 over LDAP, adding a much-needed internal channel to C3’s arsenal.

C2 (Command & Control) over LDAP is not a new concept, and WithSecure’s implementation has been built on top of fantastic research by others in the community[1][2]. Rather than re-invent the wheel, this post provides an actionable quick start guide to help you get up and running.

Prerequisites

This post assumes you are familiar with C3 and already have a working deployment. If you don’t, I’d suggest checking out our introduction to C3 here, which will walk you through the steps you need to deploy C3 in anger.

Quick Start

Once an initial foothold has been obtained using an alternative channel type, follow the steps below to use LDAP for internal C2.

• From an existing Gateway/Relay, select AddNegotiationChannelLDAP
• Fill in attributes:
  • Data LDAP Attribute – The attribute used to send & receive packets. The default is mSMQSignCertificates as it doesn’t require special privileges to modify, is large (1MB), and is rarely ever set. Manually check that it is empty before using.
  • Lock LDAP Attribute – The attribute used to track which channel the message in the Data LDAP Attribute is destined for. This is needed so that multiple relay instances can use the same account & attribute for C2, limiting the number of compromised accounts needed for lateral movement. Manually check that it is empty before using.
  • Max Packet Size – The maximum size of the packets that C3 should attempt to write to the given Data LDAP Attribute. This will be different if you change the Data LDAP Attribute above.
  • Domain Controller – Both sides of the channel must communicate with the same domain controller, and therefore this can’t be determined programmatically. If different domain controllers are used, it can take 15 minutes for changes to propagate, impacting the channel’s performance. Must use the FQDN, for example DC1.FSECURE.COM.
  • Username – The UPN of an account with permissions to modify the target user’s attributes (often the target user itself). Must be specified in UPN format, for example JAMES@FSECURE.COM. Defaults to the user executing the relay if left blank.
  • Password – The password for the account with permissions to modify the target user’s attributes. Defaults to the user executing the relay if left blank.
  • User Distinguished Name – The user whose attributes should be changed. This is often the same user as above, however doesn’t need to be. Can’t be left blank, and must be in the DN format, for example CN=James,CN=Users,DC=fsecure,DC=com
• Click on Send Command to create the LDAP channel
• Double click on your newly-created Channel and select New Relay. The fields will be auto-populated to match what you selected during channel creation
• Click on Create and Download Relay
• Run relay on target

Demonstration

The video below shows initial channel creation using the credentials of an account which has the ability to modify the test.user’s attributes. To simulate a real scenario, initial access to the target network was achieved using an alternative channel type and this channel is being created to emulate lateral movement to a target internal machine.

To extend this scenario further, the video below shows an additional channel being created off of the original foothold, however this time omitting the username and password. This means both sides of the channel must be executed under the context of an account which has the privileges to the modify the attributes of the user specified by the User DN.

Multiple relays can be operated using the same channel, meaning the same relay payload can be executed multiple times without needing to reconfigure the account/attributes that are modified. This would be particularly useful when using the payload in an internal phishing campaign or backdoored document.