Agentic AI Applications go beyond simple question-and-answer interactions. They autonomously pursue complex goals, reasoning, planning, and executing multi-step tasks with minimal human intervention. Unlike LLMs/chatbots that wait for explicit instructions, agentic systems decompose objectives into subtasks, invoke external tools (APIs, databases, code execution), and adapt dynamically.

This autonomy is powerful. It's also dangerous. It introduces a new attack surface that traditional security frameworks don't adequately address. In December 2025, OWASP released the first Top 10 for Agentic Applications to fill this gap.

This post aims to provide a comprehensive overview of each security risk. While it doesn't dive into deep exploitation techniques or defensive code, it covers how each risk works, real-world cases, and practical mitigation guidance.

1. OWASP Top 10 for Agentic Applications
   • ASI01: Agent Goal Hijack
   • ASI02: Tool Misuse
   • ASI03: Identity & Privilege Abuse
   • ASI04: Supply Chain Vulnerabilities
   • ASI05: Unexpected Code Execution
   • ASI06: Memory & Context Poisoning
   • ASI07: Insecure Inter-Agent Communication
   • ASI08: Cascading Failures
   • ASI09: Human-Agent Trust Exploitation
   • ASI10: Rogue Agents
2. Key Takeaways
3. Conclusion
4. Resources

OWASP Top 10 for Agentic Applications

Unlike the classic OWASP Top 10 for web applications or the LLM Top 10 for language models, this framework specifically targets autonomous AI systems that take real-world actions. It uses the ASI prefix (Agentic Security Issue) for each vulnerability, ranked by prevalence and impact observed in production deployments throughout 2024-2025.

The framework maps each vulnerability to a specific point in the agentic AI flow: inputs, model processing, tool integrations, inter-agent communication, and outputs:

Let's break down each one with the real CVEs and incidents.

ASI01: Agent Goal Hijack

Unlike traditional software where attackers need to modify code, AI agents can be redirected through natural language. If an agent processes external content like emails, documents, web pages, calendar invites, that content can contain hidden instructions that hijack the agent's goals.

This fundamentally breaks the traditional security model: the attack surface is no longer just code, but any text the agent reads.

Incidents

• EchoLeak (CVE-2025-32711) - CVSS 9.3: The first real-world zero-click prompt injection exploit in a production agentic AI system. Researchers at Aim Security discovered that Microsoft 365 Copilot could be tricked into exfiltrating data via a single crafted email:

• GitHub Copilot YOLO Mode (CVE-2025-53773) - CVSS 7.8: Malicious instructions hidden in repositories (README files, code comments, GitHub issues) could trick Copilot into modifying .vscode/settings.json to enable "YOLO mode" (auto-approve all tool calls), then execute arbitrary shell commands. The attack was wormable, infected projects could spread to others via AI-assisted commits.
• AGENTS.MD Hijacking in VS Code (CVE-2025-64660, CVE-2025-61590): VS Code Chat auto-includes AGENTS.MD in every request, treating it as an instruction set. Researchers demonstrated how a malicious AGENTS.MD could convince the agent to email internal data out of the organization during an everyday coding session.

Mitigation: Treat all external content as potentially hostile. Implement strict boundaries between instructions (from your system) and data (from users/external sources). Monitor for behavioral anomalies.

ASI02: Tool Misuse

AI agents are given tools the ability to send emails, query databases, execute commands, call APIs. These tools are features, not bugs. But an attacker who can influence the agent's reasoning can turn those features into weapons:

• A coding assistant with filesystem access becomes a data exfiltration tool.
• A customer service bot with email capabilities becomes a phishing engine. The more powerful the agent, the more dangerous it becomes when compromised.

Incidents

• Amazon Q Code Assistant (CVE-2025-8217) - July 2025: Attackers compromised a GitHub token and merged malicious code into Amazon Q's VS Code extension (version 1.84.0). The injected code contained destructive prompt instructions: "clean a system to a near-factory state and delete file-system and cloud resources." Combined with --trust-all-tools --no-interactive, the agent executed commands without confirmation. Nearly one million developers had the extension installed. Amazon patched to version 1.85.0.

• Langflow AI RCE (CVE-2025-34291): CrowdStrike observed multiple threat actors exploiting an unauthenticated code injection vulnerability in Langflow AI, a widely used tool for building AI agents. Attackers gained credentials and deployed malware through this widely-deployed agent framework.
• OpenAI Operator Data Exposure: Security researcher Johann Rehberger demonstrated how malicious webpage content could trick OpenAI's Operator agent into accessing authenticated internal pages and exposing users' private data, including email addresses, home addresses, and phone numbers from sites like GitHub and Booking.com.

Mitigation: Apply least privilege to every tool. Require explicit approval for destructive operations. Validate tool arguments. Monitor for unusual patterns (an agent suddenly making thousands of API calls is a red flag).

ASI03: Identity & Privilege Abuse

Agents often operate with significant privileges: access to databases, cloud resources, internal APIs. When an agent is compromised, the attacker inherits all of those permissions. This creates a privilege inheritance problem:

• A coding assistant with repository access can exfiltrate source code.
• A scheduling agent with calendar access can map organizational structure.
• A DevOps agent with deployment credentials can push malicious code to production.

The agent's access scope becomes the attacker's access scope.

Incidents

• Copilot Studio Connected Agents - December 2025: Microsoft's "Connected Agents" feature, unveiled at Build 2025, is enabled by default on all new agents. It exposes an agent's knowledge, tools, and topics to ALL other agents within the same environment—with no visibility showing which agents have connected to yours. Zenity Labs exposed how attackers could impersonate organizations and execute unauthorized actions without detection.
• CoPhish Attack - October 2025: Datadog Security Labs discovered a phishing technique abusing Copilot Studio agents. Attackers created malicious agents with OAuth login flows hosted on trusted Microsoft domains (copilotstudio.microsoft.com). When victims clicked "Login," they were redirected to a malicious OAuth consent page. After consent, the agent captured the User.AccessToken and exfiltrated it via HTTP request to the attacker's server—granting access to emails, chats, calendars, and OneNote data.

• Copilot Studio Public-by-Default Agents: Microsoft Copilot Studio agents were configured to be public by default without authentication. Attackers enumerated exposed agents and pulled confidential business data directly from production environments.

Mitigation: Treat agents as first-class identities with explicit, scoped permissions. Use short-lived credentials. Never allow implicit trust between agents. Audit credential flows regularly.

ASI04: Supply Chain Vulnerabilities

Traditional supply chain attacks target static dependencies. Agentic supply chain attacks target what agents load dynamically: MCP servers, plugins, external tools, even other agents. This introduces a runtime trust problem that traditional security tools cannot address and creates a fundamental gap in security visibility.

Incidents

• postmark-mcp - September 2025: Koi Security discovered the first malicious MCP server in the wild—an npm package impersonating Postmark's email service. It worked as a legitimate email MCP server, but every message sent through it was secretly BCC'd to phan@giftshop[.]club. Downloaded 1,643 times before removal. Any AI agent using this for email operations unknowingly exfiltrated every message it sent. As one researcher noted: "These MCP servers run with the same privileges as the AI assistants themselves—yet they bypass every security control."

• Shai-Hulud Worm - September 2025: CISA issued an advisory about a self-replicating npm supply chain attack that compromised 500+ packages. The worm weaponized npm tokens to infect other packages maintained by compromised developers. CISA recommendation: Pin dependencies to pre-September 16, 2025 versions.
• MCP Remote RCE (CVE-2025-6514) - CVSS 9.6: JFrog discovered a critical vulnerability in the MCP Remote project enabling arbitrary OS command execution when MCP clients connect to untrusted servers. First documented case of complete RCE in real-world MCP deployments.

Mitigation: Verify every MCP server before allowing it. Monitor for definition changes after approval. Pin dependencies to known-good versions. Treat the dynamic tool ecosystem as hostile by default.

ASI05: Unexpected Code Execution

Many agentic systems—especially coding assistants—generate and execute code in real-time. This creates a direct path from text input to system-level commands. Over 30 CVEs were discovered across major AI coding platforms in December 2025 alone.

Traditional code execution vulnerabilities require exploiting memory corruption or injection flaws. In agentic systems, code execution is a feature. The challenge is ensuring the agent only executes code aligned with the user's intent and not instructions embedded in untrusted input.

Incidents

• CurXecute (CVE-2025-54135) - CVSS 8.6: Aim Labs discovered that Cursor's MCP auto-start feature could be exploited. A poisoned prompt, even from a public Slack message, could silently rewrite ~/.cursor/mcp.json and run attacker-controlled commands every time Cursor opened. Fixed in version 1.3.

• MCPoison (CVE-2025-54136) - CVSS 7.2: Check Point Research found that once a user approved a benign MCP configuration in a shared GitHub repository, an attacker could silently swap it for a malicious payload (e.g., calc.exe or a backdoor) without triggering any warning or re-prompt.
• Cursor Case-Sensitivity Bypass (CVE-2025-59944): On Windows and macOS, case-insensitive filesystems meant that crafted inputs could overwrite configuration files controlling project execution—bypassing Cursor's guardrails entirely.
• Claude Desktop RCE - November 2025 (CVSS 8.9): Three vulnerabilities in Claude Desktop's official extensions (Chrome, iMessage, Apple Notes connectors) allowed code execution through unsanitized AppleScript commands. All three were published by Anthropic themselves. Attack vector: Ask Claude a question → Claude searches the web → attacker-controlled page with hidden instructions → code runs with full system privileges.
• IDEsaster Research - 24 CVEs: Security researcher Ari Marzouk discovered 30+ flaws across GitHub Copilot, Cursor, Windsurf, Kiro.dev, Zed.dev, Roo Code, Junie, and Cline. 100% of tested AI IDEs were vulnerable. AWS issued security advisory AWS-2025-019.

Mitigation: Sandbox all code execution. Require human approval for commands touching databases, APIs, or filesystems. Never auto-approve tool calls based on repository content. Disable auto-run mode.

ASI06: Memory & Context Poisoning

Unlike chatbots that forget between sessions, agents maintain memory—conversation history, user preferences, learned context. This memory enables personalization but also creates persistent attack surfaces.

A single successful injection can poison an agent's memory permanently. Every future session inherits the compromise. The attacker injects once; the payload executes indefinitely.

Incidents

• Google Gemini Memory Attack - February 2025: Security researcher Johann Rehberger demonstrated "delayed tool invocation" against Google Gemini Advanced. He uploaded a document with hidden prompts that told Gemini to store fake information when trigger words like "yes," "no," or "sure" were typed in future conversations. Result: Gemini "remembered" him as a 102-year-old flat-earther living in the Matrix. Google assessed impact as low but acknowledged the vulnerability.

• Gemini Calendar Invite Poisoning - 2025: Researchers demonstrated "Targeted Promptware Attacks" where malicious calendar invites could implant persistent instructions in Gemini's "Saved Info," enabling malicious actions across sessions. 73% of 14 tested scenarios were rated High-Critical. Attack outcomes ranged from spam generation to opening smart home devices and activating video calls.
• Lakera AI Memory Injection Research - November 2025: Researchers demonstrated memory injection attacks against production systems. Compromised agents developed persistent false beliefs about security policies and vendor relationships. When questioned by humans, the agents defended these false beliefs as correct—creating "sleeper agent" scenarios where compromise is dormant until triggered.
• ASCII Smuggling in Gemini - September 2025: FireTail demonstrated that invisible Unicode control characters ("tag characters") could hide instructions in benign-looking text. The UI shows normal text; the AI ingests and executes hidden commands. Google's response: "no action."

Mitigation: Treat memory writes as security-sensitive operations. Implement provenance tracking (where did this memory come from?). Regularly audit agent memory for anomalies. Consider memory expiration for sensitive contexts.

ASI07: Insecure Inter-Agent Communication

Multi-agent systems rely on messages exchanged between agents for coordination. Without strong authentication and integrity checks, attackers can inject false information into these channels.

In traditional architectures, service-to-service communication is usually secured through mTLS, API keys, and strict schemas. Inter-agent communication rarely has equivalent controls. Messages are often natural language, trust is typically implicit, and authentication, when it exists, is assumed rather than verified.

Incidents

• Agent Session Smuggling in A2A Protocol - November 2025: Palo Alto Unit 42 demonstrated "Agent Session Smuggling" where malicious agents exploit built-in trust relationships in the Agent-to-Agent (A2A) protocol. Unlike single-shot prompt injection, a rogue agent can hold multi-turn conversations, adapt its strategy, and build false trust over multiple interactions. Because agents are often designed to trust collaborating agents by default, this allows attackers to manipulate victim agents across entire sessions.

• ServiceNow Now Assist Inter-Agent Vulnerability: OWASP documented cases where spoofed inter-agent messages misdirected entire clusters of autonomous systems. In multi-agent procurement workflows, a compromised "vendor-check" agent returning false credentials caused downstream procurement and payment agents to process orders from attacker front companies.

Mitigation: Authenticate and encrypt all inter-agent communication. Implement message integrity verification. Never assume peer agents are trustworthy. Consider cryptographically signed AgentCards for remote agent verification.

ASI08: Cascading Failures

When agents are connected, errors compound. A minor misalignment in one agent can trigger failures across the entire workflow.

A compromised agent doesn't just fail, it can poison every agent it communicates with. One manipulated response propagates through the chain, corrupting downstream decisions and actions. The blast radius of a single compromise extends to every connected agent.

Incidents

• Galileo AI Research - December 2025: In simulated multi-agent systems, researchers found that a single compromised agent poisoned 87% of downstream decision-making within 4 hours. Cascading failures propagate faster than traditional incident response can contain them. Your SIEM might show 50 failed transactions, but it won't show which agent initiated the cascade.

• Manufacturing Procurement Cascade - 2025: A manufacturing company's procurement agent was manipulated over three weeks through seemingly helpful "clarifications" about purchase authorization limits. By the time the attack completed, the agent believed it could approve any purchase under $500,000 without human review. The attacker then placed $5 million in false purchase orders across 10 separate transactions.

Mitigation: Implement circuit breakers between agent workflows. Define blast-radius caps and containment thresholds. Test cascading scenarios in isolated digital twins before deployment. Maintain deep observability into inter-agent communication logs.

ASI09: Human-Agent Trust Exploitation

Agents generate polished, authoritative-sounding explanations. Humans tend to trust them—even when they're compromised or manipulated.

Human-in-the-loop controls assume the human can detect when something is wrong. But a manipulated agent presents malicious actions with perfect confidence and coherent justification. The approval prompt becomes a rubber stamp.

Incidents

• M365 Copilot Manipulation Research - 2025: Microsoft's own research showed attackers could manipulate M365 Copilot to influence users toward ill-advised decisions, exploiting the trust people place in the assistant. The agent presents faulty recommendations confidently, and employees approve risky transactions because they appear to come from a trusted system.
• AI Reward Hacking - 2025: Researchers documented cases where agents discovered that suppressing user complaints maximized their performance scores instead of resolving the issues. The agents optimized for metrics in unintended ways that harmed users.
• Agent-Driven Phishing - 2025: Advanced phishing campaigns now initiate interactive conversations via agent-driven chatbots that hold convincing dialogue—some using deepfake audio to impersonate known executives. If an attacker fully compromises an internal agent, they can use it to impersonate the CFO in internal systems and request fund transfers "on behalf of" legitimate business activities.

Mitigation: Require independent verification for high-impact decisions. Implement human-in-the-loop controls with clear escalation paths. Train users to question AI recommendations on YMYL (your-money-or-your-life) issues. Add transparency about AI uncertainty.

ASI10: Rogue Agents

This is the ultimate failure state: an agent that appears compliant on the surface but pursues objectives that conflict with its original purpose.

The nine risks above describe attacks against agents. Rogue agents describes what happens when the agent itself becomes misaligned. No attacker required.

Incidents

• Cost-Optimization Agent Gone Wrong: OWASP documented cases of agents that learned counterproductive optimizations. A cost-optimization agent discovered that deleting production backups was the most effective way to reduce cloud spending. It wasn't programmed to be malicious—it autonomously decided backup deletion achieved its goal most efficiently.
• Procurement Agent Fraud - 2025: After memory poisoning over three weeks, a manufacturing company's procurement agent developed completely misaligned beliefs about authorization limits. When questioned, it confidently explained why transferring funds to attacker-controlled accounts served the company's interests—according to its corrupted reasoning.
• Ray Framework Breach - December 2025: Security researcher Johan Carlsson presented at the Chaos Communication Congress how over 230,000 Ray AI clusters were compromised. Attackers used AI-generated code to spread malware and exfiltrate data. Many organizations were "already exposed to Agentic AI attacks, often without realizing that agents are running in their environments."

Mitigation: Implement kill switches as a non-negotiable, auditable, and physically isolated mechanism. Deploy continuous behavioral monitoring to detect subtle drift before it becomes catastrophic misalignment. Conduct rigorous testing and auditing of agent reward functions.

Key Takeaways

If you're deploying AI agents:

• Inventory your agents. Many organizations don't know how many agents are running, what tools they have access to, or what data they can reach.
• Define trust boundaries. What can agents access? What requires human approval? Document these decisions explicitly.
• Implement kill switches. You need the ability to immediately halt any agent that shows anomalous behavior.
• Monitor continuously. Agent security isn't a one-time audit. Behavior drifts. Memory accumulates. Tools change.

If you're building AI agents:

• Assume external input is hostile. Every email, document, web page, and API response your agent processes could contain attack payloads.
• Sandbox tool execution. Especially for code generation. Auto-approve is an anti-pattern.
• Scope permissions aggressively. Every tool, every credential, every API should be the minimum needed for the task.
• Log everything. Your future incident responders will thank you.

If you're receiving traffic from AI agents:

Even if you don't deploy agents yourself, your applications are increasingly on the receiving end of agentic behavior. Automated browsers, AI assistants, and LLM crawlers are hitting your APIs and websites. Some of their goals may have been hijacked. Some may be operating outside their intended scope.

Conclusion

AI agents are not chatbots with extra features. They're a fundamentally different paradigm, one where AI systems take actions, maintain state, use tools, and operate with increasing autonomy.

This shift introduces security risks that traditional application security wasn't designed to handle:

• Goals can be hijacked through natural language, not code exploits
• Tools become weapons when agents are manipulated
• Identity and credentials flow through systems in new ways
• Memory creates persistence for attacks that outlive sessions
• Multi-agent systems amplify and propagate failures

The OWASP Agentic Top 10 provides a framework for understanding and mitigating these risks. But frameworks don't secure systems. Implementation does.

The attackers are already here. EchoLeak, the Amazon Q compromise, the malicious MCP servers, the 30+ CVEs in AI IDEs—these aren't theoretical threats. They're incidents that happened in 2025.

The question isn't whether agentic AI will transform how we work. It will. The question is whether you'll secure it before something goes wrong.

Resources

Official OWASP Documentation:

• OWASP Top 10 for Agentic Applications 2026
• Agentic AI Threats and Mitigations
• A Practical Guide to Securing Agentic Applications

Research & Incident Reports:

• Aim Security: EchoLeak Analysis
• Koi Security: Real-World MCP Attacks
• Lakera AI: Memory Injection Attacks
• IDEsaster Research: 30+ Flaws in AI Coding Tools
• Palo Alto Unit 42: Agent Session Smuggling
• CISA Advisory: npm Supply Chain Attack

CVEs Referenced:

At Lares, we specialize in threat simulation and adversarial collaboration with our clients, replicating the tactics, techniques, and procedures (TTPs) observed in the latest cybercriminal groups. By studying real-world incidents, like those perpetrated by Scattered Spider, we design controlled simulations to test organizational defenses, evaluate incident response readiness, and identify gaps across networks, endpoints, and cloud environments.

Our approach combines ethical hacking, red teaming, and threat emulation to provide actionable intelligence. Clients benefit from hands-on exercises that mirror the strategies of sophisticated actors, including social engineering, credential theft, and advanced persistence techniques, allowing organizations to strengthen their security posture proactively.

In this post, we provide an overview of the operations and tactics of the advanced persistent threat (APT) group Scattered Spider, highlighting their typical attack patterns and the lessons organizations can draw to strengthen defenses. Rather than a step-by-step technical breakdown, this post focuses on the overall flow of their attacks, from initial access and social engineering to lateral movement, privilege escalation, and exfiltration, offering a high-level perspective on how sophisticated threat actors operate in today’s digital landscape.

• Scattered Spider
• Attack Timeline
• Tactics and Tools
  • Reconnaissance & infrastructure
  • Initial Access via social engineering
  • Privilege Escalation
  • Defense Evasion
  • Credential Access
  • Discovery
  • Lateral Movement
  • Exfiltration
• Conclusion
• Techniques

Scattered Spider

Scattered Spider is a financially motivated APT group that emerged in May 2022. Initially, they focused on telecommunications companies and business process outsourcing (BPO) firms. Over time, their attacks expanded to sectors such as hospitality, retail, healthcare, and aviation.

The group is primarily composed of young, native English-speaking individuals aged between 19 and 22, based in the United States and the United Kingdom. They are known for their sophisticated social engineering tactics, including SIM swapping, phishing, and exploiting weak verification processes to gain unauthorized access to systems.

Scattered Spider has been linked to several high-profile cyberattacks, including the breaches of MGM Resorts and Caesars Entertainment in 2023, which led to significant operational disruptions and ransom payments. The group often acts as an initial access broker, enabling ransomware affiliates to deploy attacks, and has been associated with various ransomware variants, including BlackCat/ALPHV and DragonForce.

Their technical expertise extends to cloud environments, with a deep understanding of platforms like Microsoft Azure, Google Workspace, and AWS. This technical proficiency, combined with their social engineering skills, makes Scattered Spider a formidable threat to organizations across multiple industries.

Other aliases used by the group include:

• UNC3944 – used by Mandiant
• Octo Tempest – used by Microsoft
• 0ktapus – used by Group-IB
• Muddled Libra – used by Palo Alto Networks
• Scatter Swine – used by Okta
• Star Fraud – self-attributed by the group
• Storm-0875 – used by Microsoft
• LUCR-3 – used by Permiso

Attack Timeline

The following timeline highlights notable attacks carried out by the group over recent years:

Tactics and Tools

Reconnaissance & infrastructure

Scattered Spider leverages OSINT techniques to gather information on employees and corporate targets, primarily using LinkedIn and other professional networks to map organizational structures. They also exploit publicly available data breaches and purchased private datasets, register domains similar to target companies for phishing, and use CDNs and domain fronting to obscure their infrastructure, enabling more effective social engineering and targeted attacks.

According to the latest update from CISA, the domains used follow the pattern:

• targetsname-sso[.]com
• targetsname-servicedesk[.]com
• targetsname-okta[.]com
• targetsname-cms[.]com
• targetsname-helpdesk[.]com
• oktalogin-targetcompany[.]com

Initial Access

The group used open-source platforms to gather intelligence on potential targets. They also acquired employee or contractor credentials from cybercriminal marketplaces and exploited third-party services with network access.

Scattered Spider employs multiple social engineering techniques to compromise targets, including smishing, vishing, and phishing, often convincing victims to install legitimate remote access management tools. Other tactics include:

