{
	"id": "9bb5eb63-c8a8-4134-84c1-1013180569b2",
	"created_at": "2026-04-06T00:09:26.250824Z",
	"updated_at": "2026-04-10T13:12:06.250521Z",
	"deleted_at": null,
	"sha1_hash": "c0dd0549e6e1ef216afe3368810035295a7794ad",
	"title": "VIASAT incident: from speculation to technical details.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2638056,
	"plain_text": "VIASAT incident: from speculation to technical details.\r\nPublished: 2022-03-31 · Archived: 2026-04-05 15:06:30 UTC\r\nVIASAT incident: from speculation to technical details.\r\n34 days after the incident, yesterday Viasat published a statement providing some technical details about the attack\r\nthat affected tens of thousands of its SATCOM terminals. Also yesterday, I eventually had access to two\r\nSurfbeam2 modems: one was targeted during the attack and the other was in a working condition. Thank you so\r\nmuch to the person who disinterestedly donated the attacked modem.\r\nI've been closely covering this issue since the beginning, providing a plausible theory based on the information\r\nthat was available at that time, and my experience in this field. Actually, it seems that this theory was pretty close\r\nto what really happened.\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 1 of 12\n\nFortunately, now we can move from just pure speculation into something more tangible, so I dumped the flash\r\nmemory for both modems (Spansion S29GL256P90TFCR2) and the differences were pretty clear. In the following\r\npicture you can see 'attacked1.bin', which belongs to the targeted modem and 'fw_fixed.bin', coming from the\r\nmodem in working conditions.\r\nA destructive pattern, that corrupted the flash memory rendering the SATCOM modems inoperable, can be\r\nobserved on the left, confirming what Viasat stated yesterday. \r\nAfter verifying the destructive attack, I'm now statically analyzing the firmware extracted from the 'clean' modem.\r\nFirmware version is 3.7.3.10.9, which seems to date back to late 2017.\r\nBesides talking about a 'management network' and 'legitimate management commands', Viasat did not provide any\r\nspecific details about this. In my previous blog post I introduced the theory that probably 'TR069' was the\r\ninvolved management protocol.\r\nObviously, I can't completely confirm this scenario but I'll try to elaborate my reasoning.\r\nAttacking via a management protocol\r\nI think there are two main options: either the attackers abused a MAC management protocol or an application\r\nlayer one.\r\nFor the MAC case ('ut_mac' binary), in general terms, the attackers would have required an even more privileged\r\naccess to either the NOC or the Ground Stations, probably in a persistent way via malware. I guess that this kind\r\nof privileged access would have been enough to limit the attack to Ukraine, instead of knocking out half Europe.\r\nAs a result, I'm inclined to think this was not the case.\r\nOn the other hand, a 'misconfigured VPN' that enabled the attackers to reach the 'management segment' and\r\nexecute 'commands' seems to be more related to an application layer management protocol: SNMP or TR069.\r\nSNMP \r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 2 of 12\n\nAn initial analysis of 'vsatSb2Ut.so' shows that the implemented MIB does not seem to provide the required\r\nfunctionality to perform this kind of attack. \r\nI would initially discard this option.\r\nTR069\r\nAs suggested in the previous blog post, the Surfbeam2 modems are deployed with the Axiros' AXACT client.  The\r\nnature of the operations performed by TR069 clients makes them very convenient for an attack of this type.\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 3 of 12\n\ncwmpdefault.xml\r\nBy reverse engineering the 'cwmpclient' binary it is possible to recover the Viasat's TR069 data model, analyze\r\nhow it has been implemented as well as  how it communicates with other components to perform the required\r\nactions (via IPC queues). \r\nSo far, I would highlight the following  features/issues:\r\n1. * Updated *  \r\nAs the analysis is ongoing I want to clarify that new firmware may be cryptographically validated, after being\r\ndownloaded by the TR069 client. It depends on the configuration of the terminal, according to 'sw_unwrap.sh'\r\nIf the signature is not enforced, then the firmware image is just validated against a CRC via 'swValidate' \r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 4 of 12\n\n...\r\n     swValidate (implemented in 'ut_mac' binary)\r\n2. * Updated *  'APP INSTALL'\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 5 of 12\n\nA deeper look at the 'ut_app_execute_operation' function revealed that it is implementing a functionality that\r\nenables the ACS to install (upload and run) arbitrary binaries on the modem, without requiring either a signature\r\nverification or a complete firmware upgrade. \r\nThis functionality seems to match both the Viasat statement as well as the approach to deploy the  'AcidRain'\r\nwiper described by SentinelOne. \r\n     '/usr/bin/app_img_dwnid'\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 6 of 12\n\nCommand Injections\r\nAdditionally, there are multiple command injection vulnerabilities that can be trivially exploited from a malicious\r\nACS (or someone with the same privileged position in the network).\r\ni.e 'ut_app_execute_operation' for the custom 'Device.Services.X_VIASAT-COM_app' object ('cwmpclient')\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 7 of 12\n\nAlso in '/usr/bin/bbagent' (listening on *:8700/TCP, when activated)\r\n'Lifeline' - Firmware update over multicast\r\nThis is an interesting 'emergency' feature intended to perform a firmware upgrade over a specific Multicast group,\r\nwhen everything else fails. It's implemented across different binaries: 'ut_mac', 'mim', 'mimIf' and 'lifelineClient'\r\nConclusion\r\nThere are similarities between these issues and the approach followed by the attackers in the Viasat incident,\r\nespecially the TR069 'APP INSTALL' feature, but I am not implying that any of these techniques were actually\r\nabused by the attackers. However, overall the security posture of the Surfbeam2 firmware does not look good. \r\nHopefully these vulnerabilities are no longer present in the newest Viasat firmware, otherwise that may pose a\r\nsecurity risk.\r\nThere are several unknowns yet to be resolved.\r\n1. How the initial compromise of the VPN appliance worked. Did the attackers have valid credentials (maybe\r\nstolen from either Skylogic or its partners) or they exploited a known vulnerability (assuming an 0day doesn't\r\nmatch a 'misconfigured VPN appliance' explanation )? \r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 8 of 12\n\n2. How exactly the attack propagated to other countries, lasting for several hours. One of the affected persons I\r\ntalked to got his modem knocked out around 9:00 am (GMT+1), several hours after the initial attack.\r\n3. Before the destructive payload was executed, there was any other kind of malicious code running in the\r\nmodems for a short period of time? Sentinelone published a very interesting research on 'AcidRain', a wiper that is\r\nable to generate the same destructive pattern observed in the modem's flash memory. \r\nCoincidentally, this wiper also has similarities with 'VPNfilter' malware.\r\n4. Did the compromise of the management segment involve additional attacks besides the VPN issue?\r\nUnfortunately these technical questions can only be answered by people with an insider knowledge. Let's see if\r\nViasat is willing to provide further details on this case.\r\n* Updated  - The VPN Attack vector* \r\nViasat has not elaborated the VPN attack vector yet, but they acknowledged to journalists that the attack\r\noriginated from the Internet. Viasat is also distancing itself from the fiasco by directly pointing to Skylogic and its\r\nground infrastructure.\r\nAlthough we're entering again the land of speculation, there are some factual bits that should be considered.\r\nA simple recon of Skylogic's ground network (AS201935) reveals a couple of interesting things:\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 9 of 12\n\n1. Skylogic relies on Fortigate appliances\r\n            'cgl-fw02' may be indicating the Skylogic's Cagliari teleport.\r\n2.  The route propagation matches the attack. Viasat's statement explicitly mentions that the attacker moved\r\nlaterally until reaching the management network.\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 10 of 12\n\nIt is also worth mentioning that, in 2021, there were different attack campaigns and leaks targeting Fortinet VPN\r\nappliances. These attacks were carried out by groups of malicious actors that exploited multiple vulnerabilities\r\nthat were discovered in these products.\r\nViasat's statement mentions a 'misconfigured VPN appliance', so if we consider that this definition may be a\r\neuphemism for an 'unpatched VPN appliance', then we may have a plausible attack vector. It is also possible that\r\nmalicious actors may have previously collected valid VPN credentials as a result of these attacks. \r\nAnother interesting aspect that Viasat implicitly introduces in its statement is the potential security weaknesses\r\nthat may be derived from the complexity of wholesale operations for a Satellite infrastructure.  Down in this chain\r\nwe find ground station operators, satellite service providers, distributors , resellers...\r\nAt some point they all need certain kind of access to provide their services, so this integration also may pose a\r\nchallenge in terms of security. For instance, a publicly exposed server provides a glimpse of the Eutelsat's partners\r\nAPI capabilities.\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 11 of 12\n\nIn general terms, it is also recommended to not expose an operator's desktop in corporate videos. It usually leaks\r\ninformation that may facilitate different kinds of attacks.\r\nSource: https://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nhttps://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html"
	],
	"report_names": [
		"viasat-incident-from-speculation-to.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434166,
	"ts_updated_at": 1775826726,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c0dd0549e6e1ef216afe3368810035295a7794ad.pdf",
		"text": "https://archive.orkl.eu/c0dd0549e6e1ef216afe3368810035295a7794ad.txt",
		"img": "https://archive.orkl.eu/c0dd0549e6e1ef216afe3368810035295a7794ad.jpg"
	}
}