{
	"id": "526c5eae-0f2e-49e8-b754-3508b5fd920a",
	"created_at": "2026-04-06T00:09:48.648156Z",
	"updated_at": "2026-04-10T13:12:06.582577Z",
	"deleted_at": null,
	"sha1_hash": "9ebfc7d199038a553b57aa13b3ca067d0c2ae061",
	"title": "A deep dive into Phobos ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1052042,
	"plain_text": "A deep dive into Phobos ransomware\r\nBy Bill Cozens\r\nPublished: 2019-07-24 · Archived: 2026-04-05 22:37:48 UTC\r\nPhobos ransomware appeared at the beginning of 2019. It has been noted that this new strain of ransomware is\r\nstrongly based on the previously known family: Dharma (a.k.a. CrySis), and probably distributed by the same\r\ngroup as Dharma.\r\nWhile attribution is by no means conclusive, you can read more about potential links between Phobos and\r\nDharma here, to include an intriguing connection with the XDedic marketplace.\r\nPhobos is one of the ransomware that are distributed via hacked Remote Desktop (RDP) connections. This isn’t\r\nsurprising, as hacked RDP servers are a cheap commodity on the underground market, and can make for an\r\nattractive and cost efficient dissemination vector for threat groups.\r\nIn this post we will take a look at the implementation of the mechanisms used in Phobos ransomware, as well as at\r\nits internal similarity to Dharma.\r\nAnalyzed sample\r\na91491f45b851a07f91ba5a200967921bf796d38677786de51a4a8fe5ddeafd2\r\nArticle continues below this ad.\r\nBehavioral analysis\r\nThis ransomware does not deploy any techniques of UAC bypass. When we try to run it manually, the UAC\r\nconfirmation pops up:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 1 of 25\n\nIf we accept it, the main process deploys another copy of itself, with elevated privileges. It also executes some\r\ncommands via windows shell.\r\nRansom notes of two types are being dropped: .txt as well as .hta. After the encryption process is finished, the\r\nransom note in the .hta form is popped up:\r\nEven after the initial ransom note is popped up, the malware still runs in the background, and keeps encrypting\r\nnewly created files.\r\nAll local disks, as well as network shares are attacked.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 2 of 25\n\nIt also uses several persistence mechanisms: installs itself in %APPDATA% and in a Startup folder, adding the\r\nregistry keys to autostart its process when the system is restarted.\r\nThose mechanisms make Phobos ransomware very aggressive: the infection didn’t end on a single run, but can be\r\nrepeated multiple times. To prevent repeated infection, we should remove all the persistence mechanisms as soon\r\nas we noticed that we got attacked by Phobos.\r\nThe Encryption Process\r\nThe ransomware is able to encrypt files without an internet connection (at this point we can guess that it comes\r\nwith some hardcoded public key). Each file is encrypted with an individual key or an initialization vector: the\r\nsame plaintext generates a different ciphertext.\r\nIt encrypts a variety of files, including executables. The encrypted files have an e-mail of the attacker added. The\r\nparticular variant of Phobos also adds an extension ‘.acute’ – however in different variants different extensions\r\nhave been encountered. The general pattern is:  .id[-][].\r\nVisualization of the encrypted content does not display any recognizable patterns. It suggests that either a stream\r\ncipher, or a cipher with chained blocks was used (possibly AES in CBC mode). Example – a simple BMP before\r\nand after encryption:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 3 of 25\n\nWhen we look inside the encrypted file, we can see a particular block at the end. It is separated from the encrypted\r\ncontent by ‘0’ bytes padding. The first 16 bytes of this block are unique per each file (possible Initialization\r\nVector). Then comes the block of 128 bytes that is the same in each file from the same infection. That possibly\r\nmeans that this block contains the encrypted key, that is uniquely generated each run. At the end we can find a 6-\r\ncharacter long keyword which is typical for this ransomware. In this case it is ‘LOCK96’, however, different\r\nversions of Phobos have been observed with different keywords, i.e. ‘DAT260’.\r\nIn order to fully understand the encryption process, we will look inside the code.\r\nInside\r\nIn contrast to most of the malware that comes protected by some crypter, Phobos is not packed or obfuscated.\r\nAlthough the lack of packing is not common in general population of malware, it is common among malware that\r\nare distributed manually by the attackers.\r\nThe execution starts in WinMain function:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 4 of 25\n\nDuring its execution, Phobos starts several threads, responsible for its different actions, such as: killing blacklisted\r\nprocesses, deploying commands from commandline, encrypting accessible drives and network shares.\r\nUsed obfuscation\r\nThe code of the ransomware is not packed or obfuscated. However, some constants, including strings, are\r\nprotected by AES and decrypted on demand. A particular string can be requested by its index, for example:\r\nThe AES key used for this purpose is hardcoded (in obfuscated form), and imported each time when a chunk of\r\ndata needs to be decrypted.\r\nThe Initialization Vector is set to 16 NULL bytes.\r\nThe code responsible for loading the AES key is given below. The function wraps the key into\r\na BLOBHEADER structure, which is then imported.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 5 of 25\n\nFrom the BLOBHEADER structure we can read the following information: 0x8 – PLAINTEXTKEYBLOB,\r\n0x2=CUR_BLOB_VERSION, 0x6610 – CALG_AES_256.\r\nExample of a decrypted string:\r\nAmong the decrypted strings we can also see the list of the attacked extensions\r\nWe can also find a list of some keywords:\r\nacute actin Acton actor Acuff Acuna acute adage Adair Adame banhu banjo Banks Banta Barak Caleb Cales\r\nCaley calix Calle Calum Calvo deuce Dever devil Devoe Devon Devos dewar eight eject eking Elbie elbow\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 6 of 25\n\nelder phobos help blend bqux com mamba KARLOS DDoS phoenix PLUT karma bbc CAPITAL\r\nThese are a list of possible extensions used by this ransomware. They are (probably) used to recognize and skip\r\nthe files which already has been encrypted by a ransomware from this family. The extension that will be used in\r\nthe current encryption round is hardcoded.\r\nOne of the encrypted strings specifies the formula for the file extension, that is later filled with the Victim ID:\r\nUNICODE \".id[-1096].[lockhelp@qq.com].acute\"\r\nKilling processes\r\nThe ransomware comes with a list of processes that it kills before the encryption is deployed. Just like other\r\nstrings, the full list is decrypted on demand:\r\nmsftesql.exe sqlagent.exe sqlbrowser.exe sqlservr.exe sqlwriter.exe\r\noracle.exe ocssd.exe dbsnmp.exe synctime.exe agntsvc.exe\r\nmydesktopqos.exe isqlplussvc.exe xfssvccon.exe mydesktopservice.exe\r\nocautoupds.exe agntsvc.exe agntsvc.exe agntsvc.exe encsvc.exe\r\nfirefoxconfig.exe tbirdconfig.exe ocomm.exe mysqld.exe mysqld-nt.exe\r\nmysqld-opt.exe dbeng50.exe sqbcoreservice.exe excel.exe infopath.exe\r\nmsaccess.exe mspub.exe onenote.exe outlook.exe powerpnt.exe steam.exe\r\nthebat.exe thebat64.exe thunderbird.exe visio.exe winword.exe\r\nwordpad.exe\r\nThose processes are killed so that they will not block access to the files that are going to be encrypted.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 7 of 25\n\nDeployed commands\r\nThe ransomware deploys several commands from the commandline. Those commands are supposed to prevent\r\nfrom recovering encrypted files from any backups.\r\nDeleting the shadow copies:\r\nvssadmin delete shadows /all /quiet\r\nwmic shadowcopy delete\r\nChanging Bcdedit options (preventing booting the system in a recovery mode):\r\nbcdedit /set {default} bootstatuspolicy ignoreallfailures\r\nbcdedit /set {default} recoveryenabled no\r\nDeletes the backup catalog on the local computer:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 8 of 25\n\nwbadmin delete catalog -quiet\r\nIt also disables firewall:\r\nnetsh advfirewall set currentprofile state off\r\nnetsh firewall set opmode mode=disable\r\nexit\r\nAttacked targets\r\nBefore the Phobos starts its malicious actions, it checks system locale\r\n(using GetLocaleInfoW options: LOCALE_SYSTEM_DEFAULT, LOCALE_FONTSIGNATURE ). It terminates\r\nexecution in case if the 9th bit of the output is cleared. The 9th bit represent Cyrlic alphabets – so, the systems that\r\nhave set it as default are not affected.\r\nBoth local drives and network shares are encrypted.\r\nBefore the encryption starts, Phobos lists all the files, and compare their names against the hardcoded lists. The\r\nlists are stored inside the binary in AES encrypted form, strings are separated by the delimiter ‘;’.\r\nAmong those lists, we can find i.e. blacklist (those files will be skipped). Those files are related to operating\r\nsystem, plus the info.txt, info.hta files are the names of the Phobos ransom notes:\r\ninfo.htainfo.txtboot.inibootfont.binntldrntdetect.comio.sys\r\nThere is also a list of directories to be skipped – in the analyzed case it contains only one directory:  C:Windows .\r\nAmong the skipped files are also the extensions that are used by Phobos variants, that were mentioned before.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 9 of 25\n\nThere is also a pretty long whitelist of extensions:\r\n1cd 3ds 3fr 3g2 3gp 7z accda accdb accdc accde accdt accdw adb adp ai ai3 ai4 ai5 ai6 ai7 ai8 anim\r\narw as asa asc ascx asm asmx asp aspx asr asx avi avs backup bak bay bd bin bmp bz2 c cdr cer cf cfc\r\ncfm cfml cfu chm cin class clx config cpp cr2 crt crw cs css csv cub dae dat db dbf dbx dc3 dcm dcr\r\nder dib dic dif divx djvu dng doc docm docx dot dotm dotx dpx dqy dsn dt dtd dwg dwt dx dxf edml efd\r\nelf emf emz epf eps epsf epsp erf exr f4v fido flm flv frm fxg geo gif grs gz h hdr hpp hta htc htm\r\nhtml icb ics iff inc indd ini iqy j2c j2k java jp2 jpc jpe jpeg jpf jpg jpx js jsf json jsp kdc kmz\r\nkwm lasso lbi lgf lgp log m1v m4a m4v max md mda mdb mde mdf mdw mef mft mfw mht mhtml mka mkidx mkv\r\nmos mov mp3 mp4 mpeg mpg mpv mrw msg mxl myd myi nef nrw obj odb odc odm odp ods oft one onepkg\r\nonetoc2 opt oqy orf p12 p7b p7c pam pbm pct pcx pdd pdf pdp pef pem pff pfm pfx pgm php php3 php4 php5\r\nphtml pict pl pls pm png pnm pot potm potx ppa ppam ppm pps ppsm ppt pptm pptx prn ps psb psd pst ptx\r\npub pwm pxr py qt r3d raf rar raw rdf rgbe rle rqy rss rtf rw2 rwl safe sct sdpx shtm shtml slk sln\r\nsql sr2 srf srw ssi st stm svg svgz swf tab tar tbb tbi tbk tdi tga thmx tif tiff tld torrent tpl txt\r\nu3d udl uxdc vb vbs vcs vda vdr vdw vdx vrp vsd vss vst vsw vsx vtm vtml vtx wb2 wav wbm wbmp wim wmf\r\nwml wmv wpd wps x3f xl xla xlam xlk xlm xls xlsb xlsm xlsx xlt xltm xltx xlw xml xps xsd xsf xsl xslt\r\nxsn xtp xtp2 xyze xz zip\r\nHow does the encryption work\r\nPhobos uses the WindowsCrypto API for encryption of files. There are several parallel threads to deploy\r\nencryption on each accessible disk or a network share.\r\nAES key is created prior to the encrypting thread being run, and it is passed in the thread parameter.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 10 of 25\n\nFragment of the key generation function:\r\nAlthough the AES key is common to all the files that are encrypted in a single round, yet, each file is encrypted\r\nwith a different initialization vector. The initialization vector is 16 bytes long, generated just before the file is\r\nopen, and then passed to the encrypting function:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 11 of 25\n\nUnderneath, the AES key and the Initialization Vector both are generated with the help of the same function, that\r\nis a wrapper of  CryptGenRandom  (a strong random generator):\r\nThe AES IV is later appended to the content of the encryped file in a cleartext form. We can see it on the following\r\nexample:\r\nBefore the file encryption function is executed, the random IV is being generated:\r\nThe AES key, that was passed to the thread is being imported to the context ( CryptImportKey ), as well the IV is\r\nbeing set. We can see that the read file content is encrypted:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 12 of 25\n\nAfter the content of the file is encrypted, it is being saved into the newly created file, with the ransomware\r\nextension.\r\nThe ransomware creates a block with metadata, including checksums, and the original file name. After this block,\r\nthe random IV is being stored, and finally, the block containing the encrypted AES key. The last element is the file\r\nmarker: “LOCK96”:\r\nBefore being written to the file, the metadata block is being encrypted using the same AES key and IV as the file\r\ncontent.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 13 of 25\n\nEncrypted metadata block:\r\nFinally, the content is appended to the end of the newly created file:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 14 of 25\n\nBeing a ransomware researcher, the common question that we want to answer is whether or not the ransomware is\r\ndecryptable – meaning, if it contains the weakness allowing to recover the files without paying the ransom. The\r\nfirst thing to look at is how the encryption of the files is implemented. Unfortunately, as we can see from the\r\nabove analysis, the used encryption algorithm is secure. It is AES, with a random key and initialization vector,\r\nboth created by a secure random generator. The used implementation is also valid: the authors decided to use the\r\nWindows Crypto API.\r\nEncrypting big files\r\nPhobos uses a different algorithm to encrypt big files (above 0x180000 bytes long). The algorithm explained\r\nabove was used for encrypting files of typical size (in such case the full file was encrypted, from the beginning to\r\nthe end). In case of big files, the main algorithm is similar, however only some parts of the content are selected for\r\nencryption.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 15 of 25\n\nWe can see it on the following example. The file ‘test.bin’ was filled with 0xAA bytes. Its original size was\r\n0x77F87FF:\r\nAfter being encrypted with Phobos, we see the following changes:\r\nSome fragments of the file has been left unencrypted. Between of them, starting from the beginning, some\r\nfragments are wiped. Some random-looking block of bytes has been appended to the end of the file, after the\r\noriginal size. We can guess that this is the encrypted content of the wiped fragments. At the very end of the file,\r\nwe can see a block of data typical for Phobos::\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 16 of 25\n\nLooking inside we can see the reason of such an alignment. Only 3 chunks from the large file are being read into a\r\nbuffer. Each chunk is 0x40000 bytes long:\r\nAll read chunks are merged together into one buffer. After this content, usual metadata (checksums, original file\r\nname) are added, and the full buffer is encrypted:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 17 of 25\n\nBy this way, authors of Phobos tried to minimize the time taken for encryption of large files, and at the same time\r\nmaximize the damage done.\r\nHow is the AES key protected\r\nThe next element that we need to check in order to analyze decryptability is the way in which the authors decided\r\nto store the generated key.\r\nIn case of Phobos, the AES key is encrypted just after being created. Its encrypted form is later appended at the\r\nend of the attacked file (in the aforementioned block of 128 bytes). Let’s take a closer look at the function\r\nresponsible for encrypting the AES key.\r\nThe function generating and protecting the AES key is deployed before the each encrypting thread is started.\r\nLooking inside, we can see that first several variables are decrypted, in the same way as the aforementioned\r\nstrings.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 18 of 25\n\nOne of the decrypted elements is the following buffer:\r\nIt turns out that the decrypted block of 128 bytes is a public RSA key of the attacker. This buffer is then verified\r\nwith the help of a checksum. A checksum of the RSA key is compared with the hardcoded one. In case if both\r\nmatches, the size that will be used for AES key generation is set to 32. Otherwise, it is set to 4.\r\nThen, a buffer of random bytes is generated for the AES key.\r\nAfter being generated, the AES key is protected with the help of the hardcoded public key. This time the authors\r\ndecided to not use Windows Crypto API, but an external library. Detailed analysis helped us to identify that it\r\nis the specific implementation of RSA algorithm (special thanks to Mark Lechtik for the help).\r\nThe decrypted 128 bytes long RSA key is imported with the help of the function  RSA_pub_key_new . After that,\r\nthe imported RSA key is used for encryption of the random AES key:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 19 of 25\n\nSumming up, the AES key seems to be protected correctly, which is bad news for the victims of this ransomware.\r\nAttacking network shares\r\nPhobos has a separate thread dedicated to attacking network shares.\r\nNetwork shares are enumerated in a loop:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 20 of 25\n\nComparison with Dharma\r\nPrevious sources references Phobos as strongly based on Dharma ransomware. However, that comparison was\r\nbased mostly on the outer look: a very similar ransom note, and the naming convention used for the encrypted\r\nfiles. The real answer in to this question would lie in the code. Let’s have a look at both, and compare them\r\ntogether. This comparison will be based on the current sample of Phobos, with a Dharma sample\r\n(d50f69f0d3a73c0a58d2ad08aedac1c8).\r\nIf we compare both with the help of BinDiff, we can see some similarities, but also a lot of mismatching\r\nfunctions.\r\nIn contrast to Phobos, Dharma loads the majority of its imports dynamically, making the code a bit more difficult\r\nto analyze.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 21 of 25\n\nAddresses of the imported functions are stored in an additional array, and every call takes an additional jump to\r\nthe value of this array. Example:\r\nIn contrast, Phobos has a typical, unobfuscated Import Table\r\nBefore the encryption routine is started, Dharma sets a mutex: “Globalsyncronize_“.\r\nBoth, Phobos and Dharma use the same implementation of the RSA algorithm, from a static library. Fragment of\r\ncode from Dharma:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 22 of 25\n\nFile encryption is implemented similarly in both. However, while Dharma uses AES implementation from the\r\nsame static library, Phobos uses AES from Windows Crypto API.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 23 of 25\n\nLooking at how the key is saved in the file, we can also see some similarities. The protected AES key is stored in\r\nthe block at the end of the encrypted file. At the beginning of this block we can see some metadata that are similar\r\nlike in Phobos, for example the original file name (in Phobos this data is encrypted). Then there is a 6 character\r\nlong identifier, selected from a hardcoded pool.\r\nSuch identifier occurs also in Phobos, but there it is stored at the very end of the block. In case of Phobos this\r\nidentifier is constant for a particular sample.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 24 of 25\n\nConclusion\r\nPhobos is an average ransomware, by no means showing any novelty. Looking at its internals, we can conclude\r\nthat while it is not an exact rip-off Dharma, there are significant similarities between both of them, suggesting the\r\nsame authors. The overlaps are at the conceptual level, as well as in the same RSA implementation used.\r\nAs with other threats, it is important to make sure your assets are secure to prevent such compromises. In this\r\nparticular case, businesses should review any machines where Remote Desktop Procol (RDP) access has been\r\nenabled and either disable it if it is not needed, or making sure the credentials are strong to prevent such things are\r\nbrute-forcing.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/\r\nPage 25 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2019/07/a-deep-dive-into-phobos-ransomware/"
	],
	"report_names": [
		"a-deep-dive-into-phobos-ransomware"
	],
	"threat_actors": [
		{
			"id": "20c759c2-cd02-45bb-85c6-41bde9e6a7cf",
			"created_at": "2024-01-18T02:02:34.189827Z",
			"updated_at": "2026-04-10T02:00:04.721082Z",
			"deleted_at": null,
			"main_name": "HomeLand Justice",
			"aliases": [
				"Banished Kitten",
				"Karma",
				"Red Sandstorm",
				"Storm-0842",
				"Void Manticore"
			],
			"source_name": "ETDA:HomeLand Justice",
			"tools": [
				"BABYWIPER",
				"BiBi Wiper",
				"BiBi-Linux Wiper",
				"BiBi-Windows Wiper",
				"Cl Wiper",
				"LowEraser",
				"No-Justice Wiper",
				"Plink",
				"PuTTY Link",
				"RevSocks",
				"W2K Res Kit"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434188,
	"ts_updated_at": 1775826726,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9ebfc7d199038a553b57aa13b3ca067d0c2ae061.pdf",
		"text": "https://archive.orkl.eu/9ebfc7d199038a553b57aa13b3ca067d0c2ae061.txt",
		"img": "https://archive.orkl.eu/9ebfc7d199038a553b57aa13b3ca067d0c2ae061.jpg"
	}
}