Just a few days ago the world felt the rippling effects of a third-party push to networks across the globe. What would have normally been a routine undertaking instead caused mass disruption of information systems and brought businesses of all sizes to a standstill. Almost everyone was impacted by this incident in one way or another. At the time of this writing, some companies continue to struggle to resume normal business activities.
As with any incident, we must take a look at our processes to see what lessons we can learn and how we can improve – an after-action report, if you will.
Third-Party Risks
Our society is more interconnected than ever before, and third-party vendors increasingly are active on customer production business networks. The advantages businesses receive from these interactions are often worth the risks. However, as with all business decisions, we must understand the risks that we are accepting and take steps to mitigate them to the greatest practical extent.
One of the key takeaways from this incident is that we need to incorporate third-party risks into our business continuity (BC) plans, incident response (IR) plans, and tabletop exercises. Businesses cannot control every aspect of a third-party integration, but they can control how that risk is incorporated into the environment and put safeguards in place for maintaining continuity when an action fails to go as planned.
Businesses should not only take this into account with their BC/IR planning but should actively incorporate this into their tabletop simulation drills. At Raxis, we conduct tabletop offerings as a simulated attack intended to model real-world threats. They facilitate cohesion and seek to highlight process gaps and less obvious exposures. A plan is only as good as its execution, and tabletop exercises are an excellent way to identify improvement opportunities in plans and processes.
A Few Things to Think About
Do you have redundant systems in place that would be resilient to a third-party incident?
Do you have tested backups (emphasis on tested) that allow you to quickly restore your system?
Do you maintain adequate logging, and are these logs stored for a long enough time period to allow your team to review them and determine affected systems?
Do you have a current BC/IR plan, and does this plan include incidents that could be caused by third-party vendors?
Do you actively review your vendors and their operational processes that could affect your business stability?
Vince Lombardi once said, It’s not whether you get knocked down, it’s whether you get up. This rings true after every security incident. What do we learn, and how do we improve?
On June 18th, 2024, thousands of car dealerships across the United States and Canada fell victim to a cyberattack against an upstream cloud service provider, resulting in widespread outages and significant operational degradation. A second attack occurred a day later and caused further damage, exacerbating an already dire situation.
What happened?
The attackers targeted CDK Global, a behemoth in the automobile SaaS industry with services extending into nearly all areas of business.
CDK Global offers SaaS solutions that help dealerships manage various aspects of their business, including vehicle acquisitions, sales, financing, insuring, repairs, and maintenance. Their services are critical for business continuity of their customers. The downstream impacts of the attack affected over 15,000 dealerships across the continental US and Canada. At this time, no direct impact to any vehicles or vehicle-connected systems has been reported.
In response to the attack, CDK shut down its IT systems, including customer logins and data center operations. At the time of this writing, three days after the initial attack, dealerships remain severely hampered by the ongoing outage, as noted in numerous X feeds:
While specific impacts vary or have yet to be determined, at the time of this writing, concerns shared amongst the victims include:
Operational Disruption: CDK’s systems were compromised, affecting dealership operations, inventory management, and customer service for an extended period.
Reputation Damage: Public scrutiny of the breach may erode trust in dealerships and manufacturer brands, affecting customer loyalty and sales.
Legal and Regulatory Fallout: Dealerships may face legal actions, fines, and regulatory scrutiny due to data protection violations.
Financial Loss: Remediation costs, legal fees, and potential lawsuits can strain dealership finances.
Why were Car Dealerships Targeted?
Car dealerships pose a uniquely attractive target to malicious actors. Often lacking in dedicated security staff and formal risk management processes, they still handle large amounts of money and store vast amounts of customer data, including sensitive PII.
Also, dealership systems are often interconnected with other external systems for business processing, which may facilitate additional side channel attacks.
Recent Trends
A 2023 report by CDK highlighted that 17% of surveyed dealers experienced cyber-attacks within the past year, up from 15% the previous year. Of those dealerships affected, 46% reported negative financial or operational impacts. The scale and impact of this incident is without prescedent and may be felt for months.
Response and Recovery
To their credit, CDK Global promptly shut down affected and potentially affected systems as a precautionary measure.
Core document management and digital retailing solutions were prioritized and later restored.
At the time of this writing, CDK continues to conduct ongoing tests to bring other applications back online without introducing additional risk.
CDK also issued a warning to customers on its interactive voice line:
‘We are aware that bad actors are contacting our customers posing as members or affiliates of CDK trying to obtain system access. CDK associates are not contacting customers for access to their environment or systems.’ ‘There is currently no known estimated time frame for resolution and therefore our dealer systems will not be available likely for several days.’
Looking Forward
It goes without saying that risk management and business continuity are critical for car dealerships. Dealerships now find themselves facing the stark reality that the two are inseparable. How they choose to move forward will shape the viability and perceived trust of the industry.
Raxis recommends that car dealerships consider the following steps when designing a robust security program:
Data Protection Regulations:
Become familiar with data protection laws such as the Gramm-Leach-Bliley Act (GLBA), which outlines obligations to safeguard consumers’ PII, such as names, addresses, and social security numbers.
Implement comprehensive data protection measures, including encryption, granular access controls, and effective monitoring.
Secure IT Infrastructure:
Ensure dealership IT systems are secure:
Encrypt data at rest and in transit.
Use multi-factor authentication for identity verification.
Regularly update software and maintain firewalls.
Educate employees about phishing scams and secure password practices.
Data Integrity and Governance:
Establish strong data governance policies and procedures:
Conduct regular audits to identify and reconcile anomalies.
Apply layered controls and redundancy to critical systems.
Limit Access and Educate Staff:
Using the principle of least privileged access, allow access to dealership data to only what’s necessary for specific functions. This applies to personal and interconnected systems.
Train employees to recognize security threats and respond appropriately.
User strong, complex passwords and change them regularly.
Password length is a topic we’re asked about a lot, and that makes sense because it can be quite confusing. There are several different compliance models that organizations use – from PCI to NIST to OWASP and more. Each has its own standards for password strength and password length.
When it comes to penetration testing, weak password recommendations often are more rigorous than compliance standards, and this leads to a great deal of stress, especially for organizations that have already spent time and effort in implementing password rules that meet the compliance standards they’ve chosen.
Why So Many Different Standards?
First, speaking from experience, penetration testers see firsthand how weak and reused passwords are often a key part of achieving access over an entire domain (i.e. having administrative powers to view, add, edit, and delete users, files, and sensitive data, including passwords, for an organization’s Active Directory environment). While this is the type of success that pentesters strive to achieve, the true goal of a penetration test is to show organizations weaknesses so that they can close exploitation paths before malicious attackers find them.
For this reason, Raxis penetration tests recommend passwords of at least 12-16 characters for users and at least 20 characters for service accounts. Of course, we recommend more than length (see below for some tips), but Raxis password cracking servers have cracked weak passwords in minutes or even seconds on internal network penetration tests and red team tests several times this year already. We don’t want our customers to experience that outside of a pentest.
On the other hand, compliance frameworks are just that – frameworks. While their aim is to guide organizations to be secure, they do not endeavor to force organizations out of compliance with a stringent set of rules that may not be necessary for all systems and applications. For example, a banking website should require stronger credentials and login rules than a store website that simply allows customers to keep track of the plants they’ve bought without storing financial or personal information.
If you read the small print, compliance frameworks nearly always recommend passwords longer than they require. It’s unlikely, though, that many people read the recommendations when working on a long compliance checklist when they have several more items to complete.
Times are Changing
Of course, time goes on, and even compliance frameworks usually recommend at least ten-character passwords now. The PCI (Payment Card Industry) standards that are required for organizations that process credit cards now require 12 character passwords unless the system cannot accept more than eight characters. PCI DSS v4.0 requirement 8.3.6 does have some exceptions including still allowing PCI DSS v3.2.1’s seven-character minimum length that is grandfathered in until the end of March 2025.
This is a good example of PCI giving companies time to change. It’s been well known for years that someone who has taken the time and expertise to build a powerful password-cracking system can crack a seven-character password hash in minutes. This leaves any organization that still allows seven-character passwords with a strong threat of accounts becoming compromised if the hash is leaked.
OWASP (the Open Web Application Security Project), which provides authoritative guidance for web and mobile application security practices, accepts 10 characters as the recommended minimum in their Authentication Cheat Sheet. OWASP states that they base this on the NIST SP 800-132 standard, which was published in 2010 and is currently in the process of being revised by NIST. Keep in mind that OWASP also recommends that the maximum password length not be set to low, and they recommend 128 characters as the max.
The Center for Internet Security, on the other hand, has added MFA to their password length requirements. In their CIS Password Policy Guide published in 2021, CIS requires 14 character passwords for password-only accounts and eight character passwords for accounts that require MFA.
Other Factors
This brings up a good point. There is more to a strong password than just length.
MFA (multi-factor authentication) allows a second layer of protection such as a smartphone app or a hardware token. Someone discovered or cracked your password? Well, they have one more step before they have access. Keep in mind that some apps allow bypassing MFA for a time on trusted machines (which leaves you vulnerable if a malicious insider is at work or if someone found a way into your offices).
Also keep in mind that busy people sometimes accept alerts on their phones without reading them carefully. For this reason, Raxis has a service – MFA Phishy – that sends MFA requests to employees and alerts them (and reports to management) if they accept the false MFA requests.
MFA is a great security tool, but it still relies on the user to be vigilant.
Raxis’ Recommendations
In the end, there are a myriad of ways that hackers can gain access to accounts. Raxis recommends setting the highest security possible for each layer of controls in order to encourage attackers to move on to an easier target.
We recommend the following rules for passwords along with requiring MFA for all accounts that access sensitive data or services:
Require a 12-character minimum password length.
Include uppercase and lowercase letters as well as numbers and at least once special character. Extra points for the number and special character being anywhere but the beginning or end of the password!
Do not include common mnemonic phrases such as 1234567890, abcdefghijkl, your company name, or other easily guessable words. Don’t be on NordPass’s list!
Do not reuse passwords across accounts, which could allow a hacker who gains access to one password to gain access to multiple accounts.
There are two easy ways to follow these rules without causing yourself a major headache:
Use a password manager (such as NordPass above, BitWarden, Keeper, or 1Password amongst others). Nowadays these tools integrate for all of your devices and browsers, so you can truly remember one (very long and complex) password in order to easily access all of your passwords
These tools often provide password generators that quickly create & save random passwords for your accounts.
They usually use Face ID and fingerprint technology to make using them even easier.
And they also allow MFA, which we recommend using to keep your accounts secure.
Use passphrases. Phrases allow you to easily remember long passwords while making them difficult for an attacker to crack or guess. Just be sure to use phrases that YOU will remember but others won’t guess.
And I’ll leave you with one last recommendation. On Raxis penetration tests, our team often provides a list of the most common passwords we cracked during the engagement in our report to the customer. Don’t be the person with Ihatethiscompany! or Ihatemyb0ss as your password!
AICPA (the American Institute of Certified Public Accountants) developed the SOC 2 (System and Organization Controls) framework in 2010 to provide guidance for evaluating the operating effectiveness of an organization’s security protocols, especially within cloud environments.
SOC 2 is a compliance and privacy standard that outlines how organizations should manage customer data and related systems to ensure confidentiality, integrity, and availability.
SOC 2 defines five Trust Services Criteria (TSC) that evaluate various aspects of information security and governance. The first, security, must be a part of any SOC 2 audit, and organizations can choose to include other trust services categories. Organizations tailor their SOC 2 audits based on their specific needs and the services they provide.
Security: Ensures protection against unauthorized access, breaches, and other security incidents by assessing the effectiveness of controls related to data protection, access, and system security.
Availability: Ensures systems are available for use as needed by examining whether the service is available as promised and whether any planned or unplanned downtime occurs.
Processing Integrity: Ensures accurate and complete processing of data as well timeliness and consistently of data processing.
Confidentiality: Ensures data confidentiality by examining data encryption, access restrictions, and confidentiality agreements.
Privacy: Ensures compliance with privacy regulations for personal information.
Customizing SOC 2 Controls to Best Fit Your Organization
Organizations design their own internal controls to meet these requirements, as needs and controls are unique to each organization. It’s common for organizations to use a service or consulting company, such as Raxis’ partner Strike Graph, to help them understand the different controls, to assess which are relevant for the organization’s systems and services, and to ensure that they have fulfilled the controls properly before an audit takes place.
Many organizations focus entirely on the Security TSC, also known as the common criteria, for their SOC 2 audits. The common criteria are required for all SOC 2 audits. These are the areas of focus, created in 2017 and revised in 2022:
CC1: Control Environment
CC2: Communication and Information
CC3: Risk Assessment
CC4: Monitoring Activities
CC5: Control Activities
CC6: Logical and Physical Access Controls
CC7: System Operations
CC8: Change Management
CC9: Risk Mitigation
During the SOC 2 audit, an independent auditor evaluates the organization’s security posture related to the selected Trust Services Criteria. Organizations provide evidence for the controls they have in place, and, if auditors feel there are deficiencies, organizations can choose to remedy those during the audit or to explain why they accept the risk.
SOC 2 Type 1 versus SOC 2 Type 2
While Type 1 provides a foundational layer regarding the control design for the organization, Type 2 offers a comprehensive view of control effectiveness over time. Type 1 is the first step in annual SOC 2 compliance. Organizations can choose to combine Type 1 and Type 2 during their first SOC 2 audit or to become Type 1 compliant the first year and then move on to Type 2 in subsequent years.
SOC 2 Type 1 evaluates an organization’s cybersecurity controls for their effectiveness at safeguarding customer data at a specific point in time, while Type 2 examines how well the organization’s system and controls actually perform over a period of time (often 3-12 months).
Raxis, for example decided to focus on SOC 2 Type 1 in our first year of compliance so that our team had the time to focus on building out the necessary controls in the most robust manner possible that matched our systems and services. SOC 2 allows organizations (to a certain extent) to setup their controls with as much simplicity or complexity as they see fit. As security is integral to every part of Raxis’ business and goals, our aim in choosing to become SOC 2 compliant was to take the time to build the controls out to best protect the data entrusted to us.
Honestly, we discovered that we could not discover the best way to implement our controls without building out and testing the systems themselves. In the end, we could have performed our SOC 2 Type 2 audit in 2023 as well, but with the busy end-of-year penetration testing season, we decided to complete our first SOC 2 Type 2 compliance audit this April, covering this past winter and spring.
How Does Penetration Testing Relate to SOC 2 Compliance
SOC 2 compliance is essential for demonstrating your commitment to data protection, while penetration testing provides an extra layer of security by identifying vulnerabilities so that your organization can correct them before they are exploited.
But there’s more… SOC 2 compliance often requires a penetration test (and a retest of critical and severe findings) as one of the controls in order to show that organizations successfully monitor and correct/mitigate security risks to their systems.
Raxis often performs SOC 2 penetration tests for our customers and is proud to work with SOC 2 partners to perform penetration tests for their customers as part of their framework offerings. Tailoring your penetration test to your specific needs and goals is an important first step in scoping any test.
Why Choose to Become SOC 2 Compliant?
While not yet required, SOC 2 compliance helps establish trust between service providers and their customers. With high-profile data breaches becoming more common, many organizations, like Raxis, choose to become SOC 2 compliant both as an exercise to ensure the security controls they’ve created are robust and also to ensure the controls are updated as the threat landscape changes over time.
SOC 2 compliance is audited annually, ensuring that both the organization’s controls themselves and their implementation are tested regularly to ensure that new risks are accounted for and that security policies and procedures do not become stale. SOC 2 compliance ensures that organizations handle customer data securely and transparently, meeting specific criteria for trust and protection.
We are thrilled to announce that Raxis has successfully achieved SOC 2 Type 2 compliance. This milestone underscores our commitment to maintaining effective security controls over our information systems and the penetration testing and cybersecurity services we offer.
Our SOC 2 compliance provides assurance to our clients that their data is handled securely and in accordance with industry best practices. We remain committed to maintaining the highest level of security and privacy, and we will continue to invest in our compliance program to stay ahead of evolving threats.
We remain dedicated to providing a secure platform and services for our clients. We are pleased to provide our SOC 2 Type 2 report to current customers and prospective customers under NDA. Contact our team for more information.
Although social engineering attacks – including phishing, vishing, and smishing – are the most popular and reliable ways to gain unauthorized access to a network, some hackers simply don’t have the social or communications skills necessary to perform those attacks effectively. Wireless attacks, by contrast, are typically low-risk, high-reward opportunities that don’t often require direct interaction with the target.
That’s one reason why pentesting for wireless networks is one of Raxis’ most sought-after services. We have the expertise and tools to attack you in the same ways a real hacker will. In fact, I’ve successfully breached corporate networks from their parking lots, using inexpensive equipment, relatively simple techniques, and by attacking devices you might never suspect.
To appreciate how we test wireless networks, remember that wireless simply means sending radio signals from one device to another. The problem with that is that no matter how small the gap between them, there’s always room for a hacker to set up shop unless the network is properly secured.
So, if Raxis comes onsite to test your wireless network, the first thing we will likely do is map your network. This is a mostly passive activity in which we see how far away from your building the wireless signal travels normally. But we also have inexpensive directional antennas that allow us to access it from further away if we need to be stealthier.
Using an easily accessible aircrack-ng toolkit, we can monitor and capture traffic from wireless devices as well as send our own instructions to others that are unprotected. (I’ll go into more detail about that in a moment.)
As we establish the wireless network’s boundaries, we also determine whether there are guest networks or even open networks in use. Open networks, as the name implies, require no special permission to access. Even on controlled guest networks, we can usually get in with little effort if weak passwords are used or the same ones reused. Once we’re in as a guest, we’ll pivot to see if we can gain unauthorized access to other areas or other users’ data.
While this is going on, we will often set up a rogue access point, essentially just an unauthorized router that passes traffic to the internet. If the network is configured properly, it should detect this access point and prevent network traffic from accessing it. If not, however, we can capture the credentials of users who log into our device using a man-in-the-middle attack.
Our primary goal here is to capture usernames and password hashes, the characters that represent the password after it has been encrypted. In rare cases, we’re able to simply “pass the hash” and gain access by sending the encrypted data to the network server.
Most networks are configured to prevent this technique and force us to use a tool to try to crack the encryption. Such tools – again, readily available and inexpensive – can guess more than 300 billion combinations per second. So, if you’re using a short, simple password, we’ll have it in a heartbeat. Use one that’s more complex and it may take longer or we might never crack it.
If a network isn’t properly secured, however, we might be able to find a way in that doesn’t require a password. Many people who use wireless mice and keyboards, for example, don’t realize that we can sometimes intercept those signals as well. For non-Bluetooth devices, we can use our aircrack-ng tools to execute commands from a user’s (already logged-in) device.
As a proof of concept, we sometimes change screensavers or backgrounds so that network admins can see which devices are vulnerable. However, we can also press the attack and see if we’re able to pivot and gain additional access.
The good news for business owners is that there are simple methods to protect against all these attacks:
Never create an open network. The convenience does not justify the security risk.
If you have a guest network, make sure that it is not connected to the corporate network and that users are unable to access data from any others who may also be using it.
Use the latest wireless security protocol (WPA3) if possible.
If you’re using WPA2 Enterprise, make sure the network is requiring TLS and certificates.
If you’re using WPA3 Personal, make sure your password is at least 30 characters long. (That’s not a typo – 30 characters is still out of reach for most hash-cracking software.)
Here’s the most important piece of advice: Test your network regularly. New exploits are found every day, and hackers’ tools get better, faster, and cheaper every day. The only way to stay ahead of them is with professionals like us who live in their world every day.
And, trust me, you’d much rather have Raxis find your vulnerabilities than the bad guys.
A common finding in web applications we test is ‘Application Supports Simultaneous Logins’. This finding occurs when both of the following conditions are met:
The application allows for multiple sessions at the same time, from different devices, browsers, etc.
The application does not alert the user to the multiple sessions through:
Email notification,
Notification inside the application, or
A session management page inside the application.
Essentially, this boils down to the user being allowed to have multiple sessions without a way to manage them or see other active sessions through notifications or otherwise.
What does this look like?
In practice, we look in several locations for the functionality to manage sessions, but the most common place we find it is in profile sections or settings. When these are not available, we’ll log in on two separate browsers — or on two devices — and navigate them both to the settings page, checking for notifications or other session management abilities. An example of multiple sessions without notification to the user in a popular online platform is shown below:
Why does this matter?
Allowing simultaneous sessions seems innocuous at first. I mean, we mostly all have multiple devices that we log in through, right? True, but the lack of insight into your account’s session management becomes a problem if your session is somehow stolen, credentials are obtained, or your account is otherwise compromised through other vulnerabilities. If multiple sessions are allowed without notification to the user, there is no way for the user to know that their account has been compromised or to terminate the active sessions that have been compromised.
Remediations
In today’s world, disallowing multiple sessions is likely not realistic due to business constraints. Most people have several devices themselves, and logging in to an application on multiple is common, so this likely needs to be a feature in your application. However, alerting the user or allowing them to view their active sessions is important so they can maintain control of their account in the event of a breach. There are several ways to do this, with varying functionality, including:
Showing users active sessions with details about the session
Allowing users to terminate specific sessions
Providing functionality to log out the user from all other devices
Combine any of the above when the account password is changed
These are all valid approaches, but the specific one you choose to implement will depend on your application’s use cases, business constraints, and design. In our Raxis One application, we provide the user both with details about their active sessions, functionality for terminating specific sessions, and a session history that includes IP Address and location details, as shown in below:
The nature of cybersecurity is that threats evolve rapidly, and hackers often strike unpredictably. Despite the dynamic nature of the field, however, there are security frameworks in place to guide the development of effective cyber defenses. The ones used most frequently by security professionals are the National Institute of Standards and Technology (NIST) Framework for Improving Critical Infrastructure, also known as the NIST Cybersecurity Framework (NIST CSF), and the Center for Internet Security’s 18 CIS Critical Security Controls (CIS 18).
Depending on their industry and/or company size, Raxis customers are sometimes required to assess the maturity of their cybersecurity using these tools. Other times, they simply want to have a better internal understanding of their overall security posture and gaps. Regardless of the reason, the question we get most often is which standard is best for the company. Our team has vast experience with both CIS 18 (formerly SANS Top 20 or CIS 20) and NIST CSF v1.1 requirements, and we can develop a scope of work based on either.
That said, it’s important to understand exactly what these frameworks are and how they help improve your cybersecurity posture. Let’s start with CIS 18 as we’re asked about that one most often.
CIS 18
As the name suggests, the CIS 18 is a list of 18 primary security controls organized by activity. It is designed to measure an organization’s level of maturity as compared to a set of recommended standards.
The 18 CIS controls each include three categories of sub-controls, called implementation groups, that increase in complexity based on the maturity of the organization’s cyber defenses.
IG1 includes the base-level security controls every enterprise-level organization should have in place. Think of this as the minimum standard, designed to help companies with limited cybersecurity expertise thwart general, non-targeted attacks. There are 56 additional safeguards in this group.
IG2 is designed to help organizations that manage multiple IT departments, with varying degrees of risk, cope with increased operational complexity. It includes 74 additional safeguards.
IG3 is aimed at organizations that employ IT security experts and is designed to help them secure sensitive data and lessen the impact of cyberattacks. There are 23 additional safeguards included in IG3.
For customers who need a detailed analysis of each control, Raxis recommends our Enterprise CIS 18 Analysis. This includes an extensive interview and documentation process that will yield a detailed gap analysis and roadmap for hardening your defenses in accordance with the CIS controls.
NIST
The NIST CSF Version 1.0 was created in 2014 in response to the US government’s call for a voluntary framework to establish a “prioritized, flexible, repeatable, performance-based and cost-effective approach to managing cyberthreats.” Version 1.1 was released in 2018 and includes additional guidance and clarification.
Unlike CIS, the NIST framework is intended as a gap-analysis tool based on the organization’s target operational state. It includes a core set of five cybersecurity functions that present industry standards and guidelines for all levels of an organization. These are broken out as follows:
Identify: Develop an organizational understanding to manage cybersecurity risk to
systems, people, assets, data, and capabilities.
Protect: Develop and implement appropriate safeguards to ensure delivery of critical
services.
Detect: Develop and implement appropriate activities to identify the occurrence of a
cybersecurity event.
Respond: Develop and implement appropriate activities to act regarding a
detected cybersecurity incident.
Recover: Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity incident.
Within each function are categories which are groups of cybersecurity outcomes closely tied to needs and activities. An example would be “Data Protection.” Within each category are sub-categories which identify specific outcomes or operational states. For the preceding example, sub-categories include: “data is protected at rest” and “data is protected in transit.”
Another difference between CIS 18 and NIST CSF is that the latter also includes informative references, which map the CSF’s applicability to other frameworks, such as COBIT, ISO, ISA, CIS, and others.
For customers needing detailed reviews of each of the 108 NIST CSF sub-categories, Raxis recommends our Enterprise NIST Analysis. Like the Enterprise CIS 18 Analysis, this includes an extensive interview and documentation process that will yield a detailed gap analysis and roadmap for hardening your defenses, but this time in accordance with the NIST controls.
Security Framework Analysis (SFA)
For organizations that don’t have to meet regulatory compliance standards, it may still make sense to evaluate your security against a meaningful framework. This approach will look at groupings of controls versus individual controls and provide a gap analysis with road mapping based on your organization’s needs. Toward that end, Raxis offers security framework analysis (SFA) engagements that are based on the CIS 18 or the NIST CSF (as well as customized engagements for other frameworks that may fit your industry best).
Similar in purpose to our enterprise analyses, but reduced in scale, the Raxis SFA is designed for small and midsized businesses that want peace of mind knowing that they are addressing the broader security standards, but that don’t need the intensive, granular focus of the enterprise analyses.
Conclusion
Whether your goal is to satisfy a legal or industry requirement, to gain a better understanding of your security posture, or both, Raxis has the experience and expertise to guide you to the service that matches your needs. Our goal is to help you reach the highest level of security possible to protect your data, your customers, and your reputation.
The best place to start is a conversation with our experts. Just give us your contact information and we’ll be in touch.
The results from your vulnerability scan showed only a couple of low or moderate level findings, but there is no denying that two experienced hackers now have domain admin rights; the freshly printed summary document on your desk spells out in excruciating detail how they traversed the darkest corners of your network and gained access to critical data.
Fortunately for you, they’re Raxis team members, and you’ve paid them to do just that.
The Chained Attack
This scenario plays out frequently for Raxis customers who previously relied on companies that pass off vulnerability scans as faux penetration tests. It highlights why a scan, by itself, can give businesses a false sense of security about their cyber defenses. At their best, scans only point out individual links in what skilled and experienced hackers can turn into a chained attack – using one vulnerability to discover others, increasing or escalating network access with each move. In the case of parameter or business logic exposures, scans often remain blissfully unaware, failing to identify the exposures at all.
We’ll use a real-life example from a recent Red Team engagement to illustrate just how this works. Keep in mind that the following recap is just one way to employ a chained attack. There are many others. In fact, it’s such a common technique that it’s part of the test ethical hackers take to earn the Offensive Security Certified Professional (OSCP) certification. (Read about Senior Penetration Tester Andrew Trexler’s experience with the OSCP exam.)
The First Link
Using a response poisoning attack, our testers achieved Man in the Middle (MitM) and relayed Server Message Block (SMB) handshakes to hosts with SMB signing disabled, which allowed them to execute local commands and extract local password hashes stored by the security account manager (SAM). One of those hashes was associated with a local administrator account, and they used it to connect to a system on the internal network.
Once inside, they exploited a known design flaw in Windows authentication and used this local administrator hash in a Pass-the-Hash (PtH) attack using CrackMapExec (CME). They didn’t even have to crack the hash and get a cleartext password. Just sending the hash was sufficient to allow access.
Creating the Chain
Using PtH, our ethical hackers enumerated users logged on to a system, determined valid usernames, and extracted their Kerberos ticket hashes. This time, they did have to crack the hashed ticket for an administrative service account they found. A weak password and robust cracking hardware made this possible within seconds.
Having identified the cleartext password for that administrator account, they found that it was shared amongst numerous systems. They connected to other systems across the network and found a domain administrator logged into one of them. An attempt to access the Local Security Authority Subsystem Service (lsass.exe) file failed at first because the company’s security blocked “procdump.exe,” the tool we were using to gather a memory dump of the process. However, a second attempt with Process Explorer was successful and allowed our team to download a memory dump of the “lsass.exe” process, giving us access to the runtime state of the service that performs Active Directory database lookups, authentication, and replication.
Another tool, Mimikatz, enabled our testers to extract the contents of that file, including the reusable NTLM password hash of a Domain Administrator (DA). Again, using CME, they used the NTLM DA password hash to extract the contents of the entire Active Directory database. This is the database housing all Active Directory objects, including users and their password hashes for the entire domain (that often means every employee at a small company or every employee in a division of a large company).
“Vulnerability scans are excellent point-in-time snapshots of potential problems. But it takes comprehensive penetration testing to demonstrate how easily a malicious hacker can link them together to create a chained attack.”
Tim Semchenko
Owning the Network
Using this DA access, our team created a new backdoor domain administrator account in the Domain Admins group – ample proof for the customer that Raxis had in fact pwned their network.
What else could they have done? Anything they wanted, including staying on the system indefinitely or just logging in periodically to steal data or disrupt operations. Once a hacker has this type of access, it’s very difficult for a company to know if their access has been truly and completely removed.
How is this possible? Because a serious security flaw – one that would not be revealed in full by a vulnerability scan – offered our skilled team members an entry way to take down an entire network had they been bad guys.
The point is that vulnerability scans are excellent at providing a point-in-time snapshot of potential problems on your network. But it takes comprehensive penetration testing to find out just how serious those issues are and to demonstrate how easily a malicious hacker can link them together to create a chained attack.
In June of 2021, Secureworks Counter Threat Unit (CTU) discovered that the protocol used by Azure Active Directory (AD) Seamless Single Sign-On (SSO) allows for brute-forcing usernames and passwords without generating log events on the targeted tenant. In addition to brute-forcing credential pairs, the Azure endpoint returns error codes that allow for username enumeration. This post details the vulnerable endpoint, and how it can be exploited to brute-force usernames and passwords in a succinct Metasploit module.
Vulnerability Description
In addition to the normal Azure AD authentication workflow for SSO, which utilizes Kerberos, the usernamemixed endpoint of Autologon accepts single-factor authentication. Authentication attempts to this endpoint are in XML, as shown here:
The Autologon endpoint takes these credentials and sends them to Azure AD to authenticate the user. If the credentials are valid, the authentication is successful, and the Autologon endpoint responds with XML containing a DesktopSsoToken, which is used to further connect and authenticate with Azure AD. When a successful logon occurs, Azure AD properly logs the event.
However, on authentication attempts that are unsuccessful, the authentication attempt does not get logged by the tenant. If the credentials are invalid, the Autologon endpoint responds with XML containing a specific error code for the authentication attempt, as shown here:
The error code provided in this response can be further used to determine valid usernames, whether MFA is needed, if the user has no password in Azure AD, and more. The error codes used in the Metasploit module I developed are shown below:
Metasploit Module
The Metasploit module (auxiliary/scanner/http/azure_ad_login) can enumerate usernames or brute-force username/password pairs based on the responses from the Autologon endpoint described above. If you have a target tenant using Azure AD SSO and usernames/passwords to validate, you can use this module by setting the following variables:
DOMAIN – The target tenant’s domain (e.g., bionicle.dev)
USERNAME or USER_FILE – A single username to test or a file containing usernames (one per line)
PASSWORD or PASS_FILE – A single password or a file containing passwords (one per line)
When you run the module, every username/password pair is tested using the authentication XML request shown above to validate the pairing. When a valid username/password pairing is found, the DesktopSsoToken is also displayed to the user, as shown here:
Remediation and Protection
As of the writing of this post, there is no direct remediation to this vulnerability if your organization is using Azure AD with Single Sign-On. Microsoft has deemed this part of the normal workflow, and thus there are no known plans to remediate the endpoint. From a defender’s point of view, this vulnerability is particularly difficult to defend against due to the lack of logs from invalid login attempts. Raxis recommends the following to help defend against this vulnerability:
Ensure users set strong passwords in Active Directory by having a strong password policy.
Enable Multi-Factor Authentication on all services that may use AD credentials in case a valid username/password pair is discovered.
Consider setting a Smart Lockout policy in Azure that will lock out accounts targeted by brute-force attacks. This won’t help with password spraying, but will for single user brute-forcing.
Monitor for unusual successful logins from users (e.g. unusual locations).
Educate users about password hygiene so that they can learn to set strong passwords that won’t be caught by password spraying attacks.
Cross-site scripting (XSS) has been a popular finding for me in 2021, discovering five XSS vulnerabilities that have been assigned CVEs. Additionally, it’s been present on recent application testing as well, so I thought it would be beneficial to cover XSS in more depth.
This video is the first in a series of blog posts that will describe various cross-site scripting attacks, remediations, and specific areas to look out for that I have seen overlooked in the sanitization of user-supplied data. This video covers the basics of cross-site scripting, including reflected, stored, and DOM-based XSS. Additionally, I’ll discuss remediation to protect against these attacks. Future videos will cover filter evasion and side-loading payloads, as well as cookie theft and advanced payloads.
I hope this video and the ones that follow give you a better idea about how cross-site scripting works, why it’s dangerous, and how to prevent it from happening to your company.
Recently, I discovered a stored cross-site scripting (XSS) vulnerability in Nagios XI v5.8.5. The vulnerability exists in the dashboard page of Nagios XI (/dashboards/#) when administrative users attempt to edit a dashboard. The dashboard name is presented back to the user unencoded when the edit button is clicked, which can allow dashboard names with malicious JavaScript to be executed in the browser.
Proof of Concept and Exploitation Details
The vulnerability can be triggered by inserting html content that contains JavaScript into the name field of dashboards. The following payload was used to launch an alert box with the number 1 in it as a proof of concept:
“><script>alert(1)</script>
An example of this in the dashboard’s name field can be seen in the image below:
After clicking the edit button for the dashboard name, the dashboard’s name is loaded as unencoded HTML, as shown below:
After clicking the edit button for the dashboard name, the JavaScript from the script tag is executed as shown in the following image:
Vulnerable Software Version
Raxis discovered this vulnerability on Nagios XI v5.8.5.
Remediating the Vulnerability
Upgrade Nagios XI to version 5.8.6 or later immediately.
Disclosure Timeline
August 5, 2021 – Vulnerability reported to Nagios
August 6, 2021 – CVE-2021-38156 is assigned to this vulnerability
September 2, 2021– Nagios releases version 5.8.6 addressing this vulnerability
