{
	"id": "9a22680c-772d-480c-907a-bc315040ee88",
	"created_at": "2026-04-06T02:10:57.235708Z",
	"updated_at": "2026-04-10T03:21:59.793636Z",
	"deleted_at": null,
	"sha1_hash": "2e7ed5a7782528b36261a3e2fb75a38be2a43c8b",
	"title": "Hancitor. Evasive new waves, and how COM objects can use Cached Credentials for Proxy Authentication.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 403065,
	"plain_text": "Hancitor. Evasive new waves, and how COM objects can use\r\nCached Credentials for Proxy Authentication.\r\nBy dodgethissecurity_1ooun4\r\nPublished: 2019-11-01 · Archived: 2026-04-06 01:36:29 UTC\r\nWhile analyzing a new wave of Hancitor, I have determined that they have combined a variety of techniques\r\ntogether which greatly increases the effectiveness of the campaign.\r\nAccording to my research, they have leveraged an effective combination of Living off the Land Techniques in\r\norder to evade detection. WMI for indirect command execution and COM objects to download stage-two binaries\r\nin Proxy and Non-Proxy environments. Most security teams are not aware of the danger COM objects pose. My\r\nresearch partners and I have determined them to be very dangerous given the current state of EDR and EPP\r\nmonitoring. Not to mention, Windows COM object mitigation and proxy capabilities to minimize the use of\r\nCached Credentials.\r\nCOM Objects Use of Cached Credentials – Backstory of how/when this was discovered.\r\nThis was theorized by my research partners and I around a year ago. A few months later, one of my research\r\npartners figured out how to write the COM object code from a Sandbox Escaper function call that used to be\r\nlinked here. He rewrote it in C++, to specifically call Internet Explorer instead of “CLSID_ShellLink”.\r\nIn order to eliminate unrelated possibilities, we set up two boxes in our virtualized test environment to verify our\r\ntheories. One box was a Ubuntu 16.04 system setup with a range of free proxy tools/software. The second was a\r\nWindows 10 box that had NOT been authenticated with any web browsers or software during testing sessions.\r\nWe had configured the Windows 10 system to route all traffic through the Ubuntu Linux system via the proxy port\r\nwhich we setup to require Base64/Legacy Authentication. Once everything was finalized, my research partner\r\nexecuted his program that used COM object calls to initialize an instance of Internet Explorer and reach out to an\r\nexternal benign website “https://www.google.com”\r\nBase64/Legacy Authentication – Successful Internet Access via Cached Creds.\r\nTo our surprise, callouts through each tested proxy software with this authentication succeeded. We had not set up\r\nthe proxy within the POC program, so we didn’t expected cached credentials to work against this authentication\r\nmechanism or for the IE instance to callout successfully. Based on our assessment we theorized that Internet\r\nExplorer pulled the proxy settings automatically from Windows and the locally cached creds for the current user\r\nfrom the Windows Password Vault automatically.\r\nKerberos Authentication Successful – Internet Access via Cached Creds.\r\nWe reset the Windows 10 box and Ubuntu box back to their initial VM Snapshots from before the first phase of\r\ntesting. We reconfigured each of the proxy programs/services in Linux to now only accept Kerberos\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 1 of 8\n\nauthentication. We ran the sample again and it succeeded. Once again, we theorized that Internet Explorer pulled\r\nits proxy settings from Windows without explicit configuration in the calling program, and that it pulled the\r\ncached credentials from the local Windows Password Vault.\r\nNow onto the Hancitor Analysis:\r\nFirst off, lets show a quick chart of how these waves of Hancitor execute.\r\nFlow Chart – Overview of How Hancitor Executes\r\nHancitor – Stage 1 – Malspam, Download and Document Summary:\r\nA user receives a Hancitor infected email, this email directs them to download their “DHL Notification” from a\r\nmalicious link embedded in the email. When a user clicks the link, it sends them to a website which redirects them\r\nto another website that actually serves up the malicious file. Linux user agents from my testing resulted in a error\r\non the first link. Changing user agent to a Windows one resolved this.\r\nFilename Regular Expression: “dhl\\_[0-9]{1,6}\\.doc” is what I had observed from multiple downloads.\r\nOnce the word document is received and opened, it asks the user to enable Macros/editing to view the document.\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 2 of 8\n\nFake “Document is Protected” document content which directs the user to effectively enable\r\nMacros.\r\nThe user is then prompted to “Enter the document password to view it”\r\nFake document requires a password warning.\r\nThe small text chosen along with the non-normal font is likely to confuse image recognition based\r\nautomation.\r\nCurrently, this form is not tied to the macros. Based on observations, I do believe that it will likely move toward\r\nmacro execution and the user will be required to enter something to enable it. This would be an effective Anti-sandbox feature in the short term, as Sandbox providers would have to play catch-up in order to adjust to this new\r\ndata automation.\r\nHancitor Stage 1 – Macro Execution:\r\nHancitor in this case has two functions that are named similarly to one another. The first is the Function\r\n“AutoOPeN()” which calls and attempts to run the malicious code in the function “hEXXhG”. The second, is the\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 3 of 8\n\nfunction “Auto_OPeN()”. It calls “AutoOPeN()” again, if the attempt to run the malicious code failed for some\r\nreason. This sets up an infinite loop between the two functions. I believe this is done to give the document the\r\nhighest chance of infection success.\r\nThis is the Function that calls the malicious code in the function named “hEXXhG”\r\nThis is the fallback function that attempts to be called if the first AutoOpen execution failed.\r\nThe malicious function “hEXXhG” first executes code (see below), which uses a COM object call to spawn an\r\nInternet Explorer window that is hidden from the users view. Due to the nature of how COM objects work, most\r\nEDR and EPP solutions will not see that the source document was responsible for the followup activity in IE.\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 4 of 8\n\nHancitor Stage 1 – Download of Stage 2 via COM called Internet Explorer\r\nNotice from the screenshots above that Hancitor is also calling COM objects to create an Internet Explorer\r\ninstance. This is similar to the research and POC testing that my research partners and I tested/analyzed nearly six\r\nmonths ago. This IE instance should also be theoretically proxy aware and use cached credentials in a similar\r\nfashion as well. The stage two download link is passed to IE, then an attempt to download the malicious file is\r\nmade. This is looped until it succeeds or the document is closed.\r\nHancitor Stage 1/2 – COM calls to evasive file saving functions. (Part 1)\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 5 of 8\n\nIn the screenshot above, the macro saves the returned web page content to a variable named “txBJBGa”. In this\r\ncase, this is the stage two payload (the actual hancitor binary/downloader). After this, it uses the Environ call to\r\nuse the environment variables and determine where the app data folder is located for the current user. It then\r\ncombines that path with the Microsoft Word Startup folder. The stage two payload is then saved as a .wll file\r\n(Word Addon file) to this directory. Using Joe Sandbox it was “C:\\Users\\Suzanne\r\nDavies\\AppData\\Roaming\\Microsoft\\Word\\Startup\\651F.wll”.\r\nThe file name is randomized at the time of it being saved to disk. In all cases the stage two appeared to be named\r\nwith a random number of 000-999 followed by the letter F and the extension. If Microsoft Word is opened while\r\nthis file is still in this path/location it warns that a add-on file failed to load properly.\r\nHancitor Stage 1/2 – COM calls to evasive file saving functions.(Part 2)\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 6 of 8\n\nThe contents of “txBJBGa” from earlier is then written to this fake word addon file. The writing of the file to disk\r\nis then closed.\r\nHancitor Stage 2 – COM object reference to WMI created, which calls the LOLBIN “regsvr32.exe”:\r\nBased on the documentation of the GetObject function in VB, COM is used to either load or create a reference to\r\nan application, in this case WMI. This WMI call in the above code then creates the process “regsvr32.exe -s file”\r\nto execute the stage two downloader which was written to disk earlier. This is three layers of evasion techniques\r\njust to reach the point of code execution. This proves that they have detailed knowledge of COM, WMI, and\r\nresearch into LOLBINS. Finally, after successful execution of the Hancitor downloader telling a user to “Enter a\r\npassword to access the protected document”, you can see the Macro code at the end.\r\nWhat does this all mean?\r\nCompanies, individuals, etc. will no longer be able to assume that stage two downloads will likely fail for a broad\r\nrange of malware. Or that stage one and two C2 callouts will fail due to proxy servers.\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 7 of 8\n\nPrediction on Future COM Developments + Personal Theories:\r\n1. Use of COM objects for persistence, execution, downloads, exfiltration, lateral movement, etc. is likely to\r\nincrease in the future.\r\n2. I believe that it is likely possible (if not already being abused) for cached credentials to be used to laterally\r\nmove via COM object calls to SMB, RDP, WMI, etc to other systems within a network.\r\n3. EDR, EPP, and OS vendors will be forced to add COM visibility, mitigation’s and preventative\r\nfunctionality as awareness of this threat drives customer pressure and demand for solutions.\r\n4. Based on information found regarding COM objects even from the Vault 7 breach it is likely that\r\nIntelligence Agencies (Nation States) utilize COM objects (and likely have for possibly up to the last\r\ndecade). Visibility into COM objects may lead to discovery of some of these operations.\r\nIOCs:\r\nPlease use the pastebin post from @James_inthe_box which I have linked here to see the IOCs.\r\nSource: https://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-pro\r\nxy-authentication/\r\nhttps://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.dodgethissecurity.com/2019/11/01/hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication/"
	],
	"report_names": [
		"hancitor-evasive-new-waves-and-how-com-objects-can-use-cached-credentials-for-proxy-authentication"
	],
	"threat_actors": [],
	"ts_created_at": 1775441457,
	"ts_updated_at": 1775791319,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2e7ed5a7782528b36261a3e2fb75a38be2a43c8b.pdf",
		"text": "https://archive.orkl.eu/2e7ed5a7782528b36261a3e2fb75a38be2a43c8b.txt",
		"img": "https://archive.orkl.eu/2e7ed5a7782528b36261a3e2fb75a38be2a43c8b.jpg"
	}
}