{ "id": "207851c2-6408-4825-9956-ed213681cc16", "created_at": "2026-04-06T00:08:35.645437Z", "updated_at": "2026-04-10T13:12:16.322102Z", "deleted_at": null, "sha1_hash": "e843178554f1cd0b20ea2b11d27cc3969199d934", "title": "Technical Walkthrough: Office Test Persistence Method Used In Recent Sofacy Attacks", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1052127, "plain_text": "Technical Walkthrough: Office Test Persistence Method Used In\r\nRecent Sofacy Attacks\r\nBy Robert Falcone\r\nPublished: 2016-07-20 · Archived: 2026-04-05 19:19:46 UTC\r\nAs mentioned in our previous blog, we observed the Sofacy group using a new persistence mechanism that we call\r\n“Office Test” to load their Trojan each time the user opened Microsoft Office applications. Following the report,\r\nwe received several questions regarding this persistence method, specifically how it works and which versions of\r\nMicrosoft Office were affected. This blog will serve as a technical analysis of this persistence method that security\r\nprofessionals and network defenders can use for awareness, as we believe it is likely additional threat groups will\r\nbegin using this technique.\r\nWe have added a malicious behavior tag named OfficeDllSideloading to AutoFocus for Palo Alto Networks\r\ncustomers to track the usage of this persistence method.\r\nOffice Test Backstory\r\nDuring our analysis of the delivery document used by the Sofacy group in recent targeted attacks, we saw the\r\ndocument create the following registry key:\r\nHKEY_CURRENT_USER\\Software\\Microsoft\\Office test\\Special\\Perf\r\nBased on our analysis, adding a path to a DLL to this registry key would load the DLL each time a Microsoft\r\nOffice application was opened. We had not seen this registry key used for persistence before, so we looked into\r\nhow this registry key results in the execution of a malicious payload. We checked a clean system with Microsoft\r\nOffice installed, and confirmed that it did not have the key in the registry, as seen in Figure 1.\r\nFigure 1 Windows Registry does not have the \"Office Test\" key by default with Microsoft Office Installation\r\nWe checked our WildFire data and found only a handful of samples using this registry key for persistence, all of\r\nwhich were used to load the Carberp variant of Sofacy. At the time, we thought the Sofacy group had discovered a\r\nnew persistence technique, but to our surprise, Hexacorn had revealed this registry key in an April 2014 blog post.\r\nThis suggests that the Sofacy group may not have discovered this persistence technique themselves, and as threat\r\nactors often do, absorbed an existing technique into their playbook.\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 1 of 9\n\nDLL Loading Process\r\nTo determine how this registry key executed the malicious DLL, we analyzed activities that occur when the user\r\nopens the Microsoft Word application. We chose to analyze Word because we knew from our research on the\r\nSofacy attacks that Word loaded the Trojan’s malicious DLL; however, other Microsoft Office applications were\r\nalso discovered to be susceptible to this persistence method, which we will elaborate on in the next section.\r\nFigure 2 below shows the API function calls during the startup process that are related to the registry key. The API\r\ncalls show Word (WINWORD.EXE) loading “wwlib.dll”, which is a legitimate library loaded by Word at runtime.\r\nThe “wwlib.dll” library opens the registry key in question, queries its default value (NULL in Figure 2) and then\r\nloads the malicious DLL (“btecache.dll”) stored within this key using LoadLibraryW.\r\nFigure 2 API functions called by Word that Loads Malicious DLL\r\nThe last activity seen by “wwlib.dll” in Figure 2 involves an attempt to open a handle to the same registry key\r\nwithin the HKEY_LOCAL_MACHINE hive, as follows:\r\nHKEY_LOCAL_MACHINE\\Software\\Microsoft\\Office test\\Special\\Perf\r\nThe attempt to open this key fails because the key does not exist with a default installation of Microsoft Office. In\r\naddition, using this registry key for persistence purposes is not ideal because the actor would need elevated\r\nprivileges to modify registry keys in the HKLM hive. Instead, the threat actors created the “Office Test” registry\r\nkey in the HKCU hive, which only requires the current account privileges to modify the key with a path to a\r\nmalicious DLL.\r\nIn the Sofacy attacks, the actors added its loader Trojan named “btecache.dll” (Figure 2) to the “Office Test”\r\nregistry key. The loader Trojan locates and loads a second DLL from “C:\\ProgramData\\svchost.dll” into Word, as\r\nseen in Figure 3 and exits. The “svchost.dll” contains the functional code of the Carberp variant of the Sofacy\r\nTrojan, which remains running in Word until the user closes the application.\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 2 of 9\n\nFigure 3 The payload \"svchost.dll\" running within Microsoft Word\r\nPurpose of the Office Test Key\r\nBased on the activities in the startup process, we saw the legitimate “wwlib.dll” library loading the malicious DLL\r\nfrom the registry key. We wanted to know why “wwlib.dll” would load a DLL from a key that was not added to\r\nthe registry during the installation of Microsoft Office. Static analysis of “wwlib.dll” revealed that the DLL loads\r\nthe library from the registry key, then attempts to resolve and call an API function named\r\n“_GetPerfhostHookVersion@0” from the loaded library, as seen in Figure 4.\r\nFigure 4 Code within wwlib.dll that loads a DLL from the registry and attempts to resolve and call\r\n_GetPerfhostHookVersion@0\r\nWhen “wwlib.dll” uses the LoadLibraryW function to load the DLL from the registry key, it runs the\r\nDllEntryPoint exported function in the DLL. In the case of Sofacy’s “btecache.dll”, the DllEntryPoint function\r\nlocates the second DLL called “svchost.dll”, loads and runs its functional code. The “btecache.dll” file does not\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 3 of 9\n\ncontain an exported function named “_GetPerfhostHookVersion@0”, but this does not matter as the code in\r\nFigure 4 would fail to resolve the API function but would continue executing without calling the API.\r\nIn addition to “_GetPerfhostHookVersion@0”, the “wwlib.dll” library also attempts to resolve several additional\r\nexported functions from the DLL loaded from the registry, specifically with names that contain the following:\r\n_InitPerf\r\n_PerfCodeMarker\r\n_UnInitPerf\r\nIt appears that Word (and other Microsoft Office applications) use this registry key to load DLLs in order to\r\nconduct performance evaluations and other debugging tasks during development or testing phases of the\r\napplications. This would explain the reason why the “Software\\Microsoft\\Office test\\Special\\Perf” registry keys\r\nare not created during the installation of Microsoft Office.\r\nWe also discovered that the library will attempt to load a DLL from the following registry key in the\r\nHKEY_LOCAL_MACHINE hive, whose key name “RuntimePerfMeasurement” further suggests that “wwlib.dll”\r\nuses these registry keys for performance testing and debugging purposes:\r\nHKEY_LOCAL_MACHINE\\Software\\Microsoft\\Office test\\Special\\Perf\\RuntimePerfMeasurement\r\nSusceptible Applications and Versions\r\nTo see which versions of Word were susceptible to this persistence mechanism, we checked “wwlib.dll” in the\r\nfollowing Word versions: 2003, 2007, 2010, 2013, 2015 and 2016. We were able to confirm “wwlib.dll” from\r\nOffice 2007, 2010, 2013, 2015 and 2016 would load a DLL from the “Office Test” registry key discussed in this\r\nblog. Office 2003 would not load a DLL from this registry key and it did not have a “wwlib.dll” file.\r\nWe also tested other Microsoft Office applications to see which would load a DLL from the “Office Test” registry\r\nkey, which includes Word, Powerpoint, Excel, Outlook, OneNote and Publisher. It is interesting to note, that some\r\napplications in the Office suite do not need to call another DLL to load the malicious payload via the registry\r\npersistence mechanism (such as Word using wwlib.dll) and instead will load the malicious payload directly from\r\nthe application. Figure 5 shows a graphical representation of applications loading the payload directly from the\r\nexecutable versus using a separate DLL file.\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 4 of 9\n\nFigure 5 Office Test workflow\r\nSimple Protection\r\nDuring our research, we found that the \"Office Test\" persistence technique could be easily defeated by manually\r\ncreating the registry key “HKCU\\Software\\Microsoft\\Office test” and removing the current user’s account write\r\npermissions for this key. Microsoft Office does not require this registry key to operate and does not even create the\r\nregistry key during installation; therefore, adding this key as read-only will have no effect on the usability of\r\nMicrosoft Office applications. The steps taken to defeat the “Office Test” persistence mechanism will be outlined\r\nbelow and could also be easily scripted or pushed to systems via group policy.\r\nDisclaimer: Modifying the registry can cause serious problems that may require you to reinstall your operating\r\nsystem. We cannot guarantee that problems resulting from the incorrect use of the registry can be solved. Use the\r\ninformation provided at your own risk.\r\nFirst, we created the \"HKCU\\Software\\Microsoft\\Office test\" via the “reg” command. Open a command prompt\r\n(cmd.exe) and input the following:\r\nreg add \"HKCU\\Software\\Microsoft\\Office test\"\r\nFigure 6 The \"reg\" command used to create the \"Office test\" registry key\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 5 of 9\n\nWe then navigated to the newly created registry key using the “regedit” application. By right clicking on the key,\r\nwe can access the permissions associated with the key, as seen in Figure 7.\r\nFigure 7 Right clicking key allows access to permissions\r\nThe current user has “Full Control” permissions for this registry key, as seen in Figure 8. This permission allows\r\nan actor to write the path to the Trojan to the “Special\\Perf” sub-key. The “Read” control in Figure 8 allows\r\nMicrosoft Office to read the contents of this key and its sub-keys, which is how the actor leverages this technique\r\nto load a malicious DLL into Office applications. To defeat this persistence mechanism, we can remove the current\r\nuser’s write permissions to this key by clicking the “Advanced” button.\r\nFigure 8 Current user's default permissions to the \"Office test\" registry key\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 6 of 9\n\nThe current user was granted “Full Control” permissions to this registry key because it inherited permissions from\r\nits parent object, which ultimately inherited its permissions from the HKEY_CURRENT_USER hive. To remove\r\nthe user’s write permissions to this registry key, we first must remove the inherited permissions by unchecking the\r\nbox seen in Figure 9.\r\nFigure 9 Remove inherited permissions by unchecking this box\r\nBy unchecking the box in Figure 9, the dialog box in Figure 10 pops up, which provides options for “Remove” to\r\nremove all permissions from this key or “Add” to set specific permissions for the user.\r\nFigure 10 Dialog box displayed after removing the registry key's inherited permissions\r\nHere we will click “Add”, select the current user, then press the “Edit” button to set specific permissions for this\r\nuser. In the next dialog, click the “Clear All” button first to remove all existing permissions then select only “Read\r\nControl”, as seen in Figure 11.\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 7 of 9\n\nFigure 11 Read-only permissions assigned to this key\r\nWith the “Read Control” permission, Microsoft Office products are still able to read from this registry key, but\r\nmalicious documents will not be able to write to this key. We tested this simple registry modification against the\r\ndelivery document used by Sofacy discussed in our previous blog and discovered that while the delivery\r\ndocument was still able to exploit our analysis system, the payload would not be able to run when the user opened\r\nMicrosoft Office applications, thus creating a benign infection.\r\nAutoruns Detecting Office Test\r\nUnit 42 reached out to notify Microsoft of the Office Test persistence mechanism and its use by a threat group in\r\ntargeted attacks. On July 4, 2016, Microsoft released a new version of Autoruns, specifically v13.52 that includes\r\nchecks for the Office Test registry keys. We downloaded Autoruns v13.52 and tested both the GUI (Autoruns.exe)\r\nand CLI (autorunsc.exe) versions of the tool on a system compromised with the Sofacy tool that used this\r\npersistence technique. Figure 12 and Figure 13 below show the two Autoruns tools detecting the use of this\r\nregistry key for persistence.\r\nFigure 12 GUI version of Autoruns detecting Office Test persistence mechanism\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 8 of 9\n\nFigure 13 Autorunsc detecting the Office Test persistence mechanism\r\nConclusion\r\nThe \"Office Test\" persistence mechanism allows threat actors to execute a Trojan each time a user runs any of the\r\nOffice applications. This persistence mechanism loads a malicious DLL by leveraging a registry key that appears\r\nto be used during the development and testing of Microsoft Office applications. The use of this registry key for\r\npersistence is quite clever, as it requires user interaction to load and execute the malicious payload, which makes\r\nautomated analysis in sandboxes challenging. Low awareness of this persistence method, coupled with the\r\nsandbox evasion obtained from user interactions, makes this a potentially attractive persistence method that we\r\nbelieve may be used in future attacks. Unit 42 suggests monitoring for systems that have this registry key already\r\ncreated, as it is possible a threat is already using the key for persistence purposes. Microsoft has added the “Office\r\nTest” registry keys to its Autoruns tool for detection purposes as well. Also, we suggest disabling this persistence\r\nmethod by creating the “Office test” registry key in read-only mode as outlined in this blog.\r\nSource: https://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofa\r\ncy-attacks/\r\nhttps://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://researchcenter.paloaltonetworks.com/2016/07/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/" ], "report_names": [ "unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks" ], "threat_actors": [ { "id": "730dfa6e-572d-473c-9267-ea1597d1a42b", "created_at": "2023-01-06T13:46:38.389985Z", "updated_at": "2026-04-10T02:00:02.954105Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "Pawn Storm", "ATK5", "Fighting Ursa", "Blue Athena", "TA422", "T-APT-12", "APT-C-20", "UAC-0001", "IRON TWILIGHT", "SIG40", "UAC-0028", "Sofacy", "BlueDelta", "Fancy Bear", "GruesomeLarch", "Group 74", "ITG05", "FROZENLAKE", "Forest Blizzard", "FANCY BEAR", "Sednit", "SNAKEMACKEREL", "Tsar Team", "TG-4127", "STRONTIUM", "Grizzly Steppe", "G0007" ], "source_name": "MISPGALAXY:APT28", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e3767160-695d-4360-8b2e-d5274db3f7cd", "created_at": "2022-10-25T16:47:55.914348Z", "updated_at": "2026-04-10T02:00:03.610018Z", "deleted_at": null, "main_name": "IRON TWILIGHT", "aliases": [ "APT28 ", "ATK5 ", "Blue Athena ", "BlueDelta ", "FROZENLAKE ", "Fancy Bear ", "Fighting Ursa ", "Forest Blizzard ", "GRAPHITE ", "Group 74 ", "PawnStorm ", "STRONTIUM ", "Sednit ", "Snakemackerel ", "Sofacy ", "TA422 ", "TG-4127 ", "Tsar Team ", "UAC-0001 " ], "source_name": "Secureworks:IRON TWILIGHT", "tools": [ "Downdelph", "EVILTOSS", "SEDUPLOADER", "SHARPFRONT" ], "source_id": "Secureworks", "reports": null }, { "id": "ae320ed7-9a63-42ed-944b-44ada7313495", "created_at": "2022-10-25T15:50:23.671663Z", "updated_at": "2026-04-10T02:00:05.283292Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "APT28", "IRON TWILIGHT", "SNAKEMACKEREL", "Group 74", "Sednit", "Sofacy", "Pawn Storm", "Fancy Bear", "STRONTIUM", "Tsar Team", "Threat Group-4127", "TG-4127", "Forest Blizzard", "FROZENLAKE", "GruesomeLarch" ], "source_name": "MITRE:APT28", "tools": [ "Wevtutil", "certutil", "Forfiles", "DealersChoice", "Mimikatz", "ADVSTORESHELL", "Komplex", "HIDEDRV", "JHUHUGIT", "Koadic", "Winexe", "cipher.exe", "XTunnel", "Drovorub", "CORESHELL", "OLDBAIT", "Downdelph", "XAgentOSX", "USBStealer", "Zebrocy", "reGeorg", "Fysbis", "LoJax" ], "source_id": "MITRE", "reports": null }, { "id": "d2516b8e-e74f-490d-8a15-43ad6763c7ab", "created_at": "2022-10-25T16:07:24.212584Z", "updated_at": "2026-04-10T02:00:04.900038Z", "deleted_at": null, "main_name": "Sofacy", "aliases": [ "APT 28", "ATK 5", "Blue Athena", "BlueDelta", "FROZENLAKE", "Fancy Bear", "Fighting Ursa", "Forest Blizzard", "G0007", "Grey-Cloud", "Grizzly Steppe", "Group 74", "GruesomeLarch", "ITG05", "Iron Twilight", "Operation DealersChoice", "Operation Dear Joohn", "Operation Komplex", "Operation Pawn Storm", "Operation RoundPress", "Operation Russian Doll", "Operation Steal-It", "Pawn Storm", "SIG40", "Sednit", "Snakemackerel", "Sofacy", "Strontium", "T-APT-12", "TA422", "TAG-0700", "TAG-110", "TG-4127", "Tsar Team", "UAC-0028", "UAC-0063" ], "source_name": "ETDA:Sofacy", "tools": [ "ADVSTORESHELL", "AZZY", "Backdoor.SofacyX", "CHERRYSPY", "CORESHELL", "Carberp", "Computrace", "DealersChoice", "Delphacy", "Downdelph", "Downrage", "Drovorub", "EVILTOSS", "Foozer", "GAMEFISH", "GooseEgg", "Graphite", "HATVIBE", "HIDEDRV", "Headlace", "Impacket", "JHUHUGIT", "JKEYSKW", "Koadic", "Komplex", "LOLBAS", "LOLBins", "Living off the Land", "LoJack", "LoJax", "MASEPIE", "Mimikatz", "NETUI", "Nimcy", "OCEANMAP", "OLDBAIT", "PocoDown", "PocoDownloader", "Popr-d30", "ProcDump", "PythocyDbg", "SMBExec", "SOURFACE", "SPLM", "STEELHOOK", "Sasfis", "Sedkit", "Sednit", "Sedreco", "Seduploader", "Shunnael", "SkinnyBoy", "Sofacy", "SofacyCarberp", "SpiderLabs Responder", "Trojan.Shunnael", "Trojan.Sofacy", "USB Stealer", "USBStealer", "VPNFilter", "Win32/USBStealer", "WinIDS", "Winexe", "X-Agent", "X-Tunnel", "XAPS", "XTunnel", "Xagent", "Zebrocy", "Zekapab", "carberplike", "certutil", "certutil.exe", "fysbis", "webhp" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434115, "ts_updated_at": 1775826736, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e843178554f1cd0b20ea2b11d27cc3969199d934.pdf", "text": "https://archive.orkl.eu/e843178554f1cd0b20ea2b11d27cc3969199d934.txt", "img": "https://archive.orkl.eu/e843178554f1cd0b20ea2b11d27cc3969199d934.jpg" } }