Persistent access to a target’s network is one of the milestones in any offensive operation. During our operations, we use various types of short-haul beacons for day-to-day operations. If all short-haul beacons fail, a long-haul beacon which calls back much less frequently, can restore access to the target’s network. As such, a long-haul beacon should function in a way that it does not attract the attention of the blue team.

TL;DR
For OPSEC reasons, it is a good habit to split your command and control (C2) between low-and-slow channels (stage 1, long-haul) and operational channels (stage 2, short-haul). This blog post provides operational details for building a stage 1 C2 channel using DNS over HTTPS (HTTPS calls to dns.google.com to retrieve DNS TXT records) to trigger the download of a stager that will subsequently launch a payload for stage 2 C2.

Read full post

DISCLAIMER: this blog post covers functionality of Cobalt Strike that is not officially supported, nor fully tested or confirmed to ever appear with the current specs as official functionality. If you want to experiment with this yourself, @armitagehacker has provided a link that will be used for future documentation.
It is however a lot of fun. It provides flexibility and allowed us to leverage the power of CS in a far from default network setup at a high secure environment. We truly hope this functionality becomes available in future releases of Cobalt Strike.

External_C2

We encountered the need for alternatives to the standard DNS, HTTP or HTTPS channels for C2 traffic We feel Mallable format allows for great C2, especially when combined with Haproxy which sends all non C2 traffic to a real site that relates to the Mallable profile used.

Read full post

If you’re a penetration tester, you’ve been there: that customer that certainly knows what they’re doing. The one that makes their stuff secure by the less-is-more concept.

In an assignment of all internet facing systems of this customer we had to dig deeper to find something. After extensive testing of their web applications, we weren’t happy enough and wanted more. Scanning the full perimeter was already done and didn’t present us any useful vulnerabilities. Time to go deeper!

Researching all internet-exposed services, I found they were running an older version of Haraka mail handler (NodeJS) which had quite a history but not a single security flaw with a CVE or other report. Time to dig in, reading back from the used version to the current I did a quickscan on the changes in source and reached out to the developers.

Read full post