DEV Community: Prem Kumar Santhanam

NTLM vs Kerberos vs LDAP : Best Authentication for E-commerce

Prem Kumar Santhanam — Wed, 23 Sep 2026 14:30:00 +0000

This blog provides an in-depth analysis of three popular authentication methods — NTLM, Kerberos, and LDAP — to recommend an efficient and secure authentication solution for a startup or for people who are starting their careers in cybersecurity.

This analysis aims to identify the best-suited method for protecting user identities and maintaining data integrity in a company environment. The three authentication methods each offer unique strengths and face specific limitations. Each method was evaluated across several dimensions, including usage scenarios, security strengths, limitations, and potential vulnerabilities.

NT LAN Manager (NTLM) Authentication

What It Is

NTLM (NT LAN Manager) is an authentication protocol that was developed by Microsoft and used in Windows-dependent environments. Its function is to somehow restrict access and secure communication in the form of a challenge-response. It employs hash-based rather than sending plaintext passwords, which reduces some risks but does not provide the encryption required for full security.

Purpose

The purpose of NTLM is to verify the identity of users within a network and control access to network resources, providing a basic level of security that restricts unauthorized access. It was designed to support Windows-based networks, offering a protocol that could authenticate users without exposing their passwords during transmission.

How They Work

The server challenges a client trying to authenticate, and the client responds with a hash that corresponds to the password. The NTLM password is encrypted with a one-way hash. The password is first hashed into a binary large object of fixed length, and this binary hash is used for authentication instead of the password. This method of operation reduced the chances of a plain-text password traversing the network, which was considered an improvement in security at that time. NTLM uses a six-step challenge-response mechanism to authenticate users :

Step 1: The user’s device (client) initiates the authentication process by sending an access request to the server.

Step 2: Upon receiving the request, the server creates a random challenge (a numeric value) and sends it back to the client. This challenge is unique for each authentication session, providing a fresh element in each exchange.

Step 3: The client uses the stored password hash to encrypt the received challenge, generating a unique response. The password hash itself is generated by applying a hashing algorithm that the client can use for verification.

Step 4: The client returns the computed response to the server. This response acts as proof of the user’s identity, as it can only be generated correctly with the correct password hash.

Step 5: The server compares the response received from the client to its own computed response, using the stored password hash for that user. If the two responses match, it verifies that the client has the correct password hash, authenticating the user.

Step 6: Once the server confirms the validity of the client’s response, it allows the user access to the requested resources.

Where They Are Used

Essentially, NTLM is supported mainly on Windows OS networks and within the legacy systems themselves to assist in the processes that require the use of older systems. The NTLM authentication method has been discontinued in favor of secure authentication protocols. NTLM is still applicable in certain scenarios:

Intranets and Internal Networks: NTLM is typically used in IT departmental groups when there is little to no need for external access. Because it is so simple to deploy and works with many outdated systems, it is perfect for most places where maintaining older systems is a priority, but protective measures are not a necessity.

Legacy Systems: Most, if not all, companies that utilize an outdated IT architecture still use NTLM authentication to connect their machines operating on an older version of Windows. Where systems have not migrated to Kerberos or other current protocols, NTLM is useful, including in scenarios for small or medium-sized enterprises where migration resources are unavailable.

Implementing on the company network

Implementing NTLM in the company infrastructure would generally be limited due to its security vulnerabilities, such as susceptibility to pass-the-hash attacks and lack of encryption in transit. However, there are a few good cases where NTLM might be used in a supporting role:

Internal Administrative Access: NTLM could be used to control authentication to internal administrative information systems or back office, where employees need operational resources. Such may be appropriate where these systems are in a closed network, isolated from any external threats.

VPN and Remote Worker Access: It uses an offline infrastructure, and hence, we can authenticate remote employees accessing company resources through a VPN by means of NTLM. This is not the best option due to NTLM’s weaknesses; it could be used for a short-term or transitional situation where stronger protocols such as Kerberos cannot be used because of technical limitations or a lack of sufficient resources.

Strengths

Resource Efficiency: The great advantage of NTLM, as stated by its minimal infrastructure requirements, is that many servers, encryption keys, or wide area network alterations do not have to be drawn. For a company with limited technical resources, NTLM offers a flexible user authentication method that does not require such an extensive configuration as for more complicated protocols.

Low Management Overhead: NTLM does not need the centralized management infrastructure that protocols such as Kerberos require. Unlike Kerberos, which is much more complex and involves KDCs, NTLM is a hash-based protocol that simplifies the management of the authentication process and does not require as complex IT staff to manage.

Weaknesses

Lack of Encryption for Data in Transit: NTLM does not provide for the encryption of the challenge-response swap during an authentication process. This absence of encryption puts the user’s password hash and other sensitive information at risk of interception. In this manner, the attackers are able to capture data and seek to abuse it in attacks involving certain manipulation, for example, replay attacks.

Susceptibility to Pass-the-Hash Attacks: In this attack, a hacker captures a hashed password and reuses it to gain unauthorized access, without needing to know or decrypt the actual password. This is possible because NTLM relies heavily on hashes, which can be captured and exploited by attackers with network access.

Common Attacks

Replay Attack

The NTLM system is susceptible to replay attacks due to its absence of encryption or session validation features. A replay attack is when an attacker captures the client-server authentication via a valid handshake and attempts to resend that exchange for malicious gain. The NTLM method does not have any features built into it to mitigate or combat the abuse of identical credentials or information, so whenever a credential is obtained by an attacker, it can always be used to impersonate the real user.

As an example, suppose a malicious individual sitting on the network could take over a valid NTLM authentication session between an employee and the network resource server. This type of attacker is not looking for intervention and can use the same credentials over and over again, enabling them to traverse the internal resources to gain the same permissions as the employee and spark an attack on internal tools such as sensitive order records and customer profiles.

Brute-Force and Dictionary Attacks

Also described as passwords cracking attack is a form of attack whereby hackers aim to achieve the generation of a password by hitting the hash with several iterations of the password or even common password phrases. Attackers have been able to carry out such attacks because the NTLM hashes are considered weak, which makes them easy to crack with today’s computational power.

For Instance, if an attacker gains access to NTLM hash values — such as through a compromised database — they could use a brute-force or dictionary attack to decode weak passwords. By using software that rapidly tests common password combinations against the hash, the attacker could retrieve plaintext passwords from poor hashes.

Kerberos

What It Is

Kerberos is a network authentication system that was created in the 1980s at MIT as its first implementation, and technologies and techniques have undergone progressive advancement in the current era. It was specifically created to minimize credential leakage during communication and ensure trust relationships between users and servers. The primary function of Kerberos is issuing ‘tickets’ to users and servers as authentic login qualifiers for virtually all secure transactions through a Key Distribution Center (KDC), which transaction takes place via server authentication and encryption.

How They Work

The entire process revolves around the Key Distribution Center (KDC), which acts as the trusted authority for issuing authentication tickets. This process is divided into two main stages:

Initial Authentication and Ticket Granting Ticket (TGT) Issuance: Any user of a network configured with a Kerberos authentication system must first log in by submitting their user name and password credentials from a device, the first time they connect to the Kerberos-protected network. This request is sent to the Authentication Server (AS), which, together with a directory service form the KDC. The credentials of the user are verified by the AS, which, if found correctly entered, grants a Ticket Granting Ticket (TGT), which is encrypted with a hash of the password for the user account. The TGT is a string used to represent the user by his/her credentials, which the user can use whenever he/she desires to access other services on the network without running through a login process every time.

Service Ticket Request and Access: After being issued a TGT, the user can then make a request for certain services that are provided on the network. To do this, they use the TGT and reach the service that issues tickets for thematic network resources, which is TGS, or rather Trusted Gateways, as in the KDC structure. The TGS will have the task of confirming the validity of the TGT, and if affirmative, supply a ticket that renews service to the asset that was requested by virtue of the ticket that it validates.

Here’s a breakdown of each step and the role of each component in this process:

Step 1: The user logs into the Kerberos-secured network by providing their credentials, and the client software on the user’s device encrypts the password and sends an authentication request to the Authentication Server (AS) within the KDC.

Step 2: The AS verifies the user’s credentials by comparing them with its stored records. If valid, the AS generates a Ticket Granting Ticket (TGT), which includes a session key encrypted with the user’s password hash. This ensures that only the user can decrypt the TGT.

Step 3: When the user needs access to a network service, they present their TGT to the Ticket Granting Server (TGS), which is also part of the KDC. The TGS verifies the TGT and, if valid, issues a service ticket specific to the requested service. This service ticket is also encrypted with the session key and is valid only for the duration needed to access the service.

Step 4: The user sends the service ticket to the specific network service they wish to access, and the service validates the service ticket using the session key, confirming the user’s identity. Once validated, the service grants the user access to the requested resource, allowing them to interact with the network without re-entering credentials.

Where They Are Used

Its ability to securely authenticate users and services across untrusted networks makes it well-suited to complex, multi-user settings where frequent access to various resources is needed. Here are some key real-world applications of Kerberos:

Corporate and Enterprise Networks: For secure logging in and managing various resources within its internal resource such as file servers, databases, applications, and shared drives, several corporations with a deep intranet implement a mechanism named Kerberos.

Educational Institutions: Many colleges and research institutions, where there are thousands of users, tend to use KERBEROS in these directions: access and authentication of users to resources like academic databases, library systems, and student portals. Students and staff are effortlessly provided with access to a variety of departments and roles due to the controlled central management of user accounts.

Implementing on the company network

As a startup, you can consider Kerberos as an efficient and steady solution to provide both customer and internal authentication. It's derived from a ticket-based approach, lowering the frequency with which passwords are required, thereby reducing the opportunities for password misuse. Here are some ways Kerberos could be implemented:

Secure Internal Operations: Kerberos can also be deployed for the internal users, for employees and administrators, who need to perform back-end access to internal applications like inventory databases, customer management systems, and any internal resources.

Customer Identity Management: Even though Kerberos is not normally used for e-commerce, for direct and customer-related authentication due to the level of complexity, it can fit very well as a part of other tools focused on identity management.

Payment and Financial Systems: Kerberos can also be deployed in the payment gateways and in the financial systems to protect the relations of the e-commerce site with the payment systems. In these systems, Kerberos provides additional security since each transaction request is authenticated, allowing sensitive financial data to be better protected.

Strengths

Enhanced Data Protection for Growth: However, as business organizations grow, security threats are bound to increase. The ticketing and encryption features of Kerberos provide a layered security that is able to scale with the organization and therefore prevent data loss and unauthorized access.

Support for Cross-Platform Environments: As companies grow, they may have to chart a mix of technologies, including Windows, Linux, and cloud-based services. Kerberos can perform well in a cross-platform environment. So the companies will be able to grow and enhance their resource base without having to change authentication technologies.

Weaknesses

Vulnerability to Password-Guessing Attacks: With low or easily guessed passwords, Kerberos, despite its encryption, still remains prone to dictionary and brute force attacks. Those who obtain encrypted Kerberos tickets or session keys might use brute force to crack weak ones.

Complex Configuration and Management: Kerberos is both time and energy-consuming, as it demands proper setup, time coordination among the devices, and effective updates. Kerberos can only be effective when users and systems are well synchronized, owing to the time-stamping of tickets that prevents the repetition of transactions from various users.

Common Attacks

Pass-the-Ticket (PtT) Attack

Pass-the-ticket attack refers to attackers obtaining any of the already obtained valid Kerberos tickets, especially the Ticket Granting Ticket (TGT) that does not belong to them, and using that ticket to gain access. The ticket contains some information concerning the users who own it, and since attackers manage to acquire the ticket, they can bypass all passwords and pretend to be the owner of the ticket, allowing them to move around the network.

For Instance, an attacker breaches an employee’s device and captures a valid Kerberos TGT during the breach. By means of the pass-the-ticket technique, the attacker has the former’s TGT and impersonates that employee to use other network services without the former’s actual password. In this way, attackers may be able to get into the system’s administrative, customer’s, or even financial records area without being discovered and thus, may be able to steal sensitive information and money.

Replay Attack

The attacker intercepts an existing valid authentication exchange and retransmits some parts of the packet in order to gain access that did not belong to them. Through the use of time stamps on the tickets, Kerberos claims to prevent replay attacks. Time measuring and management, however, must be reasonably accurate, thus leaving the door open to abuse. If the network time is not uniform, attackers may use this weakness to their advantage and utilize old tickets that they’ve acquired.

For instance, if an attacker intercepts a Kerberos ticket while it is in transit between the client and server, this attack could allow unauthorized access to order management or inventory systems, where attackers could modify orders, cancel transactions, or manipulate stock records.

Lightweight Directory Access Protocol (LDAP)

What It Is

Lightweight Directory Access Protocol is an open standard-based protocol that is utilized to retrieve and control directory information within an IP-based network. It acts as a central point of management, where it retains and arranges related information regarding users, devices, and resources in a form. Being system and application-friendly, it becomes very useful in handling authentication in heterogeneous environments. It is usually applied in enterprise networks for the purpose of authenticating and authorizing users, enabling the administrator to handle many users and access to network resources from one point.

Purpose

LDAP provides management of users and resources in the network from one central point with safe and secure authentication and directory access. The solution helps organizations to efficiently enforce access control policies, keep a single repository of user credentials, and enable seamless authentication for users across different applications.

How They Work

LDAP’s authentication process involves verifying a user’s identity by comparing their credentials against information stored in a centralized directory. This directory, structured as a hierarchical tree, contains user entries (or objects) with attributes such as usernames, passwords, email addresses, and roles. When a user attempts to authenticate, LDAP uses bind operations to validate their credentials.

Step 1: When a user attempts to access a resource or application, their device (client) initiates a bind request to the LDAP server. The bind request includes the user’s Distinguished Name (DN), a unique identifier within the directory, and the user’s password.

Step 2: The LDAP server receives the bind request and searches its directory tree for the DN provided in the request. Once it locates the user’s entry, the LDAP server retrieves the stored credentials (password) associated with the DN to prepare for validation.

Step 3: The LDAP server compares the password provided in the bind request with the password stored in the user’s directory entry. If the credentials match, the bind operation is successful, and the user is authenticated. If the credentials do not match, the bind operation fails, and access is denied.

Step 4: Upon successful authentication, the LDAP server establishes a session for the user.

Step 5: LDAP uses Access Control Lists (ACLs) to determine which resources or directory information the authenticated user can access. They are configured based on individual users, groups, or organizational units.

Step 6: After authentication, LDAP supports attribute-based searches within the directory. These searches allow applications to retrieve specific information tied to the user’s entry, such as group memberships, roles, department, or organizational unit.

Step 7: Once the user completes their tasks or logs out, the session is terminated, closing their access to the LDAP-controlled resources.

Where They Are Used

LDAP is widely used in various enterprise, educational, and government settings where centralized user management and secure authentication are essential. Here are some common real-world applications and scenarios:

Educational Institutions: For universities or schools with large populations of students, faculty, and staff, LDAP is commonly used for identity management and access. Educational institutions can utilize LDAP directories as an effective way of managing access to various resources on campus, like library databases, student portals, learning management systems, and research tools, through an automated process from a single point of control.

Single Sign-On (SSO) Systems: It is usually extended to include SSO procedures, allowing a user to log in only once to a computer and gain access to various resources without the need to log in again.

Implementing on the company network

In the company backend, it will provide centralized user management and secure authentication for both employees and customers. Here are some:

Single Sign-On (SSO) for Internal Applications: Often, employees have many applications that they use, such as an analytics application, a CRM app, and email, etc. It would connect with an SSO service so that the employees can authenticate once and access many internal applications smoothly.

Customer Identity Management: It can be applied at the backend for handling management and customer authentication for people who logon to the e-commerce site. It might keep track of customer data, including the user ID, hashed password, and the account status, and use those to check if the request to log on has been reported.

Strengths

Cross-Platform Support for Flexibility: Many companies operate on different platforms and software. One of the advantages of using LDAP is that it provides a good adaptation since it not only cuts across Windows but also Linux and Unix, as well as cloud application and thus reduces the acquisition and setup of multiple authentication applications.

Support for Encryption (LDAPS): LDAP can operate over SSL/TLS-encrypted connections, known as LDAPS, which secures the communication between clients and servers.

Weaknesses

Lack of Built-In Encryption: By default, LDAP does not encrypt data in transit. Unless configured to use LDAPS (LDAP over SSL/TLS), sensitive information such as usernames and passwords can be transmitted in plaintext, leaving it vulnerable to interception by attackers.

Limited Support for Direct Customer Authentication: LDAP is generally better suited for internal user authentication and enterprise environments. It is not commonly used for direct customer-facing applications, as it lacks certain features designed for customer identity management, such as self-service account recovery and multi-factor authentication (MFA).

Common Attacks

Man-in-the-Middle (MitM) Attacks

However, LDAP by default does not encrypt data in transit, and LDAPS (LDAP over SSL/TLS) would need to be first enabled in order to avoid man-in-the-middle (MitM) attacks. In a MitM attack, it is assumed that an attacker intercepts the communication between a client, typically an application, and the LDAP server and is thus able to capture usernames, passwords, and other sensitive information in plaintext. This is a serious threat, particularly for environments where LDAPS is used to secure the connection, and none has been put in place.

Brute-Force and Dictionary Attacks

LDAP directories are also susceptible to brute-force or dictionary attacks in which an intruder tries to guess usernames and passwords in order to break into the system. Because LDAP is widely regarded as a centralized authentication system, succeeding in a brute attack could enable the attacker to breach several applications and systems that are linked to the directory. Slowly shifting password policies and the absence of multi-factor authentication (MFA) may also expose LDAP directories to additional heightened vulnerability to these attacks.

Conclusion

After a comparative analysis of three different authentication methods, LDAP presents the best scalability, security, and manageability. Its centralization and integration abilities suit a growing enterprise, and TLS/SSL encryption will protect data on the fly. Even though NTLM is relatively simple to configure, it is not appropriate for data protection in an e-commerce framework due to its security flaws. Kerberos is strong on security; this might be overkill for small teams in terms of resources.

Google Gemini Security Incident: AI Test Reached Three Real Companies

Prem Kumar Santhanam — Mon, 21 Sep 2026 06:59:51 +0000

In September 2026, Google confirmed that its Gemini AI had gained unauthorized access to systems belonging to three real companies during a cybersecurity evaluation. The disclosure was new in September, although the underlying activity took place in May. A timeline distinction that matters when discussing the incident accurately.

Gemini did not become sentient, turn hostile, or deliberately escape its operators. The real story is less cinematic and more useful to security teams. A powerful cyber agent was placed in a test environment with faulty boundaries, reached the public internet, mistook real systems for authorized targets, and gained access to three companies.

That distinction matters.

Calling this only an "AI gone rogue" story hides the controls that actually failed. The Google Gemini security incident was a breakdown in test scoping, network containment, credential hygiene, and detection around an agent capable of taking action at machine speed.

What Google confirmed

Google confirmed the incident publicly on September 18, 2026, following reporting by The Wall Street Journal. The unauthorized access itself occurred in May during a capture-the-flag cybersecurity evaluation run by Irregular, an independent company that tests advanced AI systems. Gemini was supposed to attack a fictional organization inside a controlled environment. Internet access was unintentionally available, however, and a fictional company used in the scenario coincided with a real domain.

Once Gemini reached the live internet, it treated real infrastructure as part of the exercise. In one case, the model repeatedly guessed passwords until it entered a protected system. In the other two, it found exposed credentials in a public repository and used them to access protected systems.

Heather Adkins, vice president of Security Engineering at Google said,

We ensured the three entities were made aware, and we worked with our training partner on the changes they've now made to their testing processes.

Google said Gemini stopped in each case after recognizing that it had reached a real company. The affected organizations were notified, and Google reported finding no evidence that the incidents caused damage. Their identities have not been disclosed.

The timing deserves attention.

The activity happened in May. Irregular notified the relevant AI labs in late July, and Google publicly confirmed its involvement on September 18 after reporting by The Wall Street Journal.

Rumors that are actually not in play

Accuracy is important because the phrase "Gemini hacked three companies" can suggest more than the known facts support.

There is no public evidence that Gemini chose to leave a correctly isolated sandbox, pursued a goal that conflicted with its instructions, or tried to hide its actions. Irregular's own account says internet access was unintentionally available and that models believed they were operating in simulations when they were acting against real systems.

There is also no verified public report of destructive activity, extortion, persistence, or stolen data in the Gemini incidents. "No evidence of damage" is not the same as proof that nothing happened, but it is the limit of what can responsibly be claimed from the available disclosures.

This was still unauthorized access.

A system does not need malicious intent to create a security incident. Production infrastructure was touched outside the approved scope, and three companies had to be notified.

The actual failure chain

From a security engineering perspective, the notable part is not any single bug. Several ordinary failures lined up:

The environment had unintended internet egress. A cyber-capable model expected to remain inside a simulation could reach external hosts.

The fictional target overlapped with a real domain. The scenario design created ambiguity between the lab and the public internet.

Authorization was represented in text, not enforced by infrastructure. The model believed reachable systems were in scope because the exercise framed them that way.

Real organizations exposed usable access paths. One reportedly accepted a guessed password, and the other two had credentials available in a public repository.

The controls did not stop the first unauthorized connection. Gemini reportedly stopped itself, but only after access had already occurred.

None of these conditions are exotic. Public credentials, weak passwords, loose egress rules, ambiguous asset inventories, and delayed detection have existed for years. Agentic AI changes the operating speed and scale. It can search, test, authenticate, and pivot without waiting for a human operator to approve every command.

What's in It for Companies

The three unnamed companies were not participants in Google's evaluation. Yet their security posture became part of it because their systems were reachable and their credentials or passwords were weak enough to use.

This was the uncomfortable lesson

A company does not need to deploy Gemini, approve an AI project, or purchase an agent platform to be affected by autonomous systems. External AI agents can interact with any public-facing service they can resolve and reach.

The incident also challenges a familiar security assumption: that intent helps determine risk.

A scanner, red team operator, criminal, and confused AI agent can generate similar telemetry at the network edge. Defenders cannot rely on the source understanding of legal scope. **Authorization **has to be enforced through allowlists, routing, credentials, rate controls, and monitored execution, not through a sentence in a prompt.

The episode is not isolated to Google.

Irregular said later disclosures by several customers referred to the same underlying evaluation issue, and other frontier model developers reported related incidents involving unintended internet access during cyber testing. That points to a shared weakness in evaluation infrastructure, not a quirk unique to one model.

Controls that would have helped

Security leaders do not need a new framework for every AI incident. The strongest defenses here are recognizable controls applied with more discipline.

For AI evaluation teams

Default-deny egress: Block public internet access at the network layer. If external access is essential, route it through an authenticated proxy with a narrow destination allowlist.

Use reserved namespaces: Build scenarios on domains and address ranges that cannot resolve to real organizations. Revalidate them before every run, not only when the exercise is created.

Create a hard scope manifest: Bind each job to approved hostnames, IP ranges, ports, tools, and time windows. Reject actions outside that manifest before execution.

Separate planning from execution: Let the model propose actions, but require a deterministic policy engine or a human reviewer for high-risk steps to authorize password guessing, exploitation, credential use, and data access.

Add tripwires: Canary domains, decoy credentials, DNS alerts, and egress-volume limits can stop an evaluation when it drifts beyond the expected path.

Log at the action layer: Record prompts, tool calls, DNS queries, connections, authentication attempts, files accessed, and policy decisions in a tamper-resistant store.

Test the evaluator: Treat a third-party AI testing environment like any other critical supplier. Review its network diagrams, containment controls, incident notification terms, and evidence of remediation.

Irregular says it disabled the affected evaluation, reviewed relevant logs, remediated the internet-access problem, notified affected parties, and added safeguards. Its postmortem also calls for stronger documentation, monitoring, threat modeling, and information sharing.

For every company

Remove secrets from public repositories: Run continuous secret scanning across source control, package artifacts, documentation, and commit history. Rotate exposed credentials because deleting the file is not enough.

Eliminate guessable authentication: Enforce phishing-resistant MFA where possible, rate-limit failed logins, block breached passwords, and alert on password spraying.

Reduce public attack surface: Maintain an external asset inventory and close forgotten services, stale subdomains, test interfaces, and exposed administration panels.

Detect automated behavior: Look for high-velocity discovery, repeated authentication attempts, unusual user agents, rapid tool switching, and successful logins following repository access.

Prepare for ambiguous actors: Incident playbooks should focus first on containment and evidence preservation. Whether the source is a researcher, a criminal, or an autonomous agent may not be immediately clear.

The harder governance question

Google's position is that the behavior did not amount to model misalignment because Gemini stopped after realizing it had reached real systems. That may be a reasonable model-safety classification, but it does not settle the incident management question.

A model can behave consistently with its assigned objective while the overall system remains unsafe. In this case, the model, evaluator, network configuration, target naming, and external credential exposure formed one operational chain. Judging only the model's intent would miss most of the risk.

The disclosure gap also merits scrutiny.

The incidents occurred in May, the relevant labs were notified in late July, and public confirmation followed in September.

Organizations deploying high-autonomy systems need written thresholds for reporting out-of-scope access, even when no damage is found and the model later stops. Affected parties should not depend on press inquiries to learn how vendors classify such events.

The security engineer's takeaway

The Google Gemini security incident should not be reduced to a headline about an AI "escaping." The test boundary failed, the agent acted on the environment it was given, and weak real-world security controls made three unauthorized accesses possible.

The practical rule is straightforward. Never ask a capable agent to respect a boundary that the infrastructure does not enforce. Prompts can describe scope. Firewalls, proxies, policy engines, credential controls, and monitoring must impose it.

Gemini stopping itself was a useful safeguard. It was not a containment strategy. The next agent may not recognize the mistake, and the next exposed system may carry consequences that cannot be dismissed as "no evidence of damage."

Thank you for the support. Stay tuned for information security writing by subscribing to my newsletter. Follow me on LinkedIn & Medium

WSO2 Vulnerability CVE-2026–5430 Explained: How Attackers Are Bypassing Authentication in the Wild

Prem Kumar Santhanam — Mon, 21 Sep 2026 05:12:57 +0000

WSO2’s identity and API infrastructure sits behind roughly a thousand enterprise deployments (banks, telecoms, government agencies, and logistics networks), plus thousands more running it through open-source builds and OEM partnerships. This week, exposure management firm WatchTowr confirmed active exploitation of CVE-2026–5430, a maximum-severity (CVSS 10.0) authentication bypass affecting WSO2’s API Manager, API Control Plane, Traffic Manager, and Universal Gateway products.

The patch shipped in April. The CVE was assigned in early August. The first confirmed attack against a honeypot landed on September 13. That’s a five-month gap between “fixed” and “actively exploited,” and it’s the part of this story that matters more than the bug itself.

Security Advisory:

security.docs.wso2.com

CVE-2026–5430:

cve.org

What’s Actually Broken

The root cause is a JWT algorithm confusion flaw. WSO2’s own advisory puts it plainly: a token signed using an unsupported algorithm can bypass authentication entirely. If you’ve spent any time around identity and access management, you’ll recognize this pattern immediately. It’s a variation on the “alg: none” family of JWT attacks that has been showing up in security research for close to a decade. The server accepts a token because it fails to strictly enforce which signing algorithm is valid, and an attacker who understands that gap can forge credentials that the system treats as legitimate.

What makes this instance dangerous isn’t novelty. It’s reach. WSO2 sits at the API and identity layer, where the control plane decides who talks to what. A successful forgery here doesn’t just get you into one application. WatchTowr’s own researcher described the attacker’s objective directly: access to every API backend endpoint and the credentials tied to them. That’s not an account compromise. That’s a keys-to-the-kingdom scenario sitting one algorithm-parsing bug away from reality.

The Timeline Tells You Something About Attacker Behavior

A few details from the disclosure are worth sitting with:

No public PoC, and it still got exploited fast. Technical details for CVE-2026–5430 still aren’t publicly documented in depth. WatchTowr reproduced the vulnerability by reverse-engineering WSO2’s own patch, comparing the fixed code against the vulnerable version to figure out what changed and why. This is a well-worn technique known as patch diffing, and it means “no public exploit code” is not a control you can rely on. If a vendor ships a patch, assume capable adversaries are already working backward from it.

The attacker fumbled the target and still succeeded. One detail stood out in WatchTowr’s write-up: the first attacker hit the wrong WSO2 product in the honeypot. When researchers took that same payload and replayed it against the correct component, it worked without modification. Read that twice. This wasn’t a sophisticated, bespoke operation. It was closer to spray-and-pray tooling that happened to get lucky on a retry. Low attacker sophistication combined with high-value access is exactly the combination that produces mass exploitation events, not the quiet, targeted intrusions that dominate incident response tabletop exercises.

This isn’t an isolated bug; it’s a pattern. The WSO2 flaw follows closely behind a separate critical JWT authentication bypass disclosed in Fortinet products this same month. Two unrelated vendors, two unrelated codebases, the same underlying failure mode: token validation logic that doesn’t hold up under adversarial input. If your security program treats each CVE as a one-off fire drill instead of a signal about a systemic weakness in how software validates trust, you’re going to keep getting surprised by the next one.

Why This Should Change How You Think About Patch Prioritization

Here’s the uncomfortable part for a lot of security teams. This vulnerability was patched five months before anyone weaponized it. If your organization runs WSO2 and hasn’t applied the April fix, the reason almost certainly isn’t ignorance; it’s prioritization. A CVSS 10 sitting in a backlog next to forty other “critical” findings is a familiar problem, and it’s rarely solved by telling people to “patch faster." It’s solved by better signal on which vulnerabilities sit in your actual internet-facing, identity-adjacent attack surface.

A few things worth pulling out of this specific case for how you triage:

Identity and API gateway components deserve a different SLA than internal tooling. A bug in your internal wiki is not the same risk class as a bug in the system deciding who gets an authenticated session to your APIs. If your patch management process doesn’t already weight “blast radius through the identity layer” more heavily than raw CVSS score, this is a good week to fix that.
**“Patched” doesn’t mean “safe” if the patch isn’t deployed everywhere. **WSO2’s footprint includes direct enterprise customers, OEM-embedded deployments, and open-source self-hosted instances. Each of those has a different patching cadence, and the OEM and open-source tail is exactly where unpatched instances linger the longest, often because nobody on the security team even knows the component is there.
Vendor advisory language is a signal, not just paperwork. WSO2’s own wording, "potential compromise of administrative accounts and full account takeover," was about as unambiguous as vendor advisories get. When a vendor tells you the blast radius includes admin accounts, that’s not boilerplate. Treat it as an instruction.

What Detection Actually Looks Like Here

If patching windows are your first line of defense, monitoring is your second, and this incident gives a decent blueprint for what to watch:

Malformed or unusual algorithm headers in JWTs hitting your API gateway. Algorithm confusion attacks leave a fingerprint in the token header itself. If your logging pipeline captures JWT headers (not just payloads) at the gateway layer, you have a detection opportunity most teams aren’t using.
Authentication successes that don’t match expected session-issuance patterns. A forged token bypasses the normal login flow, which means the resulting “authenticated” session often lacks the upstream artifacts, such as (MFA challenge completion, password verification events, and expected geographic or device fingerprints), that a legitimate session would generate. Correlating “authenticated” against “actually logged in through the front door” is a high-value detection rule.
Anomalous API backend enumeration from a single authenticated identity. Given that the observed attacker goal was to reach every backend endpoint and its credentials, a session that suddenly starts touching an unusually broad set of API resources is a strong behavioral signal, independent of whether you’ve fully confirmed the authentication path was forged.

None of this replaces patching. It buys you time and visibility for the deployments you haven’t gotten to yet, and it catches the next algorithm confusion bug that shows up under a different CVE number.

The Broader Point for Anyone Running Identity Infrastructure

Zero Trust architecture gets talked about mostly in terms of network segmentation and least-privilege access, but this incident is a reminder that the token itself is a trust boundary, and trust boundaries need adversarial testing, not just code review. If your organization builds or operates any identity or token-issuing service, even internally, even something you consider “not really an IdP,” a few questions are worth asking this week:

Does your JWT validation logic explicitly allowlist accepted signing algorithms, or does it trust whatever algorithm the token claims to use?
Do you have visibility into which of your deployed WSO2 or any API gateway/IAM instances are actually patched, including anything embedded through a vendor or OEM relationship?
Can your SOC actually distinguish a forged authentication event from a legitimate one in your current logging setup, or would this kind of bypass sail through undetected?

CVE-2026–5430 will get patched across most environments over the coming weeks, and the news cycle will move on. The underlying failure mode- trust decisions made on unvalidated cryptographic assumptions won’t go anywhere. It’ll show up again under a different CVE, in a different product, and the organizations that come out ahead of it will be the ones that treated this week’s headline as a prompt to check their own identity stack, not just a warning about somebody else’s software.

Complete SIEM Implementation Guide: Log Collection, Correlation Rules, Alerting, and Dashboards

Prem Kumar Santhanam — Sat, 19 Sep 2026 02:09:40 +0000

I have assembled a home lab using a Kali virtual machine and Elastic SIEM. I used the Elastic Beats agent to transfer data from the Kali virtual machine to the SIEM; Nmap was used to generate security events on the Kali VM; and the Elastic web interface was used to query and analyze the logs in the SIEM. In order to detect security incidents, I also designed an alert and a dashboard to visualize security occurrences.

Using the help of this home lab, I can acquire and hone the skills required for efficient security monitoring and incident response using Elastic SIEM. By following these steps, I can enhance my security monitoring abilities and obtain practical experience with utilizing a SIEM, which will help me become a great security analyst or engineer.

Prerequisites

Before we get started, make sure you have the following:

VirtualBox or VMware
Basic knowledge of Linux and virtualization software.

Overview of the tasks

Set up a free Elastic account.
Install the Kali VM.
Set up the Linux virtual machine’s Elastic Agent to gather logs and send them to the SIEM.
Generate security events on the Kali VM.
Query to find the security events in the Elastic SIEM.
Create a Dashboard to visualize security events.
Create alerts for security events.

Task 1: Set up an Elastic Account

Sign up for a free trial to use Elastic Cloud at https://cloud.elastic.co/registration
Once you have an Elastic account, log in to the Elastic Cloud console at https://cloud.elastic.co.
Click on “Start your free trial.”
When choosing the deployment type, click the “Create Deployment” button and choose “Elasticsearch.”
Select the deployment size and region that best suit your requirements, then click “Create Deployment.”
Wait for the configuration to complete.

Once the deployment is ready, click “continue.”

Task 2: Setting up the Linux VM

Download the Kali Linux VM from the official Kali website at https://www.kali.org/get-kali/#kali-virtual-machines.
Using the Kali VM file, create a new virtual machine (VM) in your favourite virtualization software, like VMware or VirtualBox.
Start the VM and follow the on-screen prompts to install Kali.

After installation is finished, use “kali” as the login and password to access the Kali virtual machine (VM).

Task 3: Setting up the Agent to Collect Logs

To gather and transmit data to a centralized system for analysis and monitoring, software called an agent is placed on a device, such as a server or endpoint. Security-related events from your endpoints are gathered and forwarded to your Elastic SIEM instance via an agent in the context of the platform.

To set up the agent to collect logs from your Kali VM and forward them to your Elastic SIEM instance, follow these steps:

To access the Integrations page, log in to your Elastic SIEM instance, click the Kibana main menu bar in the upper left corner, and then choose “Integrations” from the bottom menu.
Search for “Elastic Defend” and click on it to open the integration page.
To install the agent on your Kali VM, click “Install Elastic Defend” and adhere to the installation instructions on the integration page. Paste that command into the Kali terminal (command line).
You will receive a notification stating that the “Elastic Agent has been successfully installed” after the agent has been installed, which may take several minutes. It may take a few minutes for the logs to show up in the SIEM, but it will begin automatically gathering and transmitting data to your Elastic SIEM server.
You can verify that the agent has been installed correctly by running this command: sudo systemctl status elastic-agent.service

Note: Before continuing, make sure your Kali is online by pinging google.com if you receive a problem when installing the agent.

Search Elastic Defend in the Integration Menu

Elastic Defend Agent Verification

Task 4: Generating Security Events on the Kali VM

You can create some security-related events on your Kali virtual machine (VM) to confirm that the agent is operating as intended. We can use a tool like Nmap and Wireshark to accomplish this. A free and open-source tool for network administration, exploration, and security auditing is called Nmap (Network Mapper).

Its purpose is to identify hosts and services on a computer network, generating a network “map” in the process. Nmap may be used to find out what operating system and software are installed on a target system, check hosts for open ports, and obtain further network information. Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development, and education.

To run an Nmap scan, follow these steps:

Install Nmap on the Linux VM if you’re not using Kali, Nmap already comes preinstalled in Kali. Open a new Terminal and run this command to install it: sudo apt-get install nmap.
Run a scan on Kali machine by running the command: sudo nmap . You can also run a scan of your host machine if you place your Kali VM on a “bridged” network.
This scan generates several security events, such as the detection of open ports and the identification of services running on those ports. Run a few more Nmap scans (“nmap -sS ”, “nmap -sT ”, “nmap -p- ”etc..)

Nmap and Wireshark scan data

Task 5: Querying for Security Events in the Elastic SIEM

We can now begin searching through and examining the SIEM’s logs after moving data from the Kali VM.

To do this, follow these steps:

To see the logs from the Kali virtual machine, within your Elastic Deployment, click the three horizontal line menu icon in the top-left corner and select the “Logs” option under “Observability.”
In the search bar, enter a search query to filter the logs. For example, to search for all logs related to Nmap scans, enter the query: event.action:“nmap_scan” or process.args: “sudo”.
Click on the “Search” button to execute the search query.
The results of the search query will be displayed in the table below. You can click on the three dots next to each event to view more details.

Note: You can learn more about how security incidents are found, looked into, and handled in real-world settings by creating and examining various security event types in Elastic SIEM, such as the one above, or by creating authentication failures caused by a user entering the wrong password or trying to log in to SSH with the wrong password.

Nmap Event Log

Wireshark Event Log

Task 6: Create a Dashboard to Visualize the Events

You can also use the visualizations and dashboards in the SIEM app to analyze the logs and identify patterns or anomalies in the data.

Here’s how you can do that:

Navigate to the Elastic web portal at https://cloud.elastic.co/.
Click on the menu icon on the top-left, then under “Analytics,” click on “Dashboards.”
Click on the “Create dashboard” button on the top right to create a new dashboard.
Click on the “Create Visualization” button to add a new visualization to the dashboard.
Choose the visualization kind you desire, either “Area” or “Line.” A chart displaying the number of incidents over time will be produced as a result.
Choose “Timestamp” for the horizontal field and “Count” for the vertical field type in the “Metrics” section of the visualization editor on the right. This will display the number of occurrences over time.
Click on the “Save” button to save the visualization and then complete the rest of the settings.

Visualization Dashboard

Task 7: Create an Alert

Alerts are an essential component of a SIEM that help identify security events and quickly address them. Alerts can be set up to perform particular actions when predetermined criteria are fulfilled, and they can be generated using established rules or bespoke queries.

Here are the steps:

Click on the menu icon on the top-left, then under “Security,” click on “Alerts.”
Click on “Manage rules” at the top right.
Click on the “Create new rule” button at the top right.
Under the “Define rule” section, select the “Custom query” option from the dropdown menu.
Establish the rules’ conditions under “Custom query.” The following query can be used to find Nmap scan events. All events that match the action “nmap_scan” will be matched by this query. Next, select “Continue.”
Under the “About rule” section, give your rule a name and a description (Nmap Scan Detection).
You can prioritize warnings according to their importance by setting the alert’s severity level. Click “Continue” after maintaining all other default settings under “Schedule rule.”
Choose the action you wish to perform when the rule is activated from the “Actions” section. You have the option to start a custom webhook, start a Slack chat, or send an email notification.
Finally, click the “Create and enable rule” button to create the alert.

Note: After creating the alert, it will keep an eye out for Nmap scan events in your logs. The alarm will sound and the chosen action will be carried out if a Nmap scan event is found. Under “Security,” go to the “Alerts” section to view and manage your notifications.

Create a Rule to filter out Nmap Events

Alert detected after successful rule creation

Additional Observations:

In order to use Anomaly detection, Data Frame Analytics, Dashboard Management, Data Visualizations, and other features on your deployment, you can also build Machine Learning models.
You may locate your rule operating on the specified path and receiving the triggered actions on the main dashboard under the alerts part of the observability section.

Alert Dashboard view

You can filter out specific events from the stream section by using the timestamps and actions completed as a collaborative log found in the discover sections. These logs will be used to create a pictorial representation of the occurrences.

Log Analysis on Event Dashboard

Numerous performance data, like CPU Usage, CPU Credits, Number of Inbound Requests, Search Response Time, and so forth, are available on your deployment’s Main Page. You will receive a comprehensive analysis of the performance and health of your deployment from these indicators.

Metrics Analysis on Deployment Dashboard

You can compute your data quality, Kubernetes, entity analytics, and detection and response data using a variety of pre-defined dashboards found under the security area. Additionally, you may design a custom dashboard to track the actions that are triggered by your deployment and conduct technical analysis.

Technical Analysis Dashboards

Data Quality Analysis Dashboard

Understand Authentication — NTLM vs Kerberos vs LDAP

Prem Kumar Santhanam — Sun, 21 Jun 2026 13:23:07 +0000

NT LAN Manager (NTLM) Authentication

What It Is

Purpose

How They Work

Step 1: The user’s device (client) initiates the authentication process by sending an access request to the server.

Step 4: The client returns the computed response to the server. This response acts as proof of the user’s identity, as it can only be generated correctly with the correct password hash.

Step 6: Once the server confirms the validity of the client’s response, it allows the user access to the requested resources.

Where They Are Used

Intranets and Internal Networks: NTLM is typically used in IT departmental groups when there is little to no need for external access. Because it is so simple to deploy and works with many outdated systems, it is perfect for most places where maintaining older systems is a priority, but protective measures are not a necessity.
Legacy Systems: Most, if not all, companies that utilize an outdated IT architecture still use NTLM authentication to connect their machines operating on an older version of Windows. Where systems have not migrated to Kerberos or other current protocols, NTLM is useful, including in scenarios for small or medium-sized enterprises where migration resources are unavailable.

Implementing on the company network

Internal Administrative Access: NTLM could be used to control authentication to internal information administrative systems or back office, where employees need operational resources. Such may be appropriate where these systems are in a closed network, isolated from any external threats.
VPN and Remote Worker Access: It uses an offline infrastructure, and hence, we can authenticate remote employees accessing company resources through a VPN by means of NTLM. This is not the best option due to NTLM’s weaknesses; it could be used for a short-term or transitional situation where stronger protocols such as Kerberos cannot be used because of technical limitations or a lack of sufficient resources.

Strengths

Resource Efficiency: The great advantage of NTLM, as stated by its minimal infrastructure requirements, is that many servers, encryption keys, or wide area network alterations do not have to be drawn. For a company with limited technical resources, NTLM offers a flexible user authentication method that does not require such an extensive configuration as for more complicated protocols.
Low Management Overhead: NTLM does not need the centralized management infrastructure that protocols such as Kerberos require. Unlike Kerberos, which is much more complex and involves KDCs, NTLM is a hash-based protocol that simplifies the management of the authentication process and does not require as complex IT staff to manage.

Weaknesses

Lack of Encryption for Data in Transit: NTLM does not provide for the encryption of the challenge-response swap during an authentication process. This absence of encryption puts the user’s password hash and other sensitive information at risk of interception. In this manner, the attackers are able to capture data and seek to abuse it in attacks involving certain manipulation, for example, replay attacks.
Susceptibility to Pass-the-Hash Attacks: In this attack, a hacker captures a hashed password and reuses it to gain unauthorized access, without needing to know or decrypt the actual password. This is possible because NTLM relies heavily on hashes, which can be captured and exploited by attackers with network access.

Common Attacks

Replay Attack

Brute-Force and Dictionary Attacks

Kerberos

What It Is

How They Work

The entire process revolves around the Key Distribution Center (KDC), which acts as the trusted authority for issuing authentication tickets. This process is divided into two main stages:

Initial Authentication and Ticket Granting Ticket (TGT) Issuance: Any user of a network configured with a Kerberos authentication system must first log in by submitting their user name and password credentials from a device, the first time they connect to the Kerberos-protected network. This request is sent to the Authentication Server (AS), which, together with a directory service form the KDC. The credentials of the user are verified by the AS, which, if found correctly entered, grants a Ticket Granting Ticket (TGT), which is encrypted with a hash of the password for the user account. The TGT is a string used to represent the user by his/her credentials, which the user can use whenever he/she desires to access other services on the network without running through a login process every time.
Service Ticket Request and Access: After being issued a TGT, the user can then make a request for certain services that are provided on the network. To do this, they use the TGT and reach the service that issues tickets for thematic network resources, which is TGS, or rather Trusted Gateways, as in the KDC structure. The TGS will have the task of confirming the validity of the TGT, and if affirmative, supply a ticket that renews service to the asset that was requested by virtue of the ticket that it validates.

Here’s a breakdown of each step and the role of each component in this process:

Where They Are Used

Corporate and Enterprise Networks: For secure logging in and managing various resources within its internal resource such as file servers, databases, applications, and shared drives, several corporations with a deep intranet implement a mechanism named Kerberos.
Educational Institutions: Many colleges and research institutions, where there are thousands of users, tend to use KERBEROS in these directions: access and authentication of users to resources like academic databases, library systems, and student portals. Students and staff are effortlessly provided with access to a variety of departments and roles due to the controlled central management of user accounts.

Implementing on the company network

Secure Internal Operations: Kerberos can also be deployed for the internal users, for employees and administrators, who need to perform back-end access to internal applications like inventory databases, customer management systems, and any internal resources.
Customer Identity Management: Even though Kerberos is not normally used for e-commerce, for direct and customer-related authentication due to the level of complexity, it can fit very well as a part of other tools focused on identity management.
Payment and Financial Systems: Kerberos can also be deployed in the payment gateways and in the financial systems to protect the relations of the e-commerce site with the payment systems. In these systems, Kerberos provides additional security since each transaction request is authenticated, allowing sensitive financial data to be better protected.

Strengths

Enhanced Data Protection for Growth: However, as business organizations grow, security threats are bound to increase. The ticketing and encryption features of Kerberos provide a layered security that is able to scale with the organization and therefore prevent data loss and unauthorised access.
Support for Cross-Platform Environments: As companies grow, they may have to chart a mix of technologies, including Windows, Linux, and cloud-based services. Kerberos can perform well in a cross-platform environment. So the companies will be able to grow and enhance their resource base without having to change authentication technologies.

Weaknesses

Vulnerability to Password-Guessing Attacks: With low or easily guessed passwords, Kerberos, despite its encryption, still remains prone to dictionary and brute force attacks. Those who obtain encrypted Kerberos tickets or session keys might use brute force to crack weak ones.
Complex Configuration and Management: Kerberos is both time and energy-consuming as it demands proper setup, time coordination among the devices, and effective updates. Kerberos can only be effective when users and systems are well synchronized, owing to the time-stamping of tickets that prevents the repetition of transactions from various users.

Common Attacks

Pass-the-Ticket (PtT) Attack

Replay Attack

Lightweight Directory Access Protocol (LDAP)

What It Is

Purpose

How They Work

Step 4: Upon successful authentication, the LDAP server establishes a session for the user.

Step 7: Once the user completes their tasks or logs out, the session is terminated, closing their access to the LDAP-controlled resources.

Where They Are Used

Educational Institutions: For universities or schools with large populations of students, faculty, and staff, LDAP is commonly used for identity management and access. Educational institutions can utilize LDAP directories as an effective way of managing access to various resources on campus, like library databases, student portals, learning management systems, and research tools, through an automated process from a single point of control.
Single Sign-On (SSO) Systems: It is usually extended to include SSO procedures, allowing a user to log in only once to a computer and gain access to various resources without the need to log in again.

Implementing on the company network

In the company backend, it will provide centralized user management and secure authentication for both employees and customers. Here are some:

Single Sign-On (SSO) for Internal Applications: Often, employees have many applications that they use, such as an analytics application, a CRM app, and email, etc. It would connect with an SSO service so that the employees can authenticate once and access many internal applications smoothly.
Customer Identity Management: It can be applied at the backend for handling management and customer authentication for people who logon to the e-commerce site. It might keep track of customer data, including the user ID, hashed password, and the account status, and use those to check if the request to log on has been reported.

Strengths

Cross-Platform Support for Flexibility: Many companies operate on different platforms and software. One of the advantages of using LDAP is that it provides a good adaptation since it not only cuts across Windows but also Linux and Unix, as well as cloud application and thus reduces the acquisition and setup of multiple authentication applications.
Support for Encryption (LDAPS): LDAP can operate over SSL/TLS-encrypted connections, known as LDAPS, which secures the communication between clients and servers.

Weaknesses

Lack of Built-In Encryption: By default, LDAP does not encrypt data in transit. Unless configured to use LDAPS (LDAP over SSL/TLS), sensitive information such as usernames and passwords can be transmitted in plaintext, leaving it vulnerable to interception by attackers.
Limited Support for Direct Customer Authentication: LDAP is generally better suited for internal user authentication and enterprise environments. It is not commonly used for direct customer-facing applications, as it lacks certain features designed for customer identity management, such as self-service account recovery and multi-factor authentication (MFA).

Common Attacks

Man-in-the-Middle (MitM) Attacks

Brute-Force and Dictionary Attacks

Conclusion

Security Hardening: Stateful iptables Firewall for DMZ Isolation & Cyber Threat Mitigation

Prem Kumar Santhanam — Fri, 19 Jun 2026 03:58:34 +0000

Organization Overview

Started last year, Luna Bags (LB) is a new fashion company that sells a variety of eco-friendly handbags and backpacks. The company has about 20 employees, mostly working from its New York main office and some working remotely from home, who are responsible for different business functions, including finance, marketing, IT, customer relations, human resources, and management executives. They hired me as a specialist in the cybersecurity team for the company to implement strategies to secure the company’s network.

Network Topology

The company has a visualized network to test the proposal. 192.168.60.0/24 is an internal network where many employees need to access internal services and the customer database. 10.9.0.0/24 is the DMZ where many public services are offered to LB’s customers.

Existing Topology

Network Overview

Luna Bags network is divided into distinct zones to enforce security boundaries. The primary zones include the External (Internet), the DMZ (demilitarized zone for public-facing services), the Internal Network (trusted corporate LAN), and a VPN Subnet for remote users. This segmented design ensures that each zone’s traffic can be controlled and monitored.

The network is divided into four distinct zones — External, DMZ, Internal, and VPN — each protected by firewall rules that enforce strict segmentation. The External network is treated as untrusted, with only HTTP traffic to the DMZ permitted, while all other inbound traffic, including ping requests, is dropped to minimize exposure. The DMZ (10.9.0.0/24) hosts public-facing services like the web server and acts as a buffer zone; it allows limited communication with the internal network, ensuring that even if compromised, attackers cannot reach internal resources.

The Internal network (192.168.60.0/24) is Luna Bag’s secure LAN, completely isolated from the internet, along with some exceptions for internal employees, with outbound access and controlled access to the DMZ, maintaining a strong internal defense. Lastly, the VPN subnet (10.10.10.0/24) allows secure remote access, treating authenticated VPN users as internal clients while routing all their traffic through the corporate firewall. This architecture enforces a least-privilege model, ensuring that only business-critical traffic flows between zones, significantly reducing the risk of lateral movement or external compromise.

Proposed Topology

Firewall Architecture and Explanation (Rule Table Included)

The firewall configuration on the router is structured into categories of rules, each governing traffic between specific zones or handling particular types of traffic. At a high level, the firewall is set to “deny by default” — any traffic not explicitly allowed in these rules will be blocked. The rules below are processed in order, and they apply to the router’s main firewall chains: INPUT, FORWARD, and OUTPUT.

External → DMZ Traffic:
Only HTTP (port 80) from the internet to the DMZ web server (10.9.0.5) is allowed using a specific FORWARD rule. All other ports, protocols, and services are logged and dropped, preventing attackers from probing other services in the DMZ. This follows the principle of least privilege, exposing only what’s necessary.
Internal → DMZ Traffic:
Internal users (192.168.60.0/24) can access the DMZ for HTTP (80) and SSH (22) using specific rules. This supports web testing and administrative SSH access without opening DMZ services to the public. Any non-approved traffic, like Telnet, is dropped by default.
Internal → Internet (Outbound) Traffic:
Internal hosts are allowed to initiate outbound internet connections for browsing, email, etc., via a general rule allowing new sessions to 0.0.0.0/0. This is complemented by stateful inspection, allowing return traffic seamlessly.
NAT for Internal Outbound Traffic:
The router performs NAT masquerading on outbound traffic (MASQUERADE), allowing internal private IPs to access the internet while hiding internal addressing from external entities. This is essential for internet connectivity and enhances privacy.
HTTPS Access Rule:
A specific rule also permits outbound HTTPS (port 443) from internal users. While somewhat redundant due to the general outbound rule, it reinforces the allowance of secure web browsing. We may further refine this if access control policies evolve.
DMZ → Internal Traffic:
The firewall blocks all new connections initiated by the DMZ to the internal network. This ensures that even if a DMZ host is compromised, it cannot reach internal resources. Only reply traffic (e.g., SSH session responses) is allowed through stateful tracking.
VPN Access (Remote VPN Clients ↔ Internal Network):
The firewall securely enables remote access by allowing VPN connections on UDP port 1194 to the router’s internal IP (192.168.60.1), using the rule. Once connected, VPN clients on the 10.10.10.0/24 subnet are permitted to communicate with internal resources (192.168.60.0/24) via bidirectional FORWARD rules, allowing seamless access to file servers, printers, and other services as if the user were on-site.

Additionally, the firewall supports full-tunnel VPN functionality by applying NAT masquerading, which enables VPN clients to access the internet through the corporate gateway. This ensures their traffic is filtered and monitored like any internal user, improving security on untrusted networks. By restricting access to a defined subnet and enforcing encryption and authentication, this setup aligns with best practices for secure and manageable remote access.

Management Access (SSH to Router, ICMP Ping):
The firewall configuration permits secure SSH access to the router exclusively from the internal network (192.168.60.0/24), allowing IT administrators to manage firewall, VPN, and routing settings without exposing this sensitive service to external or DMZ sources. Additionally, ICMP echo (ping) requests are allowed from internal and optionally from DMZ hosts to their respective router interfaces for basic network diagnostics. This controlled use of ping supports troubleshooting without weakening security, as external ICMP requests are blocked, and all replies are governed by stateful inspection.
Stateful Connection Tracking (Established/Related Traffic):
I configured Luna Bag’s firewall to use stateful inspection, allowing return traffic for established and related connections using iptable rules. This enables secure two-way communication without requiring duplicate rules. Packets that don’t match a valid connection, such as stray XMASs or FINs are dropped, enhancing protection against spoofed or malformed traffic. This mechanism ensures only legitimate, session-based traffic is allowed, reducing risk and simplifying rule management.
Dropping Invalid or Malicious Packets:
The firewall uses connection tracking to identify and drop packets marked as INVALID, which often represent malformed, spoofed, or out-of-sequence traffic. These are logged with the prefix “DROP INVALID:” and provide valuable insights into potential attacks or network misconfigurations. This rule adds an extra layer of protection against non-standard or malicious traffic.
Null, Xmas, and FIN Scan Protection:
The firewall blocks stealth scanning techniques — Null, Xmas, and FIN scans — by detecting specific TCP flag patterns and dropping such packets immediately. This prevents attackers from using these methods to discover open ports, making the network appear “filtered” and significantly harder to map or target.
Rate Limiting on Web Server:
A rule caps concurrent connections to port 80 at 100 per IP, rejecting further attempts to prevent simple DoS or abuse. This rate-limiting protects server resources from being overwhelmed by excessive connections from a single source while maintaining performance for legitimate users.
Default DROP Policy:
The firewall applies a strict default deny policy (iptables -P FORWARD DROP) for all traffic not explicitly permitted. This ensures that any unforeseen or misconfigured services are automatically blocked, enforcing strong access control and minimizing risk from unanticipated vulnerabilities.

Attack Stimulation and Validation

To verify that the firewall is indeed providing the intended protection, I performed a series of tests simulating both malicious attacks and legitimate traffic. Below, I outlined each test scenario, the method used, and the observed result, demonstrating that the firewall rules are effective.

Simulated Attacks (Blocked Traffic)

Null Scan
I performed a Null scan (nmap -sN) against the DMZ web server, which sends TCP packets with no flags. The firewall’s Null scan rule dropped these silently. Nmap reported all ports as “filtered” or “open|filtered,” confirming that the firewall successfully blocked the scan and concealed open ports.
Xmas Scan
An Xmas scan (nmap -sX) was launched, sending TCP packets with FIN, PSH, and URG flags. The firewall’s explicit rule targeting this flag combination effectively blocked the packets. Nmap could not determine the status of any ports, verifying that the firewall prevented reconnaissance attempts.
Fin Scan
I executed a FIN scan (nmap -sF), which sends TCP packets with only the FIN flag. Although not explicitly blocked, these were dropped by the firewall’s stateful inspection as they lacked a proper SYN handshake. All ports appeared filtered, confirming that the firewall blocked the scan based on connection state.
DMZ to Internal Access Attempt
To validate internal network protection, I attempted to connect from the DMZ server to an internal host on random ports, but all attempts failed as expected. The firewall logged these as “FW DROP DMZ->INT” confirming that DMZ-initiated traffic to the internal LAN is effectively blocked, preventing lateral movement even if the DMZ is compromised.

Additionally, I conducted external Nmap scans targeting ports other than HTTP (80) and VPN (1194) on the DMZ server, and all were shown as “filtered.” Attempts to access closed ports (e.g., port 81) or internal IPs (e.g., 192.168.60.5) were also silently dropped. These results confirm that only explicitly allowed services are accessible externally, while everything else remains hidden and unreachable — ensuring a strong, locked-down perimeter.

Blocked Traffic Tests (Simulation of Attacks and Unauthorized Access)

Telnet/FTP from External to DMZ: Attempted to connect to DMZ server on ports 21 and 23 from the internet, were dropped silently. Logs confirmed “FW DROP EXT->DMZ” entries, validating firewall enforcement.
DMZ to Internal FTP Attempt: DMZ server tried to initiate FTP to the internal host, which failed. The connection was blocked and logged as “FW DROP DMZ->INT”, confirming strict internal network protection.
Internal Telnet to DMZ: An internal client tried Telnet to 10.9.0.5 (port 23), which timed out. Only SSH and HTTP are permitted to DMZ, proving the firewall’s service-specific rules.
DMZ to Internal HTTP Probe: A DMZ host tried to access internal HTTP services and was blocked. The attempt was logged, confirming the firewall’s DMZ-to-Internal isolation is working.
External Access to Unauthorized Ports: Nmap scans from external sources (except port 80) returned “filtered.” Attempts to access ports like 22, 81, and 3389 received no response, proving stealth protection.

Allowed Traffic Tests (Legitimate Business Connectivity)

External Access to DMZ Web Server: HTTP requests from external users to the public web server (10.9.0.5) succeeded. Verified using curl and logs showing accepted port 80 connections.
Internal Access to DMZ Web Server: HTTP requests from internal clients to the public web server (10.9.0.5) succeeded. Verified using curl and logs showing accepted port 80 connections.
Internal SSH to DMZ and Router: SSH from internal hosts to DMZ (10.9.0.5) and router (192.168.60.1) was successful. Admin access worked, while SSH from DMZ was denied, as expected.

Additional Hardening in Configuration

I have implemented several advanced hardening measures that significantly enhance the security and resilience of its firewall setup. The configuration adopts a default DROP policy, which blocks all unsolicited traffic unless explicitly permitted, reducing the risk of exposed services and making the network less visible to automated scans. Stateful inspection is used to allow only valid return traffic, ensuring that unauthorized or malformed packets are dropped, offering basic protection against certain DoS attempts. The firewall also includes detailed logging of dropped packets, enabling the security team to monitor for suspicious activity and respond quickly to potential threats.

Additionally, anti-scan rules proactively block stealthy reconnaissance techniques like Null, Xmas, and FIN scans, helping to hide open ports from attackers. A rate-limiting rule on port 80 restricts the number of concurrent connections per IP, preventing a single host from overloading the web server. The router itself is hardened by running only essential services, with unnecessary ports (like HTTP or SNMP) disabled to reduce the attack surface. Furthermore, NAT combined with private IP addressing ensures that internal systems are not directly reachable from the outside, adding both network segmentation and obscurity. Collectively, these measures form a defense-in-depth strategy that not only blocks common threats but also provides administrators with visibility and control to detect and respond to more sophisticated attacks early.

Maintenance and Future Recommendations

To sustain its strong security posture, we suggest that Luna Bags regularly audit firewall rules to align with evolving business needs and remove outdated entries. Log monitoring with alerts or SIEM integration is crucial for spotting anomalies like excessive “DROP INVALID” entries. All systems, including the router and web servers, must be kept patched to guard against known vulnerabilities. As traffic scales, additional throttling using iptables modules can help mitigate abuse. Strong VPN security, with multi-factor authentication and access reviews, is vital due to its direct link to internal resources. Finally, periodic penetration testing should be conducted to validate and enhance the firewall’s resilience against real-world threats.

Rule Proposal

Attack Stimulation performed

DEV Community: Prem Kumar Santhanam

NTLM vs Kerberos vs LDAP : Best Authentication for E-commerce

NT LAN Manager (NTLM) Authentication

What It Is

Purpose

How They Work

Where They Are Used

Implementing on the company network

Strengths

Weaknesses

Common Attacks

Kerberos

What It Is

How They Work

Where They Are Used

Implementing on the company network

Strengths

Weaknesses

Common Attacks

Lightweight Directory Access Protocol (LDAP)

What It Is

Purpose

How They Work

Where They Are Used

Implementing on the company network

Strengths

Weaknesses

Common Attacks

Conclusion

Google Gemini Security Incident: AI Test Reached Three Real Companies

What Google confirmed

Rumors that are actually not in play

The actual failure chain

What's in It for Companies

Controls that would have helped

For AI evaluation teams

For every company

The harder governance question

The security engineer's takeaway

WSO2 Vulnerability CVE-2026–5430 Explained: How Attackers Are Bypassing Authentication in the Wild

Security Advisory: security.docs.wso2.com

CVE-2026–5430:

What’s Actually Broken

The Timeline Tells You Something About Attacker Behavior

Why This Should Change How You Think About Patch Prioritization

What Detection Actually Looks Like Here

The Broader Point for Anyone Running Identity Infrastructure

Complete SIEM Implementation Guide: Log Collection, Correlation Rules, Alerting, and Dashboards

Prerequisites

Overview of the tasks

Task 1: Set up an Elastic Account

Task 2: Setting up the Linux VM

Task 3: Setting up the Agent to Collect Logs

Task 4: Generating Security Events on the Kali VM

Task 5: Querying for Security Events in the Elastic SIEM

Task 6: Create a Dashboard to Visualize the Events

Task 7: Create an Alert

Additional Observations:

Understand Authentication — NTLM vs Kerberos vs LDAP

NT LAN Manager (NTLM) Authentication

What It Is

Purpose

How They Work

Where They Are Used

Implementing on the company network

Strengths

Weaknesses

Common Attacks

Kerberos

What It Is

How They Work

Where They Are Used

Implementing on the company network

Strengths

Weaknesses

Common Attacks

Lightweight Directory Access Protocol (LDAP)

What It Is

Purpose

How They Work

Security Advisory:

security.docs.wso2.com