{
	"id": "22b1c4a6-d890-4e45-bafa-b06be1641513",
	"created_at": "2026-04-06T00:14:06.935023Z",
	"updated_at": "2026-04-10T03:21:52.58573Z",
	"deleted_at": null,
	"sha1_hash": "7b68d6aef329b3c237d94161f4e51192484c49b8",
	"title": "LockerGoga: Ransomware Targeting Critical Infrastructure",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2531158,
	"plain_text": "LockerGoga: Ransomware Targeting Critical Infrastructure\r\nPublished: 2019-04-11 · Archived: 2026-04-05 17:40:23 UTC\r\nA FortiGuard Labs Threat Analysis Report\r\nSince the discovery of Stuxnet, more and more attacks are being discovered targeting critical infrastructures.\r\nWhile some attacks are sophisticated and some are not, both can cause significant damage with far-reaching\r\nimpact.  \r\nFigure 1. Critical infrastructure attacks since Stuxnet discovery\r\nIn the early age of ransomware, these attacks were not primarily used to target critical infrastructure. But recently,\r\nthe FortiGuard Labs threat research teams have seen an increasing trend of ransomware attacks targeting critical\r\ninfrastructures using attacks such as WannaCry, NotPetya, SamSam and now LockerGoga. This says a lot about\r\nthe future of ransomware.\r\nDiscovered early this year, LockerGoga is a new ransomware family that has been detected attacking industrial\r\ncompanies, severely compromising their operations. The file-encrypting malware’s entrance to the scene began\r\nwhen it was allegedly involved in attacking an engineering consulting firm based in France. Just two weeks ago, it\r\nmade headlines again for crippling the operations of the an international manufacturer. And shortly thereafter, two\r\nAmerican chemical companies were also reported to have been hit by the same malware.\r\nAt the moment, there are very limited details as to how this malware got into their systems, but there seems to be a\r\nhigh possibility that the campaigns were targeted and conducted in a multi-stage scheme. Building on that\r\npremise, the fact that the malware’s execution needs administrative rights suggests that the attackers had\r\npreviously gained high system privileges in an earlier stage of the attack.\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 1 of 13\n\nThese uncertainties aside, in this article we will dive into what we know for certain about the characteristics of\r\nLockerGogas as a ransomware. We will also show that although it has some unusual techniques, it is not as\r\nadvanced as one would expect from such high-profile, targeted attacks.\r\nOverview\r\nThe binary for this particular variant of LockerGoga does not utilize any type of security evasion or obfuscation.\r\nInstead, the binary only goes as far as encoding the RSA public key that is used in its later stages for file\r\nencryption. It’s possible to speculate that the attackers may have already been fully aware of the target companies’\r\nsecurity measures, and were therefore confident that their malware would not be intercepted even without any\r\nobfuscation.\r\nAnother interesting fact is that the malware uses open-source Boost libraries for its filesystem, and inter-process\r\ncommunication and Crypto++ (Cryptopp) for file encryption. One of the advantages of using these libraries is\r\neasier development and implementation since developers only need to work with wrapper functions instead of\r\ncalling individual native APIs to achieve the same goal. And since this utilizes a higher level of programming,\r\nstatically and dynamically analysing the application without source code is more complicated than just reading a\r\nstraight sequence of Windows APIs. However, since they do not use standard libraries, they need to be manually\r\nlinked and the functions need to be physically added to the final binary, which results a larger file size than usual.\r\nThe image below shows the execution flow of LockerGoga ransomware. There are three basic stages to the\r\nmalware’s execution, and the malware switches between them depending on supplied parameters or the lack\r\nthereof. \r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 2 of 13\n\nFigure 2. LockerGoga Execution Flow\r\nLockerGoga uses a master/slave model to perform file encryption. A “master” process communicates with “slave”\r\nprocesses in a unidirectional fashion. LockerGoga uses the Boost Interprocess Communication (IPC) library to\r\nimplement this model. The “master” and “slave” processes communicate through a shared memory where data is\r\nwritten. The “master” process searches for files to encrypt, then writes the paths of these files in the shared\r\nmemory. The “slave” processes then read the shared memory to get the file path and perform the file encryption.\r\nInitial Execution\r\nThere is not much going on in the malware’s initial execution, which occurs by executing without parameters. It\r\njust drops a copy of itself in %TEMP%/tgytutrc{number}.exe and executes it with the “-m” (master) parameter.\r\nAdding the “-l” parameter enables the malware to write details of its execution in “C:\\.log”.\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 3 of 13\n\nFigure 3. Sample LockerGoga execution log\r\nMaster\r\nThe “master” process is responsible for most of the malicious routines, like searching for files to encrypt, locking\r\nout Administrator users from the system, and disabling network interfaces.\r\nLog Off Sessions and Change Administrator Passwords\r\nThe first thing it does is log off all other sessions except the current one. It does this by using the Windows native\r\ntool logoff.exe. Afterwards, it sets a hardcoded password for all administrator accounts.\r\nThis is one of the confusing behaviors of this malware. If the malware sets a password that is practically unknown\r\nto the victims, they are essentially locked out of their systems, giving justice to its “Locker” name. However, this\r\nalso prevents them from reading the ransom note and having the chance to pay, which defeats the idea of the\r\ncampaign being monetary-driven. In fact, it is this unusual behaviour that started the speculations that this\r\nmalware may have a different purpose.\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 4 of 13\n\nFigure 4. Procmon log for logging off other sessions and setting administrator passwords\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 5 of 13\n\nFigure 5. Sets password for Administrator accounts\r\nIt then executes its slave processes to perform the actual file encryption, which will be discussed in more details in\r\nthe Slave section below. It does this by executing its binary with the parameters “-i \u003cshared memory name\u003e -s”.\r\nThe “-s” instructs the malware to run in “slave” mode. The “-i” specifies the shared memory name used for\r\ninterprocess communication between the “master” and the “slaves”.  This is implemented using Boost’s IPC\r\nlibrary.\r\nTo be able to communicate with the “slave” processes, the master process creates a named shared memory, “SM-tgytutrc”, with a size of 0x10000 bytes. It uses Boost library to initialize this memory, but internally it is using the\r\nFile Mapping APIs. \r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 6 of 13\n\nFigure 6. Creates a named shared memory\r\nAs seen above, the “slave” process calls CreateFileMappingA() API, with the handle set to 0xFFFFFFFF which\r\nmeans it will use the Windows Page File.\r\nThe “master” process enumerates files for encryption and puts their Base64 encoded paths into the shared\r\nmemory. Further discussion on how the “slave” processes use the data written in the shared memory can also be\r\nfound in the Slave section below.\r\nIn order to prevent the recovery of the encrypted files from deleted files on the disk, it uses another Windows\r\nnative tool: cipher.exe. Cipher.exe clears all the unused or free disk space on the disk drives, making sure none of\r\nthe deleted files can be restored.\r\nAfter that, it disables all interfaces in the system, possibly to prevent remote connections from connecting to it.\r\nThis is an unusual case for a ransomware when recovery of the encrypted files is less of a worry, since you have to\r\nfigure out how to get inside your own system first.\r\nFigure 7. Procmon log for executing slaves, cipher.exe, netsh.exe\r\nSlave\r\nThe “slave” processes are responsible for the file encryption function. A “slave” process expects a message from\r\nthe master process containing the path of the file to be encrypted.\r\nThe slave process is executed with the following parameters:\r\n-i \u003cshared memory name\u003e -s –l\r\nThe –l (log) is used when the master process was also executed with –l parameter.\r\nTo map a view of the shared memory, it calls MapViewOfFileEx() API.\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 7 of 13\n\nFigure 8. Mapping a view of the shared memory\r\nIt then waits for an incoming message from the master process. This message contains a base64 encoded data\r\nwhich when decoded, is actually the path of the file it will encrypt.\r\nFigure 9. Base64 encoded path of the file it will encrypt\r\nBefore encrypting the file, it calls the Restart Manager and the Service Control Manager APIs to stop non-critical\r\nservices that might be using the file it will encrypt.\r\nFigure 10. Restart Manager and Service Control Manager stopping services that might be using the file it\r\nwill encrypt\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 8 of 13\n\nThe file encryption function starts with getting the addresses of Native APIs that it will use to manipulate the file\r\nit will encrypt. These include:\r\nNtOpenFile\r\nNtClose\r\nNtReadFile\r\nNtWriteFile\r\nRtlInitUnicodeString\r\nNext, it prepares a memory space that’s 0x90 bytes in size which will be appended to the encrypted file. This will\r\nhold the “GOGA” structure that contains the following data:\r\nFigure 11. “GOGA” structure contains encryption information\r\nThe marker contains the string “GOGA1510”. This is followed by the size of the file to be encrypted. The next\r\nDWORD is always 0 (more on this below). The next data contains the randomly generated AES key and IV,\r\nfollowed by the end marker “goga” and padding.\r\nFigure 12. Data initialisation in the “GOGA” structure\r\nIt then checks whether the file with .locked extension exists. If it exists, it will delete the file.\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 9 of 13\n\nFigure 13. Deletes encrypted file with .locked extension\r\nIt then renames the targeted file adding the .locked extension.\r\nFigure 14. Rename the file adding .locked extension\r\nThe “slave” process splits the file into 0x10000 byte chunks, and then encrypts each chunk individually with\r\nCrypto++ AES algorithm using the randomly generated key and IV. \r\nFigure 15. File encryption in chunks of 0x10000 bytes\r\nBefore the last chunk (likely to be less than 0x10000 bytes in size) is encrypted, the negated value of its crc32 is\r\nappended to the chunk, increasing the size to plus 4 bytes. \r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 10 of 13\n\nFigure 16. Negated CRC32 of the last chunk is appended to the file content before encryption\r\nThe “append_negated_crc32val” function above is then called twice. The second call assigns value to the\r\n“always_0” DWORD in the “GOGA” structure mentioned above. This means that the “always_0” member might\r\nhave also contained the crc32 of the last chunk of the file content. However, for some reason, a -1 value is copied\r\nto the crc32 buffer by the author before the function ends, so on the second cal, a 0 (~(-1)) will be copied to the\r\n“always_0”.\r\nFigure 17. -1 is copied to the CRC32 buffer\r\nLastly, the AES key and IV used to encrypt the file, which is contained in the “GOGA” structure mentioned\r\nabove, are encrypted with an RSA algorithm using the following public key.\r\nFigure 18. RSA public key embedded in the malware body\r\nThe final “GOGA” structure is then appended to the encrypted file.\r\nFigure 19. “GOGA” structure is appended to the encrypted file\r\nRansom Note\r\nNext, the ransom note named “README-NOW.txt” is dropped into the %Desktop% of the current user. It\r\ncontains instructions to contact some email addresses for payment instructions.\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 11 of 13\n\nFigure 20. LockerGoga ransom note \r\nConclusion\r\nLockerGoga is not at all exceptional in terms of sophistication, especially when compared to other ransomware\r\nfamilies.\r\nHowever, it has a unique way of iterating through the files of the victim. In most cases, ransomware uses low level\r\nWindows APIs in a multi-threaded approach to encrypt all the files, which is more than adequate for its purposes.\r\nIn this case however, it spawns a process of itself in \"slave\" mode to encrypt a file. That means for each file, a new\r\n\"slave\" process is executed just to encrypt the file. This creates much more noise, as any process spawning\r\nhundreds of child processes will be an obvious cause for suspicion, to say the least.\r\nAlthough the malware developer obviously does not bother using evasions, especially considering the binaries\r\ndon't have any obfuscation, its use of a valid Digital Certificate may be the source of their confidence. Plus,\r\naccording to reports, there is a high possibility that these attacks are targeted, which might entail a previously\r\nconducted reconnaissance stage—an integral part of any targeted attack—to check the security composure of the\r\ntarget before deploying the payload, and in that process they may have figured out that evasions were not needed.\r\nIn this kind of targeted attack, it is not a matter how sophisticated or advanced the malware payload is. It is a\r\nmatter of how they were able to get inside the company. Even the fastest and most advanced malware will not be\r\nable to cause any damage unless it finds its way into a system. So while LockerGoga has some features that give it\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 12 of 13\n\nan edge compared to other ransomware families, it’s not about that. It's how they were able to deliver and execute\r\nthe ransomware inside the company.\r\nOn this note, it is very important to both users and the security industry for us to continue to investigate so we can\r\nfind out how what happened to patient zero. As this incident is still an ongoing investigation, we'll be keeping\r\neveryone posted with any developments.\r\n-= FortiGuard Lion Team =-\r\nSolution\r\nFortinet customers are protected by the following:\r\nSamples are detected by W32/Crypren.AFFL!tr.ransom signature\r\nFortiSandbox rates the LockerGoga’s behaviour as high risk\r\nIOCs\r\nSha256\r\nc97d9bbc80b573bdeeda3812f4d00e5183493dd0d5805e2508728f65977dda15 – W32/Crypren.AFFL!tr.ransom\r\nView the latest Fortinet Threat Landscape Indices for botnets, malware, and exploits.\r\nLearn more about FortiGuard Labs and the FortiGuard Security Services portfolio. Sign up for the\r\nweekly FortiGuard Threat Intelligence Briefs.\r\nLearn more about the FortiGuard Security Rating Service, which provides security audits and best practices.\r\nRead more about our Network Security Expert program, Network Security Academy program or our FortiVets\r\nprogram.\r\nSource: https://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nhttps://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/lockergoga-ransomeware-targeting-critical-infrastructure.html"
	],
	"report_names": [
		"lockergoga-ransomeware-targeting-critical-infrastructure.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434446,
	"ts_updated_at": 1775791312,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7b68d6aef329b3c237d94161f4e51192484c49b8.pdf",
		"text": "https://archive.orkl.eu/7b68d6aef329b3c237d94161f4e51192484c49b8.txt",
		"img": "https://archive.orkl.eu/7b68d6aef329b3c237d94161f4e51192484c49b8.jpg"
	}
}