{
	"id": "688e0f35-479b-47ea-b053-77bd52c2ca4f",
	"created_at": "2026-04-06T00:07:10.359297Z",
	"updated_at": "2026-04-10T03:33:30.066355Z",
	"deleted_at": null,
	"sha1_hash": "a4792923ea7c45526bfa14eafa04d2ce4b1edd27",
	"title": "VMConnect: Malicious PyPI packages imitate popular open source modules | ReversingLabs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 94479,
	"plain_text": "VMConnect: Malicious PyPI packages imitate popular open source\r\nmodules | ReversingLabs\r\nBy Karlo Zanki, Reverse Engineer at ReversingLabsKarlo Zanki\r\nPublished: 2023-08-03 · Archived: 2026-04-05 20:11:31 UTC\r\nReversingLabs has identified several malicious Python packages on the Python Package Index (PyPI) open source\r\nrepository. In all, ReversingLabs researchers uncovered 24 malicious packages imitating three, popular open\r\nsource Python tools: vConnector, a wrapper module for pyVmomi VMware vSphere bindings; as well as eth-tester, a collection of tools for testing ethereum based applications; and databases, a tool that gives asyncro\r\nsupport for a range of databases.\r\nBased on the research team's observations, the campaign began on or around July 28, 2023, when the first of the\r\nmalicious packages were published. It continues to the current day, with new, malicious PyPI packages posted on\r\na daily basis, as prior packages are detected and removed.\r\nIn contrast to other, recent supply chain campaigns, such as Operation Brainleeches, the malicious packages that\r\nmake up this campaign display evidence of a concerted effort to deceive developers. They achieve this by\r\nimplementing the entire functionality of the modules they are imitating and standing up corresponding and linked\r\nGitHub projects that omit the malicious functionality found in the PyPI release package.\r\nThis is not the first time that we have observed such behavior. In June, 2022, for example, we discovered an npm\r\nmalicious package, maintenancewebsite, which used a similar approach to hide cryptomining features. The\r\nVMConnect campaign is the latest example of open source modules being used to propagate malicious code, and\r\nmore evidence that security assessments of open source code repositories may miss these nuanced attacks.\r\nThe ReversingLabs research team is continuously monitoring open-source package repositories for instances of\r\nmalicious code tampering, the planting of malicious packages or dependencies and other forms of software supply\r\nchain attacks. This work involves both automated and human-led scanning and analysis of packages published in\r\nthe most popular public package repositories like npm, PyPI, Ruby and NuGet.\r\nHistorically, the vast majority of the malicious supply chain campaigns we have identified were found on the npm\r\nopen source repository, which is home to the lion’s share of open source projects and developers. However, in\r\nrecent months other platforms, in particular, the Python Package Index (PyPI) have seen increased malicious\r\nactivity. In February, for example, ReversingLabs researchers discovered 41 malicious PyPI packages posing as\r\nHTTP libraries, with some mimicking popular and widely used libraries. In March, we encountered a malicious\r\nPyPI package named termcolour, a three-stage downloader published in multiple versions that co-opted the name\r\nof a defunct PyPI package. Then, in May, PyPI briefly stopped accepting new submissions after it was\r\noverwhelmed with malicious submissions.\r\nReversingLabs threat researchers have identified a new malicious PyPI campaign that includes a suspicious\r\nVMConnect package published to the PyPI repository.\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 1 of 8\n\nSuspicious behavior detected\r\nThis package was declared suspicious during routine scanning by ReversingLabs Titanium Platform, a powerful\r\nstatic analysis engine capable of extracting various types of metadata from a wide range of file formats.\r\nBesides the various types of metadata, the ReversingLabs Titanium Platform is also capable of extracting behavior\r\nindicators, making it easier to understand functional capabilities of a file. And that capability is what drew our\r\nattention to the _init_.py file within VMConnect. Code inside VMConnect’s __init__.py file is capable of creating\r\na process, decoding data using the Base64 algorithm and converting binary data to its string representation — a\r\nbehavior commonly used in obfuscation. This combination of behaviors is what triggered the initial detection and\r\nprompted further investigation.\r\nFigure 1: Behavior indicators extracted from VMConnect package.\r\nA detailed look at the __init__.py file confirmed the presence of malicious functionality inside the package. That\r\nstarted with that Base64 encoded string, which gets decoded and executed in another process.\r\nFigure 2: Execution of Base64 encoded string inside the __init__.py file.\r\nWhen we decode the string, we discovered that it contains a download URL which is modified based on the\r\ninformation collected from the host machine. The substring paperpin3902 in the command and control URL is\r\nreplaced with a string containing the first letter of the host’s platform name, username and a random, 6 character-long string.\r\nFigure 3: C2 URL template, extracted from the Base64 encoded string, gets modified based on host machine\r\ninformation.\r\nThe decoded and executed Base64 string contains an endless execution loop which contacts the command and\r\ncontrol (C2) server and attempts to download another Base64 encoded string with additional commands. If it\r\nsucceeds, that code is executed and the loop repeats, with the C2 server polled by the infected host for new\r\ncommands after a preconfigured sleep period.\r\nFigure 4: Command fetching and execution loop extracted from the Base64 encoded string present in the\r\n__init__.pyfile.\r\nAlthough the C2 server was live at the time of this research, the research team did not observe it serving any\r\ncommands. Since the command fetching is performed in an endless loop, it is possible that the operator of the C2\r\nserver uploads commands only after the infected machine is determined to be interesting to the threat actor.\r\nAlternatively, the C2 server could be performing some type of request filtering. For example, attackers may filter\r\nrequests based on the IP address of the infected machine to avoid infecting targets from specific countries.\r\nGithub misdirection\r\nThe VMConnect package was published on July 28th, by a developer named Hushki Manager — a throw-away\r\nPyPI account created the same day when its only package was published.\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 2 of 8\n\nFigure 5: PyPI profile of hushki502 user.\r\nDespite that, the actor did put a lot of effort into making the package look trustworthy. For example, it has a\r\nlegitimate-looking description, and that description corresponds to the functionality present inside the package.\r\nThreat actors often don’t make the effort to tidy up the project's description on the PyPI website.\r\nInstead, they often rely on simple typosquatting of package names in order to trick enough developers into\r\ninstalling their creation. For example, the threat actors behind the recently discovered Operation Brainleeches\r\ncampaign made minimal efforts to disguise their malicious packages, using default file names like index.html and\r\nDEMO.txt likely copied from phishing kits and minimally altered before being published.\r\nFigure 6: VMConnect package description.\r\nIn this campaign, however, the attackers took a more studied approach. In addition to reusing the description from\r\nthe actual packages, the attackers properly set links to a Github source code repository which was created by the\r\nsame author on the same day. The Github project site looks trustworthy, with a description matching the one on\r\nthe PyPI site and several commits and nothing obviously suspicious in the published files.\r\nFigure 7: Github profile of hushki502 user.\r\nFinally, the malicious actors took care to hide the malicious nature of this tool by omitting malicious functionality\r\nfrom the __init__.py file that was published to the Github repository.\r\nFigure 8: Benign version of__init__.py file present in Github repository.\r\nThe use of corresponding GitHub repositories to create the impression of a legitimate open source package is\r\nsomething we have seen before - and there’s a good explanation for why threat actors are taking the trouble to do\r\nthis.\r\nHistorically, many supply chain security solutions have relied on source code reviews of third party libraries.\r\nAttackers, therefore, have an incentive to throw code scanning tools and manual code reviewers off their scent.\r\nFor reviewers, PyPI projects tend to look more trustworthy if they have a corresponding link to a Github\r\nrepository that doesn’t seem arbitrary.\r\nIn the case of the malicious PyPI packages, the attacker created a phony Github repository with an identical name\r\nas the PyPI package and copied the entire functionality from the legitimate Github project into the corresponding\r\nPyPI project. However, the malicious functionality is not present within the source code. It is only by scanning the\r\nartifacts used in the build process that this threat would have been detected.\r\nReversingLabs observed a similar tactic used in the case of the npm coinminer discovered a year ago. In that\r\ncampaign, the content of the release package - a temporary “maintenance mode” website” — was also different\r\nfrom the content hosted in the corresponding source code repository. As with the current PyPI packages, malicious\r\ncontent was added to the legitimate public source code resulting in a PyPI release package that looks much the\r\nsame as the open source code it is built on, but with some subtle (and malicious) changes that are easily\r\noverlooked.\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 3 of 8\n\nThe lesson for development and application security teams is that release packages can (and do) contain malicious\r\nfunctionality which isn’t present in open source repositories and therefore can’t be detected with source code\r\nscanning or manual source code reviews alone. These teams need a method for detecting suspicious content in the\r\nfinal release packages themselves to avoid falling victim to supply chain attacks such as this VMConnect PyPI\r\ncampaign.\r\nImitation: The sincerest form of thievery\r\nIt is also educational to take a closer look at the methods the attackers in this case used to disguise their malicious\r\nintent, including dressing their malicious wares up to imitate legitimate and widely used open source packages.\r\nAs we noted above, the packages we detected mimic a variety of well known PyPI packages with wide\r\ndistributions, but serving very different ends. The common thread connecting the PyPI packages that were\r\nimitated appears to be nothing more than their popularity, measured in monthly downloads.\r\nIn each case, the attackers disguised their PyPI packages to look like these widely used and legitimate tools. That\r\nincluded copying the package description and pasting it into their imitation packages, simply replacing the\r\nlegitimate package name with the name of their impostor package.\r\nFrom the standpoint of a threat researcher or incident responder, their lack of effort makes the job of detecting the\r\nruse easier. In our research, a Google search for the first sentence of the description immediately revealed the\r\ncorresponding, legitimate package that was being mimickedAs visible in Figures 9 and 10, the descriptions of the\r\nPyPI packages and Github projects are identical, aside from the project name.\r\nFigure 9: Github description of the malicious VMConnect project.\r\nFigure 10: Github description of the legitimate vConnector project.\r\nIn this case, vConnector is a fairly popular package, first published nine years ago, with the last modification\r\nbeing committed to the Github repository almost four years ago. Download stats for this package show that it has\r\nalmost 40 thousand downloads per month. A large number of monthly downloads combined with the lack of\r\nrecent maintenance make this package a very good target for impersonation.\r\nOn July 19, seven different versions of a package titled osinfopkg were published to the PyPI repository and used\r\nto develop and test the malicious functionality that eventually got included into the VMConnect package.Since\r\nthis was a testing package, the malicious actor didn’t give too much care into making it look trustworthy, even\r\nthough it did create a dedicated Github repository containing two more projects.\r\nThen, on July 31, another package named ethter, was released. In this case, the threat actor impersonated the\r\npopular package eth-tester — a collection of tools for testing ethereum based applications which has more than 60\r\nthousand monthly downloads. As the ReversingLabs research team observed with the VMConnect package, the\r\nethter description was copied verbatim from the eth-tester package, with only the package name replaced.\r\nHere again, a phony Github repository was created and malicious functionality was hidden in the utils/based.py\r\nfile inside the corresponding PyPI package. The malicious file isn’t present in the Github source code repository,\r\nonly in the PyPI package. The threat actor also released the latest version of their malicious package with the\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 4 of 8\n\n1.10.1b1 version number. That is in line with the version numbering convention of the impersonated package, and\r\nis higher than the latest released version of the impersonated package. The same approach is applied to the\r\nmalicious quantiumbase package impersonating legitimate databases package.\r\nAttackers play Whac-a-Module\r\nFortunately for Python developers, none of the packages we detected were available for download for very long.\r\nMost, including the VMConnect package, were removed from PyPI within one to three days of being posted.\r\nBecause of limitations in the PyPI platform, we do not know the reason that these packages were removed:\r\nwhether they were detected by internal systems operated by PyPI itself, whether reports from ReversingLabs or\r\nother firms led to the takedowns, or whether the malicious actors themselves removed the packages. Efforts to get\r\na definitive answer from PyPI on the circumstances that led to the various take downs were not successful.\r\nHowever, we have observed that new malicious packages get published to PyPI on a daily basis, as soon as the\r\nprevious package is reported and removed from the PyPI repository. In other words, despite the detection and\r\nremoval of the packages described above, this malicious PyPI campaign is alive and ongoing. The quick response\r\nfrom threat actors to replace malicious PyPI packages suggests that this is a well-planned and organized campaign\r\nand that the malicious actors probably have a prepared list of packages suitable for imitation.\r\nQuestions linger on who, what, and why\r\nThere are lingering questions about key elements of this malicious, supply chain campaign. Among them: who (or\r\nwhat) posted the malicious packages, what the ultimate objective of the attacks is and why the campaign was\r\nlaunched.\r\nOn the question of who, we do not have sufficient telemetry to pinpoint a threat actor or actors as being\r\nresponsible for the latest campaign. By publishing the IOCs including command and control infrastructure we\r\nhave collected, however, we hope that others may be able to connect those with evidence of known attacks and\r\nthreat actors to help fill in the full picture behind this campaign.\r\nPrevious supply chain attacks utilizing PyPI, npm and other public repositories range from sophisticated\r\n(IconBurst) to unsophisticated (Operation Brainleeches). While the VMConnect campaign doesn’t have many of\r\nthe telltale signs of a sophisticated nation-state campaign, it is not a copy and paste “script kiddie” operation\r\neither. More data is required to reach conclusions about who or what is responsible for this PyPI malicious\r\ncampaign.\r\nSimilarly, the research team was unable to obtain the second stage deliverable used in these attacks. As noted, the\r\ncompromised endpoints ReversingLabs observed merely polled C2 servers waiting for further commands (and\r\npresumably downloads). But we were unable to observe any active exchanges, which could indicate that the\r\nmalicious actors were not actively using the infrastructure, or that the compromised endpoints we controlled were\r\nnot of interest to them.\r\nLacking any visibility into the later stages of this campaign, it is impossible to know what its ultimate purpose\r\nwas: theft of sensitive data or intellectual property? Surveillance? Ransomware? All of the above? More data that\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 5 of 8\n\nreveals the full breadth of this campaign is needed before we can speculate on its intent.\r\nIndicators of Compromise (IOCs)\r\nIndicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized\r\nactivity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber\r\nincident response efforts, helping analysts and cybersecurity professionals identify and detect potential security\r\nincidents.\r\nThe following IOCs were collected as part of ReversingLabs investigation of the VMConnect software supply\r\nchain campaign.\r\nCommand and Control (C2) domains and IP address:\r\n45.61.139.219\r\nethertestnet.pro\r\ndeliworkshopexpress.xyz\r\nPyPI packages:\r\npackage_name version SHA1\r\nVMConnect 1.1.7 b0095f149951241c6e11e0d1be1f74e8cdfbdbb2\r\nVMConnect 1.1.7 2ff1b3aa2dbff6d87447b250a8d19241e7853ab0\r\nosinfopkg 0.0.2 67226da423ab4a2c97b2d008dec45280aaa5fdf5\r\nosinfopkg 0.0.2 146942c5dbaba55be174b1bfb127410e332caa03\r\nosinfopkg 0.0.3 0eb79e80c51c0e14be3620dfb237f7b53160a292\r\nosinfopkg 0.0.3 bc2d48d6d9eeaf0b29625683942e90dfd2b75723\r\nosinfopkg 0.0.4 9a276ca3678898f5596166416f7e709a2064e95c\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 6 of 8\n\nosinfopkg 0.0.4 658605988c7afd9adf437fb64ff682cb4190f144\r\nosinfopkg 1.0.1 5f03b73d56528ecbc3f24b8e7daec6b3d3370834\r\nosinfopkg 1.0.1 19684554e4905bb3cf354a5d5a0f00d696f38926\r\nosinfopkg 1.0.2 e531121b137182453f0d120be860ad882d2dc0a7\r\nosinfopkg 1.0.2 b1f2d50be0aca0672475488d77c6f71a1b0633f8\r\nosinfopkg 1.0.3 de4e9efeace6ff76dc00a166dca152dc3021d799\r\nosinfopkg 1.0.3 664f0913a5952eeb77373f83e090fab7e94aa45e\r\nosinfopkg 1.0.4 bd7ba47f730c2bc33afa67a39d9cbe3768f62426\r\nosinfopkg 1.0.4 0dc723e77a5b97183a90eaecb62c9b7341e483ed\r\nethter 0.9.1b1 6bf76b01bd17f370cd3f9947135bf250597d1ac1\r\nethter 0.9.1b1 497df2fd2dba324be04cc57f50a3170b532aa70c\r\nethter 1.10.1b1 d404a55f1f7fbcd8b3156a84ebcf97c57ba24b95\r\nethter 1.10.1b1 9588affaf9d85e2141b9d76b914d9f89a8292574\r\nquantiumbase 0.7.0 dbc14c3ac0528a8aeb6edba8a0b2792dab131102\r\nquantiumbase 0.7.0 0b7b4444f820e9990dfeb5e2080321b5f25a9785\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 7 of 8\n\nquantiumbase 0.8.1 e6494b9a91862191556d77022e5577ddbe749ef4\r\nquantiumbase 0.8.1 a1b039f88c385f5c5eec2ef1701251c7341b1fcd\r\nConclusion\r\nThese latest examples of malicious packages on the PyPI platform are typical in many ways. They imitate popular\r\nand legitimate open source packages with tens of thousands monthly downloads and hide malicious functionality\r\ninside Base64 encoded strings which downloads additional commands from a C2 server. The ReversingLabs\r\nresearch team has seen many variations on this attack pattern in recent months.\r\nWhat does this mean for security teams and development organizations? The VMConnect campaign is a reminder\r\nthat threats lurk on open source repositories, and that standard practices like automated source code reviews are\r\nnot enough to smoke them out.\r\nSource code for the malicious modules published to GitHub was non malicious, but significantly different from\r\nthe content of the release packages that eventually get compiled into the release artifacts as third party\r\ndependencies. Clues that something was amiss — like Base64 encoded strings — were easy to spot, if you know\r\nwhere to look for them. Still, such indicators often escape notice by conventional application security testing and\r\nmanual code reviews.\r\nThe ReversingLabs Software Supply Chain Security platform can assist you in security assessments, helping sniff\r\nout signs of malicious functionality, assess third party package dependencies, and provide a wide range of\r\nbehavior indicators. These indicators can be extracted from various file formats and used to detect this type of\r\nthreat before it results in malicious code being deployed in your environment.\r\nSource: https://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nhttps://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.reversinglabs.com/blog/vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules"
	],
	"report_names": [
		"vmconnect-malicious-pypi-packages-imitate-popular-open-source-modules"
	],
	"threat_actors": [
		{
			"id": "dcba8e2b-93e0-4d6e-a15f-5c44faebc3b1",
			"created_at": "2022-10-25T16:07:23.816991Z",
			"updated_at": "2026-04-10T02:00:04.758143Z",
			"deleted_at": null,
			"main_name": "Lurk",
			"aliases": [],
			"source_name": "ETDA:Lurk",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434030,
	"ts_updated_at": 1775792010,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a4792923ea7c45526bfa14eafa04d2ce4b1edd27.pdf",
		"text": "https://archive.orkl.eu/a4792923ea7c45526bfa14eafa04d2ce4b1edd27.txt",
		"img": "https://archive.orkl.eu/a4792923ea7c45526bfa14eafa04d2ce4b1edd27.jpg"
	}
}