{
	"id": "7e69527e-162e-4950-a69a-a814ad5f075f",
	"created_at": "2026-04-06T00:19:23.826709Z",
	"updated_at": "2026-04-10T03:20:05.94547Z",
	"deleted_at": null,
	"sha1_hash": "663ae2bcfe9a53be7a4a978c5a22a37ce417c30b",
	"title": "The MeDoc Connection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1327853,
	"plain_text": "The MeDoc Connection\r\nBy David Maynor\r\nPublished: 2017-07-05 · Archived: 2026-04-05 14:47:55 UTC\r\nWednesday, July 5, 2017 14:22\r\nSummary\r\nThe Nyetya attack was a destructive ransomware variant that affected many organizations inside of Ukraine and\r\nmultinational corporations with operations in Ukraine. In cooperation with Cisco Advanced Services Incident\r\nResponse, Talos identified several key aspects of the attack. The investigation found a supply chain-focused attack\r\nat M.E.Doc software that delivered a destructive payload disguised as ransomware. By utilizing stolen credentials,\r\nthe actor was able to manipulate the update server for M.E.Doc to proxy connections to an actor-controlled server.\r\nBased on the findings, Talos remains confident that the attack was destructive in nature. The effects were broad\r\nreaching, with Ukraine Cyber police confirming over 2000 affected companies in Ukraine alone.\r\nDetails\r\nFor Talos, June 27th, 2017, started with a message from our intelligence partners in Ukraine.  A massive\r\nransomware attack was underway, and they were asking for help.  An organized attacker had the means to deliver\r\narbitrary code to users of the most popular accounting software in Ukraine, and that includes multinational\r\ncorporations that do business there.  The actor in question chose to use this capability to encrypt critical files and\r\nhard drives, with no way to decrypt the software.\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 1 of 15\n\nSince the BlackEnergy attacks of late 2015, Talos has worked with public and private organizations in Ukraine to\r\nrespond to attacks in the region.  Once already this year, Talos has assisted organizations targeted by actors with\r\ndestructive intent.  Interestingly, in those cases a wiper very similar to prior BlackEnergy malware was deployed\r\nand, when that was blocked by our Advanced Malware Protection (AMP) product, the actor fell back to using a\r\nransomware variant in an attempt to disrupt the organization’s activities.  With this recent history in mind, we\r\nwere immediately concerned that there was more to this story than just another ransomware attack.\r\nEarly on it became clear that, while a majority of the early events were in Ukraine, the malware was infecting\r\norganizations that didn’t immediately have any known connection to the country.  Because of the scale of the\r\nevent, Talos initiated an internal response management system call TaCERS (Talos Critical Event Response\r\nSystem) and began the research and response process.  TaCERS divides up activities into intelligence, telemetry\r\nanalysis, reverse engineering, communications and detection research.  Talos researchers and engineers from\r\naround the world came together to address this threat.\r\nBased on endpoint telemetry, it was clear that a Ukranian accounting software package called “M.E.Doc” was at\r\nthe center of activity. Like WannaCry, there were reports of an email vector.  This is most likely because some of\r\nthe earliest infected machines had concurrent Lokibot infections with indications of an email vector for that\r\nmalware. After careful research Talos concluded that for the delivery of the Nyetya malware, all installations came\r\nthrough the M.E.Doc update system.\r\nM.E.Doc is a widely deployed accounting package created by a Ukrainian company named Intellect Service and\r\nthat it was used to interact with Ukrainian tax systems.  At this point we were in a position to reach out to\r\nM.E.Doc directly and offer assistance.\r\nM.E.Doc was quick to accept an offer of assistance.  As part of Cisco’s global response to this event, two incident\r\nresponse specialists from the Advanced Services group arrived in Ukraine on the evening of June 29th and an\r\nadditional incident response specialist supported the investigation from the UK.  M.E.Doc was exceptionally open\r\nin arranging access to engineers and administrators who walked the team through the system and provided access\r\nto log files and code.  They also agreed to share the results of our investigation for the purposes of this report.\r\nIn every Cisco incident response investigation, anywhere in the world, a dedicated Talos resource is made\r\navailable to the incident response team to coordinate intelligence analysis, reverse engineering escalations and\r\ntelemetry analysis activities.  The two teams work together constantly, and that experience was put to full use in\r\nthis investigation.\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 2 of 15\n\nEarly in the investigation, a web shell was discovered at http://www.me-doc[.]com[.]ua/TESTUpdate/medoc_online.php.  The timestamp in the file was May 31 14:45 2017. Our analysis\r\nshows the webshell to be a slightly modified version of the open source PHP webshell PAS. The webshell is stored\r\nin an encrypted form and requires a passphrase set in a HTTP POST variable to decrypt. The decryption of the\r\nshell shows a fully featured PAS webshell.\r\nAs the incident response team extracted logs and additional forensic data, it was uploaded to Talos.  This started a\r\n24-hour cycle where at around 10am EDT, when it was evening in Ukraine, the Cisco incident response team\r\nwould brief Talos on their findings and new data.  Then at 3am EDT, as Ukraine was getting to work, Talos would\r\nbrief the Cisco incident response team on their overnight findings.\r\nAlmost immediately, indications of problems were found.  In the July 1st briefing, Talos identified key evidence in\r\nthe logs:\r\n8:57:46\r\nAM\r\nusc-cert sshd[23183]: subsystem request for sftp\r\n8:59:09\r\nAM\r\nusc-cert su: BAD SU to root on /dev/pts/0\r\n8:59:14\r\nAM\r\nusc-cert su: to root on /dev/pts/0\r\n9:09:20\r\nAM\r\n[emerg] 23319#0: unknown directive \"\" in /usr/local/etc/nginx/nginx.conf:3\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 3 of 15\n\n9:11:59\r\nAM\r\n[emerg] 23376#0: location \"/\" is outside location \"\\.(ver|txt|exe|upd|rtf|cmnt)$\" in\r\n/usr/local/etc/nginx/nginx.conf:136\r\nAn unknown actor had stolen the credentials of an administrator at M.E.Doc. They logged into the server,\r\nacquired root privileges and then began modifying the configuration file for the NGINX web server.  We were\r\nunable to recover the nginx.conf file, as it was subsequently overwritten, but additional log files were important in\r\nunderstanding what was changed.  What we found were thousands of errors that looked like this:\r\n[error] 23401#0: *374685644 upstream timed out (60: Operation timed out) while connecting\r\nto upstream, client: \u003cREDACTED\u003e, server: upd.me-doc.com.ua, request: \"GET /last.ver?\r\nrnd=1b2eb092215b49f5b1d691b5c38e3a74 HTTP/1.1\", upstream:\r\n\"http://176.31.182[.]167:80/last.ver?rnd=1b2eb092215b49f5b1d691b5c38e3a74\", host:\r\n\"upd.me-doc.com.ua\"\r\nThe NGINX server had been reconfigured so that any traffic to upd.me-doc.com.ua would be proxied through the\r\nupdate server and to a host in the OVH IP space with an IP of 176.31.182.167.  Subsequent investigation found\r\nthat this server was operated by a reseller, thcservers.com, and that the server had been wiped the same day at 7:46\r\nPM UTC.\r\nWhen we compare the time of the first and last upstream error messages on the server to our in-field endpoint\r\ntelemetry, we find that they bracket the beginning and the end of the active infection phase of the event.  The\r\ninitial log message was at 9:11:59 UTC and the last message was seen at 12:31:12 UTC.  In our telemetry we see\r\nno new organizations infected outside of this timeframe.\r\nWe found one other piece of forensic evidence showing that the event concluded on or around 12:30 PM UTC.\r\n The file timestamp for nginx.conf at the time we analyzed the servers was Jun 27th, 12:33 PM UTC.  The actor\r\nhad returned the NGINX configuration to its original state at this time.  There is only one other indicator to share,\r\nwhich was a Latvian IP address that disconnected from the system at 2:11:07 PM UTC:\r\nReceived disconnect from 159.148.186.214: 11: FlowSshClientSession: disconnected on user's request\r\nM.E.Doc confirms that neither the OVH server nor the Latvian IP address have any association with M.E.Doc.\r\nAt this point we understood that the actor in question had access to much of the network and many of the systems\r\nof M.E.Doc through compromised credentials.  The questions remaining were:  What were they doing with\r\ncontrol of the upgrade server?  How were they delivering the malicious software?\r\nWhile we didn’t know it at the time, we can now confirm ESET’s research into the backdoor that had been\r\ninserted into the M.E.Doc software.  The .net code in ZvitPublishedObjects.dll had been modified on multiple\r\noccasions to allow for a malicious actor to gather data and download and execute arbitrary code:\r\nDate M.E.Doc Update Version\r\n4/14/2017 10.01.175-10.01.176\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 4 of 15\n\n5/15/2017 10.01.180-10.01.181\r\n6/22/2017 10.01.188-10.01.189\r\nLooking further back in the logs provided by M.E.Doc, we could see the same “upstream” activity on June 22nd.\r\n Unfortunately, we do not have logs available for May or April, but it is reasonable to assume similar behavior\r\noccurs back through those dates as well.\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 5 of 15\n\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 6 of 15\n\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 7 of 15\n\nTimeline\r\nZvitPublishedObjects.dll Backdoor Analysis\r\nThe backdoor was added to the ZvitPublishedObjects.Server.UpdaterUtils.IsNewUpdate function in\r\nZvitPublishedObjects.dll:\r\nBetween lines 278 and 279 on the left, we can see on the right that code was added to retrieve every organization’s\r\nEDRPOU and name. Then it creates a new MeCom object and a thread for it which will contact http://upd.me-doc[.]com.ua/last.ver?rnd=\u003cGUID\u003e every 2 minutes. It will also send any replies to this URL.\r\nIf a proxy has been configured, when the MeCom object is created at line 288 on the right, it proceeds to retrieve\r\nthe proxy’s host, port, username and password:\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 8 of 15\n\nIt then retrieves the SMTP host, username, password and email address for every organization in the application’s\r\ndatabase:\r\nIt also writes the previously collected proxy info to a registry key: HKCU\\SOFTWARE\\WC. It stores the proxy\r\nusername and password in the “Cred” subkey and the full proxy information in “Prx”.\r\nAt line 294 in IsNewUpdate is a call to meCom.CreateMeainThread.  The code creates a thread that performs the\r\n“MainAction”. This thread will continuously query the request URL (http://upd.me-doc[.]com.ua/last.ver?rnd=\r\n\u003cGUID\u003e) looking for commands and will then start a new thread per command to execute, waiting a maximum of\r\n10 minutes for the thread to complete. It will then send back the result of the thread to the response url, which in\r\nthis case is the same as the request URL: http://upd.me-doc[.]com.ua/last.ver?rnd=\u003cGUID\u003e.\r\nThe GetCommandsAndPeriod function will retrieve the commands from the web request:\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 9 of 15\n\nWhen sending the request, it will pass along in cookies the EDRPOU and the username that the program is\r\nrunning as. From the response, it will read the first 8 bytes as the initialization vector for the encryption. The rest\r\nof the data is encrypted with the TripleDes using a 24-character key: \\x00 to \\x17 (i.e. characters 0 to 23). It will\r\ndecrypt, decompress and deserialize the commands it has to execute. It will also retrieve information on how long\r\nit should wait until the next time it goes to ask for commands (this was originally set to 2 minutes when the object\r\nwas created).\r\nSendAnswer will send multiple web requests with a maximum of 2048 bytes each, with the result of the executed\r\ncommand stored in cookies. It will encrypt this data the same way as the received commands, using a random 8-\r\nbyte IV and the 24-character key 0-23.\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 10 of 15\n\nThese are the encryption and decryption functions:\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 11 of 15\n\nFinally, the Worker object (see Line 372 of MainFunction) handles executing the commands. There are a total of 6\r\ncommands that Worker can execute.\r\nThis appears to be the mechanism used for delivering the Nyetya malware.  The command line arguments\r\nperfectly match what was observed in endpoint telemetry when M.E.Doc machines executed the initial sample.\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 12 of 15\n\nDetail of Commands\r\nWhat Now?\r\nFirst we need to put together everything we know.  In the past Talos has observed an actor specifically targeting\r\nUkrainian institutions attempt to use the BlackEnergy wiper malware and, when that attempt was blocked, fall\r\nback to using a ransomware variant as an acceptable replacement for a wiper.  We’ve also already documented in\r\nour previous blog that “Given the circumstances of this attack, Talos assesses with high confidence that the intent\r\nof the actor behind Nyetya was destructive in nature and not economically motivated.”  Finally, now that we can\r\nconfirm that M.E.Doc was the installation vector, we can assess that the targets for this attack were Ukraine and\r\nthose organizations that chose to conduct business with Ukraine.\r\nOur Threat Intelligence and Interdiction team is concerned that the actor in question burned a significant\r\ncapability in this attack.  They have now compromised both their backdoor in the M.E.Doc software and their\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 13 of 15\n\nability to manipulate the server configuration in the update server.\r\nIn short, the actor has given up the ability to deliver arbitrary code to the 80% of UA businesses that use M.E.Doc\r\nas their accounting software, along with any multinational corporations that leveraged the software.  This is a\r\nsignificant loss in operational capability, and the Threat Intelligence and Interdiction team assesses with moderate\r\nconfidence that it is unlikely that they would have expended this capability without confidence that they now have\r\nor can easily obtain similar capability in target networks of highest priority to the threat actor.\r\nBased on this, Talos is advising that any organization with ties to Ukraine treat software like M.E.Doc and systems\r\nin Ukraine with extra caution since they have been shown to be targeted by advanced threat actors.  This includes\r\nproviding them a separate network architecture, increased monitoring and hunting activities in those at-risk\r\nsystems and networks and allowing only the level of access absolutely necessary to conduct business.  Patching\r\nand upgrades should be prioritized on these systems and customers should move to transition these systems to\r\nWindows 10, following the guidance from Microsoft on securing those systems.  Additional guidance for network\r\nsecurity baselining is available from Cisco as well.  Network IPS should be deployed on connections between\r\ninternational organizations and their Ukrainian branches and endpoint protection should be installed immediately\r\non all Ukrainian systems.\r\nTalos places this attack in the supply-chain category.  Rather than targeting organizations directly, an actor\r\ncompromises trusted hardware and software vendors to deliver compromised assets to a high-priority\r\nenvironment.  We believe that these types of malicious capabilities are highly desired by sophisticated actors. All\r\nvendors, regardless of size or geographic region, must be increasingly vigilant. Find out more about how Cisco\r\nassures the integrity of their products here.\r\nFor further coverage of the Nyetya incident, please refer to our previous blog post.\r\nIndicators of Compromise\r\nSHA256\r\nM.E.Doc ZvitPublishedObjects.dll files with backdoor:\r\nf9d6fe8bd8aca6528dec7eaa9f1aafbecde15fd61668182f2ba8a7fc2b9a6740\r\nd462966166450416d6addd3bfdf48590f8440dd80fc571a389023b7c860ca3ac\r\n2fd2863d711a1f18eeee5c7c82f2349c5d4e00465de9789da837fcdca4d00277\r\nNyetya Malware:\r\n027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745\r\n02ef73bd2458627ed7b397ec26ee2de2e92c71a0e7588f78734761d8edbdcd9f\r\neae9771e2eeb7ea3c6059485da39e77b8c0c369232f01334954fbac1c186c998\r\nMalicious IP Addresses:\r\n176.31.182[.]167\r\n159.148.186[.]214\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 14 of 15\n\nAMP Coverage\r\nW32.Ransomware.Nyetya.Talos\r\nW32.F9D6FE8BD8.Backdoor.Ransomware.Nyetya.Talos\r\nW32.D462966166.Backdoor.Ransomware.Nyetya.Talos\r\nW32.2FD2863D71.Backdoor.Ransomware.Nyetya.Talos\r\nW32.02EF73BD24-95.SBX.TG\r\nW32.GenericKD:Petya.20h1.1201\r\nSource: http://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nhttp://blog.talosintelligence.com/2017/07/the-medoc-connection.html\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"http://blog.talosintelligence.com/2017/07/the-medoc-connection.html"
	],
	"report_names": [
		"the-medoc-connection.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434763,
	"ts_updated_at": 1775791205,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/663ae2bcfe9a53be7a4a978c5a22a37ce417c30b.pdf",
		"text": "https://archive.orkl.eu/663ae2bcfe9a53be7a4a978c5a22a37ce417c30b.txt",
		"img": "https://archive.orkl.eu/663ae2bcfe9a53be7a4a978c5a22a37ce417c30b.jpg"
	}
}