This post describes a new capability that has been deployed within PoshC2, which is designed to assist with revealing a wider set of target environment variables at the dropper stage, as part of operational security controls.
Imagine the following scenario. You’ve deployed IP address white-listing on a proxy in order to limit implant installation to a specific environment. A connection arrives back from a host that’s not associated with your target environment, so the connection is dropped and PoshC2 never sees the incoming connection attempt. By adding some additional logging on the proxy, and utilising the new CookieDecrypter.py script, you can now reveal specific environment variables about where the dropper was executed. This information allows for better decision making on what to do next in this scenario. It yields greater situational awareness.
The background
When carrying out red team testing, a number of safety checks are required to:
- Environmentally key the implant to the target environment variables.
- Make sure only those targeted assets are compromised.
The purpose of this post is not to discuss these safety measures in depth. Rather, it is to instead focus on the problem wherein a target environment has been IP white-listed on the attacking infrastructure, but a connection has come back from an IP address not already on that approved list of target environments. Large organisations do not always readily or thoroughly understand their full external IP address range, or do not force tunnelling of all traffic across a VPN. It is therefore not uncommon to receive legitimate connect backs from non-whitelisted sources.
As a simulated attacker, you now have a decision to make; you have sent very unique malicious links to a target employee and those have been verified as followed, and certain local checks have been satisfied, but the connection is coming from an IP address that’s not on your white-list. The dropper must have been executed and has consequently called back to your attacking infrastructure to download the core implant from the PoshC2 server. Now what?
Further detail
PoshC2’s implant is a staged implant and utilises a dropper to satisfy certain criteria before calling back to the C2 server to pick up a core implant. The dropper uses a unique encryption key specific to the PoshC2 instance, but not unique to each dropper. Each dropper shares the same encryption key; it is only when the core implant is sent down that each implant is uniquely keyed for all further communication.
Generally, the following infrastructure is set up to support a PoshC2 instance. This includes a number of redirectors or Internet Proxies that forward C2 communications back to the PoshC2 instance, limiting exposure of the C2 servers and allowing a flexible approach to building many redirectors to combat take-downs or blocked URL’s.
The redirectors can be made up of any infrastructure or technology, whether it be cloud based redirectors such as CloudFront, or applications running on a host such as Socat, python or Apache, to name a few.
Apache is a preference for its rewrite rules, which can be used to make smart decisions on traffic traversing the proxy. White-listing the X-forwarded-for address is one common method and can be written into rewrite rules using a RewriteMap, as follows.
RewriteMap ips txt:/etc/apache2/whitelist.txt
RewriteCond ${ips:%{REMOTE_ADDR}|NOT-FOUND} !NOT-FOUND [OR]
RewriteCond ${ips:%{HTTP:X-Forwarded-For}|NOT-FOUND} !NOT-FOUND
Something you might not know
The configuration of the dropper has now been modified to retry multiple times after a timeout, if the connection returns a HTTP 404 response. This provides extra time to make a decision on whether to add the IP address to the white-list, without losing the implant. If the IP address is then added to the white-list, then when the dropper connects back, it will be allowed to traverse to the PoshC2 server instance and download the core implant.
Extra help
The CookieDecrypter.py script was created to assist in decision making by providing more information. The connection from the dropper includes a cookie value that details useful environment variables such as those detailed below, however it is encrypted with the key created on initialisation of the PoshC2 instance.
- Domain
- User Account
- Hostname
- Implant Architecture
- Process ID
- URL
Capturing the cookie
By default the cookie value will not be stored anywhere on the proxy server. As previously mentioned, Apache is powerful and includes a number of options to assist, one of which is ModSecurity.
Installing ModSecurity:
apt install libapache2-modsecurity
Enabling the configuration to capture cookies for requests that are returned a HTTP 404 response:
SecAuditEngine RelevantOnly SecAuditLog /var/log/apache2/sec.log SecAuditLogParts BSecAudit LogRelevantStatus ^(404)
Now if a dropper connects and gets a 404 response, the following log entry will be created in “/var /log/apache2/sec.log”:
--05326010-B-- GET /implant/url/whatever HTTP/1.1 Host: somebody.whatever.com Connection: Keep-Alive User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko Cookie: SessionID=P3NYO7GOCYZJUEvY/HMZ0w/Z6UGQSASuHsifpW+uIsvHwdpsJsbQBgKCIYeGQWgcX3plsXEBdEQQBQsFGL6qMqxlykP25OAaY X-Forwarded-For: 192.168.20.10
The script
The script CookieDecrypter.py has been created to ingest the log file and parse the ‘SessionID’ from the log file, then connect to the PoshC2 database to retrieve the encryption keys and use the encryption functions to reverse the cookie value. It has to be executed on the PoshC2 server.
python CookieDecrypter.py log.txt
Conclusion
With increased visibility comes better decision making. Knowledge of the workstations domain and the user generally provides most, if not all, of the information you need to assess whether an asset is in scope. We have multiple layers of protection in our approach to risk management to ensure that we stay on the right side of the rules of engagement, and this is just one of them. We recommend that you develop your own set of risk management procedures too.
