{
	"id": "36fad8e3-35b0-4fd3-b22f-2fa29508c90d",
	"created_at": "2026-04-06T00:07:40.086903Z",
	"updated_at": "2026-04-10T13:13:07.229304Z",
	"deleted_at": null,
	"sha1_hash": "579428ea3765a7f017f9d003e00369ff06d750d0",
	"title": "A deep dive into Phobos ransomware, recently deployed by 8Base group",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 788297,
	"plain_text": "A deep dive into Phobos ransomware, recently deployed by 8Base group\r\nBy Guilherme Venere\r\nPublished: 2023-11-17 · Archived: 2026-04-05 22:03:34 UTC\r\nFriday, November 17, 2023 08:01\r\nCisco Talos has recently observed an increase in activity conducted by 8Base, a ransomware group that uses a variant\r\nof the Phobos ransomware and other publicly available tools to facilitate their operations. \r\nMost of the group’s Phobos variants are distributed by SmokeLoader, a backdoor trojan. This commodity loader\r\ntypically drops or downloads additional payloads when deployed. In 8Base campaigns, however, it has the\r\nransomware component embedded in its encrypted payloads, which is then decrypted and loaded into the\r\nSmokeLoader process’ memory.\r\n8Base’s Phobos ransomware payload contains an embedded configuration which we describe in this blog. Besides\r\nthis embedded configuration, our analysis did not uncover any other significant differences between 8Base’s Phobos\r\nvariant and other Phobos samples that have been observed in the wild since 2019. \r\nOur analysis of Phobos’ configuration revealed a number of interesting capabilities, including a user access control\r\n(UAC) bypass technique and reporting victim infections to an external URL.\r\nNotably, in all samples of Phobos released since 2019 that we analyzed, the same RSA key protected the encryption\r\nkey. This led us to conclude that attaining the associated private key could enable decryption of all these samples. \r\nSmokeLoader’s three stage process to deliver the Phobos payload\r\nWe won’t use this space to provide a full overview of SmokeLoader (Malpedia has the basics), but we would like to show\r\nhow reverse-engineers can reach the final payload. In this example, we’ll use the sample\r\n518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c, but any recent 8base sample will have the\r\nsame ransomware binary payload in the end. This process requires the execution of the malware in a controlled environment\r\nunder a debugger like x32dbg.\r\nSmokeLoader malware decrypts its payload in three stages. The first contains many random API calls to obfuscate the\r\nexecution flow, while the other two involve shellcode stored in allocated memory. The final binary is exposed in the third\r\nstage, where a binary copy of the PE (Windows Portable Executable) data in that memory block gives the final payload in its\r\noriginal form.\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 1 of 13\n\nDecryption process for SmokeLoader embedded payload.\r\nIn the first stage, enabling a breakpoint at VirtualAlloc or VirtualProtect and checking its arguments should reveal the\r\naddress where the next stage will be decrypted. This memory location will then be called at the end of the entry point (EP)\r\nfunction, as shown above.\r\nOn the second-stage shellcode, following the second call in the function called from the entry point leads to the call to the\r\nsecond allocated memory with the third stage. Once the third stage is reached, that memory area should contain the\r\nunpacked binary (PE) which can then be exported to a file and analyzed.\r\nThe final payload hash extracted by this method is\r\n32a674b59c3f9a45efde48368b4de7e0e76c19e06b2f18afb6638d1a080b2eb3.\r\nOverview of features included in the Phobos ransomware\r\nOur analysis of Phobos uncovered a number of features that enable operators of the ransomware to establish persistence in a\r\ntargeted system, perform speedy encryption, and remove backups, amongst other capabilities. Phobos is a typical\r\nransomware capable of encrypting files both in local drives as well as network shares. In our FY23 Q2 Talos Incident\r\nResponse Quarterly Report, we detailed how the 8Base group used their Phobos variant after installing AnyDesk to enable\r\nremote access to the machine as well as perform credential dumping via LSASS. These stolen credentials were later used to\r\nelevate privileges, exfiltrate data and run the ransomware module.\r\nTalos has observed the following features present in the malware code:\r\nFull encryption of files below 1.5MB and partial encryption of files above this threshold to improve the speed of\r\nencryption. Larger files will have smaller blocks of data encrypted throughout the file and a list of these blocks is\r\nsaved in the metadata along with the key at the end of the file.\r\nCapability to scan for network shares in the local network.\r\nPersistence achieved via Startup folder and Run Registry key.\r\nGeneration of target list of extensions and folders to encrypt.\r\nProcess watchdog thread to kill processes that may hold target files open. This is done to improve the chances the\r\nimportant files will be encrypted.\r\nDisable system recovery, backup and shadow copies and the Windows firewall.\r\nEmbedded configuration with more than 70 options available. This configuration is encrypted with the same AES\r\nfunction used to encrypt files, but using a hardcoded key.\r\nBased on the analysis of this configuration data, we were able to uncover additional features present in the malware binary\r\nwhich can be enabled by setting specific options. These features have not been documented or have only been superficially\r\nmentioned in open source reporting to date: \r\nUAC bypass using a .NET profiler DLL loading vulnerability.\r\nThe existence of a debugging file that enables additional features in the malware, illustrated in the following section.\r\nList of blocklisted file extensions that point to names of other groups using the Phobos malware.\r\nDynamically imported API calls to avoid behavioral detection by security products.\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 2 of 13\n\nA hardcoded RSA key used to protect the per-file AES key used in the encryption. \r\nReporting of victim infection to an external URL.\r\nOS check for Cyrillic language to prevent the malware from running in unwanted environments.\r\nWe also examined the encryption methodology used by Phobos. Versions of Phobos released after 2019 use a custom\r\nimplementation of AES-256 encryption, with a different random symmetric key used for each encrypted file, instead of\r\nusing the Windows Crypto API like earlier variants. Once each file is encrypted, the key used in the encryption along with\r\nadditional metadata is then encrypted using RSA-1024 with a hardcoded public key, and saved to the end of the file. This\r\nalgorithm has been documented before, for example in this Malwarebytes post from 2019, and the process still remains the\r\nsame.\r\nThis makes it extremely unlikely the files can be decrypted by brute force, as each file uses a different key, even though\r\nattempts at brute-forcing it have been made in the past. It implies, however, that once the private RSA key is known, any file\r\nencrypted by any Phobos variant since 2019 can reliably be decrypted. This fact is supported by an analysis of over a\r\nthousand unpacked Phobos samples available on VirusTotal since 2019, where the same public RSA key mentioned above is\r\nused. \r\nRSA key used in all variants of Phobos since 2019 analyzed by Talos.\r\nNext, we are going to take a deeper look at the configuration file and some of the features it enables.\r\nDecrypting the Phobos configuration file\r\nIn order to understand how the configuration data is used in Phobos, we analyzed the malicious code in IDA Pro. This\r\nallowed us to interact with the configuration data using IDA Python and to decrypt all the configuration data at once. But\r\nfirst, we are going to look at how the configuration data looks in the binary. Once the file is loaded in IDA Pro, one of the\r\nfirst operations we observe being executed by the code is to check its payload and load it into memory:\r\nA snippet of code at the entry point with Phobos configuration data setup in memory.\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 3 of 13\n\nIn the code above we see the malware initially checking the CRC32 hash of the data in the last section of the PE file. In the\r\ncase of our sample, this section is named “.cdata” although different samples may use a variation of this name. We have\r\nobserved samples using “.cdata” and “.sdata”.\r\nThe data is then loaded into a heap-allocated memory and a structure with pointers to this data is saved to a global variable,\r\nnamed “payoad_struct_addr” in the image above. This structure will be used by the decryption function in order to load\r\nrequested configuration entries later throughout the code. Each entry has a specific index which is passed as a parameter to\r\nthe decryption function as we can see in the last code block.\r\nThe structure used to handle the configuration data has 48 bytes and is defined as follows:\r\nStructure storing pointers to configuration data.\r\nThe headers and the actual data are loaded in different buffers allocated in heap memory and pointers to these buffers are\r\nsaved in the structure, as well as the number of entries in the configuration. The data is followed by a 16-byte AES key used\r\nto decrypt the configuration. This key is hardcoded in the binary. \r\nThe header contains information to find the encrypted data for each index in the configuration. The structure has 12 bytes\r\nand is defined as follows:\r\nStructure for header entries in configuration data.\r\nThe offset above is relative to the start of the encrypted data buffer starting at 0x00. The index also starts at 0x00 and each\r\nindex is relatively static for the type of data it contains, which means that for a given index, every sample should have the\r\nsame type of configuration data in them.\r\nWe have, however, observed that some samples show small changes in the content of their indexes. Since Phobos has been\r\nused by many groups in the past, these variations could indicate they are using a different builder or variant. In our analysis\r\nof the public samples available in VirusTotal, we found that around 88% of them have 64 configuration entries, while some\r\nhave as little as 40 and as many as 72 entries.\r\nBased on our code analysis, we were also able to infer the existence of three additional options used for setting the reporting\r\nURL and custom message to be sent back to the attacker. These options were not observed in any sample we analyzed, but\r\nthe code to handle them is present in all samples. A better look at this feature is shown later in this blog.\r\nThe decryption function accepts two parameters: an index to the desired entry and a pointer to a buffer that’s used if the\r\nentry contains more than four bytes of data. Otherwise, the buffer parameter must be zero.\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 4 of 13\n\nDecryption function showing the call to AES_Init and AES_Decrypt using the key present in the payload\r\nstructure.\r\nThe code scans the header buffer for an entry matching the requested index. It then allocates enough memory to store the\r\nencrypted data and copies the data to that space, and calls the AES_Init function with the key present at\r\n“payload_struct_addr + 0x10”, which is hardcoded in the sample data section. The function AES_Decrypt is then called\r\nwith the encrypted data and this AES object as a parameter.\r\nAutomating the configuration decryption with IDA Pro\r\nOnce the decryption algorithm is understood, it is easy to automate the decryption of every entry in the configuration and\r\noutput the details to a file. IDA Pro allows the use of Python to automate tasks inside the application, and we decided to use\r\nthe Flare-Emu Python module to emulate the malware’s AES routines instead of re-implementing the code in Python.\r\nSince the decryption function requires only two parameters and is therefore fairly independent, we decided to start the\r\nemulation from that point, creating a structure similar to what the malware does for the payload data:\r\neh=flare_emu.EmuHelper()\r\nconf_struct=eh.allocEmuMem(0x30)\r\nheader_data=eh.allocEmuMem(header_size)\r\nconfig_data=eh.allocEmuMem(config_size)\r\nThen populating this structure with the appropriate values:\r\neh.writeEmuPtr(conf_struct,header_data)\r\neh.writeEmuPtr(conf_struct+4,config_entries)\r\neh.writeEmuPtr(conf_struct+8,config_data)\r\neh.writeEmuPtr(conf_struct+0xc,config_size)\r\neh.writeEmuMem(conf_struct+0x10,AES_Init_key_struct)\r\n# load buffers\r\neh.writeEmuMem(header_data,eh.getEmuBytes(enc_data_start+0x8, header_size))\r\neh.writeEmuMem(config_data,eh.getEmuBytes(config_start,config_size))\r\n# write addr of struct back to code\r\neh.writeEmuPtr(eh.analysisHelper.getNameAddr(CFG_STRUCT_NAME), conf_struct)\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 5 of 13\n\nOnce the structure is created, we can walk through each entry in the header and prepare the emulator stack and call the\r\nemulation starting at the decryption function:\r\nif entry_size\u003c=4:\r\nbuffer=0\r\nelse:\r\nbuffer=eh.allocEmuMem(entry_enc_size)\r\nmyStack = [0xffffffff, entry_idx, buffer]\r\neh.emulateRange(eh.analysisHelper.getNameAddr(DECRYPT_FN), stack = myStack, skipCalls=False)\r\nThe resulting decrypted data will be present in the EAX register if it’s four bytes or less, or in the allocated buffer if larger.\r\nAfter our analysis of the samples found in the wild, we found the following types of configuration entries:\r\nMalware configuration index.\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 6 of 13\n\nUAC bypass technique\r\nTo execute its main objective of encrypting as many files from the victim machine as possible, a ransomware needs to be\r\nexecuted with elevated privileges so it can access all files on disk as well as disable important system services which may\r\nhinder its objective. Elevating process privileges usually causes a warning to be displayed to the user and may prevent the\r\nmalware from running. To bypass that message, many malicious programs use an UAC bypass or exploits to elevate its own\r\nprocess privileges.\r\n The Phobos binary contains code that performs UAC bypass using a vulnerability in the .Net Profiler DLL loading process\r\nwhile executing “compmgmt.msc”. This technique has been documented since at least 2017 but still works in the latest\r\nversion of Windows 10.\r\nNote: Even though the malware contains code to bypass UAC and the exploit works when executed, this only happens once\r\nwe force the execution to follow that specific code branch and is not being actively used by the malware. The code path\r\nleading to this specific function seems to be reachable only when specific parameters are present in the malware\r\nconfiguration. Since Phobos is generally distributed along other malware and only after the actors are able to extract all the\r\ninformation they need, it’s possible the UAC code is not used because it’s not needed at the point in time the actors decide to\r\nencrypt the files.\r\nIn this method, a DLL is dropped to a user-writable folder and the environment variables are modified to make the .Net\r\nprofiler load the file even in elevated processes. In the case of Phobos, the configuration file stores a small 2KB DLL file\r\nthat only contains code to create a new process with the malicious binary. Both 32- and 64-bit files are embedded in the\r\nconfiguration.\r\nCode used to start the malicious binary from the elevated process.\r\nThe DLL is written to the %TEMP% folder using the machine serial number as its name like this:\r\nC:\\Users\\User\\AppData\\Local\\Temp\\1E41F172. \r\nThe DLLs embedded in the configuration data do not represent a complete PE, containing only the data up to the import\r\ntable present right after the “CALL [EAX]” shown above. The PE file is extracted from the configuration and fixed in\r\nmemory before it is written to disk. The path to the malware binary is written to the file right after the import table, and will\r\nbe used by the code as one of the parameters to “CreateProcessW”. The section is then finalized until the section alignment\r\nwith the bytes 0xBAADF00D:\r\nA comparative view of the 64-bit sample before and after being fixed in memory. The PE file in the\r\nconfiguration ends right after the import table.\r\nThe code will then call ShCreateItemFromParsingName using “Elevation:Administrator!new:{3ad05575-8857-4850-9277-\r\n11b85bdb8e09}” as a parameter in order to create an elevated shell object which will later be used to initialize the .Net\r\nenvironment before executing the Computer Management tool via mmc.exe.\r\nOnce the exploit is successful, a new instance of the malware binary is started with high privileges: \r\nProcess information showing the new process with high integrity and fully elevated privileges.\r\nThe process tree is also worth noting, as it is not typical to have MMC.EXE starting unknown binaries, as shown in the\r\nexample below:\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 7 of 13\n\nProcess tree shows the ransomware process started from mmc.exe.\r\nPhobos’ hidden debug file feature\r\nOne of Phobos’ hidden abilities we found in the configuration data is support for a debug file which can be used to enable\r\nadditional features in the binary. At the beginning of the code, Phobos checks for the presence of a file name at index 0x43\r\nin the configuration. If the setting is present, it will then check if the file exists in the same folder and if it contains valid\r\narguments:\r\nPhobos checking for the presence of debug file.\r\nIf the debug file exists, Phobos will parse each line to see if they contain valid commands and will create a structure\r\ncontaining the flags and string parameters found after the commands. In the 8Base campaign, the name of this file is\r\n“suppo” but other groups use different names for the debug file or don’t have one set up at all.\r\nBased on our code analysis, the following commands are available for debugging:\r\n‘C’ or ‘c’: Shows a console to print debug strings.\r\n‘L’:  Outputs a log file name. This name will be prefixed by \"e-\" to indicate the process is running elevated. For a\r\ntypical process tree with a low privilege malware running an elevated process, two files will be created: “filename”\r\nand “e-filename”.\r\n‘M’ or ‘m’: Does not run the encryption loop. This option disables the malicious actions and causes the malware to\r\njump to the end of the code.\r\n‘n’: Sets a flag in the buffer.\r\n‘e’: Accepts a string of values separated by ';' and stores a pointer to the data in the buffer structure.\r\n‘s’: Sets a flag in the buffer.\r\n‘x’: Sets a flag in the buffer.\r\nWhile some of these commands can be derived from analysis of the code, Talos never found an actual sample of these debug\r\nfiles to compare with our analysis, so some of the commands are not yet completely understood. \r\nWhen the options for showing the console are present in the debug file, this is what is output by the malware during typical\r\nexecution:\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 8 of 13\n\nDebug console and log files created by Phobos debug file setting.\r\nIn the example above, we have enabled the Console display (command ‘c’) and log file (command ‘L’) and we can see the\r\nmessages printed to the console. It shows the victim identification (the string “[1E41F172-3483]”) as well as the build\r\nnumber “v2.9.1”. All the strings shown in the output are also present as settings in the configuration, which indicates these\r\nmessages can be customized by the threat actors behind each campaign.\r\nPhobos’ infection reporting capabilities\r\nWhile Phobos does not typically demonstrate reporting a new infection to the attacker, our analysis indicates the capability\r\nto do so is present in the code, hidden behind a configuration setting which enables this feature and the creation of a custom\r\nURL and message chosen by the attacker.\r\nThe configuration setting with index “0x31” is a flag used throughout the code to check if various features are enabled or\r\nnot. If the reporting capability is enabled, the malware will attempt to extract the server name, URI path and custom\r\nmessage from indexes 0x44, 0x45 and 0x46 respectively:\r\nPhobos code checking if the reporting URL is present in the configuration.\r\nIf these options are present, the malware will then attempt to communicate an alert of the infection back to the specified\r\nserver. The custom message mentioned above is a string parameter which may contain the tag “\u003c\u003cID\u003e\u003e” in its body. This\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 9 of 13\n\ntag will then be replaced by the victim ID before submitting the request. As shown in the example below, the original\r\nmessage extracted from the binary still has the tag and the parsed message with the victim ID is passed as parameter to the\r\nHTTP Post function:\r\nExcerpt of code showing the parameters to the HTTP POST request after parsing the ID.\r\nThe request is sent with almost no headers, as seen in this example:\r\nPOST request sent back to attacker if enabled in the configuration.\r\nIt is worth noting, however, Talos has not seen any threat actor use this feature in any sample analyzed thus far.\r\nAnalysis of code changes in Phobos binaries over time\r\nSince 8Base group is known to operate with characteristics similar to previous Phobos campaigns, we compared the code in\r\nan 8Base sample with previous Phobos variants and determined there are no differences between the code at the binary level\r\nat all. As we mentioned above, this 8Base sample,\r\n32a674b59c3f9a45efde48368b4de7e0e76c19e06b2f18afb6638d1a080b2eb3, was extracted from a SmokeLoader binary\r\ndeployed in a recent 8Base campaign seen between June and August 2023. \r\nIn their February 2023 post about brute-forcing Phobos encryption, the Computer Emergency Response Team from Poland\r\n(Cert-PL) looked at sample 2704e269fb5cf9a02070a0ea07d82dc9d87f2cb95e60cb71d6c6d38b01869f66 which was first\r\nobserved in VirusTotal in 2020. Their observations about how the encryption works had many similarities with the 8Base\r\nsample we analyzed, and our analysis revealed that there were no changes in the code at all, with 100% carryover of\r\nsamples’ functions and basic blocks.\r\nThe only thing that changes between these two binaries is the configuration data in the last PE section:\r\n8Base\r\nConfiguration\r\nEntries\r\n64\r\nEncryption\r\nkey\r\n0xea73000e61c749e5287a2407e44c8679\r\nFile\r\nextension\r\n(IDX 0x4)\r\n.id[\u003c\u003e-3483].[support@rexsdata.pro].8base\r\nDebug file\r\n(IDX 0x43)\r\nsuppo\r\nExtension\r\nBlocklist\r\n(IDX 0x7)\r\n8base;actin;DIKE;Acton;actor;Acuff;FILE;Acuna;fullz;MMXXII;6y8dghklp;SHTORM;NURRI;GHOST;FF6OM6;MNX;BACKJOH\r\nSTARS;faust;unknown;STEEL;worry;WIN;duck;fopra;unique;acute;adage;make;Adair;MLF;magic;Adame;banhu;banjo;Banks;Banta\r\nThe same holds true for other samples found since 2020. The differences in code start to appear when we compare the 8Base\r\nsample with Phobos variants created in 2019. We analyzed the sample\r\nfc4b14250db7f66107820ecc56026e6be3e8e0eb2d428719156cf1c53ae139c6 first seen in VirusTotal in August 2019. The\r\ncurrent 8Base sample shares 89.6% of its code with the 2019 sample, according to our analysis.\r\nThere are several functions present in the current 8Base sample that did not exist in 2019:\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 10 of 13\n\nList of functions present in 8Base sample but not in the 2019 sample.\r\nThere is now support for debug files and infection report capabilities, which are not present in the old samples. This implies\r\nthese features were added to Phobos source code at some point in 2019 or 2020, likely the last time the Phobos source code\r\nwas updated.\r\nAnother sample that caught our attention was first described by Malwarebytes in 2019. The sample,\r\na91491f45b851a07f91ba5a200967921bf796d38677786de51a4a8fe5ddeafd2, was first observed in the wild in May 2019.\r\nThis sample is considerably different from other samples from the same time frame, only sharing 47.2% of their code.\r\n8base sample compared to 2019 sample from Malwarebytes blog.\r\nThe main difference we observed in this sample is the usage of Windows Crypto API instead of the custom cryptographic\r\ncode from recent samples. Looking at the functions present in the 2019 sample, we can see the Crypto API imported by this\r\nsample:\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 11 of 13\n\nList of imported functions from 2019 sample analyzed by Malwarebytes.\r\nWe observed these APIs being used in some critical functions throughout the code. The code block below is related to the\r\nencryption/decryption function in 8Base, which uses the custom cryptographic library, versus the code in the 2019 sample\r\nwhich uses Windows Crypto API\r\nFile encryption function comparison between 8Base and old 2019 Phobos sample.\r\nThere are similar differences in the function used to decrypt the configuration file, which behaves in a related fashion but\r\nusing different cryptographic APIs.\r\nThese changes observed in early samples support the assumption that Phobos went through a development phase in 2019 but\r\nhas remained unchanged since then.\r\nIn our second post titled \"Understanding the Phobos affiliate structure and activity \", we will have additional information on\r\nthe data we found in the blocklist extensions and how this is mapped to different actor groups, as well as the behavior of\r\nsuch groups once they get into a victim’s network.\r\nCoverage\r\nCisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in\r\nthis post. Try Secure Endpoint for free here.\r\nCisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.\r\nCisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their\r\ncampaign. You can try Secure Email for free here.\r\nCisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense\r\nVirtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 12 of 13\n\nCisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure\r\nproducts.\r\nUmbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs,\r\nwhether users are on or off the corporate network. Sign up for a free trial of Umbrella here.\r\nCisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests\r\nsuspicious sites before users access them.\r\nAdditional protections with context to your specific environment and threat data are available from the Firewall\r\nManagement Center.\r\nCisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.\r\nClamAV detections are available for this threat:\r\nWin.Packed.Zusy\r\nWin.Ransomware.8base\r\nWin.Downloader.Generic\r\nWin.Ransomware.Ulise\r\nIOCs\r\nIndicators of Compromise associated with this threat can be found here.\r\nSource: https://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nhttps://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/\r\nPage 13 of 13\n\nsample with Phobos fc4b14250db7f66107820ecc56026e6be3e8e0eb2d428719156cf1c53ae139c6 variants created in 2019. We analyzed the sample first seen in VirusTotal in August 2019. The\ncurrent 8Base sample shares 89.6% of its code with the 2019 sample, according to our analysis.\nThere are several functions present in the current 8Base sample that did not exist in 2019:\n  Page 10 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.talosintelligence.com/deep-dive-into-phobos-ransomware/"
	],
	"report_names": [
		"deep-dive-into-phobos-ransomware"
	],
	"threat_actors": [
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434060,
	"ts_updated_at": 1775826787,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/579428ea3765a7f017f9d003e00369ff06d750d0.pdf",
		"text": "https://archive.orkl.eu/579428ea3765a7f017f9d003e00369ff06d750d0.txt",
		"img": "https://archive.orkl.eu/579428ea3765a7f017f9d003e00369ff06d750d0.jpg"
	}
}