{
	"id": "5d76c113-e4dc-4aa7-997c-ebfd4140061e",
	"created_at": "2026-04-06T00:19:11.23717Z",
	"updated_at": "2026-04-10T03:20:43.057443Z",
	"deleted_at": null,
	"sha1_hash": "8c2ba457a5350eab2e0ae15ad90dc858d8988253",
	"title": "How ntopng monitors IEC 60870-5-104 traffic – ntop",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 492301,
	"plain_text": "How ntopng monitors IEC 60870-5-104 traffic – ntop\r\nArchived: 2026-04-05 18:33:19 UTC\r\nBusy times for OT analysts.\r\nLast month the number of known OT (operational technology) malware increased from five to seven. First\r\nmalware discovered is Industroyer2 which was caught in the Ukraine. As nowadays popular, security companies\r\nname the malware they discover. That is why for the second malware two names were assigned, Incontroller or\r\nPipedream. This malware was discovered before it was deployed.\r\nIndustroyer2 [1] is an evolution of Industroyer1, first seen in 2014. Both variants are targeting the electrical\r\nenergy sector, specifically in Ukraine. As the malware is using commands out of the industrial protocol IEC-60870-5-104, traffic looks like legit communication as during normal operation.\r\nIncontroller [2] is a new set of malware components, targeting the LNG sector in the US. Similar to Industroyer2,\r\npipedream is using popular industrial protocols like OPC-UA and ModbusTCP. Further more it uses build in\r\nfunctionality from engineering tools made to interact with OT devices like PLCs (process logic controller).\r\nBoth malware show clearly that the criminals behind have evolved and do understand OT protocols and are able to\r\nuse build in functionality of legit software engineering tools like CODESYS.\r\nWhat has not changed over the last years, is that SCADA systems still control like “fire and forget”. A command is\r\nsent from the control system server to the client in the field. The client translates the event into a physical action,\r\nlike open or close a circuit breaker. The command source is not verified by the client. Translated back to the\r\nnetwork traffic, it means that one packet containing a command is enough to disrupt the complete industrial\r\nprocess or power distribution.\r\nIndustroyer2 uses IEC-104, the short version for IEC 60870-5-104. IEC-104 is widely used in European energy\r\nsector and as well in utilities sector like water or waste water treatment.\r\nA characteristic of many industrial protocol is, that even though the protocol is standardised, its implementation\r\ncan vary between manufacturers or even system integrators. Meaning IEC-104 implemented by Hitachy Energy\r\ndiffers from how it is implemented by Siemens. Operators are familiar with it, but for network security monitoring\r\nit can be a challenge.\r\nFurther difficulty for monitoring is, that one packet transporting the IEC-104 payload can have multiple IEC-104\r\ndata messages, called APDU’s. Therefore traditional signature based detection on the TCP payload does not work.\r\nThe payload needs to be parsed in order to understand what type of command each APDU contains:\r\nhttps://www.ntop.org/cybersecurity/how-ntopng-monitors-iec-60870-5-104-traffic/\r\nPage 1 of 5\n\nSince the discovery of Industroyer2 in early of April 2022 until now, several reports analysing the malware were\r\npublished. They contain information how the malware is working, captured network data and most of them\r\ncontain recommendation how to deal with such type of malware. Having a closer look at the recommendations, or\r\nnowadays called actionable items, they are high level items. Example:\r\n“Use anomaly detection tools to detect any irregular activity occurring in OT environments“\r\n“Employing network segmentation to separate sensitive applications (e.g. PCN) from other network parts\r\nvia firewalls“\r\n“Monitor East-West ICS networks with ICS protocol aware technologies“\r\nNot much actionable in my point of view or a whole set of commercial products need to be in place. Products\r\nwhich for most SMEs are not suitable to operate. I am therefore looking for ways how to detect the malware with\r\nminimal effort.\r\nLet’s have a look at the environment. SCADA networks are highly deterministic. Means who is talking to whom\r\nand how, i.e. command and control patterns, is repeatable. For IEC-104 it means the same type and sequence of\r\nIEC-104 commands can be found in normal operation in time periods over a day or over weekdays and weekend\r\ndays.\r\nExample 1, time period 2 working days and one night, 36 hours:\r\nTypeID Type Description\r\nNumber of\r\nOccurrences\r\n13 M_ME_NC_1 Measured value, short floating point number 1’184’834\r\nhttps://www.ntop.org/cybersecurity/how-ntopng-monitors-iec-60870-5-104-traffic/\r\nPage 2 of 5\n\n30 M_SP_TB_1\r\nSingle-point information witd time tag\r\nCP56Time2a\r\n2\r\n103 C_CS_NA_1 Clock synchronisation command 1\r\nThe only command sent was for time synchronisation of the client.\r\nComparing operations data with the available malware data, the different behaviour of the malware becomes\r\nvisible:\r\nSource\r\nhttps://www.ntop.org/cybersecurity/how-ntopng-monitors-iec-60870-5-104-traffic/\r\nPage 3 of 5\n\nThe malware is sending command after command to the client device (ASDU=3), iterating through the IOAs.\r\nKind of similar like checking different ports on a host and trying to login.\r\nTypeID Type Description\r\n100 C_IC_NA_1 Interrogation command\r\n45 C_SC_NA_1 Single command\r\n46 C_DC_NA_1 Double command\r\nFrom defender point of view, we obviously can not block port 2404, neither the commands used by the malware,\r\nas one or all commands are used for normal operation by the control system itself.\r\nBut looking at the TypeID transition, the malware differentiates from legitimate traffic:\r\nTransitions Normal Operations Traffic Malware\r\nM_ to M_ \u003e 1000 0\r\nM_ to C_ or C_ to M_ \u003e 0 \u0026\u0026 \u003c 10 0\r\nC_ to C_ 0 \u003e 10\r\nIn ntopng, three detection mechanism are build in:\r\nIEC Unexpected TypeID. As used TypeIDs are known by the operator, this check monitors for unknown or\r\nnot allowed TypeIDs and alerts them.\r\nIEC Invalid Transition. In this check TypeID transitions are recorded over a predefined time period, the\r\nIEC60870 Learning Period, found under Settings / Preferences / Behaviour Analysis. An alert is generated,\r\nif a unknown TypeID transition is detected.\r\nIEC Invalid Command Transition is as well checking for transitions, but specifically transitions of\r\ncommands. If the amount of command to command transition exceeds a threshold, an alert is generated.\r\nAll three Check can be found in the Flow Checks.\r\nhttps://www.ntop.org/cybersecurity/how-ntopng-monitors-iec-60870-5-104-traffic/\r\nPage 4 of 5\n\nFor “IEC Invalid Transition” ntopng needs a learning period in order to track transitions. Default is set to 6 hours,\r\nbut most likely a longer learning period is necessary, e.g. 2 days.\r\nSource: https://www.ntop.org/cybersecurity/how-ntopng-monitors-iec-60870-5-104-traffic/\r\nhttps://www.ntop.org/cybersecurity/how-ntopng-monitors-iec-60870-5-104-traffic/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.ntop.org/cybersecurity/how-ntopng-monitors-iec-60870-5-104-traffic/"
	],
	"report_names": [
		"how-ntopng-monitors-iec-60870-5-104-traffic"
	],
	"threat_actors": [],
	"ts_created_at": 1775434751,
	"ts_updated_at": 1775791243,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8c2ba457a5350eab2e0ae15ad90dc858d8988253.pdf",
		"text": "https://archive.orkl.eu/8c2ba457a5350eab2e0ae15ad90dc858d8988253.txt",
		"img": "https://archive.orkl.eu/8c2ba457a5350eab2e0ae15ad90dc858d8988253.jpg"
	}
}