{
	"id": "558ff71f-6df3-4007-80a5-79049f7e3b69",
	"created_at": "2026-04-06T00:08:39.481354Z",
	"updated_at": "2026-04-10T13:11:48.208218Z",
	"deleted_at": null,
	"sha1_hash": "f0fffea462ad80fe22c654ed66a8c1621c57249d",
	"title": "SamSam - The Evolution Continues Netting Over $325,000 in 4 Weeks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 521833,
	"plain_text": "SamSam - The Evolution Continues Netting Over $325,000 in 4\r\nWeeks\r\nBy Vitor Ventura\r\nPublished: 2018-01-22 · Archived: 2026-04-05 21:21:23 UTC\r\nThis post was written by Vitor Ventura\r\nIntroduction\r\nTalos has been working in conjunction with Cisco IR Services on what we believe to be a new variant of the\r\nSamSam ransomware. This ransomware has been observed across multiple industries including Government,\r\nHealthcare and ICS. These attacks do not appear to be highly targeted, and appear to be more opportunistic in\r\nnature.\r\nGiven SamSam's victimology, its impacts are not just felt within the business world, they are also impacting\r\npeople, especially if we consider the Healthcare sector. Non-urgent surgeries can always be rescheduled but if we\r\ntake as an example patients where the medical history and former medical treatment are crucial the impact may be\r\nmore severe. Furthermore, many critical life savings medical devices are now highly computerized. Ransomware\r\ncan impact the operation of these devices making it very difficult for medical personnel to diagnose and treat\r\npatients leading to potentially life threatening situations. Equipment that might be needed in time-sensitive\r\noperations may be made unavailable due to the computer used to operate the equipment being unavailable.\r\nThe initial infection vector for these ongoing attacks is currently unknown and Talos is investigating this in order\r\nto identify it. The history of SamSam indicates that attackers may follow their previous modus operandi of\r\nexploiting a host and then laterally moving within their target environment to plant and later run the SamSam\r\nransomware. Previously, we observed the adversaries attacking vulnerable JBoss hosts during a previous wave of\r\nSamSam attacks in 2016. Although the infection vector for the new variant is not yet confirmed, there is a\r\npossibility that compromised RDP/VNC servers have played a part in allowing the attackers to obtain an initial\r\nfoothold.\r\nThere are no differences between the encryption mechanism used by this current SamSam variant compared to\r\nolder versions. However, this time the adversaries have added some string obfuscation and improved the anti-analysis techniques used to make detection and analysis marginally more difficult.\r\nThis new variant is deployed using a loader which decrypts and executes an encrypted ransomware payload, this\r\nloader/payload model represents an improvement in the anti-forensic methods used by the malware. Samples\r\ncontaining this loader mechanism have been found as far back as October 2017. The wallet used by SamSam for\r\nthis wave is shared by multiple infected victims as observed by monitoring the wallet at\r\n1MddNhqRCJe825ywjdbjbAQpstWBpKHmFR. We are also able to confirm the first payment into this wallet\r\nwas received on 25th December 2017 - a nice holiday gift for this adversary. This can be confirmed by observing\r\nhttps://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html\r\nPage 1 of 6\n\nthe first wallet transaction found on the Bitcoin blockchain here. There is a possibility that other Bitcoin wallets\r\nare also used but currently Talos is currently unaware of any others.\r\nSimilar to the previous variants, we believe the deployment of this SamSam variant to be highly manual, meaning\r\nan adversary must take manual action in order to execute the malware. The symmetric encryption keys are\r\nrandomly generated for each file. The Tor onion service and the Bitcoin wallet address are hardcoded into the\r\npayload whilst the public key is stored in an external file with the extension .keyxml.\r\nAdditionally, code analysis didn't find any kind of automated mechanism for contacting the Tor Service address\r\nwhich means that the victim identification with the associated RSA private key must be done either manually or\r\nby another adversary tool.\r\nRansom note displayed by SamSam new variant\r\nIn most ransomware the attackers try to convince affected users that they have the ability to decrypt the data after\r\nthe payment is made. SamSam is no different here and even displays a disclaimer as seen in the above screenshot,\r\nstating 'we don't want to damage our reliability' and 'we are honest'.\r\nTo this end SamSam adversaries offer free decryption of two files and an additional free key to decrypt one server.\r\nOnce again SamSam actors show their ability to monitor and laterally move through the network by pointing out\r\nthey will only provide a key if they believe the server is not an important piece of infrastructure. As with previous\r\nversions of SamSam they are advising that messaging the attackers can be performed via their site.\r\nThe \"Runner\"\r\nThe adversary has changed their deployment methodology and now they use a loader mechanism called \"runner\"\r\nto execute the payload. Upon execution, the loader will search for files with the extension .stubbin in its execution\r\ndirectory, this file contains the SamSam encrypted .NET Assembly payload. Upon reading the file, the loader\r\nhttps://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html\r\nPage 2 of 6\n\ndecrypts the payload with the password supplied as the first argument and executes it, passing the remaining\r\narguments.\r\nThe loader is a very simple .NET assembly with no obfuscation. Comparing both the Initialization Vector (IV) and\r\nthe code structure it seems like it may have been derived from an example posted on the Codeproject.com website.\r\nAs you can seen in the images below, the IV used for the Rijndael encryption is the same in both implementations\r\n(posted code in hexadecimal, reversed code in decimal due to decompiler implementation).\r\nPosted code Reversed code\r\nAt the code level looking specifically at the function 'Decrypt', it is obvious that the code structure in the\r\nCodeproject source and the latest SamSam runner sample is the same (comments from the posted code were\r\nremoved).\r\nEncryption routine source code comparison\r\nThe Payload\r\nPrevious versions of SamSam put some effort into the obfuscation of the malware code by encrypting strings with\r\nAES. The new version also obfuscates functions, class names and strings, including the list of targeted file\r\nhttps://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html\r\nPage 3 of 6\n\nextensions, the help file contents and environment variables, this time using DES encryption with a fixed hard-coded key and the IV.\r\nOnce again, the adversary has put more effort into preventing the forensic recovery of the malware sample itself\r\nrather than only relying on the obfuscation the running malware code, which allowed us to reverse engineer this\r\nsample.\r\nAs mentioned before, the password to decrypt the payload is passed as a parameter to the loader, which reduces\r\nthe chances of obtaining the payload for analysis.\r\nPrevious versions of SamSam had an equivalent method for making payload access difficult by launching a thread\r\nthat would wait 1 second before deleting itself from the hard disk.\r\nThe comparison of the main encryption routines between the old and the new samples indicates that this version\r\nof SamSam is similar enough to have high confidence that it belongs to the same malware family.\r\nEncryption Routine Comparison\r\nWhile previous SamSam versions used the API call DriveInfo.GetDrives() to obtain the list of available drives,\r\nthis new version has the drive letters hardcoded. After checking that a drive is ready it starts a search for targeted\r\nfiles on the non-blocklisted folder paths.\r\nThe new variant keeps the same list of targeted file extensions as some of the previous ones. It adds a few new\r\nentries to the list of paths not to encrypt, which includes user profiles \"All Users\", \"default\" and the boot directory.\r\nhttps://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html\r\nPage 4 of 6\n\nThis is in tune with most ransomware which attempt to preserve the operability of the victim's machine. If the\r\nmachine operation is so damaged that the system cannot be booted then the victim will be unable to pay, whereas\r\nif they keep the machine able to function, with limited access to files/folders, then they have a greater chance of a\r\nvictim paying for recovering their important files and documents.\r\nJust like previous versions of SamSam the new version is especially careful to make sure that there is enough\r\nspace on the current drive to create the encrypted document, thus avoiding any corruption that would lead to\r\nirrecoverable encryption.\r\nUnlike most ransomware, SamSam does not delete Volume Shadow Copies and creates an encrypted version of\r\nthe original file which is then deleted using the regular Windows API. Although unlikely, due to block\r\noverwriting, recovery of the original files from the versions of affected folders saved by the operating system may\r\nbe possible.\r\nProfitability\r\nIn identifying the scope of this SamSam campaign, Talos analyzed the Bitcoin wallet addresses used by the\r\nattackers in each of these attacks. As of the time of this writing, the attackers have received approximately 30.4\r\nBTC which equals $325,217.07. As previously mentioned, it is possible that the attackers are leveraging multiple\r\nbitcoin wallets, however Talos has not observed any other than the one listed here being used in these attacks.\r\nhttps://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html\r\nPage 5 of 6\n\nRecommendations\r\nAs the specific initial threat vector is not known at this time, best practices should be implemented to minimize\r\nrisk to organizations. Talos has outlined several best practices that should be considered in a previous blog related\r\nto defending against ransomware related threats. In accordance with best practices protocols like SMB or RDP\r\nshould never be internet facing.  \r\nIOCs SHA256s\r\n0785bb93fdb219ea8cb1673de1166bea839da8ba6d7312284d2a08bd41e38cb9\r\n338fdf3626aa4a48a5972f291aacf3d6172dd920fe16ac4da4dd6c5b999d2f13\r\n3531bb1077c64840b9c95c45d382448abffa4f386ad88e125c96a38166832252\r\n4856f898cd27fd2fed1ea33b4d463a6ae89a9ccee49b134ea8b5492cb447fb75\r\n516fb821ee6c19cf2873e637c21be7603e7a39720c7d6d71a8c19d8d717a2495\r\n72832db9b951663b8f322778440b8720ea95cde0349a1d26477edd95b3915479\r\n754fab056e0319408227ad07670b77dde2414597ff5e154856ecae5e14415e1a\r\n88d24b497cfeb47ec6719752f2af00c802c38e7d4b5d526311d552c6d5f4ad34\r\n88e344977bf6451e15fe202d65471a5f75d22370050fe6ba4dfa2c2d0fae7828\r\n8eabfa74d88e439cfca9ccabd0ee34422892d8e58331a63bea94a7c4140cf7ab\r\n8f803b66f6c6bc4da9211a2c4c4c5b46a113201ecaf056d35cad325ec4054656\r\ndabc0f171b55f4aff88f32871374bf09da83668e1db2d2c18b0cd58ed04f0707\r\ne7bebd1b1419f42293732c70095f35c8310fa3afee55f1df68d4fe6bbee5397e\r\nBTC Wallet\r\n1MddNhqRCJe825ywjdbjbAQpstWBpKHmFR\r\nTor onion service\r\njcmi5n4c3mvgtyt5.onion\r\nDetection\r\nSnort Rules: 45484-45486\r\nAMP for Endpoints: Ensure the TETRA engine, ‘Command Line Capture’, “System Process Protection” are\r\nenabled, and client is v6.05+\r\nSource: https://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html\r\nhttps://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.talosintelligence.com/2018/01/samsam-evolution-continues-netting-over.html"
	],
	"report_names": [
		"samsam-evolution-continues-netting-over.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434119,
	"ts_updated_at": 1775826708,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f0fffea462ad80fe22c654ed66a8c1621c57249d.pdf",
		"text": "https://archive.orkl.eu/f0fffea462ad80fe22c654ed66a8c1621c57249d.txt",
		"img": "https://archive.orkl.eu/f0fffea462ad80fe22c654ed66a8c1621c57249d.jpg"
	}
}