{
	"id": "18403921-1976-4370-bfce-344082cb5161",
	"created_at": "2026-04-06T01:29:38.489791Z",
	"updated_at": "2026-04-10T03:20:18.296722Z",
	"deleted_at": null,
	"sha1_hash": "dc9f8c0391600210586ecd21652de09c175b8f2a",
	"title": "Deep Analysis – The EKING Variant of Phobos Ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2349713,
	"plain_text": "Deep Analysis – The EKING Variant of Phobos Ransomware\r\nBy Xiaopeng Zhang\r\nPublished: 2020-10-13 · Archived: 2026-04-06 00:34:27 UTC\r\nFortiGuard Labs Threat Report\r\nAffected platforms:    Microsoft Windows\r\nImpacted parties:       Windows Users\r\nImpact:                       Encrypts Victims’ Files for Ransom\r\nSeverity level:             Critical\r\nThe Phobos ransomware family is fairly recent, only having been first spotted by security researchers in early 2019. But\r\nsince then, it has continued to push out new variants that not only evolve attack methods, but also frequently change the\r\nextension name of encrypted files in past variants. And in its short history, its victims have often complained that they were\r\ncheated by the attacker of Phobos by not restoring files.\r\nTwo weeks ago, FortiGuard Labs captured a new threat sample from the wild. It was a Microsoft Word document with a\r\nmalicious Macro designed to spread the EKING variant of Phobos. I ran a deep analysis on this sample, and in this analysis\r\npost I will show how this variant infects victim’s system and how it scans and encrypts files using an AES algorithm on a\r\nvictim’s device as well as shared network folders.\r\nLater, in December 2020, I also presented my findings from this Phobos variant (with title \"Pay or Lose Your Critical Data -\r\nDeep Analysis of A Variant of Phobos Ransomware\") on AVAR 2020 Virtual.\r\nOpening the Captured Sample in MS Office Word\r\nAfter opening the Word document, it displays a warning that directs the victim to click an “Enable Content” button on the\r\nyellow bar to enable Macros, as shown in Figure 1.1.\r\nSince Macros can contain malicious code, MS Office Word by default displays a Security Warning that warns users that the\r\ndocument could be risky. The user can then decide whether or not to execute the Macro (by clicking the “Enable Content”\r\nbutton).\r\nFigure 1.1. Sample content in MS Office Word\r\nHowever, the document warning screen is a ruse. Going through the Macro code, I found that it has a built-in event function\r\nnamed Document_Close(), which is invoked automatically when MS Office Word exits. In other words, the malicious\r\nMacro code is executed when the victim closes the document. This also has the benefit of bypassing detection by some\r\nsandbox solutions (FortiSandbox detects this malicious Word attachment as riskware.)\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 1 of 11\n\nThe code of the Macro is simple and clear. It extracts a base64-encoded block from the opened sample into a local file at\r\n“C:\\Users\\Public\\Ksh1.xls”. It then decodes the file into another file by calling the command “Certutil -decode\r\nC:\\Users\\Public\\Ksh1.xls C:\\Users\\Public\\Ksh1.pdf”. “Ksh1.pdf” is a base64-decoded file, which is a PE file (DLL\r\nfile). Figure 1.2 is a screenshot of the Macro code, showing where it is about to perform a command to base64 decode the\r\nfile “Ksh1.xls” into “Ksh1.pdf”.\r\nFigure 1.2. Macro to base64 decode extracted file\r\nThe final task of the Macro is to execute the decoded PE file “Ksh1.pdf” by executing the command “Rundll32\r\nC:\\Users\\Public\\Ksh1.pdf,In”. The decoded PE file “Ksh1.pdf” is a DLL file with export function “In” that is called by\r\n“Rundll32.exe” in the above command line.\r\nFigure 1.3. ASM code of the export function In\r\nFigure 1.3 shows the ASM code of the export function “In” of “Ksh1.pdf”. From my comments inserted next to the ASM\r\ncode, one can easily understand that it first creates a new directory at “C:\\Users\\Public\\cs5”. It then downloads a file from\r\nthe URL “hxxp://178[.]62[.]19[.]66/campo/v/v” into file “C:\\Users\\Public\\cs5\\cs5.exe” by calling the API\r\n“URLDownloadToFile()”. And finally, it runs up the downloaded “cs5.exe” file by calling the API “CreateProcessA()”.  By\r\nthe way, the download URL string and full file path string are hard coded in the DLL file “Ksh1.pdf”.  Interestingly, the\r\ndownloaded file “cs5.exe” is the payload file of Phobos.\r\nLooking into the Payload EXE File\r\n“C:\\Users\\Public\\cs5\\cs5.exe” is the payload of the EKING variant of Phobos, which has been protected by an unknown\r\npacker, as shown in Exeinfo PE in Figure 2.1.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 2 of 11\n\nFigure 2.1. Protected Phobos payload EXE file\r\nPhobos has an AES encrypted configuration block that contains much configuration information (69 items in this variant).\r\nThese are decrypted in a function before being used with an index number argument. It also contains the new extension\r\nstring for encrypted files, data to generate key for encrypting files, a file exclusion list, version information of Phobos,\r\nransom information for the victim, and so on. \r\nIn Figure 2.2 we can see an example of decrypting the new extension for encrypted files “.id[\u003c\u003cID\u003e\u003e-2987].\r\n[wiruxa@airmail.cc].eking”, whose index number is 0x04. According to one decrypted string “[\u003c\u003cID\u003e\u003e-2987] v2.9.1”,\r\nwhose index number is 0x33, we know the version of this variant is v2.9.1.\r\nFigure 2.2. Decrypting a new extension from the configuration block\r\nStart a Second Process and Execute Two Groups of Commands\r\nWhen “cs5.exe” runs, it creates a second process of itself by calling the API CreateProcessWithTokenW(), along with a\r\ntoken from Explorer.exe process so that the second process runs in the security context of the Explorer.exe’s token. In this\r\nway, it has the privilege needed to read and write more files on the victim’s system. \r\nPhobos executes two groups of commands in two created threads.\r\nThe first group of commands are listed below with my added comments:\r\nvssadmin delete shadows /all /quiet   – Deletes all of the volume's shadow copies.\r\nwmic shadowcopy delete  – Deletes shadow copies from local computer.\r\nbcdedit /set {default} bootstatuspolicy ignoreallfailures \r\nbcdedit /set {default} recoveryenabled no – Disables the automatic startup repair feature.\r\nwbadmin delete catalog –quiet  – Deletes the backup catalog.\r\nexit\r\nBy deleting the shadow copies that the Windows system makes for system restore, the victim is not able to use it to restore\r\nthe encrypted files. It also prevents the victim from restoring files from an automatic startup repair or from a backup catalog.\r\nThe commands of the second group turn off the Windows Firewall on the infected system, as shown below.\r\nnetsh advfirewall set currentprofile state off  – For Windows 7 and later versions.\r\nnetsh firewall set opmode mode=disable  – For Windows XP, Windows 2003 versions.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 3 of 11\n\nexit\r\nAdding Auto-run Items \r\nThe malware also decrypts the string \"Software\\Microsoft\\Windows\\CurrentVersion\\Run\" (index number is 0x11), which is\r\nthe registry subkey path, from the encrypted configuration block. It then creates an auto-run item “cs5” to the same subkey\r\nof both root keys, HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. Figure 4.1 is a screenshot of the added\r\nauto-run item under the root key “HKEY_CURRENT_USER”.\r\nFigure 4.1. Added auto-run item “cs5”\r\nOther than adding this item into the auto-run group in the system registry, it also copies “cs5.exe” into two auto startup\r\nfolders: “%AppData%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup” and “%ProgramData%\\Microsoft\\Windows\\Start\r\nMenu\\Programs\\Startup”.  Figure 4.2 shows the ASM code snippet of copying “cs5.exe” into the two startup folders.\r\nFigure 4.2. Copy payload file into startup folders\r\nExecutable files in these two folders are executed automatically by Windows system when Windows starts. That means that\r\nfour “cs5.exe” files will be started by Windows at startup to maintain malware survival. You don’t need to worry about the\r\nconflict. Phobos has a mechanism that uses a Mutex object to ensure only one process is running. The other “cs5.exe”\r\nprocesses exit if the same Mutex object exists.\r\nCore Tasks Phobos Performs on a Victim’s System\r\nFor ransomware, the core task is to encrypt victim’s files and then demand a ransom for decrypting those encrypted files. In\r\nthis section, I will show you how the EKING variant of Phobos performs this task.\r\nTo increase its performance, it creates a number of threads to scan and encrypt files on the victim’s system. In addition, it\r\nuses a lot number of Event objects to control and synchronize the progress of these threads.\r\n1.  Thread to Terminate Processes\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 4 of 11\n\nIt begins by starting a thread to keep from terminating specified processes from a name list that contains forty-one process\r\nnames shown, as below. As you may guess, the name list was also decrypted from the configuration block with index\r\nnumber 0x0a.\r\nmsftesql.exe;sqlagent.exe;sqlbrowser.exe;sqlservr.exe;sqlwriter.exe;oracle.exe;ocssd.exe;dbsnmp.exe;synctime.exe;agntsvc.exe;mydesktopqos.exe;isqlplus\r\nnt.exe;mysqld-opt.exe;dbeng50.exe;sqbcoreservice.exe;excel.exe;infopath.exe;msaccess.exe;mspub.exe;onenote.exe;outlook.exe;powerpnt.exe;steam.exe;thebat.exe;theb\r\nThis process name list has been spotted many times being used by other Ransomware families to do the same action.\r\nThese processes belong to products like MS SQL Server, Oracle Database, VMware, Panda Security, MySql, FireFox, SQL\r\nAnywhere, RedGate SQL Backup, MS Excel, MS Word, MS Access, MS PowerPoint, MS Publisher, MS OneNote, MS\r\nOutlook, The Bat!, Thunderbird, WordPad, and so on.\r\nPhobos keeps terminating these applications to force them to release any files they have currently opened so Phobos can\r\nencrypt them.\r\n2.  Threads to Scan Files to Encrypt\r\nThe thread function of this thread calls the API GetLogicalDrives() to obtain and enumerate all logical drives on the victim’s\r\nsystem, such as “C:\\”, “D:\\”, “E:\\” and so on. It then creates two scan threads for each logical drive. That means the files in\r\neach logical drive are handled by two threads.\r\nFigure 5.1. Ignore two system folders\r\nTo avoid destroying the victim’s Windows system, it ignores encrypting files under two system folders and their sub-folders,\r\nwhich are “%WinDir%” (usually “C:\\Windows”) and “%ProgramData%\\Microsoft\\Windows\\Caches”. Figure 5.1 shows\r\nthat Phobos is able to detect if a current path (“\\\\?\\D:”) matches the two system folders it needs to ignore.\r\nAs mentioned, it creates two threads for scanning each logical drive’s files. One thread is for normal scan (one file by one\r\nfile) and the other is a special scan only for database related files. I can assume that these kinds of files have more value for\r\nthe victim than the others. It then scans database files by the following extensions, listed below (decryption index number is\r\n0x06):\r\nfdb;sql;4dd;4dl;abs;abx;accdb;accdc;accde;adb;adf;ckp;db;db-journal;\r\ndb-shm;db-wal;db2;db3;dbc;dbf;dbs;dbt;dbv;dcb;dp1;eco;edb;epim;fcd;gdb;\r\nmdb;mdf;ldf;myd;ndf;nwdb;nyf;sqlitedb;sqlite3;sqlite;\r\nBesides this, it also has two extension exclusion lists. One contains the encrypted file extensions that Phobos has used in its\r\nhistory, as listed below (decryption index number is 0x07):\r\neking;actin;Acton;actor;Acuff;Acuna;acute;adage;Adair;Adame;banhu;banjo;Banks;Banta;Barak;Caleb;Cales;Caley;calix;Calle;Calum;Calvo;deuce;D\r\nThe other list contains files that this variant uses to show its victim the ransom information, as well as some Windows\r\nsystem files, as listed below (decryption index number is 0x08):\r\ninfo.hta;info.txt;boot.ini;bootfont.bin;ntldr;ntdetect.com;io.sys;osen.txt\r\nBoth of these exclusion lists are used by the scan thread in a callback function to filter files to encrypt according to its rules.\r\nMeanwhile, Phobos also creates an encryption thread in each scan thread for encrypting the victim’s files. Here is how the\r\nscan thread and encryption thread work together: The scan thread keeps scanning files, and copying the file name with full\r\npath into a common buffer and an event is set once one file is selected. The encryption thread then can obtain the file name\r\nfrom the common buffer and encrypt.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 5 of 11\n\n3.  Encryption Algorithm and Key Phobos Uses\r\nPbobos uses AES (Advanced Encryption Standard) CBC (Cipher Block Chaining) mode as its encryption algorithm for\r\nencrypting files. In my analysis, this variant of Phobos does not use the built-in Crypto APIs for AES that Windows\r\nprovides, but implements its own AES function.\r\nAs you may know, when people talk about AES CBC encryption and decryption, “IV” and “Key” are often mentioned. \r\nFor its key length, we know Phobos uses a 256-bit AES key (20H bytes), which is the strongest file encryption. Moreover, it\r\nuses an asymmetric public-private key cryptosystem to protect the AES key. The public key is decrypted from the\r\nconfiguration block with index number 0x2.  \r\nFigure 5.2 AES key and its public key encrypted\r\nThe AES key is generated using 10H bytes of random data and 10H bytes of data from the decrypted public key. As you can\r\nsee in Figure 5.2, it has just generated its AES Key (20H bytes) at the top of memory window. The subsequent information is\r\nthe related data of the encrypted AES Key (80H bytes) that is generated with the data of the volume serial number of\r\n“%systemdrive%” (like “C:\\” on the victim’s system) as well as some decrypted constant values in the function\r\nSub_401706. The last four bytes following the encrypted AES key are a CRC32 hash value of the above two parts. \r\nTo protect the AES key, Phobos encrypts it using RSA algorithm with attacker’s public key. Therefore, as long as the victim\r\nis able to obtain the attacker’s private key, the AES key can be decrypted and furthermore the encrypted files can\r\nbe restored. It is hard to obtain the RSA private key with the public key saved in Phobos even through brute force. The\r\nprivate key is always kept by the attacker.\r\nThe encrypted AES key will be recorded in the encrypted file, I will explain the encrypted file structure later. \r\nThe IV (Initialization Vector) data is 10H bytes long and is usually randomly generated. It is also recorded in the encrypted\r\nfiles like the encrypted AES key is. An IV is used along with AES key for data encryption, just like a salt to an MD5\r\nalgorithm.\r\nOnce the IV data and the AES key are obtained, it can decrypt the encrypted files.\r\n4.  Thread for Encrypting Files\r\nAs I mentioned above, this is the encryption thread started by the scan thread. Once the scan thread selects a file, it then\r\ncopies the file full path to a common buffer for the encryption thread, which is notified by the scan thread (setting an event\r\nobject). \r\nIt then decrypts a format string (index number 0x04) from the configuration block as a new file extension for those\r\nencrypted files, as seen below, where “\u003c\u003cID\u003e\u003e” will be replaced by the volume serial number of the system drive.\r\n.id[\u003c\u003cID\u003e\u003e-2987].[wiruxa@airmail.cc].eking\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 6 of 11\n\nFigure 5.3 Encrypted file with new extension\r\nThis is just a formatted new file name for the encrypted file with the new extension. This time, the file selected and filtered\r\nby a scan thread is “\\\\?\\E:\\test_file.txt” and the encrypted file name for it is “\\\\?\\E:\\test_file.txt.id[[581F1093-2987].\r\n[wiruxa@airmail.cc].eking”.\r\nIt continues to read out the content of the selected file (for example: “E:\\test_file.txt”). We know the size of the AES\r\nencryption block is fixed at 10H bytes. Thus, if the size of data to be encrypted is not aligned to 10H, it needs to append the\r\ndata using padding (Phobos uses “00” as padding) to fix the problem. \r\nFigure 5.4 Calling the AES_CBC_Encrypt() function to encrypt file content\r\nFigure 5.4 shows that Phobos is about to call the AES_CBC_Encrypt() function, whose arg0 is a key object\r\n(AES_CTX Struct) containing the IV and Key used to encrypt the file content shown in the memory window (with three\r\n“00” padding elements appended to it).\r\nAfter encryption, Phobos saves the ciphertext into the encrypted file (for example, “E:\\test_file.txt.id[[581F1093-2987].\r\n[wiruxa@airmail.cc].eking”) by calling the API WriteFile(), as shown in Figure 5.5.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 7 of 11\n\nFigure 5.5 Saving ciphertext into an encrypted file\r\nThe encrypted file content consists of two parts. The first part is the ciphertext of the original file content. The second part is\r\na group of data, which I call the decryption_config_block. It is used to decrypt the first part. Figure 5.6 is a screenshot of\r\nencrypted file content. I will explain what the decryption_config_block contains.\r\nFigure 5.6 Example of the encrypted file content\r\nThe first 10H bytes (surrounded by red) are the encrypted original file content—the same as shown in Figure 5.5. The 40H\r\nbytes (surrounded by blue) are an encrypted block that contains some constant values as well as the original file name,\r\nwhich are encrypted using the same AES Key and IV. The following 14H bytes “00” can be thought as a data delimiter. The\r\n10H bytes (surrounded by black) are the IV data only for this file. The next Dword 0x03 tells the size of the appended\r\npadding to the original file content (refer to Figure 5.5 again). The 80H data block (in green) is the related data of the\r\nencrypted AES key, which is generated in the scan thread and is different for different scan threads. The next Dword 0xF2 is\r\nthe size of the entire decryption_config_block. The last six bytes “4B E5 1F 84 A9 77” are decrypted from the configuration\r\nblock with index number 0x00.\r\nAfter that, the last thing Phobos does is to call the API DeleteFileW() to wipe the original file from the victim’s system.\r\n5.  Scan Network Sharing Resources\r\nThis thread function focuses on network sharing resources. Phobos calls the API WNetOpenEnum() many times using\r\ndifferent values of the argument dwScope. These are RESOURCE_CONNECTED, RESOURCE_RECENT,\r\nRESOURCE_CONTEXT, RESOURCE_REMEMBERED and RESOURCE_GLOBALNET.  \r\nRESOURCE_CONNECTED: Enumerates all currently connected resources.\r\nRESOURCE_RECENT: Enumerates all recently connected resources.\r\nRESOURCE_CONTEXT: Enumerates only those resources in the network context of the caller.\r\nRESOURCE_REMEMBERED: Enumerates all remembered (persistent) connections.\r\nRESOURCE_GLOBALNET: Enumerates all resources on the network.\r\nAPI WNetOpenEnumW() and WNetEnumResourceW() are involved in this work to enumerate network sharing resources. \r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 8 of 11\n\nOnce one resource is successfully obtained, Phobos starts the two scan threads that I discussed in point 2, above, with the\r\nfull address to the resource, like \\\\?\\UNC\\{resource name}\\{folder name}, to start the scan and filter files on it. The scan\r\nthread then starts the encryption thread and is noticed to encrypt when one file is selected, as I explained in point 4.\r\nFigure 5.7 One sharing resource ready to start the scan thread\r\nFigure 5.7, above, shows a sharing resource (“\\\\?\\UNC\\VBoxSvr\\vbox_share_folder”) that is obtained from\r\nRESOURCE_CONNECTED, and is about to call function Sub_405840 to start a new scan thread on this sharing resource.\r\n6.  Thread to Monitor and Scan Future Logical Drives\r\nI have talked about Phobos scanning files on local logical drives, and scanning network sharing resources, which are all the\r\nexisting sources to the victim’s system. \r\nThere is another thread, whose main task is to monitor future logical drives. Why future? Cause, it occurs in special\r\nsituations, for example, the victim attaches a USB flash drive or a cell phone, which the Windows system treats as a new\r\nlogical drive. This will be captured by this thread. It runs detection every second and starts two new scan threads for any\r\nnew logical drives it detects. Figure 5.8 displays a pseudo code showing the logical structure for this thread function.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 9 of 11\n\nFigure 5.8 Pseudo code for scanning a new logical drive\r\nDisplaying Ransom Information to the Victim\r\nThe main thread of Phobos waits for all scan threads and encryption threads to finish their work. It then drops two files,\r\ninfo.hta (html version ransom information) and info.txt (text version ransom information), onto the Desktop as well as into\r\nthe root directory of available logical drives on the victim’s system. It also calls the API ShellExecuteExW() with the\r\ncommand “open” to open the html version info.hta on the victim’s screen, as shown in Figure 6.1. When contacting the\r\nattacker via email, the victim needs to provide a unique victim ID in the email subject like \"581F1093-2987\" for my device ,\r\nwhich consists of a volume serial number of the system drive (usually \"C:\\\") and the variant sub-version number.\r\nFigure 6.1 Ransom information displayed to the victim\r\nConclusion on the Deep Analysis of the EKING Variant\r\nIn this post, I provided a deep analysis of the EKING variant of the Phobos ransomware. I have presented how the payload\r\nfile (cs5.exe) is downloaded from the original MS Word document sample, and what Phobos does to keep it persistent on a\r\nvictim’s system.\r\nI primarily analyzed Phobos’s core task – the scanning and encryption of files on the victim’s system. Through this post, we\r\nknow now that it not only scans files not on logical drives, but also network sharing resources and new attached logical\r\ndrives. I also elaborated on how this variant of Phobos uses multiple threads to finish its work.  \r\nFinally, I explained how Phobos displays its ransom information to the victim when encryption is done.\r\nTo protect your device from being attack by malware, we recommend not opening email attachments from untrusted\r\nsources. \r\nFortinet Solutions\r\nFortinet customers are already protected from this variant of Phobos with FortiGuard’s Web Filtering, AntiVirus, and CDR\r\n(content disarm and reconstruction) services, as follows:\r\nThe downloading URL is rated as \"Malicious Websites\" by the FortiGuard Web Filtering service.\r\nThe Word document and downloaded payload file are detected as \"VBA/Agent.KBU!tr\" and\r\n\"W32/Phobos.HGAF!tr.ransom\" and blocked by the FortiGuard AntiVirus service.\r\nIn addition, FortiSandbox detects the Word document as riskware.\r\nFortiMail users are protected by FortiGuard AntiVirus, which detects the original Word document that is delivering Phobos,\r\nand further protected with the CDR service which can be used to neutralize the threat from all macros within Office\r\ndocuments.\r\nIn addition, to protect devices from being attacked by malware delivered in this way, we recommend that users not open\r\nemail attachments from untrusted sources. End user training on how to identify and flag potentially malicious email is also\r\nhighly recommended.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 10 of 11\n\nIOCs:\r\nURLs\r\nhxxp://178[.]62[.]19[.]66/campo/v/v\r\nSample SHA-256\r\n[Word Document]\r\n667F88E8DCD4A15529ED02BB20DA6AE2E5B195717EB630B20B9732C8573C4E83\r\n[Phobos Payload]\r\n6E9C9B72D1BDB993184C7AA05D961E706A57B3BECF151CA4F883A80A07FDD955\r\nReferences:\r\nhttps://id-ransomware.blogspot.com/2017/10/phobos-ransomware.html\r\nLearn more about FortiGuard Labs threat research and the FortiGuard Security Subscriptions and Services portfolio. Sign\r\nup for the weekly Threat Brief from FortiGuard Labs. \r\nLearn more about Fortinet’s free cybersecurity training initiative or about the Fortinet Network Security Expert\r\nprogram, Network Security Academy program, and FortiVet program.\r\nSource: https://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/deep-analysis-the-eking-variant-of-phobos-ransomware"
	],
	"report_names": [
		"deep-analysis-the-eking-variant-of-phobos-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775438978,
	"ts_updated_at": 1775791218,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dc9f8c0391600210586ecd21652de09c175b8f2a.pdf",
		"text": "https://archive.orkl.eu/dc9f8c0391600210586ecd21652de09c175b8f2a.txt",
		"img": "https://archive.orkl.eu/dc9f8c0391600210586ecd21652de09c175b8f2a.jpg"
	}
}