DEV Community: Marek „Netbe” Lampart

Social Media as a Digital Identity Layer — The Security Problem Developers Should Understand

Marek „Netbe” Lampart — Thu, 17 Sep 2026 11:05:22 +0000

Social media accounts are no longer just pages containing a profile picture, posts and followers.

They increasingly act as a digital identity layer connecting users with applications, APIs, authentication providers, business platforms and third-party services.

That changes the security model.

A compromised social media account may no longer mean simply losing access to a profile. It can mean losing access to connected applications, OAuth integrations, business tools, recovery channels and other services that trust that identity.

I recently explored this topic in more detail here:

Social media przestają być tylko profilami. Stają się warstwą tożsamości cyfrowej

The identity graph

Modern applications rarely operate as isolated systems.

A single user identity can be connected to:

User
 │
 ├── Social Account
 │    ├── OAuth
 │    ├── Sessions
 │    └── Recovery
 │
 ├── SaaS Applications
 │
 ├── Developer Platforms
 │
 ├── Business Accounts
 │
 ├── APIs
 │
 └── Third-Party Integrations

The result is an identity graph.

The more connections an account has, the more valuable the account becomes to an attacker.

This is why developers should stop thinking about authentication as simply:

username + password

The real attack surface is much larger.

OAuth changes the attack model

OAuth makes integrations easier, but it also introduces additional trust relationships.

A user may authorize an external application to access parts of their account without giving that application the password.

From a security perspective, this means the following components matter:

access tokens
refresh tokens
scopes
redirect URIs
authorization codes
session cookies
token storage
application permissions

A compromised OAuth integration can become an indirect path into the user's digital identity.

Developers should therefore treat OAuth permissions as security boundaries, not merely implementation details.

Sessions are credentials too

One of the most common mistakes is focusing heavily on password protection while underestimating active sessions.

An attacker who obtains a valid session token may not need the password at all.

Conceptually:

Password
   ↓
Authentication
   ↓
Session Token
   ↓
Authenticated Application

If the session token is stolen:

Attacker
   ↓
Stolen Session
   ↓
Authenticated Account

The password becomes irrelevant until the session is invalidated.

Applications should therefore consider:

short-lived access tokens
secure cookie attributes
token rotation
session revocation
device/session management
suspicious-login detection
reauthentication for sensitive operations

Account recovery is part of the attack surface

Recovery mechanisms are often weaker than the primary authentication mechanism.

An attacker may target:

Password reset
Email recovery
Phone recovery
Backup codes
Trusted devices
OAuth providers
Support processes

This creates an important security principle:

The effective security of an account is limited by its weakest recovery path.

Strong MFA does not help much if an attacker can bypass it through a poorly protected recovery mechanism.

Social engineering becomes more powerful after compromise

Social accounts contain context.

Contacts.

Messages.

Professional relationships.

Previous conversations.

Public information.

Business affiliations.

Once an attacker gains control, the compromised account can become a highly convincing social-engineering platform.

For example:

Compromised Account
        ↓
Trusted Identity
        ↓
Convincing Message
        ↓
Victim
        ↓
Malicious Link / OAuth Request
        ↓
Second Compromise

The original compromise can therefore become the infrastructure for another attack.

Business accounts are especially sensitive

A personal social account and a company account do not have the same security impact.

Business identities can provide access to:

advertising platforms
payment systems
analytics
customer communication
publishing systems
brand accounts
developer integrations
administrative functions

An attacker does not necessarily need access to the company's internal network.

Compromising an externally trusted identity can be enough to cause serious damage.

What developers should build

Applications that depend on external identity providers should assume that identity compromise is possible.

A resilient architecture should include:

1. Minimal OAuth scopes

Request only the permissions that the application actually needs.

Avoid:

Full account access

when the application requires:

Basic profile information

Least privilege applies to identity integrations too.

2. Secure token storage

Never expose long-lived tokens to client-side code unnecessarily.

Tokens should be protected using appropriate server-side storage and access controls.

3. Strong redirect URI validation

OAuth redirect handling must be strict.

Do not rely on loose matching or user-controlled redirect destinations.

4. Session management

Provide users with the ability to:

view active sessions
revoke sessions
revoke connected applications
rotate credentials
force reauthentication

5. Step-up authentication

Sensitive actions should require stronger verification.

For example:

Normal login
    ↓
Authenticated session
    ↓
Sensitive operation
    ↓
Reauthentication / MFA
    ↓
Action allowed

This reduces the impact of a stolen session.

Treat identity as infrastructure

Developers are used to thinking about infrastructure as servers, databases, networks and cloud services.

Identity belongs in the same category.

If an application depends on an external identity provider, then that provider becomes part of the application's security architecture.

The dependency graph may look like:

Application
   │
   ├── Identity Provider
   │
   ├── OAuth
   │
   ├── Session Infrastructure
   │
   ├── Email
   │
   └── Recovery System

Every one of those dependencies can become an attack path.

Practical security checklist

For applications using social or external identity providers:

[ ] Use MFA where available
[ ] Minimize OAuth scopes
[ ] Protect access and refresh tokens
[ ] Validate OAuth redirect URIs
[ ] Implement secure session management
[ ] Support session revocation
[ ] Support OAuth integration revocation
[ ] Require reauthentication for sensitive actions
[ ] Protect password recovery
[ ] Monitor suspicious authentication activity
[ ] Log authentication and authorization events
[ ] Avoid unnecessary long-lived credentials

The bigger problem

The security model of social media has changed.

These platforms are increasingly becoming identity hubs rather than isolated communication services.

That means developers need to think beyond:

"Can the user log in?"

The better questions are:

What does this identity control?

What applications trust it?

What tokens were issued?

What happens if the session is stolen?

Can recovery bypass MFA?

Which integrations can be revoked?

What happens after the account is compromised?

Those questions describe the real attack surface.

Conclusion

Digital identity is becoming interconnected.

Social accounts can authenticate applications, authorize integrations, maintain persistent sessions and serve as recovery channels.

That makes identity security an architectural problem.

For developers, the lesson is simple: do not protect only the login screen. Protect the entire identity graph.

MikroTik RouterOS Is Under Active Attack: What MikroTrick Means for Network Security

Marek „Netbe” Lampart — Sun, 06 Sep 2026 16:27:09 +0000

MikroTik RouterOS has just become a very practical security problem, not another vulnerability that can sit quietly in a vulnerability database.

CERT Polska has confirmed active exploitation of a chain of vulnerabilities in RouterOS that can allow an attacker to gain full control of a MikroTik router without authentication when SSH remote access is enabled. The chain has been named MikroTrick.

This matters because a compromised router is not just another compromised endpoint. It sits in the middle of the network.

What is MikroTrick?

MikroTrick is not a single vulnerability. It is a chain involving multiple RouterOS security issues.

The dangerous combination allows an attacker to reach full device compromise through the SSH service without first having valid credentials.

That changes the threat model considerably.

An exposed SSH service is normally protected by authentication. With this attack chain, that assumption can no longer be trusted on affected RouterOS installations.

CERT Polska coordinated the disclosure of six RouterOS vulnerabilities and confirmed that two of them can be combined to achieve full device takeover.

MikroTik has already released fixed RouterOS versions:

RouterOS 7.24.2
RouterOS 7.23.5
RouterOS 6.49.21

Administrators should upgrade immediately rather than waiting for exploitation indicators to appear.

Why Router Compromise Is Different

Compromising a workstation gives an attacker access to one machine.

Compromising a router can give them a strategic position inside the entire network.

A compromised RouterOS device may allow an attacker to manipulate:

DNS configuration
firewall rules
routing
NAT
VPN configuration
traffic forwarding
administrative accounts
network monitoring
remote-access infrastructure

The attacker may also use the router as a foothold for attacking systems behind it.

This is why network appliances are particularly attractive targets. They are trusted infrastructure, frequently exposed to the Internet, and often monitored less aggressively than Windows or Linux servers.

The SSH Problem

The attack is especially relevant to organizations that expose RouterOS SSH to untrusted networks.

MikroTik's own security advisory currently confirms that a RouterOS vulnerability was fixed across its release channels and recommends upgrading. Detailed technical information was initially withheld to give administrators time to patch.

That window is effectively closing now that active exploitation has been identified.

If SSH is reachable from the Internet, the router should be considered high priority.

Do not assume that changing the SSH port is sufficient protection.

Security through obscurity does not solve a vulnerability in the SSH implementation itself.

What Administrators Should Do

The first step is obvious:

Patch RouterOS.

Check the running version and upgrade to a fixed release appropriate for your RouterOS branch.

Then reduce the attack surface.

SSH management should not be exposed globally unless there is a very good operational reason. Restrict management access with firewall rules and allow only trusted administration networks or VPN endpoints.

Also review:

/ip service
firewall rules
administrator accounts
active sessions
SSH configuration
recent configuration changes
unusual DNS settings
unexpected NAT rules
unexpected firewall rules
suspicious scheduled tasks or scripts

A firmware update does not automatically tell you whether someone already compromised the router.

That distinction matters.

Patching stops the next attack. It does not undo the previous one.

Assume Compromise If SSH Was Exposed

If a vulnerable RouterOS device had SSH exposed to the Internet during the exploitation window, administrators should investigate it rather than simply applying the update and moving on.

Look for unexpected administrative users and configuration changes.

One particularly interesting indicator reported in connection with current RouterOS exploitation is an unexpected SSH user named -2. Security researchers have warned that affected devices should be checked for signs of compromise.

The exact indicators will evolve as researchers publish more technical details, so incident response should not depend on one IOC.

If compromise is suspected, preserve logs and configuration information before making extensive changes.

MikroTik Has Been Here Before

This is not the first time attackers have shown interest in MikroTik infrastructure.

RouterOS has previously been targeted through vulnerabilities that allowed attackers to read files, escalate privileges, obtain root-level access, build botnets, redirect traffic and abuse compromised routers for other purposes.

That history makes MikroTrick particularly uncomfortable.

MikroTik routers are not niche devices sitting in isolated laboratories. They are deployed as Internet gateways, wireless infrastructure, VPN endpoints and core network equipment.

A successful compromise therefore has consequences beyond the device itself.

The Bigger Lesson

The interesting part of MikroTrick isn't just the vulnerability chain.

It is the architecture around it.

Network devices are often treated as infrastructure rather than computers. They receive less endpoint telemetry, fewer security agents and sometimes fewer emergency patching cycles.

That is exactly what attackers want.

A router with an Internet-facing management interface should be treated like any other Internet-facing server.

Patch it.

Restrict it.

Monitor it.

And assume that a critical management-plane vulnerability will eventually be exploited.

The current MikroTrick campaign is a good reminder that the perimeter is not dead — attackers are simply attacking the devices that control it.

For the technical breakdown and the latest details on the MikroTrick attack, see MikroTik RouterOS Is Under Active Attack — MikroTrick Can Take Over the Router on Bugstoday.

Sources

CERT Polska — Critical vulnerabilities in MikroTik RouterOS are being actively exploited
MikroTik — RouterOS Security Announcements
CISA — MikroTik RouterOS Security Advisory
Security researchers monitoring the MikroTrick exploitation campaign

CVSS Is Not Enough: How to Prioritize Vulnerabilities in Real Environments

Marek „Netbe” Lampart — Sat, 29 Aug 2026 16:43:26 +0000

CVSS Is Not Enough: How to Prioritize Vulnerabilities in Real Environments

A vulnerability scanner can produce thousands of findings.

A security team still has to decide what gets fixed first.

That is where vulnerability management becomes difficult.

The obvious approach is to sort everything by CVSS score. Critical vulnerabilities go to the top, medium findings go lower, and low-severity issues wait for the next maintenance cycle.

It sounds reasonable.

It can also produce the wrong priorities.

CVSS describes technical severity. It does not know how your infrastructure is configured, whether an affected service is exposed to the Internet, whether an exploit is available, or whether attackers are already using the vulnerability.

Those factors can completely change the risk.

Start With the Attack Path

Instead of asking only:

How severe is this vulnerability?

ask:

How could an attacker reach it?

A useful starting point is to map the attack path:

Internet
   |
   v
Exposed Service
   |
   v
Vulnerable Component
   |
   v
Initial Access
   |
   v
Privilege Escalation
   |
   v
Sensitive System

A vulnerability sitting at the beginning of this chain deserves more attention than an identical vulnerability buried behind several security controls.

The software bug is the same.

The exposure is not.

CVSS Is a Starting Point

CVSS remains useful for comparing vulnerabilities.

It provides standardized information about characteristics such as:

attack vector,
attack complexity,
privileges required,
user interaction,
confidentiality impact,
integrity impact,
availability impact.

But a CVSS score is not an organization's risk score.

Imagine a critical vulnerability affecting a development server that is isolated from the Internet.

Now compare it with a lower-scoring vulnerability affecting an Internet-facing authentication gateway.

The second system may deserve immediate attention because the attack path is much shorter.

Security teams should therefore treat CVSS as one input into prioritization rather than the final decision.

Exposure Changes the Calculation

Internet exposure is one of the simplest factors to evaluate.

Ask:

Is the vulnerable service reachable from the Internet?
Is it exposed through a VPN?
Is authentication required?
Is the service behind a WAF?
Is access restricted to specific IP ranges?
Can the vulnerable functionality be disabled?

An Internet-facing system can be continuously scanned by automated tools.

Attackers do not need to know the organization personally.

They can discover vulnerable software through mass scanning.

This makes externally exposed infrastructure particularly important during emergency patching.

Exploit Availability Matters

A vulnerability with no known exploit is not equivalent to one with a reliable public exploit.

There is a difference between:

Vulnerability disclosed

and:

Vulnerability disclosed
        +
Working exploit

The second situation lowers the barrier to exploitation.

Security teams should therefore monitor more than vulnerability databases.

They should track:

proof-of-concept releases,
exploit repositories,
vendor advisories,
threat intelligence,
exploitation reports,
and CISA's Known Exploited Vulnerabilities catalog.

The moment reliable exploitation becomes possible, the priority may need to change.

Active Exploitation Is the Biggest Signal

The strongest warning sign is simple:

Attackers are already exploiting the vulnerability.

At that point, theoretical risk becomes observed activity.

A recent Citrix NetScaler case illustrates the difference. CVE-2026-8452 has moved into active exploitation, with researchers observing attackers deploying web shells and executing discovery commands on compromised appliances. CISA has also added the vulnerability to its KEV catalog.

That changes the remediation decision.

This is no longer:

"We should probably patch this soon."

It becomes:

"We need to determine whether our systems were exposed and potentially compromised."

Patching and Incident Response Are Different Tasks

One of the most important distinctions in vulnerability management is that patching does not automatically mean remediation is complete.

Suppose an Internet-facing appliance was vulnerable for two weeks.

An attacker exploited it on day seven.

The security team installs the vendor update on day fourteen.

The vulnerability is now patched.

The attacker may still have:

created persistence,
dropped malicious files,
created accounts,
modified configuration,
stolen credentials,
established outbound communication,
or moved toward another system.

The correct workflow is therefore:

Identify
   |
   v
Patch
   |
   +------> Verify Fix
   |
   v
Investigate Previous Exposure
   |
   v
Monitor

A patch closes the known vulnerability.

It does not erase evidence of previous compromise.

Asset Value Changes Everything

A vulnerability on a random workstation is not necessarily equivalent to the same vulnerability on an identity server.

Think about the systems that sit at important trust boundaries:

Active Directory,
identity providers,
VPN gateways,
certificate authorities,
CI/CD platforms,
Git servers,
database servers,
email infrastructure.

Compromise of one of these systems can provide access to much more than the machine itself.

For example, a compromised Git server may expose:

source code,
deployment scripts,
API keys,
CI/CD credentials,
configuration files,
container definitions,
and internal project information.

The value of the asset should therefore influence remediation priority.

Vulnerability Chaining Makes Simple Scores Misleading

Attackers do not always need one vulnerability to provide complete control.

They can chain multiple weaknesses.

A simplified attack might look like:

Initial Access
      |
      v
Local Privilege Escalation
      |
      v
Credential Theft
      |
      v
Lateral Movement
      |
      v
Domain Access

A vulnerability that only provides local privilege escalation may look less dangerous when viewed independently.

But if another flaw provides initial access to the same machine, the combination becomes much more interesting.

This is why vulnerability management should consider attack paths rather than isolated CVE entries.

Authentication Requirements Matter

Another useful question is whether exploitation requires authentication.

There is a major difference between:

Internet
   ↓
Vulnerable Service
   ↓
Code Execution

and:

Internet
   ↓
Login
   ↓
Valid Account
   ↓
Vulnerable Service
   ↓
Code Execution

The second scenario may require an attacker to obtain credentials first.

That does not make the vulnerability harmless.

It simply changes the attack path.

Security teams should evaluate where those credentials could come from and whether the affected application is exposed to credential-stuffing, phishing, session theft or other attacks.

Don't Forget Configuration

Software versions alone do not always tell the complete story.

Configuration can determine whether a vulnerability is reachable.

Examples include:

open registration,
enabled APIs,
exposed administrative interfaces,
unnecessary services,
permissive firewall rules,
weak access controls,
legacy authentication,
and excessive privileges.

Two organizations can run exactly the same software version and have very different levels of exposure.

This is one reason asset context is so important.

A Practical Prioritization Model

A simple operational model can divide findings into three groups.

Emergency

Prioritize immediately when several of these conditions apply:

active exploitation,
Internet exposure,
public reliable exploit,
remote code execution,
authentication bypass,
privileged infrastructure,
high-value data.

High Priority

Accelerate remediation when there is:

a public PoC,
remote exploitability,
broad deployment,
sensitive application access,
limited authentication requirements,
weak compensating controls.

Standard

Normal remediation may be appropriate when:

exploitation is not known,
the system is isolated,
local access is required,
strong controls reduce exposure,
the asset has limited business value.

These categories should be adapted to the organization's environment.

They are not replacements for formal risk management.

They are a way to avoid treating every CVE as equally urgent.

Verification Is Part of Patching

Installing an update is only one step.

Security teams should verify that:

the expected version is running,
vulnerable components are no longer present,
services were restarted when necessary,
configuration changes were applied,
external scanners no longer detect the vulnerability,
and the affected system is still behaving correctly.

Without verification, a patch ticket can be marked complete while the vulnerability remains exploitable.

This happens more often than organizations would like to admit.

Automate the Boring Parts

Automation can significantly improve vulnerability management.

Useful automation includes:

asset discovery,
software inventory,
vulnerability scanning,
patch deployment,
configuration checks,
external exposure monitoring,
and remediation verification.

But automation should not make the final risk decision by itself.

A scanner may tell you:

CVSS 9.8.

It may not know that the affected server is disconnected from the Internet and protected by multiple controls.

Likewise, it may not understand that a CVSS 7.5 vulnerability exists on the company's externally exposed identity infrastructure.

Human context still matters.

Build Priority Around Attacker Behavior

The best vulnerability-management programs continuously update their priorities.

A finding that was low priority last week can become urgent today.

The trigger might be:

a new exploit,
active exploitation,
a CISA KEV entry,
publication of technical details,
discovery of vulnerable Internet-facing systems,
or evidence that attackers are targeting a specific product.

This means vulnerability management cannot be a monthly spreadsheet exercise.

The threat changes faster than the spreadsheet.

A Better Daily Question

Instead of asking:

How many vulnerabilities do we have?

ask:

Which vulnerabilities can realistically be used against our most important systems right now?

That question forces the security team to combine:

Vulnerability Data
        +
Asset Inventory
        +
Network Exposure
        +
Exploit Intelligence
        +
Threat Activity
        +
Business Context

That combination produces a much more useful security picture.

Conclusion

CVSS is valuable.

It is also only part of the story.

Real-world vulnerability risk depends on exposure, exploitability, active exploitation, asset value, configuration and the attack paths available to an adversary.

The most dangerous vulnerability is not necessarily the one with the highest number.

Sometimes it is the vulnerability that is already being exploited against an Internet-facing system that controls access to everything else.

That is why effective vulnerability management is not about producing the longest list of CVEs.

It is about identifying which weaknesses attackers can actually turn into access — and closing those paths before they become incidents.

The Vulnerability Lifecycle: From CVE Disclosure to Active Exploitation

Marek „Netbe” Lampart — Wed, 26 Aug 2026 13:29:52 +0000

A vulnerability does not become dangerous simply because someone assigns it a CVE number.

The real risk usually develops over time.

A researcher discovers a bug.

The vendor investigates it.

A CVE is assigned.

Technical details are published.

Someone creates a proof of concept.

Security researchers reproduce the attack.

Attackers begin adapting the technique.

Eventually, exploitation may appear in the wild.

Understanding this lifecycle is more useful than simply sorting vulnerabilities by CVSS score.

For developers, system administrators and security teams, the important question is not just:

Does this vulnerability affect us?

The more important question is:

Where is this vulnerability in its lifecycle right now?

Stage 1: The Vulnerability Exists

At the beginning, the vulnerability may only be known to the person who discovered it.

This could be:

a security researcher,
an internal security team,
a vendor,
a bug bounty participant,
or an attacker.

At this stage, defenders may know nothing about the issue.

This is the most difficult period to manage because there may be no:

CVE,
patch,
public advisory,
detection signature,
or mitigation guidance.

If attackers discover and exploit the vulnerability before defenders know about it, the issue becomes a zero-day.

Stage 2: Disclosure

Once the vulnerability becomes known, things begin to change.

A vendor advisory may be published.

A CVE may be assigned.

Researchers may release a technical analysis.

Security teams begin checking their environments.

This is where many organizations make their first prioritization decision.

Unfortunately, that decision is often based almost entirely on CVSS.

That is not enough.

Consider two vulnerabilities.

Vulnerability A

```text id="vulnA1"
CVSS: 9.8
Public exploit: No
Active exploitation: No
Internet exposure: Limited
Affected software: Rarely deployed




### Vulnerability B



```text id="vulnB1"
CVSS: 7.8
Public exploit: Yes
Active exploitation: Yes
Internet exposure: High
Affected software: Widely deployed

Which one should be patched first?

The answer depends on your environment.

Real-world risk requires context.

Stage 3: Technical Details Become Public

A vulnerability can exist for a long time without being widely exploitable.

Then someone publishes technical details.

That changes the situation.

Researchers can understand:

the vulnerable component,
the attack surface,
the affected versions,
the conditions required for exploitation,
and possible attack paths.

Technical disclosure can significantly reduce the amount of research required to reproduce an attack.

Attackers do not always need to discover the vulnerability themselves.

They can learn from public research.

This is one reason why security teams should monitor more than CVE databases.

Technical write-ups, conference presentations and security research can provide early warning signals.

Stage 4: Proof of Concept

A proof of concept is often a turning point.

Before a PoC exists, exploitation may require significant research.

After a PoC appears, the vulnerability becomes easier to test.

That does not mean every PoC can immediately compromise a production environment.

Many require modification.

Some work only under specific conditions.

Others demonstrate the underlying vulnerability without providing a complete attack.

But public PoCs can dramatically reduce the barrier to experimentation.

A recent example is the Microsoft Defender issue covered in this BugsToday report about the Microsoft Defender zero-day.

The case demonstrates an important principle.

Even software designed to protect a system can become part of the attack surface.

Security products frequently operate with elevated privileges.

That means a vulnerability affecting a privileged component can potentially have significant consequences.

Stage 5: Exploit Development

A PoC and a production-ready exploit are not always the same thing.

Attackers may need to:

improve reliability,
bypass security controls,
adapt the exploit to different versions,
combine it with another vulnerability,
or integrate it into malware.

This is where exploit development becomes more dangerous.

The attack may evolve from:

```text id="exploit1"
Research Code
↓
Proof of Concept
↓
Reliable Exploit
↓
Automated Exploitation
↓
Malware Integration




Once exploitation becomes reliable and repeatable, defenders have less time to react.

## Stage 6: Vulnerability Chaining

One of the biggest mistakes in vulnerability management is evaluating every CVE independently.

Attackers do not always think that way.

They combine weaknesses.

A simple attack chain could look like this:



```text id="chain1"
Initial Access
      ↓
Authentication Bypass
      ↓
Remote Code Execution
      ↓
Privilege Escalation
      ↓
Persistence
      ↓
Credential Theft

Individually, each vulnerability may have limitations.

Together, they can lead to complete compromise.

A useful example is the SharePoint issue discussed in the BugsToday analysis of the SharePoint authentication bypass.

Authentication weaknesses are particularly important because they target the first security boundary.

If an attacker can bypass authentication, the rest of the application may suddenly become accessible.

And if another vulnerability provides remote code execution, the consequences can become much more serious.

Stage 7: Active Exploitation

The final and most urgent stage is exploitation in the wild.

At this point, the vulnerability is no longer theoretical.

Attackers are using it.

Security teams should immediately investigate:

whether vulnerable systems exist,
whether those systems are exposed,
whether exploitation attempts can be detected,
whether compromise indicators are available,
and whether emergency mitigation is required.

A recent example is the Gitea issue covered in this BugsToday report on active exploitation.

This is where vulnerability management changes into incident response.

The question is no longer:

Should we patch this?

It becomes:

Have we already been compromised?

That distinction is critical.

Building a Better Prioritization Model

Instead of relying exclusively on CVSS, security teams can use a broader model.

For example:

```text id="riskmodel1"
Real-World Risk =
Severity

Exploit Availability
Active Exploitation
Internet Exposure
Asset Criticality
Attack Complexity
Privileges Gained
Potential for Chaining ```

This is not a mathematical formula.

It is a prioritization framework.

The purpose is to force security teams to look beyond a single number.

Questions worth asking

When a new vulnerability appears, ask:

Are we running the affected software?
Which versions are vulnerable?
Is the system Internet-facing?
Is authentication required?
Is a public PoC available?
Is exploitation happening in the wild?
Can the vulnerability be chained?
What privileges does exploitation provide?
Is a patch available?
Are there temporary mitigations?
Do we have logs that could reveal exploitation?
What is the business impact if the system is compromised?

These questions provide much more useful context than CVSS alone.

Data Breaches Are Often the Final Stage

The vulnerability lifecycle does not always end with system compromise.

The next stage can be data theft.

A compromised system may expose:

customer data,
credentials,
API keys,
internal documents,
source code,
financial information,
or sensitive personal records.

The Nutex Health data breach reported by BugsToday is an example of why cybersecurity incidents should not be viewed only through a technical lens.

The initial compromise may take minutes.

The consequences can last for years.

Organizations may face:

incident-response costs,
regulatory investigations,
notification requirements,
reputational damage,
legal consequences,
and continued abuse of stolen information.

What Developers Can Do

Developers are often the first people capable of reducing the attack surface.

That means vulnerability management should not be treated exclusively as a security-team responsibility.

Developers can:

keep dependencies updated,
remove unused packages,
monitor security advisories,
use Software Composition Analysis,
implement secure authentication,
avoid exposing unnecessary APIs,
apply least privilege,
review third-party components,
and maintain accurate asset inventories.

The faster a team can answer:

Are we affected?

the faster it can respond.

Continuous Monitoring Matters

The vulnerability landscape moves quickly.

A CVE published today may have a public PoC tomorrow.

A proof of concept may become an active exploit next week.

A vulnerability that initially appears low priority may suddenly become critical because attackers start using it.

This is why continuous monitoring matters.

Security teams should track:

new CVEs,
vendor advisories,
public PoCs,
exploit repositories,
active exploitation reports,
CISA KEV updates,
attack campaigns,
and relevant data breaches.

Resources such as BugsToday can help follow the transition from newly disclosed Vulnerabilities to public Exploits, active attacks and security incidents.

Final Thoughts

A CVE is not the end of the vulnerability story.

It is often the beginning.

The lifecycle can move through several stages:

```text id="lifecycle1"
Vulnerability Discovery
↓
Disclosure
↓
Technical Analysis
↓
Public PoC
↓
Exploit Development
↓
Attack Chaining
↓
Active Exploitation
↓
Security Incident
↓
Data Breach




Understanding where a vulnerability currently sits in this lifecycle can help developers and security teams make better decisions.

Do not ask only:

> How severe is this CVE?

Also ask:

> How exploitable is it today?

That is often the difference between routine patching and an emergency incident.

---

### Related Reading

* [Microsoft Defender Zero-Day](https://bugstoday.com/microsoft-defender-has-a-zero-day-the-patch-still-doesnt-exist/)
* [Gitea RCE and Active Exploitation](https://bugstoday.com/gitea-rce-is-being-exploited-attackers-are-already-dropping-payloads/)
* [Microsoft SharePoint Authentication Bypass](https://bugstoday.com/microsoft-sharepoint-auth-bypass-gets-a-public-poc-and-the-rce-chain-is-worse/)
* [Nutex Health Data Breach](https://bugstoday.com/nutex-health-confirms-data-breach-sensitive-information-may-be-exposed/)

**BugsToday — Today's Bugs. Tomorrow's Breaches.**

How Tor Works: Understanding Onion Routing and Online Anonymity

Marek „Netbe” Lampart — Thu, 20 Aug 2026 08:23:58 +0000

Tor is probably the most famous privacy network on the internet.

It is also one of the most misunderstood.

For some people, Tor means the Dark Web. For others, it is synonymous with complete anonymity. Neither interpretation is technically accurate.

Tor is a distributed network designed to make it significantly harder to connect a user's network activity with their real IP address and physical location.

Its central technology is called onion routing.

Understanding how it works is essential if you want to understand the modern Dark Web, online anonymity and the limitations of privacy technologies.

What Is Tor?

Tor stands for The Onion Router.

It is an open-source network that routes internet traffic through multiple relays instead of allowing the user's device to communicate directly with the destination.

A conventional connection may look like:

User → Website

A simplified Tor connection looks more like:

User → Guard Relay → Middle Relay → Exit Relay → Website

Each relay has a limited view of the communication.

That separation is one of the fundamental principles behind Tor.

Netbe has a dedicated technical explanation of how the Tor network works, including onion routing and its main risks.

What Is Onion Routing?

The name "onion routing" comes from the idea of multiple layers.

Imagine a message protected by several envelopes.

The first recipient removes one layer and discovers where to send the message next.

The second recipient does the same.

The final recipient receives the message after the previous layers have been removed.

Tor uses a comparable concept with cryptographic layers.

Before traffic enters a Tor circuit, the Tor client establishes encryption for the different relay positions.

Each relay can then process only the information necessary to perform its part of the job.

This creates a chain in which no ordinary relay should have a complete picture of both the user and the final destination.

The Three Main Tor Relays

A typical Tor circuit contains three main relay positions.

1. Guard Relay

The first relay is usually called the guard relay or entry guard.

It receives traffic directly from the user.

Consequently, the guard can see the user's IP address.

However, it should not know the final destination of the connection.

This is an important part of the Tor trust model.

2. Middle Relay

The middle relay sits between the entry and exit points.

It primarily knows which relay sent the traffic to it and which relay should receive it next.

It should not know the original user's IP address or the final website.

3. Exit Relay

The exit relay is the point where traffic leaves the Tor network when the user connects to a conventional internet website.

The destination normally sees the exit relay's IP address, not the user's original address.

This is one of the reasons Tor can provide network-level anonymity.

However, there is an important limitation.

The exit relay does not automatically encrypt the connection all the way to the destination.

That responsibility belongs to the application protocol, such as HTTPS.

Tor Does Not Replace HTTPS

This distinction is frequently misunderstood.

Tor provides protection within its routing architecture, but it does not magically turn every website connection into an end-to-end encrypted session.

Consider two examples.

Tor + HTTP

User → Tor → Exit Relay → HTTP Website

The traffic between the exit relay and the website is not protected by HTTPS.

Tor + HTTPS

User → Tor → Exit Relay → HTTPS Website

HTTPS provides encryption between the browser and the website.

This is why Tor and HTTPS should be considered complementary technologies.

Tor helps obscure the network origin.

HTTPS protects the application-level connection.

How Does a Tor Circuit Work?

Tor does not normally establish one permanent route for everything a user does.

Instead, the client creates circuits consisting of several relays.

The client performs cryptographic handshakes with the relays and establishes the keys necessary for communication.

The resulting structure means that each relay has only part of the information needed to understand the complete route.

A simplified example:

Alice → Guard → Middle → Exit → Website

The guard knows Alice.

The exit knows the website.

The middle knows the relays immediately before and after it.

No ordinary relay is supposed to have the entire picture.

This separation is fundamental to the anonymity model.

Why Is This Better Than a Direct Connection?

Consider a normal internet connection.

A website can normally receive the user's public IP address.

That address may provide information about the user's network or approximate geographical location.

With Tor, the website normally receives the IP address of the exit relay.

The website therefore cannot simply look at the connection and see the user's original public IP address.

This doesn't mean the user becomes impossible to identify.

It means one important source of identifying information has been separated from the destination.

That distinction matters.

Tor and the Dark Web Are Not the Same Thing

Another common misconception is that Tor equals Dark Web.

It doesn't.

Tor can be used to access ordinary websites.

It can also be used to access services that exist entirely inside the Tor network.

Those services are commonly known as onion services and use .onion addresses.

Netbe's article on Tor Browser and its capabilities in the Darknet explains this relationship in more detail.

In other words:

Tor = network technology.

Dark Web = hidden services and content operating through specialized networks.

The two concepts overlap, but they are not identical.

How Do .onion Services Work?

A conventional website normally has a publicly reachable server and a public IP address.

An onion service is designed differently.

Its server does not need to expose a conventional public IP address to users.

Both sides of the communication can remain within the Tor network.

A simplified model is:

User → Tor Network → Onion Service

rather than:

User → Tor Network → Public Internet → Server

This architecture can protect the location of the server as well as the identity of the user.

Netbe also has a detailed technical article explaining how Onion Services work, including the mechanisms used to establish communication without directly exposing the server's IP address.

Why Is Tor Slower?

There is an obvious trade-off.

A normal connection tries to take an efficient path between the user and destination.

Tor deliberately introduces additional relays.

Every additional hop adds latency.

Encryption and cryptographic processing add further overhead.

As a result, Tor is generally slower than a direct connection or a conventional VPN.

This isn't necessarily a defect.

It is partly the price of the architecture.

Tor prioritizes privacy and anonymity characteristics over raw speed.

Can Tor Make You Completely Anonymous?

No.

This is the most important point in understanding Tor.

The technology can protect against certain forms of network-level identification, but it cannot protect users from their own mistakes.

Imagine someone using Tor but then logging into their personal Google account.

The network may hide their IP address from Google, but the user has voluntarily identified themselves through the account.

The same applies to:

using a personal email account,
publishing your real name,
reusing a recognizable username,
revealing personal information,
downloading unsafe documents,
installing unusual browser extensions,
changing privacy settings unnecessarily.

The network can protect the connection.

It cannot erase information you deliberately provide.

Browser Fingerprinting

IP addresses are not the only way websites can distinguish users.

Another technique is browser fingerprinting.

A website can potentially examine characteristics of the browser and device environment, such as:

screen properties,
language,
browser configuration,
graphics capabilities,
installed fonts,
operating-system characteristics.

Tor Browser attempts to reduce this problem by making users' browser environments more uniform.

This is why aggressive customization can actually be harmful to anonymity.

If your browser becomes unusually unique, you may become easier to distinguish.

For users interested specifically in anonymity, Netbe's analysis of whether Tor is really anonymous is a useful follow-up: Tor and the limits of anonymity.

Traffic Correlation Attacks

Tor also has limitations against very powerful adversaries.

One of the most important theoretical threats is traffic correlation.

Imagine an organization capable of observing traffic entering the Tor network and traffic leaving it.

Even without decrypting the contents, an observer could potentially compare:

timing,
packet volumes,
traffic patterns,
connection duration,
bursts of activity.

If enough information is available, the attacker may be able to correlate the incoming and outgoing traffic.

This is one reason Tor should never be described as an absolute anonymity guarantee.

Its effectiveness depends partly on the capabilities of the adversary.

What About the Tor Exit Node?

The exit node deserves special attention.

When traffic leaves Tor toward the normal internet, the exit relay becomes the apparent source of the connection.

The destination sees the exit relay's IP address.

However, the operator of the exit relay can potentially observe traffic that is not protected by an additional encryption layer such as HTTPS.

This is why users should not treat Tor as a substitute for secure application protocols.

A useful rule is:

Tor protects the route. HTTPS protects the web session.

Using both provides a much stronger security model than relying on either one alone.

Tor vs VPN

Tor and VPN services are often placed into the same category, but their trust models are different.

A VPN usually creates an encrypted connection between the user and a VPN provider.

That provider therefore becomes an important point of trust.

Tor distributes the route across multiple independent relays.

A simplified comparison:

Feature	Tor	VPN
Architecture	Multiple relays	Usually one provider
Destination sees	Exit relay IP	VPN server IP
Typical speed	Lower	Higher
Access to .onion services	Yes	Not inherently
Trust model	Distributed	Provider-centric
Primary goal	Anonymity/privacy	Privacy/security

Neither solution is universally superior.

The right technology depends on the threat model.

Netbe also explores the relationship between these technologies in VPN and Tor: how they compare and how privacy can be improved.

Does Tor Protect Against Malware?

No.

This is another important distinction.

Tor can change how network traffic is routed.

It does not make malicious software harmless.

A Tor user can still encounter:

phishing,
malware,
fake websites,
malicious downloads,
credential theft,
social engineering,
scams.

Privacy and security are related, but they are not identical.

A person can have a highly private connection and still be successfully attacked.

For this reason, operational security remains extremely important.

Netbe's guide to safe Tor usage and the most important security rules covers issues such as browser configuration, extensions, downloads and identity separation.

Why Does Tor Still Matter in 2026?

Despite its limitations, Tor remains one of the most important privacy technologies available to ordinary internet users.

Its value goes beyond the Dark Web.

Tor can support:

anonymous publishing,
journalism,
whistleblower platforms,
censorship resistance,
privacy research,
cybersecurity investigations,
access to onion services.

At the same time, the same infrastructure can be abused by criminals.

This dual-use characteristic is not unique to Tor.

Encryption, cryptocurrencies, VPNs and cloud infrastructure can all be used for legitimate or criminal purposes.

The technology itself does not determine the intent.

The Real Meaning of "Anonymous"

Perhaps the biggest conceptual mistake is treating anonymity as a binary state.

You are not simply either:

anonymous

not anonymous.

Real-world anonymity is better understood as a spectrum influenced by:

network architecture,
browser configuration,
user behavior,
metadata,
application security,
adversary capabilities,
operational security.

Tor can improve one part of that equation substantially.

It cannot solve every part.

Final Thoughts

Tor is not a magic invisibility cloak.

It is a carefully engineered anonymity network that separates the user's network identity from the destination through layered encryption and multiple relays.

The architecture is powerful, but it has limitations.

Tor does not mean perfect anonymity.

Tor does not mean automatic security.

Tor does not mean illegal activity.

And Tor does not equal the Dark Web.

Understanding these distinctions is essential before going deeper into the subject.

The next question is even more important for ordinary internet users:

Is the Dark Web actually illegal?

In the next article, we'll examine the legal side of anonymous networks, what people can legitimately do with privacy technologies, and where activities can cross the line into criminal behavior.

Windows Defender ShieldBreak: What a Local SYSTEM Privilege Escalation Means for Windows Security

Marek „Netbe” Lampart — Tue, 18 Aug 2026 09:30:13 +0000

A vulnerability in antivirus software creates an interesting security problem.

The software that is supposed to detect malicious activity may itself become part of an attack chain.

That is the situation with ShieldBreak, a recently disclosed Windows vulnerability tracked as CVE-2026-69414.

The vulnerability affects the Microsoft Defender Malware Protection Engine and can potentially allow an attacker with local code execution to escalate privileges to SYSTEM.

Microsoft is investigating the issue and preparing a security update.

The latest analysis published on Netbe.pl is available here:

https://netbe.pl/microsoft-is-working-on-a-patch-for-a-new-windows-defender-zero-day-called-shieldbreak/

For Windows administrators, however, the most interesting question is not simply what is ShieldBreak?

It is:

Why can a vulnerability in a security product become so important?

ShieldBreak is a local privilege escalation problem

ShieldBreak should be understood as a local privilege escalation vulnerability.

This is important because it is not the same attack model as a remotely exploitable RCE.

A simplified attack chain looks like this:

Initial Access
      ↓
Code Execution
      ↓
Standard User
      ↓
ShieldBreak
      ↓
Privilege Escalation
      ↓
SYSTEM

An attacker therefore needs some form of initial access to the Windows machine.

That initial access could come from malware, a malicious application, a compromised account or another vulnerability.

ShieldBreak can then potentially provide the attacker with a much more powerful security context.

Why SYSTEM is such a big deal

Windows uses privilege boundaries to prevent applications and users from accessing everything on the system.

A normal account has limited permissions.

SYSTEM is different.

Conceptually:

Standard User
      ↓
Limited Permissions
      ↓
Privilege Escalation
      ↓
SYSTEM
      ↓
Extensive Local Privileges

Obtaining SYSTEM can make many post-exploitation operations easier.

Depending on the environment and other protections, an attacker could potentially attempt to:

modify protected system resources,
manipulate services,
establish persistence,
interfere with security controls,
access sensitive information,
execute additional code,
prepare credential attacks,
move toward other systems.

ShieldBreak itself does not automatically perform all of those actions.

The important part is that privilege escalation removes a major security boundary.

The unusual part: the vulnerable component is Defender

This is where ShieldBreak becomes particularly interesting.

Microsoft Defender is not an ordinary desktop application.

It is deeply integrated into Windows and needs extensive access to the operating system to perform its job.

Defender analyzes files, processes and system activity.

That creates a fundamental security trade-off:

Deep System Access
        +
High Privileges
        +
Security Visibility
        =
Strong Protection

But:

Deep System Access
        +
High Privileges
        +
Software Vulnerability
        =
Potentially Powerful Attack Surface

This is not unique to Microsoft Defender.

The same principle applies to:

EDR agents,
antivirus engines,
backup agents,
vulnerability scanners,
endpoint management software,
security monitoring tools.

The more privileges a security product requires, the more important its own security becomes.

Security software is still software

This sounds obvious, but it is one of the most important principles in modern endpoint security.

Administrators sometimes implicitly treat security software as a trusted layer outside the normal attack surface.

That is dangerous.

Security products need:

patch management,
vulnerability assessment,
logging,
monitoring,
least privilege,
configuration management,
incident response.

A vulnerability inside an endpoint security product can potentially be more valuable to an attacker than a vulnerability inside an ordinary application because the security product may already have privileged access.

ShieldBreak and the RoguePlanet connection

ShieldBreak has also been discussed in the context of an earlier Defender vulnerability known as RoguePlanet.

The broader security-research process is worth understanding.

A vulnerability is discovered.

A vendor develops a mitigation.

Researchers then analyze the mitigation.

Sometimes that research reveals another path around the original security boundary.

The cycle looks like:

Vulnerability
      ↓
Vendor Fix / Mitigation
      ↓
Patch Analysis
      ↓
Security Research
      ↓
Alternative Attack Path
      ↓
New Vulnerability / Technique

This is one reason why vulnerability management cannot stop at:

"The patch was installed."

Security teams also need to monitor whether the mitigation remains effective against new techniques.

Why Windows 11 needs defense in depth

ShieldBreak is a good example of why modern Windows security should never depend on a single product.

A stronger Windows 11 architecture can combine several layers:

Secure Boot
      ↓
TPM 2.0
      ↓
VBS
      ↓
HVCI
      ↓
Microsoft Defender
      ↓
Exploit Protection
      ↓
ASR
      ↓
Application Control
      ↓
Credential Protection
      ↓
EDR / Monitoring

Each layer addresses a different part of the attack surface.

Netbe.pl has a useful technical overview of the built-in Windows 11 security model:

https://netbe.pl/wbudowane-zabezpieczenia-windows-11-jak-dziala-microsoft-defender-krok-po-kroku/

The important principle is defense in depth.

If one security mechanism has a vulnerability, other controls should still be able to slow down or detect the attack.

Defender does more than signature-based antivirus

Modern Microsoft Defender is much more than a traditional antivirus scanner.

It combines multiple mechanisms, including:

signatures,
heuristics,
cloud-based analysis,
behavioral monitoring,
exploit protection,
tamper protection,
ransomware protection,
integration with Microsoft's endpoint security ecosystem.

Netbe's analysis of Defender and zero-day protection explains this architecture in more detail:

https://netbe.pl/automatyczne-wykrywanie-i-lagodzenie-luk-zero-day-jak-windows-defender-i-smartscreen-w-windows-11-sobie-radza/

This is relevant to ShieldBreak because a vulnerability in one component does not automatically mean that every other Defender security mechanism stops working.

Security architecture is layered.

Why ASR matters

Attack Surface Reduction (ASR) is another important Windows security layer.

ASR rules attempt to prevent behaviors commonly abused during attacks.

For example, an organization may use ASR to restrict suspicious behavior originating from Office applications or other common attack vectors.

The model is:

Malicious Code
      ↓
Suspicious Behavior
      ↓
ASR Rule
      ↓
BLOCK

ASR does not patch ShieldBreak.

That distinction is critical.

Instead, it can potentially break another stage of the attack chain.

Netbe also covers ASR and related endpoint protections in its practical Windows security material:

https://netbe.pl/praktyczne-zabezpieczenia-windows-konfiguracja-asr-applocker-i-analiza-logow-sysmon-krok-po-kroku/

The objective is not to find one magical security feature.

The objective is to make the attacker's entire chain harder to execute.

Exploit Protection is another layer

Windows also includes Exploit Protection, which provides mitigation mechanisms designed to make exploitation more difficult.

Again, it should not be considered a replacement for patching.

The correct relationship is:

Patch
  +
Exploit Mitigation
  +
Application Control
  +
Endpoint Protection
  +
Monitoring

This is significantly stronger than relying on one security mechanism.

Netbe has a dedicated article discussing exploit protection and anti-exploit mechanisms:

https://netbe.pl/dodatkowe-narzedzia-zabezpieczajace-np-anty-malware-anty-exploit-i-ich-rola-w-wzmacnianiu-ochrony/

Least privilege remains fundamental

ShieldBreak also demonstrates why standard user accounts remain important.

Imagine malware starts under a normal account:

Malware
   ↓
Standard User
   ↓
Limited Permissions

Now compare that with malware running under an administrator account:

Malware
   ↓
Administrator
   ↓
Already Extensive Permissions

A local privilege escalation vulnerability is obviously more useful when the attacker starts with access to a machine but has not yet obtained administrative privileges.

Least privilege does not eliminate the vulnerability.

It can, however, reduce the attacker's initial capabilities.

This principle remains relevant even in highly automated endpoint-security environments.

What happens after SYSTEM?

Privilege escalation is often not the final goal.

It can be a bridge to the next stage.

For example:

Phishing
   ↓
Malware
   ↓
Standard User
   ↓
Local Privilege Escalation
   ↓
SYSTEM
   ↓
Credential Access
   ↓
Persistence
   ↓
Lateral Movement

This is why an LPE vulnerability can be significant even when it is not remotely exploitable.

Attackers frequently chain multiple techniques.

One vulnerability provides the foothold.

Another provides privilege escalation.

Another technique provides credentials.

Another provides lateral movement.

The complete attack is much more dangerous than any individual step.

Credential protection becomes important here

Once an attacker obtains a privileged context, credentials become an attractive target.

Windows provides mechanisms designed to make credential theft more difficult.

Credential protection should therefore be considered alongside endpoint protection and privilege management.

The general security model becomes:

Initial Access
      ↓
Endpoint Detection
      ↓
Privilege Escalation Attempt
      ↓
Exploit Mitigation
      ↓
Credential Protection
      ↓
Network Monitoring

Even if one layer fails, the attacker should still encounter additional barriers.

Why administrators should not disable Defender

A vulnerability in Microsoft Defender might tempt some users to disable the product.

That would generally be the wrong response.

Disabling Defender removes an important security layer while doing nothing to eliminate other vulnerabilities or malware.

A better strategy is:

Vulnerability Discovered
        ↓
Keep Security Controls Enabled
        ↓
Apply Available Mitigations
        ↓
Monitor
        ↓
Install Official Microsoft Fix

Not:

Vulnerability Discovered
        ↓
Disable Antivirus

Netbe's guide to Microsoft Defender configuration also emphasizes the importance of maintaining features such as real-time protection, cloud protection, Tamper Protection, Controlled Folder Access and exploit protection:

https://netbe.pl/najlepsze-ustawienia-microsoft-defender-przeciw-ransomware/

The exact configuration should depend on the system and organization, but the general principle remains valid:

Do not remove a security layer because another security problem exists.

Patch management is still the priority

The existence of defense-in-depth mechanisms does not change the most important remediation step.

When Microsoft releases the official ShieldBreak fix, administrators should deploy it.

This is particularly important because Windows vulnerabilities are continuously being discovered and analyzed.

Microsoft's August 2026 security release already addressed more than 400 vulnerabilities, including an actively exploited Windows zero-day.

Netbe covered that security release here:

https://netbe.pl/microsoft-patches-400-windows-vulnerabilities-one-zero-day-is-already-being-exploited/

This illustrates the reality of enterprise vulnerability management:

Patch
  ↓
Monitor
  ↓
New Vulnerability
  ↓
Patch
  ↓
New Research
  ↓
Patch Again

There is no final state where an operating system is simply "fully secure."

Windows administrators should focus on the attack chain

Instead of asking only:

"Is ShieldBreak patched?"

security teams should ask a broader set of questions:

Can an attacker obtain initial access?

Review:

phishing protection,
email security,
application control,
web filtering,
user privileges.

Can malicious code execute?

Review:

Defender,
ASR,
WDAC,
AppLocker,
SmartScreen.

Can the attacker escalate privileges?

Review:

Windows security updates,
exploit mitigations,
EDR telemetry,
local administrator privileges.

Can credentials be stolen?

Review:

Credential Guard,
authentication policies,
privileged accounts,
credential monitoring.

Can the attacker move laterally?

Review:

segmentation,
firewall policies,
administrative protocols,
identity security,
endpoint telemetry.

This approach is much more useful than treating one CVE as an isolated event.

What should Windows administrators do now?

A practical response to the current ShieldBreak situation is:

1. Keep Windows updated

Verify that current security updates are installed.

2. Keep Defender enabled

Do not remove endpoint protection because of the vulnerability.

3. Update Defender components

Keep security intelligence and Defender components current.

4. Use standard user accounts

Avoid unnecessary local administrator access.

5. Review exploit mitigations

Verify that Windows Exploit Protection is appropriately configured.

6. Review ASR policies

Use Attack Surface Reduction where appropriate.

7. Monitor endpoint telemetry

Look for unusual process creation, privilege escalation and attempts to interfere with security controls.

8. Deploy Microsoft's dedicated ShieldBreak fix

Once the official security update becomes available, prioritize deployment according to the organization's vulnerability-management process.

Is ShieldBreak a reason to panic?

No.

There is an important difference between:

"A vulnerability has been publicly disclosed."

and:

"Every Windows 11 computer is compromised."

Those statements are not equivalent.

ShieldBreak is particularly interesting because it targets a highly privileged security component and can potentially provide SYSTEM privileges after initial local access.

That makes it a serious vulnerability.

But the practical response for most users is straightforward:

Update Windows. Keep Defender enabled. Avoid unnecessary administrator privileges. Monitor for suspicious behavior. Install Microsoft's official fix.

The bigger lesson for endpoint security

ShieldBreak demonstrates a fundamental principle:

Security products are themselves part of the attack surface.

The more privileges a security product has, the more important it becomes to secure the product itself.

This applies to:

Microsoft Defender,
EDR platforms,
endpoint management agents,
backup software,
vulnerability scanners,
monitoring agents.

Security architecture should therefore assume that individual components can fail.

The objective is not to create an environment where vulnerabilities never exist.

That is unrealistic.

The objective is to create an environment where:

One Vulnerability
      ≠
Complete Compromise

That is what defense in depth is supposed to achieve.

Final thoughts

ShieldBreak, CVE-2026-69414, is an excellent example of why modern endpoint security cannot be reduced to the question:

"Do I have antivirus?"

The more important questions are:

Is the operating system patched?
Are security components updated?
Are users running with unnecessary privileges?
Is exploit mitigation enabled?
Is application execution controlled?
Are credentials protected?
Is endpoint telemetry monitored?
Can the organization detect privilege escalation?
Can the attack chain be broken at multiple points?

Microsoft Defender remains an important part of Windows security.

The existence of a vulnerability inside Defender does not change that.

Instead, ShieldBreak reinforces the need for layered endpoint security.

For more technical Windows security analysis, practical guides and current vulnerability coverage, see the latest material on Netbe:

https://netbe.pl/

https://netbe.pl/microsoft-is-working-on-a-patch-for-a-new-windows-defender-zero-day-called-shieldbreak/

https://netbe.pl/windows-11-zero-day-shieldbreak-gives-attackers-system-privileges-what-we-know/

https://netbe.pl/wbudowane-zabezpieczenia-windows-11-jak-dziala-microsoft-defender-krok-po-kroku/

https://netbe.pl/automatyczne-wykrywanie-i-lagodzenie-luk-zero-day-jak-windows-defender-i-smartscreen-w-windows-11-sobie-radza/

https://netbe.pl/praktyczne-zabezpieczenia-windows-konfiguracja-asr-applocker-i-analiza-logow-sysmon-krok-po-kroku/

https://netbe.pl/dodatkowe-narzedzia-zabezpieczajace-np-anty-malware-anty-exploit-i-ich-rola-w-wzmacnianiu-ochrony/

https://netbe.pl/najlepsze-ustawienia-microsoft-defender-przeciw-ransomware/

https://netbe.pl/microsoft-patches-400-windows-vulnerabilities-one-zero-day-is-already-being-exploited/

OpenAI Astra: When AI Agents Become a Cybersecurity Problem

Marek „Netbe” Lampart — Sun, 16 Aug 2026 09:48:11 +0000

The latest developments around OpenAI's upcoming Astra model highlight an important shift in AI security: the biggest risk may no longer be what an AI model can generate, but what an autonomous agent can actually do.

OpenAI recently said preliminary evaluations of Astra showed significant advances in agentic coding and cybersecurity. The company could not rule out the model reaching its Critical cybersecurity capability threshold under its Preparedness Framework.

That led OpenAI to pause some Astra activities until additional security requirements are satisfied.

From AI assistant to autonomous operator

Traditional AI assistance generally looks like this:

User
  ↓
AI
  ↓
Generated output
  ↓
Human decides what happens

An autonomous agent introduces another layer:

Goal
  ↓
AI agent
  ↓
Analysis
  ↓
Tool selection
  ↓
Execution
  ↓
Evaluate result
  ↓
Next action

This distinction is critical for cybersecurity.

An AI that explains how a vulnerability works is useful.

An AI that can discover a vulnerability, develop an exploit, execute it and adapt to the result represents a substantially different security problem.

OpenAI's Critical threshold specifically concerns capabilities such as autonomously identifying and developing functional zero-day exploits against hardened real-world critical systems or executing novel end-to-end cyberattack strategies with limited human intervention.

Why permissions matter

The same model can have radically different security implications depending on its environment.

Consider an agent with access to:

source code,
Git repositories,
cloud APIs,
databases,
shell commands,
production credentials,
internal networks.

At that point, the security question becomes less about the model alone and more about the agent's permissions.

This is why traditional principles such as least privilege, network isolation and credential separation remain important even in highly advanced AI systems.

OpenAI is adding stronger controls

OpenAI says it is implementing additional safeguards around Astra, including isolated testing environments, restricted network and tool access, sandboxed execution, stronger protection of model weights and additional monitoring.

The company also plans to work with government agencies and selected AI safety organizations on capability evaluations.

This is significant because the security controls are being strengthened before broad deployment, rather than being treated purely as a post-release problem.

The AI security paradox

There is an obvious defensive benefit to more capable cyber AI.

Advanced models can potentially help defenders:

identify vulnerabilities,
analyze malware,
audit source code,
investigate incidents,
develop patches,
improve detection,
automate security operations.

OpenAI has already been developing more permissive cyber models for verified defenders through its Trusted Access for Cyber program.

But offensive and defensive cybersecurity often rely on many of the same technical capabilities.

The challenge is therefore not simply:

"Can AI do cybersecurity?"

It is:

"Who controls the AI, what tools can it access, and what can it do autonomously?"

AI agents should be treated like privileged users

For developers building agentic systems, a useful security model is to treat an AI agent as an extremely powerful but potentially unpredictable service account.

That means:

Least privilege

Give the agent only the permissions required for its specific task.

Short-lived credentials

Avoid exposing permanent production secrets.

Network controls

Restrict outbound and internal network access.

Tool allowlists

Explicitly define which tools the agent can invoke.

Audit logging

Record important agent actions and tool calls.

Human approval

Require confirmation before high-impact operations.

Isolation

Keep experiments away from production infrastructure.

The bigger lesson for developers

A common mistake is to focus entirely on model-level safety.

But an AI agent is a complete system:

Model
 +
Prompt
 +
Tools
 +
Credentials
 +
Network
 +
Data
 +
Execution environment

A secure model can still become part of an insecure system if the surrounding architecture gives it excessive authority.

Recent security testing has also demonstrated that AI agents can cross intended testing boundaries when environments are incorrectly configured, reinforcing the importance of treating the agent's execution environment as part of the security perimeter.

What happens next?

The Astra situation may become an important milestone in the development of agentic AI.

The industry is moving toward systems that can work for longer periods, use multiple tools and perform increasingly complex technical tasks.

That creates enormous opportunities for cybersecurity defenders.

It also means that AI security and infrastructure security are becoming increasingly connected.

The most important security control may ultimately not be the model's refusal behavior.

It may be the architecture surrounding the model.

Conclusion

OpenAI has not publicly stated that Astra definitively possesses Critical cyber capabilities. The company's position is that its preliminary evaluations are strong enough that it cannot rule out that level of capability.

That distinction is important.

But the response is significant nonetheless: some Astra work has been paused while stronger safeguards and additional evaluations are implemented.

For developers building autonomous AI systems, the lesson is straightforward:

Don't ask only what your model can do. Ask what your model can do with the permissions you give it.

For a detailed analysis, see the related article on Netbe: OpenAI Pauses Astra Work After AI Model Shows Potentially Critical Cyber Capabilities.

Expired Domains Are Becoming a New Cybersecurity Attack Surface

Marek „Netbe” Lampart — Sat, 15 Aug 2026 17:40:24 +0000

An expired domain might look like nothing more than an abandoned website address.

From a cybersecurity perspective, however, it can be much more interesting.

Organizations routinely retire domains after closing projects, changing brands, migrating services or shutting down old products. The problem is that a domain can remain referenced across the Internet long after its original owner stops using it.

When somebody else registers that domain, its history can become useful.

What makes an expired domain valuable?

An established domain may have years of accumulated:

backlinks
search engine visibility
references in documentation
social media links
forum posts
partner links
historical traffic
email infrastructure

A newly registered malicious domain has to build credibility from scratch.

An expired domain may already have it.

The basic lifecycle can look like this:

Legitimate domain
       ↓
Years of usage
       ↓
Backlinks + references + traffic
       ↓
Domain expires
       ↓
New owner registers it
       ↓
Potential malicious use

The change of ownership can be invisible to somebody following an old link.

Old links can become dangerous

Consider a company that operated:

example-company.com

for ten years.

During that time, hundreds of websites may have linked to it.

The company eventually migrates to another domain and allows the old one to expire.

Several months later, someone else registers the address.

Those old links don't automatically disappear.

A user clicking one of them may still see a familiar domain — but the content behind it is now controlled by somebody completely different.

This is one reason expired domains deserve more attention from security teams.

The DNS problem

The domain itself isn't necessarily the only concern.

Before abandoning a domain, an organization should determine whether it was previously associated with:

DNS records
MX records
SPF
DKIM
DMARC
APIs
SSO
OAuth integrations
SaaS services
TLS certificates
monitoring systems
subdomains

A domain that appears unused from the marketing team's perspective may still have technical dependencies.

Email deserves special attention

Email is particularly important.

If a domain was historically used for corporate email, developers and administrators should verify that no applications, users or external services still rely on it.

Otherwise, domain reassignment could create unexpected security consequences.

The lesson is straightforward:

Domain retirement should be treated as an infrastructure and security task, not just a billing decision.

SEO history can become part of the problem

There is also an interesting connection between expired domains and SEO.

An established domain may have accumulated thousands of references over its lifetime.

That historical reputation is one reason expired domains can have significant value.

For an attacker, however, the same history can potentially provide a layer of credibility.

A malicious operator doesn't need to convince every website to link to a brand-new domain.

Some links may already exist.

What should organizations do?

Before allowing an important domain to expire, create a simple retirement checklist.

1. Inventory dependencies

Identify:

DNS records
mail servers
subdomains
APIs
certificates
cloud services
SaaS integrations
authentication systems

2. Search for references

Look for the domain in:

source code
documentation
Git repositories
configuration files
monitoring systems
internal applications

3. Check external dependencies

Third-party services may still reference the domain even if nobody inside the organization remembers it.

4. Decide whether the domain should actually be released

For critical historical domains, keeping the registration may be cheaper than dealing with an unexpected security incident later.

5. Remove dependencies before retirement

If the domain must be abandoned, make sure associated infrastructure is properly removed or migrated first.

What developers should watch for

Developers can play an important role here.

Search old repositories and configuration files for domains that are no longer actively managed.

Pay particular attention to:

API endpoints
OAuth redirect URLs
CORS configuration
Webhook URLs
Email addresses
CDN configuration
External callbacks
Hardcoded links

An old domain hidden inside a forgotten application can become a surprisingly difficult dependency to discover.

The bigger security lesson

Modern cybersecurity is increasingly about asset lifecycle management.

Organizations tend to focus on protecting active infrastructure:

servers
endpoints
cloud workloads
applications
databases

But forgotten assets can matter too.

Domains, subdomains, certificates, cloud resources and repositories don't necessarily stop being security-relevant just because a project has been discontinued.

An abandoned asset can eventually become somebody else's asset.

Read the full analysis

I covered this issue in more detail on Netbe:

Cybercriminals Are Spending Millions on Expired Domains — Old Addresses Are Becoming a New Weapon

The key takeaway:

Before abandoning a domain, ask not only what you save by cancelling it — but what could happen if somebody else registers it.

Windows 12 in 2026: The Technical Evidence Still Points to Windows 11

Marek „Netbe” Lampart — Thu, 13 Aug 2026 09:55:29 +0000

Windows 12 in 2026: The Technical Evidence Still Points to Windows 11

The Windows 12 rumor cycle has been going on for years.

Every new Windows Insider build, architectural change or AI feature seems to generate another prediction that Microsoft is preparing to launch a completely new operating system.

But if we look at Microsoft's actual release and servicing model in 2026, the technical picture is different.

Microsoft is still building on Windows 11.

Windows 11 Is Following an Active Release Cycle

Microsoft currently describes Windows 11 as having an annual feature-update cadence, with monthly cumulative security and quality updates.

The supported Windows 11 releases include 24H2, 25H2 and 26H1, with different servicing periods depending on the edition.

That is not the behavior of a platform waiting to be replaced immediately.

The Windows 11 release documentation also states that version 26H1 was introduced specifically for new devices arriving in early 2026. It is not designed as an in-place feature update for existing 24H2 or 25H2 systems.

This is a strong indication that Microsoft is continuing to adapt Windows 11 to new hardware rather than abandoning the platform.

Windows 11 26H2 Is Even More Significant

The next feature update is Windows 11 version 26H2.

Microsoft describes 26H2 as being built on the same platform and servicing approach used by previous Windows releases.

For compatible existing systems, the transition is expected to use a relatively small enablement package rather than replacing the entire operating system.

From an engineering perspective, this is important.

A major new Windows generation would normally be expected to introduce a new platform identity.

Instead, Microsoft is extending the existing Windows 11 platform.

What Does This Mean for Windows 12?

It does not mean Windows 12 will never exist.

It means there is currently no technical reason to assume that Windows 12 must arrive in 2026.

There is a significant difference between:

Microsoft developing future Windows technologies
Windows Insider experimentation
internal Windows branches
major architectural changes
and an officially announced Windows 12 product

These things should not automatically be treated as the same event.

AI Does Not Require a New Windows Version

AI is one of the biggest reasons Windows 12 rumors keep returning.

Microsoft is clearly investing in AI-powered Windows experiences and hardware.

But AI functionality can be delivered through Windows 11.

There is no technical requirement that every major AI capability needs a completely new Windows version.

The same applies to security improvements, hardware acceleration, virtualization features and changes to system components.

Microsoft can evolve Windows without changing the product number.

The Enterprise Perspective Is Different

For enterprise environments, a new Windows generation is expensive.

IT departments have to validate:

business applications
drivers
security software
authentication systems
management platforms
Group Policy
endpoint protection
virtualization environments

A stable Windows 11 platform gives organizations more predictable lifecycle management.

That is one reason Microsoft's current servicing model matters more than internet speculation.

Windows 12 Rumors Should Be Treated as Rumors

There is nothing wrong with discussing the possibility of Windows 12.

The problem begins when predictions are presented as confirmed release information.

A claim such as:

"Windows 12 is definitely launching in 2026"

requires an official source.

At the moment, Microsoft's public documentation instead shows continued Windows 11 development, including 26H1 and the upcoming 26H2 release.

What Should Users Do?

If you are running a supported Windows 11 installation, there is no reason to replace your PC simply because of Windows 12 rumors.

Check your Windows version and its support lifecycle instead.

For example, Microsoft's current documentation lists Windows 11 24H2 Home and Pro as reaching the end of updates on October 13, 2026, while 25H2 and 26H1 have longer support periods.

That information is considerably more useful than an unofficial Windows 12 release date.

Final Takeaway

The Windows 12 story is a good example of why technical analysis should separate rumors from observable platform development.

In 2026, Microsoft is still:

shipping Windows 11 releases
supporting existing Windows 11 versions
adapting Windows to new hardware
developing Windows 11 26H2
improving security
integrating AI capabilities

So while Windows 12 may eventually become a reality, the available evidence does not establish a 2026 launch.

For a broader analysis of Microsoft's strategy, see:

Windows 12 Is Not Coming in 2026: Microsoft Is Doubling Down on Windows 11

The important distinction is simple:

Windows 12 is a possibility. Windows 11 is the platform Microsoft is actually developing today.

Windows 12 Is Still a Rumor — Windows 11 26H2 Is the Real Story

Marek „Netbe” Lampart — Wed, 12 Aug 2026 09:46:56 +0000

The Windows 12 rumors continue, but Microsoft's actual roadmap tells a different story.

There is still no official Windows 12 release announcement for 2026. Meanwhile, Microsoft is continuing to develop Windows 11, with version 26H2 appearing in Insider builds and the company maintaining its annual feature-update cadence.
For developers and system administrators, this may be more important than the Windows 12 name itself.

Windows Is Becoming a Continuously Updated Platform

The old model was straightforward:

Windows 10
    ↓
Windows 11
    ↓
Windows 12

The current model looks more like:

Windows 11
    ├── Security Updates
    ├── Feature Updates
    ├── AI Features
    ├── Hardware Support
    └── Platform Changes

Microsoft says Windows 11 receives an annual feature update in the second half of each year, alongside monthly cumulative security updates.

Windows 11 26H2

Microsoft has already exposed version 26H2 in Windows Insider builds. The June 2026 Insider release changed the version information shown by winver and Windows Settings to 26H2.

Recent reporting expects the broader 26H2 rollout later in 2026, potentially as an enablement package for compatible Windows 11 systems.

This is significant because an enablement-style update can make a major version transition much less disruptive.

Why Developers Should Care

The Windows version number is becoming less useful as a proxy for the actual platform capabilities.

A developer increasingly needs to consider:

Windows build number
API availability
security features
hardware capabilities
virtualization
NPU availability
driver versions
application compatibility

Two machines running Windows 11 may therefore have substantially different capabilities.

Windows 11
    |
    +---- CPU
    +---- GPU
    +---- NPU
    +---- VBS
    +---- HVCI
    +---- Secure Boot

AI Could Define the Next Windows Generation

The biggest change may not be Windows 12 itself.

It may be the increasing integration of local AI and dedicated NPUs.

That creates a new development model:

Application
    |
    v
Windows AI APIs
    |
    +---- CPU
    +---- GPU
    +---- NPU

Developers will increasingly need to distinguish between software that runs everywhere and features requiring specific AI-capable hardware.

Security Is Another Major Factor

The future Windows architecture is also increasingly hardware- and virtualization-oriented.

A simplified security stack looks like:

UEFI
  ↓
Secure Boot
  ↓
TPM
  ↓
Windows Kernel
  ↓
VBS / HVCI
  ↓
Applications

This is particularly relevant for developers writing:

drivers,
security software,
virtualization tools,
endpoint agents,
low-level Windows utilities.

Kernel-level compatibility and code-integrity requirements can be just as important as ordinary API compatibility.

Should We Wait for Windows 12?

For development and infrastructure planning, probably not.

There is currently no confirmed Windows 12 release that developers can target.

The practical approach is:

Supported Windows
       ↓
Current APIs
       ↓
Security Updates
       ↓
Compatibility Testing
       ↓
Future-Proof Architecture

Build against documented APIs rather than rumors about the next Windows version.

The Interesting Question

The real question isn't:

"When will Windows 12 arrive?"

It is:

"How much can Microsoft change Windows 11 before a new version number becomes necessary?"

Windows 11 26H2 suggests that Microsoft can continue evolving the platform without immediately moving to a Windows 12 branding strategy.

For developers, that's actually good news.

A more incremental Windows platform can mean fewer disruptive migrations and more predictable compatibility testing.

Final Thoughts

Windows 12 remains an interesting topic, but Windows 11 26H2 is the concrete development story right now.

Developers should focus less on speculation and more on the technologies that are actually changing Windows:

AI, NPUs, virtualization, hardware-backed security, APIs and continuous servicing.

I covered the broader Windows 12 discussion in this analysis:

👉 https://netbe.pl/windows-12-in-2026-microsoft-pushes-back-as-rumors-clash-with-the-real-windows-roadmap/

Related Netbe resources

Question for developers: Would you prefer Microsoft to release a completely new Windows 12, or keep evolving Windows 11 through smaller platform updates?

NatJack: Why NAT Connection Tracking Is Becoming a Security Concern

Marek „Netbe” Lampart — Tue, 11 Aug 2026 10:33:50 +0000

Network Address Translation is everywhere.

Home routers, Linux firewalls, cloud environments, virtualization platforms and container infrastructure all depend on NAT and connection tracking.

For years, NAT has often been perceived as an additional layer of protection because internal addresses are not directly exposed to the Internet.

A newly disclosed attack class called NatJack shows why this assumption deserves another look.

The research presented at Black Hat USA 2026 focuses on weaknesses in NAT connection-state handling and demonstrates potential attacks involving TCP sessions, DNS traffic, NAT mappings and connection-table exhaustion.

The important takeaway for developers and infrastructure engineers is simple:

NAT is a networking mechanism, not a complete security boundary.

How NAT Connection Tracking Works

Consider a simple Linux gateway:

Client
192.168.1.10:50000
       |
       v
Linux Gateway
       |
       | NAT
       v
203.0.113.10:42001
       |
       v
Internet

The gateway maintains state describing the connection.

Conceptually:

Internal:
192.168.1.10:50000

External:
203.0.113.10:42001

When return traffic arrives, the NAT implementation uses this state to determine where the packet should go.

This state is critical.

It is also part of the attack surface.

Where NatJack Fits

NatJack focuses on assumptions made by NAT implementations when handling connection state.

The research is interesting because it is not simply another vulnerability in one router.

Instead, it describes a broader class of attacks that can affect independently developed NAT implementations under specific conditions.

Potential consequences include:

TCP session hijacking
DNS response manipulation
NAT port discovery
connection-table exhaustion
disruption of existing connections

The full technical analysis is available here:

https://netbe.pl/natjack-new-attack-class-can-hijack-tcp-sessions-and-spoof-dns-through-nat-manipulation/

Linux Developers Should Pay Attention

Linux networking commonly relies on Netfilter and connection tracking.

A simplified architecture looks like:

Packet
  |
  v
Netfilter
  |
  v
Conntrack
  |
  +---- Existing flow
  |
  +---- New flow

Conntrack is involved in:

stateful firewalling
NAT
connection management
packet classification

This means that a weakness in connection-state handling can have consequences beyond simple packet forwarding.

For Linux developers and administrators, it is therefore important to understand that firewall state and NAT state are closely connected.

What About Containers?

Container environments make this particularly relevant.

A typical deployment might look like:

                Internet
                    |
                    v
              Linux Host
                    |
                  NAT
                    |
        +-----------+-----------+
        |           |           |
     App A       App B       App C

Multiple applications may share networking infrastructure.

If an attacker gains control over one workload, the security question becomes:

What other workloads share the same NAT and connection-tracking state?

This is an important architectural question for:

Docker deployments
Kubernetes clusters
CI/CD infrastructure
cloud workloads
multi-tenant applications

NAT Should Not Replace Segmentation

One common architectural mistake is assuming that NAT automatically separates systems.

It does not.

Consider:

Internet
   |
   v
 NAT Gateway
   |
   +---- Server
   |
   +---- Database
   |
   +---- Developer Workstation
   |
   +---- Untrusted Workload

All of these systems may technically be behind the same NAT boundary.

A better design separates security zones:

                Firewall
                   |
       +-----------+-----------+
       |           |           |
    Servers     Users       Untrusted
       |           |           |
    Zone A       Zone B       Zone C

NAT can still be used, but it should not be the only security control.

DNS Is Another Important Part

NatJack is particularly interesting from a DNS security perspective.

A standard DNS exchange is:

Application
    |
    v
DNS Resolver
    |
    v
DNS Response

If network state can be manipulated, DNS responses may become part of the attack path.

A forged DNS response could potentially redirect an application toward an unintended destination.

This is why developers should not assume:

DNS response = automatically trustworthy

Applications should use authenticated and encrypted protocols where appropriate.

For a deeper look at DNS spoofing attacks and defensive techniques, see:

https://netbe.pl/atak-dns-spoofing-co-to-jest-na-czym-polega-jak-sie-bronic-i-zabezpieczyc/

Monitoring Conntrack

Infrastructure teams should monitor connection-tracking behavior.

On Linux, administrators can inspect current conntrack entries with:

sudo conntrack -L

Firewall state can be reviewed with:

sudo nft list ruleset

Depending on the environment, useful indicators include:

Connection count
TCP resets
SYN rate
NAT table utilization
DNS anomalies
Connection failures

A sudden increase in connection creation can indicate:

application problems
scanning
abuse
denial-of-service activity
misconfiguration

Monitoring these metrics gives defenders much better visibility.

Connection Table Exhaustion

NAT devices have finite resources.

An attacker generating large numbers of connections may consume those resources.

Conceptually:

Normal:

NAT Table
[■■■■■■□□□□□□]

Attack:

NAT Table
[■■■■■■■■■■■■]

Once resources are exhausted, legitimate clients can start experiencing connection failures.

This makes resource monitoring an important part of network security.

What Developers Can Do

Developers may not control the NAT gateway, but application design can still reduce the impact of network manipulation.

Use TLS

Do not rely on network location for trust.

Use authenticated encryption:

Application
    |
   TLS
    |
    v
Network

Avoid Hard-Coded Trust in DNS

DNS should be treated as infrastructure rather than an unquestionable source of application identity.

Where security matters, validate the destination through cryptographic mechanisms.

Design for Network Failure

Applications should handle:

connection resets
DNS failures
timeouts
retries
temporary network unavailability

This is especially important for distributed systems.

Use Short-Lived Credentials

If network-level manipulation occurs, long-lived credentials increase the potential impact.

Short-lived tokens and proper authentication reduce the blast radius.

What Infrastructure Teams Should Do

A practical checklist:

[ ] Patch Linux kernels and network appliances
[ ] Review NAT implementations
[ ] Monitor conntrack usage
[ ] Monitor DNS anomalies
[ ] Separate trusted and untrusted workloads
[ ] Review firewall policies
[ ] Use network segmentation
[ ] Encrypt application traffic
[ ] Monitor connection resets
[ ] Review shared NAT environments

The goal is not to remove NAT.

The goal is to ensure that NAT is only one component of the security architecture.

Why NatJack Matters

The most interesting aspect of NatJack is not simply another security bug.

It highlights a broader problem in infrastructure security.

Modern networks contain many layers:

Application
     |
TLS
     |
Container
     |
Virtual Network
     |
Firewall
     |
NAT
     |
Internet

Each layer makes assumptions about the layer below it.

When those assumptions are wrong, vulnerabilities can cross traditional security boundaries.

This is exactly why infrastructure security needs to be treated as part of application security.

Final Takeaway

NAT remains an important technology.

But developers and infrastructure engineers should stop thinking of it as a security mechanism by itself.

NatJack demonstrates why connection tracking, shared NAT environments and network state deserve security attention.

The practical model should be:

NAT
+
Firewall
+
Segmentation
+
TLS
+
Monitoring
+
Patching

Not:

NAT = Security

Understanding what happens below the application layer is becoming increasingly important as modern applications depend on containers, cloud networking, virtualization and shared infrastructure.

For the complete technical analysis of NatJack, including attack scenarios and defensive recommendations:

NatJack: New Attack Class Can Hijack TCP Sessions and Spoof DNS Through NAT Manipulation

https://netbe.pl/natjack-new-attack-class-can-hijack-tcp-sessions-and-spoof-dns-through-nat-manipulation/

Linux Firewall and NAT Security: What Administrators Should Actually Protect

Marek „Netbe” Lampart — Mon, 10 Aug 2026 17:11:52 +0000

Linux is often deployed as a firewall, router, VPN gateway or NAT device. It can perform all of these roles extremely well, but combining them also means that a configuration mistake can affect an entire network.

One of the most common misconceptions is that NAT itself provides sufficient security.

It does not.

NAT translates addresses and ports. A firewall defines what traffic is allowed. DNS resolves names. Routing decides where packets go.

These functions work together, but they should not be confused with one another.

A Typical Linux Gateway

A small Linux gateway might look like this:

                    Internet
                       |
                       |
                 +-----------+
                 |   Linux   |
                 |  Gateway  |
                 |  Firewall |
                 +-----------+
                    /       \
                   /         \
                  v           v
                LAN        Server VLAN

The gateway may perform:

IPv4/IPv6 routing
NAT
packet filtering
VPN termination
network segmentation
traffic logging

That makes the Linux host a critical security component.

1. Enable Routing Only When Required

For IPv4 forwarding:

sudo sysctl -w net.ipv4.ip_forward=1

Check the current state:

sysctl net.ipv4.ip_forward

A router needs forwarding enabled, but a normal application server usually does not.

Unnecessary network functionality should not be enabled simply because Linux supports it.

2. NAT Is Not a Firewall

Consider this flow:

192.168.10.50:52344
          |
          v
      NAT Gateway
          |
          v
203.0.113.10:41022

NAT translates the connection.

The firewall still needs to determine whether the traffic should be allowed.

A good mental model is:

NAT      → translation
Routing  → packet destination
Firewall → access control
DNS      → name resolution

Each component solves a different problem.

Netbe has a broader guide covering UFW, nftables and iptables on Linux.

3. Control FORWARD Traffic

This is particularly important when Linux is acting as a router.

Traffic destined for the Linux machine and traffic passing through it are not the same thing.

Internet
   |
   v
Linux
   |
   v
Internal Server

The second connection is forwarded traffic.

A firewall policy should explicitly define which forwarded traffic is allowed.

For example:

LAN → Internet       ALLOW
Internet → LAN       DROP

LAN → Servers        ALLOW
IoT → Servers        LIMITED
IoT → LAN            DROP

This prevents the gateway from becoming a simple packet-forwarding machine with little security control.

4. nftables for Modern Linux Systems

nftables is the modern Linux packet-filtering framework.

A simplified policy can be structured around:

INPUT
FORWARD
OUTPUT

For a router, FORWARD deserves particular attention.

A conceptual policy might be:

table inet filter

INPUT:
  established connections → ACCEPT
  management SSH         → ACCEPT
  everything else        → DROP

FORWARD:
  LAN → Internet         → ACCEPT
  established traffic    → ACCEPT
  everything else        → DROP

OUTPUT:
  required traffic       → ACCEPT

A practical nftables configuration can be found in nftables Firewall on Linux.

5. Default Deny

A useful security principle is:

Default:
DROP

Exceptions:
ALLOW

Instead of trying to identify every malicious connection, the administrator defines what legitimate traffic is required.

For example, if a server only needs HTTPS:

TCP/443 → ALLOW
everything else → DROP

This is much easier to reason about than exposing multiple unnecessary services.

6. UFW for Simpler Configurations

For simpler Ubuntu deployments, UFW can provide a convenient firewall interface.

Example:

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow 22/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Verify:

sudo ufw status verbose

UFW is easier to operate than writing every nftables rule manually.

See How to Configure UFW Firewall on Ubuntu for a practical example.

7. DNS Is Part of the Security Model

Applications rarely connect to domain names directly.

The typical process is:

Application
    |
    | example.com
    v
DNS Resolver
    |
    | IP address
    v
Remote Server

If DNS resolution is manipulated, the application can be directed toward an unexpected IP address.

This is the basic idea behind DNS spoofing.

A detailed explanation is available in DNS Spoofing Attack: What It Is and How to Defend Against It.

8. Why DNS Spoofing Matters

DNS manipulation can potentially redirect users to:

phishing websites,
malicious downloads,
fake login pages,
attacker-controlled infrastructure.

Developers should therefore avoid assuming that DNS is always trustworthy.

Transport encryption such as HTTPS is another important layer because even if a user is redirected, certificate validation can prevent many straightforward impersonation attempts.

9. Network Segmentation

A flat network makes lateral movement easier.

Instead, divide systems into security zones:

                 Firewall
                    |
       +------------+------------+
       |            |            |
      LAN         Servers        IoT
    VLAN 10       VLAN 20      VLAN 30

Then define explicit policies.

For example:

LAN → Servers      ALLOW
Servers → LAN      LIMITED
IoT → Servers      REQUIRED PORTS ONLY
IoT → LAN          DROP

This architecture can significantly reduce the impact of a compromised device.

10. Protect SSH

A Linux gateway will often have SSH enabled.

Do not expose administration interfaces unnecessarily.

Prefer:

Internet
   |
   X
   |
SSH

Management VLAN
   |
   v
SSH
   |
   v
Gateway

Useful hardening measures include:

SSH keys instead of passwords,
disabling root login,
restricting administrative users,
limiting SSH with firewall rules,
monitoring authentication failures.

For practical configuration, see Linux SSH Hardening.

11. Do Not Forget IPv6

A firewall configuration may look secure while protecting only IPv4.

For example:

IPv4
Internet
   |
 NAT
   |
Firewall

But IPv6 may provide a different path:

IPv6
Internet
   |
   |
Firewall
   |
Internal Host

IPv6 therefore needs its own explicit security policy.

Using nftables with the inet family can simplify the management of IPv4 and IPv6 rules.

12. Check What Is Actually Listening

One of the simplest security checks on Linux is:

ss -lntup

This shows listening TCP/UDP sockets and can quickly reveal services that should not be exposed.

Also inspect the firewall:

sudo nft list ruleset

And routing:

ip route

A firewall is only as effective as the configuration behind it.

13. Monitor the Gateway

Security is not only about blocking traffic.

You also need visibility.

Look for:

Unexpected port scans
Repeated authentication failures
Unusual outbound connections
Unexpected DNS traffic
Large connection spikes
New port-forwarding rules

Monitoring can help detect both attacks and configuration mistakes.

14. Connection Tracking Is Security-Relevant

NAT gateways maintain state about active connections.

Conceptually:

Connection #1
Connection #2
Connection #3
Connection #4
...

The state table has finite resources.

Large numbers of connections can therefore become a resource-exhaustion problem.

This is one reason why network gateways should be monitored and protected against abnormal traffic patterns.

15. A Practical Defense-in-Depth Model

A good Linux network architecture can look like this:

                 Internet
                    |
                    v
              Perimeter FW
                    |
                    v
                  NAT
                    |
                    v
             VLAN / Segmentation
                    |
                    v
              Host Firewall
                    |
                    v
              Application
                    |
                    v
               Monitoring

No single layer is expected to stop every attack.

Instead, each layer reduces a different class of risk.

16. Security Checklist

Before deploying a Linux gateway, verify:

[ ] IP forwarding is intentionally enabled
[ ] Firewall is enabled
[ ] FORWARD policy is restrictive
[ ] NAT rules are documented
[ ] Port forwarding is minimized
[ ] IPv4 is protected
[ ] IPv6 is protected
[ ] SSH is restricted
[ ] Network segmentation is configured
[ ] DNS configuration is trusted
[ ] Firewall logs are monitored
[ ] System updates are applied
[ ] Configuration backups exist

Conclusion

Linux is an extremely capable networking platform, but its flexibility also means that administrators need to understand the interaction between routing, NAT, firewalling and DNS.

The most important distinction is simple:

NAT      ≠ Firewall
Routing  ≠ Security
DNS      ≠ Trust

A secure Linux gateway combines these technologies with explicit access-control policies, network segmentation, host hardening and monitoring.

The goal is not to make the network impossible to attack.

The goal is to make unauthorized traffic difficult to reach, difficult to move through the environment and easier to detect.

For more practical Linux and cybersecurity guides, visit Netbe.