DEV Community: Tilak Upadhyay

Why your SBOM is lying to you: Rethinking OWASP A03 for 2026

Tilak Upadhyay — Mon, 20 Apr 2026 07:36:46 +0000

Bad actors aren't breaking into our front door anymore; they’re poisoning the groceries in the stores before they even get into our kitchen.

If you’ve been looking at the OWASP Top 10 for 2025, you’ve seen Software Supply Chain Failure (A03:2025) skyrocket to the #3 spot. But if we’re being honest with each other, the way most of us are handling this is broken.

We’ve fallen into a compliance-first trap. We’re checking boxes, generating massive spreadsheets and drowning our security analysts and developers into hundreds of "Critical" alerts that, in many cases, pose minimal or zero actual risk to the business.

The Massive Myth: "A 100% Clean SBOM = Secure"
As security professionals, we should know that’s a lie. We can spend an entire quarter patching every CVE in node_modules, only to realise half of those libraries weren't even being called by our application.

We are essentially chasing ghosts while the actual product roadmap dies.

To get serious about supply chain security in 2026, we have to move from Inventory (SBOM) to Context (Reachability + Impact).

Here is my point of view to address this issue:

1. Context is King: The Power of Reachability

A vulnerability in a transitive dependency only matters if your code actually executes that specific path. In a typical modern application, many of these vulnerabilities are in dead code.

The Solution: Move toward Reachability Maps. Instead of a flat list, you need a call graph that proves a path exists from your user input to the vulnerable function.

OWASP A03:2025 documentation emphasises that the failure isn't just having a vuln, but failing to verify its impact within your specific architecture.

2. Adopt VEX (Vulnerability Exploitability eXchange)

If you haven’t looked into VEX, you’re missing the most powerful tool in your noise-reduction arsenal. While an SBOM tells you what’s in the box, a VEX statement tells you if that content is actually dangerous.

The Real-World Logic: VEX allows you to formally document—in a machine-readable way—that "Yes, CVE-202X-XXXX exists, but our implementation doesn't use the vulnerable method, so we are NOT_AFFECTED."

Refer to the NTIA's VEX Framework for basic understanding.

3. The "Dependency Confusion" Trap (A03 Meets A08)

This is a low-hanging fruit that still leads to breaches. Attackers could have been shadowing your internal package names on public registries. If your build config isn't scoped strictly, it might pull a malicious internal-only-tool from the public web instead of your private repo.

The Connection: This links directly to Software and Data Integrity Failures (OWASP A08:2025). If you can't verify where your ingredients came from, you can't trust the final dish.

The Fix: Implement Namespace Scoping (e.g., @my-org/auth-package). It’s a 5-minute configuration change that prevents a catastrophic supply chain injection.

4. Verify Build Provenance (The SLSA Framework)

Scanning code is useless if your build server itself is compromised. If a hacker gets into your CI/CD pipeline, they can inject malware after your security tools have finished their scan.

You need cryptographic proof, Build Provenance, that the binary in production exactly matches the source code you actually reviewed.

The Framework: Follow the SLSA (Supply-chain Levels for Software Artifacts) guidelines.

The Goal: We should reach SLSA Level 3, which ensures our build process is Hardened and Non-falsifiable.

5. Move from "Scanning" to "Attestations"

Stop trusting the code and start trusting the process. Use tools like Sigstore or In-toto to cryptographically prove that the code running in production is exactly what left your CI/CD pipeline.

An Attestation is a signed piece of metadata that says, "I am the build server and I promise I built this specific hash from this specific code commit."

Reference: See Sigstore’s documentation on how to implement keyless signing. It’s the gold standard for modern integrity.

The Bottom Line for Security Leaders:

Security in 2026 isn't about having zero vulnerabilities, that’s a fantasy. It’s about transparency and integrity. If you are a security professional, your job isn't to find more bugs. Your job is to provide enough context so that your team only spend time on the risks that actually matter. Stop drowning your team in "Critical" lists. Start focusing on what’s reachable, verifiable and authentic.

Unpacking Application Security: A Comprehensive Threat Modeling Guide

Tilak Upadhyay — Mon, 06 Oct 2025 11:39:51 +0000

In the fast-paced world of software development, building features quickly often takes precedence. However, neglecting security early in the development lifecycle can lead to significant technical debt, costly breaches, and reputational damage down the line. This is where Threat Modeling shines. It's not just a buzzword; it's a proactive, structured approach to identifying potential security weaknesses in your application before they become exploitable vulnerabilities.

It’s crucial to understand that threat modeling isn't a rigid, one-size-fits-all process. Different individuals, teams, or organizations may approach threat modeling with varying methodologies, tools, and perspectives based on their unique knowledge, risk appetite, and operational context. The walkthrough presented here represents one effective way to conduct a thorough threat model, but it's important to remember that other valid and insightful approaches exist. The core objective remains the same: to systematically think like an attacker to build a stronger defense.

Let's embark on a practical, end-to-end journey through a threat modeling exercise for a realistic application.

The Scenario: "PlexiDocs" - A Secure Document Collaboration Platform

To make this practical, imagine we are the architects behind PlexiDocs, a new cloud-based web application. PlexiDocs is designed for small to medium-sized businesses to securely store, share, and collaborate on highly sensitive documents such as legal contracts, financial reports, and HR records. The emphasis is on strong security and ease of collaboration.

Core Features of PlexiDocs:

User Roles & Access Control: The platform distinguishes between two primary user types: Admins (who can manage users, billing, and all documents) and Members (who can manage documents they own or are shared with them). Both can upload, view, edit, and delete documents within their permissions.
Document Management: Users can upload various document types (PDFs, DOCX, XLSX). For each document uploaded, the application automatically generates a small thumbnail preview to enhance user experience. Documents can be organized into a hierarchical folder structure.
Secure Collaboration: Users have the ability to share a specific document with external parties (individuals who are not PlexiDocs users). This is done by generating a unique, hard-to-guess "secret" link. Anyone possessing this link can view the document, but cannot edit or download it directly without further authentication.
User Authentication & Recovery: Users log in with a standard username and password. A "Forgot Password" feature is also implemented, which sends a password reset link to the user's registered email address.

Technical Architecture of PlexiDocs:

Frontend: A modern Single-Page Application (SPA) built using a popular JavaScript framework (e.g., React, Angular, Vue.js). This runs entirely in the user's web browser and communicates with the backend via APIs.
Backend API: A RESTful API layer (e.g., built with Node.js, Python/Django, Java/Spring Boot) that serves as the central brain of the application. It handles all business logic, user authentication requests, authorization checks, and orchestrates interactions with databases and file storage.
Database: A relational SQL database (e.g., PostgreSQL, MySQL) serves two primary functions:
- Stores user information, including hashed passwords, user roles, and profile details.
- Stores document metadata, such as file names, sizes, creation dates, owner IDs, folder paths, and access control lists (ACLs) for shared documents.
File Storage: An object storage service (e.g., Amazon S3, Google Cloud Storage) is used to store the actual, raw document files uploaded by users. The backend API generates temporary, pre-signed URLs, allowing the frontend to directly upload/download files to/from the object storage, which improves performance and reduces backend load.
Thumbnail Service: This is a separate, dedicated microservice. When a new document is uploaded and processed by the Backend API, a notification is sent to this service. It then securely retrieves the document from the file storage, processes it to generate a thumbnail image (e.g., a JPEG or PNG preview), and saves this thumbnail back into the file storage, updating the document metadata.

