🔴 Executive Offense Issue #2

The Old & New: Buckets, ransomware, FIDO/2, ChatOps, C2, AISecTesting

EO is a security newsletter that focuses on the intersection between offensive security and security strategy. Sometimes hacker-ish, sometimes CISO-ish. Very blazer over the t-shirt type of vibe…

(Update, this turned out to be a dev instance with fake data! Phew! but protecting your s3 is still important 😉 )

This recent breach involving IntelBroker and the US Citizenship and Immigration Services infrastructure is crazy. The breach appears to be primarily linked to misconfigured cloud infrastructure, specifically an exposed AWS S3 bucket. It’s being assumed the S3 bucket contained code with hardcoded credentials embedded within it. These credentials granted unauthorized access to websites containing sensitive citizen data.

If the root cause of this breach can be attributed to the misconfigured S3 bucket, it is a persistent vulnerability that has troubled cloud adopters for nearly a decade. To mitigate such risks, I recommend hardening your data stores on cloud platforms like Amazon.

Here’s a quick checklist on some (but not all) S3 protections you should consider:


More here:

If you want to enumerate s3 boxes or scan for misconfigurations (internally or externally) there exist serval open source tools such as s3tk, s3-buckets-finder, CloudScraper, and Bucket-Flaws. I highly suggest a follow of Scott Piper in this field. Plus @asegunlolu and @karimscloud for Azure.

TIP: In our previous newsletter, we discussed the importance of secrets management. This breach serves as a stark reminder not to hardcode secrets or use weak passwords like "password1". A valuable tip for organizations is to ensure that internal libraries, which can have an equally large attack surface as application code, are not overlooked during secrets management. This involves incorporating tools like Artifactory (or other library storage/management) into your scanning schedule for hardcoded credentials.

WD is currently facing a breach, suspected to be ransomware, which has caused multiple services to go down. Last week, we briefly discussed downtime as a primary threat model for your entire organization. To illustrate the impact:

(Napkin Math) WD generates $18.7 billion in annual revenue, with their cloud divisions (the ones currently down) accounting for 42% of that revenue. This amounts to $7.5 billion. When divided by 365 days, we see that WD potentially loses around $20 million per day of downtime. This estimate has been rounded down in two places.

Ransomware continues to be a plight to organizations. While many will argue the efficacy of EDR/XDR, it is often your 1st (and sometimes only) defense in ransomware infections. That’s why EDR remains an earmarked cost in security budgets. In my convos with other CISOs, vendors that I hear win the race in bakeoffs? 1) CrowdStrike 2) Defender (with all the E5 support) 3) SentinelOne.

FIDO/2

One of the most valuable security threads I've seen this year comes from a friend of mine, Clint Gibbler. Clint compiled a series of threads by other defensive security practitioners on rolling out FIDO/2 tokens. We all know that FIDO represents the next generation in protecting against phishing, but many people discuss FIDO tokens as though implementing them were as simple as flipping a light switch. The hard truth is that deploying FIDO is often a painful process due to the lack of interoperability between different types of software in your organization, the absence of features on various tokens, and the challenge of seamlessly integrating all of your infrastructure.

You can follow this thread and each individual branch to discover some truly valuable insights into the implementation process. Additionally, the thread provides key metrics for measuring success in such an endeavor.

Security ChatBots

Recently, I attended a talk by a security practitioner from a security company. They introduced me to the idea of ChatOps as a defense strategy, similar to FIDO, but not as robust. The concept involves using a webhook in Slack to create a channel and invite the user in question to it for any change in security features or concerning activity in logs. The invitation step is crucial because if an administrator creates the channel and invites you, an attacker with access to Slack cannot simply leave it.

In the message that appears in this channel, the webhook creates a three-option prompt and a description of the alert, such as "We noticed that you are trying to change your two-factor authentication device; is this you?" with three options: "Yes, it was me," "No, it wasn't me," and "I don't know." If the user selects "Yes, it was me," the action continues. If the user selects "No, it wasn't me" or "I don't know," the action is blocked and an alert is sent to the SOC with appropriate priority.

Obviously, this strategy relies on having your chat program of choice highly secured. In the world of SaaS, this isn't always easy, but it does provide a single escalation point to protect. I found this approach to be novel and, although slightly weaker than FIDO, quite interesting. This is not the person who gave me the education, but a similar article series:

Sponsor

None yet! 😁 

A new C2 Appears!

The offensive security space often resembles a cat-and-mouse game between adversaries and defenders. Sometimes, it's your red team that pushes you to improve. This week, a new open source command and control (C2) framework was launched by DragoQcc. I always get genuinely excited when fresh players enter the C2 arena. It not only ignites innovation in the field but also compels defenders to adapt to heuristics rather than relying on signatures. Oftentimes, tools and code employed in adversary kill chains utilize similar tactics, but they are entirely regenerated using obfuscation to evade security software.

The Red Canary Threat Detection Report and Open/Closed Source C2 software

One of the most fascinating debates I've seen lately is about open/closed source offensive security tools. Red Canary released a report that listed their top 10 threats which included many open source c2 tools. Some folks, like world class defender Florian Roth, think that might mean open source is doing more harm than good when it comes to offensive security tools.

TBH, I don't think that's the whole story. Open source tooling being on that list might just mean that we can detect them more easily because they're open source. That means defenders get to take a look at how they work, learn from them, and build better detections. IMO, having open source tools out there could actually be helping the security community as a whole.

Either way the report is great reading and Florian is worth a follow for his red team trolling alone!

The realities of time-boxed assessment

I adore this thread because it allows me to speak to my younger self. Kuzushi wrote a fantastic breakdown about how, in offensive security, you can hustle relentlessly and try to not miss a thing, but you're still only seeing a small part of the picture over a very short period of time. Statistically, a point-in-time assessment cannot find everything.

This is absolutely true. It's my firm belief (and not just because I lead a company doing this) that security testing needs to move simultaneously away from the middle ground. By middle ground, I mean that most security testing these days lasts anywhere from one to three weeks. This duration simply doesn't reflect the amount of time an actual attacker would spend profiling and attempting to exploit your applications. Many adversaries invest months or even years trying to find complex bugs that will work in their kill chain against you. On the other hand, it's much easier to identify security bugs in source code than it is dynamically. To genuinely maximize your return on investment when it comes to assessment, you should concentrate significant effort upfront on CI/CD tooling and a substantial effort at the tail end performing adversarial simulation, red teaming, or adversary emulation. I understand this is a contentious topic, but I was also around when security assessments began. The only reason we work in three-week sprints is that it's easy to bill for and provides a number that doesn't shock clients too much. It’s time to evolve testing.

WebSecGPT - AI for Web Testing

This week, I wrote a thread about using Chat GPT-4 with what's known as a master prompt. The thread detailed how I passed a JavaScript file to the chatbot, which had been instructed to focus on web security knowledge. I then started asking the AI questions as if it were an intelligent peer. Without proper API documentation, the AI provided me with valuable context and a wealth of useful information based solely on the frontend code. You can read the entire thread to see the types of questions I asked the AI, and at the end of the thread, I released my master prompt. In the second tweet, I also explained how to split a large piece of code across the Chat GPT token system using GPT Splitter.

I know AI is a contentious topic for security professionals. I was planning to avoid discussing it in the second issue since I talked about it a lot in the first issue.

Here's the thing: AI is going to cause massive disruption in the security industry. While I don't think it will replace all of us, it will certainly enhance our ability to attack and defend. My instinctive reaction to people's disdain for AI is to liken them to Luddites, but I'd prefer to help people understand AI as I do. For now, AI is a tool—a very powerful tool—and as security experts, we should be at the forefront of harnessing powerful computing tools to promote the greater good.

I had a blast writing this week's newsletter. I think the great thing about the format of the newsletter is that it gives me an opportunity to go back through all of my bookmarked content and expand upon the thoughts that were in my head when I bookmarked them. I hope the format of offering insights into things rather than just a list of tweets and tools is better for you, the readers. If not hit me up and let me know what you'd like to see in Executive Offense.

Thanks for reading. I sincerely appreciate it. If you enjoyed the newsletter, please share the signup page on Twitter or with friends!

If you are a red teamer or bug hunter, consider checking out my training in July:

And finally, if you are anywhere near Florida, come hang with me and several of my hacker buddies at HackSpaceCon!

I also have several newsletters which inspire me, and I suggest them wholeheartedly to security folk. Check them out: