Next Article in Journal
A Motion Control Strategy for a Blind Hexapod Robot Based on Reinforcement Learning and Central Pattern Generator
Previous Article in Journal
CMB Parity Asymmetry from Unitary Quantum Gravitational Physics
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Security Symmetry in Embedded Systems: Using Microsoft Defender for IoT to Detect Firmware Downgrade Attacks

Faculty of Telecommunications, Technical University of Sofia, 1756 Sofia, Bulgaria
*
Authors to whom correspondence should be addressed.
Symmetry 2025, 17(7), 1061; https://doi.org/10.3390/sym17071061
Submission received: 5 May 2025 / Revised: 16 June 2025 / Accepted: 19 June 2025 / Published: 4 July 2025

Abstract

Nowadays, the world witnesses cyber attacks daily, and these threats are becoming exponentially sophisticated due to advances in Artificial Intelligence (AI). This progress allows adversaries to accelerate malware development and streamline the exploitation process. The motives vary, and so do the consequences. Unlike Information Technology (IT) breaches, Operational Technology (OT)—such as manufacturing plants, electric grids, or water and wastewater facilities—compromises can have life-threatening or environmentally hazardous consequences. For that reason, this article explores a potential cyber attack against an OT environment—firmware downgrade—and proposes a solution for detection and response by implementing Microsoft Defender for IoT (D4IoT), one of the leading products on the market for OT monitoring. To detect the malicious firmware downgrade activity, D4IoT was implemented in a pre-commissioning (non-production) environment. The solution passively monitored the network, identified the deviation, and generated alerts for response actions. Testing showed that D4IoT effectively detected the firmware downgrade attempts based on a protocol analysis and asset behavior profiling. These findings demonstrate that D4IoT provides valuable detection capabilities against an intentional firmware downgrade designed to exploit known vulnerabilities in the older, less secure version, thereby strengthening the cybersecurity posture of OT environments. The explored attack scenario leverages the symmetry between genuine and malicious firmware flows, where the downgrade mimics the upgrade process, aiming to create challenges in detection. The proposed solution discerns adversarial actions from legitimate firmware changes by breaking this functional symmetry through behavioral profiling.
Keywords:
AI; IT; OT; D4IoT

1. Introduction

Symmetry in system and process behavior is progressively exploited by threat actors to disguise malicious actions as legitimate operations. Annually, hundreds of researchers and security professionals present their findings at conferences such as Black Hat [1] and DEFCON [2]. During the latest conference (August 2024, Las Vegas, USA), SafeBreach security researcher Alon Leviev presented his “Windows Downdate: Downgrade Attacks Using Windows Updates” project [3]. He revealed a method of forcing an up-to-date Windows device to roll back to an older software version, reintroducing vulnerabilities that can be exploited to compromise the system. The novel approach misused a flaw in the Windows update process, leveraging its purpose and, therefore, making it the least-suspicious entity for such an attack [4]. The method targeted the action list (Pending.xml) within the Windows update flow. It is located in a server-controlled folder, contains the update actions the client needs to perform, and is executed during the Operating System (OS) reboot. By exploiting a registry key (PoqexecCmdline) not Trusted Installer enforced, Leviev was able to replace the action list with a custom downgrading one and bypass the integrity verifications. This attack technique goes completely undetectable, which was one of the predefined success criteria:
  • Fully undetectable—the Endpoint Detection and Response (EDR) failed to identify the malicious activity.
  • Invisible—the system continued to display as up-to-date despite the downgrade.
  • Persistent—future updates are compromised, preventing genuine patches from being applied (modification of poqexec.exe).
  • Irreversible—integrity and repair utilities did not detect any issues, making the remediation challenging (modification of SFC.exe).
Another real-life scenario involving OS/firmware alternation is the SYNful Knock, a Cisco router implant discovered in 2015 [5]. This sophisticated attack involved a stealthy firmware modification targeting several Cisco models, including 1841, 2811, and 3825. By modifying the firmware, threat actors were able to maintain persistent access to compromised networks and evade traditional detection mechanisms. The initial compromise is believed to have been facilitated by the use of default credentials or credentials discovered by the attackers, rather than exploiting a zero-day vulnerability [6].
While the two examined cases involved malicious OS/firmware modifications in enterprise-grade equipment, similar tactics, techniques, and procedures (TTPs) have also been observed in the OT industry, for instance, in microgrids [7] and other electric power systems [8].
These novel attack concepts often mimic benign update processes, creating a deceptive structural symmetry between legitimate and malicious actions. For that reason, the current publication proposes a detection mechanism for firmware downgrades in OT environments. It leverages the passive agentless network monitoring capabilities of Microsoft Defender for IoT [9], combined with the robust Security Information and Event Management (SIEM) features of Microsoft Sentinel [10]. The solution was designed by considering the main differences in the detection of OS/firmware downgrades in IT vs. OT networks. For instance, a frequent inability to install an agent on the requiring-protection OT device (e.g., Programmable Logic Controller (PLC), Remote Terminal Unit (RTU), etc.) or the requirement for totally passive monitoring in contrast to active scanning, which can affect the determinism of the environment. The proposed approach enhances the visibility of covert threats by examining deviations in these symmetrical patterns at the asset behavior and protocol levels.
As part of this research work, a comprehensive comparative analysis was conducted to examine alternatives to the proposed solution, focusing on D4IoT’s two primary competitors: “Guardian” of Nozomi Networks and “CTD” of Claroty. The investigation specifically targeted firmware alternation detection capabilities across these platforms. This analysis revealed that the standard detection features in all examined solutions lack the necessary sophistication to properly identify and distinguish between legitimate firmware updates and potentially malicious downgrades. Both competitor platforms exhibit similar limitations to those found in D4IoT. Nozomi’s Guardian generates generic “Firmware transfer (Type ID SIGN:FIRMWARE-TRANSFER)” and “Firmware change (Type ID SIGN:FIRMWARE:CHANGE)” alerts, while Claroty’s CTD produces “Firmware Download (Alert Type ID 1000; QID 1003000042)”. These alerts merely identify firmware modifications without providing critical context about version trajectories, such as whether the change represents progressive advancement or regressive downgrade. Our solution distinctively overcomes these industry-wide limitations by implementing version-aware comparison logic, representing a significant advancement in detection capabilities.
The detection mechanism was successfully implemented in a manufacturing organization but is equally applicable to any cloud-friendly environment within the OT domain. The initial results indicated that this approach could effectively identify firmware downgrade attempts, significantly strengthening the security posture of critical infrastructure environments. The presented results validate that this research successfully answered the primary question: How effectively can passive, agentless network monitoring identify and distinguish between legitimate and malicious firmware alterations? In addition, the article conclusively fulfilled all predefined research objectives, which are as follows:
  • Assess the potential risks and real-world impact of firmware downgrades;
  • Characterize the structural and behavioral symmetries exploited by firmware downgrade attacks;
  • Design a solution that mitigates these implications while considering the OT domain-specific characteristics and limitations;
  • Evaluate the solution’s efficiency in both a controlled test environment and a real production network.

2. Materials and Methods

2.1. Firmware Change Detected D4IoT Alert Overview

The “Firmware Change Detected” alert is one of twelve scenarios generated by the Policy Violation detection engine under the Firmware Change category in Microsoft Defender for IoT (D4IoT) [11]. This alert is classified with medium severity and aligns with the “T0857: System Firmware” technique, associated with the “Inhibit Response Function” and “Persistence” tactics as defined by the Industrial Control Systems (ICS) MITRE ATT&CK framework [12]. T0857, as described in the framework, outlines the possibility of threat actors exploiting the firmware update function to upload malicious or outdated firmware, potentially granting them root access to the device. The list of targeted assets includes Data Gateways, Human–Machine Interfaces (HMIs), Intelligent Electronic Devices (IEDs), and various types of controllers [13]. This technique has been observed in two pivotal ICS security incidents: the 2015 Ukraine Electric Power Attack [14] and the 2017 Saudi Arabia Triton Attack [15].
In late December 2015, threat actors used the Black Energy malware to target three Ukrainian power companies. By remotely manipulating and opening breakers, they induced widespread outages that affected approximately 225,000 customers. Almost two years later, in August 2017, the sophisticated Triton malware targeted the Safety Instrumented System (SIS) at a Saudi Arabian petrochemical facility. This unprecedented, at the time, cyber attack, specifically engineered to compromise an industrial safety controller, represents a significant acceleration in OT/ICS threats. Fortunately, although the threat actors succeeded in deploying malicious code, the incident was discovered and halted before any physical harm occurred.
The SYNful Knock and the two cases from 2015 and 2017 illustrate how potential firmware compromises create severe security implications beyond conventional cyber threats. These examples demonstrate the importance of contrasting legitimate firmware updates with malicious downgrades, which is crucial for effective security monitoring.
The four primary methods for detecting T0857 are as follows:
  • DS0015—Monitoring application logs for firmware changes (it should be noted that not all devices generate such logs);
  • DS0001—Tracking firmware modifications and comparing them to a database of known-good versions and expected patching behavior;
  • DS0029—Analyzing ICS/file transfer protocols for activities that might indicate firmware changes;
  • DS0040—Monitoring operational alarms that could alert firmware changes.
The proposed detection mechanism leverages DS0029 as its foundation.
D4IoT supports the detection of “Firmware Change Detected” alert across 40 ICS and standard well-known protocols, including the following:
  • OPAC (Open Protocol Atlas Copco)—a communication protocol designed for the remote control of Atlas Copco controllers. It supports both Ethernet (TCP port 4545) and serial (Serial ASCII or Serial ASCII with 3964R handshake) connections [16].
  • MODBUS—an application-layer communication protocol for establishing connections between devices from different vendors. It operates on a client–server model, utilizing various function codes for request/response messages. The protocol uses TCP port 502 [17].
  • Profinet—an industrial Ethernet-based communication protocol for real-time data transfers between controllers (PLCs) and field devices (sensors, actuators, and robots). The protocol operates on TCP port 102 (configuration) and UDP 34962-34964 (communication) [18].
  • Rockwell CSP2—a Layer 7 protocol designed by Rockwell Automation for communication between Allen–Bradley PLCs and Rockwell software applications. The default port is TCP 2222 [19].
  • MMS (Manufacturing Message Specification)—an Ethernet-based client-server communication protocol used for data exchange between IEDs (Intelligent Electronic Devices) and higher-level systems, such as Supervisory Control and Data Acquisition (SCADA). The protocol typically operates over TCP port 102 [20].
  • CDP (Cisco Discovery Protocol)—a proprietary Layer 2 protocol designed for directly connected network devices (such as routers, switches, and bridges). It enables network management applications to discover Cisco devices, providing at least their IP address and device type [21].
D4IoT generates a “Firmware Change Detected” alert when deviations from the established baseline are identified. Upon installation, a D4IoT network sensor begins monitoring the environment by analyzing mirrored traffic forwarded to its monitoring interface(s). The sensor detects devices and their properties (e.g., hostname, IP address, MAC address, and OS/firmware) and records them in the device inventory. Once the sensor has gathered complete information about the devices in the environment, it triggers a “Firmware Change Detected” alert if any device is found with a firmware version different from the one stored in the database. The alert includes a “Learn” capability, allowing the newly discovered firmware to be validated and the device entry to be updated accordingly. However, if the alert is just closed (i.e., the firmware is not learned), it will reappear the next time the device is detected.
The “Firmware Change Detected” alert is presented in Figure 1. It contains information about the device with changed firmware, the previous and current versions, and the detection time.
In addition to tracking “Firmware Change Detected” alerts, users can explore the detected firmware version of a monitored device by checking the “Backplane” device inventory page or creating a data mining report with the category “Modules and Firmware Versions”. The report can be granular (specific device/time period) or generic (reveals all results for the selected category). The two options are presented in Figure 2 and Figure 3.

2.2. D4IoT Setup Prerequisites

The proposed detection mechanism for firmware downgrades requires cloud-connected D4IoT sensor(s) and Microsoft Sentinel integration. For air-gapped environments, the solution can be implemented using an on-premises SIEM product, such as Splunk Enterprise [22].
During the onboarding process, the “Cloud Connected” option must be selected, and the sensor requires access to specific Azure secure endpoints on port 443 [23]. The configuration is presented in Figure 4. The other two options (Automatic Threat Intelligence updates/Automatic Sensor updates) do not impact the implementation.
Once the sensor(s) begins streaming data to the Azure portal, D4IoT alerts can be ingested into Microsoft Sentinel. This is achieved by enabling the “Microsoft Defender for IoT” data connector [24]. The connector configuration page is presented in Figure 5.
To confirm that the integration between Azure D4IoT and Microsoft Sentinel was successful, we can run a Kusto Query Language (KQL) that searches D4IoT alerts in the “Security Alert” table. The query is presented in Figure 6.

2.3. Implementation of a Detection Mechanism for Firmware Downgrade

The implementation of a detection mechanism for firmware downgrades involves the creation of a custom Sentinel Analytics rule and requires the introduction of several variables. These variables are utilized within the KQL query to parse the raw data and compare previous and current firmware versions.
The process begins by retrieving firmware versions from the “Updated To” and “Updated From” properties within “ExtendedProperties”, as illustrated in Figure 7.
The next step applies a regular expression (Regex) to extract the numerical digits of the firmware version. The original format begins with “Software Revision:”, followed by three or four digits, and ends with a semicolon—“Software Revision: x.x.x.x;”. This is presented in Figure 8.
The subsequent phase involves splitting the three or four digits into separate variables to facilitate comparison. This process is illustrated in Figure 9.
The final operation involves comparing the previous and current firmware versions digit by digit and displaying the result, which can be one of the following: “NewVersion is newer”, “OldVersion is newer”, or “Versions are equal”. The comparison utilizes “case()” KQL function [25] and is presented in Figure 10.
The implemented detection mechanism for the firmware downgrade described above was developed and validated as part of this study. In alignment with the best practices for research transparency and reproducibility, relevant detection logic and queries can be made available under the conditions below.
The KQL queries and Regex parsing logic developed for this article can be made available upon request. Due to internal security policies, raw device data and network captures are not publicly shared.
No generative AI tools were used in the design, implementation, data collection, analysis, or interpretation phases of this work.

2.4. Selected Methods’ Rationale

The proposed solution relies on KQL queries and Regex for parsing raw data and comparison logic to optimize both performance and operational efficiency. The detection mechanism leverages Sentinel’s real-time evaluation of D4IoT alert ingestion, enabling the discovery of a potentially malicious firmware downgrade and incident creation in approximately one minute. Alternative implementation strategies, such as utilizing Azure Functions or Python scripts, introduce latency and unnecessary operational complexity through additional code maintenance and/or scaling considerations. Sentinel’s native capabilities, including parse_json(), extract(), and split(), enable the processing of ExtendedProperties within a single atomic query execution, eliminating external dependencies and maintaining rapid response capabilities.
The selected Regex is based on a thorough analysis of D4IoT’s firmware version annotation conventions—typically present as human-readable strings, such as “Software Revision: 2.6.6.6”. Our solution demonstrates exceptional versatility by reliably capturing three or four digit versions, regardless of potential formatting inconsistencies.
Finally, implementing all logic within a Sentinel Analytics rule significantly enhances operational sustainability. The method eliminates the need to synchronize external libraries or manage version compatibility. Additionally, the solution provides complete transparency to SOC teams, as Microsoft Sentinel is currently one of the SIEM solutions with the largest market share.

3. Results

3.1. Setting Up the Test Bed

The test environment set to evaluate and assess the performance of the designed detection mechanism consisted of the following components:
  • Atlas Copco Power Focus 6000—a single, centralized tightening controller, typically connected to one or more screwing machines, and presented in Figure 11;
  • Moxa AWK-3131A—industrial wireless AP/bridge/client that supports IEEE 802.11 a/b/g/n and is utilized to connect the “Atlas Copco Power Focus 6000” and “Beckhoff CP2916-0000” to the wireless network, presented in Figure 12;
  • Beckhoff CP2916-0000—industrial panel PC (processor + HMI) that runs Windows 10 IoT. Utilized for direct monitoring and process control, presented in Figure 13.
Scheme 1 presents the network topology of the Test Bed implemented to evaluate the proposed detection mechanism. The configuration accurately simulated a real production environment with all necessary components for comprehensive testing. Notably, the “Wireless Access Point” and “Screwing Machine(s)” components are included to represent a complete screwing production line typical for a manufacturing facility and provide contextual accuracy to the simulation environment.
Table 1 presents the IP configuration settings for the Atlas Copco Power Focus 6000, Moxa AWK-3131A, and Beckhoff CP2916-0000 devices utilized in the test environment. It is important to highlight that in actual production manufacturing environments, firmware alterations and/or configuration changes to Atlas Copco screw joint machines are typically deployed from a centralized location (e.g., an application server) rather than from the local control device (i.e., Beckhoff CP2916-0000). This approach enables enterprise-scale management and centralized control across hundreds or even thousands of screwing controllers deployed throughout manufacturing operations.
Table 2 presents the comprehensive testing scenarios formulated to evaluate both the functional capabilities and operational effectiveness of the developed detection mechanism. Each scenario is systematically documented with three key components: a procedural description, the anticipated outcome based on the design specifications, and the actual observed results from execution. Exhaustive details of all performed simulations are presented in Section 3.2, which provides substantial evidence demonstrating the successful implementation and operational effectiveness of the proposed solution, which is illustrated in Figure 14, Figure 15, Figure 16 and Figure 17.

3.2. Testing the Implemented Solution

The proposed solution for the detection of firmware downgrades was tested by intentionally downgrading an Atlas Copco screw joint machine (model: Power Focus 6000) in a controlled environment (testing segment of a manufacturing facility). Subsequently, the controller was restored to its original firmware version (upgraded), triggering a second “Firmware Change Detected” alert in D4IoT. However, this alert did not generate an additional Sentinel incident. Figure 14 presents the alert generated by the firmware downgrade, which involved changing the Atlas Copco device’s firmware from version 2.6.6.6 to 2.5.7.2.
Figure 14. “Firmware Change Detected” alert generated by the downgrade.
Figure 14. “Firmware Change Detected” alert generated by the downgrade.
Symmetry 17 01061 g014
Approximately one minute after D4IoT detected the activity and generated an alert, the Sentinel rule “D4IoT—Firmware Downgrade Detected” triggered an incident. This incident indicated that a monitored device was reverting from a newer firmware version to an older one based on the variable “CompareResult”. The incident is presented in Figure 15.
Figure 15. “D4IoT—Firmware Downgrade Detected” incident in Sentinel.
Figure 15. “D4IoT—Firmware Downgrade Detected” incident in Sentinel.
Symmetry 17 01061 g015
The second phase of the test involved learning the alert, which updated the device record. Subsequently, we restored the Atlas Copco controller to its original firmware version (2.6.6.6). This action was detected by D4IoT, which then triggered a second “Firmware Change Detected” alert, indicating the transition from version 2.5.7.2 to 2.6.6.6. The alert is presented in Figure 16.
Figure 16. “Firmware Change Detected” alert generated by the upgrade.
Figure 16. “Firmware Change Detected” alert generated by the upgrade.
Symmetry 17 01061 g016
Unlike the initial detection, the second alert did not trigger a new Sentinel incident, as the new firmware version was newer than the previously installed one. A look-up for incidents generated by the Sentinel rule confirmed that only the initial detection, related to the controller’s firmware downgrade, was recorded. Figure 17 illustrates the results.
Figure 17. Available “D4IoT—Firmware Downgrade Detected” incidents.
Figure 17. Available “D4IoT—Firmware Downgrade Detected” incidents.
Symmetry 17 01061 g017

3.3. Implementation of Automation for Weekly Reports of Firmware Change Detected D4IoT Alerts

Once the proposed detection mechanism for firmware downgrades is successfully implemented, we recommend that the remaining “Firmware Change Detected” D4IoT alerts (i.e., firmware upgrades) not be completely ignored. Instead of generating Sentinel incidents and acting immediately upon detection, these alerts can be reviewed on a weekly basis through reports.
This approach can help to identify another suspicious scenario: a significant surge (e.g., 5 or 10 times) in the number of upgraded devices within a week. For instance, a bad actor might attempt to migrate as many devices as possible to a specific vulnerable firmware version, followed by a subsequent phase of vulnerability exploitation.
Another potential use case for the report on upgraded devices is regulatory and compliance requirements. Depending on the industry, some organizations may be required to maintain an up-to-date inventory of all assets, their properties, and a change log of modifications.
To facilitate this, this article proposes implementing Azure Logic Apps [26], which automates the collection of “Firmware Change Detected” D4IoT alerts and generates a CSV file. This file is then automatically sent via email to the on-site operations team responsible for device maintenance.
A best practice is to “Learn” all alerts after completing the report review. Otherwise, the same detections will appear in next week’s report, as D4IoT retains the previous firmware records.
Logic Apps incorporate several operations designed to be executed in a cyclic manner. The structure is as follows, and it is presented in Figure 18.
  • Recurrence—defines the execution interval (e.g., once a week) and the starting point (e.g., specific date). This operation triggers the Logic Apps and initiates the following steps.
  • Run query and list results—executes a KQL query that searches the “Firmware Change Detected” D4IoT alerts for the pre-defined period (e.g., last 7 days). The query is presented in Figure 19.
  • Condition—validates whether the KQL query has produced any results (i.e., found “Firmware Change Detected” D4IoT alerts in the specified period).
  • Create CSV table—collects the query results and stores them in a CSV file.
  • Send an email (V2)—sends the created CSV file containing the “Firmware Change Detected” D4IoT alerts to a pre-defined list of recipients.
Figure 18. Logic Apps for the “Firmware Change Detected” weekly report.
Figure 18. Logic Apps for the “Firmware Change Detected” weekly report.
Symmetry 17 01061 g018
Figure 19. KQL query for “Firmware Change Detected” D4IoT alerts.
Figure 19. KQL query for “Firmware Change Detected” D4IoT alerts.
Symmetry 17 01061 g019
The successful implementation of the Logic Apps for “Firmware Change Detected” weekly reports ensures the delivery of an email with an attached CSV file containing all detections for the pre-defined time period. Figure 20 illustrates the results.
Figure 20. Email containing the “Firmware Change Detected” weekly report.
Figure 20. Email containing the “Firmware Change Detected” weekly report.
Symmetry 17 01061 g020

4. Discussion

4.1. Discussion of Results

Adversaries often exploit the symmetry between business-justified OS/firmware updates and downgrades to evade detection by imitating benign behavior. This article explores potential cyber threats to OT/ICS environments, with a particular focus on intentional firmware downgrades designed to exploit known vulnerabilities in older, less secure versions. This attack method, classified as tactic T0857 in the MITRE ATT&CK framework, has been observed in real-world adversary operations, including the 2015 Ukraine Electric Power Attack and the 2017 Saudi Arabia Triton Attack, as well as in security research efforts, such as the case of Alon Leviev. While prior research and incident analyses have emphasized the impacts and potential consequences (i.e., unavailability of essential services, environmental harm, injuries to people, or even loss of life) of firmware manipulation in OT/ICS environments, few practical detection mechanisms have been demonstrated in production-like environments. Neither are offered as standard features in existing commercial solutions.
This study builds on those insights by emphasizing the importance of proactive security monitoring in OT/ICS environments and proposing a tailored and innovative detection mechanism for firmware downgrades. The designed solution was successfully implemented in a cloud-friendly manufacturing organization and is based on standard product capabilities, which were enhanced to meet the specific objectives of this research. The presented novel custom solution leverages the passive, agentless monitoring capabilities of Microsoft Defender for IoT, which, when combined with the advanced analytic strengths of Microsoft Sentinel, creates a robust detection mechanism. This cutting-edge solution, engineered by the authors, represents a substantial advancement in firmware downgrade attack detection and supports bolstering the overall cybersecurity posture of OT/ICS environments.
The developed detection mechanism was tested by intentionally downgrading an Atlas Copco screw joint machine (model: Power Focus 6000) in a pre-commissioning (non-production) environment and subsequently restoring it to its original firmware version. The results confirmed that the implementation functions as intended, generated a single Sentinel incident exclusively for the downgrade event. This selective behavior minimizes alert fatigue and ensures that only activities suggesting potential exploitation of reintroduced known vulnerabilities are escalated in alignment with best practices for threat prioritization.
In addition to detecting downgrades, the article introduces an automated reporting mechanism for handling remaining “Firmware Change Detected” alerts—typically generated by legitimate firmware upgrades. These reports can be used to detect suspicious firmware migration patterns (e.g., coordinated upgrade to a vulnerable version) or to fulfill regulatory and compliance requirements. This secondary implementation was also successfully validated and shown to support operational and governance objectives without overwhelming the Security Operations Center (SOC) incident response teams.
The presence of symmetry in firmware updates and downgrades denotes an architectural balance that can be strategically preserved or disrupted depending on the intentions. In state-of-the-art cybersecurity frameworks, especially within the OT/ICS or IoT domain, this balance becomes a double-edged sword—providing functional consistency while also introducing potentially exploitable paths for threat actors. Identifying and leveraging this symmetry enriches firmware lifecycle management and strengthens wide-ranging information security by recognizing atypical processes and deviations from the expected behavior.

4.2. Evaluation and Discussion of Impacts

The developed detection mechanism demonstrated a tangible operational impact by generating a single, high-fidelity Sentinel incident only for firmware downgrades while suppressing alerts for potentially benign upgrades. The implementation within the manufacturing organization yielded a substantial reduction in SOC workload. It enabled the analysts to focus solely on possibly malicious downgrades rather than investigating all firmware alternation activities. After three months of deployment, the solution achieved an estimated 93% reduction in weekly “Firmware Change Detected” alerts. Additionally, it substantially accelerated the incident response capabilities and improved Mean Time to Detect (MTTD) through the effective mitigation of false positives.
From a risk mitigation standpoint, the solution effectively identifies downgrade attempts as distinct security incidents, preventing threat actors from covertly reintroducing legacy vulnerabilities. By dissecting the symmetry between a legitimate upgrade and malicious downgrade patterns, the solution intercepts adversarial actions that would otherwise remain camouflaged within the regular traffic. Although our controlled tests—intentional downgrade of an Atlas Copco screw joint machine—did not involve a follow-up firmware-based exploit, the substantial reduction in firmware-based security blind spots directly correlates with a decreased probability of successful post-downgrade compromise. In operational OT/ICS environments, organizations can expect a significant decrease in exposure windows caused by stealthy rollbacks, potentially reducing MTTD from days or even weeks to minutes.
Finally, the regulatory and compliance benefits are also substantial. The automated weekly report ensures that maintenance teams possess up-to-date asset change log and meet regulatory audit requirements without manual review processes. These reports enhance both governance and operational transparency. Furthermore, organizations achieve measurable cost savings through two primary mechanisms: (A) early detection of rollback-induced vulnerabilities, which significantly reduces unplanned downtime, and (B) optimized SOC resource allocation minimizes remediation overhead and the potential impacts of firmware-driven operational disruptions.

4.3. Limitations and Future Implications

Despite the promising results, our research had several constraints that limited its immediate general rollout implementation. The tests were confined to a single device model, Atlas Copco Power Focus 6000. Therefore, considering that firmware alternation behaviors vary significantly across diverse PLCs, controllers, and vendor-specific implementations, the detection accuracy of the solution can be detrimentally impacted. In addition, the developed detection mechanism currently supports only OPAC, leaving the other OT/ICS—covered by “Firmware Change Detected”—protocols unexamined.
Advancing the solution further, future developments plan to address these challenges on multiple fronts. To broaden applicability, we will explore additional PLC/controller vendors (e.g., Siemens, Schneider, and Rockwell) and familiarize ourselves with the internal processes involved during firmware alternations. Furthermore, to extend the coverage of the developed detection mechanism, we will need to research the corresponding OT/ICS protocols (e.g., Siemens S7 protocol within Siemens PLC) and obtain an in-depth understanding of them. The next step would involve creating additional custom parsers and Regex to extract the necessary—for the solution—information from the underlying “Firmware Change Detected” alerts.
This would enable us to expand beyond the initial manufacturing use case and extend the detection mechanism to other OT/ICS sectors where firmware integrity is critical, such as the energy, water, and food and beverage industries. Its passive architecture makes it particularly suitable for environments where active scanning is undesirable, and its agentless design broadens compatibility across diverse device types and vendors.
Lastly, we plan to develop a second automation: immediate automatic email notifications to OT personnel, enabling the instant validation of whether a detected firmware change is expected and business-justified. The primary objective is to eliminate or significantly reduce delays inherent in manual SOC investigation processes.
All these enhancements will evolve our detection mechanism into a resilient, universally applicable solution for safeguarding firmware integrity across the full spectrum of OT/ICS industries.

Author Contributions

Conceptualization, M.H.; methodology, M.H. and M.N.; software, M.H.; validation, M.N. and V.D.; formal analysis, M.H.; investigation, M.H., M.N. and V.D.; resources, M.H.; data curation, M.H.; writing—original draft preparation, M.H.; writing—review and editing, M.N. and V.D.; visualization, V.D.; supervision, M.N.; project administration, M.N.; funding acquisition, M.N. All authors have read and agreed to the published version of the manuscript.

Funding

This study is financed by the European Union-NextGenerationEU, through the National Recovery and Resilience Plan of the Republic of Bulgaria, project № BG-RRP-2.004-0005.

Data Availability Statement

The data presented in this study are available upon request from the corresponding authors due to internal security policies.

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:
AIArtificial Intelligence
CSVComma-Separated Values
D4IoTMicrosoft Defender for IoT
EDREndpoint Detection and Response
HMIHuman–Machine Interface
ICSIndustrial Control Systems
IEDIntelligent Electronic Device
IoTInternet of Things
ITInformation Technology
KQLKusto Query Language
MACMedia Access Control
MMSManufacturing Message Specification
MTTDMean Time to Detect
OPACOpen Protocol Atlas Copco
OSOperating System
OTOperational Technology
PLCProgrammable Logic Controller
RTURemote Terminal Unit
SCADASupervisory Control and Data Acquisition
SIEMSecurity Information and Event Management
SISSafety Instrumented System
SOCSecurity Operations Center
TCPTransmission Control Protocol
TTPsTactics, Techniques, and Procedures
UDPUser Datagram Protocol

References

  1. Blackhat Official Conference Page © 2025 Informa PLC, August 2024. Available online: https://www.blackhat.com (accessed on 2 June 2025).
  2. DEF CON Official Conference Page © 2025 DEF CON Communications, Inc., August 2024. Available online: https://defcon.org (accessed on 2 June 2025).
  3. Leviev, A. Official Research Projects Page. Available online: https://www.alonleviev.com/research-projects (accessed on 2 June 2025).
  4. SafeBreach © Copyrights SafeBreach Inc. 2025. Windows Downdate: Downgrade Attacks Using Windows Updates, August 2024. Available online: https://www.safebreach.com/blog/downgrade-attacks-using-windows-updates (accessed on 2 June 2025).
  5. Hau, B.; Lee, T.; Homan, J. SYNful Knock—A Cisco Router Implant—Part I, Mandiant Blog, 15 September 2015. Available online: https://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis (accessed on 2 June 2025).
  6. Holmes, G. Evolution of Attacks on Cisco IOS Devices. Cisco Blog, 8 October 2015. Available online: https://blogs.cisco.com/security/evolution-of-attacks-on-cisco-ios-devices (accessed on 2 June 2025).
  7. Srivastava, A.; Thakur, S.; Kuruvila, A.P.; Balsara, P.T.; Basu, K. Hardware-Based Detection of Malicious Firmware Modification in Microgrids. In Proceedings of the 2024 37th International Conference on VLSI Design and 2024 23rd International Conference on Embedded Systems (VLSID), Kolkata, India, 6–10 January 2024; pp. 186–191. [Google Scholar] [CrossRef]
  8. Konstantinou, C.; Maniatakos, M. Impact of Firmware Modification Attacks on Power Systems Field Devices. In Proceedings of the 2015 IEEE International Conference on Smart Grid Communications (SmartGridComm), Miami, FL, USA, 2–5 November 2015; pp. 283–288. [Google Scholar] [CrossRef]
  9. Jain, S.; Lakshmi, V.; Srivathsa, R. IoT and OT Security Handbook: Assess Risks, Manage Vulnerabilities, and Monitor Threats with Microsoft Defender for IoT; Packt Publishing: Birmingham, UK, 2023. [Google Scholar]
  10. Diver, R.; Bushey, G.; Perkins, J. Microsoft Sentinel in Action: Architect, Design, Implement, and Operate Microsoft Sentinel as the Core of Your Security Solutions; Packt Publishing: Birmingham, UK, 2022. [Google Scholar]
  11. Microsoft. Microsoft Defender for IoT Alert Reference, 28 March 2024. Available online: https://learn.microsoft.com/en-us/azure/defender-for-iot/organizations/alert-engine-messages (accessed on 2 June 2025).
  12. Ekisa, C.; Ó Briain, D.; Kavanagh, Y. Leveraging the MITRE ATT&CK Framework for Threat Identification and Evaluation in Industrial Control System Simulations. In Proceedings of the 2024 35th Irish Signals and Systems Conference (ISSC), Belfast, UK, 13–14 June 2024; pp. 1–6. [Google Scholar] [CrossRef]
  13. MITRE ATT&CK. T0857: System Firmware. Available online: https://attack.mitre.org/techniques/T0857 (accessed on 2 June 2025).
  14. Liang, G.; Weller, S.R.; Zhao, J.; Luo, F.; Dong, Z.Y. The 2015 Ukraine Blackout: Implications for False Data Injection Attacks. IEEE Trans. Power Syst. 2017, 32, 3317–3318. [Google Scholar] [CrossRef]
  15. Al-Rabiaah, S. The “Stuxnet” Virus of 2010 as an Example of an “APT” and Its “Recent” Variants. In Proceedings of the 2018 21st Saudi Computer Society National Computer Conference (NCC), Riyadh, Saudi Arabia, 25–26 April 2018; pp. 1–5. [Google Scholar] [CrossRef]
  16. Atlas Copco. Open Protocol Specification Release 2.8.0. Available online: https://s3.amazonaws.com/co.tulip.cdn/OpenProtocolSpecification_R280.pdf (accessed on 2 June 2025).
  17. Modbus Organization. Modbus Protocol Overview. Available online: https://www.modbus.org (accessed on 2 June 2025).
  18. PROFINET. PROFINET Protocol Overview. Available online: https://www.profinet.com (accessed on 2 June 2025).
  19. Rockwell Automation. TCP and UDP Port Configuration—Quick Reference Guide, COMM-QR001A-EN-E; Rockwell Automation: Milwaukee, WI, USA, 2014. [Google Scholar]
  20. Typhoon HIL. IEC 61850 MMS Protocol Documentation. Available online: https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/iec_61850_mms_protocol.html (accessed on 2 June 2025).
  21. Cisco. Understanding and Configuring CDP. Software Configuration Guide—Release 12.2(25)EW. Available online: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/cdp.pdf (accessed on 2 June 2025).
  22. Splunk. Enterprise Security Product Overview. Available online: https://www.splunk.com/en_us/products/enterprise-security.html (accessed on 2 June 2025).
  23. Microsoft. Provision Sensors for Cloud Management, 30 March 2023. Available online: https://learn.microsoft.com/en-us/azure/defender-for-iot/organizations/ot-deploy/provision-cloud-management (accessed on 2 June 2025).
  24. Microsoft. Tutorial: Connect Microsoft Defender for IoT with Microsoft Sentinel, 8 March 2023. Available online: https://learn.microsoft.com/en-us/azure/defender-for-iot/organizations/iot-solution (accessed on 2 June 2025).
  25. Microsoft. Scalar Function Case(), 12 August 2024. Available online: https://learn.microsoft.com/en-us/kusto/query/case-function?view=microsoft-fabric (accessed on 2 June 2025).
  26. Microsoft. What Is Azure Logic Apps? 29 January 2025. Available online: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-overview (accessed on 2 June 2025).
Figure 1. “Firmware Change Detected” alert.
Figure 1. “Firmware Change Detected” alert.
Symmetry 17 01061 g001
Figure 2. Backplane information of a Siemens PLC.
Figure 2. Backplane information of a Siemens PLC.
Symmetry 17 01061 g002
Figure 3. “Modules and Firmware Versions” data mining report.
Figure 3. “Modules and Firmware Versions” data mining report.
Symmetry 17 01061 g003
Figure 4. Onboarding process of a D4IoT network sensor.
Figure 4. Onboarding process of a D4IoT network sensor.
Symmetry 17 01061 g004
Figure 5. Microsoft Defender for IoT Data connector.
Figure 5. Microsoft Defender for IoT Data connector.
Symmetry 17 01061 g005
Figure 6. KQL query for D4IoT alerts in the last 10 min.
Figure 6. KQL query for D4IoT alerts in the last 10 min.
Symmetry 17 01061 g006
Figure 7. Extraction of “Updated To” and “Updated From” values.
Figure 7. Extraction of “Updated To” and “Updated From” values.
Symmetry 17 01061 g007
Figure 8. Regex that extracts the firmware version digits.
Figure 8. Regex that extracts the firmware version digits.
Symmetry 17 01061 g008
Figure 9. Splitting the firmware version.
Figure 9. Splitting the firmware version.
Symmetry 17 01061 g009
Figure 10. Firmware version comparison.
Figure 10. Firmware version comparison.
Symmetry 17 01061 g010
Figure 11. Atlas Copco Power Focus 6000.
Figure 11. Atlas Copco Power Focus 6000.
Symmetry 17 01061 g011
Figure 12. Moxa AWK-3131A.
Figure 12. Moxa AWK-3131A.
Symmetry 17 01061 g012
Figure 13. Beckhoff CP2916-0000.
Figure 13. Beckhoff CP2916-0000.
Symmetry 17 01061 g013
Scheme 1. Network topology of the Test Bed.
Scheme 1. Network topology of the Test Bed.
Symmetry 17 01061 sch001
Table 1. IP configuration settings.
Table 1. IP configuration settings.
DeviceIP AddressSubnet Mask
Moxa AWK-3131A10.10.10.10255.255.255.240
Beckhoff CP2916-000010.10.10.1255.255.255.240
Atlas Copco Power Focus 600010.10.10.2255.255.255.240
Table 2. Testing scenarios.
Table 2. Testing scenarios.
#OperationDescriptionExpected ResultsActual Results
1Asset DiscoveryD4IoT detects the Atlas Copco deviceD4IoT identifies the device’s firmware version Firmware Version Identified: 2.6.6.6
2Firmware DowngradeThe Atlas Copco device is downgraded“Firmware Change Detected” alertAlert Generated Indicating Firmware Version: 2.5.7.2
3Incident GenerationTrigger a Sentinel incident for a firmware downgrade“D4IoT—Firmware Downgrade Detected” incidentIncident Generated
4Firmware UpgradeThe Atlas Copco device is upgradedSecond “Firmware Change Detected” alertAlert Generated Indicating Firmware Version: 2.6.6.6
5Incident SuppressionThe designed detection mechanism supresses the activityThe second “Firmware Change Detected” alert does not trigger an incidentNo Incident Generated
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Hristov, M.; Nenova, M.; Dimitrova, V. Security Symmetry in Embedded Systems: Using Microsoft Defender for IoT to Detect Firmware Downgrade Attacks. Symmetry 2025, 17, 1061. https://doi.org/10.3390/sym17071061

AMA Style

Hristov M, Nenova M, Dimitrova V. Security Symmetry in Embedded Systems: Using Microsoft Defender for IoT to Detect Firmware Downgrade Attacks. Symmetry. 2025; 17(7):1061. https://doi.org/10.3390/sym17071061

Chicago/Turabian Style

Hristov, Marian, Maria Nenova, and Viktoria Dimitrova. 2025. "Security Symmetry in Embedded Systems: Using Microsoft Defender for IoT to Detect Firmware Downgrade Attacks" Symmetry 17, no. 7: 1061. https://doi.org/10.3390/sym17071061

APA Style

Hristov, M., Nenova, M., & Dimitrova, V. (2025). Security Symmetry in Embedded Systems: Using Microsoft Defender for IoT to Detect Firmware Downgrade Attacks. Symmetry, 17(7), 1061. https://doi.org/10.3390/sym17071061

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop