Cloud adoption has grown dramatically within the enterprise and shows no signs of stopping. Many cloud services such as Github, Slack, Dropbox, and others are part of everyday business and rightfully don’t raise red flags to security teams. These systems are managed and patched by companies who have a strong incentive to protect the data that is stored on, and moves to and from, their infrastructure, in most cases providing encryption at rest and in transit. These are well-known, well-understood, and trusted systems with easy-to-use APIs.
But what if attackers wanted to use those APIs too? Attackers are motivated to not get caught, and are also interested in having encryption at rest and in transit. Attackers don’t want red flags raised – and they sure don’t want their IPs and domains block listed or sinkholed. So why not use those same services? With the release of SaaSy_boi, a proof-of-concept with limited functionality, we explore how the cloud provides redundancy and resilience for all applications – even those you don’t want on your network.
Anatomy of an Attack
Attackers can find all kinds of ways onto an endpoint – phishing, drive-by download, or even mistakenly downloading a file from a bucket with lax permissions. Once malware is there, most enterprises usually have an IDS or IPS to block the outbound communication. But what happens when the communication happens over a channel that is trusted and encrypted? This creates a huge problem for IDS, since URL-based detections will be defeated (the endpoint is trusted) and deep-packet inspection detections will be difficult (since the payload is encrypted).
In the case of our POC, SaaSy_boi, we start by pulling API keys from a paired url.txt file (URLs not included). This saves us the trouble of hard-coding API keys for Slack and Twitter, making it much easier for us to conduct our operations over multiple channels, should one of them be blocked by some unforeseen security solution. This sort of “lock but no key” approach is one we take repeatedly with SaaSy_boi to evade common mitigations.
Then, by using SaaS as command and control, much the same way that SLUB did, attackers can operate under the radar from most security products and conduct their surreptitious operations for longer. Slack and Twitter operate as our command and control channels. Slack takes and responds to commands over a channel with the same name as the computer name, while Twitter simply tweets out command responses for commands received. We have a third fall-back channel in Github, but no command responses are posted – so you have to know what you want to do.
SaaSy_boi will also:
- Upload to Dropbox (given a key)
- Download from dropbox (given a key)
- Upload to Slack
- Upload to file.io
- Download from file.io
- Execute any command over a reverse-shell
- Take a screenshot and upload it to imgur
Why Write This POC?
We provide all this functionality so that researchers and security professionals can play with the code, run the POC, and write detections. We at Netskope and others in the security community believe that approaching our defensive posture from an attacker’s perspective can give us insights that simply thinking about defense doesn’t provide. As such, we seek to bypass defenses wherever they are so we and others can patch the holes we find and help make things safer for everyone.
*NOTE*: If you want to freeze and package the executable to see what your security solutions can detect: the official Python docs have a resource for you.
Conclusion
This blog post is based on the talk I gave at Defcon 27.
SaaSy_Boi can be found here: https://github.com/netskopeOSS/saasy_boi
