Welcome to another exciting edition of executive offense! This week we will dive into the ransomware ecosystem, red team and bug bounty Evasion techniques, scaling, cloud penetration testing / red teaming, and more! As you can see, this week we are pretty offensive-focused again but fear not, we will try to bring a strategy and defensive mindset to these offensive topics… But first, some expert analysis of the news!

The Evolution of Lockbit

This month I ran into Lockbit several times, not as an analyst or, thankfully, as a victim, but in researching red team methodology.

A couple of publications piqued my interest.

As part of my research, I spent considerable time on the dark web conducting threat intelligence research. Many threat intelligence feeds are informed by paste sites, old breach dumps, and other less useful information. My research aimed to ensure we had the freshest credentials and emails available to us during a red team campaign. While we have no issue using Dehashed like many red team shops, our focus on adversarial simulation and emulation means we want more.

My threat intelligence investigation led me directly to the topic of this section: the prolific crew known as LockBit.

If you're unfamiliar with LockBit, it is both the name of a strain of ransomware and a group that offers ransomware-as-a-service and data breach dumps in the digital underground. LockBit infections obtain initial access through various methods, but they specialize in exfiltrating data and operating as a highly sophisticated business. The group's distinguishing feature is its use of affiliates, an army of independent hacking groups that spread their ransomware. Typically, the split between the platform and the affiliate is 70% vs. 30% in favor of the affiliate.

What first caught my attention about LockBit this week was Malwarebytes' ransomware review for April 2023, which outlined that LockBit is now the second most prevalent ransomware in existence. Most likely, law enforcement agencies worldwide are actively seeking the group's leaders to bring them down, as they recently did with Genesis Market. The group's notoriety is underscored by a shoutout from CISA, indicating the extent of the problem.

This week, there was much ado about a new LockBit ransomware variant targeting macOS. News outlets worldwide covered this story for a solid 24 hours. However, as the dust settled, researchers like Patrick Wardle and Phil Stokes reassured the security community that while the framework for running on macOS was present, the malware was not harmful. Many analysts concluded it was a fork of the Linux variant, lacking data exfiltration or persistence functionality.

The pseudo press cycle and scaffolding for the ransomware prompt reflection on the security of hybrid macOS or full macOS organizations. My perspective is that, despite a few public missteps and the attention they receive when jailbreaks or Mac malware emerge, Apple runs a tight ship regarding security. I trust the Apple App review process and the Trusted Enclave on mobile devices.

My threat model for Apple mobile devices assumes that an exploit targeting me would cost hundreds of thousands of dollars. Consequently, such exploits are typically sold and brokered to attack high-profile individuals. When a widespread exploit emerges, it's usually due to a jailbreak driven by an enthusiast community attempting to make iPhones more accessible.

As for macOS, many experienced security leader friends argue that its’ lower malware representation and exploitation result from being less targeted or less widely deployed across enterprises. However, having worked closely with 10-15 hybrid or full macOS organizations as a consultant and leader, I can attest that their malware problems are minimal compared to Windows. I recommend following Patrick Wardle, an exceptionally knowledgeable macOS internals researcher, for more on this topic.

Chrome Woes…

Twice in two weeks, we saw components of Chrome hit with zero-days. While browser exploitation is not my field, many people commented that this was excessive for what is usually an exceptional security team working on the Chrome project.

To be honest, I wish I had more analysis here, but I not only lack the requisite browser internals knowledge, but I also believe that there will always be zero-days. As mentioned in the previous section, I think highly of the security of Apple and Google. I know people who work there who are highly skilled, but it's essential for us as defenders to understand that we can't throw the baby out with the bathwater and that defense in depth is the way to go.

Dependency Debate!

Speaking of defense in depth and me arguing on the complete opposite side of that, I posted earlier this week about a bug bounty report where a researcher submitted a Dependency Confusion vulnerability that managed to get 50+ Google employees to call back to his server. A former Googler who worked on security controls replied to the thread!

He talked about how mitigations and zero trust architecture are built around developer laptops and that this was justified in being paid at such a low level ($500). For some reason, awarding this bug that allowed a researcher to implant malicious code into the computers of 50+ Google employees, some of whom were inside the “local” network, didn't sit right with me. Having been the extended bounty manager for hundreds of bug bounties during my time at Bugcrowd, it felt wrong.

I also argued that when watching Google's epic marketing piece on their security groups at Google, one of the pieces was on their red team.

The story they chose to highlight for their red team wasn't too long ago when the red team used a physical gift with a USB plug that delivered malware to a computer. They seemed to think that was a successful campaign and represented risk, enough to make a public Google video about it.

Anyway, I think you could probably argue either side of this one. But as I said, my Spidey sense told me the reward was criminally low and disrespectful to the security researcher.

BTW I recommend the whole video series! Security marketing like this is imperative to educate regular people about the role we play in a secure society.

All YOUR CLOUD ARE BELONG TO ME

Last week, I prepared a truckload of research related to offensive security in the realm of cloud hacking. Most of these were red team-related, and presenting them separately would have been a slight disservice. So this week, we're going to dive into these epic resources.

Cloud Red Teaming: AWS Initial Access & Privilege Escalation

So first on deck is a free workshop done by Bryce Kunz called “Cloud Red Teaming: Initial Access & Privilege Escalation” that was presented a few weeks ago at Bsides Tampa.

This 168-page slide deck goes over AWS infrastructure, what tokens and cookies to target to get was access, using AI to build a malicious browser extension, custom tools to attack multi-factor authentication, and common misconfigurations in AWS architecture.

Bryce even resurrects a 2019 bug to exploit misconfigured S3 buckets!

Even if it were just the slides, they would provide a ton of important context and information about how modern red teamers attack AWS environments. But you don't have to struggle through parsing just the slides because there is a video that goes over a lot (but not all) of the material from the current deck, from a past preso for SAINTCON in Janurary:

His research from last year at SAINTCON is also very useful for cloud red teamers. “Mining Cloud Resources for Initial Access via Serverless Services”:

At the same conference, Mike Felch presented “Welcome to the Jungle: Pentesting AWS”!

You can see the associated video from CACTUSCON, here:

So, right now, if you are a red teamer who needs to grow your cloud-hacking skill set, I would recommend consuming almost all of the content below:

• Beau Bullock - Videos

  • 2hr Workshop Breaching the Cloud

• Bryce Kunz - Videos

• Mike Felch - Slides - Video above

• Carlos Polop / HalbornSecurity

  • https://cloud.hacktricks.xyz/

  • AWS Red Teaming Slides

• Rhino Security Labs (maker of cloudgoat! ++ an epic walkthrough from dhiyaneshgeek)

• rvrsh3ll - Azure Console Pivoting 101

• aadinternals talks - Video

• Introduction to Offensive Operations in AWS

• What I Wish I Knew Before Pentesting AWS Environments

• Nahamsec’s Cloud Hacking Series

Now, that's a lot of content from a bunch of really legit testers. It'll take you a while to get through all of that.

In my journey of staying current with tools, techniques, and procedures for cloud red teaming, I tend to hyper-focus on initial access. What disappoints me, just a bit, is that initial access to cloud systems remains largely the same as it's been for a long time. What continues to evolve is post-exploitation—tooling to enumerate, pivot, and persist. I love all of these, but since I spent the better part of the last ten years doing bug bounty hunting, I really want more ways "in." I'd hate to think it's all just threat intelligence credentials, phishing, developers posting secrets in public places, and application-level vulnerabilities like RCE and SSRF.

Evasion and Stealth and Distribution for the External

Another area I've been updating recently in my methodology is the idea of evasion and stealth for red teamers on the external portion of a red team engagement. While my wants and needs are definitely for this, any of these techniques can also be used for bug bounty hunters who want to stay unbanned from web application firewalls and cloud services that would block your traffic.

In general, there are two categories of tools that I want to use.

One set of tools is for distributed scanning. Distributed scanning allows me to divide large brute-forcing tasks and scan tasks across multiple hosts. These tools are frameworks that take your content discovery tools, port scan tools, DNS brute-forcing, etc., and distribute your lists or tasks (which are sometimes very extensive) across multiple machines, reducing what would take hours of scanning down to minutes. While an auxiliary benefit of these tools is that they allow you to remain somewhat stealthy, I would not say that is their primary purpose.

The other set of tools is strictly for proxying individual requests, typically during a credential spray or something similar. In this category of tools, you have tools that use regular proxies, cloud instances, dynamic VPS setups, and some even proxy through SaaS platforms.

Distributed Scanning

• Axiom - https://twitter.com/Jhaddix/status/1633936278222962688

• Fleex - https://github.com/FleexSecurity/fleex

• ShadowClone - https://github.com/fyoorer/ShadowClone

Proxying Individual Requests

Socks Proxying

• https://github.com/kitabisa/mubeng

Cloud

• https://github.com/proxycannon/proxycannon-ng

• https://github.com/RhinoSecurityLabs/IPRotate_Burp_Extension

• https://github.com/ustayready/fireprox

  • https://jamesonhacking.hashnode.dev/defeating-rate-limiting-with-fireprox

Dynamic VPS

• (Web) https://github.com/d3mondev/burp-vps-proxy

• SocksProx - https://blog.ceriksen.com/2023/04/01/leveraging-llms-for-solving-bounty-hunting-pain-points/

SaaS

• https://github.com/luminati-io/luminati-proxy

  • https://lokeshdlk77.medium.com/how-to-rotate-ip-address-for-each-request-in-burp-suite-4e29645ef23e

In the category of distributed scanning, one of the clear frontrunners is Shadow Clone due to its ease of use and its ability to utilize cost-effective cloud technologies.

In the category of proxying individual requests, Fireprox and IP Rotate are the standard choices. However, if you are looking for ease of use for web testing and only need to switch to one new IP address, Burp VPS Proxy is quite impressive.

First of all, I want to thank everyone for making it to the end of the newsletter. I genuinely enjoy writing these, and I can't thank you enough for subscribing. In just three short weeks, we've reached 2,000 subscribers, which is a personal milestone for me.

I also want to quickly apologize for the delay in sending this out. In general, due to being a father of three and having a full-time job, I will aim to release the newsletter on Wednesdays or Thursdays from now on.

If you enjoy the newsletter, please don't forget to follow me on Twitter and share this week's issue with anyone you think might be interested. Additionally, some of you may have seen the tweets about the newsletter seeking sponsorships. If any of you are companies looking to reach our unique subscribers, please contact me at [email protected].

Thanks again, everyone, and I'll see you next week!

Myself and my epic company Buddobot will be in SF this weekend for BsidesSF and then RSA Conference! Come find us at the below places!