PCredz is a network credential analysis tool that examines packet captures
to identify potentially exposed authentication data. Security professionals
can use it to investigate insecure protocols, understand credential exposure,
and identify weaknesses in network authentication.
Welcome back, fellow cybersecurity enthusiasts!
In this tutorial, we will explore PCredz, a tool used for
network traffic analysis, credential exposure assessment, PCAP analysis,
and authentication security testing. Rather than manually inspecting
every packet, PCredz can help identify supported authentication artifacts
within captured network traffic.
Understanding how credentials travel across a network is an important part
of ethical hacking, penetration testing, incident response, and defensive
cybersecurity. Analyzing these artifacts can help organizations discover
legacy authentication protocols and reduce the risk of credential theft.
PCredz is an open-source tool designed to extract supported credential
artifacts and other sensitive information from network packet captures.
It is useful when examining traffic generated by older protocols or
authentication mechanisms that may expose sensitive information.
Depending on the protocol and the available packet data, PCredz can identify
artifacts associated with authentication mechanisms such as NTLM and Kerberos,
as well as certain HTTP authentication methods and credentials associated
with services such as FTP, POP, SMTP, and IMAP.
It may also identify other sensitive data patterns, including certain
payment-card number patterns and SNMP community strings. Detection depends
on the capture contents, protocol support, and tool version.
A critical distinction is that finding an authentication artifact
does not automatically mean that a valid, reusable password has been recovered.
Some protocols expose hashes, challenge-response exchanges, or other material
that requires further analysis.
2. Key Features and Capabilities of PCredz
Network Packet Capture Analysis
PCredz can process supported packet capture files, making it useful for
investigating previously recorded traffic. PCAP files may contain evidence
of insecure authentication, accidental data exposure, or legacy protocols
that should be reviewed.
Authentication Artifact Identification
The tool can help identify supported authentication-related data, including
certain NTLM and Kerberos artifacts. These findings can support a wider
security assessment of authentication configurations and network exposure.
Multiple Protocols
Depending on the captured traffic and implementation, the tool can inspect
authentication exchanges associated with several common network services.
Support for IPv4 and IPv6 traffic also makes it relevant to mixed network
environments.
Structured Output
PCredz can write discovered artifacts to output files, including a
credential dump file. Structured output helps security analysts review
findings, document evidence, and investigate potential exposure without
manually collecting every result.
3. When Would You Use PCredz?
PCredz is relevant to both offensive security assessments and defensive
network investigations when its use is explicitly authorized.
Internal Security Assessments
Security teams can analyze approved packet captures to determine whether
legacy services or authentication configurations expose sensitive data.
The results can help prioritize the migration of insecure services and
the improvement of network segmentation.
Incident Response
During an investigation, analysts may inspect existing packet captures
for authentication artifacts associated with suspicious activity.
Any discovered credentials or hashes should be handled as sensitive evidence
and stored securely.
Legacy Protocol Audits
Older business environments may still contain services that use outdated
authentication mechanisms or transmit information without adequate protection.
PCredz can help identify evidence of these weaknesses when relevant traffic
is available.
Security Training and Research
In a controlled lab, PCredz can demonstrate why encrypted transport,
modern authentication, and strong network security policies matter.
Students can compare insecure and secure authentication configurations
using traffic generated specifically for the exercise.
Important: Only inspect traffic that you own or are explicitly
authorized to analyze. Captured network traffic can contain personal information,
session tokens, credentials, and other confidential data.
4. Installing PCredz on Linux
PCredz is available through its official GitHub repository. Before
installation, review the repository's current instructions and dependencies.
The commands below illustrate a basic Linux setup; exact requirements may
vary with the current version of the project and your distribution.
Step 1: Install the Required Packages
On Debian-based systems, such as Kali Linux, update the package index
and install Python virtual environment support and relevant development
dependencies.
git clone https://github.com/lgandx/pcredz.git
cd pcredz
Step 3: Create a Virtual Environment
A Python virtual environment keeps project dependencies separate from
system-wide Python packages. This is particularly useful on recent Kali
Linux and Debian releases, where system Python environments are managed
by the operating system.
Check the repository for its current dependency instructions before
installing packages. If the project provides a requirements file, review
it and install the documented dependencies inside the activated environment.
python -m pip install --upgrade pip
# If the repository provides requirements.txt:
python -m pip install -r requirements.txt
Do not assume that every version of PCredz uses the same dependency list.
If installation fails, consult the official repository documentation and
the error message before changing system packages.
5. Understanding Live Network Traffic Analysis
Live traffic analysis involves examining packets as they pass through
a network interface. It can help authorized network administrators identify
insecure authentication exchanges and investigate suspicious network activity.
Before performing live capture, identify the correct interface and verify
that the capture is approved by the network owner. Interface names differ
between systems, so do not assume that every machine uses eth0.
To list available interfaces, use:
ip -br addr
For an authorized assessment, follow the current usage instructions
provided by the official PCredz repository. Confirm that the selected
interface is appropriate and that the capture scope is limited to the
approved environment.
Capturing on an interface does not guarantee visibility into all network
traffic. Switching infrastructure, VLAN configuration, Wi-Fi encryption,
virtualization, and network topology can affect which packets are observable.
6. Analyzing Existing PCAP Files
Offline PCAP analysis allows investigators to examine previously captured
network traffic without continuously monitoring a live interface. This can
be useful for incident response, security audits, and controlled training
exercises.
PCAP files are commonly generated by packet analysis tools such as
Wireshark and
tcpdump.
Inspecting a Capture with Wireshark
Open the authorized PCAP file in Wireshark and examine the relevant
protocols, endpoints, and authentication exchanges. Display filters can
help narrow the investigation to specific protocols or conversations.
When reviewing a capture, pay particular attention to:
Services that use unencrypted or inadequately protected communication.
Sensitive information accidentally included in application traffic.
Repeated authentication failures or unusual communication patterns.
Using PCredz for Offline Analysis
When using PCredz against an authorized capture, consult the current
repository documentation for the supported command-line options.
The project's documented usage includes options for processing a capture
file or a directory of captures. Confirm the precise syntax for your installed
version before running an analysis.
After processing, store the results in a protected directory. Review
the output carefully, because a discovered artifact may require additional
context before it can be classified as a security finding.
Evidence-handling tip: Preserve the original capture, record
its cryptographic hash when appropriate, document the analysis environment,
and restrict access to extracted data. Avoid transferring confidential PCAP
files to third-party systems unless that transfer is explicitly authorized.
7. PCredz and Hashcat: Understanding the Difference
PCredz and Hashcat serve different purposes in a security assessment.
PCredz identifies supported credential-related artifacts
in captured network traffic. Hashcat is a password recovery
and password-strength auditing tool that supports many hash formats.
Some authentication artifacts identified by PCredz may be suitable for
further analysis with a compatible password-auditing tool. Compatibility
depends on the exact artifact format, the protocol, and the supported mode
in the installed version.
For example, Hashcat documents different modes for certain NTLM and
Kerberos-related formats. A mode number must not be selected solely from
a generic label: analysts should verify the exact format against the
official documentation.
Hash analysis can help organizations determine whether their password
policies resist common guessing attacks. A recovered password, however,
does not by itself establish that an account is currently accessible or
that the account has elevated privileges.
Credential exposure can allow an attacker to impersonate users, access
internal services, or attempt further compromise. The actual risk depends
on the credential type, account privileges, network architecture, and
additional security controls.
Use Encrypted Protocols
Replace insecure protocols with appropriately configured encrypted
alternatives. Use HTTPS for web applications and secure configurations
for remote administration, email, and file transfer.
Strengthen Authentication
Use modern authentication mechanisms wherever possible. Disable obsolete
authentication methods when they are no longer required, and enforce
multifactor authentication for sensitive accounts and remote access.
Reduce Credential Reuse
Encourage unique passwords and use an approved password manager.
Privileged accounts should have separate credentials and carefully
controlled access.
Apply Least Privilege
Give users and services only the permissions they need. Segment sensitive
systems and restrict unnecessary communication between network zones.
Monitor and Respond
Monitor authentication logs for suspicious access, repeated failures,
unusual source systems, and unexpected use of privileged accounts. If
credential exposure is confirmed, follow the incident response process,
rotate affected credentials, and revoke compromised sessions where appropriate.
9. Common Misconceptions About PCredz
Does PCredz Crack Every Password?
No. PCredz is primarily used to identify supported artifacts in network
traffic. Whether a password can be recovered depends on the data captured,
the authentication protocol, and the availability of a compatible analysis
method.
Can It Read Every HTTPS Password?
No. Properly configured HTTPS encrypts application traffic in transit.
A normal packet capture generally cannot reveal the protected application
contents simply because PCredz is being used.
Does Finding a Hash Mean an Account Is Compromised?
Not necessarily. A hash or authentication exchange must be assessed in
context. Its security impact depends on the protocol, account status,
password strength, and whether the artifact can be abused.
Is Live Capture Always Better Than Offline Analysis?
No. Live capture may help investigate current activity, while offline
analysis is often more suitable for examining preserved evidence. The
right approach depends on the investigation scope, authorization, and
operational requirements.
10. Conclusion
PCredz is a useful tool for understanding credential exposure in network
traffic. By examining authorized packet captures, cybersecurity professionals
can identify authentication artifacts, investigate legacy protocols, and
discover weaknesses that require remediation.
However, the value of PCredz goes beyond extracting data. Its findings
can help organizations improve encryption, modernize authentication,
reduce password reuse, and strengthen their incident response practices.
For anyone learning network security, the key takeaway is simple:
understanding how authentication data moves across a network is
essential to protecting it.
For more cybersecurity tutorials, ethical hacking resources, OSINT guides,
and network security insights, visit
Hackersking.
Understand APNIC IPv4 transfer rules, buyer requirements, fees and approval steps, with helpful checks to assess address blocks before completing a transaction.
Compare WireGuard, OpenVPN and Shadowsocks for speed, privacy, enterprise access and censorship resistance, including VPN tunnels differ from encrypted proxies.
Fraud prevention combines rules, AI and behavioral analytics to stop scams, reduce false declines and keep automated decisions explainable through human review.
eMudhra will leave the global SSL/TLS certificate market after eight intermediate CA private keys were found easily guessable, prompting browser distrust actions.
AI agents and associated tooling are becoming increasingly common in corporate infrastructure. Agents can perform a range of actions with the user’s privileges, such as accessing data, running commands, and interacting with external services. This creates new security risks, especially when these tools are used without the security team’s oversight or well-designed policies.
Detecting, tracking, and controlling AI agents is becoming one of the most pressing tasks for security teams today. We closely follow technological developments and continuously update our solutions to respond to new threats in a timely manner amid a rapidly changing technology landscape. This post describes new expertise built into Kaspersky products that helps counter the threats posed by the proliferation of AI agents. We approach this problem from several angles.
First, you need to thoroughly understand the threat you are dealing with. To this end, we added profiles to the Kaspersky Threat Intelligence Portal that describe various AI agents and how attackers exploit them. At their core, AI agents are programs (processes) that run in the operating system on endpoints and can also launch other processes. This means that Endpoint Detection and Response solutions are among the key endpoint controls for this threat. These solutions detect the presence and launch of AI agents, track their activity, and identify potentially dangerous behavior. When needed, they also take action, such as stopping a suspicious process, blocking the activity, or isolating the host, to reduce the likelihood of an incident escalating. For this purpose, we developed specially adapted detection rules.
You can use Kaspersky Endpoint Security, now also available as Kaspersky Next, to control and restrict the launch of AI agents. This solution uses two components to detect AI agents and control how they are used. Application Control categorizes the application processes launched on endpoints, and Web Control manages access to specific categories of web resources for users on endpoints.
Finally, even harmless AI agents can contain malicious instructions (skills), such as those downloaded from unsafe external sources. Kaspersky Scan Engine analyzes installed applications to detect these threats and also checks LLM files for malicious code. Let’s take a closer look at these solutions and technologies.
Popular AI applications and services in organizations
Tools from Anthropic and OpenAI take the top spots in the September 2026 ranking of AI agents by popularity among Kaspersky users. This list is based on telemetry from Kaspersky solutions. It shows the number of users who had the relevant AI vendors’ products installed at the time of the study.
#
AI product
1
Claude
2
Claude Code
3
Codex
4
OpenCode
5
Zed
6
Wispr Flow
7
LM Studio
8
ZCode
9
Chatbox
10
Cherry Studio
The data shows that agentic systems, especially AI agents for software development, are the most popular AI applications. The TOP 10 also includes an application for running large language models locally (LM Studio) and a voice note-taking app (Wispr Flow).
According to open sources, these are the most widely used AI services in 2026:
Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)
* Data for previous quarters was updated and may differ slightly from previously published data.
Application Control and Web Control
To enforce the organization’s security policy for AI agents and other AI applications on the corporate network, Kaspersky products offer application control based on KL categories. These categories classify installed software and give you granular control over which approved applications can run in the organization.
Application Control analyzes the processes launched on endpoints, tracking which AI agents are running in corporate systems at any given moment, on which hosts, and under which accounts. Application Control also shows how long a given program has been in use.
This makes it easier for the Kaspersky Security Center (KSC) administrator to control applications. Administrators can use KL categories to allow or block AI agents inside the company for specific groups of employees.
Here is what this functionality looks like to KSC administrators:
KL categories available when configuring Application Control
For details on how to configure Application Control in KSC, follow this link.
In Kaspersky Endpoint Security (KES), Application Control can operate in two modes:
Denylist. In this mode, Application Control lets users run any applications except those blocked by Application Control rules. This is the default mode.
Allowlist. In this mode, Application Control blocks users from running any applications except those explicitly allowed by Application Control rules.
Below are the steps to configure Application Control to block AI tools.
Configuring Application Control for the AI Tools category in KES
With this setup, when a user tries to launch an AI agent, they get a notification and the agent doesn’t start.
KES notification about an attempt to launch an AI agent
The View applications drop-down list shows products for a specific vendor.
Similarly, Web Control lets you manage user access to web resources. If a user tries to open a denylisted website, KES blocks access and shows a warning.
KES notification about an attempt to access a prohibited web resource
When configuring access, the administrator can block websites that provide AI as a service.
Website categories
For more on configuring Web Control, follow this link. The help portal also provides information on website categories that can be assigned to resources to configure access control.
Kaspersky Endpoint Detection and Response
To an EDR solution, an AI agent is a regular process. It has its own executable, a tree of child processes, and network communications, all of which need to be monitored for suspicious activity. An attacker can use an AI agent as an automation tool. An AI agent installed as a legitimate user tool can also be leveraged in a ClickFix attack, where it executes a malicious instruction received from an untrusted source, such as a document, web page, or email. That said, unsafe actions by an agent do not always indicate an attack. There may be no malicious intent in the chain at all. An incident can result from what looks like an ordinary instruction from a user who doesn’t fully understand the consequences of having it executed. The mere fact that an agent was launched does not reveal whether it is being used in an attack. That is why Kaspersky EDR (KEDR) uses both conventional behavioral rules and rules written and adapted to detect AI tools. The latter identify risky agent actions and settings, and help determine which AI tool was involved in suspicious activity.
Conventional KEDR rules detect the vast majority of familiar malicious techniques, including when performed by an AI agent. A suspicious PowerShell launch, persistence via Task Scheduler, or an attempt to steal credentials leaves clear, identifiable traces. These traces look the same no matter what initiated the actions. The rules analyze launch parameters, process relationships, affected files, network activity, and other telemetry events.
For example, in a recent Armored Likho campaign, we found signs that AI had been used to create loader and dropper samples, which were later compiled with NSIS (Nullsoft Scriptable Install System). The key telltale artifacts were icons in the scripts and excessive comments on every function, which is uncharacteristic of human-written code. In addition, the group continues to generate new modules for its BusySnake Stealer and BusySnake RAT samples. For example, the attackers used AI to develop a module that runs multiple checks for virtual environment artifacts and calculates a score. Depending on the score, the sample either runs or exits with code 0. Even though the initial access samples, payloads, and their modules were AI-generated, the commands they execute via rundll32 and PowerShell are detected by the shell_creation_by_rundll32 and suspicious_powershell_cmd_or_script_spawning rules.
So, for detecting an attack like this, it is not important who wrote the loader, the payload, or its modules: they are given away by the commands they execute, process relationships, and other traces of activity in the system. AI can be involved both in preparing the code and in carrying out the attack directly on the device.
In the latter case, the attacker uses the agent to carry out their tasks and lets it choose and run the required commands within the privileges it has. For effective protection, it is critical to link suspicious actions back to the AI tool and the conditions under which it operates. In KEDR, several specialized rules handle this task.
We have created separate rules for popular AI agents, ai_agent_*_access_to_sensitive_file_**, where * is the tool name and ** is the operating system. They generate alerts when an agent accesses files that contain credentials, tokens, or keys.
The ai_agent_dangerous_execution_mode rule detects agents launched with auto-approval of all actions (so-called YOLO mode) or with the sandbox disabled. These settings do not indicate an attack on their own, but they let the agent perform dangerous actions without user confirmation.
The suspicious_mcp_server_artifact rule triggers when MCP server scripts are created or modified in hidden, temporary, or cache directories. Attackers can place an MCP server in these locations to quietly connect it to the agent: through the MCP server, they can pass instructions to the agent, call third-party tools, and access the user’s data.
The llm_api_access_by_unusual_apps rule generates an alert when an application on Windows, Linux, or macOS connects to the API of a known external LLM service, unless this activity falls under predefined exclusions. This helps spot model access by applications that do not normally behave this way.
Some Kaspersky EDR rules tag events for investigation but do not generate alerts. For example, the ai_agent_**_execution rules flag launches of known agents on Windows, Linux, and macOS. The local_ai_model_artifact rule records the creation or modification of AI model files in typical application, runtime, and cache directories. These events reveal AI tools on the device, including tools that run on local models and never call an external API.
The Kaspersky Threat Intelligence Portal offers a large number of software profiles, including profiles of AI agents. You can sort them by the ai_ prefix:
AI agent profiles on Kaspersky TIP
The profile of an AI agent such as Claude Desktop includes a detailed description of the software, the privilege level required to run it, supported platforms, and threat actor groups known to use it. It also lists tactics and techniques mapped to the MITRE ATT&CK framework, with descriptions of the procedures the tool can be used for.
Claude profile on Kaspersky TIP
The description also lists ways to detect the software through standard system auditing mechanisms:
Windows: events from standard audit logs and Sysmon events
Linux: syscall audit events and Sysmon events
Network auditing: a set of protocols and the traffic generated by the software
The detection section lists the main artifacts the software leaves in the system: command lines, possible launch parameters, names of the services and scheduled tasks it creates, and the key network artifacts.
Detection section in the Claude profile
Hunt Hub
In December 2025, the Kaspersky Threat Intelligence Portal added Hunt Hub (HH), a repository of detection rules. This is a unique Kaspersky project, and we developed it in response to growing market demand.
This functionality is available in the Threat Landscape section of the portal. It gives analysts access to detection rules: their descriptions and their mapping to MITRE ATT&CK tactics and techniques, as well as to the associated cybercriminal groups.
In the Hunt Hub section, customers can explore the detection logic of EDR, NDR, and NGFW products, including the logic for detecting AI agents.
Rules in the Hunt Hub repository
The rule card provides:
Detailed description
Rule’s severity level, confidence level, and alert format
Detection tips
Description of possible false positives
Platforms the rule can run on
Tactics, techniques, and sub-techniques covered by the rule
Groups that use the technique covered by the rule
Detection logic that shows what exactly triggers the rule
Detection rule card in Hunt Hub
Kaspersky Scan Engine
Skills are a key component of the AI agent ecosystem. They’re prewritten sets of natural-language instructions that extend agent functionality. We previously covered the risks that malicious skills pose to agent users. A skill can require the usage of additional programs and services, come with helper scripts (for example, written in Python), or contain a malicious command embedded right in the instruction text. This means that adding skills to an originally harmless AI agent opens up several new ways for malicious code to enter the system. To prevent this, any skills obtained from external sources must be scanned. Kaspersky Scan Engine is well suited for this task. This is a cyberthreat detection and response solution that seamlessly integrates with various applications. It can detect malicious code in agent skills, associated scripts, and in files generated by running agents.
Detection of a malicious agent skill in Kaspersky Scan Engine
Trained LLMs come in many formats. Some of them (PTH, PT, PKL, KERS, and others) also store parameters and weights (training datasets). These files can also contain malicious code, so it’s critical to scan them before running and using them. Kaspersky Scan Engine scans potentially dangerous LLM formats for infected data. It can deserialize and analyze models to detect malicious code regardless of model size.
Detection of an LLM with malicious code in Kaspersky Scan Engine
Conclusion
AI agents are rapidly making their way into corporate environments: they help employees work faster and take on a wide range of tasks, but they also open up new opportunities for attackers. To take advantage of this technology without compromising security, organizations need to build multi-layered protection and minimize risks. A range of Kaspersky solutions can help with this:
Kaspersky TIP keeps you up to date on current scenarios in which attackers use AI agents, and its Hunt Hub section provides rules for detecting suspicious AI agent activity.
Kaspersky EDR detects AI agents in the infrastructure and monitors their activity on endpoints. If it detects potentially dangerous actions, the product can log the event, notify the SOC, and take response actions, such as stopping the process or isolating the host.
Application Control in Kaspersky products can fully restrict the use of AI agents within the company by using application categorization. The Web Control component can restrict access to AIaaS web resources.
Kaspersky Scan Engine can be integrated into various company processes to detect malicious code in any files, including AI agent skills and LLMs.
When companies combine the tools described above in a comprehensive approach, they can adopt AI agents in an informed way: with an understanding of the associated risks and effective means of minimizing them.
GoDaddy revoked 404,607 SSL/TLS certificates after finding certificate-policy errors, with affected sites including some Gibraltar government websites.
Cardano payroll could support ADA salaries and automated payments, but employers must address price volatility, tax obligations, wallet security and compliance.
Discover how multi-cloud environments create security blind spots, inconsistent access controls, risks and how CCSP strategies help strengthen cloud security.
Imagine you’ve ordered a small paper unicorn from an online marketplace. You clicked “Buy”, received a cheerful notification, and expect a courier to bring the box tomorrow. If the unicorn is delayed by a day, it will be annoying but not catastrophic: an apology, a discount promo code — and the incident is forgotten.
Now let’s multiply one late unicorn by several hundred thousand orders.
Packages start heading to the wrong cities. The website shows an item is in stock, even though the required bin is empty. Conveyors stop, boxes get stuck between floors, the cargo piles up with no freight manifest. Trucks line up at the gates, and every minute of downtime turns into blown schedules, support tickets, fines, and lost sales.
It is at exactly this scale that a cyberincident in a warehouse becomes a problem for the entire business. A modern warehouse is no longer just a big building with shelving. It is a tightly interconnected hybrid system: web applications, radio channels, and an automated factory. Physical processes here depend on data, and errors in data have very physical consequences. Examples include an outage that affected warehouse management systems at the grocery giant Morrisons, and the 2025 Form 10-K annual report of United Natural Foods, Inc. (UNFI), which confirmed unauthorized activity on information technology systems that impacted order fulfillment. More recently, reports emerged that a cyberattack disrupted eight CEVA Logistics warehouses across Europe and exposed customer delivery data.
This paper follows a single order through a warehouse to show where the operation is vulnerable, the stages it traverses, the systems that drive it, and the points where an attacker can reach them. We then set out the threat model: what is at risk, who is in a position to take it, and how each risk lands on the business. From there, we look at how an attacker gets in, and what reaching the warehouse management system costs in practical terms: orders unshipped, inventory records nobody can trust, and an operation that stops. We close with recommendations on where the controls that matter actually sit.
Tracing the unicorn
A modern warehouse is a sequence of stages involving many machines and people, all working together to keep the business process stable so that, in the end, your order gets delivered. This process consists of eight main stages, shown in the figure below.
Stages of order fulfillment
So let’s assume we’ve ordered our paper unicorn and are waiting for it at home. Let’s follow our order through all the main stages, from its arrival at the warehouse to the final stop on its journey.
Unloading First, the unicorn arrives in the unloading zone, packed in a big truck. The driver is assigned a gate, for example, via a tablet with kiosk mode enabled, or an outdoor display board, indicating where the truck should park and where the cargo will be unloaded. Even at this very first step, a digital command (the gate number on the screen) is already triggering a physical action. Therefore, incorrectly assigned gates can create a queue, delay unloading, or send goods into the wrong workflow.
Receiving At this stage, employees identify the cargo. They scan a barcode using a portable data terminal (PDT) and the central system receives a message indicating that this object arrives at the warehouse. From this moment, the unicorn exists in two forms at once: as a real box and as a record in the information system. If these two versions diverge, the error is inherited by all subsequent processes.
Putaway Next, the goods are moved into internal storage. Two new devices come into play here. First, a thermal printer, connected to the internal network over Wi-Fi, creates an internal label for each item. Then an employee, forklift, or automated system moves the goods to the assigned bin, often with the help of lifts controlled by PLCs. Both of these devices can be valuable attack entry points: one can let an adversary pivot into the internal network, while the other can give them control over an electric motor.
Storage Then the unicorn goes into storage. Many distribution centers use multi-level mezzanine structures: several floors of metal shelving inside a huge space. They allow efficient use of the building’s height, but at the same time complicate control over the technical infrastructure. Wi-Fi access points, cameras, switches, cables, and sensors may be mounted high overhead or buried deep inside the rows. A forgotten Ethernet cable or misconfigured networked device (access point or switch) left behind in a dark corner can become a convenient initial access point into critical infrastructure.
Picking When the customer places an order, picking begins if the goods were already stored in the warehouse or as soon as they are unloaded. A PDT, workstation, light indicator, or voice terminal directs the employee to the required bin where they pick the goods and move them to the next stage. These devices are themselves potential attack entry points: compromising a workstation or PDT could allow an attacker to manipulate picking information, which could misdirect employees to the wrong bin. Here, both the speed and integrity of the information are critical, and any manipulation or disruption can lead to wrong orders, delays, or problems in subsequent stages.
Sorting At the sorting stage, the warehouse starts to look more like a factory. Boxes move through conveyor belts and pass through different scanners, diverters, and chutes. The sorting plans are usually stored and managed by dedicated servers, while PLCs are responsible for controlling the machinery and executing these plans. For example, when the warehouse management system (WMS) decides that our unicorn should take route A, the control system needs to activate the right diverter at the right moment, sometimes within a fraction of a second.
Packing During packing, an employee or a robotic arm places the goods into the final box, prints the shipping label, and sometimes measures the dimensions and weight of the package. Safety mechanisms usually prevent robotic arms from leaving the controlled zone and harming nearby operators, but their compromise might inflict physical damage on the packages being processed.
Shipment Finally, at the shipping stage, the parcel heads to the gates. Automated guided vehicles (AGVs) and autonomous mobile robots (AMRs) move containers and pallets across the warehouse, while the dock management system coordinates the truck that will carry the unicorn onward to a store, a sorting center, or straight to the customer. These robots are themselves a potential target for attackers. Attacks can be conducted against AGVs and AMRs to interfere with their operation, for example by affecting their navigation or preventing them from reaching their intended destination.
All eight stages are coordinated by the WMS. It looks like a large web application, but in its role it’s closer to the operating system of the entire warehouse: it knows which goods exist, where they’re located, who or what should move them, and where they go next, linking employees, inventory levels, storage addresses, tasks, and orders. It also exchanges data externally: with ERP systems, transport platforms, marketplaces, dark stores, and external carriers.
Surrounding the WMS is an even larger digital ecosystem: identity services, databases, APIs, printers, carrier systems, technicians’ laptops, video surveillance, access control, fire and gas alarms, power supply, and a building management system (BMS).
That is why a single “warehouse network” doesn’t really exist. As we’ve seen, there are many overlapping technologies — IT infrastructure, OT systems, radio, cloud services, building security, and automation — layered on top of one another. A lone vulnerability scanner will never tell you whether a warehouse is secure.
Hunting the unicorn
Securing an environment such as a warehouse requires a comprehensive security assessment covering all of its interconnected systems. This involves identifying vulnerabilities across each system and understanding how weaknesses can be combined into attack paths that a real attacker could exploit. But a vulnerability only matters in proportion to what it exposes and who is able to reach it, so before looking at the weaknesses themselves, we need to understand what an attacker in this environment is actually after, because in a warehouse, the blast radius extends well beyond data. Everything we just traced — the systems, the devices, and the people operating them — exists to keep goods moving, and attacks in various parts along that chain can affect the business differently. The chart below shows what is at risk in the warehouse and where those risks land for the business. The segment on the left groups them under the three core security properties: integrity, availability, and confidentiality. The segment on the right maps each property to the business outcomes a failure can cause.
Warehouse risks
The first area at risk is integrity. Inventory counts, locations, orders, and shipment data must stay in sync with the physical world. Corrupting a record silently desynchronizes the operation, and because the eight stages form a dependency chain, one falsified entry early on is inherited downstream, surfacing later as stockouts and mis-shipments. In its deliberate forms, this lets an attacker redirect goods, release stock, and perform other actions on behalf of the platform’s vendors under cover of legitimate records. Integrity is also a safety concern: when people or machines act on information that no longer reflects the physical environment, a data failure can become a physical incident. This is why integrity is the only property linked to all five outcomes, including harm to people.
The second is availability, the warehouse’s ability to keep goods moving. Halting a conveyor, a sorter, label printing, or the WMS stops orders from shipping, and in a business built on speed, every hour of downtime means delayed deliveries and broken promises. Ransomware can bring the whole warehouse to a standstill. The impact shows up as operational disruption, lost revenue, and reputational damage.
The third is confidentiality. Customer data, business records, and system credentials are valuable targets. Their exposure leads to legal liability and reputational damage, and stolen credentials often open the door to further attacks. Where the WMS connects to financial or ERP processes, the risk extends to theft of funds.
Knowing what is at risk tells us what an attacker stands to gain; the next question is who is in a position to take it. Threat actors differ in the access they already hold. For example, an attacker may be authenticated and privileged, have limited physical or remote access, or have no legitimate access to the environment at all. Based on their relationship with the warehouse and their level of access, threat actors can generally be divided into two categories:
External. An attacker with no legitimate relationship with the warehouse or the organization, operating without authorized access. External attackers can be divided into two categories based on their physical proximity to the environment:
Remote. An attacker operating from outside the site’s physical area, reaching the environment through whatever the organization exposes or makes reachable over the internet, including web services, remote access infrastructure, and third-party connections used by suppliers, carriers, and integrators.
Proximate. An attacker with no legitimate access who has nevertheless moved within physical range of the site’s locally reachable technologies. They may, for example, be in a parking lot, a neighboring unit, or a delivery bay. Their proximity may allow them to interact with wireless, radio, Bluetooth, or other short-range interfaces without possessing an account, badge, employment relationship, or other authorized access.
Internal. An individual with legitimate access to the warehouse, its systems, or its information, who intentionally or unintentionally creates a security risk. This includes employees, administrators, operators, contractors, and temporary staff.
Combining these threat actors and their access levels with the risks identified earlier, the vulnerabilities present in each system, the resulting attack surfaces, and the potential attack paths between them provides a threat model for the warehouse environment. This allows an organization to understand how different systems and people could be targeted, how individual weaknesses could be combined, and where security controls are most needed.
Cornering the unicorn
Knowing what is at risk and who might come after it still leaves the most practical question open: how they would actually get in, and how far they could go once they did. The diagram below sets out the warehouse’s attack surface: every point where an attacker can get in, organized by the access that reaching each point requires.
Warehouse attack surface
On the left are the attacker categories discussed above, distinguished by where they stand and what access they already hold. Each reaches the environment through a different set of entry points, and the impact of a successful attack can land on several systems, from the WMS to OT systems such as robots, sorters, and physical access control system (PACS). The WMS is highlighted because it is the most significant of these: it coordinates the OT systems, so compromising it can affect the entire operation rather than a single process.
Next, we will cover the initial access vectors, the points a threat actor can use to reach the warehouse environment. Following that, we turn to the impact on the logistics processes themselves, focusing on the WMS, since its compromise affects every logistics operation that depends on it.
Initial attack vectors
Internet-facing services
Remote access through internet-facing services, third-party connections, and corporate networks gives an external attacker a foothold on the warehouse network infrastructure. It is a well-covered problem and not specific to this environment, so we note it here as an entry point but will not examine it further.
Wi-Fi, Bluetooth, and other radio channels
Wi-Fi connects handhelds, tablets, printers, cameras, and workstations. Bluetooth serves scanners, headsets, and positioning beacons. Zigbee and similar low-power protocols run lighting, sensors, and building automation, while LoRaWAN carries telemetry over long distances. Cellular provides a backup channel for kiosks and contractor equipment, and proprietary protocols control industrial panels and specialized machinery.
Radio passes through windows, gates, roofing, and thin external panels, so a network built for receiving and processing goods may be reachable from the parking lot and, with a directional antenna, from considerably farther away.
That reach matters in two ways. It gives an external attacker a place to start, as proximity alone is enough to reach the Wi-Fi and the low-power protocols, and from there to gain an initial foothold in the warehouse networks.
However, radio does not only lead into the network. It also connects directly to the field devices and carries the live control traffic of warehouse operations, which makes availability a first-order concern. If hundreds of handhelds lose their connection at once, picking stops. If an AGV loses its control channel, the safe reaction may be to halt in place, and a stopped machine can block an entire route.
Physical network
The scale of the warehouse itself is part of the attack surface. A fulfillment warehouse can run up to tens of thousands of square meters, with racking climbing several stories and walkways threading through it. Structured cabling runs along that racking, cameras and access points are mounted on that, and wall jacks sit behind pallets that have not moved in months. Almost none of it is in anyone’s line of sight.
That gives a person in the warehouse something a normal office does not: unsupervised access to live network infrastructure. Unplugging a ceiling camera leaves an active port. An unused jack behind a shelf leaves another. Neither requires tools, credentials, or any interaction with a system that logs anything. And since the camera or access point sits on the same segment as the rest of the site, the compromised port, not being isolated, opens a path to the network core.
Barcode scanners
Barcode scanners are everywhere in a warehouse. They are the main tool workers use to tell the system what is moving and where, supporting receiving, picking, packing, and inventory management. A typical setup has handheld scanners communicating with a base station, which is in turn connected to a workstation or another business system.
This makes the scanner an entry point into the core network in two ways.
First, through the barcode itself. Since the scanner acts as a keyboard to the connected host, a maliciously crafted barcode or QR code can inject keystrokes when scanned, potentially giving the attacker an initial foothold on the host without directly accessing the network.
Second, through the scanner’s wireless link. During a customer engagement, with the provided test stand of such a device, we discovered that an attacker within range could inject keystrokes into the connected host and potentially achieve remote code execution without user interaction. This attack pattern was observed across multiple vendors, including, for example, Honeywell devices affected by CVE-2026-4272.
In both cases, the result is the same: a foothold on a host inside the warehouse network. The scanner is simply the entry point; the significance of that foothold comes from the host’s trusted position within the operational environment and its connectivity to core systems.
Portable data terminals
Portable data terminals (PDTs) are essentially ordinary Android devices with an embedded barcode scanner, carried by workers to scan items; each scan is passed to a dedicated application that forwards it to a remote server over an API. To keep workers on task, the devices usually run in kiosk mode, locking the user to that single application and preventing interaction with the rest of the Android system.
That lockdown is exactly what an attacker wants to break, and breaking it is what turns the terminal into an initial access vector: escaping the kiosk can expose the Wi-Fi password of the network the terminal is connected to, or allow malicious software to be installed that gives the attacker remote access to the network over the internet.
Printers
Warehouses contain different types of printers. Alongside the usual IT printers used for documents and paperwork, there are specialized thermal printers, small devices that use heated elements on the printhead to create labels, barcodes, and tags. As we mentioned earlier, these are mainly used to print the labels, usually containing barcodes, that are attached to goods during the putaway stage.
Here we focus on mobile thermal printers: small, battery-powered devices that workers can carry or wear. They typically connect to the internal network over Wi-Fi to receive print commands, while also supporting Bluetooth for connecting to nearby devices. This combination makes them a potential entry point into the internal network.
Some models, such as the Zebra ZQ630, support multiple interfaces and can run applications directly on the device. During a security assessment, we discovered that apps can be uploaded and executed over Bluetooth. By exploiting a pairing misconfiguration, an attacker within Bluetooth range could bypass pairing, upload malicious software, and gain an initial foothold through the printer.
Impact on logistics processes (attacks on WMS)
With a foothold in the network, an attacker can pivot to the logistics processes themselves: from the WMS through the warehouse infrastructure to the PLCs and the machinery they drive. As we saw earlier, all OT systems and devices are interconnected and the WMS sits at the head of that chain: it is the system of record every other process reads from and writes to, so compromising it reaches all of them at once. That, and its being specific to this environment, is why it is the focus here.
Warehouse management systems (WMS) are the software platforms that optimize warehouse processes from the entry of goods to their exit. They provide real-time visibility into inventory and orchestrate end-to-end fulfillment by integrating with many warehouse subsystems and pieces of automation equipment, such as conveyors, PLCs, robotics, scanners, and voice systems. A typical WMS includes modules for receiving, inventory control, order management, labor management, shipping, and reporting. Major vendors include SAP EWM, Oracle Warehouse Management, Manhattan Active, Blue Yonder, Infor, Körber/HighJump, Microsoft, and TECSYS.
To picture how central this is, think back to our unicorn. From the moment it was scanned at receiving, it stopped being only a physical box and became a record inside the WMS, a record the system then used to decide where it should be stored, when it should be picked, how it should be sorted, and where it should ship. Every device employed along the way — the PDT at receiving, the printer at putaway, the workstation at picking, the conveyor at sorting — was really just talking to the WMS. It is the thread that ties all eight stages together, which is exactly what makes it such a valuable target.
Because modern WMS platforms are usually web-based and heavily interconnected, they inherit common web and API vulnerabilities alongside flaws specific to the WMS itself. A recent example is CVE-2026-70774 in Oracle Warehouse Management, part of Oracle E-Business Suite. Oracle rated it High and described it as an easily exploitable authorization bypass flaw in which a low-privileged attacker with network access can compromise the application, affecting integrity and availability by allowing unauthorized creation, deletion, or modification of critical data.
A flaw like this may look like a typical web application issue, but its consequences in a warehouse are more serious, because the WMS is the system of record. If an attacker can modify its data, they can alter stock levels, bin locations, receiving records, picking tasks, or shipment information, silently corrupting the digital twin of the warehouse. And since the eight stages form a dependency chain, that corruption doesn’t stay contained: a falsified record at receiving is inherited by putaway, picking, and everything downstream. The physical box and its record diverge, and every later process trusts the record.
The most direct version of this attack comes from an authorization bypass flaw like the Oracle vulnerability above. Here the threat actor can be an external attacker who has reached the application over the network, or an insider such as a low-privileged operator or storekeeper who already holds a legitimate account.
The danger grows when such a flaw is chained with others. An external attacker who combines remote code execution with SQL injection could generate shipment orders to arbitrary addresses together with the documents needed for goods to physically leave the warehouse, fabricate waybills, acceptance or transfer records, and registers, while also exposing customer data such as names and delivery addresses. In effect, the goods are sent out with legitimate-looking paperwork.
This is why ordinary web vulnerabilities carry considerable weight in a WMS. For an external attacker or an insider probing beyond their assigned role, broken access control could open a path into another warehouse zone, allow manipulation of other workers’ tasks, permit unauthorized exception operations, or expose administrative APIs. A server-side request forgery flaw could force the WMS server to reach resources an external attacker cannot touch directly, and if the network is flat or only formally segmented, that server may in turn reach internal management panels, cloud service interfaces, or systems sitting close to the operational network, turning a single web bug into a bridge between IT and OT.
Attacks on a WMS don’t always target the application directly, though. As we saw while tracing the unicorn, the warehouse is full of connected devices that already hold trusted access. A handheld terminal carries authenticated WMS API access as a matter of course, and anyone who gains control of that terminal inherits it (by escaping the kiosk, for example). Depending on the device’s permissions, that might mean confirming picks that never occurred, falsifying receiving operations, adjusting stock counts, or marking orders complete — something warehouse employees themselves could use to avoid their assigned duties.
Where the WMS is connected to control and automation systems, access to the WMS can extend into physical operations, including conveyors, sorting systems, lifts, doors, and pumps.
PLCs translate WMS instructions and sensor inputs into physical actions. Compromising a system that controls them therefore creates an opportunity to manipulate those actions. The impact can be as simple as a sorting diverter sending boxes down the wrong route, a conveyor repeatedly entering an error state and creating a backlog, or a falsified sensor value causing a line to be treated as clear when it is full.
However the WMS is compromised, the business consequence is the same: inventory corruption, unauthorized shipments, and operational disruption, each reaching the customer in the end as a late or missing delivery, the wrong item in the box, or a personal address exposed to a stranger.
Securing the unicorn
We followed our unicorn through web applications and databases, radio channels and PDTs, printers, conveyors, robots, and the loading zone. Because warehouse environments combine IT, OT, wireless, physical, and human components, security controls should be implemented as a single, coordinated security architecture rather than as isolated measures. Network segmentation should be a foundational control, with clear separation between corporate IT, warehouse OT, operational devices, management networks, and externally connected systems. Segmentation should also extend across facilities and customer environments so that each site and customer integration is isolated from the others, limiting the potential impact of a compromise. A zero-trust approach should reinforce this architecture by requiring explicit authentication and authorization for connections between systems, regardless of their network location, and by applying least-privilege access wherever possible. Regular penetration testing of the corporate IT environment, including domain services, identity infrastructure, and endpoints, should be incorporated into the warehouse security program.
Physical and network access controls should be implemented together. Access to warehouse facilities, network rooms, communication cabinets, and operational areas should be restricted according to business need, with appropriate authentication, monitoring, and access logging. Network infrastructure should be hardened through controls such as switch port security, MAC-based access restrictions where appropriate, and IEEE 802.1X with EAP-TLS for strong device and user authentication. Network equipment should also be securely configured and regularly reviewed to ensure that unused interfaces, insecure management protocols, default credentials, and unnecessary services are disabled.
Web applications and their supporting infrastructure should be governed through a secure software development lifecycle (SSDLC), including security requirements, secure coding practices, code and dependency review, and application security assessment before deployment and throughout the application’s lifecycle. Third-party applications and components should be continuously monitored and updated, with a defined vulnerability and patch management process. This should explicitly include warehouse management systems (WMS), warehouse portals, APIs, and other applications that provide operational or customer-facing functionality.
Wireless technologies should be subject to dedicated security assessment and engineering. Radio-frequency surveys should be conducted to establish expected coverage, identify unauthorized or unexpected signals, validate the availability and protection of operational communications, and determine whether wireless deployments create unintended access paths into warehouse networks. Wireless security should be assessed not only from a connectivity perspective but also in terms of authentication, encryption, device provisioning, protocol exposure, interference resilience, and the potential impact of unauthorized devices.
Warehouse operational devices should be incorporated into the organization’s endpoint security and vulnerability management processes. Devices should receive security updates and firmware patches on a defined schedule, with accelerated remediation for critical vulnerabilities. Security assessments should be performed periodically to identify weaknesses in device configuration, applications, exposed services, and authentication mechanisms.
Personnel security should form an additional layer of the warehouse security architecture. In most industrial and ICS environments, getting inside means clearing background checks, holding relevant qualifications, or proving prior experience; the hiring process itself acts as a filter. A warehouse is different. Roles in sorting, packing, and courier work are hired quickly and in volume, and they typically require no prior expertise, certification, or specialized background at all. An ordinary person can walk in off the street, be hired within days, and immediately hold legitimate physical access to the facility. Therefore, a more restrictive and risk-based approach to hiring should be considered, particularly for roles that provide access to sensitive areas, operational systems, network infrastructure, or customer assets.
Ultimately, all of these measures serve the same objective: protecting the continuity and reliability of the warehouse as a whole. This matters because real warehouses handle food, medicines, machine parts, and the millions of ordinary things people and companies depend on every day. Protecting their journey means seeing the warehouse as it has actually become: a single digital system with doors, motors, shelving, and radio signals, and with entirely real consequences when it fails. And if the security program works, the customer never knows any of this happened. The unicorn simply arrives at the scheduled time.
If your warehouse operations rely on interconnected systems like these, we can help identify the gaps before an adversary does. Reach out to discuss a security assessment.
Summary: One BIOS setting can stop a dock from updating, and two dock CVEs live in the update tools themselves. Here’s how docks end up unpatched, and what to check on DMA protection. The easiest way to leave a dock unpatched is to lock down the laptop it’s plugged into. Dell’s support article for the […]