Open research · passive observation · OT/ICS security
What do attackers look for online?
OT·Watch is a passive measurement system emulating industrial control systems, network cameras, VPN portals and DevOps services, to study how the internet scans for these targets. All statistics are aggregated and anonymous.
01What is this?
A honeypot is a system pretending to be something it is not.
Industrial control systems (SCADA/ICS), building automation (BMS), network cameras,
VPN portals and DevOps tools are emulated here. There is nothing real to compromise.
The sole purpose is to observe and measure.
The internet is constantly scanned by automated tools such as Masscan and Shodan.
That is expected background noise and is filtered out. What is interesting is traffic
that deviates: an actor searching for Swedish OT terms, following standard reconnaissance
patterns to hidden paths, or testing credentials tailored to the specific emulated system.
That behaviour requires domain knowledge or a specialised scanning tool — and that
distinction is exactly what the system is built to capture and document.
The system passively records request metadata and interaction patterns. No valid
credentials exist, and all attempts fail with realistic error messages.
Passive observation
The system scans nothing actively. It only responds to incoming requests and records them.
No real data
All services are emulated. No real passwords, no process values, no camera stream.
Aggregated statistics
Only aggregated figures are shown publicly. No IP addresses in plaintext are exposed.
OT/ICS focus
Special focus on industrial systems (SCADA, BMS, Modbus) rarely covered in standard honeypot research.
02Why?
OT systems are under-represented in open research
Most honeypot projects focus on SSH brute-force, WordPress scans or generic web
vulnerabilities. Industrial control systems — those operating power plants, water
treatment facilities and building automation — rarely appear in open research,
despite representing a growing attack surface.
Empirical measurement approach
Rather than relying on assumptions, this project answers the question empirically:
which services attract the most hits? Where does the traffic originate? Are generic
scan tools such as Masscan and python-requests being used, or more targeted ones?
Swedish versus English endpoints
A testable hypothesis: do se/scada/ and se/kraft/ attract
different scanner types than en/scada/? Do any actors specifically
target Nordic OT systems?
Focus on Swedish critical infrastructure
The project taxonomy reflects the system types and protocols found in Swedish
critical infrastructure, as defined by the Protective Security Act (2018:585) and
the Swedish Civil Contingencies Agency sector classification. The honeypot therefore
emulates services characteristic of energy supply, water supply, building and
facilities management, civil defence and transport, rather than generic IT infrastructure.
Exposure of operational and control systems to the internet constitutes an attack
surface that is rarely documented in open research — and that gap is what this
project aims to illuminate.
This is a personal research project with no affiliation to any organisation.
Data is used exclusively to understand the threat landscape facing OT/ICS-exposed systems.
03Scope
The statistics are primarily relevant for organisations in critical infrastructure:
energy, water, transport, telecommunications and healthcare, which expose OT or
network services to the internet.
The data covers which services are scanned, which credential patterns are tested
against OT interfaces and how scanning behaviour varies geographically and over time.
This project is not a threat intelligence feed; it is an open measurement instrument
with limited scope and a specific focus on the OT attack surface.
Energy & power grids
Power utilities, generation and grid operators. Data covers SCADA and BMS exposure to external scanners, including endpoint patterns and response behaviour.
Water & utilities
Water, wastewater and district heating. OT systems in the water sector are among the more frequently scanned categories in collected data.
SOC & security teams
Supplementary data on OT exposure. Covers endpoint patterns, user-agents and credential combinations from active scans targeting industrial services.
CERT & government agencies
Aggregated OT threat trends at national level. Raw data export and technical collaboration is possible via the contact form.
OT·Watch is a passive, independent measurement project with no affiliation to any government body or commercial entity. Data is open. Attribution is appreciated when publishing analyses based on this material.
03bObserved behaviour patterns
Based on collected HTTP traffic, scanning can be categorised into five distinct behaviour types. The distribution below covers HTTP traffic Q1 2026, excluding TCP port probes.
Behaviour type
Share
Description
Automated
48 %
Automated tools with no known scanner signature
Manual / browser-like
31 %
Browser behaviour without scanner UA (manual reconnaissance or advanced bots)
Vulnerability scanning
14 %
Active CVE-specific paths and exploit probes
Known scanner IP
4 %
Shodan, Censys, Rapid7, BinaryEdge m.fl.
Credential attack
3 %
Active login attempts against emulated OT services
The share of manual/browser-like traffic (31 %) is unusually high for a honeypot system. This indicates either that the lure design is realistic enough to engage manual actors, or that well-designed bots are actively emulating browser behaviour to avoid UA-based filtering.
The strongest observed behaviour is the combination of browser behaviour + fibre terminology + active bruteforce against the fibre category, with no known scanner signature. This is consistent with a manual actor with specific knowledge of telecommunications infrastructure.
04Technical architecture
The system is intentionally simple, focusing on reliable data collection without over-engineering.
index.php
Entry point, rate-limit, cookie
router.php
URL to endpoint key and category
classifier.php
32 attack tags, known scanner IP
logger.php
Writes raw + enriched, encrypts credentials
geoip.php
Country, ISP, ASN, hosting type
ui/*.php
Vendor-specific HTML response
Taxonomy
Each endpoint is assigned a category from a canonical list:
Each emulated service is designed to be technically credible, tailored for the actor or tool actively searching for that specific product type. The mechanisms that make the honeypot difficult to distinguish from a real system are described below.
Vendor-specific HTTP signatures
Each portal responds with HTTP headers exactly matching the real signatures of the emulated system. Tools such as whatweb and wappalyzer return the "correct" product response: a scanner identifying "Niagara 4.13" will continue with Niagara-specific payloads.
Product / Portal
Server-header
Session-cookie
Inductive Automation Ignition
Jetty(9.4.51.v20230217)
JSESSIONID
Emerson DeltaV DCS
Microsoft-IIS/10.0
ASP.NET_SessionId
Tridium Niagara
niagara/4.13.3.4
niagara_id
Johnson Controls Metasys
Apache-Coyote/1.1
JSESSIONID
Schneider EcoStruxure
Microsoft-IIS/8.5
ASP.NET_SessionId
Fortinet FortiGate SSL-VPN
xxxxxxxx-HTTPS
SVPNCOOKIE
Palo Alto GlobalProtect
PAN-OS
GPCS
Cisco ASA AnyConnect
Apache
webvpnlogin=1
Check Point Quantum VPN
Check Point SVN foundation
CPCVPN_SESSION
Citrix ADC / NetScaler Gateway
Apache
NSC_AAAC
F5 BIG-IP APM
BigIP
MRHSession + F5_fullWT
FiberOps transmissionsnät
nginx/1.20.2
—
IE compatibility tags (X-UA-Compatible: IE=EmulateIE11) are set for systems that genuinely require them. HTML comments and CSS classes in the source code reflect the real products' URL structures, a detail that reinforces credibility during source inspection.
Progressive login delays and engagement traps
Login buttons have JavaScript interceptors simulating LDAP authentication against a backend controller, with 2 to 7 seconds per attempt — exactly what one expects from a real network system.
Attempt
Server delay
Error message
1
0 s + 80–380 ms jitter
"Authentication failed. Please contact your system administrator."
2
2 s + jitter
"Repeated failures may result in account lockout."
Account lockout. "This incident has been reported."
With 5 % probability at attempt ≥ 4, a "read-only stub" is shown: the session appears established with a Viewer role. This extends actor engagement and reveals what they are trying to do with the "access". Status cards (Service Load, Active Alerts) are deterministically computed using crc32(endpoint + hour) as seed, keeping them consistent without a real backend process.
Passive discovery mechanisms
Some lures are designed to be discovered via common reconnaissance patterns. An actor who finds and visits these resources has either sector-specific domain knowledge or a specialised scanning tool — a strong indication of active infrastructure reconnaissance rather than passive background traffic.
Canary tokens in downloadable documents
Documents labelled "CONFIDENTIAL" can be downloaded as genuine .docx and .xlsx files. They are built in real time as valid Office Open XML documents with a unique tracking token embedded as a hyperlink. If an actor opens the file on a different machine, it beacons back. This reveals:
Download IP versus open IP (network switch / VPN rotation)
Time delay: quick opening suggests an opportunistic actor; delayed opening suggests a more sophisticated one
Whether the file is shared onward and opened from multiple machines in an attacker network
ops_session cookie and actor correlation
Every visitor is assigned an ops_session cookie: sha256(ip + date + random), stable per IP per day. It is used for actor correlation in logs:
An actor returning with the same cookie is identified as a returning actor
A cookie returned from a new IP prefix indicates likely VPN rotation
Supplementary fingerprint: actor_id = sha256(IP + UA + floor(time/86400)), day-stable and resilient against port changes and minor header variation
Tor exit nodes are detected via periodic fetching from dan.me.uk/torlist (6h cache). Residential + high_signal is a strong combination: private individuals rarely probe transmission network portals.
Operational documents, configuration files and authentication-related files with names drawn from OT and telecoms sector nomenclature.
06Frequently asked questions
Is my IP address logged?
Yes. IP addresses are logged internally to filter out noise (known research scanners such as
Shodan and Censys). The public statistics page never exposes IP addresses in clear text;
they are truncated to the first two octets (185.220.×××.×××).
Logs are deleted after 90 days.
Can the system be "hacked"?
There is nothing to compromise. All login forms return authentication errors,
no real credentials are accepted, and no sensitive data is stored behind them.
The system is designed to look realistic, not to actually be a functioning service.
Is this legal?
Yes. Honeypots are an established and legal security research tool. The system does not
deceive or steal data from visitors. It only records what they voluntarily send to
a public address. This is legally equivalent to ordinary web server access logs.
Security researchers: can I be whitelisted?
Whitelisting is possible. Submit your IP range via the contact form and it will be
excluded from the statistics. Known research actors (Shodan, Censys, GreyNoise good-tier)
are already filtered automatically.
How often is the statistics updated?
Public aggregates are recalculated once per day (02:00 UTC) by a cron job.
Real-time data for the most recent activity is fetched every 30 seconds via the live feed shown on the statistics page.
07Contribute ideas
Suggestions for new emulation targets, improved responses, or alternative classification
methods can be submitted via the contact form. Technical precision and source references
(Shodan banner, specification document, own device) increase the likelihood of implementation.
Ideas are reviewed manually. Not all suggestions are implemented.
Wish list
Modbus TCP-emulator
responds with valid Modbus frames
Rockwell FactoryTalk View
done: login UI with SCADA classification
Schneider Electric EcoStruxure
done: BMS/energy portal with Nordic emulation
Kubernetes dashboard
k8s dashboards are actively scanned per access logs
DNP3 deep emulation
protocol visible in collected data, deeper emulation planned
EtherNet/IP emulation
protocol visible in scan data and logical next industrial protocol
ASN/ISP lookup in the actor table
reveals botnets versus targeted actors via external enrichment
Alert webhook on unusual activity
notification on high activity spikes or first scan of a new service
External visibility validation
automated check that exposed services are classified correctly externally
Prometheus /metrics endpoint
done: deterministic pseudo-random output
Stateful login UI with POST handlers
done: all forms return realistic responses
Idea templates
TEMPLATE: New endpoint to emulatecopy
Service:[Product name, e.g. "Honeywell Experion PKS"]Category:[process_scada / vpn / camera / bms / devops / other]URL pattern:[e.g. /experion/login]Server header:[e.g. "Microsoft-IIS/8.5" (if known)]Typical scanner:[Masscan / Shodan / targeted / unknown]Rationale:[Why is this particular service interesting?]Reference:[Shodan query, CVE, article (if available)]
TEMPLATE: Improved response / headerscopy
Endpoint:[e.g. en/axis/login]Problem:[What is wrong or unrealistic in the current response?]Expected:[What should a real device respond? Headers, body, cookies?]Source:[Shodan banner / own device / specification document?]
TEMPLATE: Statistics / analysis ideacopy
Idea:[What do you want to see visualised or analysed?]Data source:[Existing columns, or requires new logging?]Value:[What does this add that is not already measured?]
08Contact
The form is sent to a server-configured address. No email address
is present in the page source. Provide your email if you want a reply; otherwise
the message is handled anonymously.
Message received
Handled manually. A reply will be sent if possible.