{
	"id": "a01e4543-f060-4a0f-8be7-372e794bbcf5",
	"created_at": "2026-04-06T00:11:19.503745Z",
	"updated_at": "2026-04-10T03:26:53.36538Z",
	"deleted_at": null,
	"sha1_hash": "caf41bc8d1359d861c8b1bf2562167edfe1923eb",
	"title": "Operation Bachosens: A detailed look into a long-running cyber crime campaign",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2474220,
	"plain_text": "Operation Bachosens: A detailed look into a long-running cyber\r\ncrime campaign\r\nBy Jon DiMaggio\r\nPublished: 2018-04-03 · Archived: 2026-04-05 19:18:58 UTC\r\nA recent investigation into a unique malware attack on an automotive parts supplier in China ended quite\r\nunexpectedly. As well as discovering rarely-used malware techniques, we also discovered unexpected motivations\r\nof the individual who is likely behind the attacks, and the great lengths he went to for relatively meager gain.\r\nPress enter or click to view image in full size\r\nIn March 2016, Symantec’s automated attack notification systems, which run on our vast telemetry, identified a\r\npotentially interesting targeted attack. One of the initial interesting attributes of the attack was the small number of\r\norganizations and regions targeted. Our initial triage found a custom keylogger, along with two unknown\r\nsuspicious files.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 1 of 12\n\nPart 1: Following the malware\r\nAnalyzing the unknown samples, we confirmed they were a new backdoor Trojan that Symantec now detects as\r\nTrojan.Bachosens. Once the Bachosens malware is dropped on the victim computer, it creates a number of files\r\nwhich, in this instance, were designed to masquerade as the legitimate Java application on the target’s computer to\r\navoid detection:\r\n%AppData%\\Java\\jusched.exe\r\n%CommonProgramFiles%\\java\\jusched.exe\r\n%CommonProgramFiles%\\java\\java update\\jusched.exe\r\n%CommonProgramFiles%\\jusched.exe\r\n%System%\\sens.dll\r\n%System%\\stor64.dll\r\n%System%\\stor32.dll\r\nTrojan.Bachosens then creates a registry entry so that it remains persistent on the computer and runs every time\r\nWindows starts:\r\nHKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\”JavaUpdater” = “[PATH TO\r\nMALWARE]\\jusched.exe -v”\r\nBoth a 32 bit and a 64 bit keylogger were also identified being used in these attacks, depending on the target’s\r\nenvironment. This was our first clue that the attacker was tailoring their tools and malware specifically for targets’\r\nenvironments. The keylogger was not dropped by the malware, so we suspect it is pushed manually by the attacker\r\nto systems of interest after the initial infection.\r\nOnce we had this information, the next step was to uncover the communication protocol of the backdoor. Right\r\naway, we discovered the backdoor used a domain generation algorithm (DGA). A DGA causes the command and\r\ncontrol (C\u0026C) server that the threat communicates with to change depending on the current date. This makes\r\nshutting down the attacker’s infrastructure more difficult.\r\nSome malware will generate hundreds or thousands of possible C\u0026C domains as part of their DGA. Oddly, the\r\nBachosens attacker developed his malware to only generate 13 domains per year. Only two of the 13 domains are\r\nactive at any given time: one domain that changes each month, and another that is static for the entire year.\r\nFor the monthly changing domain, Bachosens’ DGA generates a predefined number of random characters seeded\r\nby the current date and pairs them with a free Dynamic DNS (DDNS) provided root domain:\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 2 of 12\n\nPress enter or click to view image in full size\r\nFor the yearly domain, Bachosens does the same, but ads .com rather than a static root domain.\r\nOnce we figured out this algorithm, we were able to generate all the domains for 2016 and 2017.\r\nPress enter or click to view image in full size\r\nHowever, even after determining the threat used a DGA, we still had not fully uncovered the backdoor’s C\u0026C\r\nprotocol. What we discovered next was not only unexpected, but became the catalyst for us to dig further.\r\nCovert channels\r\nMost backdoors use HTTP or HTTPS for communicating with their C\u0026C servers, but this malware was\r\ncommunicating over DNS, ICMP, and HTTP protocols.\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 3 of 12\n\nOur analysis showed the attacker actually coded the malware to attempt DNS (domain name system)\r\ncommunication first, switching to alternative methods only when necessary. DNS is the protocol used to translate\r\ndomain names (example.com) into IP addresses (127.0.0.1). Using DNS for C\u0026C communication has been\r\ndocumented previously, such techniques were seen being used in malware found in the Shadow Brokers leak, but\r\nit is rare.\r\nIn this case, the malware sends data encoded within the domain name to the DNS server and receives data from\r\nthe attacker in the DNS response packet. DNS response records can provide multiple IP addresses and Bachosens\r\nrelies on DNS AAAA response records. An AAAA response contains the requested domain’s 128-bit IPv6 address.\r\nInstead of a valid IPv6 address, the address is encoded data from the attacker. Below is an example of the DNS\r\ntraffic seen in the initial communication:\r\nPress enter or click to view image in full size\r\nThe information transmitted in the initial communications from the malware to the DNS server includes an\r\nattacker-determined “Infection ID” (decoded below), along with the infection date.\r\nSo, for example, “lok4723peoi8n1c0mk23rtmc91z” is decrypted to “0c23ca440908c1e80301020000000000”,\r\nwhich can be decoded into the “infection id” and infection date below:\r\nnonce = 0c\r\ncksum = 23ca (verification PASS)\r\ninfection_id = c1080944\r\ninfection_year = 2016\r\ninfection_month = 8\r\ninfection_day = 8\r\ninfection_random = 0944\r\nsid_relative_identifier = 1000\r\nrequest_kind = 0201\r\npadding_size = 0\r\nGet Jon DiMaggio’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 4 of 12\n\nrequest_sequence = 00000000\r\nThe DNS server responds back to the malware with a provided “session ID” and an RSA-encrypted\r\ncommunication channel is established over the same protocol where the victim’s environment, including operating\r\nsystem, computer name, and user name, is sent to the attacker.\r\nThe malware can perform this handshake and session establishment in a similar manner using DNS A records,\r\nDNS TXT records, ICMP Echo packets, and HTTP. After the communication channel session is established, the\r\nattacker has been seen to change protocols. For example, the attacker can instruct the malware to change from\r\nDNS to ICMP by sending the command “conn icmp \u003cid\u003e”.\r\nWhile DNS is considered a covert method of communication, once we discovered it was being used we could\r\nsearch for historical DNS request and response records and decode the infection ID associated with each target\r\nand the precise infection date. This allowed us to build an accurate timeline based on the attacker’s own metrics.\r\nThrough this process we were able to determine the adversary was active and present on the automotive victim’s\r\nnetwork from December 2016 through February 2017.\r\nThe historic DNS records also confirmed attempted attacks on two other organizations: a commercial airline and\r\nan organization involved in the online entertainment industry.\r\nWhile analyzing the malware we also came across an interesting aspect that could provide support for attribution.\r\nRussian strings for data sizes were used. For example, б and гб were found in the binary, which are the Russian\r\nequivalents of bytes (B) and gigabytes (GB).\r\nPart 2: Determining attacker motivation\r\nAt this point in the investigation, we had a solid grasp of the malware features, including its unique\r\ncommunication protocol. However, the limited and diverse targets of an automotive parts supplier, an airline, and\r\nan online entertainment organization were puzzling. The automotive parts supplier was especially worrisome in\r\nthe context of the recent Vault 7 leaks, which describe automobile hacking by a likely nation state. Understanding\r\nthe objective of these attacks and who else may be a target was necessary. The following were the likely scenarios:\r\n1. Could this be corporate espionage in which intellectual property is being stolen for the advantage of a\r\ncompeting firm?\r\n2. Could this be a financially motivated cyber crime gang with the ability to develop or purchase unique\r\nundetected malware?\r\n3. Could this be a nation-state attacker with a sabotage motivation?\r\nThrough our reconstructed infection timeline, we were able to see what systems the adversary spent the most time\r\non and noticed a reoccurring theme in the targets of interest. The systems in which the attacker spent the most time\r\nwere automotive technology developer systems. Of the developer systems, the primary technology that appeared\r\nto be of interest to the attacker involved the development of a very specific automotive diagnostic technology.\r\nThis technology is loaded into handheld diagnostic devices and sold to automotive repair shops globally. To\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 5 of 12\n\nprotect the victims we are masking the technology and product name and will refer to it as “Diag-1000” for the\r\nremainder of the article.\r\nPart 3: Attacker infrastructure and IOC ties\r\nIn addition to understanding the attack methods and victim profiles, analyzing the attacker’s infrastructure can\r\nprovide potential attribution clues. The earliest known Bachosens keylogger from December 2013 did not rely on\r\na DGA to generate the C\u0026C domain but instead connected to the hardcoded domain of “pstars.org”. As seen in the\r\ndiagram below, pstars.org used the name servers ns1.oyy[.]name \u0026 ns2.oyy[.]name.\r\nPress enter or click to view image in full size\r\nAt this point in the investigation, we had more than 70 samples we had analyzed made up of two versions of the\r\nBachosens Trojan and two versions of the keyloggers. Using internal systems that can find similar malware\r\nsamples, we were able to then identify another previously unknown sample associated with the attacker. The\r\nsample looked like it was developed for testing purposes as opposed to actually being used in attacks. The attacker\r\nmade a mistake in their operational security with this sample, however, as it included a hardcoded IP address of\r\n95.153.122.210. This IP address was associated with the domain gorkogo77.ddns[.]net, which is also associated\r\nwith the oyy.name name servers as seen in the diagram below.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 6 of 12\n\nThe AAAA record for oyy.name also led to a variety of other domains that also had similar IPs and registration\r\ninformation.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 7 of 12\n\nLooking at the registration information for oyy.name and a number of other domains associated with the above\r\ndomains, we see the name Igor C****** was used, as well as the common email of “igor.********@gmail.com”\r\nand the phone number “+373.7777****”. In addition, the addresses were all located in Moldova. While this name\r\nmay be a pseudonym, we have found it, or variations of it, used consistently across the supporting infrastructure,\r\nincluding on a linked personal social network page.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 8 of 12\n\nNext we looked at the common phone number used and identified a number of domains that were registered with\r\nthe same registrant phone number, as seen below:\r\nPress enter or click to view image in full size\r\nAfter checking the registration information for each of these domains we identified another tie to the registrant\r\nand Bachosens activity. The domain “funny-penny.com”, seen above with the same phone number as related\r\nBachosens domains, used the street address “str. Gorkogo 77”, which matches the previously discovered\r\ngorkogo77.ddns.net domain used by Bachosens.\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 9 of 12\n\nPress enter or click to view image in full size\r\nWithin these related domains, only one appears to have an active business. The domain sells auto parts online.\r\nFurthermore, this online shop actually has a physical shop in Moldova that matches the domain registration\r\ninformation.\r\nWe now knew the registrant of the infrastructure used to compromise an automotive technology supplier was also\r\nassociated with an automotive parts shop in Moldova. But why this automotive technology supplier was\r\ncompromised wasn’t yet completely clear.\r\nPivoting off the registration information led to a variety of other sites, including Android applications developed\r\nby the same individual and a GitHub site. The aliases and email addresses used on these sites finally led to forum\r\npostings with the subjects (translated):\r\nThe [ DIAG-1000 ] (All Android / the IOS)\r\nSale upgrade scan tool [ DIAG-1000 ]\r\nThese posts were attempting to sell a stolen version of the exact diagnostic technology produced by the victim\r\nautomotive supplier. After a lengthy investigation, we discovered the attacker’s complex efforts appear to have\r\nbeen simply to steal the technology for resale on the black market — a considerable effort for a technology that\r\ncan be legitimately purchased for around $1,100.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 10 of 12\n\n“After a lengthy investigation, we discovered the attacker’s complex efforts appear to have been simply\r\nto steal the technology for resale on the black market”\r\nConclusion\r\nGoing into this investigation, we thought there was a good chance this would be associated with a nation-state\r\nattacker based on the regions of the victims, the highly selective targeting, and the methods in which the malware\r\nused covert channels to communicate and go undetected.\r\nThe discovery that all of the attacker’s complex coding was for such small financial gain in reselling stolen\r\nautomotive diagnostic tools was very surprising. The attacks resulted in a meager payout for the attacker, who\r\nwent through such elaborate means to obtain the automotive diagnostic technology. The legitimate “Diag-1000” is\r\nsold new for less than $1,100 and the stolen version was being sold for $110.\r\nBased on the Russian strings in the malware infrastructure, Russian characters used for data size suffixes, and the\r\nopen source traces left by the attacker, we are reasonably confident the attacker is located in Tiraspol, Moldova\r\nand is associated with the automotive industry.\r\nThis investigation provided us with a good example as to why analysts cannot make assumptions when\r\nconducting an investigation and must set a hypothesis, follow the data, and prove or disprove that hypothesis\r\nbased on the facts. The initial facts could have led one to believe this was a highly sophisticated operation carried\r\nout by a nation state, however, by following the evidence and connecting the dots we were able to develop and see\r\nthe complete picture of the life cycle of the Bachosens attacks against the victim organizations.\r\nFor more information on this investigation, take a look at the Security Response blog on the subject.\r\nCheck out the Security Response blog and follow Threat Intel on Twitter to keep up-to-date with the latest\r\nhappenings in the world of threat intelligence and cybersecurity.\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 11 of 12\n\nLike this story? Recommend it by hitting the heart button so others on Medium see it, and follow Threat Intel on\r\nMedium for more great content.\r\nSource: https://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nhttps://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://medium.com/threat-intel/cybercrime-investigation-insights-bachosens-e1d6312f6b3a"
	],
	"report_names": [
		"cybercrime-investigation-insights-bachosens-e1d6312f6b3a"
	],
	"threat_actors": [
		{
			"id": "d4f7cf97-9c98-409c-8b95-b80d14c576a5",
			"created_at": "2022-10-25T16:07:24.561104Z",
			"updated_at": "2026-04-10T02:00:05.03343Z",
			"deleted_at": null,
			"main_name": "Shadow Brokers",
			"aliases": [],
			"source_name": "ETDA:Shadow Brokers",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "171b85f2-8f6f-46c0-92e0-c591f61ea167",
			"created_at": "2023-01-06T13:46:38.830188Z",
			"updated_at": "2026-04-10T02:00:03.114926Z",
			"deleted_at": null,
			"main_name": "The Shadow Brokers",
			"aliases": [
				"Shadow Brokers",
				"ShadowBrokers",
				"The ShadowBrokers",
				"TSB"
			],
			"source_name": "MISPGALAXY:The Shadow Brokers",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434279,
	"ts_updated_at": 1775791613,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/caf41bc8d1359d861c8b1bf2562167edfe1923eb.pdf",
		"text": "https://archive.orkl.eu/caf41bc8d1359d861c8b1bf2562167edfe1923eb.txt",
		"img": "https://archive.orkl.eu/caf41bc8d1359d861c8b1bf2562167edfe1923eb.jpg"
	}
}