With a clear understanding of PlexiDocs, its features, and its underlying technology, we can now commence our security analysis. Let's put on our security hats and walk through the classic four-step threat modeling process.

Step 1: Decompose the Application (What Are We Building?)

The foundational step in threat modeling is to thoroughly understand the system we are trying to secure. We cannot identify vulnerabilities in something we don't fully comprehend. Application decomposition involves breaking down the application into its constituent parts and mapping out how data flows between them. The most effective tool for this is a Data Flow Diagram (DFD).

A DFD provides a visual representation using simple, standardized symbols:

External Entities (Rectangles): Users or external systems that interact with our application but are outside its direct control.
Processes (Circles): Components that transform or handle data within our application.
Data Stores (Parallel Lines): Places where data resides persistently.
Data Flows (Arrows): The paths that data takes between entities, processes, and stores.
Trust Boundaries (Dotted Lines): Crucially, these delineate areas with different levels of trust. Crossing a trust boundary is often where attackers look for weaknesses.

Here’s the DFD for PlexiDocs, outlining these components and their interactions:

Understanding Key Data Flows:

User Authentication:
- The User (E1) initiates a login, sending DF1: User Credentials to the Authentication Service (P1).
- P1 verifies these credentials against D1: User Database.
- Upon successful login, P1 issues DF2: Session Token back to the User's browser, enabling subsequent authenticated requests.
Document Upload:
- A logged-in User (E1) sends DF3: Document Upload Request to the Document Management Service (P2).
- P2 interacts with D2: Document Metadata Database to record initial metadata.
- P2 then generates DF4: Signed URL for Upload/Download and sends it back to the User.
- The User's browser uses this signed URL to directly upload the file to D3: File Storage.
Thumbnail Generation:
- After a successful document upload, P2: Document Management Service sends DF8: New File Notification to P4: Thumbnail Generation Service.
- P4 then performs DF9: File Download for Processing from D3: File Storage, generates the thumbnail, and executes DF10: Thumbnail Upload back to D3.
- Optionally, P4 might update D2: Document Metadata Database with details about the new thumbnail.

Trust Boundaries are Critical:
Observe the dotted lines. The Internet <-> Application Boundary is the most significant, separating our controlled environment from the untrusted public internet. We also have an Internal Service Boundary encapsulating the Thumbnail Generation Service, indicating that this service is potentially isolated and might operate with different trust assumptions or permissions. Any interaction that crosses these boundaries demands heightened security scrutiny.

Step 2: Identify Threats (What Can Go Wrong?)

With our DFD clearly illustrating the system's architecture and data flows, we can now systematically brainstorm potential security vulnerabilities. This is where we shift our mindset to think like an adversary. A highly effective and widely adopted framework for this is STRIDE, a mnemonic for six primary categories of threats, developed by Microsoft. We apply STRIDE to each element of our DFD (External Entities, Processes, Data Stores, Data Flows).

