Most identity security programs focus on people: strong passwords, MFA, phishing awareness. The attack on ConnectWise Cloud Backup customers on October 15, 2026, is a reminder that there is another door, one that few teams watch: the applications we once consented into Microsoft 365 with broad permissions and then forgot about.

What happened

Attackers used a credential belonging to the ConnectWise Cloud Backup app (formerly SkyKick) to authenticate as its service principal. Between 06:13 and 08:34 UTC, from a single hosting-provider IP address, they obtained Microsoft Graph tokens in at least 173 partner and customer tenants, according to Huntress. No user signed in, so MFA never came into play. Microsoft described it as an active supply chain attack and said the attacker likely abused permissions customers had already granted, including Directory.ReadWrite.All.

In dozens of tenants, ConnectWise service principals assigned themselves directory roles, mostly Exchange Administrator. In at least one partner tenant, a separate Cloud Management app made itself Global Administrator and added new client secrets to two other trusted apps, a persistence path that survives disabling the ConnectWise apps. ConnectWise has disabled seven application identities and taken Cloud Backup offline. How the credential was obtained is still unknown.

A checklist for Microsoft 365 administrators

• In Entra, look beyond user sign-ins: review service principal sign-ins for the ConnectWise and SkyKick app IDs and flag sources outside Azure ranges.

• Keep those apps disabled until the vendor confirms that every credential has been rotated.

• Audit secrets and certificates added to any application since October 13 and remove the ones you cannot explain.

• Search audit logs for apps that assigned themselves directory roles, and turn on Microsoft Graph activity logs.

• Review every consented application and remove permissions that are no longer needed.

The broader lesson

Non-human identities, from backup services to remote management tools, are as sensitive as a Global Administrator account, yet they have no MFA and are rarely monitored. Treat every third-party integration with access to your data as part of your attack surface: least privilege, periodic review, and alerting on sign-ins from unexpected places.

The full write-up with indicators and investigation steps is here: https://symantecland.com/connectwise-skykick-breach-microsoft-365-tenants/?utm\_source=hashnode&utm\_medium=article&utm\_campaign=sx\_syndication

— Kazem Mortazavi, independent network-security consultant

Why these attacks still succeed

Most intrusions do not begin with anything sophisticated. A phishing email, a reused password, or an unpatched service is often enough. That is good news, because closing the simple paths removes a large share of the risk.

The harder part comes afterward. An attacker with a foothold can move through the network for days or weeks, looking for credentials, file shares, and backup systems. Encryption is usually the last step, which means there is a long window in which the intrusion could be detected and stopped. Many organizations never use that window because nobody is watching the signals that appear during lateral movement, such as unusual administrator logins at night or new scheduled tasks on servers that rarely change.

Layers that hold up under pressure

• Behavior-based detection on endpoints. Signatures miss new malware. Watch for mass file modification, unusual service creation, and abnormal process trees before encryption spreads.

• Immutable backups. Keep copies that cannot be altered or deleted, even by an administrator, and keep them isolated from the production identity system.

• Network segmentation. Separate sensitive systems so that a compromised workstation cannot reach backup servers or domain controllers directly.

• Privileged access control. Most ransomware depends on an administrator account. Limit standing privileges, require multifactor authentication, and log every privileged session.

Practical steps for this quarter

• List which backups share credentials or network paths with production. Fix those first.

• Test a full restore, not just a successful backup job. A backup that has never been restored is an assumption, not a guarantee.

• Harden the systems you cannot patch quickly, and monitor them more closely than the rest.

• Write an incident playbook with named owners for containment, communication, and recovery.

The question is no longer whether an organization will be targeted, but how quickly it will notice an intrusion and how confidently it can recover. The full guide, with the controls and a description of each deployable layer, is available on our site in Persian: Ransomware in 2026: Why Prevention Alone Is No Longer Enough

— Kazem Mortazavi, independent network-security consultant

Ask anyone who runs a large VDI deployment about endpoint security and you will often hear the same story: the agent built for physical PCs runs on hundreds of virtual desktops at once, everything slows down, and eventually someone switches protection off.

A few months ago we saw exactly this at an organization with about four hundred VDI users. At 8:30 every morning, opening Outlook took a full minute because every desktop started its update and scheduled scan at the same moment. Protection had been "temporarily" disabled on half of the desktops for eight months.

Why virtual environments are different

• Access to vCenter or a single host means access to every VM running on it.

• Simultaneous scans on shared storage create a "scan storm."

• Traffic between two VMs on the same host never crosses the physical firewall.

• Any weakness in the golden image is cloned into hundreds of desktops.

Four layers that work in practice

1. Harden the hypervisor itself: a separate management network, MFA and personal accounts for vCenter, SSH off by default, Lockdown Mode, and host logs forwarded to a SIEM.

2. Offload scanning: move the heavy scanning work to a dedicated security server so only a light agent runs inside each VM, randomize scan and update schedules, and prepare the golden image the way the vendor documents it.

3. Segment east-west traffic: block desktop-to-desktop traffic by default and run new rules in monitor mode before enforcing them.

4. Make recovery independent: keep backups on an identity separate from the production domain, use immutable copies and test a real restore every quarter.

Why this matters now

Ransomware operators increasingly go after the host rather than individual VMs. Huntress reported that hypervisors' share of malicious encryption rose from about 3% to 25% during 2025. Once the host is compromised, the antivirus inside the guests plays no role, so hypervisor hardening and independent backups matter as much as guest protection.

In the organization above, after scanning was offloaded and schedules were spread out, the morning slowdown disappeared and protection was turned back on for every desktop.

The full guide, with five common mistakes and a four-week rollout plan, is here: Securing virtual environments and VDI without slowing users down

— Kazem Mortazavi, independent network-security consultant

This is the problem a hardware security module (HSM) is designed to solve.

What an HSM does

An HSM is a physical, tamper-resistant device that generates, stores and manages cryptographic keys in an isolated environment. Its defining property is that the key never leaves the device. Every cryptographic operation runs inside the module, and only the result comes out. An attacker who compromises the surrounding server can request operations, but cannot copy the key itself.

Why software key storage falls short

• A key stored in a file or in server memory can be extracted once the server is compromised.

• When the same administrator can reach both the data and the key, separation of duties disappears. One person can both lock and unlock.

• Standards such as PCI DSS and many banking and government frameworks require keys to be held in a validated module with FIPS 140-2 or 140-3 certification.

• In banking, payments and digital signatures, even a brief key exposure can lead to forged transactions or unauthorized signatures.

Where HSMs are used

• Key management for databases and sensitive files

• Public key infrastructure (PKI), where a certificate authority signs certificates with a root key that must never be exposed

• Banking and payments: PIN encryption, transaction signing and card verification

• Root keys in the cloud, kept separate from the environment that holds the data

An HSM is one layer, not the whole stack

An HSM is the foundation, but it is not enough alone. Endpoint encryption, inspection of encrypted traffic, privileged access management and hardening of database servers all build on top of it. If those layers are deployed without a sound approach to key management, they rest on shaky ground.

Before you finalize your next security design, ask one question: if your encryption key were exposed today, who would notice, and how quickly?

For the full guide with more detail and examples (in Persian): HSM explained: securing cryptographic keys

— Kazem Mortazavi, independent network-security consultant

Central management consoles make life easier: one place to push policy, firmware and credentials to hundreds of firewalls. A report published by Palo Alto Networks Unit 42 on October 14, 2026, shows the other side of that convenience. When one console holds the configuration and secrets of every firewall, compromising that console exposes all of them.

What happened

In September 2024, attackers used FortiJump (CVE-2024-47575, CVSS 9.8) to get into the FortiManager of a telecommunications managed service provider. They registered a rogue virtual FortiGate and, within minutes, pulled an archive with configurations, credentials and trust material for more than 500 managed FortiGate firewalls. They cracked the reversibly encrypted passwords, opened SSL VPN sessions from external infrastructure, and then used CVE-2025-61624, a path traversal in the FortiOS auto-script engine, to write files as root and deploy a new implant called PEERSTITCH. CISA added CVE-2025-61624 to its Known Exploited Vulnerabilities catalog on October 16, 2026.

Why the implant is hard to spot

PEERSTITCH is an ARM64 binary that injects into two FortiOS daemons, the logging process and the IPsec VPN daemon. It deletes itself after running, opens no ports and makes no outbound connections. Tagged VPN sessions take an alternate code path that skips FortiOS security checks. Tools that only scan files on disk will not see it.

A practical checklist

• Upgrade FortiOS to 7.6.5 or 7.4.10 and later; every 7.2, 7.0 and 6.4 release is affected and needs to move to a fixed branch.

• Update FortiProxy, FortiSwitchManager and FortiPAM according to advisory FG-IR-26-122.

• Expose FortiManager's TCP 541 only to your own firewalls and review the device list for unknown entries.

• If the manager was exposed, rotate credentials, certificates and FGFM trust material on every managed device. Patching does not invalidate stolen keys.

• Look for auto-script objects containing ../ and for Signal 11 crashes of miglogd or iked in the crash log.

• Forward firewall logs to a central system in real time; the attackers wiped local logs.

The broader lesson

A management plane is a high-value asset in its own right. Keep it on an isolated network, reachable only from known sources, and monitor it as closely as the systems it controls.

The full write-up with affected versions and detection notes is here: https://symantecland.com/fortigate-peerstitch-implant-fortimanager-breach/?utm\_source=hashnode&utm\_medium=article&utm\_campaign=sx\_syndication

— Kazem Mortazavi, independent network-security consultant

That gap is exactly what the next-generation firewall (NGFW) was built to close.

What a port-based firewall cannot see

Three blind spots matter most.

First, encrypted traffic. Without decryption, the firewall sees that a connection reached port 443, but not what it carries. Second, a port does not identify the application. An unauthorized program can use the same port as normal web traffic, and a traditional firewall cannot tell them apart because it judges by port, not content. Third, decisions made only by IP address ignore who is behind the connection. That weakens access control, especially where addresses change often, as they do for remote and mobile users.

What an NGFW adds

A next-generation firewall brings four capabilities:

• Deep packet inspection: analysis of the actual content of traffic, not just its headers.

• Application identification and control: separating applications even when they share a port.

• Intrusion prevention: blocking known attack patterns while the traffic is passing through.

• Encrypted traffic inspection: decrypting and checking HTTPS for hidden threats. It is valuable but resource-intensive, so it has to be part of capacity planning.

Practical points before you deploy

• Measure SSL inspection capacity separately. Decryption can become the bottleneck. In larger environments, the load can be moved to a dedicated decryption layer.

• Count security-service subscriptions in the total cost. NGFW features usually depend on active subscriptions, so renewal costs belong in the yearly budget.

• Plan centralized management from day one. Applying one consistent policy across several devices is far easier with a central management and reporting platform.

• Bring identity and device posture into policy. Identity-based controls turn a firewall from an IP filter into a much more precise access tool.

The takeaway

A firewall is no longer just a box that opens and closes ports. It has to understand applications, users and behavior at the same time. Organizations that still rely on the old port-based model cannot see a large share of the traffic they carry today.

For the complete guide and the full list of criteria, read the English edition of the article: Why port-based firewall rules no longer protect your network

— Kazem Mortazavi, independent network-security consultant

Most conversations about enterprise Wi-Fi start with speed, coverage and how many users an access point can handle. In field assessments, though, the weakest part is almost never the hardware. It is the authentication model. In many organizations, staff, guests, contractors and even CCTV cameras still join the network with one shared password.

On a recent visit we found the staff Wi-Fi password on a sticky note at the reception desk. People who had left months earlier still knew it, and a consumer access point was plugged into a wall jack under someone's desk.

Why a shared password is security debt

• Logs show MAC addresses, not people, so incident response becomes guesswork.

• Revoking access for someone who leaves is impractical, because changing the password means touching every device.

• Laptops, guest phones and cheap IoT devices share one flat segment.

• The signal reaches the parking lot; an attacker does not need to enter the building.

According to HPE Juniper Mist data presented at WLPC 2026, only about 10% of Wi-Fi authentications use WPA3, so this is far from a niche problem.

A four-layer model

1. WPA3-Enterprise with 802.1X, ideally EAP-TLS with device certificates. If you still run PEAP, enforce server certificate validation on every client, or an evil twin can collect domain credentials.

2. Network access control that places each user and device in the right segment based on role, device type and posture, and profiles IoT devices that cannot do 802.1X.

3. Segmentation: guests reach only the internet, IoT reaches only its management server, and traffic between segments goes through a firewall.

4. RF monitoring (WIDS/WIPS) to detect rogue access points, look-alike SSIDs and deauthentication attacks, with events sent to the SIEM.

A realistic migration

Inventory SSIDs and client types, pilot 802.1X on one floor, separate guest and IoT traffic, turn on RF monitoring, then roll out and retire the shared-password SSID. In our experience this fits in about six weeks. Treat WPA2/WPA3 transition mode as a migration step, not a destination.

The full guide, with common mistakes and a week-by-week plan, is here: Enterprise Wi-Fi security: why a shared password is not enough

— Kazem Mortazavi, independent network-security consultant

Three weaknesses of the VPN model

• Full trust after sign-in. Once a user connects, they usually reach the whole internal network, not just the application they need. One stolen account can become a path for lateral movement across the environment.

• A visible attack surface. VPN gateways are reachable from the internet, so they face constant scanning and brute-force attempts. A single critical flaw in a VPN product can quickly lead to mass exploitation.

• A one-time decision. The VPN usually checks the credentials presented at sign-in. It rarely re-evaluates the device's health or the user's behavior during the session.

Zero Trust Network Access: verify every request

ZTNA takes the opposite approach. Instead of opening the network, it grants access to a specific application. Users reach only the services they are allowed to use, internal resources stay hidden from the public internet, and each request is evaluated against identity, device posture, location and live behavior. The result is a much smaller attack surface and more precise control.

Where to start

• List your internal applications and record which users genuinely need each one.

• Check device posture before a connection is allowed; an unhealthy device should not get in.

• Put strong multi-factor authentication and a central identity service in place first.

• Define policies per application and remove old, overly broad access rights.

• Migrate in stages: start with the most sensitive applications, then move the rest.

The bottom line

Moving from VPN to ZTNA is not a passing trend. The goal is not to switch off the VPN overnight, but to stop trusting everyone who manages to get onto the network. If your migration path is unclear, begin with a technical assessment of your current remote access.

The full guide (in Persian) covers the reference architecture and the deployable options: VPN vs ZTNA: Why Zero Trust Access Is Replacing Traditional Remote Access

— Kazem Mortazavi, independent network-security consultant

Remote support appliances are easy to treat as plumbing: the help desk uses them to reach a user's laptop and fix a problem. But the same appliance can reach almost every system in the network and often stores privileged credentials. On October 15, 2026, BeyondTrust disclosed that CVE-2026-102764 in Remote Support had been exploited as a zero-day since August 29. The flaw scores 9.3 on CVSS v4 and lets an unauthenticated attacker perform file operations on the appliance, which in the observed attacks led to root.

Scope and timeline

• Remote Support 26.2.3 and earlier is affected (advisory BT26-05).

• The patch shipped on October 8, and SaaS tenants were patched by October 9.

• Privileged Remote Access shares the code; BeyondTrust found no exploitable path there but released a precautionary patch.

• Mandiant attributes the activity to ARMORY CASTLE (formerly UNC5221), a suspected China-nexus espionage group.

What the intrusion looked like

According to Mandiant, about 11 minutes after initial access the attacker dropped a PHP web shell, created a SUID copy of the system shell to become root, dumped the credential vault, added a boot-time persistence script with a passwordless sudo rule, and wiped local logs. With a compromised administrator account, the attacker then raised Jump Item and team roles to Administrator, opened support sessions to internal endpoints, pulled documents through the built-in file transfer, and exposed a SOCKS5-over-WebSocket tunnel through HAProxy.

A practical checklist

• Apply BT26-05-RS from the /appliance interface on 24.3.1 or later; older appliances must upgrade first.

• Treat any internet-reachable appliance on a vulnerable version since August 29 as potentially compromised until reviewed. Patching does not remove an attacker who is already in, and a reboot does not remove the observed persistence.

• Preserve evidence first: memory and disk snapshots, plus firewall, proxy and syslog data kept off the appliance.

• Hunt for /usr/bin/dbus-authd with SUID, a zz-root-persist script in post_boot.d, NOPASSWD lines in sudoers.template and /uidchanarge in the HAProxy config.

• Rotate vault credentials and anything typed into sessions only after patching or rebuilding.

• Restrict /login and /appliance to trusted IP ranges and require phishing-resistant MFA for administrators.

The broader lesson

A privileged access tool is itself a privileged asset. Forward its logs to a central system the appliance cannot erase, review role changes like any other admin change, and track appliance versions in the vulnerability program.

The full write-up with indicators and detection notes is here: https://symantecland.com/beyondtrust-remote-support-zero-day-armory-castle/?utm\_source=hashnode&utm\_medium=article&utm\_campaign=sx\_syndication

— Kazem Mortazavi, independent network-security consultant

Why privileged accounts carry the most risk

Four patterns show up again and again in organizations:

• Passwords that have not changed for years and may already be exposed in an old breach.

• Shared accounts such as root or administrator, which make it impossible to tell during an incident who did what.

• Standing access that stays active around the clock, even when nobody needs it.

• No session recording, which leaves the response team with no evidence to reconstruct the attack.

When one of these accounts leaks, the attacker can move laterally without triggering alerts, extract data, or disable backups. That sequence appears in many of the large ransomware attacks of recent years.

What privileged access management (PAM) actually does

PAM is a set of controls that answers three questions: who has access, to which system, and under what approval. Its core capabilities include:

• Secure credential storage: passwords live in an encrypted vault and rotate automatically, instead of sitting in spreadsheets or on paper.

• Just-in-time access: users receive elevated rights for a defined period after approval, and those rights are revoked automatically when the task ends.

• Session recording: every action on sensitive systems is logged and can be reviewed, both for investigations and for compliance.

• Approval for risky actions: a confirmation step before high-impact operations prevents mistakes and misuse.

Where to start

Before deploying any tool, build an accurate inventory of privileged identities. That includes human administrators, service accounts and API keys, which are often forgotten. Next, review the Active Directory paths that lead to privileged groups. Many of these paths have accumulated for years without anyone noticing. A practical sequence is to discover them, remove unnecessary rights, and then move the remaining accounts into a vault protected by multi-factor authentication with session recording enabled.

Finally, protect the vault itself with strong authentication. A PAM system without a second factor simply creates a new single point of attack.

The full guide, written in Persian, includes a deployment checklist and detailed steps for each stage: PAM: Why Privileged Access Management Is the Missing Link

— Kazem Mortazavi, independent network-security consultant

Ask an IT manager how they plan to roll out endpoint protection and you often hear the same idea: buy the most complete package for every device and stop worrying. In practice, depth of features matters less than one simple property: no device should sit outside the management console.

The Microsoft Digital Defense Report 2024 found that in more than 90% of ransomware attacks that reached the ransom stage, attackers used unmanaged devices, either to get in or to encrypt data remotely. A server with no agent, a laptop that never checked in, or a virtual machine whose protection was disabled because it was slow is exactly what attackers look for.

Match the protection tier to the team

When I help design an on-premises endpoint deployment, I map tiers to people, not to a feature list:

• Core prevention (antimalware, exploit protection, ransomware mitigation, firewall, device control) fits small IT teams with mostly physical machines.

• Advanced prevention (tunable machine learning, fileless attack protection, application control, central scanning) fits organizations that face targeted attacks but have no dedicated analyst.

• EDR is worth it only when someone reviews incidents every day. Without an owner, it is just a longer list of unanswered alerts.

One detail is easy to miss: some "on-premises" features still use the cloud. A sandbox that analyzes suspicious files remotely may conflict with a strict data-egress policy, so decide on it before rollout, not after.

Virtual environments need a different design

Running a full scan engine inside every virtual desktop creates morning "scan storms" that slow the host and push users to switch protection off. Offloading scanning to a dedicated security server reduces CPU, memory and disk I/O on the host. A common pattern is physical endpoints on an agent-based tier and hypervisor hosts on central scanning, all in one console.

A short pre-rollout checklist

• Count everything: servers, virtual machines, branch devices and remote laptops.

• Size the management appliance for growth, not for today's device count.

• Add encryption, patching or storage scanning only for a real, named problem.

• Run a four-week pilot on representative devices, including at least one VDI host, and finish with a coverage report.

I wrote a full walkthrough with a decision table, console sizing figures and the pilot plan here: the complete guide

— Kazem Mortazavi, independent network-security consultant

Three ordinary logs, one important signal

Data leaves a network through a small number of visible paths. The firewall records how many bytes were sent to each destination. The proxy shows which web services were contacted and by whom. DNS shows which hosts resolved which names, and how often. If your firewall logs only denied traffic, or the bytes-sent field is missing, you are effectively blind to the most useful metric.

Five steps that deliver the most value

• Enable logging for allowed outbound traffic, including bytes sent, and keep the clocks on every device synchronized with NTP.

• Build a baseline: calculate the average daily upload per user and per server over the last 30 days.

• List the servers that should never reach the internet, such as databases, domain controllers and file servers, and alert on any outbound connection from them.

• Start with a simple rule: uploads above three times a user's or server's average, or more than one gigabyte in an hour from a single host, deserve immediate review.

• Alert separately on personal file-sharing services, anonymous upload sites and command-line sync tools.

Also watch for unusually large or frequent DNS request volume from one host. DNS tunneling usually reveals itself through many small queries, and that pattern often appears in DNS logs long before it shows up anywhere else.

Test before you trust it

Upload a large test file from a lab system and measure how long it takes for an alert to appear. That number answers the question at the top of this article. If it is hours or days, the work is clear: define an owner for every alert, agree on a response time, and write a short procedure for quickly cutting off access, such as blocking a port or disabling an account.

A weekly review closes the loop. Look at the ten users and ten hosts with the largest uploads, compare them with last week, and note any destination seen for the first time. Assign one named person to read the report and record the outcome.

This approach will not replace content inspection or cloud visibility. It is a practical starting point, and once the baseline and alerts are working, the next step is usually adding content controls and cloud application visibility.

For the full checklist, with detailed steps and thresholds (in Persian): Early detection checklist for data exfiltration

— Kazem Mortazavi, independent network-security consultant

We usually think of the email gateway as a guard: the box that opens suspicious attachments so users never have to. On October 14, 2026, Cisco reminded everyone that the guard can also be the way in. Cisco confirmed that CVE-2026-76519 in Cisco Secure Email Gateway is being exploited in real attacks. The flaw has a CVSS score of 9.8 and lets an unauthenticated attacker write arbitrary files and run commands as root, simply by sending an email with a crafted attachment.

Where the bug lives

The issue is a relative path traversal (CWE-23) in how the File Reputation service, part of Advanced Malware Protection, handles attachments. A gateway is only exposed when both conditions are true:

• File Reputation is enabled and assigned to a mail policy.

• Content Scanner Tools is older than version 25.3.0.5525.

Cisco says Secure Email and Web Manager and Secure Web Appliance are not affected, and there is no workaround.

A pattern, not a one-off

This is the third root-level flaw in these appliances confirmed as exploited since December 2025, after CVE-2025-20393 and the September 2026 SQL injection CVE-2026-76461. The fixed AsyncOS builds have been available since September 14, so any gateway left unpatched for the last month is exposed today. Shadowserver tracks close to 300 Secure Email Gateway instances reachable from the internet.

A short checklist

• Check the scanner version with contentscannerstatus and update to 25.3.0.5525 or later. This update does not need a restart.

• Upgrade AsyncOS to 15.5.5-014 or 16.5.0-780. The 16.0 train has no fixed build, so plan a migration.

• Run grep "System Security" system_logs on every cluster member and contact Cisco TAC if it reports a suspected compromise or an incomplete scan.

• Review firewall logs for unexpected outbound transfers from the gateway. An attacker with root can erase local evidence, so a clean result is not proof.

• If compromise is confirmed, preserve evidence, rebuild on a fixed release without importing the old configuration, and rotate credentials and keys. Cluster members trust each other through SSH keys, so rebuild every member.

The broader lesson

An email gateway accepts and parses untrusted files from the whole internet all day. It deserves the same monitoring as any internet-facing server: central logging, alerts on unusual outbound connections, and a vulnerability program that tracks appliance components, not just operating systems.

The full write-up with detection details is here: https://symantecland.com/cisco-secure-email-gateway-zero-day-root-attachment/?utm\_source=hashnode&utm\_medium=article&utm\_campaign=sx\_syndication

— Kazem Mortazavi, independent network-security consultant

VMware no longer sells its products separately under perpetual licenses. Everything is sold as an annual subscription priced per physical CPU core, in a few fixed bundles, so the central decision for most organizations is choosing between VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF).

What Actually Separates VCF from VVF

VVF is a complete virtualization platform: high availability, automated load distribution, live migration, central management, capacity and monitoring tools, a Kubernetes service, and a limited software-defined storage quota. VCF includes all of that and adds software-defined networking, a much larger storage quota per core, automation and self-service provisioning, tools for moving workloads between data centers, and lifecycle management for the entire infrastructure.

An important point is often overlooked: distributed firewalling and micro-segmentation, software load balancing, and recovery from ransomware and disasters are not fully included in either bundle. They are sold as separate add-ons.

Which Bundle Fits Which Organization?

• A mid-sized organization with one or two data centers, physical network and firewall appliances, and a small team: VVF is usually sufficient.

• A bank or large organization with several data centers and hundreds of hosts: VCF makes sense, provided you have a real plan to use software-defined networking and automation.

• Hyperconverged infrastructure with software-defined storage: Compare the storage capacity you need with each bundle's quota. Sometimes the extra capacity required under VVF makes VCF the more economical option.

• A mix of both: VCF for the primary data center and critical systems, and VVF for branch offices, a backup site, or development and test environments.

Counting Cores Correctly, and Four Common Mistakes

Under the new model, licensing is calculated from the physical cores in each processor, with a minimum of 16 cores per CPU. A dual-socket server with 8-core processors therefore needs 32 cores of license, not 16. To avoid unexpected costs:

• Export an exact inventory of hosts, processors, and cores from your management console.

• Identify low-utilization hosts, and consolidate virtual machines onto fewer, newer servers.

• Do not forget backup-site hosts, test clusters, and recently added servers. Missing them is a common audit surprise.

• Start negotiations at least three months before the contract ends, not in the last minute.

• Saving money by skipping micro-segmentation and ransomware recovery is not real savings, because the hypervisor is one of attackers' main targets.

For the full guide, checklist, and details, read the English edition: VCF or VVF: Choosing the Right VMware License and Avoiding Overspending

— Kazem Mortazavi, independent network-security consultant

"If we get attacked, we will call the data center." I have heard this from many technical teams, usually a few weeks before a big sales campaign or a registration period. The problem is that a modern attack does not wait for a phone call.

Cloudflare's DDoS threat report for the first half of 2026 found that 90.6 percent of network-layer attacks ended in under ten minutes. Before anyone opens a ticket, the first wave is over and the next one is on its way. Protection has to be automatic and always on.

No single device does everything

In designs that hold up in practice, traffic passes four stations:

• Upstream scrubbing at the ISP or a cloud service for attacks larger than your link. Agree on the contract and activation threshold before peak day.

• A dedicated DDoS mitigation appliance at the edge that absorbs SYN and UDP floods and DNS reflection within seconds. A stateful firewall should not be the first barrier, because its session table fills up long before the link does.

• An application delivery controller that terminates TLS, removes unhealthy servers and applies rate limits per path.

• A web application firewall with bot management for layer-7 floods, where normal-looking requests exhaust the database without filling the bandwidth.

Three details that decide peak day

• Run the WAF policy in learning mode for a few weeks and switch to blocking before the campaign. Attack day is not test day.

• Search, login and cart endpoints need their own, stricter thresholds than the home page.

• Hide the origin server and accept traffic only from the protection layer. An old DNS record or a forgotten test subdomain makes every other layer irrelevant.

The bottleneck is usually somewhere else

In most of the drills we have run with teams, the first thing to fall over was not the bandwidth. It was the database. A few hundred heavy search requests per second, without any visible spike on the traffic graph, pushed response times from tens of milliseconds to several seconds. That is why a simple load test and a controlled drill, coordinated with your ISP, are worth more than any product sheet before you buy anything. The results tell you which layer to strengthen first and which thresholds need to be stricter.

The full five-stage readiness plan, from six weeks before a campaign to the post-incident review, and four common mistakes are in the complete guide: DDoS and WAF readiness for high-traffic websites

— Kazem Mortazavi, independent network-security consultant

What a load balancer does, and what an ADC adds

A Layer 4 load balancer spreads connections across servers based on address and port. It is fast and simple, and it is enough for many stateless internal services. An application delivery controller (ADC) works at Layer 7 and understands the application. It checks health with real requests, terminates TLS in one place, keeps user sessions on the same server when needed, routes requests by content, and can run a web application firewall on decrypted traffic.

A practical rule: if a service is stateless, internal, and low-impact, plain load balancing is usually enough. If it serves end users, keeps sessions, runs over HTTPS, or is reachable from outside the organization, you probably need an ADC.

Match the form factor to the environment

• Data center and critical applications: an enterprise ADC, hardware or virtual, with strong TLS throughput and advanced health monitoring.

• Private cloud: a software ADC with a central controller that adds service engines as load grows, so teams do not request new hardware for each application.

• Containers and microservices: a lightweight proxy or ingress controller configured in the same deployment pipeline as the application.

• Multiple sites: DNS-based global server load balancing that sends users to the healthiest site and fails over automatically.

Internet-facing applications also need a web application firewall, and high-volume entry points need protection against denial-of-service floods before traffic reaches the ADC.

Four common mistakes

• Shallow health checks that confirm a server is powered on but not that the application works.

• One shared ADC pair for everything, so a single small change carries risk for every application behind it.

• Scattered certificates and outdated TLS, where expiry dates and legacy protocols are discovered late.

• Forgetting the ADC itself. Its management interface should not be reachable from user networks or the internet, and its firmware needs the same patch discipline as any other edge device.

Five steps to choose

1. Inventory each application: where it runs, whether it keeps sessions, whether it is exposed, and what an outage costs.

2. Classify by need: stateless internal services, critical business applications, fast-changing virtual applications, and microservices.

3. Measure real numbers: concurrent connections, TLS transactions per second, and peak bandwidth. TLS capacity often runs out before bandwidth does.

4. Design for availability: paired devices or engines per site, and global load balancing between sites where needed. Test the failure scenario before go-live.

5. Integrate security and monitoring: send WAF policy, access logs, and health alerts to your security monitoring platform so the ADC also becomes a useful source of visibility.

In our experience, organizations suffer less from missing capabilities than from capabilities that were never configured. Many ADCs we have reviewed had deep health monitoring, centralized TLS, and a WAF available, yet were used only as an expensive simple load balancer.

For the full English guide, checklist, and details: Load Balancer vs. ADC: choosing the right application delivery model

— Kazem Mortazavi, independent network-security consultant

What makes CVE-2026-96951 different

CVE-2026-96951 is a security feature bypass in Windows Shell with a CVSS score of 8.8. It defeats Mark of the Web (MotW), the marker Windows adds to files downloaded from the internet so that it can warn before a file opens. When that marker is bypassed, a malicious file can run without the warning users are trained to notice. Microsoft has not published how the flaw is being exploited or who reported it. CISA has added it to its Known Exploited Vulnerabilities (KEV) catalog, with a remediation deadline of October 16 for U.S. federal agencies.

Two more zero-days, already public

Two other flaws were disclosed before patches were available:

• CVE-2026-108398 affects .NET Framework and allows bypass of Windows Defender Application Control (WDAC), which can let unauthorized applications run. Microsoft considers exploitation unlikely.

• CVE-2026-92707 is a denial-of-service flaw in the MessagePack-CSharp component used by Visual Studio and .NET.

What the release covers

According to SecurityWeek, the release includes 1,102 Windows fixes, 134 for Office, 61 for developer tools and 36 for SharePoint Server. BleepingComputer counts 70 critical flaws, most of them remote code execution. The totals differ between outlets because some count only the Patch Tuesday release and leave out the 348 fixes shipped earlier in October, so the exact figure varies between about 1,411 and 1,413.

Practical steps this week

• Install the October 13 updates on Windows systems, starting with file servers, terminal servers and any machine that routinely opens internet downloads.

• Review your policies for files downloaded from the internet and your SmartScreen settings for unknown files.

• If you rely on WDAC, retest your application-control policies after patching.

• Take the final CVE list and fixed build numbers only from Microsoft's official advisories.

One number to keep in mind

The 2025 Data Breach Investigations Report from Verizon found that the median time to fully remediate edge-device vulnerabilities was about 32 days. That figure refers to edge devices, not Windows, but it shows the cost of delay. When an exploited flaw is public, every day without a patch is an open window.

For the full analysis and the checklist, read the original article (in Persian): Microsoft's October 2026 Patch Tuesday and the exploited Windows Shell zero-day

— Kazem Mortazavi, independent network-security consultant

Three questions to answer first

First, count your applications and APIs. Do not stop at the main website. Admin panels, internal systems, mobile back ends, and APIs that partners call are all applications, and the real number is usually two to three times the first estimate.

Second, decide who will use the tool: one penetration tester, a small security team, or dozens of developers across several teams.

Third, trace where findings go. A PDF report emailed to a manager is a very different workflow from findings that land directly in a development team's task system.

Three scenarios, three different needs

One expert, a handful of applications. A small organization or a consultancy running tests for clients needs accurate scanning, presentable reports, and low maintenance. A base-level scanner with API support and proof-based reporting of common issues such as SQL injection and cross-site scripting is often enough. A security team working with internal developers. Here the challenge is getting findings to developers and tracking fixes, which is where many programs stall. Team-oriented editions add role-based access, connections to delivery pipelines and ticketing systems, and the ability to create temporary firewall rules while code is being fixed. An interactive analysis agent running beside the test environment adds value too, because it points developers to the affected file and line.

Hundreds of applications in a large organization. Banks, telecom operators, and multi-subsidiary groups need scale, discovery of unknown assets, and central management. Enterprise platforms address this with cloud or on-premises deployment, parallel scanning, single sign-on, role-based access control, and proof-based engines that confirm vulnerabilities through controlled exploitation.

Four common mistakes

• Scanning without logging in. Most application logic sits behind authentication. A scanner that never gets past the login page has seen only the shell of the application.

• Forgetting APIs. Without an API definition such as OpenAPI or a Postman collection, the APIs behind a mobile app may never be tested.

• Confusing web and infrastructure scanners. Infrastructure scanners assess servers and services; web scanners assess application logic and inputs. They complement each other.

• Buying beyond remediation capacity. A tool that generates a thousand findings without anyone to fix them only documents your security debt.

A five-step selection plan

1. Inventory every application and API, with its owner, environment, and business criticality.

2. Define the path a finding takes from discovery to remediation, and who owns each step.

3. Trial candidates on two or three of your own applications, including one with a complex login and one with an API, rather than on a vendor's demo site.

4. Measure finding accuracy, scan duration, report quality for developers, and how easily the tool connects to your own systems.

5. Set remediation deadlines by severity, for example seven days for critical and thirty days for high, and report against them monthly.

The data shows why this matters. In Veracode's 2026 State of Software Security report, 82 percent of organizations carry security debt, meaning flaws that have remained unresolved for more than a year. The bottleneck is rarely discovery. It is getting findings to someone who will fix them.

For the full guide, the checklist, and the details (in Persian): Web application scanning: how to match the tool to your organization

— Kazem Mortazavi, independent network-security consultant

The Verizon 2026 Data Breach Investigations Report found that credential abuse still appears in about 39 percent of breaches at some point in the attack chain. A stolen or guessed password remains one of the most common ways in.

Two different controls

• Single sign-on (SSO) means one authoritative identity and one sign-in across several applications. When an employee leaves the directory, access to every connected application ends with that one change.

• Multi-factor authentication (MFA) adds a second factor to sign-in. Number matching, where the user types a number shown on the login screen, is far more resistant to push fatigue than a simple approve button.

• SSO without MFA simply means one password that opens every door.

Where to start

• List internal applications and rank them by the data they hold and whether they are reachable from the internet.

• Enable MFA for administrators first, then for VPN and remote-work portals.

• Pilot SSO with two or three high-risk applications, then expand.

• Move shared and service accounts into a privileged access vault, and give every privileged access an owner and an expiry date.

I wrote the full five-step plan, the three common mistakes and a two-week pilot in the complete guide, in Persian: Why a password alone is no longer enough: MFA and SSO for internal applications

— Kazem Mortazavi, independent network-security consultant

A password alone is not enough

Passwords escape in many ways: phishing pages, credential-stealing malware, or a password reused on another website that later got breached. Multi-factor authentication (MFA) changes the rule: besides something the user knows, the sign-in also requires something they have (a phone or a hardware key) or something they are (such as a fingerprint). A stolen password on its own no longer opens the door.

Which second factor?

Not every method offers the same protection, and the choice is a trade-off between security and convenience:

• SMS codes: easy and familiar, but the weakest option

• One-time passwords from an authenticator app: a good balance of security and simplicity

• Push approval: very convenient for users, with good security

• Hardware keys: the highest level of assurance, well suited to administrators and sensitive accounts

There is also adaptive MFA: the system asks for the second factor only when a sign-in looks risky, for example from an unfamiliar device or location. Users see fewer prompts, and security does not suffer. Whichever method you pick, plan the recovery path too: a lost phone or key should lead to a verified reset, not to a help-desk call that skips the second factor.

Where to start

You do not need to cover everything overnight. A sensible order is:

• VPN and remote access first, because they are directly exposed to the internet

• Then corporate email and web portals

• Administrator logins to servers and network devices

• RDP and Windows logon on sensitive systems

• Finally, cloud applications, together with single sign-on (SSO)

MFA is one piece of the larger identity and access management picture, and it works best alongside SSO and privileged access management (PAM). Even so, few security measures reduce this much risk at such a low cost.

The full article includes a comparison table of second-factor methods and more detail on rollout: https://symantecland.com/multi-factor-authentication-mfa-explained/?utm\_source=hashnode&utm\_medium=article&utm\_campaign=sx\_syndication

— Kazem Mortazavi, independent network-security consultant