Passwords, passwords, passwords: end users and defenders hate them, attackers love them. Despite the recent focus on stronger authentication forms by defenders, passwords are still the predominant way to get access to systems. And due to the habit of end users reusing passwords, and the multitude of public leaks in the last few years, they serve as an important attack vector in the red teamer’s arsenal. Find accounts of target X in the many publicly available dumps, try these passwords or logical iterations of it (Summer2014! might very well be Winter2018! at a later moment) on a webmail or other externally accessible portals, and you may have got initial access to your target’s systems. Can’t find any accounts of your target in the dump? No worries, your intel and recon may give you private email addresses that very well may be sharing the password with the target’s counter parts.
In many of our red teaming and incident response engagements, we encounter the abuse of MS Office macros as a vector to drop a remote access trojan and thereby gain initial foothold. From many discussions with our clients we have learned that macros are hard to secure and often a necessity for business operations. In this blog I’ll share a rough approach for detection of evil macros. In parallel, we are working on a more robust solution that can fully manage the macro problem (we hope to share some news on this later).
Once discussing the subject of macro security, clients indicate that there is no insight into what office macros are being used/executed with a legit business purpose. In the majority of cases businesses leave Macro settings untouched, rendering the effective settings “macro disabled with notification”.
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.
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. Still we would like to be able to build our own channels and have Cobalt Strike talk over that. We even considered building a proxy that could decode a special Mallable profile, push the data trough our own channel, reparse it in the Mallable profile on our redirectors and forward it to the Cobalt Strike teamserver.
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. There was one change that altered the way zip files where processed if the attachment plugin was enabled and claimed to fix a security vulnerability.