Spoofing: Pretending to be someone or something you're not. (e.g., impersonating a user or a trusted service)
Tampering: Modifying data or code. (e.g., altering a document, changing a user's role)
Repudiation: Denying that an action took place. (e.g., a user denying they deleted a file, lacking proof)
Information Disclosure: Exposing information to unauthorized individuals. (e.g., sensitive data leaks, viewing private documents)
Denial of Service (DoS): Making a system or resource unavailable to legitimate users. (e.g., flooding a server, resource exhaustion)
Elevation of Privilege: Gaining capabilities or access beyond what one is authorized for. (e.g., a 'Member' acting as an 'Admin')

Let's apply STRIDE to several key components of PlexiDocs to build a list of potential threats:

Category	Component / Data Flow	Threat Description
Information Disclosure	Data Flow: User Credentials	(Threat #1) Credentials are sent over an unencrypted channel (HTTP), allowing a Man-in-the-Middle attacker to intercept and steal the password.
Elevation of Privilege	Process: Document Mgmt Service	(Threat #2) An authenticated `Member` user modifies the document ID in an API call (e.g., `/api/docs/123` to `/api/docs/124`), bypassing authorization and accessing another user's document (Insecure Direct Object Reference - IDOR).
Repudiation	Process: Authentication Service	(Threat #3) An `Admin` user performs a sensitive action (e.g., deleting another user account) and later denies having done so. The system lacks robust, immutable audit logging for such critical actions to provide non-repudiable proof.
Denial of Service	Process: Thumbnail Service	(Threat #4) An attacker uploads a computationally intensive file (e.g., a "zip bomb" or a massive image file) designed to exhaust the CPU and memory of the `Thumbnail Service`, preventing it from processing legitimate documents.
Information Disclosure	Process: Link Sharing Service	(Threat #5) The "secret" links generated for external sharing use predictable or sequential identifiers, allowing an attacker to enumerate URLs and discover links to other private documents.
Spoofing	Process: Thumbnail Service	(Threat #6) The `Thumbnail Service` can be tricked into downloading a file from an arbitrary URL supplied by an attacker instead of from the internal file storage (Server-Side Request Forgery - SSRF), allowing the attacker to scan the internal network.
Tampering	Data Store: User Database	(Threat #7) An attacker with SQL injection or direct database access modifies a user's role in the database from `Member` to `Admin`, gaining full administrative control.

Step 3: Rate the Threats (What Do We Fix First?)

After identifying a multitude of potential threats, we face a critical challenge: we can't fix everything at once. Resources (time, budget, personnel) are always limited. Therefore, we must prioritize the threats based on their potential impact and likelihood of occurrence. A widely used model for this is DREAD, which provides a quantitative way to assess and compare risks.

From our list generated in Step 2, let's select two distinct and highly illustrative threats to analyze and prioritize:

Threat #1: Information Disclosure due to no HTTPS.
Threat #3: Repudiation due to no audit logs.

DREAD evaluates each threat across five dimensions, typically on a scale of 1 (low) to 10 (high):

Damage Potential: How bad would it be if this threat were successfully exploited? (e.g., minor data loss vs. full system compromise)
Reproducibility: How easy is it for an attacker to reliably reproduce the conditions necessary for the attack? (e.g., requires specific timing vs. happens every time)
Exploitability: How much skill or effort is required to perform the attack? (e.g., expert hacker vs. script kiddie with automated tools)
Affected Users: How many users would be impacted by a successful exploit? (e.g., a single user vs. the entire user base)
Discoverability: How easy is it for an attacker to find this vulnerability or weakness? (e.g., hidden deep in code vs. immediately visible)

The total DREAD score is typically the average of these five ratings, with a higher score indicating a more critical threat requiring immediate attention.

Threat Analysis 1: Information Disclosure due to no HTTPS (Threat #1)

This threat describes a scenario where an attacker intercepts user credentials because the login or application pages are served over unencrypted HTTP, allowing for easy snooping of sensitive data over a public network.

Damage Potential (D): 8
- Justification: A successful MITM attack on an HTTP login page leads directly to credential compromise, which can result in full account takeover. This gives the attacker access to all of the user's documents and potentially other sensitive functions. This is a severe, high-impact outcome.
Reproducibility (R): 9
- Justification: If a site serves content over HTTP (especially a login form), an attacker on the same local network (e.g., public Wi-Fi) can reliably intercept traffic. Tools for setting up such attacks are common and effective, making this highly reproducible.
Exploitability (E): 7
- Justification: While not a one-click exploit, there are numerous readily available tools (like Wireshark, MITMproxy, SSLStrip) and public guides that significantly lower the bar for executing this type of attack. It doesn't require advanced zero-day expertise.
Affected Users (A): 3
- Justification: This attack typically targets users on a specific compromised network segment or in a particular physical location. While not impacting all users globally, it can impact any user connected to that network, potentially affecting a significant portion of a small business's workforce using a shared office network.
Discoverability (D): 10
- Justification: The absence of HTTPS is trivially discoverable. Any user or attacker simply needs to look at the URL bar in their browser (which displays "Not Secure" or lacks the padlock icon). Automated scanners also flag this immediately. It requires no special effort to find.

Threat #1 - Average Risk Score: (8+9+7+3+10) / 5 = 7.4 (High Priority)

Threat Analysis 2: Repudiation due to no audit logs (Threat #3)

This threat describes a situation where an Admin user performs a critical action (like deleting sensitive documents or user accounts) and later falsely claims they did not perform the action, and the system lacks the necessary immutable audit trails to prove otherwise.

Damage Potential (D): 8
- Justification: The business impact can be severe. Losing the ability to prove who performed a critical action can lead to legal disputes, regulatory non-compliance, financial penalties, internal mistrust, and inability to perform forensic investigations.
Reproducibility (R): 9
- Justification: If the audit logging mechanism for specific actions is non-existent or easily tampered with, an attacker (or rogue insider) can perform the action and deny it 100% of the time. The lack of a log is a consistent flaw.
Exploitability (E): 2
- Justification: This threat requires virtually no technical skill to "exploit." The "attacker" is a legitimate user simply using the application's existing functionality and then lying about it, knowing there's no proof.
Affected Users (A): 5
- Justification: While it might involve a single Admin user's action, the impact often cascades. If a crucial document is deleted without accountability, it can disrupt an entire team, a project, or even the whole business, affecting many indirect users.
Discoverability (D): 2
- Justification: This is a subtle, hidden architectural weakness. It's not something an attacker can "find" by probing the application directly. It's usually discovered only after an incident occurs and an investigation attempts (and fails) to find evidence in logs.

Threat #3 - Average Risk Score: (8+9+2+5+2) / 5 = 5.2 (Medium Priority)

Prioritization Conclusion:
Based on our DREAD analysis, Threat #1 (Information Disclosure due to no HTTPS) emerges as the highest priority with a score of 7.4. While Threat #3 (Repudiation) is also significant, the immediate and widespread exploitability and discoverability of unencrypted communications make Threat #1 a more urgent and easily exploitable risk that must be addressed first.

Step 4: Determine Countermeasures (How Do We Fix It?)

The final step is to design and implement countermeasures (or mitigations) to address the identified and prioritized threats. A robust security strategy emphasizes defense-in-depth, employing multiple layers of controls across different categories: prevention, detection, and response.

Let's focus on our highest-priority threat: Threat #1: Information Disclosure due to no HTTPS.

Strategy	Countermeasure
Prevention	1. Enforce HTTPS Everywhere: This is the most critical and fundamental step. Configure all web servers (frontend and API) to serve only HTTPS traffic. Implement server-side redirects (HTTP Strict Transport Security - HSTS) to automatically forward any HTTP request to its HTTPS equivalent. HSTS specifically instructs browsers to always connect via HTTPS for your domain, even on subsequent visits, preventing downgrade attacks.
Reduce Impact (Resilience)	2. Implement Multi-Factor Authentication (MFA): Even if an attacker somehow manages to steal a username and password (e.g., via phishing, not just MITM), MFA adds a crucial second layer of verification (e.g., a code from an authenticator app, a biometric scan). This significantly raises the bar for an attacker to gain access, drastically reducing the impact of compromised credentials. 3. Utilize Secure and HttpOnly Flags for Cookies: Ensure all session tokens and other sensitive cookies are set with the `Secure` flag (cookies are only sent over HTTPS) and the `HttpOnly` flag (client-side JavaScript cannot access the cookie, mitigating XSS risks).
Detection	4. Implement Robust Logging & Anomaly Detection: Integrate all authentication logs (successful logins, failed attempts, password resets) into a centralized Security Information and Event Management (SIEM) system. Configure alerts for suspicious patterns, such as: - Multiple failed login attempts from a single IP address (brute-force/credential stuffing). - Impossible travel (logins from geographically distant locations in a short timeframe). - Logins from unknown or suspicious IP ranges.
Response	5. Develop a Comprehensive Incident Response (IR) Plan: A detailed IR plan is essential. This plan should clearly outline steps to take upon detection of a credential compromise or MITM attack. This includes: - Immediate invalidation of the compromised session token. - Forcing a password reset for the affected user. - Notifying the user of the potential compromise. - Escalation paths and communication protocols for internal teams and, if necessary, external authorities.

Concluding Thoughts

Threat modeling is a continuous, living process, not a one-time exercise. By integrating it into your development lifecycle, you transform security from a reactive, often panicked, afterthought into a proactive, engineering discipline. This structured approach forces us to challenge our assumptions, anticipate attacker behavior, and build security directly into the design, leading to more resilient, trustworthy, and ultimately successful applications. It saves time, reduces costs, and most importantly, protects your users and your business.

What Other Techniques Can Be Used for Threat Modeling?

While the STRIDE and DREAD frameworks are highly effective and beginner-friendly, the landscape of threat modeling methodologies is rich and diverse. Each offers a slightly different lens through which to view your system's security:

PASTA (Process for Attack Simulation and Threat Analysis): This is a risk-centric, seven-stage methodology that guides you from understanding business objectives and technical scope to simulating attacks and managing identified risks. It's more comprehensive and business-driven than STRIDE.
VAST (Visual, Agile, and Simple Threat modeling): Designed to integrate seamlessly into Agile and DevOps workflows, VAST emphasizes visual diagrams (like DFDs and process flow diagrams) and aims to be understandable by both technical and non-technical stakeholders across the organization.
Trike: A methodology that focuses heavily on defining security requirements, developing threat models, and using them as a security auditing tool. It has a strong emphasis on establishing clear data trustworthiness and authorization rules.
CVSS (Common Vulnerability Scoring System): While not a threat modeling methodology itself, CVSS is the industry standard for rating the severity of discovered vulnerabilities. It provides a standardized, objective framework (metrics for exploitability, impact, environmental factors) that can be used as an alternative or complementary approach to DREAD for prioritizing risks once identified.
Attack Trees: A formal, hierarchical diagramming technique that breaks down a high-level attack goal into more specific sub-goals, which are then broken down further. They help visualize all possible ways an attack could succeed.
Kill Chains (Cyber Kill Chain): Originally developed by Lockheed Martin, this framework describes the stages of a successful cyberattack (reconnaissance, weaponization, delivery, exploitation, installation, command & control, actions on objectives). It's more of an operational security framework but can inform threat modeling by helping visualize attacker progression.

Exploring these various techniques will broaden your threat modeling toolkit and allow you to select the best approach for the specific context of your project.

A 'feature' of AI can become a 'nightmare' for an organisation - Here's how.

Tilak Upadhyay — Fri, 29 Aug 2025 18:48:59 +0000

The developers are living in an exciting time. A whole new generation of AI-powered terminals, code editors and IDE plugins has emerged, promising to supercharge our productivity. They can write boilerplate code, explain complex algorithms and even debug for us. Many of these tools are free and open-source, making them incredibly tempting to install and try out.

But in my role in security operations, I've seen the other side of this magic. I've watched as these "helpful" assistants inadvertently become data exfiltration channels, leaking sensitive company information directly from a developer's machine.

The scary part? The developer is almost always completely unaware it's happening.

This isn't about some malicious malware. The leak is often a core function of the tool itself. Let's break down how this happens and, more importantly, how you can prevent it.

The Core Problem: "Leak is a Feature, Not a Bug"

To give you a smart, context-aware response, an AI model needs one thing above all else: context.

When you ask an AI tool to "explain this function" or "find a command I ran last week" or "help me to fix this error", it doesn't just send your question to a cloud API. It packages up the surrounding "context" to get a better result. And what is that context basically?

It's,

The code in your currently open file.
The code in all your open tabs.
Your terminal command history and the output on your screen.
Sometimes, even file names from your entire project directory.

The process looks like this:

You use an AI feature.
The tool grabs "context" to be helpful.
It sends that entire package to a cloud-based AI service for processing.

If a stray API key, a database password, a piece of customer data or an intellectual property (IP) or even a private key, in that context, it gets sent too.

Your Network DLP lights up (if configured properly) and people like us in security / SOC may get an alert.

Real-World Scenarios I've Seen

These aren't theoretical risks. Based on alerts and logs I've analysed, here are a few anonymised ways these leaks happen, showing you exactly how the data gets packaged and sent (of course by sanitising sensitive data)

Scenario 1: The "Intelligent" Terminal
Many new terminals use AI for natural language command search. To achieve this, they create "embeddings" (vector representations) of your command history. This involves sending the text content of your terminal buffer to their API.

I've seen network traces where the tool makes a POST request to an endpoint like https://api.ai-terminal-app.dev/v1/embeddings. The JSON payload often looks like this, sending a chunk of your recent terminal session directly:

{
   "input_text": "user@host:$ gcloud auth print-access-token\nyour-long-gcp-token-string\nuser@host:$ git push origin feature-branch\nCounting objects: 5, done.\n...",
   "model": "text-embedding-v2"
}

Notice how the output of the gcloud command, which is a temporary but highly sensitive access token, is captured right along with the benign git push command. You didn't copy it; the tool scraped it as part of its routine context gathering.

Scenario 2: The "AI-First" Code Editor
These editors let you "chat with your codebase." When you ask a question like, "How can I optimize this function?", the editor sends your code along with your question to a Large Language Model (LLM).

The API call to an endpoint like https://api.ai-code-editor.com/v2/chat/completions is often structured with a series of messages. The tool programmatically injects your code as part of the context, like so:

{
   "model": "code-gen-pro-4",
   "messages": [
     {
       "role": "system",
       "content": "The user is working with the following file named 'db_connector.py'. Use it as context."
     },
     {
       "role": "user",
       "content": "### Start of file: db_connector.py ###\n\nimport os\n\ndef connect_to_database():\n    # TODO: Move this to a secrets manager later\n    db_password = 'temp_password_for_dev_123!'\n    # ... rest of the connection logic\n\n### End of file ###"
     },
     {
       "role": "user",
       "content": "How can I optimise this function?"
     }
   ]
 }

The developer's innocent TODO comment and hardcoded password become part of the prompt payload sent over the internet, triggering a data leak alert.

Scenario 3: The "Innocent" Code Analyser Extension
This is the most dangerous one. You install a promising AI-powered security linter or code analyzer extension. In the background, it scans your code, perhaps by parsing it into an Abstract Syntax Tree (AST) to understand its structure.

For its own analytics or to report a "finding" back to a security dashboard, the extension might send telemetry about what it discovers. If it finds a hardcoded secret, its report can include the secret itself as part of the "evidence." The outbound JSON to a diagnostics service could look like this:

{
   "event_type": "code_analysis_finding",
   "file_hash": "e4f5g6h7...",
   "linter_rule": "HardcodedPrivateKey",
   "severity": "critical",
   "code_snippet": "private_key_pem = \"-----BEGIN EC PRIVATE KEY-----\\nMI...H6g==\\n-----END EC PRIVATE KEY-----\"",
   "extension_version": "1.4.1"
 }

The extension's feature of finding a hardcoded private key is genuinely useful. However, in the process of reporting this finding, it exfiltrates the actual key to a third-party server. This instantly turns a local security vulnerability into an active, critical data breach.

A Quick Note on Free v/s Enterprise AI
It's important to distinguish these free tools from enterprise-grade, subscription-based AI services like GitHub Copilot for Business, Google's Gemini for Workspace or Azure OpenAI services. Free tools often use your data to train their models—your data is the price you pay.

Enterprise services, on the other hand, operate under strict data privacy contracts. They typically offer zero-data-retention policies, meaning your code is not stored on their servers or used for model training. This is why your company may pay for one service while blocking another.

How to Prevent These Leaks and Code Safely

Remediating a leak is a painful fire drill. Preventing one is a simple habit. Here’s how you can protect yourself and your company.

1.⁠ ⁠Cultivate a "Zero-Trust" Mindset for Tools
Treat every new tool, especially those with cloud-based AI features, as a potential data leak path. Before you install that shiny new editor or extension, read its privacy policy. Understand what data it collects and where it sends it. If it’s not clear, don’t install it.

2.⁠ ⁠Configure Your Tools Defensively
Dive into the settings menu of your tools. Look for and disable any options related to:
"Send anonymous telemetry"
"Help improve our models"
"Enable cloud-based AI suggestions" (if you can live without them)
Opt-out of everything that isn't always essential for the tool's core function.

3.⁠ ⁠Practice Strict Secret Hygiene
The best way to prevent secrets from leaking is to never have them in your code in the first place. Not even for a "quick test".

Use .env files for local development and add them to your .gitignore - (don’t expose them over the internet unless you’re in the mood to speedrun a career change.)
Use a proper secrets manager like HashiCorp Vault, AWS Secrets Manager or Google Secret Manager.
Install pre-commit hooks like Gitleaks or TruffleHog. These tools will scan your code for secrets before you can commit them, stopping a leak before it even begins.

4.⁠ ⁠Vet Your Extensions
Your editor is only as secure as its most permissive extension. Before installing a new one, ask:

Who is the publisher? Is it a reputable company or a random, unknown individual?
What are the reviews? Do other developers mention privacy concerns?
Can I do this without an extension? Sometimes, a simple script is safer than a black-box extension.

5.⁠ ⁠Advocate for Safe, Company-Approved AI
If you need AI tools to do your job effectively, talk to your IT and Security teams. They can procure enterprise-grade tools that come with the security and privacy guarantees your organisation needs. It’s better to use a sanctioned tool than to download a free one that puts everyone at risk.

Final Thoughts

AI developer tools are a massive leap forward for productivity, but we can't afford to be naive about how they work. By being mindful of the data we expose to them and adopting a few key security habits, we can embrace the benefits of AI without creating a nightmare for our organisations.

Stay safe and code secure.

SOC Analysts: How to Future-Proof Your Career in the Age of AI

Tilak Upadhyay — Fri, 22 Aug 2025 07:32:08 +0000

If you work in a SOC, you already know how it feels: alert fatigue, endless investigations and constant pressure to respond fast. Burnout is common. And when burnout hits, the SOC loses its quality, leading to gaps in defense and even compromising the very purpose of having a SOC in place.

But with AI, the burning issue of burnout can finally be addressed. Industries are bringing AI/LLMs into SOCs to bring more outcome, consistency and speed. In near future, AI will start handling triage, low level investigation, enrichment and even communication/followups.

This is great for organizations. But for analysts, it’s a sign: if you want to grow in your career and stay relevant, you must evolve.

Here’s how growth looks at different stages of a SOC career.

1. For Junior SOC Analysts: Skill Upgrade

If you’re starting out, your focus should be on expanding your technical depth beyond the traditional endpoint & network level threat investigation. That knowledge is valuable, but not enough anymore.

Invest in building these skills:

Cloud Security (CNAPP, CWPP alerts): Get comfortable with triaging and investigating Cloud security alerts. These include issues such as exposed storage buckets, overly permissive IAM roles, vulnerable workloads running in containers/VMs, misconfigured security groups or unencrypted data in transit/at rest. Understanding these alerts helps you see how misconfigurations and workload risks translate into real attack paths in the cloud.
Docker and container security (Kubernetes included): Learn how insecure container configs, weak isolation or exposed ports can lead to compromise. Junior analysts should learn how investigate and respond to such threats.
API security and identity/authorization (IAM): Understand how weak authentication, over-permissive roles or exposed endpoints create easy entry points for attackers.
Web and application-based threat investigation: Spot anomalies at the application layer, like injection attempts, credential abuse or suspicious traffic.
CI/CD pipeline security: Developers may hardcode secrets, QA may skip security validation and DevOps could push insecure builds. Analysts should learn how to detect and investigate these pipeline missteps.
Application/code-level issues (DAST/SAST & ASM alerts): Be comfortable reading and validating findings from security scans, such as insecure dependencies, improper input validation or weak cryptography.

Building these skills ensures you can investigate threats across modern attack surfaces — not just servers and workstations.

2. For Mid-Level SOC Analysts: Thinking Beyond the Box

At the mid-level, it’s time to move past pure investigation. You should start building the SOC’s capabilities and thinking in systems.

Log visibility and parsing: Ensure all required logs reach the SIEM and are parsed/enriched properly.
Detection engineering: Create new detection use cases, tune noisy ones and map alerts to adversary behaviors (MITRE ATT&CK).
Alert quality: Develop meaningful alerts that balance sensitivity (catching real threats) with efficiency (avoiding false positives).
Runbooks and workflows: Build clear incident runbooks so investigations can be handled consistently, especially by junior analysts.
Coverage validation: Check all the possible corners of cloud and on-prem environments are fully monitored.

This is the transition from alert responder to SOC builder. You’re shaping how the SOC detects and responds to threats.

3. For Senior/Lead SOC Analysts: Shaping Security Posture

At the senior level, your focus shifts toward strategy and posture. You’re not only fighting fires — you’re designing the fire prevention system.

Understand SOC maturity: Know exactly where your SOC stands today in detection capability, coverage, and response readiness.
Identify blind spots: Examples include unmanaged endpoints, SaaS apps without logs, cloud misconfigurations (like open storage buckets), or shadow IT systems.
Drive posture improvements: Champion the onboarding of new log sources, EDR tools, or advanced correlation. Push for automation that reduce response time and increase visibility.
Threat-informed defense: Align SOC detections with adversary behaviors. Ask: “If an attacker used technique X, would we catch it?”
Resilience planning: Ensure the SOC can respond quickly, contain threats effectively and prevent repeat incidents.
Business alignment: Translate technical weaknesses into business risks leadership understands, ensuring security investments get prioritized.

Senior and lead analysts are not just responders — they are strategists who ensure the SOC evolves with the threat landscape.

Final Thought

AI will soon taking over repetitive triage and investigation tasks. That’s good for SOC efficiency — but for analysts, it’s a career checkpoint.

Juniors: focus on building skills in modern environments.
Mid-levels: think beyond alerts and become detection engineers.
Seniors/Leaders: design, influence and strengthen the organization’s overall security posture.

The SOC of the future won’t just investigate incidents — it will engineer detections, understand systems deeply and drive security at scale.

The question is: are you growing with it?

🛡️ India’s Quantum Cybersecurity Leap: IIT Delhi & DRDO Demonstrate Unhackable Communication

Tilak Upadhyay — Tue, 24 Jun 2025 12:31:23 +0000

In a world where even the strongest encryption could one day be cracked by quantum computers, India just took a giant leap toward future-proof cybersecurity.

In a landmark demonstration, IIT Delhi and the DRDO successfully achieved Quantum Secure Communication over a 1 km open-air distance — using the bizarre yet beautiful principles of quantum physics.

📢 Official PIB Press Release

🧠 What Is Quantum Secure Communication (QSC)?

Quantum Secure Communication is a method of transmitting data in a way that’s inherently protected by the laws of physics — not just by algorithms or software.

The core of this lies in Quantum Key Distribution (QKD). Here's how it works:

Communication keys are generated using entangled photons — tiny particles of light linked in such a way that their states are perfectly correlated.
Any attempt to intercept or observe these photons disturbs their state — thanks to the Heisenberg Uncertainty Principle.
This disturbance acts as a built-in alarm: if anyone tries to snoop, the system detects it instantly and can discard the compromised key.

In simple terms: you can't spy on a quantum key without being caught — because physics won’t allow it.

🧪 What Did IIT Delhi & DRDO Demonstrate?

✅ Established a 1.0 km free-space QKD link using entangled photons (no fiber optics, just open air).
✅ Achieved a secure key rate of ~240 bits/second — enough for real-time encryption.
✅ Maintained Quantum Bit Error Rate (QBER) < 7%, within secure thresholds.

This proves that reliable quantum key exchange is possible even without physical cables, laying the groundwork for secure communication in battlefield conditions, remote areas and even space.

🛡️ Why This Matters for Cybersecurity

The Challenge:

Current encryption (RSA, ECC, AES) relies on mathematical problems. But quantum computers could break these within minutes in the near future.

The Solution:

Quantum Secure Communication uses physics itself to ensure data security.

🔓 Traditional Encryption	🔐 Quantum Encryption
Based on math problems	Based on physics
Can be cracked eventually	Cannot be cracked
No built-in tamper alert	Detects any tampering instantly

This breakthrough is a game-changer for:

🛡️ Nation-state cyber defense
🔍 Insider threat detection
🔐 Securing future-proof data infrastructure

🧰 Cybersecurity Use Cases Across Sectors

🏛️ Government & Military

Secure battlefield and border communications
Tamper-proof inter-agency collaboration
Quantum-safe national intelligence systems

🏦 Finance & Infrastructure

Quantum-resilient banking transactions
Protection of national stock exchanges and telecom hubs
Secure SCADA & smart city systems

🧪 Enterprise & R&D

Protecting sensitive research and intellectual property
Securing healthcare data and genomic information
Future-ready data centers and cloud environments

🌌 How Physics Makes It Secure – Simplified

Here’s how quantum mechanics secures communication:

🧪 Quantum Principle	🔍 What It Does	🛡️ Cybersecurity Benefit
Heisenberg Uncertainty	Observing a quantum particle disturbs it	Any spying attempt is instantly detected
Quantum Entanglement	Two particles share a state even when apart	Perfectly synced encryption keys
No-Cloning Theorem	Quantum states can't be copied	Keys can't be intercepted or duplicated

Unlike classical encryption, this doesn’t rely on secrets staying hidden, but on the unbreakable laws of nature.

🇮🇳 The Bigger Vision – Quantum India

India’s quantum journey is only accelerating:

🚀 ₹6000 Cr National Quantum Mission aims to build a quantum communication network across the country.
🛰️ Plans for satellite-based QKD links spanning 2000+ km.
🏢 Deployment of quantum nodes in defense, government, research and financial sectors.

With this demo, India joins the elite group of nations building quantum-secure internet backbones.

🔐 TL;DR – Why It Matters

✅ Demonstrated secure, cable-free quantum communication
✅ Communication protected by laws of physics, not just software
✅ Step toward quantum internet and national cyber defense
✅ Built for a post-quantum world — one where today's encryption may no longer protect us

💬 Final Thoughts

This isn't just a lab success — it's a national cybersecurity milestone.

By combining deep physics with cutting-edge technology, India is building a cyber defense strategy that's not just secure for today — but resilient for the future.

If you're in cybersecurity, policy, defense or tech, this is your cue:

Start learning quantum — the future of secure communication is already being built.

✨ Follow for more insights on quantum tech, cybersecurity and India's digital future!

💬 Got questions or thoughts? Drop them in the comments!

QuantumComputing #Cybersecurity #QuantumSecurity #QKD #IITDelhi #DRDO #DigitalIndia #Innovation #Physics #PostQuantumSecurity #QuantumTech #NationalSecurity #India

Security Operations in 2025: Global Demands, Real Gaps & The Way Forward

Tilak Upadhyay — Sat, 21 Jun 2025 12:11:56 +0000

In the ever-evolving threat landscape of 2025, Security Operations Centers (SOCs) are more important than ever—but many are still operating on outdated models.

While technology evolves rapidly, most SOCs are struggling with a very human problem: misalignment between expectations, investments and operations.

This blog dives deep into:

🌍 What global enterprises expect from modern SOCs
❌ Where SOC teams and management are falling short
🔧 How to bridge the gap across technical, managerial and monetary levels

🌍 What Modern SOCs Are Expected to Deliver

The days of simple log monitoring are long gone.

Here’s what global organizations now expect from a modern SOC:

✅ Cloud-native detection and response (AWS, Azure, GCP)

✅ Proactive threat hunting, not just reactive alerts

✅ SOAR-enabled automation and MITRE ATT&CK-driven playbooks

✅ Unified telemetry from endpoints, networks, identities and third-party sources

✅ Support for hybrid work and BYOD environments

✅ Compliance-aware operations (e.g., ISO, NIST CSF, PCI-DSS, GDPR)

✅ Real-time threat intelligence ingestion and response

✅ Business-aligned impact analysis and reporting

These are non-negotiables in 2025.

❌ Where SOC Teams and Leadership Are Falling Short

Despite this shift, many SOCs still lag behind. Here’s where they’re struggling:

🧑‍💼 Managerial Gaps

Focused on alert counts instead of business impact and MTTD/MTTR
No structured escalation paths involving non-technical stakeholders
Playbooks are either too generic or non-existent
Hiring junior analysts only, ignoring senior detection engineers and threat hunters

💸 Monetary Gaps

Overpaying for tools, underpaying for skilled talent
Security controls and tools are underutilized despite full licensing
Training and red-teaming seen as "optional"
Budgets not aligned with actual attack surface

🛠️ Technical Gaps

Lack of understanding of modern threat landscapes (e.g., cloud-specific attacks, identity-based threats)
Poor cloud and application telemetry visibility and correlation
Ingesting logs without context (asset criticality, business function)
No automation for common triage tasks (e.g., phishing, IOC enrichment)
No use of Detection-as-Code, CI/CD, or version control

🔧 How to Bridge the Gap (Realistically)

🧭 Managerial: Run the SOC Like a Business Unit

Focus KPIs on MTTD/MTTR and impact reduction
Simulate not just tech drills, but business-impact cyber crises
Encourage cross-skilling between SOC, CloudSec, Compliance and AppSec teams
Use MITRE ATT&CK to drive both detection and executive reporting

💰 Monetary: Spend Smarter, Not Bigger

Review underutilized licenses and reallocate funds to skills and engineering
Invest in purple teaming, detection logic development, and training labs
Choose tools that integrate well, offer real ROI and reduce alert fatigue
Consolidate tools where possible to reduce overhead

⚙️ Technical: Make Your SOC Adaptive

Automate alert triage, IOC enrichment, and phishing analysis using SOAR
Move to Detection-as-Code with Git, versioning, and automated deployment
Ingest context-rich data—who the user is, what the asset does, how critical it is
Build custom detections aligned with your actual threat landscape

🧠 Final Thoughts: Your SOC Is a Strategy, Not Just a Team

The SOC of the future isn’t defined by flashy UIs or a fancy XDR label.

It’s defined by:

📊 Business alignment
🧠 Threat-informed decision-making
⚙️ Automation where it matters

"The gap between attackers and defenders is not just technical—it's strategic"

If your SOC isn’t adapting, it’s already lagging.

📣 Join the Conversation

Are you seeing similar challenges in your org or region?

How is your team adapting to the growing complexity of threats and tech stacks?

Drop a comment, and let’s build better SOCs—together.

If you found this useful, follow me here on Dev.to for more real-world insights on cybersecurity and security operations.

India Needs Cyber Unity: How Government and Professionals Can Collaborate to Secure Our Digital Borders

Tilak Upadhyay — Fri, 16 May 2025 13:10:19 +0000

🛡️ In light of recent Indo-Pak tensions, cybersecurity is no longer just a tech issue—it’s a national security imperative.

While our soldiers guard the physical borders, India’s digital borders are being probed every day by nation-state actors, hacktivists, and opportunistic threat groups.

🧠 Key Insight:

India’s cybersecurity strategy cannot rely on isolated defense. We need collaboration between the government and cybersecurity professionals.

🇮🇳 The Reality of India’s Cyber Exposure

From Aadhaar-linked services to cloud-hosted citizen data and internal gov communications—India's digital infrastructure is massive.

During times of geopolitical tension, we see a surge in:

🕵️‍♂️ Website defacements
🌐 DDoS attacks on public portals
🧬 Phishing against officials
🎯 Propaganda via social media

To tackle this, we need more than 'firewalls'. We need strategy, skill and structured partnerships.

🤝 How the Indian Government Can Collaborate with Cybersecurity Professionals

Here are 5 actionable B2G (Business-to-Government) and P2G (Professional-to-Government) partnership models:

1️⃣ Create a National Cybersecurity Reserve (NCR)

Like a digital army reserve.

Vetted cybersecurity experts from the private sector
Mobilized during national-level cyber incidents
Periodic training + structured response readiness

2️⃣ Launch Public Bug Bounty Programs for Government Platforms

Proactive security over reactive firefighting.

Incentivize ethical hackers to find and report bugs
Rewards, recognition or government certifications
Encourage trust, transparency and improvement

3️⃣ Formalize B2G Cybersecurity Alliances

Let’s build stronger cyber bridges between CERT-IN, NIC, and private SOCs — While some collaboration exists today, it still lacks the depth and structure needed to meet modern threats.

Sign MoUs with security firms
Enable real-time threat intel sharing
Leverage tooling like CNAPP, CTEM, CSPM, etc.
Modernize the government’s detection and response framework

4️⃣ Collaborate on Open Threat Intelligence Platforms

Community-powered defense is scalable and fast.

Contribute to platforms like MISP, OpenCTI or Indian CTI hubs
Enrich CERT-IN advisories with field-level visibility
Foster a collaborative early warning system

5️⃣ Promote Indigenous Development of Cybersecurity Tools

Reduce dependency. Increase capability.

Support Indian devs, researchers, and startups building:
- CNAPP (Cloud-Native Application Protection)
- CSPM (Cloud Security Posture Management)
- CTEM (Continuous Threat Exposure Management)
Provide funding, test environments and early adoption opportunities

📢 Final Word: Cyber Unity is National Unity

India is digitizing fast—but that comes with cyber risks. Cybersecurity should not remain a siloed government operation.

We must build a united cyber defense model — powered by trust, collaboration and shared responsibility.

🇮🇳 Let’s bring policymakers and professionals to the same table.

Let’s defend our digital borders — together.

✌️ Stay sharp. Stay secure.

Follow me for more posts on Cybersecurity, SOC and real-world defense.

Why Cloud Security Knowledge is No Longer Optional for SOC Analysts 🛡️☁️

Tilak Upadhyay — Sun, 20 Apr 2025 17:28:27 +0000

The cybersecurity landscape is evolving rapidly—and so must we.

As someone actively working in a Security Operations Center (SOC), I recently went through a hiring phase where I interacted with several candidates ranging from entry-level analysts to experienced seniors. One thing stood out starkly: a significant gap in cloud security knowledge.

🔍 What I Observed During the Hiring Process

Most of the candidates I interviewed had strong exposure to Microsoft Defender product suites or AWS GuardDuty. While these are undoubtedly powerful tools, depending solely on them is definitely not enough.

The reality is: cyber threats are no longer confined to on-premises environments. Organizations are migrating their workloads to cloud platforms like AWS, Azure, and GCP at an unprecedented rate. But sadly, many SOC professionals are still stuck with a legacy mindset and tooling.

This gap becomes a serious concern when incidents arise in cloud-native environments and the analysts are unsure how to investigate or even detect them effectively.

☁️ Why Cloud Security Skills Are Essential in Modern SOCs

1. Cloud is the New Normal

Most companies are running hybrid or fully cloud-native environments. SOCs must monitor cloud activity with the same rigor as on-prem systems.

2. Cloud Threats Are Unique

Threat actors are adapting fast to cloud environments, and traditional detection methods are falling short. Unique challenges in cloud include:

Misconfigured storage buckets exposing sensitive data to the internet.
Over-permissive IAM roles leading to privilege escalation.
Serverless function abuse (e.g., AWS Lambda) for data exfiltration or persistence.
Abuse of metadata APIs within cloud instances to extract credentials.
Container escape attacks via misconfigured Docker/Kubernetes environments.
Cross-account access abuse via trust relationships.
Shadow IT—untracked workloads or services running in cloud environments without proper visibility.
Multi-cloud complexity—organizations often use multiple cloud providers, each with different logging formats, threat surfaces and controls.

3. Cloud Logs ≠ Traditional Logs

SOC analysts need to become fluent in logs from:

AWS: CloudTrail, Config, CloudWatch, VPC Flow Logs
Azure: Activity Logs, Defender for Cloud, Sentinel, Log Analytics
GCP: Audit Logs, VPC Flow Logs, Security Command Center

4. Tooling Isn’t Enough

Relying only on GuardDuty or Defender alerts is dangerous. Analysts must:

Correlate multiple cloud-native logs
Understand cloud behavior and threat models
Write and test their own detection rules
Perform forensic investigations in cloud environments

🔧 The Growing Role of CSPM, CTEM, CNAPP, and Other Cloud Security Tools

Cloud security is not just about logs and alerts—it’s also about visibility, misconfiguration detection, and proactive risk management. Here's why SOC teams need to be aware of tools like:

CSPM (Cloud Security Posture Management): Tools like AWS Security Hub, Azure Security Center, Wiz, Prisma Cloud
CTEM (Continuous Threat Exposure Management): Prioritizes exposure based on real-time threat intelligence and business context
CNAPP (Cloud-Native Application Protection Platform): Combines CSPM, CWPP, CIEM, and more to give a full-stack view
CWPP (Cloud Workload Protection Platform): Offers runtime protection for VMs, containers and serverless
CIEM (Cloud Infrastructure Entitlement Management): Manages and secures cloud identities and permissions

🐳 The Rising Need for Container Security

SOC teams must also upskill in container security, especially with the growing adoption of Kubernetes and Docker-based microservices. Key focus areas:

Image vulnerabilities (pre-deployment scanning)
Runtime behavior monitoring
Kubernetes misconfiguration detection
Container-to-container communication visibility

Essential tools include Aqua Security, Sysdig, Falco, Twistlock, and Kube-bench.

📚 What SOC Analysts Should Learn to Stay Relevant

If you're a SOC analyst (or planning to become one), here’s what you should focus on:

Cloud Fundamentals: IAM, networking, compute, and storage in AWS/Azure/GCP
Logging and Monitoring: Cloud-native logs and centralization techniques
Detection Engineering: Use Sigma, KQL, custom queries in SIEMs
Proactive Security: Hands-on with CSPM, CNAPP, and CTEM tools
Cloud IR and Forensics: Investigate breaches in dynamic, ephemeral environments
Container Security: Understand images, orchestrators, runtime threats

💡 Final Thoughts: Adapt or Fall Behind

Cloud isn’t just a trend—it’s a foundational shift in how infrastructure is built, deployed, and attacked. If you're a SOC analyst and haven’t explored the cloud security domain yet, now is the time.

Whether you're a beginner or seasoned professional, cloud security expertise is quickly becoming a baseline, not a bonus.

✋ Are you seeing the same skill gaps in your SOC teams or during hiring?

Let's start a discussion in the comments below!

Feel free to connect—I’d love to hear your thoughts and experiences.

Credential Dumping: NTDS.dit Dump Detection

Tilak Upadhyay — Wed, 06 Nov 2024 09:14:22 +0000

Introduction

In the first two parts of this series, we explored credential dumping techniques involving NTLM hash extraction and LSASS memory dumps. In this third part, we'll focus on the detection of NTDS.dit dumps—a critical component of Active Directory that stores all domain data, including user credentials.

Understanding NTDS.dit and Its Significance

The NTDS.dit file is the Active Directory database that resides on domain controllers, containing information about user accounts, groups, and password hashes. Attackers target this file to extract credential data, enabling unauthorized access and lateral movement within a network.

Common Techniques for Dumping NTDS.dit

Attackers employ various methods to extract the NTDS.dit file:

1. Volume Shadow Copy Service (VSS)

Attackers use tools like vssadmin or ntdsutil to create shadow copies of the volume containing NTDS.dit, bypassing file locks.

2. Built-in Utilities

Tools such as ntdsutil can be misused to create backups of the NTDS.dit file.

3. Direct File Access

With sufficient privileges, attackers might attempt to directly copy the NTDS.dit file from its default location:

%SystemRoot%\NTDS\Ntds.dit

Detection Strategies

To identify potential NTDS.dit dumping activities, consider the following detection methods:

1. Monitor Command Execution

Command-Line Analysis

Detect the use of commands associated with shadow copy creation and NTDS.dit access. For example:

vssadmin create shadow
ntdsutil "ac i ntds" "ifm" "create full"

SIEM Detection Query Example

event_id:4688 AND (command_line:"vssadmin create shadow" OR command_line:"ntdsutil \"ac i ntds\" \"ifm\" \"create full\"")

2. File Access Monitoring

NTDS.dit File Access: Monitor attempts to access or copy the NTDS.dit file, especially from non-standard processes or users.
Shadow Copy Access: Track access to shadow copy directories where NTDS.dit might be extracted.

3. Registry Monitoring

SYSTEM Hive Access: Monitor access to the SYSTEM registry hive, as it's required to decrypt password hashes from NTDS.dit.

4. Anomalous Tool Usage

Penetration Testing Tools: Detect the use of tools like PowerSploit's Invoke-NinjaCopy, which can copy locked files like NTDS.dit.

Mitigation Measures

To reduce the risk of NTDS.dit dumping:

Restrict Administrative Privileges: Limit administrative access on domain controllers to essential personnel only.
Disable Unnecessary Services: If VSS is not required, consider disabling it to prevent its misuse.
Regular Audits: Conduct regular audits of domain controllers for unauthorized shadow copies or backups.
Network Segmentation: Isolate domain controllers in a secure network segment to limit exposure.
Implement File Integrity Monitoring: Use tools to monitor critical files like NTDS.dit for unauthorized access or changes.

Conclusion

Detecting and preventing NTDS.dit dumping is crucial for maintaining the security of an Active Directory environment. By implementing robust monitoring and stringent access controls, organizations can safeguard against unauthorized access to sensitive credential data.

Note: The information provided here is based on current best practices and known attack vectors as of March 2025.

🚀 Follow me for more cybersecurity insights and detection techniques!

Credential Dumping: LSASS Memory Dump Detection

Tilak Upadhyay — Wed, 06 Nov 2024 09:01:09 +0000

What is LSA/LSASS?

LSA (Local Security Authority) is a component of Windows that enforces security policies on a system, managing user logins and maintaining information about all aspects of the system’s security, including logins, authentication and privileges.

LSASS (Local Security Authority Subsystem Service), represented by the process lsass.exe, is the part of LSA that actually runs on the system to enforce these security policies. It is responsible for authenticating users and storing sensitive information such as password hashes and Kerberos tickets in its memory during active sessions. Because LSASS stores credentials and session tokens, it is a common target in attacks aimed at credential theft.

Various Methods for Extracting LSASS Memory

Various techniques, such as using ProcDump, PowerSploit or Mimikatz, enable attackers to extract NTLM hashes from system memory, risking unauthorized access. This article covers each method in detail, including detection techniques and false positive chances.

1. Using ProcDump (Windows Native Utility)

ProcDump is a legitimate Windows utility commonly used for creating process memory dumps. Attackers use it to avoid detection while capturing sensitive data from LSASS memory.

Example Command:

procdump.exe -accepteula -ma lsass.exe lsass.dmp

Detection Query:

SIEM: event_id:4688 AND process_name:"procdump.exe" AND command_line:"lsass.exe"
EDR: command_line contains "procdump.exe" AND command_line contains "lsass.exe"

False Positive Chances:

Medium - Windows administrators can use ProcDump to create an LSASS memory dump for debugging purposes.

2. Using comsvcs.dll (Windows Native DLL)

Attackers can use the comsvcs.dll library to directly dump LSASS memory. This is often seen as a less conspicuous method because it’s a native Windows DLL.

Example Command:

rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).id <Path\to\dump> full

Detection Query:

SIEM: event_id:4688 AND process_name:"rundll32.exe" AND command_line:"comsvcs.dll" AND command_line:"minidump"
EDR: process_name contains "rundll32.exe" AND command_line contains "comsvcs.dll, minidump"

False Positive Chances:

Low - rundll32.exe is a legitimate Windows utility and it's abuse with comsvcs.dll is unusual.

3. Using PowerSploit MiniDump

PowerSploit’s MiniDump function allows attackers to dump LSASS memory through PowerShell. This method can evade detection if PowerShell script-block logging is not enabled. The attacker uses PowerShell to dump LSASS memory with Out-MiniDump.

Example Command:

Get-Process lsass | Out-MiniDump

Detection Query:

SIEM: event_id:4104 AND process_name:"powershell.exe" AND command_line:"Out-MiniDump" (NOTE: PowerShell event logging must be enabled)
EDR: process_name contains "powershell.exe" AND command_line contains "Out-MiniDump"

False Positive Chances:

Low - Usage of Out-MiniDump is very unusual.

4. Using SekurLSA (Mimikatz)

Mimikatz is a tool commonly used for credential dumping. It can dump LSASS memory, extract NTLM hashes, and perform pass-the-hash attacks.

Example Command:

sekurlsa::Minidump lsass.dmp
sekurlsa::logonPasswords
sekurlsa::pth

Detection Query:

EDR: process_name contains "mimikatz.exe" OR command_line contains "sekurlsa::"

False Positive Chances:

Very Low - Almost exclusively used for malicious purposes.

5. Using Windows Credential Editor (WCE)

WCE is another utility capable of extracting live NTLM hashes from a machine.

Example Command:

wce64.exe
wce32.exe

Detection Query:

EDR: process_name contains "wce64.exe" OR process_name contains "wce32.exe" OR process_name contains "wce.exe"

False Positive Chances:

Very Low - Uncommon in legitimate operations.

Credential Dumping: NTLM Hash Dump

Tilak Upadhyay — Wed, 06 Nov 2024 08:21:48 +0000

What is NTLM?

NTLM (NT LAN Manager) is a suite of Microsoft security protocols designed to provide authentication and encryption for users accessing network resources. NTLM was introduced in the early versions of Windows and is now largely considered outdated, yet it remains prevalent in various systems due to compatibility with legacy applications and networks.

Data Stored in NTLM:

NTLM stores crucial credential data in the form of hashes rather than plaintext passwords, enhancing security by preventing exposure of actual passwords. The primary types of data associated with NTLM include:

User Password Hashes: NTLM generates a hash from a user’s password, which is stored in a secure location. When a user attempts to authenticate, the system hashes the input password and compares it to the stored hash.
Challenge/Response Mechanism: NTLM uses a challenge/response mechanism for authentication. When a user logs in, the server sends a challenge to the client. The client then uses its password hash to compute a response, which is sent back to the server for validation.
Session Keys: NTLM can generate session keys during authentication to encrypt communications between the client and server, ensuring confidentiality and integrity of data exchanged during the session.
Security Identifiers (SIDs): NTLM also utilizes SIDs to uniquely identify users and groups within Windows environments, facilitating access control and permissions management.

What is NTLM Credential Dumping?

NTLM Credential dumping is a critical post-exploitation activity where an attacker collects NTLM hashes from a compromised Windows system.

Once attackers extract NTLM hashes, they can use them in pass-the-hash attacks, enabling unauthorized access or lateral movement within a network. This article outlines the methods of NTLM hash extraction, detection strategies and the chances of generating false positives when detecting these activities using SIEM and EDR queries.

NTLM hashes are commonly found in two locations:

1. Non-Domain Controller Systems (e.g., Workstations and Servers): NTLM hashes are primarily stored in the memory of the LSASS (Local Security Authority Subsystem Service) process. This process manages security policies and handles account logins, which makes it a target for credential dumping attacks on individual workstations and servers.

To know more about how an LSASS memory dump can be detected, refer,

Credential Dumping: LSASS Memory Dump Detection

Tilak Upadhyay ・ Nov 6 '24

#cybersecurity #threathunting #credentialdumping

2. Domain Controller Systems: On domain controllers, NTLM hashes are stored within the NTDS.dit file—the Active Directory database file. This file contains hashed credentials for all users in the domain, making it a high-value target for attackers aiming to compromise a network.

For more information on NTDS.dit extraction techniques and detection methods, refer,

Credential Dumping: NTDS.dit Dump Detection

Tilak Upadhyay ・ Nov 6 '24

#cybersecurity #threathunting #credentialdumping