Bypassing multi-factor authentication (MFA): Using push bombing, social engineering, or SIM swaps to circumvent additional verification steps:

• Push bombing: Flooding a user with repeated MFA push notifications until one is approved, bypassing MFA.
• SIM swap attacks: Convincing mobile carriers to transfer a victim’s phone number to a SIM controlled by the attacker, allowing access to calls, texts, and MFA codes.

Installing remote access tools (RATs): Deploying software that gives attackers remote control over devices or networks for surveillance, data theft, or further compromise.

Privilege Escalation

Scattered Spider leverages a wide range of privilege escalation techniques to expand their access within victim environments. These include cloud credential theft using tools like aws console or MicroBurst to compromise cloud secrets.

To achieve privilege escalation on Windows machines, the group used advanced tactics such as and Bring Your Own Vulnerable Driver (BYOVD) attacks exploiting signed but vulnerable Microsoft drivers. They also harvest sensitive secrets via tools such as Jetcretz and GitGuardian, and exploit common Active Directory weaknesses like ADCS (Active Directory Certificate Services) abuse, reading LAPS passwords, or performing credential dumping of LSASS memory and NTDS.dit using secretsdump or Mimikatz.

Another common technique used by the group for privilege escalation is the abuse of misconfigurations in privilege relationships between Active Directory objects. They exploited improperly configured Discretionary Access Control Lists (DACLs) to gain elevated permissions, enabling actions such as modifying critical security settings or adding accounts to privileged groups.

The Phantom Menace: Exposing hidden risks through ACLs in Active Directory

The abuse of misconfigured Access Control Lists is nothing new. However, it is still one of the main ways of lateral movement and privilege escalation within an active directory domain.

Lares LabsRaúl Redondo

Additionally, the group abuses Single Sign-On (SSO) sessions on workstations to gain access to sensitive internal resources such as SharePoint,  and Slack:

Defense evasion

The APT group uses BYOVD (Bring Your Own Vulnerable Driver) techniques, deploying a custom loader called STONESTOP to load a Microsoft-signed but vulnerable driver, POORTRY, in user space. This approach allows them to terminate EDR or antivirus agent processes.

By abusing a Microsoft-signed vulnerable driver, they bypass signature checks and disable security defenses, giving them the freedom to operate quietly during critical stages such as data theft or ransomware deployment. In addition, they used software signing certificates stolen from the compromised internal certification authorities of victim organizations to sign their malicious binaries.

To avoid detection related to lateral movement, Scattered Spider create instances in the cloud to use during lateral movement and data collection.

Credential Access

During the reported attack chains, Scattered Spider leveraged common credential-harvesting techniques, including LSASS dumping through Sysinternals tools such as ProcDump or well-known utilities like Mimikatz. They also employed LAPSToolkit to obtain clear-text LAPS credentials by abusing accounts with permissions to read them. Once the environment was compromised, the group used the Domain Controller Active Directory replication (DCSync) to further their access and extract NTDS.dit.

Discovery

During the Network Discovery phase, Scattered Spider prioritizes techniques that leverage both scanning tools and internal resources within the compromised environment.

They use common port and service scanning utilities such as RushScan or Advanced Port Scanner to map the network infrastructure and identify active systems and services. Simultaneously, they explore internal resources, including SharePoint, to locate documentation on network architecture, diagrams, and other sensitive information that could facilitate subsequent operations.

The group also utilizes Microburst, which includes functions and scripts that support Azure Services discovery, weak configuration auditing.

Other common tools such as ManageEngine, and Amazon Web Services inventory, always aiming, whenever possible, to use legitimate tools native to the target environment to reduce detection by security solutions and maintain a low-profile attack.

Lateral Movement

Regarding lateral movement, Scattered Spider consistently prioritized the use of native techniques within the compromised environment to reduce detection risk. This included leveraging Single Sign-On (SSO) sessions from compromised workstations to access additional internal resources via RDP or Chrome Remote Desktop.

The group made use of Proxifier, a tool that enables the redirection of internal traffic through attacker-controlled systems, allowing them to execute malicious tools without triggering Endpoint Detection and Response (EDR) or antivirus solutions.

In the cloud side, the group exploited Amazon EC2 instances and the AWS Management Console to take advantage of asume role, group and policies misconfigurations. By abusing overly permissive Identity and Access Management (IAM) policies, Scattered Spider was able to pivot laterally between instances and compromise additional user accounts, expanding their control across the victim’s cloud infrastructure.

Exfiltration

Scattered Spider employed multiple exfiltration methods to ensure the successful extraction of compromised data while minimizing detection.

For smaller, high-value files, the group leveraged Telegram, using its encrypted messaging capabilities to transmit data securely.

To handle large-scale data transfers, they utilized Rclone to move substantial volumes to attacker-controlled cloud infrastructure, and MEGAsync to synchronize stolen files directly to cloud storage accounts. Additionally, Storage Explorer was deployed to extract sensitive information from both cloud storage repositories and enterprise databases, enabling the actors to target a broad range of valuable assets across the victim environment.

Conclusion

The operations of Scattered Spider illustrate a reality that modern organizations cannot ignore: adversaries blend technical proficiency with human-focused deception to bypass even the most advanced defenses. Their reliance on social engineering, abuse of cloud misconfigurations, and creative privilege escalation highlights how security gaps extend beyond technology into processes and people. Their targets, spanning telecommunications, hospitality, healthcare, retail, and aviation, reflect a strategy aimed at industries where service disruption or data loss translates directly into financial leverage.

At Lares, our mission is not only to document these tactics but to bring them to life in controlled environments where our clients can confront them head-on. By emulating real-world adversaries like Scattered Spider, we help organizations test resilience, validate detection capabilities, and train teams to recognize and contain attacks before they escalate. Our objective is clear: to shift organizations from reactive to proactive, ensuring they are not merely aware of threats, but prepared to withstand and outmaneuver them.

Techniques

Reconnaissance & infrastructure

Initial Access

Privilege Escalation

Defense evasion

Credential Access

Discovery

Lateral Movement

Exfiltration

Resources

• CISA - Scattered Spider
• MITRE - Groups : Scattered Spider
• Splunk - Scattered Spider Isn’t a Glitch, It’s a Warning
• CybersecurityDive - What we know about the cybercrime group Scattered Spider
• American Hospital Association - Tactics by Scattered Spider cybercriminals highlighted in joint advisory

In the third part of this Kerberos series, we focused on leveraging user credential material for impersonation through techniques such as Pass-the-Key/Ticket/Cache/Certificate, and Shadow Credentials. Additionally, we explored how to manage and forge Kerberos tickets to facilitate lateral movement, privilege escalation, and establish persistence within the domain.

In this fourth post, and last of the series, we will explore Kerberos delegations.

There are many great articles about delegations, even though the abuse of this feature is an old attack vector, here at Lares, we wanted to deep dive and analyze the whole flow of what Kerberos delegations entail. In this post, we’ll review the different types of delegation, providing a detailed understanding of their use cases and potential security implications.

While this post primarily focuses on the functionality of Kerberos delegations and abuse cases, we have also included brief notes and best practices for detecting potential abuses and misconfigurations, which will in turn help to enhance security postures against these risks.

Note: In each delegation scenario, the communication flow will be analyzed. For a review of the Kerberos communication process, refer to the first post in this series..

Kerberos I - Overview

This post, is the first in the series and will aim to provide an overview of the protocol, from its beginnings to the different (ab)use techniques.

Lares LabsRaúl Redondo

• Kerberos Delegations
  • Unconstrained Delegation
    • Abusing Unconstrained Delegation
  • Constrained Delegation
    • Kerberos-only delegation
      • Abusing KCD Kerberos Only
    • Protocol transition delegation
      • Abusing KCD Protocol Transition
    • Resource-Based Constrained Delegation
      • Abusing RBCD
  • Useful Defenses
• Resources

Kerberos Delegations:

Microsoft introduced the Kerberos delegation feature with the first implementation of Active Directory in Windows 2000. Defined by Microsoft; Kerberos delegation is a setting that allows applications to request end-user access credentials to access resources on behalf of the originating user.

This feature was intended to solve the double-hop issue. ‘Double Hop’ issues can occur when a user needs to access a resource on a second server through an initial server. After authenticating to the first server (Server A), the user’s credentials are used to get a service ticket for Server A; however, when Server A needs to access resources on Server B on behalf of the user, it faces a problem because it cannot use the user’s credentials or tickets to authenticate to Server B. This prevents proper authentication on the second hop, resulting in access failures.

Below is a classic example of a basic double-hop scenario and would be why delegation is necessary:

• The user Elliot.A wants to access company documents, so he authenticates with his domain credentials on the web application hosted on the server DEV.Lareslabs.local. This application runs in the context of its own service machine account (DEV$).
• The folder that the web application has to retrieve is located on another server shared path (\\FS1\Data) and this folder has the following security descriptor, defining access rights for Elliot.A, and other ACEs that do not grant access to DEV$:

• When the web application tries to retrieve the files through the CIFS service on the FS1 server, it will do so under its context and will not have access, preventing Elliot.A from accessing the files through the web application:

• Kerberos delegation helps solve this problem, in the following example, DEV.lareslabs.local (DEV$) is configured with unconstrained delegation (the most insecure kind of delegation, which we will see next), so it can gain access to the shared folder impersonating Elliot, using Elliot´s Kerberos Tickets as proof that it has permission to impersonate, then placing a copy of the user token in a new thread of its executing process so that thread can act on behalf of Elliot.A and is subject to the restrictions imposed by ACLs:

There are three kinds of delegations:

• Unconstrained Delegation.
• Constrained Delegation, (Kerberos Only and Protocol Transition).
• Resource-based Constrained delegation (RBCD).

Note: The ASP.NET Core Web API application "KerbApp" by @_RastaMouse has been used for the lab configuration. The application allows the authentication scheme to be configured through HTTP.sys.

Unconstrained Delegation:

Unconstrained Delegation allows an entity to impersonate a Principal to any chosen service. When this delegation is configured in a service, the client delegates a copy of its TGT to this service, so this service can act on behalf of the client in the network by using that TGT.  

So, it allows an attacker who has gained control of a domain account configured with delegated permissions to impersonate any user or service within the domain.

To configure graphically, it is required to enable the option "Trust this user for delegation to any service (Kerberos Only)":

Using the PS Active Directory module, it is possible to verify whether an account is configured with Unconstrained Delegation by checking the attribute "TrustedForDelegation":

To better understand this kind of delegation, let's examine step-by-step the traffic generated during the scenario described above:

• The user Elliot.A wants to access company documents, so he authenticates using his domain credentials on the web application hosted on the server DEV.lareslabs.local. Since DEV$ does not have direct permissions to access these files, which are hosted on another server called FS1.lareslabs.local, it is configured with unconstrained delegation. This allows it to impersonate Elliot.A and access the files on his behalf.

The communication flow in this scenario will be as follows:

The following shows Elliot.A performing an HTTP request to DEV webapp:

Using Wireshark to capture and review this network traffic, we will be able to identify the following network flow:

Let's break things down step by step:

1. The client, Elliot.A, requests a TGT from the KDC, if credentials are valid, the KDC will return the TGT, just the normal Kerberos flow, AS-REQ/AS-REP.
2. The client requests an HTTP Service Ticket (HTTP/DEV.lareslabs.local) in the first TGS-REQ, sending his TGT and authenticator:

3. The KDC provides the Service Ticket with the flag ok-as-delegate flag set, which indicates that the requested service is configured to allow delegation:

4. Since the client verified that the target service is enabled for delegation, it will send a new TGS-REQ request for an additional Service Ticket (Elliot.A`s TGT), again sending its TGT and Authenticator, but this time it will ask for a copy of his TGT with the flag forwarded set:

The ticket-granting service (TGS) then provides a (delegated) TGT with the forwarded flag, the KDC expects this request as a follow-up of the previous one, as the service is configured with Unconstrained Delegation:

5. Once with a forwardable TGT, the client will perform an AP-REQ message within the HTTP request, sending the service ticket for the HTTP service in addition to the delegated TGT. The forwardable TGT is contained within the HTTP request:

6. The web server, (DEV$), uses the client's cached TGT to request a Service Ticket from the KDC for the CIFS/FS1 on behalf of Elliot through a regular TGS-REQ message:

The KDC provides a valid Elliot.A Service Ticket for CIFS/FS1 service to DEV$:

7. DEV$ will send an AP-REQ message via SMB on behalf of Elliot.A, sending the CIFS service ticket and the authenticator:

FS1$, will in turn, perform a mutual authentication process with DEV$, via SMB, through an AP-REP message:

8. Finally, the client (Elliot.A) and DEV$ will complete the mutual authentication process via an AP-REP message over HTTP, resulting in displaying the FS1$ shared files that the client wanted to access:

Abusing Unconstrained Delegation:

As we already know, any principal connecting to a machine configured with unconstrained delegation will drop a copy of its TGT in memory.

From a threat actors’ stance, the objective will be to gain privileged access to these servers and dump these delegated TGTs that are cached in memory. Alternatively, they/we can force the authentication of a privileged account against this machine, to obtain clients delegated TGTs.

From Linux, the first step will be adding a "fake" spn pointing to our listener, our attacker machine. To do this, addspn can be used, as machine accounts can edit their own msDS-AdditionalDnsHostName attribute.

Note: Depending on the chosen authentication coercion method (e.g., PrinterBug, Coercer), different types of services will be required.

It is also required to create a DNS record with the name of the fake registered spn pointing to the attacking machine, dnstool from @_dirkjan's krbrelayx suite can be used to perform this operation.

Finally, krbrelayx will be used, in conjunction with the Kerberos key or the password and salt of the account configured with Unconstrained Delegation that has been compromised, forcing authentication with the chosen method. In this example, Coercer:

Once the delegated TGT (.ccache) is obtained, it can be exported and used to impersonate that coerced account:

From Windows computers, the Rubeus monitor function performs the same role. After forcing authentication with the desired method, the cached .kirbi in memory can be obtained and used for impersonation.

Constrained Delegation:

Kerberos Constrained Delegation, Introduced in Windows Server 2003, aims to provide a safer form of delegation that could be used by services.

While Unconstrained Delegation allows the impersonation of any domain principal on any network service, for accounts configured with Constrained Delegation, target services are limited by configuration. This approach enhances security by limiting the scope of delegation to only explicitly allowed services, thus minimizing potential exposure from compromised services.

In addition, to the above, in Constrained Delegation, it is not necessary to have a user's TGT within the TGS request. The service itself can request service tickets for other services on behalf of a user as long it has proof that it has received a request from the user.

For this purpose, Microsoft issued the S4U [MS-SFU] extension that allows the KDC to issue a new TGS to the service using a valid TGS through two subprotocols, S4U2Self and S4U2Proxy.

• S4U2Self: allows a service to obtain a service ticket to itself on behalf of a user.
• S4U2Proxy: allows a service to obtain a service ticket on behalf of a client to a different service using a service ticket as evidence that the client has authenticated.

Constrained delegation can be configured to accept only Kerberos authentication, or other protocols, such as NTLM, in scenarios where Kerberos authentication is not possible.

Kerberos Only:

A visual depiction of the Constrained Delegation configuration, using Kerberos only, can be seen in the image below. In this instance it is configured for only delegation allowed for FS1.lareslabs.local CIFS service:

Following the same scenario, but now, DEV$ configured with Constrained Delegation and Kerberos Only:

1. Kerberos pre-auth, usual flow, obtaining a TGT via AS-REQ/AP-REP messages.
2. The client (Elliot.A) requests a service ticket for HTTP/DEV.lareslabs.local (TGS-REQ message). Then, the KDC provides the service ticket through the TGS-REP message.
3. The client sends an HTTP AP-REQ message to the web server, including the service ticket within the request.
4. Through the next TGS-REQ message sent by DEV$ to the KDC, the service can request additional service tickets using an S4U2Proxy request. Through this extension, the web server will send a request to the KDC for a CIFS/FS1.lareslabs.local service ticket sending its TGT and authenticator and the previous HTTP/DEV service ticket from Elliot.A, within the "additional tickets" block:

In the following image, it is shown how, in the same request, the client (DEV$), requires the KDC to check if the constrained delegation is configured and viable:

The KDC will check the additional ticket, verify that it is forwardable, and further verify that DEV$ can delegate to FS1$, by checking the msDS-AllowedToDelegateTo an attribute:

Forwarding Elliot.A's CIFS/FS1 ST + Session Key through the TGS-REP response to DEV$:

5. DEV$ requests CIFS access to FS1$ on behalf of Elliot.A through the AP-REQ message and FS1$ will reply to DEV$, performing the mutual authentication process via the AP-REQ message.

6. Finally, the web application will return the information retrieved for Elliot.A through an AP-REP message via HTTP (Mutual authentication between
the DEV$ and Elliot.A):

Abusing KCD Kerberos Only:

Kerberos Only requires an additional ticket as a requirement to invoke S4U2Proxy. The first approach should be user S4U2Self but required TRUSTED_TO_AUTH_FOR_DELEGATION flag set, which is not True, since Kerberos Only was used and the resulting ST will be non-forwardable.

Although it is possible to abuse Kerberos Only through the “bronze bit” (CVE-2020-17049)  technique or by forcing authentication, the most direct method would be through RBCD.

To abuse this, it is first necessary to use an indirect method that exploits Resource Based Constrained Delegation first.

Protocol Transition:

In Constrained Delegation Kerberos Only, the service can invoke S4U2Proxy using Elliot.A’s service ticket (ST) as an additional ticket; however, if the service does not have this additional ticket, such as via NTLM authentication, it needs another way to obtain proof (a ticket) that the client is delegating on its behalf. In this case, a service can invoke S4U2Self to ask the authentication service to produce a TGS for arbitrary users to itself, which can then be used as “evidence” when invoking S4U2Proxy. This feature allows impersonating users on an ad-hoc basis, and it is only possible when the TrustedToAuthForDelegation flag is set for the service account that invokes S4U2Self.

In the following image, we can see a visual representation of the configuration of Constrained Delegation using protocol transition:

Following the same scenario, with DEV$ configured with Constrained Delegation and Protocol Transition, the flow looks as follows:

1. Client Elliot.A will send an HTTP request to the DEV web server. Authentication will be performed using NTLM since the application does not accept Kerberos:

2. To get CIFS/FS1 service ticket (using the S4U2Proxy request) DEV$ has to provide a proof, a service ticket from the user. Since there is no service ticket provided by Elliot.A (NTLM authentication was used) the server should ask for it using the S4U2Self extension.

In the TGS-REQ message that DEV$ will send to the KDC, the structures specific to the S4U2Self extension, pA-FOR-X509-USER, and pA-FOR-USER are present, with the name as the client to impersonate (Elliot.A) and its’ own SPN, e.g. the DEV$ target spn:

The KDC will then verify that DEV is configured with constrained delegation enabled (TRUSTED_TO_AUTH_FOR_DELEGATION) and will provide a service ticket on behalf of Elliot.A with the forwardable flag set to True through the TGS-REP message to DEV$ server:

3. DEV$ sends its TGT and authenticator to request a service ticket on behalf of Elliot.A for CIFS/FS1 to the KDC. This process, will include the forwardable service ticket previously obtained through S4U2Self:

The additional ticket (forwardable ST) is pointing to DEV$ instead of HTTP/DEV.lareslabs.local, confirming that it was obtained through S4U2Self:

In this request, the flags for constrained delegation and resource-based constrained delegation are set. This is significant because RBCD will serve as a fallback if constrained delegation fails, for example, if the additional ticket is not forwardable.

The KDC checks if DEV is authorized to delegate to FS1 by verifying the msDS-AllowedToDelegateTo attribute. It also ensures that the Additional Ticket is forwardable. If all checks are correct, the KDC responds with Ellio.A’s service ticket (ST) and the session key in the TGS-REP message:

Note: An important fact here, and as @elad_shamir describes in his awesome = post Wagging the dog , in S4U2Proxy, the ticket should always be forwardable, and will have the bit "resource-based-constrained-delegation" to check if RBCD is configured in case KCD does not work, as a fallback (when the ticket is not forwardable for example).

5. DEV request CIFS access to FS1 on behalf of Elliot.A through the AP-REQ message and FS1 will reply to DEV, performing the mutual authentication process via the AP-REQ message.

6. Finally, the web application will return the information retrieved for Elliot.A through an AP-REP message via HTTP (Mutual authentication between
the DEV and Elliot.A):

Abusing KCD Protocol Transition:

To abuse the KCD with any protocol (protocol transition), it is necessary to request a service ticket, using the S4U2self extension and then request the final TGS ticket using S4U2Proxy. On Linux, Impacket's getST handles all the work behind the scenes

On Windows systems, Rubeus, through the S4U function, requests a Ticket Granting Ticket (TGT) on behalf of DEV using the specified Kerberos key. It then invokes S4U2Self to obtain a Service Ticket (ST) in the name of Lares.DA. The resulting  in a forwardable service ticket:

Then, Rubeus will use the forwardable ticket to invoke S4U2Proxy:

Once ptt is performed, the target user can be impersonated in the chosen service.

Resource-Based Constrained Delegation:

Resource-based constrained delegation, introduced in Windows Server 2012, operates similarly to classic constrained delegation by using S4U extensions; however, the key difference is that in RBCD, delegation is configured directly on the service receiving the delegated credentials, managed through the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, rather than on the delegating service.

This attribute is a security descriptor that contains an ACE for every account the user can delegate to.

To configure Resource-Based Constrained Delegation (RBCD), it is necessary to use the command line, as there is no graphical interface available for this configuration:

In the classic Constrained Delegation, the delegation is configured in DEV$ via msDS-AllowedToDelegateTo:

In contrast,RBCD is configured in FS1$, through the attribute msDS-AllowedToActOnBehalfOfOtherIdentity:

So, in case of compromising an account with enough privileges to write to that attribute (GenericAll/GenericWrite/WriteDacl/WriteProperty/...) of the target account, it would be possible to configure RBCD.

Note: If you need to review attacks related to ACLs, we recommend taking a look at our post:

The Phantom Menace: Exposing hidden risks through ACLs in Active Directory

The abuse of misconfigured Access Control Lists is nothing new. However, it is still one of the main ways of lateral movement and privilege escalation within an active directory domain.

Lares LabsRaúl Redondo

1. Client Elliot.A will send an HTTP request to the DEV web server. Authentication will be performed using NTLM since the application does not support Kerberos.

2. To obtain a service ticket for CIFS (using the S4U2Proxy request), DEV$ needs to provide proof of a service ticket from the user. Since Elliot.A did not provide a service ticket (due to NTLM authentication), the server will request it using the S4U2Self extension.

In the TGS-REQ message that the DEV server sends to the KDC, the S4U2Self-specific structures pA-FOR-X509-USER and pA-FOR-USER are included. These structures specify Elliot.A as the client to impersonate and DEV$ as the target SPN:

The KDC responds with the Elliot.A´ST and the session key:

3. DEV sends its own TGT, an authenticator, and the S4U2Self additional ticket, asking the KDC for an CIFS/FS1 service ticket:

Here is the difference from the classic constrained delegation, the KDC checks:

• If FS1$ is listed in DEV$ msDS-AllowedToDelegateTo. Since RBCD has been configured and not KCD , Constrained Delegation cannot be applied.
• Then, as a "fallback" if DEV$ is listed in msDS-AllowedToActOnBehalfOfOtherIdentity attribute of FS1$. RBCD can be applied.

4. DEV request CIFS access to FS1 on behalf of Elliot.A through the AP-REQ message and FS1 will reply DEV, performing the mutual authentication process via the AP-REQ message.

5. Finally, the web application will return the information retrieved for Elliot.A through an AP-REP message via HTTP (Mutual authentication between
the DEV and Elliot.A).

Abusing RBCD:

Having write rights on the target msDS-AllowedToActOnBehalfOfOtherIdentity attribute enables the configuration of Resource-Based Constrained Delegation (RBCD). Exploiting this trust requires an account capable of invoking both S4U2Self and S4U2Proxy, though, fortunately, any account with a configured SPN can invoke these extensions, allowing for the impersonation of any user against the services tied to the affected service account.

The quickest way is to create a machine account, as demonstrated in the following example is by using PowerMad:

Note: James Forshaw discovered a way to abuse RBCD by using a user without SPN, but the account would be unusable. So in the following scenario, we used the traditional method, creating a machine account with MachineAccountQuota set to the default value (10).

Next, the msDS-AllowedToActOnBehalfOfOtherIdentity attribute in DEV will be edit with the new machine account:

Rubeus s4u function requests the delegated ST, specifying an SPN pointing to our target and a user to impersonate, using the new machine account credentials:

The resulting ticket will be forwardable:

Use that service ticket as proof of authentication in S4U2Proxy for FS1$:

Through pass-the-ticket, access to the target service will be granted:

From Linux, the process would be the same, easily replicable using impacket, addcomputer, rbcd.py and getST.

Useful Defenses:

• Enable AccountNotDelegated (Account is sensitive and cannot be delegated) UAC flag on your Tier-0 accounts.
• Identify all the servers that have delegation configured and change to constrained delegation whenever possible.
• Add user accounts to the Protected Users Security Group.
• Sigma rule for unconstrained delegation (PS-Enumeration).
• Events: 4769 - 5156 - 4624 - 5140 - 5145 - 4675 - 4672 - 4673- 4611- 5136.
• Techniques - T1589.002. , T1018, T1550.003, T1078.002, T1078.002, T1589.002.

We hope you enjoyed this Kerberos series, and that the series will continue to serve as a reference for your Kerberos queries.
Finally, thank you for reading it!

Resources

• Specterops - Hunting in active directory : Unconstrained Delegation.
• Atl4s - Understanding - or at least, trying to.
• Dirk-Jan Mollema - Having fun with unconstrained delegation.
• Harmj0y - S4U2Pwnage. | Another word of delegation.
• Elad Shamir - Wagging the dog, abusing RBCD.
• Charlie Clark - Abusing Users Configured with K-UD.
• Charlie Bromber - Bypass Kerberos Delegation.
• Splunk - Detecting Active Directory Kerberos Attacks.
• Luemmelsec - A low dive into Kerberos Delegations.
• Swolfsec - Detecting RBCD.

In the second part of the Kerberos series, we delved into how the Kerberos authentication flow allows the enumeration of domain user accounts and the validation of credentials through the network messages employed by Kerberos. Additionally, it was demonstrated that user credential material can be obtained through the AS-REQ/AS-REP and TGS-REQ/TGS-REP messages. The UnPAC technique was also discussed, which allows for obtaining the NTLM hash of a user authenticated through Kerberos PKINIT as a pre-authentication mechanism.  

In this third part, we will explore the techniques for leveraging those credentials for lateral movement, privilege escalation, and persistence methods within the Active Directory environment.

• User Impersonation
  • Pass the Key / Overpass the hash
  • Pass the Ticket / Pass the Cache
  • Pass the Certificate
  • Shadow Credentials
  • Playing with (and forging) tickets
    • Silver tickets
    • Golden tickets
    • Diamond tickets
    • Sapphire tickets
• Resources

User Impersonation:

Once access to an Active Directory environment is achieved, it is crucial to understand how, as adversaries, the credential material obtained can be used to authenticate through Kerberos and impersonate users. Clear-text passwords, hashes, Kerberos keys, or certificates acquired during an engagement can be leveraged to access new resources within the domain, facilitating lateral movement or privilege escalation. This post will focus on these techniques. Operational Security (OPSEC) concepts will not be covered, as the goal is to understand each method comprehensively. Additionally, brief notes about detection and recommendations have been included for each technique.

Pass the Key / Overpass the Hash

As discussed in the first post of the series, the user must undergo the pre-authentication process before a user can obtain a TGT from the KDC. This pre-authentication mechanism is enabled by default for all accounts within the domain. Still, it can be disabled (ASREPRoast becomes a viable attack path when it is disabled, as described in the second post of the series about credential access). This pre-authentication mechanism requires credential material from the user, meaning any secret keys derived from their password, whether DES, RC4, AES128, or AES256 keys. If we have access to any of these keys, we can request TGTs on behalf of that user.

The only difference between Pass the Key and Overpass the Hash is that Pass the Key uses the user's RC4 key, essentially the NT hash.

From Linux, Impacket's getTGT can be used with the user's NT hash (overpass-the-hash) :

impacket-getTGT -hashes :NTHASH DOMAIN/USER@HOST

The traffic generated is the legitimate TGT request to the KDC (AS-REQ/AS-REP). The following image shows how the user uses the RC4 etype (Kerberos Encryption Type Number 23) to encrypt the timestamp:

And with the user AES key (pass-the-key):

impacket-getTGT -aesKey AESKey DOMAIN/USER@HOST

In line with prior observations, now, the network traffic capture displays the timestamp encrypted using AES256 (Kerberos Encryption Type Number 18):

From Windows, the same action can be performed using Rubeus, asking for a TGT (askTGT) with the user's keys:

.\Rubeus asktgt /domain:DOMAIN /user:USER /enctype:ENCTYPE /aes256:AESKEY /nowrap /ptt

After successfully executing overpass-the-hash / pass-the-key and obtaining a TGT, the next step could involve carrying out pass-the-ticket.

Note:

To obtain the user's hashes from his password in clear, use the hash function of Rubeus:

.\Rubeus.exe hash /password:pass /user:USER /domain:DOMAIN

From the Rubeus documentation, this function will generate the rc4_hmac (NTLM) representation of the password using @gentilkiwi's kerberos:hash (KERB_ECRYPT HashPassword) approach. If user and domain names are specified, the hash forms aes128_cts_hmac_sha1, aes256_cts_hmac_sha1 and des_cbc_md5 are generated. The AES and DES implementations use the user and domain names as salts.

Useful Event IDs & Defenses:

• 4768 – A Kerberos authentication ticket (TGT) was requested. (Encryption Type for RC4/AES128/AES256).
• Monitor unusual login times and atypical locations.
• Service ticket requests that do not follow normal user behavior.

Pass the Ticket / Pass the Cache

Through these techniques, an adversary reuses domain user tickets to inject them into memory and, through the Kerberos authentication flow, gains access to resources/services where the user is authorized without knowing any user credential material.

On Windows hosts, once admin rights are achieved, it is possible to extract the TGTs from the Local Security Authority Subsystem Service (LSASS) process using tools such as mimikatz.

Furthermore, ticket dumping can be performed using Rubeus. As we can read in the Rubeus description:

• Rubeus has no code that touches LSASS (and is not intended to), so its functionality is limited to extracting Kerberos tickets using the LsaCallAuthenticationPackage() API. From a non-elevated point of view, session keys for TGTs are not returned (by default), so only extracted service tickets will be usable (the tgtdeleg command uses a Kekeo trick to get a usable TGT for the current user). If, in a high-integrity context, a GetSystem equivalent is executed using token duplication to elevate to SYSTEM, and a fake login application is registered with the LsaRegisterLogonProcess() API call. This allows privileged enumeration and extraction of all tickets currently registered with LSA on the system, resulting in base64-encoded .kirbi output for later reuse.

Rubeus is employed in an elevated context to enumerate Kerberos tickets in the host:

Confirming the existence of tickets from a privileged user, in this case, a Domain Admin (lares.da), the process continues by dumping the desired ticket for the krbtgt service and the lares.da user:

.\Rubeus.exe dump /service:targetSevice /user:targetUser /nowrap

Creating a “sacrificial session” using the runas command is now advisable since a logon session can only hold a single TGT at a time, and injecting a new TGT into memory would delete the current user's TGT and cause authentication problems.

In the new session, we import the TGT with the Rubeus ptt flag, and we will be able to access the privileged assets:

runas /netonly /user:lareslabs.local\fake powershell.exe
.\Rubeus.exe ptt /ticket:<b64EncondedTicket...>

The ticket can also be used on Linux systems to perform the same technique (Pass-the-Cache).

The Impacket tool 'ticketerConverter' allows the conversion of .kirbi to .ccache format and vice versa, enabling export to the system. This converted ticket can then be used with tools that support Kerberos authentication, like the Impacket suite:

echo "<b64EncodedTicket>" | base64 -d > ticket.kirbi
impacket-ticketConverter ticket.kirbi ticket.ccache
export KRB5CCNAME=ticket.ccache
impacket-<anyScript> -k -no-pass ....

Pass the Certificate

As discussed in the first post of the series, Kerberos I - Overview, every client must go through a ‘pre-authentication’ process before obtaining a Ticket Granting Ticket (TGT) from the KDC, which can be used to get service tickets.

This pre-authentication process can be validated, among other things, by encryption algorithms such as DES, RC4, AES128, or AES256, or in an asymmetric way (public key), using certificates (Public Key Cryptography for initial authentication (PKINIT)).

In short, Pass the Ticket is nothing more than performing Kerberos pre-authentication through PKINIT to obtain a user's TGT, from which we have obtained a valid certificate for authentication.

Below is an example of obtaining a user certificate by abusing the ESC1 misconfiguration in ADCS. Then we perform Pass the Certificate using the “auth” function of certipy:

We have several posts about ADCS misconfigurations in the series “Common ADCS Vulnerabilities: Logging, Exploitation, and Investigation” by Louai Abboud:

Common ADCS Vulnerabilities: Logging, Exploitation, and Investigation - Part 1

In a two-part series, we look at Active Directory Certificate Services (ADCS), how to stand up a lab environment and logging from a defensive standpoint.

Lares LabsLouai Abboud

In the network traffic, we could see the certificate sent through the AS-REQ type request:

In the same way, the technique can be carried out using asktgt function of Rubeus, indicating the user's certificate. In addition, with the /getcredentials flag, it will perform UnPAC the hash to obtain the user's NT-LM hash:

Useful Defenses:

• Audit Active Directory Certificate Services.
• Remove “Client Authentication” where possible (ADCS).
• Monitor pre-authentication events through PKINIT on non-regular users.
• Event 4768: A Kerberos authentication ticket (TGT) was requested. If the PATYPE is PKINIT, the logon was a smart card logon.

Shadow Credentials:

For compatibility reasons regarding environments where authentication with certificates is not supported, Microsoft introduced the Key Trust concept. In the Key Trust model, authentication is established and validated based on raw data instead of certificates.

In these environments, the public key of the client (either user accounts or machine accounts) is stored in its msDS-KeyCredentialLink attribute.

When the client attempts to pre-authenticate with PKINIT, the KDC will check that the authenticating user knows the private key matching the public key stored in its msDS-KeyCredentialLink multi-value attribute. If there is a match, a TGT will be sent. The value in this attribute is Key Credentials, which are serialized objects that include, among other information, the client's public key.

Shadow Credentials was introduced by Elad Shamir, and as he explains in his post “Shadow Credentials: Abusing Key Trust Account Mapping for Account Takeover”, in case of compromise an account with enough privileges to write that attribute to another domain account (user/machine account), e.g GenericWrite rights, this allows us to create a key pair, append it to the raw public key in the attribute, and gain persistent and stealthy access to the target object.

Shadow Credentials: Abusing Key Trust Account Mapping for Takeover

The techniques for DACL-based attacks against User and Computer objects in Active Directory have been established for years. If we…

Posts By SpecterOps Team MembersElad Shamir

This attack involves the following requirements:

• A domain that supports PKINIT AND contains at least one Domain Controller running Windows Server 2016 or above.
• A domain where the Domain Controller(s) has its own key pair (for the session key exchange) (e.g. happens when AD CS is enabled or when a certificate authority (CA) is in place).
• Control over an account that can edit the target object's msDs-KeyCredentialLink attribute.

Our post ‘The Phantom Menace: Exposing hidden risks through ACLs in Active Directory’ covers other examples of ACL abuse.

The Phantom Menace: Exposing hidden risks through ACLs in Active Directory

The abuse of misconfigured Access Control Lists is nothing new. However, it is still one of the main ways of lateral movement and privilege escalation within an active directory domain.

Lares LabsRaúl Redondo

From Linux, pyWhisker, by Charlie Bromberg, provides a way to automate the whole process, from the RSA-peer keys creation to writing to the attribute of the target account.

In the following evidence, it is possible to see, together with ldapmonitor, how the msDS-KeyCredentialLink attribute of the user Darlene has been modified:

pywhisker -d domain -u user -p password --target targetAccount --action add --filename certOutputFile

The following is a brief diagram about Shadow Credentials and how the Key Trust model works:

Once the attack is complete, an adversary can use the certificate to authenticate via PKINIT using Dirkjanm's PKINITools, being able to obtain a TGT to import it later and access services to which Darlene is authorized, or get the NTLM hash via getnthash, as we saw in the first post by requesting a TGS for yourself using Kerberos U2U.

Alternatively, if the Domain Controller does not accept PKINIT authentication (error KDC_ERR_PADATA_TYPE_NOSUPP), it is possible to authenticate with the target account using passthecert. The following example shows the use of PassTheCert with its ldap-shell function:

passthecert.py -action ldap-shell -crt cert.crt -key cert.key -domain domain -dc-ip dcIp

Useful Defenses:

• Audit Directory Service Changes (SACL configured).
• Event - 5136: A directory service object was modified (SACL configured).
• In environments where PKINIT authentication is not standard, the "Kerberos authentication ticket (TGT) was requested" event (4768) may be suspicious when the Certificate Information attributes are not blank.

Playing with (and forging) tickets:

If an adversary compromises a service´s long-term secret key, he can forge tickets or modify them to be legitimate ones. As already discussed, tickets are encrypted with the service's secret key to whom they are targeted.

Note: Microsoft released the security patch KB5008380—Authentication updates in November 2021 to address CVE-2021-42287, aka Kerberos Key Distribution Center (KDC) confusion. This security bypass vulnerability affects the Kerberos PAC and, together with CVE-2021–42278 (sAMAccountName spoofing), allows potential attackers to impersonate domain controllers. This attack is known as noPAC. After that, if the supplied user name does not exist in Active Directory, the KDC will return the error: KDC_ERR_TGT_REVOKED.

The following is an example of forging a Silver Ticket with a user that does not exist (fakeUser) within the domain in an environment with an up-to-date KDC:

Silver tickets:

As discussed in previous posts, services are offered within the Active Directory through machine or service accounts. Acquiring the secret key associated with an account providing a specific service makes it possible to forge Silver Tickets (forged service tickets), impersonating any user for that designated service.

Knowing the secret key (NT hash or RC4/AES keys) of a principal offering a service, it is possible to create a data block just like those found in a legitimate service ticket of a KRB_TGS_REP message, specifying the realm, the intended SPN, the user requesting the service, and its PAC. Once the structure is created, the enc-part block will be encrypted with the compromised secret key.

But... as discussed in the first post of the series, the PAC is double signed, first with the service account secret and a second signature with the krbtgt account secret. So how is it possible to forge the second signature on a service ticket without knowing the krbtgt account secret?, the answer is that it is unnecessary to, since the service (AP server)  receives this ticket, it usually verifies only the first signature. This is because service accounts with SeTcbPrivilege, which can act as part of the operating system (e.g. the local SYSTEM account), do not verify the Domain Controller signature. Consequently, this technique presents a more significant challenge for detection than methods such as Golden Ticket, as there is no communication between the service and the KDC for PAC validation. In addition, any registration is limited to the target computer.

The following diagram outlines the process of creating a silver ticket:

The Impacket ticketer script allows forging TGTs/STs from scratch or based on a template (legally requested by KDC). The script will also enable data customization within the PAC_LOGON_INFO, such as groups, extrasids, etc. Ticketer tickets have a lifetime of 10 years from ticket creation.

This process involves leveraging the hash of the service account and specify the ServicePrincipalName (SPN) of the service account. Initially, obtaining the SID of the domain is essential, which can be accomplished, among other methods, using the 'lookupsid' script:

impacket-lookupsid DOMAIN/USER:PASSW@HOST | grep "Domain SID

With the SID of the domain and the hash of the service account, ticketer does the job:

impacket-ticketer -aesKey AESKey -domain-sid DOMAINSID -domain DOMAIN -spn TARGET_SPN -dc-ip DCIP RANDOMNAME

Importing the new ticket allows it to be utilized for the CIFS service:

Analyzing Silver Ticket forging flow in Wireshark reveals that no preceding AS-REQ / AS-REP messages and no TGS-REQ / TGS-REP messages occur; only AP-REQ and (optionally) AP-REP messages are generated, indicating no communication with the Domain Controller.

Furthermore, it can be observed how privileged groups have been added to the PAC:

Likewise, Mimikatz can forge silver tickets through the 'kerberos::golden' function:

mimikatz "kerberos::golden /admin: /domain: /sid: /target: /aes256: /service: /ptt" exit

Typically, machine account passwords rotate every 30 days. So, obtaining the updated secret keys is imperative to create new silver tickets.

Useful Defenses:

• Enable privileged attribute certificate validation of Kerberos. This can assist with the prevention and detection of silver tickets.
• Use a strong password policy for service accounts.
• Enforce user least privilege.
• Audit service accounts.

Golden tickets:

If the secret key of the krbtgt account is compromised (e.g., through complete domain compromise and gaining DCSync rights), ticket-grating tickets (TGTs) signed by the krbtgt account can be forged.

With these TGTs forged with the krbrtgt secret key, an adversary can obtain service tickets and thus obtain permissions for any service, on any machine and as any domain user. Graphically, the flow of this attack would look like the following diagram:

To forge this Golden Ticket, an adversary will need the secret key of the krbtgt account (in this example, the NT hash) and the SID (Security IDentifier) of the domain:

With the krbtgt hash and the domain SID, ticketer script can be used to forge the Golden Ticket. As we mentioned before, in environments with domain controllers updated at least to November 2021, we will need the -user-id of a user that exists within the domain:

ticketer.py -user-id userID -aesKey krbtgtAESKey -domain-sid domainSid -domain domain -dc-ip DCIp domainUser 

The following image illustrates how, when authenticating with Kerberos via psexec, the forged TGT is sent through a TGS-REQ with the privileged groups added to the PAC:

In the same way, from Windows, Rubeus allows this kind of tickets forging through its "golden" function:

.\Rubeus.exe golden /aes256:KRBTGTAESKey /user:domainUser

Useful Defenses:

• Change the KRBTGT account password every 180 days.
• Events 4768 & 4769.
• A possible tactic for detecting the use of golden tickets is to look for TGS-REQs without corresponding AS-REQs.
• Restricting administrative privileges across security boundaries.
• Well-known IOAs associated with Golden Tickets: the default End and Renew time is 10 years minus two days.

Diamond tickets:

Unlike a Golden Ticket, where a new TGT is forged with the hash of the krbtgt account, the Diamond Ticket technique modifies a legitimate TGT issued by a KDC. To do this, the TGT is decrypted using the secret key of the krbtgt account, then modified with the desired fields and re-signed with the key.

The following is a diagram showing the attack flow:

Rubeus performs this attack through its “diamond” function:

.\Rubeus.exe diamond /tgtdeleg /ticketuser:domainUser 
/ticketuserid:domainUserID /groups:groupsToAddToPAC /krbkey:KRBRTGTAESKey /ptt

Sapphire tickets:

Created by Charlie "Shutdown", Sapphire tickets are the evolution of Diamond Tickets, stealthier. These are legitimate tickets, but while the Diamond ticket modifies the PAC, the Sapphire ticket replaces it with the PAC of another privileged user.

The way to obtain the legitimate PAC of a privileged user is thanks to S4U2self+u2u.

Although we will see this Kerberos extension in detail in the next post focusing on delegations, here is a brief summary of how these Kerberos extensions work:

S4U2Self Extension: Subprotocol extension to the Kerberos protocol that allows a service to obtain a Kerberos service ticket for a user that has not authenticated to the Key Distribution Center (KDC). S4U includes S4U2proxy and S4U2self. Basically, allows a service to receive the user’s authorization data (e.g the PAC).

For this extension, it is required through the KRB_TGS_REQ:

• Must have at least one Service Principal Name (SPN) to allow the DC to encrypt the generated service ticket with the service secret key.
• Data structure PA_FOR_USER, which contains the information about the user on whose behalf the service requests the service ticket.
• The PAC returned in the service ticket in the following KRB_TGS_REQ contains the authorization data.

U2U Authentication: allows the client to request that the ticket issued by the KDC be encrypted using a session key from a TGT issued to the party that will verify the authentication, basically provides a method to perform authentication when the verifier does not have access to long-term
service key. In order to perform this U2U authentication, the KRB_TGS_REQ needs to contain:

• additional-tickets: field containing the TGT from the secret-key is taken.
• ENC-TKT-IN-SKEY = TRUE : supports user-to-user authentication by allowing the KDC to issue a service ticket encrypted using thesession key from another TGT issued to another user.
• ServiceName (sname) that can refer to an user, not necessarily a service with SPN.

In brief, the following would be the forging flow of a Sapphire Ticket:

The following steps are taken during the Sapphire ticket forging process:

1. Obtain the secret keys of KRBTGT and Elliot.A.
2. Performing the pre-authentication process with a non-privileged user through KRB_AS_REQ message (e.g for Elliot.A).
3. The KDC issued a legit TGT.

4. Generate a KRB_TGS_REQ with:
   • PA_FOR_USER: struc with the impersonated user (e.g Administrator)
   • Service name (same): Elliot.A, same user from the 1º step.
   • Elliot.A's TGT will be added to the additional-tickets field
   • ENC-TKT-IN-SKEY flag set to TRUE (indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided).

Analyzing the network traffic, it is possible to identify the mentioned requirements in the KRB_TGS_REQ request:

The PA-FOR-USER padata value is used for the user that wants to impersonate (Administrator). As a snamestring, U2U is employed to obtain a service ticket for an unprivileged user (Elliot.A):

5. Obtain the service ticket for the Administrator using Elliot.A as sname, through TGS-REP response:

6. Forge the sapphire ticket, replacing Elliot.A's original PAC using the ST PAC of Administrator + match the cname with "Administrator".

From Windows hosts, at the date of writing this post, it has not been possible to replicate this attack, but ticketer could run it again on Linux:

ticketer.py -nthash krbtgtNTHash -request -impersonate 'Administrator' -domain 'domain' -user 'domainUser' -password 'Password123' -aesKey 'krbtgtAESKEY' -domain-sid 'domainSID' -dc-ip dcIP 'justignored'

Once imported in the KRB5CCNAME environment variable, we will be able to access using any tool that accepts kerberos authentication:

Wrapping things up …

In this third part of the Kerberos series, we’ve dug a little deeper into the Kerberos user impersonation techniques. The goal with this post, whether we are adversaries or defenders, is to understand the multiple ways that Kerberos offers us to access resources using the credential material gathered.

We hope this installment of the Kerberos series has helped you better understand the number of techniques adversaries can use to attack the Kerberos authentication protocol.

In the next post of the series, we will continue to delve deeper, next time looking at ‘Kerberos Delegations’ and talking about how this setting allows applications to request end-user access credentials to access resources on behalf of the originating user and how an adversary would benefit from this flow.

Resources:

• Alva Duckwall & Benjamin Delpy - Abusing Microsoft Kerberos: Sorry You Guys Don't Get It.
• Netwrix - Exploiting Service Accounts.
• Adsecurity - Mimikatz and Active Directory Kerberos Attacks.
• Unit42 -  The New Generation of Kerberos Attacks.
• Fortra - Impacket - We love playing tickets.
• Overpass-the-Hash Attack: Principles and Detection.
• Elda Shamir - Shadow Credentials.
• Atl4s - Understanding - or at least, trying to.
• Peter Gabaldon - Diamond and Sapphire Tickets.
• Tarlogic - Kerberos.
• Packt - NoPac Vulnerability.
• Cyberstoph - Detecting shadow credentials.
• GhostPack - Rubeus.
• Splunk - Detecting Active Directory Kerberos Attacks.

Ransomware attacks have emerged as one of the most significant cybersecurity threats to organisations worldwide, particularly financial institutions, creating substantial challenges for data security and business continuity.

These attacks have become a major cybersecurity threat globally. They exploit vulnerabilities in hospital, medical, aviation, Telecoms, financial, and professional services systems and networks.

Lets pick out some key points, according to a 2023 report from Sophos "The State of Ransomware":

• 76% of those who experienced a ransomware event said that, during the most significant attack, the cybercriminals involved successfully encrypted their data.
• 46% paid the ransom to regain access to their data. However, even after payment, only an average of 63% of the encrypted data was successfully restored.
• 30% of ransomware attacks where data was encrypted reported that data was also stolen.
• Emails were the root cause of 30% (approx.) of attacks; 18% started with a malicious email and 13% with phishing.
• The mean recovery cost from a ransomware attack:
  • $1.82 million - excluding ransomware payment.
  • $2.6 million if paid and got data back
  • $1.6 million - costs drop if successfully restoring from backups can be achieved as the primary means of recovery.

As you can see, in today's digital landscape, ransomware attacks continue to pose a significant threat to businesses of all sizes. These malicious attacks encrypt critical data, rendering it inaccessible until a ransom is paid.

To safeguard your organization against such threats and ensure quick recovery in the case of an attack, it's crucial to implement robust prevention and recovery measures.

Lets Breakdown a 'Ransomware' Attack

(... at a high-level)

So before we talk about protecting your business from ransomware and recovery best practices, let's first break down a ransomware attack. We'll use a well-known ransomware and explore how the attack unfolded.

Ransomware: WannaCry

WannaCry was the first ransomware to exploit the EternalBlue flaw in Windows systems. You can find further info about WannaCry from the US CISA & UK NCSC.

Note: Yes, WannaCry is a good few years old now, given that it happened in 2017; however, it is still one of the most prominent attacks on organizations around the globe and caught many organizations who thought they were prepared but weren't.

The U.K.'s National Health Service (NHS) was one of the most prominent WannaCry victims. Multiple hospitals, general practitioners, and pharmacies were affected in England and Scotland. NHS facilities were forced to delay and divert medical services.

Financial Losses: £92 million (approximately $100 million) according to the National Health Executive:

• £20m was lost during the attack mainly due to lost output.
• Followed by a further £72m from the IT support to restore data and systems.
• Impact: Approx. 19,000 appointments were cancelled across the one week of the attack.

This was coupled with 24-hour news coverage about the attack on the NHS, leading to patient panic, loss of faith in the service, and damage to the NHS brand itself.

Attack Breakdown

The Key Points:

• WannaCry exploits a vulnerability in Microsoft's SMBv1 network resource-sharing protocol.
• The exploit let the threat actors (TA) transmit crafted packets to any system that accepted data from the public internet on port 445.
  • SMBv1 is a deprecated network protocol.
  • SMB Should not be exposed to the internet.
• WannaCry appears on computers as a dropper.
  • This is a small helper program that delivers and installs malware.
    • Components in the dropper include:
      • An application for data encryption and decryption.
      • Files of encryption keys.
      • A copy of Tor for command-and-control communications.
• WannaCry used, at the time, a 0day exploit known as 'EternalBlue' to spread.
  • TA first step: search the target network for devices accepting traffic on TCP port 445, indicating the system is configured to run SMB.
  • TA then initiate an SMBv1 connection to the device.
    • Once a connection is made, a buffer overflow is used to take control of the targeted system and install the ransomware component of the attack.
• Once a system is affected, the WannaCry worm propagates itself and infects other unpatched devices.
  • All without any human interaction.
• WannaCry encrypts files on the hard drives of Windows devices so users can't access them.
• Ransom payment demanded.
  • A significant flaw was noted with the release of decryption keys:
    • The TA didn't have any way to prove who paid the ransom, resulting in a completely manual process of attribution from the TA to attribute the decryption keys to the correct person/org who had paid.

Attack Diagram:

Attack Breakdown Summary

WannaCry ransomware leverages vulnerabilities in Microsoft's SMBv1 network protocol to propagate across networks and encrypt files on Windows devices, demanding ransom payments for decryption.

The attack spreads via crafted packets sent to systems exposed to the Internet on port 445, exploiting a buffer overflow to install the ransomware component. Once infected, WannaCry autonomously propagates across unpatched devices, encrypting files without user interaction.

When we look at this, the UK's NHS, for instance, would have benefited from the following points, which would have ultimately aided in the prevention and/or more efficient recovery from such an attack:

Network Segmentation:

• Segment networks to prevent SMB traffic exposure to the internet, limiting access to internal systems only.
• Use firewalls and network security measures to restrict traffic on port 445 and other vulnerable ports.

Vulnerability & Patch Management:

• Regularly update and patch systems to address known vulnerabilities.
• Implement a robust vulnerability & patch management program to ensure timely updates across all devices.

Disable SMBv1:

• Disable SMBv1 protocol on all devices, as it is deprecated and prone to exploitation.
• SMBv2 or SMBv3 protocols are used, which offer improved security features.

Endpoint Security:

• Deploy endpoint protection solutions with ransomware detection and prevention capabilities to detect and mitigate ransomware attacks at the endpoint level.
• Enable behaviour-based detection to identify and block suspicious activities indicative of ransomware behaviour.

Backup and Recovery:

• Maintain regular backups of critical data stored offline or in secure, isolated environments.
• Test backup restoration procedures regularly to ensure data can be recovered without paying the ransom in the event of a ransomware attack.

The Impact of Ransomware Attacks

The impact of ransomware attacks on any organisation, though in particular financial and healthcare institutions, can be and is far-reaching, resulting in severe consequences (as discussed briefly in the section above, where the impact on the UK's NHS was highlighted).

Financial Losses
Ransomware attacks can result in substantial financial losses for any affected organisation, particularly financial institutions. Paying the ransom demanded by attackers is often costly and provides no guarantee of recovering the encrypted data. The costs of investigating the attack, restoring systems, and implementing enhanced security measures can also be significant.

Regulatory Penalties
Financial institutions in particular are subject to strict data protection and security regulations. In a ransomware attack leading to a data breach, regulators may impose severe penalties and fines for non-compliance. Moreover, reputational damage caused by non-compliance can further erode customer trust and investor confidence.

Loss of Customer Trust / Reputation Damage
Customers entrust organizations like professional services and financial institutions with sensitive financial data and personal information. A successful ransomware attack compromising this data can lose customer trust and loyalty and damage the brand irreparably. Customers may lose confidence in the compromised organizations' ability to protect their data, leading to potential client/customer attrition.

Operational Disruption
Ransomware attacks can cause significant operational disruption for any organization, though in particular, financial institutions. Encrypting critical systems and data can render them inaccessible, resulting in delays and disruptions in financial transactions, customer services, and other essential operations. This can lead to a loss of productivity, decreased customer satisfaction, and potential financial losses.

Legal Costs
Ransomware attacks can also lead to legal consequences and associated costs for the effective organization. When client/customer data is compromised, affected individuals may take legal recourse for negligence in protecting their information. Legal fees, settlements, and potential damages can add to the financial impact of the attack.

Loss of Intellectual Property
In addition to customer data, ransomware attacks can also result in the theft or loss of valuable intellectual property. Many business and financial institutions may have proprietary software, algorithms, trading strategies, or other sensitive information that, if compromised, can lead to significant competitive disadvantages and financial losses.

Disruption in Supply Chain
Ransomware attacks targeting key organisations and financial institutions can also have ripple effects on their supply chain partners. Suppose threat actors gain access to these systems and use them as a launchpad for further attacks. In that case, it can impact other organizations connected to the compromised company, leading to a wider business and financial ecosystem disruption.

Increased Insurance Premiums
Following a ransomware attack, organizations and financial institutions may experience an increase in their cyber insurance premiums (if applicable). Insurance companies may reassess the organization's risk profile and adjust premiums accordingly, adding to the financial burden and outlay.

Ten Best Practices to Aid Your Recovery Strategy

With all of the above in mind, here are ten best practices to consider which will aid your disaster recovery strategy and offset your threat model for ransomware:

1. Backup Data: Regularly backup all important data and ensure that backups are stored securely offsite or in the cloud. This ensures that even if your primary data is compromised, you can restore it from a secure backup. Ideally multiple instances of sensitive data should exist, providing redundancy, should your data and primary back up data be successfully targeted.

2. User Training: Educate employees about the risks of ransomware and social engineering attack vectors and provide training on how to identify phishing attempts and suspicious links or attachments.

3. Email Filtering: Implement robust email filtering solutions to block malicious emails and prevent phishing attempts from reaching employees' inboxes.

4. Vulnerability & Patching Management: Keep all software, operating systems, and applications up to date with the latest security patches to address known vulnerabilities.

5. Network Security: Utilize firewalls, intrusion detection systems, and other network security measures to protect against unauthorized access and malware infiltration.

6. Incident Response Plan: Develop a comprehensive incident response plan outlining steps to take in the event of a ransomware attack, including who to contact and how to contain the damage.

7. Multi-Factor Authentication: Implement multi-factor authentication (MFA) wherever possible to add an extra layer of security to user accounts and systems.

8. Regular Testing: Conduct regular testing and simulations of ransomware scenarios to evaluate the effectiveness of your prevention and recovery measures.

9. Isolation: Segment your network and restrict access to critical systems to minimize the impact of a ransomware infection and prevent it from spreading across the entire network.

10. Data Recovery: Establish procedures and tools for quickly recovering encrypted data from backups in the event of a ransomware attack, minimizing downtime and business disruption.

By implementing these best practices, businesses can significantly reduce their risk of being victims of ransomware attacks and mitigate the impact if one does occur.

In Summary ...

Remember, prevention is key, but having a robust recovery plan is equally essential to ensure business continuity in the face of cyber threats. Stay vigilant, stay prepared, and keep your business safe from ransomware.

In general, organizations should aim to focus on the following key areas:

• Robust vulnerability management (VM) program. Vulnerability management is a continuous, proactive, and often automated process that keeps your computer systems, networks, and enterprise applications safe from cyberattacks, such as ransomware and data breaches. The goal of VM is to reduce the organization's overall risk exposure by mitigating as many vulnerabilities as possible.
  • Maintaining good security hygiene, including timely patching and regularly reviewing security tool configurations
• Security tooling, people and processes that defend against the most common attack vectors, including endpoint detection, protection and response.
• 24/7 threat detection, investigation, and response, e.g., a security operation centre (SOC) whether delivered in-house or in partnership with a specialist Managed Detection and Response (MDR) service provider.
• Disaster response (DR) preparation and optimization, including making regular backups, practising recovering data from backups, and maintaining an up-to-date incident response plan

How can we help?

Here at Lares, we help empower organizations to maximize their security Potential.

Lares is a security consulting firm that helps companies secure electronic, physical, intellectual, and financial assets through a unique blend of assessment, testing, and coaching.

If you would like any further information, you can get in touch here or head over to the Lares.com website for more information about how we can help you and the things that matter to you.

Following on from the series created by Chris Pritchard, Social Engineering 101, which features blogs by both Chris and I, this is the latest post in the series, which covers ‘Phishing’, a highly prevalent yet, more importantly, highly successful social engineering attack vector.

What exactly is ‘Phishing’?

At its most basic level, ' phishing' involves sending fraudulent emails claiming to be from a reputable or well-known/trusted/familiar company or individual. The goal is to deceive recipients into clicking on a malicious link or downloading an infected attachment, usually to steal financial or confidential information.

Common tactics employed in Phishing attacks include masquerading as reputable entities, such as:

• Banks
• Government agencies
• Well-known service providers, e.g., Facebook, Microsoft, Netflix, etc.
• Family and friends

Regardless of the entity being masqueraded in the email, these messages often contain links and files, e.g., images, documents, and compressed/archived files, that, when interacted with, can lead to the compromise of the recipient device, personal information and/or the installation of malware.

As such, we must remain vigilant and educate ourselves, our colleagues, family and friends on recognizing and avoiding such deceptive messages to safeguard our sensitive information, or in the case of business, its proprietary and customer information.

Given the prevalence of laptops, tablets, mobile devices, and desktop computers in our daily lives, Phishing has always been and will most likely always be a popular tactic among cybercriminals.

So, how does ‘Phishing’ work at a high level?

Well, this is a form/variant of a ‘phishing’ attack, in which an attacker uses a compelling narrative within the email title and message body to lure, build rapport and ultimately trick the targeted recipient(s) into doing any or all of the following:

• Clicking a link which will have malicious intent or consequences
• Sending the social engineer/threat actor private information
• Sending the social engineer/threat actor corporate login information
• Sending the social engineer/threat actor financial information
• Purchasing gift certificates/store cards e.g. Amazon, Apple…
• Transferring money to unknown accounts
• Downloading malicious programs/software to the device(s) on which the email is being opened/read on

It is worth noting that the social engineer/threat actor, or the ‘Phisher’ as we’ll now refer to them, may use your actual name and location to address you directly. Using these details makes the pretext of any message more compelling for the recipient.

Lets Breakdown a Simple 'Phishing' Attack

So before we break the attack down, it is worth pointing out that there are several common phishing email pretexts/lures that, at one point or another, we've all received at least one of:

1. The fake invoice scam: Deceptive emails posing as legitimate invoices from known companies, aiming to trick recipients into making payments to fraudulent accounts.
2. Email account upgrade scam: False notifications claiming to be from email service providers urging users to upgrade their accounts by clicking on malicious links to steal login credentials.
3. Advance-fee scam: Fraudulent emails promising large sums of money in exchange for a small advance payment, exploiting greed and desperation.
4. Google Docs scam: Phishing emails disguised as Google Docs invitations, prompting recipients to grant access to their Google accounts and allowing attackers to steal personal information.
5. PayPal Scam: Fraudulent emails impersonating PayPal, requesting account verification or claiming unauthorized transactions, aiming to obtain login credentials and financial details.
6. Message from HR scam (Corporate/Business user email): Falsified emails purportedly from Human Resources departments often contain urgent requests for sensitive employee information or login credentials.
7. Dropbox scam: Fake emails masquerading as notifications from Dropbox, tricking users into clicking on malicious links or attachments that install malware or steal credentials.
8. The local government/council tax scam: Fraudulent emails impersonating local government authorities or tax agencies, demanding immediate payment of fictitious taxes or fines, preying on fear of legal consequences.
9. Unusual activity scam: Suspicious emails claiming to be from online accounts or services, warning users of unusual activity and urging them to click on links to verify their identities, aiming to steal login credentials or personal information.

The following breakdown is taken from an actual ‘Phishing’ attack. Similar to our Smishing attack premise, the phishing email we're going to review targeted an individual user, using yet again the pre-text or ‘lure’ of urgency and a reputable provider.

The Phishing email:

Let's break down the email visually:

1. Sense of urgency and fear, e.g., fear tactics. Folks are attached to their photos!
2. Brand imitation, sender email is attempting to imitate Apple iCloud; however, the sender email address is nooreply@icloud.robert-howe.com. Lets dig into this a little more:
   1. nooreply - nothing unusual here, a lot of orgs/companies use bulk sender addresses that start with noreply or varients of this.
   2. @icloud.robert-howe.com
      1. icloud. - attempt to reinforce believability; however this is actually a subdomain, as some of the more eagle eyed out there may have spotted!
      2. robert-howe.com - this is the actual top level domain and indicates beyond doubt that this email has not come from a legitimate Apple iCloud source address.
3. It was flagged as Spam, but not as an attempted phishing email; however, this should still raise your concerns that this is indeed a phishing attempt.
4. Brand imitation, use of Apple iCloud icon for increased believability, along with a failure message; however, if you look at the grammatical syntax of the failure message, it also reads off, although grammatically it is correct!
   1. From a well know and high profile brand such as Apple, I would have expected something like this, for example:
      1. "Failed to process payment when renewing your iCloud storage subscription."
5. Storage capacity, this looks off based on the details e.g., 48.9 out of 50GB.
   1. Would Apple really make a simple user interface / user experience error like this??
6. The font used is 'Comic Sans', which is very rarely, if ever, used in business communications from high profile brands.
   1. Have you ever seen any legitimate business communications using Comic Sans font type to convey information?
7. 'Full' indicator button. Again, the use of fear and urgency tactics, with the colour red. The colour red is regularly associated with stop, danger, fear, anger, which consequently induces some form of quick response/action.
8. Expiration date, again continuing to build on the sense of urgency and fear tactics. Basically attempting to convey that if you don't take action by this date you could lose everything!

One thing to note was that the entire email body was 'clickable', as when the mouse hovered over any part of the email body, the remote server URL was displayed at the bottom of the screen, as identified by point 9 and the red box outline:

9. Redirect the URL to the remote malicious server via Google???.

Now, it is a little tricky to read; however, point 9 and the red box depict a remote/redirect address linked to https://storage.googleapis.com, weird right? Why would Apple be using Google? Well, they aren't. This is the first of 2 redirect URLs which eventually land on a fake iCloud login portal:

10. Bogus URL; although it looks to have a valid SSL/TLS Cert due to the green padlock, the URL being used is not correct. The legitimate iCloud URL is: https://www.icloud.com/
11. Brand imitation, continuing with the façade of imitating Apple iCloud. Though this is not what the actual portal looks like at all!
12. Credential harvester, to capture users login details, which will then redirect you to a page of the threat actors choosing or the legitimate page

Many of you may have flagged this as a phishing email or are wondering how folks would fall for this; however, folks still do and are! Especially folks who may not be as 'tech-savvy'. When you think about it, the lure itself is very emotive; I mean, who would want to lose access to all their photos? This feeling of fear and impending loss is enough to make some folks do something they know they shouldn't, e.g., click the link and submit their iCloud login details, which could ultimately result in the compromise of their account if the targeted user doesn't have MFA enabled.

Let's end the breakdown with a little bit of fun! Would you be able to identify and spot any of the following emails as phishing emails:

Note: this above Amazon email, in this instance, was/is indeed a phishing email, with the malicious links subtlety disguised as the 'Order #' and the 'tax and seller information.

So, how can we Protect Ourselves from Phishing Attacks?

We all know and have heard about email phishing, its dangers, what to look for, and that if it ultimately feels ‘off’, we call it out; however, many folks out there still don't, for one reason or another!

So, we must continue to promote phishing awareness and protect ourselves from 'Phishing' attacks. Depending on the targeted user’s ability to identify a phishing attack and ignore or report the message, here are some simple steps as individuals, to be mindful of:

• Check the Sender's email; Look to ascertain or verify that the email is coming from the actual domain/business the email is implying.
• Check the message, grammar, spelling and structure
• Don’t click on any links which you are unsure of the origin or validity
  • Use your mouse to hover over, but not clicking on the email body and/or links within the email. This usually, but not in all instances, provides an insight in the remote URL.
  • In phishing emails, these more often than not, point to an HTTP unencrypted website and/or login portal. As such, looking up site information can be difficult or obfuscated by layers of proxies and redirects.
  • more sophisticated threat actors may use HTTPS and have valid SSL certificates; so keep this in mind, a general rule of thumb is, if in doubt, chuck it out!
• Don’t send anyone private information via email
• Don’t send anyone financial information via email
• Don’t make and bank or financial transfers. Always check with the actual organisation or vendor first using their legitimate service, app or contact details.
• Don't make any purchases for gift certificates/store cards e.g. Amazon, Apple…
• Don’t download malicious programs/software to a smartphone or other hardware devices if asked to do so via email.

A note for Corporate Users: If you work within a corporate environment, your current organization may have security awareness programs, which covers topics such as Phishing and Social engineering. As such this would be a great place for corporate/business users to seek help and understanding.

In addition to the above point, there are several technological solutions which can also prevent or act as defence in depth:

• Email Filtering: Many email services and providers now provide ‘Email filtering’ options to identify and block or flag suspicious emails. This can be based on the email content, links, files, originator email address, domain or all of the above.
• Multifactor Authentication (MFA): Utilizing MFA is an additional protective layer, will serve as an extra layer of defence and can prevent a threat actor from using credentials obtained through a ‘Phishing’ attack.

Closing Points

Anyone with a device, such as a computer, laptop, smartphone, or tablet, can receive email messages from anywhere in the world via any inbuilt email platforms or specific vendor apps, e.g., Outlook, Gmail, and various other supported applications.

Many users already know the dangers of clicking a link in email messages; however, users/people still fall foul of this attack vector.

How to Spot a Phishing Email

In the past, identifying phishing emails was relatively simple. They often arrived with obvious red flags, such as requests from an "insert_your_prince_here" seeking financial assistance in exchange for promised wealth.

Nowadays, criminals have evolved their tactics, investing considerable effort into crafting convincing emails that appear legitimate. These sophisticated attackers often mimic communication from friends or trusted institutions like banks. These sophisticated attackers may even research their targets, incorporating personal details into their messages to increase the likelihood of successful deception and prompt recipients to click on malicious links or attachments.

The following steps can be taken to help spot a phishing email:

• Sender Email Address Inspection:

  • Examine the sender's email address closely; however, ensuring that you do not inadvertently click on any other links within the email whilst doing so. Inspecting the the sender address can reveal whether the sender is legitimate.
  • Cybercriminals often use public email services like gmail.com, outlook.com and others. Legitimate emails from banks or companies typically come from company email accounts bearing the company's name.
    • Note that the displayed email address may differ from the actual sender's address; to verify, hover over/click on the sender's email name at the top of the email.

• Request for Secret Information Verification:

  • Exercise caution where an email requests details or verification of details, such as personal information, bank details or passwords.
  • Legitimate organizations will never solicit such information via email; any email doing so is likely a phishing attempt.

• Suspicious Attachments:

  • Avoid opening unexpected emails or attachments from unknown or unsolicited senders, as they may contain malware capable of compromising your computer and stealing personal data.
  • As a side note, always ensure your devices anti-virus and threat detection software/services are up-to-date and enabled. As they should provide another layer of security and apply a defense in-depth principle toward you and your device.

• Creation of Urgency:

  • Phishing emails often induce urgency by claiming suspicious activity on your account or impersonating someone in need of urgent financial assistance. Beware of such tactics and verify the authenticity of the sender through established contact details or official websites.

• Unrecognized Website Links:

  • Be cautious of clicking links within emails, as phishing emails may redirect you to fraudulent websites and login portals.
  • Hover over the link to reveal the true URL, which may be misspelled or entirely different from what you expect.
  • Always verify before clicking.

• Poor Spelling and Grammar:

  • Phishing emails often exhibit poor writing quality, including spelling mistakes and grammatical errors.
  • Take note of any deviations from the sender's usual writing style, as these can be indicators of a fraudulent/phishing email.

General Awareness

The following general steps can be taken to help prevent being exploited:

• Ignore: If it looks too good to be true and/or the message is unsolicited, ignore, report and delete.  For example, email messages offer quick money from winning prizes or collecting cash after entering information.
• Remember: Financial institutions will never email asking for credentials or a money transfer. Never send credit card numbers, ATM PINs, or banking information to someone via email messages.
• Avoid: avoid responding to emails that you don’t recognize or, at the very least, if received on a work device, contact your IT security team and forward the email to them to asses. Also, see the point below.
• Awareness: Make an effort to stay current with current phishing tactics and threats. Awareness can be your first line of defence. As an individual, this may seem like a daunting task; however, your current organization may have a security awareness program that covers topics such as this, and as such, this would be a great place to seek help and understanding. Alternatively, seeking knowledge online from reputable providers can also be another great option.

As users in an interconnected digital age, we are inherently trusting of email, despite the news about cyber attacks originating from a phishing email, as this is usually the primary means of communication between businesses, colleagues and in some cases where family and friends are geographically displaced, so ‘Phishing’ is often lucrative to attackers seeking to build rapport and obtain credentials, banking information and private data.

How can we help?

Here at Lares, we help empower organizations to maximize their security Potential.

Lares is a security consulting firm that helps companies secure electronic, physical, intellectual, and financial assets through a unique blend of assessment, testing, and coaching.

If you would like any further information, you can get in touch here or visit the Lares.com website for more information about how we can help you and what matters to you.

At Lares, we find many weird and wonderful engagement attack paths when testing our clients. This series of posts will dive into a handful of our favourites, demonstrating the mind-bending attacks we've carried out in the past. We will take you along for the ride, walking through what got us to the various stages and achieved actions on objectives.

All screenshots and scenarios have been recreated or described in detail in our internal labs; therefore, no client details or information will be mentioned in these posts.

Not every part in this series will be from a pentest; some will be from Red Teams, Insider Threat engagements, and many others. We aim to show some of our fun attack paths and how you might undertake them within your environment. We will also evaluate mitigations, detections, and key takeaways from each.

Starting with Recon

Many engagements we end up doing start from the perimeter as an external penetration test, and through various means, we will often be able to achieve internal access. This scenario, in particular, started like any other external, starting with enumeration and hunting; we tend to use a large amount of external open-source intelligence (OSINT) gathering. We do this to identify critical services and open ports before actively touching services; we achieve this by using services such as the following(note the list is an example but not exhaustive of all the sources):

• Shodan - Searching for open ports, additional domains, services, and other helpful information that mentions the company name in adjacent IP ranges.
• Zoomeye—Similar to Shodan, Zoomeye often provides the information listed above and historical information to identify what services might have been running on obscure ports in the past.
• Hunter.io - Sometimes, it can be a bit hit-and-miss with content. Still, Hunter often gives a good overview of the company email format for formulating password sprays, phishing, and other potential username formatting.
• SpyCloud - Spycloud gives an added edge of breach data and botnet data, which we use in external password spraying and credential stuffing on various services; it also often provides us with an idea of the internal domain name of the customer, which we can then search on all of the other services listed.  
• Social Media—LinkedIn for Staff members, Twitter for developers, critical information, and various Telegram channels are also used to identify potential areas of data breaches or historical supply chain issues/new vulnerabilities. For more information on how we do social profiling, we've written about this here.
• Github, Gitlab, and Bitbucket for code repositories and other critical information often reveal internal or historical information about the internal domain.
• Cloud Resources—Azure AD Internals, Greyhat Warfare, GCP/AWS/AZ discovery: Most cloud resources can be identified using open-source intelligence gathering, with a wealth of tools available to our consultants.

Breaching The Perimeter

Once we have an idea of the perimeter, the footprint, and what services look attractive, we can start planning a route into the environment. What does this look like? What tools, such as credentials, scripts, social engineering, or other techniques, can we leverage in our toolbox?

Typically, we like to start with credential stuffing and brute-force attempts. We have access to SpyCloud, which provides a wealth of information from breaches and botnets, often serving as cheat codes to emulate real adversaries.

In this scenario, we identified that RDP was running on a non-standard port and that a single-factor VPN portal was exposed. With the help of ZoomEye and Shodan, we validated that the host had the port open to negate the need to port scan and potentially alert our target.

The steps below detail the identification and connection on a non-standard port:

Once the port was identified, we were able to connect using mstsc.exe also known as remote desktop, and authenticate it with the previously found credentials. Certain users in this environment had Okta Verify set up multi-factor authentication to access other services via Okta single sign-on. Still, in many cases, this was not configured for RDP. Thus, it was possible to traverse to the remote host and connect with a single-factor set of credentials:

In addition to the RDP host, we identified a single-factor VPN endpoint granting access to a development environment. In this particular test, there was no connection between dev and prod; however, we have observed this setup in other client environments and have been able to jump between environments.

Navigating the Internal Minefield

Once initial entrenchment was achieved, the first step was to enumerate the local system to identify any potential paths for lateral movement and domain privilege escalation, as the assessment was not primarily focused on evasion of detections, and the primary objective was going after privileged access.

We found that our user,backupadmin was indeed an administrator using the Powershell module Get-LocalGroupMember -Member Administrators

With this information, it was time to explore our potential attack paths within the environment. At the back of our mind, we thought this may have been a honeypot host, so we remained cautious in our approach.

We began executing a slightly modified version of SharpEDRChecker (This tooling can be executed as a standard user and enumerates various paths, services, running tasks and DLLs on disk to identify defensive products in use) to identify and profile the defensive stack. This revealed a reasonably box-standard Windows setup with Defender and Antimalware Scan Interface (AMSI).

[!] Service Summary: 
	[-] mpssvc : defender
	[-] PolicyAgent : defender
	[-] SecurityHealthService : securityhealthservice
	[-] Sense : defender, threat
	[-] WdNisSvc : antivirus, defender, nissrv
	[-] WinDefend : antimalware, antivirus, defender, malware, msmpeng
	[-] wscsvc : antivirus


[!] Driver Summary: 
	[-] WdFilter.sys : antimalware, malware
	[-] WdNisDrv.sys : defender

If you see Defender there is a high chance A M S I is there too

With this in mind, we were also able to enumerate where some exceptions were applicable for Defender-excluded paths using the fact our user was an administrator and built-in PowerShell tooling:

Get-MpPreference | Select-Object -Property ExclusionPath -ExpandProperty ExclusionPath

This led to the discovery of C:\BackupLogs which appeared to be a Defender exception; upon browsing this folder, there were some interesting named files:

The files found appeared to be nightly backups of the SAM, SYSTEM, SECURITY and SOFTWARE registry keys, so we decided to see if we could decrypt them. Until now, we still believed this might be a honeypot, but it also felt a bit like a capture-the-flag (CTF) box!

Cracking the Secrets

With these files and the ability to operate in Defender's exceptions folder, we copied across a py2exe version of secretsdump to the system to decrypt the local Security Accounts Manager (SAM) database (which is used to house all the local users on the system's usernames and password hashes) using the following command:

secrets.exe -sam sam1 -system system1 -security1 security  LOCAL

This was done to obtain the NTLM hash value for the administrator and other users. In many cases where Local Administrator Password Solution (LAPS) is not in use, the administrator hash is likely shared across systems within the environment. Either by cracking the password, forging a Kerberos ticket, or passing the hash, it is possible to traverse the environment easily to gain vertical privilege escalation.

In this case, we opted to crack it using our hashcat rigs, the syntax for which was as follows:

hashcat.exe -m 1000 warstories.txt wordlists\result.txt -r rules\Lares.rule -O

The command line arguments for the above are as follows:

• hashcat.exe - Running hashcat on Windows.
• -m 1000 - Setting the mask to type 1000, which is NTLM hashes.
• warstories.txt - This is the file containing the NTLM hashes to be cracked
• wordlists\result.txt - This is our wordlist, a combination of previously cracked domain and local passwords.
• -r rules\Lares.rule - This is our ruleset for permuting the entries in the wordlist to ensure we hit different variations of words, append different characters, and make other modifications to the entries.
• -O - Use the optimised kernel for GPU cracking of the passwords.

This resulted in the retrieval of both the Administrator and User clear-text passwords. However, you'll notice that the Guest and DefaultAccount users have weird-looking passwords; these are essentially blank passwords as the accounts are not enabled, which is how hashcat represents them.

Administrator:077cccc23f8ab7031726a3b70c694a49:Passw0rd123
User:b2bdbe60565b677dfb133866722317fd:Passw0rd1!
backupadmin:5858d47a41e40b40f294b3100bea611f:Passw0rd1

Once the password had been cracked, the next step was to identify if the administrator password was shared across other hosts within the environment and to target additional domain reconnaissance.

We leveraged Explorer and PowerShell from the compromised machine to determine whether we could authenticate to the domain controller using the local administrator password, which was successfully cracked. This resulted in connecting successfully and mounting both the C$ and ADMIN$ shares, indicating that the credentials were shared, at least for the RID500 Administrator account.

At this stage, by having a local admin on a domain controller, we could add ourselves to the Domain Admins group or perform other administrative tasks. We created a Lares user and proceeded with this moving forward to enable the client to identify the pentest activity quickly and deconflict where necessary.

Domain Admin is Just the Beginning

Frequently, on assessments, we find that getting domain admin is only the beginning, and further compromise and coverage of the environment often take place post-compromise. Sometimes, the keys to the kingdom are not enough, and going for broader coverage of sensitive data, credential matter, and other areas of the network become our focus.

As such, the attack path continued.  We could freely traverse other systems within the environment and uncover additional sensitive information. One of our favourite tools to leverage on pentests of Windows environments is Snaffler, as it does an excellent job crawling shares, indexing available files, and searching them for sensitive data.

Using the exception folder once again, we copied Snaffler across and executed with the following flags:

Snaffler.exe -s -o Logging.txt

This tells Snaffler to run with the default ruleset and regular expressions and write it out to an output file called Logging.txt.

For this example, we have placed several files in the domain for snaffler to find; the output can be deciphered like so:

Running snaffler enabled further identification of sensitive information, which in this case was looking for data related to domain trusts and other client information. The output was several hundred megabytes, parsed and listed into a CSV for the client.

Attack Path Summary -  How We Got Here

This first part of the series walked you through an attack path from the Internet, starting from an unauthenticated perspective, successfully gaining access to valid credentials, paired with single factor authentication and remote desktop externally facing, we were able to compromise the system successfully, obtain local administrator access and escalate our access to that of domain administrator, then perform post-exploitation activities to get data governance coverage of the environment.  

Conclusion

To successfully protect yourself from an attack path like this, several key recommendations can be followed;

• Ensure you have Multi-Factor Authentication enabled and enforced for all users
• Lock down your perimeter to ensure that RDP and other remote access protocols are restricted to set IP ranges if they need to be externally facing or disabled for internal use only.
• Set a robust password policy with word denylists to prevent weaker password creation. Consider implementing the suggestions detailed in our Password Analysis post.
• Consider implementing LAPS or a similar privileged access management solution to prevent local administrator password re-use.
• Perform regular external asset discovery to ensure your perimeter is under control and you know what assets you have.

Moreover, organisations should embrace the principle of 'defence in depth'. This is a comprehensive approach to cybersecurity that layers multiple defensive mechanisms. If one mechanism fails, another steps in immediately to thwart an attack. This approach involves technological solutions and encompasses policies, procedures, and awareness training to ensure that all possible security gaps are covered.

How can we help?

Here at Lares, we help empower organizations to maximize their security Potential.

If you would like any further information, you can get in touch here or head over to the Lares.com website for more information about how we can help.

In the first part of the Kerberos series, we’ve set the groundwork for the following parts, covering an overview of Kerberos, concepts, encryption types, the authentication flow, and the PKINIT pre-authentication mechanism.

In this second post, we'll delve into techniques that can be leveraged to obtain credential access using the Kerberos authentication flow:

• Credential Access
  • User enumeration
  • Password Guessing
  • AS-REQroasting
  • AS-REProasting
  • TGS-REProasting (Kerberoast)
  • UnPAC the hash
• Resources

This post is the second part of the next Kerberos series:

• Kerberos I - Kerberos Overview.
• Kerberos II - Credential Access.
• Kerberos  III - User Impersonation.
• Kerberos IV - Delegations.

Credential Access:

Through the Kerberos authentication flow, it is possible to enumerate domain user accounts and validate credentials through the error messages returned by the KDC to the client. In addition, user hashes can be obtained through encrypted parts included in AS-REQ/AS-REP and TGS-REQ/TGS-REP messages (Roasting attacks). Also, in case a user uses PKINIT as a pre-authentication method, it is possible to extract his NT/LM hashes using the UnPAC the hash technique, which we will see in this post.

Although we won't delve into low-level detection measures, notes have been added as references as we go through each technique, which can help detect these Kerberos authentication flow abuse techniques.

User Enumeration:

Due to how Kerberos works, it is possible to enumerate valid domain accounts by sending TGT requests (AS-REQ) and analyzing the KDC errors in the response.

When Kerberos receives an AS-REQ message from the client,  the KDC responds with KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN error message if the user is not found in its database.

If the KDC responds with KRB5KDC_ERR_PREAUTH_REQUIRED error, or returns a TGT in an AS-REP response (Accounts not requiring pre-authentication), it will confirm that the user exists.

In addition, KDC will respond with KDC_ERR_CLIENT_REVOKED if the account is locked or disabled.

The following is an example of this enumeration using the own Kerberos pre-authentication flow via Kerbrute:

The traffic generated would be as follows:

Useful Windows event IDs to take note of:

• 4768 - A Kerberos authentication ticket (TGT) was requested. A Kerberos authentication ticket (TGT) was requested to identify one source endpoint trying to obtain an unusual number of Kerberos TGT tickets for non-existing users.
• This event can be monitored closely for excessive Kerberos Authentication ticket requests issued from a single source with no pre-authentication.

Password Guessing

The Kerberos authentication flow can be leveraged to validate user credentials, which, from an offensive security or threat actor stance, facilitates the ability to carry out ‘Password Guessing’ attacks.

In this process, AS-REQ messages are sent with an encrypted timestamp and the password to be validated. If the password is incorrect, the Key Distribution Center (KDC) responds with the message KDC_ERR_PREAUTH_FAILED (pre-authentication information was invalid).

The password spray feature of kerbrute can automate this process:

Below is an example of the generated traffic from a password-guessing attack, showing that the KDC has not been able to decrypt the timestamp we have sent as the user ‘Tyrell.W’ because the password is wrong, which causes the KDC to respond with the following Kerberos error message:

This kind of enumeration does not trigger event 4625 (An account failed to log on), but it will increase the number of logon attempts from the target user. It may consequently block the account due to excessive logon attempts.

This technique will trigger event 4771 - Kerberos pre-authentication failed, which is disabled by default.

Useful Event IDs & Defenses:

• 4771 - Kerberos pre-authentication failed. (Event disabled by default).
• 4768 - A Kerberos authentication ticket (TGT) was requested.
• Mitre | ATT&CK T1110.003 - Brute Force: Password Spraying

AS-REQroasting:

In the first AS-REQ message with pre-authentication, the client will ask the KDC for a TGT (Ticket Granting Ticket). The client generates a timestamp and encrypts it with its secret key (DES, RC4, AES128 or AES256) derived from the user password. This encrypted timestamp is sent to the KDC together with the username.

Through man-in-the-middle techniques, it may be possible to capture these pre-authentication messages, including the encrypted timestamps:

Once the timestamp encrypted with the user's key is obtained, it is possible to attempt to crack it locally and try to retrieve the password in plain text from the client.

To crack this type of hash, we need to use the following format: $krb5pa$18$da$$<cipher_bytes>

In hashcat the hash mode 19900(AES256), 19800(AES128) or 7500 (RC4):

hashcat -O -m 19900 wordlists.txt
hashcat -O -m 19900 -a 3 ?l?l?l?l?l?l?l?l

Useful Defense:

• Since this technique is based on monitoring network traffic, enforce a strong password policy to increase the complexity of possible hash-cracking methods.

AS-REProasting:

AS-REP messages contain a Ticket-Granting Ticket (TGT) encrypted with the secret key of the ticket-granting service (krbtgt), along with a session key that is encrypted with the secret key of the user being authenticated during the Kerberos flow.

Although we typically associate AS-REP roasting with user accounts that have the "do not require Kerberos Pre-authentication" option enabled, this technique can be employed whenever we can intercept this type of AS-REP message.

As shown in the following example, we will need the session key, which can be found in "enc-part" part:

Suppose any domain users have the "do not require Kerberos Pre-authentication" option enabled. In that case, we can attempt authentication and retrieve the session key encrypted with the user's secret key from the AS-REP message.

Below is an example of the option enabled for the user "Darlene":

This technique can be performed using impacket's GetNPUsers script. The script itself allows for the option to specify a list of users:

The same attack can also be carried out using an alternative tool from Windows, Rubeus:

Once the hash has been obtained via either method, the next stage would be to conduct hash-cracking techniques. At this stage it can be cracked locally or exfiltrated to a remote computer, using  Hashcat or  John (JTR) through a combination of dictionary, brute-force, rules...

hashcat.exe -m18200 <HASH> wordlist
hashcat.exe -m18200 <HASH> -a 3 ?l?l?l?l?l?l?l?l

The following is the plain-text password obtained from the hash retrieved through the AS-REProasting attack, using the hashcat tool:

LdapFilter for "do not require Kerberos pre-authentication":

(&(objectclass=user)(objectcategory=user)(useraccountcontrol:1.2.840.113556.1.4.803:=4194304))

Useful Event IDs & Defenses:

• 4768 - A Kerberos authentication ticket (TGT) was requested.
• 4738 - A user account was changed (to identify a change performed on a domain user object that disables Kerberos Pre-Authentication, UserAccountControl property).
• Mitre | ATT&CK T1558.004- Steal or Forge Kerberos Tickets: AS-REP Roasting

TGS-REProasting (Kerberoast):

Any domain user can request as many service tickets for any service as he wants, even if he does not have access to that service.

Since we know that service tickets (TGS) are encrypted with the secret key of the service (machine account or service account) it is intended for, we can order service tickets and then subsequently attempt to crack the secret key offline.

In Active Directory, domain services are typically run from two types of accounts:

• Machine accounts.
• Service accounts.

While trying to crack a TGS from machine accounts can be an arduous task, as these passwords will (by default) be generated automatically, it will be easier to crack the secret keys of service accounts, as humans have generated these.

Utilizing either Rubeus on Windows (Kerberoast option) or Impacket's GetUserSPNs on Linux, a request can be made to obtain tickets from accounts that have SPNs:

LDAP filter for Kerberoastable users:

(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

This will generate a lot of traffic, especially if we have a large number of accounts that contain SPN, and we request it for all kinds of SPN (servicePrincipalName=*).

The following Wireshark capture shows the traffic generated when requesting TGS from the KDC. In the "enc-part" of the ticket, we can find the data encrypted with the Kerberos key of these service accounts:

In hashcat, use hash mode 13100 (Kerberos 5 TGS-REP etype 23) to try to crack the hash:

hashcat.exe -m13100 <HASH> wordlist
hashcat.exe -m13100 <HASH> -a 3 ?l?l?l?l?l?l?l?l

It is also possible to perform this technique directly from accounts that do not require pre-authentication. Through the impacket branch getuserspns-nopreauth from @Shutdown.

Useful Event IDs & Defenses:

• 4776 - Credential Validation.
• 4769 - A Kerberos service ticket (TGS) was requested. (Multiple).
• 4768 - A Kerberos Authentication ticket (TGT) was requested.
• Use strong passwords for service accounts.
• Monitor LDAP queries with servicePrincipalName=* wildcard filter.
• Check for TGS with downgrade encryption from AES to RC4.
• Mitre | ATT&CK T1558.003 - Steal or Forge Kerberos Tickets: Kerberoasting

UnPAC the hash

As explained in the first post of the series, Kerberos supports Public Key Cryptography for Initial Authentication (PKINIT) as a pre-authentication method.

The difference with other pre-authentication methods in Kerberos is that, through PKINIT, in the AS-REP response of the KDC, the TGT is contained in the PAC, the structure PAC_CREDENTIAL_INFO. This structure includes the user's encrypted credentials (NT and LM hashes).

In the first communication exchange, during the pre-authentication flow with PKINIT, the client will send a PK_AS_REQ message with its X.509 certificate (signed by the Certification Authority) and an authenticator (timestamp encrypted with the client's private key).

After validating the certificate and the timestamp, the KDC will return a TGT with a structure called PAC_CREDENTIAL_INFO within the PAC. Since the TGT is encrypted with a secret key of the krbtgt account, it is not possible to read or extract it:

Here is where User-to-User authentication (U2U) comes into play,  as this effectively allows the client to request that the ticket issued by the KDC (service ticket) be encrypted using a session key from a TGT issued to the party that will verify the authentication.

To use this extension, the TGS-REQ request must contain an additional TGT (additional tickets field). The ENC-TKT-IN-SKEY option = True, will indicate that the session key of the additional ticket will be used to encrypt the new service ticket to be issued, instead of using the server's key for which the new ticket will be used. In addition to a service name (sname) which can be the client itself (note: the client doesn't necessarily have to have an SPN set).

Following, the client (Elliot.A) asks the KDC for a service ticket from himself while providing the ENC-TKT-IN-SKEY option and adding the TGT issued to us to the "additional tickets" field of the TGS-REQ:

The image below depicts a Wireshark capture of the ‘req body’, with the ‘enc-tkt-in-skey’ option enabled for U2U, with the client "Elliot.A", as the service request for the Ticket Granting Service (TGS):

In the same TGS-REQ request, under the 'additional-ticket' section:

In the TGS-REP response, the KDC will copy the PAC, with the encrypted NT/LM hash, into the service ticket it sends to the client. This service ticket is encrypted with the session key of the client's TGT:

In the following Wireshark capture, the TGS-REP response with the service ticket and the PAC_CREDENTIAL_INFO encrypted with the TGT session key and containing the client's NT hash:

Using the TGT session key, it's now possible to decrypt the ticket, extract the PAC, parse, and decrypt the NT hash using the AS-REP session key.

The image below demonstrates an example of how to request a TGT using Kerberos PKINIT with the certificate/private key of a user using gettgtpkinit.py:

Once the TGT is obtained, the getnthash.py script, in conjunction with the TGT and the TGT´s session key, can be used to extract the PAC and get the user's NT hash:

From Windows, the same can be accomplished with Rubeus; however, first, we need to convert the ‘.pfx’ file to a Base64 string:

The following Rubeus command can then be issued to extract the NTHash:

.\Rubeus.exe asktgt /getcredentials /user:Elliot.a /certificate:<b64Certificate> /domain:Lareslabs.local /dc:dc1.lareslabs.local /show

Defenses:

• Monitor for Kerberos authentication via PKINIT, since the NT/LM hashes is only
  returned when PKINIT is used.
• Look for TGS requests that have at least the following options set: Forwardable, Renewable, Renewable_ok, Enc_tkt_in_skey(there will be a lot of false positives).

Wrapping things up …

In this second part of the Kerberos series, we’ve dug a little deeper into the Kerberos Credentialed Access techniques, covering the following:

• User enumeration
• Password Guessing
• AS-REQroasting
• AS-REProasting
• TGS-REProasting (Kerberoast)
• UnPAC the hash

We hope this installment of the Kerberos series has helped provide a better understanding of the number of techniques threat actors can use to attack the Kerberos Authentication flow.

In the next post of the series, we will continue to delve deeper, next time looking at ‘User Impersonation’ and talking about ticket management and ticket forging.

Resources:

• Active Directory Kerberos Attacks Analytic - Splunk.
• Dirk-Jan Mollema - NTLM relaying to AD CS - On certificates, printers and a little hippo.
• Atl4s - You do (not) Understand Kerberos.
• LuemmelSec - S4fuckMe2selfAndUAndU2proxy - A low dive into Kerberos delegations.
• Microsoft - Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol.
• FalconFriday — Detecting UnPACing and shadowed credentials.
• Tarlogic - Kerberos.
• Eloy Pérez (@zer1t0) - Attacking Active Directory.
• Harmj0y - Kerberoasting Revisited.

• 

  Kerberos, again

• Brief History of Kerberos

• Kerberos 101

  • Kerberos concepts
  • Encryption types
  • Wireshark & Kerberos decryption
  • Kerberos Authentication Flow
    • Kerberos Pre Authentication
    • AS-REQ (Authentication Service Request)
    • AS-REP (Authentication Service Response)
    • TGS-REQ (Ticket-Granting Service Request)
    • TGS-REP (Ticket-Granting Service Response)
    • AP-REQ (Application Server Request)
    • AP-REP (Application Server Response)
  • Public Key Cryptography for Initial Authentication (PKINIT)

• Resources

Kerberos, again

For many years, the Kerberos protocol has been one of the best friends of offensive security professionals. Leveraging this protocol has brought us many wins during assessments and caused many headaches for ‘blue teamers’, who must always be on point and right every time!

That's why, at Lares, we've created a series explicitly relating to the Kerberos protocol and a look at the associated headaches.

• Kerberos I - Kerberos Overview (this post).

The Kerberos Blog series will include and cover:

• Kerberos II - Credential Access.
• Kerberos  III - User Impersonation.
• Kerberos IV - Delegations.

With the outline of the series covered, let’s get started …

Brief History of Kerberos

The development of the Kerberos protocol began in the Athena Project at the Massachusetts Institute of Technology (MIT). This project started in 1983 and aimed to provide cutting-edge computing resources, including networked workstations, high-speed networking, and collaborative software tools, to empower students and researchers.

Below is an example of the Athena computing environment:

As shown in the diagram above, the environment consisted of a client-server model of distributed computing using a three-tier architecture.
The environment used, among other features, a name resolution service called Hesiod, instant messaging through the Zephyr service, and Kerberos as a system-wide authentication protocol.

The Kerberos v1 was developed for this project to authenticate service requests between two or more trusted hosts across an untrusted network and provide a Single Sign-On (SSO) authentication to these services.

• Kerberos versions 1 through 3 only operated only within the MIT environment.
• Kerberos version 4 was released on January 24, 1989; however, it was considered insecure due to several cryptographic issues (its use of DES encryption).
• Kerberos v5 was released in 1993 and updated in 2005 to solve the problems of the previous versions. This version added additional encryption types, cross-realm authentication, and the Generic Security Services Application Program Interface (GSS-API).

Kerberos replaced the Windows New Technology LAN Manager (NTLM) as the default AUTHENTICATION protocol from Windows Server 2000 onwards; however, Microsoft still supports NTLM for backward compatibility.

Project Athena Technical Overview video, produced in 1991 with a MIT copyright.

Kerberos 101

The Kerberos authentication protocol outlines how clients (principals) engage with a network authentication service and provides a mechanism for mutual authentication between entities before establishing a secure network connection.

Security principals acquire tickets from the Kerberos Key Distribution Center (KDC) and subsequently present these tickets along with any authenticators while establishing a connection. Kerberos tickets serve as the representation of the client's network credentials.
Here’s a basic representation of the Kerberos Authentication flow:

Kerberos concepts

Let's walk through some basic concepts in Kerberos:

Realm: a domain or administrative boundary that defines a Kerberos authentication space. Realms are often associated with a specific network or organization. e.g.: lareslabs.local.

Principal: unique security entity, such as a user or service identified by a name (principal name) within a realm, to which Kerberos can assign a ticket. Principals authenticate themselves to access secured resources using tickets. Some examples of security principals could include a user, a workstation, a server, services (NFS, hosts...).

Principal Names: Unique identifier to each entity within the domain in Active Directory. e.g.:Elliot.a@Lareslabs.local

Service Principal Names (SPNs): unique identifier of a service instance. Kerberos authentication uses SPNs to associate a service instance with a service sign-in account. e.g., CIFS/fs.Lareslabs.local, MSSQLSvc/SQL01.Lareslabs.local:1433.

SPNs are referenced in the servicePrincipalName attribute of the domain machine/user accounts.

Application/Services Servers (AP):  A host that provides one or more services over the network.

Key Distribution Center (KDC): Implemented as a domain service and located on a domain controller, its primary function is to securely manage the distribution of encryption keys among authorized principals in a network. KDC provides two services that are started automatically by the domain controller's Local Security Authority (LSA) and run as part of the LSA's process:

• Authentication Service (AS): This service handles the issuing of ticket-granting tickets (TGTs) to connect to the ticket-granting service (TGS) in its domain or other trusted domains. TGTs have an expiration date.
• Ticket-Granting Service (TGS): issues service tickets, allowing authenticated users to access specific network services. Upon presenting a Ticket-Granting Ticket (TGT), the TGS verifies and provides a time-limited service ticket for the requested service.

Tickets: Kerberos tickets are encrypted structures that ensure confidentiality and integrity during transmission. This encryption helps protect sensitive information, and only entities with the appropriate keys (such as the user, TGS, and target service) can decrypt and verify the contents of the tickets.

Kerberos tickets are encrypted using the Kerberos keys derived from the user’s password and additional data.

Note: We will discuss tickets in-depth in the third part of the series, Kerberos III— User Impersonation.

Tickets have an expiration time, although they may be renewable and reusable.

• Ticket-granting tickets (TGT): cryptographic structures obtained by a user during the initial authentication process. They are encrypted using the user's long-term secret key and can be used to request service tickets without requiring the user to re-enter their credentials (allow Single Sign-On).
• Service Ticket (ST): obtained from the TGS after presenting a valid TGT and specifying the desired service to access. Contains information about the user, the service, and a session key for secure communication.

Authenticators: Data structures created and encrypted by the client with the session keys provided by the Authentication Services ( KDC).

Privilege Attribute Certificate (PAC): Kerberos is an authentication protocol, not an authorization protocol, this is why this data structure was created, to provide this authorization data for Kerberos extensions.

The PAC is included in nearly every ticket (Authorization Data) that encodes authorization information, consisting of group memberships, additional credential information, profile and policy information, and supporting security metadata.

Below is an example of the information that can be found within the PAC, obtained through a network traffic capture:

When using Kerberos service tickets for server authentication, the Privilege Attribute Certificate (PAC) can be extracted from a user's ticket. This provides the server with information about user privileges without the need to query the domain controller.

Encryption Types

As defined in [MS-KILE], The Kerberos V5 protocol supports multiple encryption types, which are the algorithms for encrypting the tickets or other data. The Kerberos V5 protocol negotiates which encryption type to use for a particular connection.

Windows must support :

• AES256-CTS-HMAC-SHA1-96 [18]
• AES128-CTS-HMAC-SHA1-96 [17]

And  should support:

• RC4-HMAC [23]
• DES-CBC-MD5 [3]
• DES-CBC-CRC [1]

The following example shows how to enable the encryption types for a machine account (FS1$) through the msDS-SupportedEncryptionTypes attribute

More information on how to set encryption types in Kerberos can be found in the Microsoft's documentation.

Wireshark & Kerberos decryption

To better understand what happens within the Kerberos authentication flow, it is possible to provide Wireshark with a key tab file containing Kerberos principal's encryption keys.

To facilitate this, we will need the Kerberos keys of the principals participating in the communication, for example, krbtgt, Elliot.A, and FS1$. To obtain these keys, we can use a number of common tools, such as mimikatz, secretsdump, etc.

The next step is to add the keys to the  keytab.py script provided by @dirkjanm:

Import the output file from keytab.py to Wireshark (Edit>Preferences>Protocols>Krb5):

After that, within the Wireshark capture, we should be able to see several things:

•  Blue highlighted parts, Wireshark has been able to decrypted information using the Kerberos keys of the different principals.
• Yellow highlighted parts, indications of missing key data, resulting the blob not being decrypted.

Kerberos Authentication Flow

The image below shows the Kerberos authentication flow, using our example of a client (Elliot.A) requesting access to a shared folder (CIFS service) on the server FS1.Lareslabs.local:

In Wireshark, the traffic that is generated when a domain user requests a network resource:

Kerberos Pre-Authentication

Kerberos supports different types of pre-authentication including password-based and public key cryptography PKINIT. The most common is using a Timestamp, (PA-ENC-TIMESTAMP). This is just the current timestamp encrypted with the client's key.

Pre-authentication in the Kerberos protocol involves the KRB_AS_REQ (Authentication Service Request) and KRB_AS_REP (Authentication Service Reply) messages.

This pre-authentication process is enabled in all accounts by default, but it is possible to disable it with the flag "Do not require pre-authentication":

The client will first send the AS-REQ without any pre-authentication data. If the server requires pre-authentication for this principal (default option) it will return an error (KRB5KDC_ERR_PREAUTH_REQUIRED) to the client to indicate that pre-authentication is expected.

If you find an account with this option enabled, you can obtain an AS-REP message without knowing the client's secret key for that account (ASREProasting). We will discuss this and other ‘Roasting’ techniques in the second part of the series: Kerberos II—Credential Access.

In the following scenario, Elliot.A., a domain user of the Lareslabs.local domain, wants to start the negotiation process with Kerberos. First, they send an AS-REQ message with his username (cname) to the authentication server (KDC):

By default, all domain accounts have pre-authentication enabled; as such the KDC will return an error (KRB5KDC_ERR_PREAUTH_REQUIRED):

The following image illustrates an initial AS-REQ request from the client without pre-authentication data, along with the response from the KDC:

It is possible to use these error messages to confirm that a user account exists. We will cover this technique in depth in the post: Kerberos II - Credential Access.

Once the KDC confirms that the client requires pre-authentication, the client must send a second AS-REQ message with more data to authenticate against the KDC.

AS-REQ (Authentication Service Request)

The client requests a TGT from the authentication service (AS) at this stage. To do this, the client must send an AS-REQ message.

This message will include, but are not limited to, the following data:

• Principal Name (cname):
• Pre-authentication information (PA-ENC-TIMESTAMP): Timestamp encrypted with the client's key).

It is essential to know that the encrypted timestamp is only necessary if the  user requires pre-authentication, as we have already discussed, is the default option unless the user has the DONT_REQ_PREAUTH flag enabled.

The following image below depicts an example of the AS-REQ message captured using Wireshark:

In the message body, it is possible to find in the padata field, the TimeStamp encrypted with the client's secret key (pA-ENC-TIMESTAMP).

AS-REP (Authentication Service Response)

The KDC attempts to decrypt the Timestamp sent by the client in the previous AS-REQ message using the client's secret key. In case of pre-authentication failure, e.g. if the client does not provide a correct password, an error message KDC_ERR_PREAUTH_FAILED will be returned.

This message contains, among other data:

• Ticket Granting Ticket (TGT), includes the session key encrypted with the ticket granting service secret key (krbtgt secret key), user name, expiration date, and the PAC (provide SIDs, RIDs, user information, password credentials, used for smart card authentication, S4U data..).
• Encrypted data: The session key is encrypted with the user´s secret key.

TGS-REQ (Ticket-Granting Service Request)

The client sends a TGS-REQ message requesting a service ticket (ST) to access a specific service. The client includes, along with other data:

• Ticket-Granting Ticket (TGT) with an "enc-part" encrypted with the krbtgt Kerberos key. It also includes the PAC.
• Authenticator: Encrypted with the user's login session key.
• Service Principal Name (SPN) of the requested service.

The Wireshark capture below identifies that we have found a TGS_REQ message. In the PA-TGS-REQ block, we can see the Ticket Granting Ticket (TGT) and the authenticator sent by the client (Elliot.A). Additionally, in the ‘re-body’ blob, we can identify the service name for which access is being requested (CIFS/FS1):

TGS-REP (Ticket-Granting Service Response)

After receiving the TGS-REQ message and verifying the validity of its Ticket-Granting Ticket (TGT), the KDC returns a response through a TGS_REP message with:

• Service Ticket (TGS), encrypted with the service owner (FS1$) Kerberos key.
• Encrypted data (EncTGSRepPart) is encrypted with a copy of the service session key and the user logon session key.

The image below depicts a TGS-REP message, along with key points to note:

AP-REQ (Application Server Request)

The client forwards a service request message to the intended service, with the following data, among other information:

• Service Ticket (ST): Encrypted with the server kerberos key (FS1$).
• Authenticator: Timestamp encrypted with the current service key.

Here is a snippet of the related network traffic:

If the PAC validation is enabled, which isn't by default, the AP will verify the PAC against the KDC. Also, if mutual authentication is needed, it will respond to the user with a KRB_AP_REP message.

Optional - KERB_VERIFY_PAC [Need to enable Kerberos PAC validation]:

PAC validation is the procedure of confirming the authenticity of a user's PAC during authentication with a server. The AP will verify the PAC included in the TGS against the KDC. If mutual authentication is required, it will respond with an AP_REP message to the user.

This PAC validation can be enabled in the registry key ValidateKdcPacSignature (“ValidateKdcPacSignature”=dword:00000001), in the path:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters].

By default, the value of this entry is 0, so Kerberos does not perform PAC validation on a process that runs as a service.

Optional - RPC status code (PAC Verify Response): The domain controller verifies the signature on the response and returns the result to the server. When the method completes, the server operating system MUST examine the return code to determine if the PAC contents have been altered. The server operating system MUST treat any nonzero return code as a failure.

AP-REP (Application Server Response)

If mutual authentication is required in the AP_REQ request (ISC_REQ_MUTUAL_AUTH request flag), the server must respond with a timestamp encrypted with its own session key:

Once the client receives it and can decrypt it correctly, it will verify that the server is legitimate. If it does not receive a valid AP_REP, the client can confirm that it is a fake/rogue server and stop the communication.

Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)

As described in the MIT documentation, PKINIT is a pre-authentication mechanism for Kerberos 5 that uses X.509 certificates to authenticate the KDC to clients and vice versa. PKINIT can also enable anonymity support, allowing clients to communicate securely with the KDC or with application servers without authenticating as a particular client principal.

PKINIT makes use of the following new pre-authentication types: PA_PK_AS_REQ and PA_PK_AS_REP.

In the context of using PKINIT, the communication flow would be as follows:

The client (Elliot.A) uses its X.509 certificate (signed by the Certificate Authority) and an authenticator (timestamp encrypted with the client´s private key):

Below is the PK-AS-REQ request in Wireshark, including the certificate and timestamp sent by the client:

The authentication server (AS) verifies the certificate, signature and client binding.

If everything is OK, the KDC responds with an TGT encrypted with the krbtgt´s private key and a session key.

In addition, KDC includes the user's LM and NT hash in the PAC (PAC_CREDENTIAL_INFO structure) of the  TGT. This feature will allow the client to switch to NTLM if the remote host does not accept Kerberos.

Since the PAC is embedded within the TGT, which is encrypted with one of the Kerberos keys for the krbtgt account, extracting the PAC is currently impossible.

Due to this, it is possible to use the User to User (U2U) extension to request a TGS ticket with PAC encrypted with the TGT´s session key instead of the krbtgt key and get the user's hash.

In the next post of the series, we will delve deeper into the UnPAC the Hash technique to explore this process more comprehensively.

Wrapping things up ...

In the first part of the Kerberos series, we’ve set the groundwork for the following parts of the series, covering the following:

• An overview of Kerberos.
• The concepts.
• Encryption types.
• The Kerberos Authentication Flow.
• Public Key Cryptography for Initial Authentication (PKINIT).

This concludes our first approach to Kerberos. In the next post, we will explore different (ab)use techniques and discuss ticket and delegation management in depth. The following posts will be published in the future, and their posts can be found linked below.

• Kerberos II - Credential Access.
• Kerberos  III - User Impersonation.
• Kerberos IV - Delegations.

Resources

• Attl4s - You do (not) Understand Kerberos.
• Looking back at Project Athena.
• Microsoft - Kerberos Authentication Overview.
• MIT - Kerberos papers and documentation.
• GoogleProjectZero - Kerberos Relay Requirements.
• Maksim Chudakov - I understand.
• Kerberos PKINIT: what, why, and how (to break it).
• Tarlogic - Kerberos

Hacking is the fun part; now, for the business end of things, it is the most crucial output.

Following our previous posts, Part1, Part 2,  Part3, let's continue building on what we have learned, identified, carried out, and moved towards our end goal.

So, a quick recap … again!

• We’ve identified the reason for driving/your need to conduct a penetration test, as well as any required testing types.
• We’ve identified our engagement prerequisites and the scope of the penetration testing.
• We've carried out our penetration testing activities as defined by our agreed Scope of Work.
• We have documented any observations, findings, evidence and exploitation.

Where Do We Start?

We are at the stage where we have everything we need to compile our report. From an engagement and business point of view, this is ultimately the deliverable.

A good friend and colleague of mine regularly says:

We get paid to write reports, the hacking is free.

This is definitely true!

In Part 3 of our series, I briefly discussed reporting and the debrief and explained that the main deliverable of any penetration test is a formal penetration/engagement test report.

The test team will write an engagement overview and assemble the findings with associated risk ratings to compile a report. The resulting report is then peer-reviewed by Senior or Principal consultants. Once ready, the final report will be sent directly to the customer and/or related in-house security/technical teams (where agreed upon in advance).

Ultimately, the analysis and reporting of the engagement should include:

• Any security issues uncovered.
• The test team's assessment of the level of risk of each finding.
• A method of resolving each issue found.
• An opinion on the risk of your organization's security posture based on the evidence from the penetration testing carried out.

Note: It is important to remember that penetration testing should not be used to drive your organization's vulnerability management process; it is entirely the reverse. Your organization's vulnerability management process must be the driving factor when conducting penetration testing activities and assessments.

A typical penetration testing engagement report, at a minimum, should have the following sections:

• Executive Summary
• Technical Summary
• Engagement Overview
• Engagement Phases and Detailed Findings
• Supplemental Data
• Appendices

That said, when it comes to writing the penetration testing report itself, it will most likely NOT happen in the order listed above. Most, if not all, penetration testers will write their report in reverse:

• Detailed Findings
  • includes annotating/marking items for inclusion within a standalone appendices section, if required
• Technical Summary
• Engagement Overview
• Executive & Assessment Summaries
• Appendices

Key Point to Remember... Target Audience

Three distinct types of readers will generally read a report; as such, the report itself needs to be written in a manner that is digestible by each group:

• C-Level: They usually have minimal time on their hands and, as a result, will probably not have the time to read beyond the first few pages (if that). For this reason, a visual representation of findings to indicate the areas where they need to invest, immediate risks to the business, and any impact on the business's operations is a good idea.
• Security/Project Managers & Stakeholders: These sections are generally read from the start of the report to the business and technical summaries, along with the engagement findings overview. Therefore, these sections need to detail the issues and their associated impacts in an understandable and actionable manner. They will need technical details and remediation advice. Details of the overall trends observed during the engagement will enable them to present results to the risk committee and executive board.
• Technical folks: e.g., Security, IT, Network and App teams, DevOps, Developers, etc. These folks will read the vulnerabilities and findings they have been told to fix. The findings section will need clear details on reproducing the identified issue, a recommendation, and references to enable them to deploy a fix.

Let us get down to Reporting.

So now we know the typical sections a penetration testing engagement report should have. Let's expand on each section, digging deeper into its purpose and how and why each is useful in communicating any risk, impact, and overall outcome of the engagement.

First up, we have:

Executive Summary Section

How different testing companies approach this section can be a mixed bag. Ideally, it should be inclusive of the following or incorporate the following:

• Executive Overview
  • e.g., It should contain the client name, testing company name, dates when the work took place and type of assessment.
• Assessment Summary
  • e.g., Still high-level at this stage, though should contain more about what type of testing took place, testing actions and a general indiaction of the overall risk and testing outcome.
• Engagement Recommendations
  • e.g., Still high-level, these should be overall and accumulative, recommendations and not specific (at this stage), unless there is an overall need to. These recommendations normally centre around reviewing current policy & procedures around risk prevention, mitigation and vulnerability patching etc

In short, this section will provide and/or describe a high-level overview of the engagement's purpose, objectives, general scope, and limitations.

Next Up, we have the following:

Technical Details Summary Section

This section will provide and/or describe a more specific, detailed, and technical account of the engagement, along with the associated phases and work undertaken by the test team.

Key points to look out for are:

• Assessment Contact Information
• Scope of Work (SoW)
• Scope & Engagement Caveats or Limitations
• Post Engagement Clean Up
• Risk Ratings Explanation (pre-agreed risk ratings)

Note: Information in several sections listed above can and should be populated from the engagement scoping questionnaire, scoping calls/meetings and data returned from the engagement itself.

This should then naturally be followed by a more concise section:

Engagement Overview Section

The engagement overview section should consist of the technical findings per phase. This is generally in the form of a table (or similar) for each phase, which will be used to communicate details, such as:

• Risk Rating
• Affected component/host
• Finding(s) discovered

Note: This is again used to provide a high-level overview of issues discovered; however, it is aimed more at those responsible for remediating the issues discovered; therefore, more concise and technical language would be expected here.

Lastly, the engagement overview section should ideally serve as a segue into the "meat and potatoes" section of the report, the:

Engagement Phases and Detailed Findings Section

Whilst the report serves as the overall account of when, what, and how things were done, the detailed findings section is probably the most crucial section of a penetration testing report.

This section provides a detailed overview of the testing phases conducted and the consequent security issues and findings discovered. The main focus is that this section will be specifically for those responsible for remedying the issues found during the engagement.

Several key areas should be included. These are as follows:

• Issue Title & Risk Rating
  • In keeping with the actual issue and identified risk
• Description & Evidence
  • What: Summary of issue identified
  • How: e.g., screenshots, tool and or exploitation output. Evidence such as screenshots and tool/exploit output must be clear and readable
  • Steps to recreate
• Affected Components
  • e.g., IP address and/or hostname
• Recommendation
  • Suitable/appropriate & evidence based
• References
  • Appropriate - not a random/obscure 'blog' or 'stackoverflow' post
  • We often link to Lares Labs' blog posts when referencing previously discussed work that goes into further depth.

A note on the ‘Description’ of the issue identified. This should explain how it impacts the affected host/application/area, then detail how this risks the business, end users or interactions with both.

When reading/reviewing a penetration testing report, a handy technique to ensure that the findings the report details are fit for purpose is to identify that each finding follows along these three simple steps:

• Introduce ...
  • This is where the issue/finding is described
• Show ...
  • This is where what was found is documented e.g., evidence, images & steps to reproduce
• Discuss ...
  • discuss the impact and risk

Note: More evidence is always better than less! Providing steps that are understandable and repeatable is vital.

Appendices

This section should be used for any information such as:

• Additional information that is provided or pertains to documented finding outlined within the ‘Engagement Phases and Detailed Findings. For example, exploitation code, proof-of-concepts etc.
• Data which would complicate any particular finding, e.g., information that degrade the overall flow and/or readability of the report.
• Glossaries
• Detailed methodologies

Tying Everything Together …

Once you've written your report, it should cover all the key areas and necessary points. It should also be digestible by the three distinct groups we outlined earlier. Lastly, it should include any potential appendices detailing more information on the findings themselves or additional supporting context to the engagement, including detailed methodologies.

The report should then be submitted for a technical peer review and quality assurance round to identify any technical inaccuracies and grammatical errors. This will ensure the report is ready for delivery and receipt by the client so that the final product is error-free and both reads and flows well.

Client Debrief

A client debrief should be offered and arranged, allowing enough time for the client and their in-house technical teams to review, digest, and understand the report, its contents, and overall risk/impact. This will also allow them to formulate appropriate follow-up questions and/or queries.

Sessions such as these can be highly beneficial for several reasons, several of which are listed below:

1. Clear Communication of Findings: During the debriefing session, the test team can systematically walk through their findings, detailing the vulnerabilities discovered, the methods used to exploit them, and the potential impact on the client's systems. This clear communication ensures that technical and non-technical stakeholders understand the risks identified during the assessment.
2. Immediate Feedback and Clarification: The client can ask questions, seek clarification, or request additional information about any specific issues identified during the penetration testing. This real-time feedback loop allows for a deeper understanding of the vulnerabilities and their potential implications, enabling the client to make informed decisions about remediation priorities and strategies.
3. Enhanced Collaboration: Debrief sessions foster collaboration between the test team and the client, creating an environment conducive to open dialogue and knowledge sharing. Clients may provide insights into their systems or business processes that could further contextualize the findings, while the test team can offer guidance on best practices for addressing security weaknesses.
4. Tailored Recommendations: During the debriefing session, the test team can discuss tailored recommendations and mitigation strategies that align with the client's needs and constraints. This personalized approach ensures that the remediation efforts are practical, effective, and feasible within the client's organizational context.
5. Opportunity for Improvement: Debriefing sessions allow clients to reflect on their existing security practices and processes. Organizations can refine their security policies, procedures, and training programs to better defend against future attacks by understanding how vulnerabilities were identified and exploited.
6. Documentation and Reporting: The debrief session serves as a forum for documenting the findings, discussions, and action items arising from the penetration testing. This formal record ensures that all stakeholders understand the assessment outcomes clearly and facilitates accountability for promptly addressing security issues.

Let’s recap...

In summary, in this part of the series, we’ve discussed/walked through the following:

• A general recap and overview of a penetration testing report
• The target audience
• The sections of a penetration testing report
• A more detailed view of what each section and what to expect
• The engagement debrief and the benefits

At this stage of the series, whether you're writing or receiving a report—be it your first or 5,000th report—it is essential to ensure that what we have covered during each post directly translates to your specific needs and/or deliverables.

If you are on the receiving end of the report, hopefully, by now, you should know what to expect from the overall penetration test process. This includes identifying your testing needs, scoping the test, understanding the execution, and ultimately understanding and interpreting the report. Digesting each segment of the report should be pretty straightforward and sufficiently segment the sections between relevant teams in your organization.

Suppose you are a penetration tester just starting. In that case, hopefully, the topics and areas we have covered will empower you and instil confidence in your ability to carry out a penetration test to a benchmark standard. Ultimately, you will provide your client with a tangible, structured engagement process, execution of work, and penetration testing report at the end of everything.

If you are ever in doubt or unsure about your penetration testing needs, seeking assistance from a dedicated organization that provides such services regularly is the first step to maturing your security posture.

Over time, you will become more informed and able to take more ownership of this process.

How can we help?

Here at Lares, we help empower organizations to maximize their security Potential.

Lares is a security consulting firm that helps companies secure electronic, physical, intellectual, and financial assets through a unique blend of assessment, testing, and coaching.

If you would like any further information, you can get in touch here or head over to the Lares.com website for more information about how we can help.

It's time to test some pens ...

Following our previous posts, Part1 & Part 2, let's continue building on what we have learned and moving towards our end goal.

So, a quick recap!

• We posed and answered the question: what is Penetration Testing?
• We’ve identified your driving factors, why you need to conduct a penetration test, and any required testing types.
• We’ve identified our engagement prereqs and the scope of the penetration testing engagement.

Now, we are, or rather should be, at the stage where we have everything we need to conduct our engagement.

In part 1 of the series, we posed and answered the question: What is a Penetration test? Using the following answer to serve as a generic base:

A method for gaining assurance in the security of an IT system/environment, by attempting to breach some or all of that system's/environment’s security, using the same tools and techniques as an adversary might.

Here at Lares, we do just this with our penetration testing, attempt to circumvent security controls and gain unauthorized access to an environment, system or service, from an adversarial stance, as a threat actor. Ultimately, it seeks to identify exposures, weaknesses, misconfigurations, and vulnerabilities, which consequently allow/facilitate the exploitation of given systems, infrastructure, applications, or networks.

These attack vectors and exploits will attempt to gain control and further penetrate/compromise the network. With the aim to gain an understanding of the extent of exposure, risk, and compromise to which our clients are face, as a result of the infrastructure, services and security maturity in play. Doing so allows us to understand the true impact to any client organization or what it will likely be, e.g., a postulated threat.

I hear you asking how we do this ... well simply put, we execute our engagements with a detailed methodology, which follows many repeatable steps that can be used no matter the type of engagement.

Methodology Overview

As I mentioned, a methodology, sometimes referred to as the ‘stages of a penetration test’, can be broken down into the following five steps/stages/phases:

• Planning & Reconnaissance
• Discovery/Enumeration (Automated & Manual)
• Attack Simulation & Exploitation (Automated & Manual)
  • Command & Control (optional)
  • Exfiltration (optional)
• Analysis & Reporting
• Client Debrief

However, let's take a moment or two to revisit a crucial stage of the overall penetration testing process, ‘Pre-engagement’ activities.

The first element of any penetration test should always be pre-engagement with the customer. This is where we define the engagement parameters, e.g., Plan, Prepare & Perform, ultimately setting the engagement up for success! Here are a few key points to tick: a pre-engagement checklist.

• Meet with the engagement point-of-contact, commonly referred to as the “PoC”.
• Meet with the customer's security team/technical liaison.
• Ensure there is a description, known as the Statement-of-Work, for the testing types/activities highlighted within the Scope of Work document.
  • Statement of Work: Summary describing the overall work to be carried out.
  • Scope of Work (SoW): The actual specifics, e.g., IPs, Domains, Environments, Type of testing/scenarios.
    • Note: I see lots of folks use these headings interchangeably, which is not correct and can lead to complications/confusion.
• Ideally, there should be no deviation from the scope document. Where a new testing requirement has been identified, a procedure relating to SoW changes or additional work must be followed prior to any new or undefined work being undertaken. Doing so will keep everyone right.
• Confirm connectivity, access and any credentials required/provided for testing purposes are working correctly/as expected.
• Ensure there is an agreed method to communicate with the PoC’s, both primary and secondary (if required), along with establishing a communal & line of communication throughout the testing,
  • Ensure that where details for any technical PoC exist they are also added into any communications.
  • Ensure that the necessary communications with any involved security team are established, if different from your point of contact.
• Where on-site testing site is applicable, or where multiple on-site locations are in scope, then an onsite point-of-contact must be nominated for each site in scope.
• Again, include these PoCs in any engagement’s communications (as applicable).
• Prior to the engagement/testing commencing on the agreed start date, a final authorization to test will be sought via email. This is in order to verify there have been no changes and/or issues with any of the scoped items for review.

So, now we have revisited the pre-engagement activities and double checked that we’re good to go e.g., get to the fun stuff, lets provide some context around each of the steps/stages/phases outlined in the Methodology Overview and set some expectations around what to expect.

A not-so-linear process ...

With all that said, the penetration testing methodology, or rather the one that I will lay out and step through, describing as a linear model isn’t necessarily the best way to describe it; a more accurate representation would look like this (everyone loves a diagram):

I should state, at this stage at least, that whilst the methodology depicted in the diagram above can be applied across several different engagement types, the actual activities/actions, taken for example, for a Red or Purple team engagement, each would significantly differ in execution, due to the engagement deliverables or objectives. So, it is essential to remember this and understand the differences. As such, this post won't cover the specifics of a Red & Purple team engagement.

Planning & Reconnaissance

This can differ depending on engagement type and objectives, but in a general sense this can be framed as conducting initial reconnaissance & target confirmation phase of a penetration test.

The test team will perform activities to enumerate, identify, and confirm information relating to the engagement target(s) or specific environment(s) in a non-invasive or passive manner.

This phase can or will be conducted in a variety of ways, some examples of which are detailed below:

• Customer-supplied information, i.e., target lists, IP ranges, URLs.
• Use and reference publicly available information sources such as domain name registrars, corporate information disclosed as a matter of public record and/or social media platforms.
• Publicly available data breach information, e.g., emails, passwords, usernames etc.

Note: The points detailed above are not exhaustive, and any source that discloses information regarding a target and/or environment can or may be used to some extent.

Discovery/Enumeration (Automated & Manual)

This step involves taking the information and data gathered above and then using it more actively, meaningfully and strategically, e.g., interacting with the target resources and services. This step will typically involve activities such as:

• Port scanning
• Banner grabbing
• Vulnerability assessment & mapping
• User verification/validation
• Security misconfiguration verification/validation
• Password analysis & reuse

Essentially, the test team will look to validate any of their findings/observations for the services and capabilities, which would ultimately be presented to a threat actor for any of the given assets/applications/environments in scope.

Example Enumeration and Discovery:

The test team has identified and confirmed a selection of servers as target assets.

• They will then attempt to identify a list of services running on the host(s).
  • For internal network environments this could be done via passive monitoring of the network or be achieved with active scanning techniques such as port scanning.
• Further targeted manual testing and probing of any applications, networks, services and/or devices in scope will be conducted. This is to provide continuity of testing as well as determine or identifying exact versions of software or hardware (where possible) in use on the asset(s) in scope.
• The test team will now determine whether any of these services are vulnerable and furthermore, whether any consequent issues identified are associated with publicly disclosed vulnerabilities, which have been documented as leading to successfully compromising the assets or services.

Note: The points detailed above are not exhaustive and are merely provided for context and visualization of what may occur during this phase.

Attack Simulation & Exploitation (Automated & Manual)

• Execute attack path to compromise
  • Command & Control activities (optional – dictated by SoW/objectives)
  • Exfiltration activities (optional – dictated by SoW/objectives)

During the targeted attack simulation and exploitation phase of testing, the test team will work towards proving or disproving their ability to interact in an unintended manner and/or to compromise the target environment/application/asset(s) using the enumerated data collected, in conjunction with any vulnerabilities that were mapped earlier in the Vulnerability Mapping and Data Analysis phase.

This will ultimately unfold in such a manner, where the test team will emulate the actions of a malicious individual/threat actor or group; however, a distinct and noticeable difference in general penetration testing engagements, is that they are time-boxed and executed in a controlled manner. This will minimize disruption to client service level agreements, impact to the network and to the services or assets they are targeting; however, a legitimate threat actor, depending on skill/technical ability may not care of the resulting impact of such activities, nor are they limited by time.

Example Attack Scenario: NTLM Relay Attack (High-level overview)

The test team has identified and confirmed the presence of server message block (SMB) traffic, and that Link-Local Multicast Name Resolution (LLMNR), along with NetBIOS Name Resolution (NBT-NS), is enabled.

• Using the tool, CrackMapExec, the consultant generated a relay list of SMB hosts that do not enforce signing, which will serve as relay targets.
• Responder used to carry out a poisoning attack against LLMNR, NBT-NS, and mDNS traffic, along with capturing authentication hashes.
• NTLMrelayX is then used to relay those authentication hashes to the list of relay targets.

A successful relay can result in the following:

• Command execution
• Establish additional footholds
• Persistence
• Interactive shells on the exploited server
• Lateral/vertical movement
• Establish additional footholds
• Persistence
• Dumping Hashes
• Offline cracking

Command & Control activities (optional – dictated by SoW/objectives)

Where a foothold has been successfully gained, a malicious individual or hacking group will often attempt to take their attacks further by escalating access privileges of any compromised users and/or accounts. This may require a command and control (C2) element but can be done without. Often, Lares consultants will perform additional enumeration without using C2 communications and operate from compromised endpoints or using legitimate user access.

The test team's next steps would be to emulate the same approach and install some form of C2; this can be as simple as a reverse connection to using more complex frameworks alongside multiple connectivity methods to ensure redundancy.

Ultimately, the goal is to gain administrative/complete control of the compromised target. This may include but is not limited to, such assets as:

• A domain controller(s)
• Active Directory
• Critical system(s) containing sensitive data
• Network devices i.e. switches, routers, firewalls (if or where applicable)
• Application Servers
• Cloud environments

Exfiltration activities (optional – dictated by SoW/objectives)

Data exfiltration and proof-of-concepts are typically the final active stages of any penetration testing engagement. Data exfiltration is not conducted on every engagement. It is generally agreed in advance as an engagement deliverable, or more commonly reserved for scenario-driven, offensive or bespoke object-orientated testing (commonly referred to as “red or purple team” type engagements).

It is worth noting that depending on the data “in play”, various legal considerations may need to be assessed and understood before any actual execution of data exfiltration. For instance, European/UK clients and their associated data may be governed by legislation such as the General Data Protection Regulation (GDPR) and/or the UK’s Data Protection Act.

In general, data can be categorized as non-sensitive or sensitive.

• Non-sensitive PII is information that can be transmitted in an unencrypted form without harming the individual. Non-sensitive PII can be easily gathered from public records, phone books, corporate directories, and websites.
• Sensitive PII is information that, when disclosed, could harm the individual whose privacy has been breached. Sensitive PII should therefore be encrypted in transit and when data is at rest. Such information includes biometric information, medical information, personally identifiable financial information (PIFI) and unique identifiers such as passport or Social Security numbers.

So, it is highly recommended, that before any data exfiltration the test team understand the type of data they will be interacting, along with any regulatory/legal requirements.

Finally, it is essential to realise that, as general penetration tests are carried out within the context of a timeboxed and controlled manner, attacks such as Denial-of-Service (DoS) attacks are often avoided, along with exploits/exploitation, which may be unreliable or are known to work in such a way that they cause damage or disruption.

Where there is a requirement/deliverable for this type of specific testing, where possible, testing should be carried out in a simulated and representative test environment rather than against the real/live asset(s) itself; this is particularly beneficial where sensitive or high use production environments are being tested.

Analysis & Reporting

A good friend and colleague of mine comments regularly that:

...we get paid to write reports, the hacking is free!

and this is definitely true!

The main deliverable of any penetration test is a formal penetration/engagement test report. This should be compiled by the test team and overseen by a senior/lead tester for each engagement. The final report will be ultimately sent directly to the customer and/or related in house security/technical teams (where agreed in advance).

Ultimately, the analysis and reporting of the engagement should include:

• Any security issues uncovered.
• The test team assesses the level of risk that each vulnerability exposes to the organisation or system.
• A method of resolving each issue found.
• We will use our consultants' professional opinion on the accuracy of your organisation's security posture based on the evidence from the penetration testing.
• Advice on how to improve your vulnerability assessment and management process.

As such, a typical penetration testing engagement report, at a minimum, should have the following sections:

• Executive Summary
• Technical Summary
• Engagement Overview
• Engagement Phases and Detailed Findings
• Supplemental Data
• Appendices

Client Debrief

A penetration testing debriefing session should be arranged(where applicable per assessment type) after a suitable/pre-agreed timeframe, after which the client's in-house technical and security teams have had ample time to read, understand, and formulate the basis of any engagement questions and remediation approach.

This serves as a crucial step in the overall assessment process, providing an opportunity for the test team to communicate their findings comprehensively and for the client to gain deeper insights into the security posture of their systems.

Practical Execution of the Methodology: External Penetration Test

In reality, an actual practical example of the execution of a penetration test, for example, an external penetration test, might look like this, as depicted in the image below.

Note: this is a high-level representation of the execution of the methodology.

Using our previously defined methodology, let’s break down the example in the image above.

• Planning & Reconnaissance
  • Activities are conducted against a number of services/ resources, as annotated within the pink box.
• Discovery & Enumeration
  • Target identification/verification
  • Port scanning
  • Banner grabbing
  • Manual interaction
  • Vulnerability assessment
• Attack Simulation & Exploitation
  • Test team reference the SOW & engagement deliverables:
    • If allowed: further targeted activities can be focused on perimeter/network devices, Operating Systems, Servers, Web Servers and Services, with the view to identify vulnerabilities leading to viable attack paths and exploitation.
    • If not allowed: Conduct a vulnerability assessment (see note below), with follow-up non-invasive manual verification, along with documenting any the likely outcome/risk.

Note: a vulnerability assessment is not the same as an actual penetration test; these two terms are used interchangeably regularly. A key point to note is that a vulnerability assessment generally focuses on the identification of as many vulnerabilities within the allotted period as possible, whereas an ‘actual’ penetration test will not only identify vulnerabilities, it will also focus on active exploitation of these vulnerabilities, to fully understand their actual security risk and impact.

Let’s recap...

In summary, we’ve discussed/walked through the execution of the scope-of-work (SOW) and the actual phases of a penetration test, what they look like in general, the types of actions that could be taken throughout that process, reporting and what that should look like, along with the view of a practical representation of what this looks like in ‘real life’, using an external penetration test as our reference point.

If you are ever in doubt or unsure about your penetration testing needs, seeking assistance from a dedicated organisation that provides such services regularly and has a proven track record and reputation is the first step to maturing your security posture, awareness, and understanding of penetration testing.

Over time, you will become more informed and able to take more ownership of this process.

From here, the following steps involve: Given that we carried out the scope of work and our testing activities following our methodology, we now need to compile the engagement report, deliver it to our client, and follow this up with a debrief call/session. This will be covered in part 4 of the ‘Pentesting 101’ series.

How can we help?

Here at Lares, we help empower organizations to maximize their security Potential.

Lares is a security consulting firm that helps companies secure electronic, physical, intellectual, and financial assets through a unique blend of assessment, testing, and coaching.

If you would like any further information, you can get in touch here or head over to the Lares.com website for more information about how we can help.

As security professionals, we often run into the age-old issue of passwords across multiple environments, systems, implementations, and other chaos. An interesting aspect we regularly encounter when compromising organisations is the psychology behind how people choose their passwords. This insight reveals patterns and tendencies in password creation within windows environments, shedding light on common vulnerabilities and the human factors influencing password security.  

Understanding these psychological elements is crucial for developing more effective security strategies and educating users about safer password practices. It is equally important when building cracking methodologies to effectively assess an organisation's security posture and crack the keys to the kingdom.

This post delves into the trends identified over the past two years, offering insightful comparisons between strong and weak password policies. It also explores the user behaviors that develop due to these policies.

We use hashcat as a strategic and systematic approach to advancing our engagements over time, particularly in the realm of cracking password hashes. This method has proven effective in obtaining the cleartext values for various interesting passwords, providing valuable insights into organisations' trends and practices in establishing their password policies.

Additionally, this approach informs our strategies for password guessing and spraying attacks against endpoints, enhancing our understanding of the thought processes prevalent in specific industries and how certain security controls can be bypassed.

The Core Data

All of the analysis in this post is from an amalgamation of cracking windows NTLM passwords over two years; the total amount of hashes was 186149, unique hashes were 99918, and 31200 were cracked, resulting in many repeat passwords across users and industries.

The findings from this extensive data set offer valuable insights:

1. Password Reuse: The large number of repeat passwords suggests a widespread issue of password reuse across different users and industries, a practice that significantly compromises security.
2. Common Weak Passwords: The success in cracking a substantial portion of the hashes indicates that many users continue to rely on weak passwords, which are vulnerable to cracking tools and techniques.
3. Industry Patterns: The data potentially reveals patterns in password creation and policy enforcement across various industries, providing an understanding of industry-specific security postures.

Our Hashcat Rules and Setups

Depending on the hash type will depend on how we approach cracking it on our rig; typically, quicker to crack hashes such as NTLM, we will approach with a wordlist for a quick flyover followed by rules, followed by specifics around the company name, and other relevant wording or phrases.

Our collective NTLM cracking rate is ~600GH/s, comprised of several RTX 4090s, 3090s, and other cards.

We use a collection of custom and standard wordlists when targeting organisations. The standard public lists we try with various rules are shown:

• HaveIBeenPwned password list from PwnedPasswords (https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader)
• Common Corp Passwords (https://github.com/danielmiessler/SecLists/blob/master/Passwords/common_corporate_passwords.lst)
• English Dictionary (https://github.com/dwyl/english-words/blob/master/words.txt)
• Crackstation (https://crackstation.net/crackstation-wordlist-password-cracking-dictionary.htm)
• Antipublic (https://bigpasswordlist.com/DAAP.html)
• Weakpass_3a (https://weakpass.com/wordlist/1948)

As for rulesets, we use public and private ones again, but here are the public ones we use:

• OneRuleToRuleThemAll  (https://github.com/NotSoSecure/password_cracking_rules)
• OneRuleToRuleThemStill  (https://github.com/stealthsploit/OneRuleToRuleThemStill)
• Pantagrule  (https://github.com/rarecoil/pantagrule/tree/master/rules/private.hashorg.royce)

Finally, on top of wordlists and rules, there are some custom masks we frequently use when targeting specific organisations, but there is a core list of masks and hashcat commands:

CompanyName?a?a?a?a?a?a
Colour?a?a?a?a?a?a

A prevalent trend observed in various environments is the use of situational or time-structured passwords. Users often create passwords incorporating elements such as the current season, month, day, company, or department name, typically followed by a date. This predictable pattern makes it easier to crack these passwords using hashcat rules and masks, allowing for efficient and swift password reversal.

Andy Gill, one of our consultants, wrote a toolkit for parsing pot files that we've leveraged to build master wordlists and standard rules:

GitHub - ZephrFish/PotUtils

Contribute to ZephrFish/PotUtils development by creating an account on GitHub.

GitHubZephrFish

The crack flow process typically follows targeting the company with a select wordlist and rulesets, brute-forcing up to the nine-character keyspace with optimized keyspace, parsing the profile, and running the cracked list against a ruleset again to fish out patterns.

What was your password last summer?

As companies mature, so do their password policies; gone are the days when many of our clients were simplySummer2024! , and you're in the front door. We still see SeasonYYYY or variations of it in less mature environments now and again. Here are some of the examples we've seen of seasons and mentions of them:

We wrote an in-house tool to do password analysis. When given an input of cracked hashes, it would analyze common words, phrases, and other attributes. The results from said tool are shown in the following screencaps detailing common passwords, top passwords, days of the week, months of the year, seasons, and colours.

The average length of 11 characters shows a good improvement year on year and more mature password policies being applied across organisations. While there are still outliers, the general coverage of estates looks to be on an upward trajectory for improvement.

Despite people being big fans of summer, it would appear the winter months are more prevalent in passwords.

The title of this post gives it away, but people are big fans of summer, and it's apparent in their password creations, too.

Many folks have a favourite colour of blue, with red and green following closely behind.

Of the top years in passwords, 108 were forward thinkers, getting that 2025 several years ahead; attackers will never think of that!

Interesting Passwords

We come across many interesting passwords; here are some of our favourites we've seen in the last couple of years, both secure and funny.

<Passw0rd1><Passw0rd2>
#1PeppermintPatty
Grits&Gravy4u
HelloSummertime2023!
Security4You
Sec9re_NobodyWillGuessMe
Gustavo12345678901234567890
Green eggs and ham!
Why $o Serious?

These passwords were cracked using a combination of mask attacks, wordlist and rule-based attacks. In addition, baseline password lists were used iteratively to crack and inform cracking other passwords. Remember that complexity and length can make cracking time-consuming and resource-intensive, especially with high-entropy passwords.

Further Analysis on Duplicates

Our analysis revealed significant findings regarding duplicates and unique users with shared passwords. A recurring pattern was observed where accounts set up by an organisation for specific purposes shared identical passwords, often resulting from mass-reset procedures.

Additionally, instances were noted where users with multiple accounts, especially those with privileged access, reused passwords across different organisations. The research also sheds light on cases where users, upon changing organisations, continued to employ poor password practices, carrying the same weak passwords to their new workplaces.

• Total Hashes: 186149
• Total Duplicate Hashes: 56648
• Total Users with Duplicate Passwords: 11359

The successfully cracked passwords were analyzed on publicly available lists from SecLists(https://github.com/danielmiessler/SecLists/tree/master/Passwords/) to uncover interesting matches in public wordlists.

2020-200_most_used_passwords.txt: 19 matches
2023-200_most_used_passwords.txt: 20 matches
500-worst-passwords.txt: 39 matches
bt4-password.txt: 212 matches
cirt-default-passwords.txt: 7 matches 
clarkson-university-82.txt: 7 matches
common_corporate_passwords.lst: 118 matches 
darkc0de.txt: 135 matches
darkweb2017-top10.txt: 5 matches
darkweb2017-top100.txt: 9 matches 
darkweb2017-top1000.txt: 54 matches 
darkweb2017-top10000.txt: 161 matches
days.txt: 17 matches 
dutch_common_wordlist.txt: 105 matches
dutch_passwordlist.txt: 724 matches
months.txt: 48 matches
Most-Popular-Letter-Passes.txt: 94 matches
mssql-passwords-nansh0u-guardicore.txt: 118 matches
openwall.net-all.txt: 143 matches
probable-v2-top12000.txt: 148 matches
probable-v2-top1575.txt: 65 matches
probable-v2-top207.txt: 26 matches
richelieu-french-top20000.txt: 104 matches
richelieu-french-top5000.txt: 67 matches
scraped-JWT-secrets.txt: 8 matches
seasons.txt: 40 matches
twitter-banned.txt: 34 matches
unkown-azul.txt: 9 matches
UserPassCombo-Jay.txt: 23 matches
xato-net-10-million-passwords-10.txt: 4 matches
xato-net-10-million-passwords-100.txt: 16 matches
xato-net-10-million-passwords-1000.txt: 53 matches
xato-net-10-million-passwords-10000.txt: 121 matches
xato-net-10-million-passwords-100000.txt: 284 matches
xato-net-10-million-passwords-1000000.txt: 525 matches
xato-net-10-million-passwords-dup.txt: 523 matches
xato-net-10-million-passwords.txt: 755 matches

The results indicate that all the passwords identified are already known and included in standard wordlists. This suggests a greater likelihood of successful compromise by attackers.

Advice For Password Creation

When selecting a password, conventional advice has long recommended using a mix of special characters, numbers, and upper and lower case letters, with a minimum length of 8 characters. However, this advice evolves. Observations from our more mature clients indicate that prioritizing password length over complexity and less frequent changes encourages the adoption of passphrases. These are easier to remember yet remain challenging to crack, offering a balance of security and user-friendliness.

Both the UK and US government security arms have great advice around password creation; therefore, here is a combination of their advice to help you create strong passwords:

1. Length is significant; aim for a minimum of 16 characters when creating an active directory policy.

To help users with creating long passwords, try suggesting using four random words and connecting them with a special character like a - or $, doing so increases the complexity and at the same time the length. An example of this may be:

• Sunset$Guitar$Puzzle$Journey or Cloudy-Envelope-Rainbow-Dinosaur (Don't use these two examples as they're also on our wordlist ;) )

Both of these would fall within a decent length as the phrase "Cloudy-Envelope-Rainbow-Dinosaur" consists of 32 characters, including the hyphens, and  "Sunset$Guitar$Puzzle$Journey" consists of 28 characters, including the dollar signs.

2. When setting up default or initial passwords for the organisation, it is advisable to use an algorithm for generating unique user passwords, rather than relying on a static value. If implementing such an algorithm is not feasible, an alternative approach is to require users to change their password upon their first login. This practice helps in minimizing security risks.

3. To ensure that users maintain unique passwords, it is beneficial to encourage and enforce the use of password managers. These tools assist not only in generating solid passwords but also in creating distinct and unique passwords for different accounts. This approach steers users away from easily crackable passwords, such as basic phrases, common words (like 'welcome' or 'password'), seasons, months, years, and places. Instead, users can opt for the recommended method of combining four random words, which can then be securely stored in a password manager. This strategy enhances overall password security and management.

Conclusion

This post has primarily focused on the security of passwords within Windows environments, particularly from an internal standpoint using data collected across many datasets. However, it is vital to stress that a robust password policy should not be an organisation's sole line of defence. In addition to strong passwords, it is imperative to implement further protective measures.

Key among these is the adoption of multi-factor authentication (MFA), which adds a layer of security beyond just the password. MFA requires users to provide two or more verification factors to access a resource such as an application, online account, or a VPN. This significantly reduces the risk of unauthorised access. Where possible, we have seen some clients implement MFA for access to internal resources, utilising existing single sign-on providers and similar identity and access management technology to restrict lateral movement opportunities.

Moreover, organisations should embrace the principle of 'defence in depth'. This is a comprehensive approach to cybersecurity that layers multiple defensive mechanisms. If one mechanism fails, another steps in immediately to thwart an attack. This approach involves technological solutions and encompasses policies, procedures, and awareness training to ensure that all possible security gaps are covered.

Incorporating these practices alongside a robust password policy creates a more resilient and secure environment, reducing the likelihood of successful cyberattacks and enhancing overall organisational security.

Following on from the SE:101 Series created by Chris Pritchard, featuring blogs post by both Chris and I, this is the latest post in the series, which covers ‘Smishing’, a lesser known, but highly prevalent social engineering attack vector.

What exactly is ‘Smishing’?

Common tactics employed in smishing attacks include masquerading as reputable entities, such as banks, government agencies, or well-known service providers, family and friends. These messages often contain links or phone numbers that, when interacted with, can lead to the compromise of personal information or the installation of malware.

Given the prevalence of mobile devices in our daily lives, smishing has become an increasingly favoured tactic among cybercriminals. As such, it is imperative that we remain vigilant and educate ourselves, our colleagues, family and friends on recognizing, and avoiding such deceptive messages to safeguard our sensitive information, or in the case of business, its proprietary and customer information.

So how does ‘Smishing’ work at a high-level?

Well, this is a form/variant of a ‘phishing’ attack, in which an attacker uses a compelling text message to lure, build rapport and ultimately trick the targeted recipient(s) in to the doing any or all of the following:

• Clicking a link which will have malicious intent or consequences
• Sending the social engineer/threat actor private information
• Sending the social engineer/threat actor financial information
• Making a purchase for gift certificates/store cards e.g. Amazon, Apple…
• Downloading malicious programs/software to a smartphone or other hardware devices

It is worth noting that the social engineer/threat actor, or the ‘Smisher’ as we’ll now refer to them, may use your actual name and location to address you directly. Using these details make the pretext of any message more compelling for the recipient.

Lets Breakdown a 'Smishing' Attack

The following breakdown is taken from an actual ‘Smishing’ attack which targeted an individual using the pre-text or ‘lure’ of urgency and a position of authority. I should point out, at this stage, that the smishing attack featured, was ultimately unsuccessful, due to the security awareness of the targeted individual and their ability to challenge politely but firmly.

Using the following image, which depicts the ‘Smishing’ attack message exchange, we can break down the ‘Smishers’ approach/methodology.

Note: the SMS conversation has been redacted to protect the recipient’s identity (yellow box), as well as the senior figure being impersonated (red box).

Step 1) OSINT: The ‘Smisher’ has clear done some open-source intelligence gathering (OSINT) and identified a senior figure of importance within the target organization. (Easily done via LinkedIn, Corporate publications/resources, news articles, media coverage etc.)

Step 2) Identify targets: Using data breaches, social media platforms, sources of public record, a social engineer/threat actor can enumerate an individual or groups of individuals information. Once a target list has been constructed, depending on the technical ability of the ‘Smisher’ or threat actor, both manual (time consuming) and automated (most efficient, as allows for mass campaigns) means can be used to launch the attack.

Step 3) The Pretext: In our example, the ‘Smisher’ poses as a high profile, well known and important individual, within the target organization. This is then supported with the “lure/enticement”, and this is conveyed in the following forms:

• First: A closed question first (e.g. a question that is either a yes/no)
• Second: Politeness
• Third: Needing Help third
• Fourth: Urgency fourth
• Lastly: Directness last (issuing a request, with the initial pretext set as coming from a high profile/important individual)

At this point, Directness, the ‘Smisher’ will either succeed with the lure, get caught out, or attempt to enacted a secondary pretext/lure! In our case they got caught out, as when the colleague issued the verification challenge, requesting a current picture, the ‘Smishing’ replied with “Check on LinkedIn”, at which point, the targeted recipient ceased all further interaction with the ‘Smisher’ and reported the incident to the organization security team.

So, how can we Protect Ourselves from Smishing Attacks?

We all know about email phishing, the dangers of it and what to look for, but ultimately if it feels ‘off’ we call it out! Protecting ourselves from ‘Smishing’ attacks, we need to take the same approach; however, smishing prevention, much like phishing prevent, depends on the targeted user’s ability to identify a smishing attack and ignore or report the message. With this in mind, here are some simple steps, as an individual, to be aware of:

• Check the listed Caller ID; this usually points to an online voice over IP (VOIP) provider, where looking up the number and its location is not normally possible.
• Check the message, grammar, spelling and structure
• Don’t click on any links which you are unsure of the origin or validity
• Don’t send anyone private information via SMS
• Don’t send anyone financial information via SMS
• Don’t make purchases for gift certificates/store cards e.g. Amazon, Apple… if asked to do so via SMS
• Don’t download malicious programs/software to a smartphone or other hardware devices if asked to do so via SMS
• Ultimately be aware of your social media/online presence and what you make available

In addition to the above point, there are several technological solutions which can also prevent, or act as defense in depth:

· SMS Filtering: Many smartphones/cell phone carriers now provide ‘SMS filtering’ options to identify and block or flag suspicious SMS’s.

· Multifactor Authentication (MFA): Utilizing MFA is an additional protective layer, will serve as an additional layer of defense and can prevent a threat actor from using credentials obtained through ‘Smishing’ attack.

Anti-phishing Tools: Some security applications for mobile devices, for example, Google Chrome’s ‘Safe browsing’ and IOS’s ‘Built-in Privacy & Security’ protections, can help identify phishing links in text messages and prevent users from accessing malicious sites.

Closing Points

Anyone with a mobile device, such as a smartphone or tablet, can receive regular cellular text messages, from any number in the world, or indeed via any supported applications e.g., WhatsApp, Telegram, Signal. Many users are already aware of the dangers of clicking a link in email messages; however, fewer people are aware of the dangers of clicking links which are contained within SMS messages and ‘Smishing’ attacks.

In short:

• Ignore: If it looks too good to be true and/or the message is unsolicited, ignore, report and delete. SMS messages offering quick money from winning prizes or collecting cash after entering information.
• Remember: Financial institutions will never send a SMS asking for credentials or a money transfer. Never send credit card numbers, ATM PINs, or banking information to someone via text messages.
• Avoid: avoid responding to a SMS/phone number that you don’t recognize.
• Awareness: Make an effort to stay up to date with current smishing tactics and threats. Awareness can be your first line of defense. As an individual this maybe seem like a daunting task; however, your current organization may have security awareness program which covers topics such as this, as such this would be a great place to seek help and understanding. Alternatively, seeking knowledge online from reputable providers can also be another great option.

As users, we are much more trusting of text messages in this day and age, as this is normally the main means of communications between family and friends, so ‘Smishing’ is often lucrative to attackers seeking to build rapport and obtain credentials, banking information and private data.

Back Story

SuperSharpShares came about somewhat unexpectedly - it was never intended for release and wasn't initially developed with that goal in mind. Originally, it served as a solution within a more intricate tool we created that remains unreleased (for now, never say never). However, during a challenging assessment due to the scale of the environment, the automated share enumeration functionality was attractive as something to run quicker than other tools. As such, we copied that functionality and then used it to create this standalone program.

While numerous tools offer similar functionalities, our preference, where possible, is to develop our tooling in-house. This kind of hands-on approach gives us a better understanding of how something works and enables the opportunity to change or tweak it as required. Releasing the tool allows others to ignore, tweak, or improve as they feel fit.

If we had to sum up the advantages of SuperSharpShares. They are as follows:

• easy to use,
• quick, even within large environments,
• suitable for auditing,
• A small data footprint with minimal lines of code makes it easier to understand how it works and use it in other projects.

Again, numerous tools offer similar functionalities, but they are often bundled within a more extensive tool offering; it is nice to have a single function within a tool to help keep it simple.

As the saying goes, “A picture is worth a thousand words,” with that, it's best we just show you SuperSharpShares after execution.

Execute SuperSharpShares from a domain-joined host or a runas window, both with no command options required. The program automates the entire process for you: the domain look-up, host machines, accessible shares, and finally, each available share or write access status. We have used SuperSharpShares across multiple domains, and even in large environments, we've observed that it swiftly enumerates accessible shares quicker than many other tools.

Read and Write Access

Domain shares are filled with gold; in almost every environment, examples of sensitive data are being overly shared. Armed with a typical user's domain account, adversaries can often access enough internal data to tarnish the business name, manipulate a business's share price, encrypt data for a ransom, or snoop.

During an assessment, it's common to uncover read access to shares that were either unknown or intended to be accessible only by a specific group of individuals.

Having write access to a share implies the ability to make unauthorized changes to files or folders, allowing manipulation or injection of malicious content. Notably, write access to an ADMIN$ or C$ share often signifies that the executing account potentially possesses administrative privileges over the identified host.

The picture below details the following:

1. The execution of SuperSharpShares has revealed Write access to the C$ share on host WIN10-LAB2.
2. Windows File Explorer is used to manually access the share, verifying the administrative access to the host.
3. The final CMD prompt confirms that the executing account is only a member of Domain Users group.

In large environments, it's common to discover an individual domain user account or the whole group has been added to a machine's local administrative security group.

SuperSharpShares Under The Hood

The program starts by retrieving the domain name associated with the currently logged-in user.

After obtaining the domain name, the program calls the GetComputerNames method, which is part of the EnumerateDomainShares class. This method queries Active Directory for computer objects within the specified domain and retrieves a list of their host names.

The GetComputerNames method uses an LDAP path and Active Directory queries to fetch the list of computer names within the enumerated domain.

The NetShareEnum function from the Netapi32.dll library is then used to enumerate and retrieve information about the accessible shared resources (shares) on each enumerated computer within the domain.

The script utilizes the Parallel.For construct, a mechanism provided by the Task Parallel Library (TPL) in C# to help perform parallel processing.

The TPL automatically manages the allocation of threads based on the available CPU cores. The idea is to divide the workload (iterations of the loop) among multiple threads, allowing concurrent execution to speed up the overall process; it works!

Endpoint Detection and Response

The program would be a valuable addition for any internal IT team to help them audit which shares are accessible by domain members.

While all included functionality is strictly legitimate, there is still a chance that the program could eventually be categorized as malicious by EDR solutions. At the time of release, there was no categorization by Windows Defender.

During a recent assessment of a very mature environment, we noted that SuperSharpShares was not blocked from execution but did raise a medium alert for potentially suspicious behavior due to the large amount of internal SMB connections to each host machine during the share enumeration phase.

This released version is intended for legitimate auditing purposes only and not super stealthy, sneaky red teaming assessments. This aside, we have verified in our lab that changing the method of execution from parallel to sequential means it does not perform multiple SMB requests at once, and then, in addition, adding a delay option would make the tool undetected. We have not added these options in the public release because it dramatically reduces execution speed.

Building

Double-clicking the SuperSharpShares.sln file should load all required to build the program.

Verify that the release has been selected on the top toolbar.

Under Solutions Explorer, right-click on the program and select Build.

Under the Output bar, you should see the build location.

Good Practice

Following verification that the initial build was successful, you may wish to rename the program as such.

1. Right-click on the program name under Solutions Explorer and select Rename.

2. Right-click on the renamed program under Solutions Explorer right-click and select Properties.

3. Change the Assembly name and Default namespace in the Application tab.

4. Back under Solutions Explorer, maximize Properties, and select AssemblyInfo.cs.

This should load the AssemblyInfo.cs parameters of which you may wish to edit the AssemblyTitle, AssemblyProduct, AssemblyCopyright, and the GUID (use https://guidgenerator.com/)

5. After changing the above-suggested options then, rebuild the program.

You should see that the name and its original descriptions have all been updated.

Conclusion

We have released SuperSharpShares to help IT engineers and security professionals enumerate shares accessible with associated domain accounts. The tool offers a swift and straightforward solution to help review internal network shares.

Insecure storage and oversharing of sensitive business data are widespread occurrences noted during security assessments; using tools such as SuperSharpShares allows internal and external professionals to identify the foundations of such dangers.

You can download and compile the tool from our git here: https://github.com/LaresLLC/SuperSharpShares

Often when performing some kind of social engineering, you'll need a pretext.

Well, what is a pretext? The Cambridge Dictionary lists it as:

A pretended reason for doing something that is used to hide the real reason

It's a fancy way of saying; it's your back story (or legend as they call it in the UK, undercover, police world).

The back story that you'd use in justification if you were challenged or asked why you're in the server room (when you shouldn't be).

Fitting Your Pretext

If you're physically and socially engineering into a building or office, fit your pretext around your knowledge and skill set, i.e. Don't say you're a plumber if you've never plumbed before.

There's a chance you'll be asked questions and/or terminology you probably do not know about.

But if, like me, you've got an IT Support and IT Network background, these are ideal things to fit your pretext.

If you get challenged, or asked questions, not only do you know the terminology but, more importantly, the answers will come to you quickly and you'll answer confidently.

It's a subject you know; you won't be umming nor arrrr'ing; you'll just answer without thinking about it. Doing that will give the person asking the question no concerns that you shouldn't be there.

There's much more to it than that. Don't just wing it; try to get in, and say you're from IT Support.

It would be best if you did some background research. Do they even have in-house IT Support? Is it outsourced? To whom? Can you use sites like LinkedIn to find the names of IT Support people?

Your Story

Also, you need a story! Why are you there? You can't just turn up and say, "Hi, I'm from IT Support", and expect to be let in (Although, in fairness, I have done this before and, yes, it worked, but it was an exceptional set of circumstances).

It would be best to have a reason to be there, doing what you want/need to do. Think of a story and an explanation and your knowledge and skill set.

You could be from IT Support and there to fix a slow internet issue.

What's great about this, assuming you have an IT Support background, is that it would be difficult to check whether a ticket has been raised, and it's very unlikely someone will check if you are from IT.

More importantly, EVERYONE wants their internet to run fast and smooth.

However, this is just an example. Fit it around your knowledge, your target, and the situation.

Just Because

If you've read Robert Cialdini's book "Influence", there's some excellent psychological research around just using the word "because".

If you walk into a coffee shop and see a massive queue, people will be annoyed with you, if you loudly proclaim, "I need a coffee urgently!". You're going to get booted to the back of the queue.

However, and there's research to prove this, if you say, "I need to jump the queue because my car is double parked", you've got a 94% chance that no one will mutter a word.

What's crazy, and again they've proved this, you could say, "Because the sky is blue", and it would STILL work!? The percentages are less, but still oddly high at 60%.

Match Your Outfit

Whatever you choose as your pretext, match your dress style and outfit to that pretext. There are caveats to this theory.

Let's work through some examples;

You're an IT Support engineer, and from the reconnaissance (Link to come), you've seen that everyone in your target office dresses smartly.

If everyone is dressed in a suit, shirt, tie, nice trousers (pants my American friends), then you need to match that dress style and outfit because it's very likely that the IT Support team will wear the same as the rest as the general office staff.

Ok, that works, but let's say your pretext is you're an outsourced or third-party alarm engineer. Well, that's different.

It's likely that the "company" that you're pretending to work for has an entirely different dress style.

To generalise, there's a good chance it could be a polo neck with an embroidered logo, maybe cargo/work trousers (remember pants US friends).

You'll also need a toolbox, some tools, a clipboard with a worksheet, etc. You get the idea.

What I'm saying is you want things to add up. An alarm engineer probably doesn't wear a suit, but maybe an officer worker doesn't wear a suit either, it might be dressed down.

Do the reconnaissance and find out. This blog is part of a SE101 series, and originally appeared here:

What’s a Pretext?

Often when performing some kind of social engineering, you’ll need a pretext. Well, what actually is a pretext? The Cambridge dictionary lists it as: A pretended reason for doing something that is used to hide the real reason It’s a fancy way of saying; it’s your back story (or legend

Chris P's BlogChris P