{
	"id": "8f237088-3b67-4f9c-8a16-1db74b2df67c",
	"created_at": "2026-04-06T00:17:09.079423Z",
	"updated_at": "2026-04-10T03:26:22.075686Z",
	"deleted_at": null,
	"sha1_hash": "13017fa68d002c79ec20071c4e7cdfe7fb61cbb1",
	"title": "Epic Manchego – atypical maldoc delivery brings flurry of infostealers",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1573776,
	"plain_text": "Epic Manchego – atypical maldoc delivery brings flurry of\r\ninfostealers\r\nBy NVISO\r\nPublished: 2020-09-01 · Archived: 2026-04-05 18:11:21 UTC\r\nIn July 2020, NVISO detected a set of malicious Excel documents, also known as “maldocs”, that deliver malware\r\nthrough VBA-activated spreadsheets. While the malicious VBA code and the dropped payloads were something\r\nwe had seen before, it was the specific way in which the Excel documents themselves were created that caught our\r\nattention.\r\nThe creators of the malicious Excel documents used a technique that allows them to create macro-laden Excel\r\nworkbooks, without actually using Microsoft Office. As a side effect of this particular way of working, the\r\ndetection rate for these documents is typically lower than for standard maldocs.\r\nThis blog post provides an overview of how these malicious documents came to be. In addition, it briefly\r\ndescribes the observed payloads and finally closes with recommendations as well as indicators of compromise to\r\nhelp defend your organization from such attacks.\r\nKey Findings (TL;DR)\r\nThe malicious Microsoft Office documents are created using the EPPlus software rather than Microsoft\r\nOffice Excel, these documents may fly under the radar as it differs from a typical Excel document;\r\nNVISO assesses with medium confidence that this campaign is delivered by a single threat actor based on\r\nthe limited number of documents uploaded to services such as VirusTotal, and the similarities in payloads\r\ndelivery throughout this campaign;\r\nThe payloads that have been observed up to the date of the release of this post, have been, for the most\r\npart, so called information stealers with the intention of harvesting passwords from browsers, email clients,\r\netc.;\r\nThe payloads stemming from these documents have evolved only slightly in terms of obfuscation and\r\nmasquerading. This is another indication of a single actor who is slowly evolving their technical prowess.\r\nAnalysis\r\nThe analysis section below is divided in two parts and refers to a specific link in the infection chain.\r\nMalicious document analysis\r\nIn an earlier blog post, we wrote about “VBA Purging”[1], which is a technique to remove compiled VBA code\r\nfrom VBA projects. We were interested to see if any malicious documents found in-the-wild were adopting this\r\ntechnique (it lowers the initial detection rate of antivirus products). This is how we stumbled upon a set of peculiar\r\nmalicious documents.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 1 of 19\n\nAt first, we thought they were created with Excel, and were then VBA purged. But closer examination leads us to\r\nbelieve that these documents are created with a .NET library that creates Office Open XML (OOXML)\r\nspreadsheets. As stated in our VBA Purging blog post, Office documents can also lack compiled VBA code when\r\nthey are created with tools that are totally independent from Microsoft Office. EPPlus is such a tool. We are\r\nfamiliar with this .NET library, as we have been using it since a couple of years to create malicious documents\r\n(“maldocs”) for our red team and penetration testers.\r\nWhen we noticed that the maldocs had no compiled code, and were also missing Office metadata, we quickly\r\nthought about EPPlus. This library also creates OOXML files without compiled VBA code and without Office\r\nmetadata.\r\nThe OOXML file format is an Open Packaging Conventions (OPC) format: a ZIP container with mainly XML\r\nfiles, and possibly binary files (like pictures). It was first introduced by Microsoft with the release of Office 2007.\r\nOOXML spreadsheets use extension .xlsx and .xlsm (for spreadsheets with macros).\r\nWhen a VBA project is created with EPPlus, it does not contain compiled VBA code. EPPlus has no methods to\r\ncreate compiled code: the algorithms to create compiled VBA code are proprietary to Microsoft.\r\nThe very first malicious document we detected was created on 22nd of June 2020, and since then 200+ malicious\r\ndocuments were found over a period of 2 months. The actor has increased their activity in the last weeks, as now\r\nwe see more than 10 new malicious documents on some days.\r\nFigure 1 – Unique maldocs observed per day\r\nThe maldocs discovered over the course of two months have many properties that are quite different from the\r\nproperties of documents created with Microsoft Office. We believe this is the case because they are created with a\r\ntool independent from Microsoft Excel. Although we don’t have a copy of the exact tool used by the threat actor\r\nto create these malicious documents, the malicious documents created by this tool have many properties that\r\nconvince us that they were created with the aforementioned EPPlus software.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 2 of 19\n\nSome of EPPlus’ properties include, but are not limited to:\r\nPowerful and versatile library: not only can it create spreadsheets containing a VBA project, but that\r\nproject can also be password protected and/or digitally signed. It does not rely on Microsoft Office. It can\r\nalso run on Mono (cross platform, open-source .NET).\r\nOOXML files created with EPPlus have some properties that distinguish them from OOXML files created\r\nwith Excel. Here is an overview:\r\nZIP Date: every file included in a ZIP file has a timestamp (DOSDATE and DOSTIME field in the\r\nZIPFILE record). For documents created (or edited) with Microsoft Office, this timestamp is always\r\n1980-01-01 00:00:00 (0x0021 for DOSDATE and 0x0000 for DOSTIME). OOXML files created\r\nwith EPPlus have a timestamp that corresponds to the creation time of the document. Usually, that\r\ntimestamp is the same for all files inside the OOXML files, but due to execution delays, there can\r\nbe a difference of 2 seconds between timestamp. 2 seconds is the resolution of the DOSTIME\r\nformat.\r\nFigure 2 – DOSTIME difference (left: EPPlus created file)\r\nExtra ZIP records: a typical ZIP file is composed of ZIP file records (magic 50 4B 03 04) with metadata for\r\nthe file, and the (compressed) file content. Then there are ZIP directory entries (magic 50 4B 01 02)\r\nfollowed by a ZIP end-of-directory record (magic 50 4B 05 06). Microsoft Office creates OOXML files\r\ncontaining these 3 ZIP record types. EPPlus creates OOXML files containing 4 ZIP records: it also\r\nincludes a ZIP data description record (magic 50 4B 07 08) after each ZIP file record.\r\nFigure 3 – Extra ZIP records (left: EPPlus created file)\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 3 of 19\n\nMissing Office document metadata: an OOXML document created with Microsoft Office contains\r\nmetadata (author, title, …). This metadata is stored inside XML files found inside the docProps folder. By\r\ndefault, documents created with EPPlus don’t have metadata: there is no docProps folder inside the ZIP\r\ncontainer.\r\nFigure 4 – Missing metadata (left: EPPlus created file)\r\nVBA Purged: OOXML files with a VBA project created with Microsoft Office contain an OLE file\r\n(vbaProject.bin) with streams containing the compiled VBA code and the compressed VBA source code.\r\nDocuments created with EPPlus do not contain compiled VBA code, only compressed VBA source code.\r\nThis means that:\r\nThe module streams only contain compressed VBA code\r\nThere are no SRP streams (SRP streams contain implementation-specific and version-dependent\r\ncompile code, theire name starts with __SRP_)\r\nThe _VBA_PROJECT stream does not contain compiled VBA code. In fact, the content of the\r\n_VBA_PROJECT stream is hardcoded in the EPPlus source code: it’s always CC 61 FF FF 00 00\r\n00.\r\nFigure 5 – Hardcoded stream content (left: EPPlus created file)\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 4 of 19\n\nIn addition to the above, we have also observed some properties of the VBA source code that hints at the use of a\r\ncreation tool based on a library like EPPlus.\r\nThere are a couple of variants to the VBA source code used by the actor (some variants use PowerShell to\r\ndownload the payload, others use pure VBA code). But all these variants contain a call to a loader function with\r\none argument, a string with the URL (either BASE64 or hexadecimal encoded). Like this (hexadecimal example):\r\nLoader”68 74 74 70 …”\r\nDo note that there is no space character between the function name and the argument: there is no space between\r\nLoader and ”68 74 74 70 …”.\r\nThis is an indication that the VBA code was not entered through the VBA EDI in Office: when you type a\r\nstatement like this, without space character, the VBA EDI will automatically add a space character for you (even if\r\nyou copy/paste the code). The absence of this space character divulges that this code was not entered through the\r\nVBA EDI, but likely via a library such as EPPlus.\r\nTo illustrate these differences in properties, we show examples with one of our internal tools (ExcelVBA) using\r\nthe EPPlus library. We create a vba.xlsm file with the vba code in text file vba.txt using our tool ExcelVBA, and\r\nshow some of its properties.:\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 5 of 19\n\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 6 of 19\n\nFigure 6 – NVISO created XLSM file using the EPPlus library\r\nFigure 7 – Running oledump.py reveals this document was created using the EPPlus library\r\nSome of the malicious documents contain objects that clearly have been created with EPPlus, using some of the\r\nexample code found on the EPPlus Wiki. We illustrate this with the following example (the first document in this\r\ncampaign):\r\nFilename: Scan Order List.xlsm\r\nMD5: 8857fae198acd87f7581c7ef7227c34d\r\nSHA256: 8a863b5f154e1ddba695453fdd0f5b83d9d555bae6cf377963c9009c9fa6c9be\r\nFile Size: 5.77 KB (5911 bytes)\r\nEarliest Contents Modification: 2020-06-22 14:01:46\r\nThis document contains a drawing1.xml object (a rounded rectangle) with this name: name=”VBASampleRect”.\r\nFigure 8 – zipdump of maldoc\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 7 of 19\n\nFigure 9 – Selecting the drawing1.xml object reveals the name\r\nThis was created with sample code found on the EPPlus Wiki[2]:\r\nFigure 10 – EPPlus sample code, clearly showing the similarities\r\nNoteworthy is that all maldocs we observed have their VBA project protected with a password. It is interesting to\r\nnote that the VBA code itself is not encoded/encrypted, it is stored in cleartext (although compressed) [3]. When a\r\ndocument with a password protected VBA project is opened, the VBA macros will execute without the password:\r\nthe user does not need to provide the password. The password is only required to view the VBA project inside the\r\nVBA IDE (Integrated Development Environment):\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 8 of 19\n\nFigure 11 – Password prompt for viewing the VBA project\r\nWe were not able to recover these passwords. We used John the Ripper with the rockyou.txt password list[4], and\r\nHashcat with a small ASCII brute-force attack.\r\nAlthough each malicious document is unique with its own VBA code, with more than 200 samples analyzed to\r\ndate, we can generalize and abstract all this VBA code to just a handful of templates. The VBA code will either\r\nuse PowerShell or ActiveX objects to download the payload. The different strings are encoded using either\r\nhexadecimal, BASE64 or XOR-encoding; or a combination of these encodings. A Yara rule to detect these\r\nmaldocs is provided at the end of this blog post for identification and detection purposes.\r\nPayload analysis\r\nAs mentioned in the previous section, via the malicious VBA code, a second-stage payload is downloaded from\r\nvarious websites. Each second-stage executable created by its respective malicious document acts as dropper for\r\nthe final payload. In order to thwart detection mechanisms such as antivirus solutions, a variety of obfuscation\r\ntechniques are leveraged which are however not advanced enough to hide the malicious intent.  The infrastructure\r\nused by the threat actor appears to mainly comprise compromised websites.\r\nPopular antivirus solutions such as those listed on VirusTotal, shown in Figure 12, commonly identify the second-stage executables as “AgentTesla”. While leveraging VirusTotal for malware identification is not an ideal method,\r\nit does display how simple obfuscation can result in an incorrect classification. Throughout this analysis, we’ll\r\nexplain how only few of these popular detections turned out to be accurate.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 9 of 19\n\nFigure 12: VirusTotal “AgentTesla” mis-identification.\r\nThe different obfuscation techniques we observed outline a pattern common to all second-stage executables of\r\noperation Epic Manchego. As can be observed in Figure 13, the second stage will dynamically load a decryption\r\nDLL. This DLL component then proceeds to extract additional settings and a third-stage payload before\r\ntransferring the execution to the final payload, typically an information stealer.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 10 of 19\n\nFigure 13: Operation Epic Manchego final stage delivery mechanism.\r\nAlthough the above obfuscation pattern is common to all samples, we have observed an evolution in its\r\ncomplexity as well as a wide variation in perhaps more opportunistic techniques.\r\n  Early Variants Recent Variants\r\nDLL Component\r\nObfuscation\r\nObfuscated base64\r\nencoding\r\nEmpty fixed-size structures\r\nFinal Payload Obfuscation Single-PNG encoding Multi-BMP dictionary encoding\r\nOpportunistic Obfuscation Name randomisation\r\nRun-time method resolving, Goto flow-control, …\r\nTable 1 – Variant comparison\r\nA common factor of the operation’s second-stage samples is the usage of steganography to obfuscate their\r\nmalicious intent. Figure 14 identifies a partial configuration used in recent variants where a dictionary of settings,\r\nincluding the final payload, is encoded into hundreds of images as part of the second-stage’s embedded resources.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 11 of 19\n\nFigure 14: Partial dictionary encoded in a BMP image\r\nThe image itself is part of the following second-stage sample which has the following properties:\r\nFilename: crefgyu.exe\r\nMD5: 7D71F885128A27C00C4D72BF488CD7CC\r\nSHA256: C40FA887BE0159016F3AFD43A3BDEC6D11078E19974B60028B93DEF1C2F95726\r\nFile Size: 761 KB (779.776 bytes)\r\nCompilation Timestamp: 2020-03-09 16:39:33\r\nNoteworthy is the likelihood that the obfuscation process is not built by the threat actors themselves. A careful\r\nreview of the second-stage steganography decoding routine uncovers how most samples mistakenly contain the\r\nfinal payload twice. In the following representation (Figure 15) of the loader’s configuration we can see that its\r\npayload is indeed duplicated. The complexity of the second- and third-stage payloads furthermore tend to suggest\r\nthe operation involves different actors as the initial documents reflect a less experienced actor.\r\nThroughout the multiple dictionary-based variants analyzed we furthermore noticed that, regardless of the final\r\npayload, similar keys were used as part of the settings. All dictionaries contained the final payload as\r\n“EpkVBztLXeSpKwe” while some, as seen in Figure 15, also contained the same value as “PXcli.0.XdHg”. This\r\nsuggests a possible builder for payload delivery, which may be used by multiple actors.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 12 of 19\n\nFigure 15: Stage 2 decoded dictionary\r\nWithin the manually analyzed dataset of 30 distinct dictionary-based second stages, 19 unique final payloads were\r\nobserved. From these, the “Azorult” stealer accounts for 50% of the variant’s delivery (Figure 16). Other payloads\r\ninclude “AgentTesla”, “Formbook”, “Matiex” and “njRat”, which are all well-documented already. Both\r\n“Azurult” and “njRAT” have a noticeable reusage rate.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 13 of 19\n\nFigure 16: Dictionary-based payload classification and (re-)usage of samples with trimmed hashes\r\nOur analysis of droppers and respective payloads uncovered a common pattern in obfuscation routines. While\r\nopportunistic obfuscation methods may evolve, the delivered payloads remain part of a rather limited set of\r\nmalware families.\r\nTargeting\r\nA small number of the malicious documents we retrieved from VirusTotal were uploaded together with the\r\nphishing email itself. Analysis of these emails can shed some light on the potential targets of this actor. Due to the\r\nlimited number of source emails retrieved, it was not possible to identify a clear pattern based on the victims. In\r\nthe 6 emails we were able to retrieve, recipients were in the medical equipment sector, aluminium sector, facility\r\nmanagement and a vendor for custom made press machines.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 14 of 19\n\nWhen looking into the sender domains, it appears most emails are sent from legitimate companies. Having used\r\nthe “Have I Been Pwned”[5] service to confirm if any of the email addresses were known to be compromised,\r\nturned up with no results. This leaves us to wonder whether the threat actor was able to leverage these accounts\r\nduring an earlier infection or whether a different party supplied them. Regardless of who compromised the\r\naccounts, it appears the threat actor primarily uses legitimate corporate email accounts to initiate the phishing\r\ncampaign.\r\nLooking at both sender and recipient, there doesn’t appear to be a pattern we can deduce to identify potential new\r\ntargets. There does not seem to be a specific sector targeted nor are the sending domains affiliated with each other.\r\nBoth body (content) and subject of the emails relate to a more classic phishing scheme, for example, a request to\r\ninitiate business for which the attachment provides the ‘details’. An overview of subjects observed can be seen\r\nbelow, note some subjects have been altered by the respective mail gateways:\r\nRe: Quotation required/\r\nQuote volume and weight for preferred\r\n*****SPAM***** FW:Offer_10044885_[companyname]_2_09_2020.xlsx*\r\n[SUSPECTED SPAM] Alternatives for Request*\r\nPurchase Order Details\r\nQuotation Request\r\nFigure 17 – Sample phishing email\r\nThis method of enticing users to open the attachments is nothing new and does not provide a lot of additional\r\ninformation to pinpoint the campaign targeting any specific organisation or verticals.\r\nHowever, leveraging public submissions of the maldocs through VirusTotal, we clustered over 200 documents,\r\nwhich allowed us to rank 27 countries by submission count without differentiating between uploads possibly\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 15 of 19\n\nperformed through VPNs. As shown in Figure 18, areas such as the United States, Czech Republic, France,\r\nGermany, as well as China, account for the majority of targeted regions.\r\nFigure 18 – Geographical distribution of VT submissions\r\nWhen analysing the initial documents for targeted regions, we primarily identified English, Spanish, Chinese and\r\nTurkish language-based images.\r\nFigure 19 – Maldoc content in Chinese, Turkish, Spanish and English respectively\r\nSome images however contained an interesting detail: some of the document properties are in Cyrillic, and this\r\nregardless of the image’s primary language.\r\nAlthough the Cyrillic Word settings were observed in multiple images, a new maldoc detected at time of writing\r\nthis blog post piqued our interest, as it appears to be the first one to explicitly impersonate a healthcare sector\r\nmember (“Ohiohealth Hardin Memorial Hospital”), as can be observed in Figure 20. Note also the settings as\r\ndescribed above: СТРАНИЦА 1 ИЗ 1; which means page 1 of 1.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 16 of 19\n\nFigure 20 – Maldoc content impersonating “Ohiohealth Hardin Memorial Hospital” with Cyrillic Word settings\r\nThis Microsoft Excel document has the following details:\r\nFilename: 새로운 주문 _2608.xlsm (Korean: New order _2608.xlsm)\r\nMD5: 551b5dd7aff4ee07f98d11aac910e174\r\nSHA256: 45cab564386a568a4569d66f6781c6d0b06a9561ae4ac362f0e76a8abfede7bb\r\nFile Size: 5.77 KB (5911 bytes)\r\nEarliest Contents Modification: 2020-06-22 14:01:46\r\nWhile the template from said hospital may have been simply discovered on the web and consequently used by the\r\nthreat actor, this surprising change in modus operandi does appear to align with the actor’s constant evolution\r\nobserved since the start of tracking.\r\nAssessment\r\nBased on the analysis, NVISO assesses the following:\r\nThe threat actor observed has worked out a new method to create malicious Office documents with a way\r\nto at least slightly reduce detection mechanisms;\r\nThe actor is likely experimenting and evolving its methodology in which malicious Office documents are\r\ncreated, potentially automating the workflow;\r\nWhile the targeting seems rather limited for now, it’s possible these first runs were intended for testing\r\nrather than a full-fledged campaign;\r\nRecent uptick in detections submitted to VirusTotal confirms the actor may be ramping up their operations;\r\nWhile the approach to create malicious documents is unique, the methodologies for payload delivery as\r\nwell as actual payloads are not, and should be stopped or detected by modern technologies;\r\nOf interest is a recent blog post published by Xavier Mertens on the SANS diary Tracking A Malware\r\nCampaign Through VT[6]. It appears another security researcher has also been tracking these documents,\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 17 of 19\n\nhowever, they have extracted the VBA code from the maldocs and uploaded that portion. These templates\r\nrelate to the PowerShell way of downloading the next stage.\r\nIn conclusion, NVISO assesses this specific malicious Excel document creation technique is likely to be observed\r\nmore in the wild, albeit missed by email gateways or analysts, as payload analysis is often considered more\r\ninteresting. However, blocking and detection of these types of novelties, such as the maldoc creation described in\r\nthis blog, enables organizations to detect and respond quicker in case an uptick or similar campaign occurs. The\r\nrecommendations section provides ruling and indicators as a means of detection.\r\nRecommendations\r\nFilter email attachments and emails sent from outside your organization;\r\nImplement robust endpoint detect and respond defenses;\r\nCreate phishing awareness trainings and perform a phishing exercise.\r\nYARA\r\nWe provide the following rule to implement in your detection mechanisms for use in further hunting missions.\r\nrule xlsm_without_metadata_and_with_date {\r\n meta:\r\n description = \"Identifies .xlsm files created with EPPlus\"\r\n author = \"NVISO (Didier Stevens)\"\r\n date = \"2020-07-12\"\r\n reference = \"http://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-fl\r\n tlp = \"White\"\r\n strings:\r\n $opc = \"[Content_Types].xml\"\r\n $ooxml = \"xl/workbook.xml\"\r\n $vba = \"xl/vbaProject.bin\"\r\n $meta1 = \"docProps/core.xml\"\r\n $meta2 = \"docProps/app.xml\"\r\n $timestamp = {50 4B 03 04 ?? ?? ?? ?? ?? ?? 00 00 21 00}\r\n condition:\r\n uint32be(0) == 0x504B0304 and ($opc and $ooxml and $vba)\r\n and not (any of ($meta*) and $timestamp)\r\n}\r\nThis rule will match documents with VBA code created with EPPlus, even if they are not malicious. We had only\r\na couple of false positives with this rule (documents created with other benign software), and quite some corrupt\r\nsamples (incomplete ZIP files).\r\nINDICATORS OF COMPROMISE (IOCs)\r\nIndicators of compromise can be found on our Github page here.\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 18 of 19\n\nMITRE ATT\u0026CK MAPPING\r\nInitial Access:\r\nT1566.001 Phishing: Spearphishing Attachment\r\nExecution:\r\nT1204.002 User Execution: Malicious File\r\nDefense Evasion:\r\nT1140 Deobfuscate/Decode Files or Information\r\nT1036.005 Masquerading: Match Legitimate Name or Location\r\nT1027.001 Obfuscate Files or Information: Binary Padding\r\nT1027.002 Obfuscate Files or Information: Software Packing\r\nT1027.003 Obfuscate Files or Information: Steganography\r\nT1055.001 Process Injection: DLL Injection\r\nT1055.002 Process Injection: PE Injection\r\nT1497.001 Virtualization/Sandbox Evasion: System Checks\r\nAuthors\r\nThis blog post was created based on the collaborative effort of :\r\nDidier Stevens: Linkedin – Twitter\r\nMaxime Thiebaut: Linkedin – Twitter\r\nDries Boone: Linkedin– Twitter\r\nBart Parys: Twitter\r\nMichel Coene: Linkedin – Twitter\r\nSource: https://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nhttps://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/\r\nPage 19 of 19\n\nthis blog post piqued member (“Ohiohealth our interest, Hardin Memorial as it appears to Hospital”), be the first one as can be observed to explicitly in Figure impersonate a healthcare 20. Note also sector the settings as\ndescribed above: СТРАНИЦА 1 ИЗ 1; which means page 1 of 1.\n   Page 16 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/"
	],
	"report_names": [
		"epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers"
	],
	"threat_actors": [
		{
			"id": "08c8f238-1df5-4e75-b4d8-276ebead502d",
			"created_at": "2023-01-06T13:46:39.344081Z",
			"updated_at": "2026-04-10T02:00:03.294222Z",
			"deleted_at": null,
			"main_name": "Copy-Paste",
			"aliases": [],
			"source_name": "MISPGALAXY:Copy-Paste",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "f1c14cad-15c0-4ae3-be08-4226044aa8cb",
			"created_at": "2022-10-25T16:07:23.954439Z",
			"updated_at": "2026-04-10T02:00:04.806247Z",
			"deleted_at": null,
			"main_name": "Operation Epic Manchego",
			"aliases": [],
			"source_name": "ETDA:Operation Epic Manchego",
			"tools": [
				"AZORult",
				"AgenTesla",
				"Agent Tesla",
				"AgentTesla",
				"Bladabindi",
				"Formbook",
				"Jorik",
				"Matiex",
				"Negasteal",
				"Origin Logger",
				"PuffStealer",
				"Rultazo",
				"ZPAQ",
				"njRAT",
				"win.xloader"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434629,
	"ts_updated_at": 1775791582,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/13017fa68d002c79ec20071c4e7cdfe7fb61cbb1.pdf",
		"text": "https://archive.orkl.eu/13017fa68d002c79ec20071c4e7cdfe7fb61cbb1.txt",
		"img": "https://archive.orkl.eu/13017fa68d002c79ec20071c4e7cdfe7fb61cbb1.jpg"
	}
}