{
	"id": "e61ac633-63f6-4579-b079-ec7e8b2b2f44",
	"created_at": "2026-04-06T00:17:16.264379Z",
	"updated_at": "2026-04-10T13:12:53.858342Z",
	"deleted_at": null,
	"sha1_hash": "6a8ca8b97aa689ad42f5995f953ce8eff19621ad",
	"title": "Qealler — The Silent Java Credential Thief",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3298698,
	"plain_text": "Qealler — The Silent Java Credential Thief\r\nBy David Cohen\r\nPublished: 2019-01-17 · Archived: 2026-04-05 14:48:29 UTC\r\nQealler is a new type of malware that CyberArk Labs recently detected in a spam campaign targeting corporate\r\nmailboxes in the UK. At first sight, it looks to be a simple, harmless file that can be detected by antivirus software.\r\nHowever, our analysis shows that there’s more to it.\r\nQealler very efficiently hides a dropper and credential stealing script. Bypassing antivirus protection, it can capture\r\nmore than 20 third-party software and Windows credentials and use them to access sensitive files.\r\nIn this blog, we’ll share our malware analysis – including insight into the information returned to the attacker. We’ll\r\nalso share best practices for protecting against it.\r\nQealler in the Wild\r\nFigure 1 Older Qealler samples found, only 5/61 positives on VirusTotal (VT).\r\nQealler was first detected in August 2018 by James_inthe_box[i] [fig. 1] and determined to be mainly hosted on UK\r\nwebsites. Since it has a very low engine detection rate, as shown in the screenshot above, a lot of antiviruses\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 1 of 13\n\nconsider it to be a safe file and don’t block it.  In short, the door is open for the execution of this malware without\r\nany problems.\r\nAs seen in the detected samples in figure 2 from URLhaus[ii], Qealler disguises itself as a Remittance Advice\r\nFile[iii]. URLhaus is a project by abuse.ch with the goal of sharing malicious URLs being used for malware\r\ndistribution.\r\nFigure 2 URLs hosting the malware are from UK.\r\nMost recently, we detected Qealler in a spam campaign targeting UK users. As you can see in figure 1, it’s mostly\r\npresent as a Jar file, which is a package file format typically used to aggregate many Java class files and their\r\nassociated metadata and resources (text, images, etc.) into one file for distribution. It’s acting as an executable\r\nrunning in the Java Virtual Machine[iv].\r\nTechnical Analysis\r\nQealler can be difficult to detect because of its high-level and multi-layer self-encryption, which has different keys\r\nfor each malware sample coupled with tricky obfuscation in every sub-file. This means that it can decrypt and\r\ncompile itself in multiple steps. Basically, using a signature-based approach, as most of the anti-viruses do for this\r\nkind of malware, would not protect against other Qealler samples.\r\nHere we’ll examine the recent sample we found:\r\n61a8b7f9260d163d0f20059bf21d6c55954ee77b0588610bfab4907dd964cf6a[v].\r\nThe first question is: how do we know it’s a malicious file? Some versions have a really low detection rate on\r\nVirusTotal (VT) [fig. 1]. Moreover, when we ran it for the first time, nothing seemed to happen. If we run it a second\r\ntime, a message box [fig. 3] appears. That’s strange for remittance advice.\r\nLet’s see what we can learn from procmon logs about its behavior.\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 2 of 13\n\nFigure 3 What happens when Qealler is run more than two times.\r\nUsing procmon, we see that Qealler is trying to communicate with 146[.]185[.]139[.]123:7766, but fails. Indeed, this\r\nIP was already down the day of the analysis. Instead, we’ll try to use the first IP in the table in figure 2 (i.e.,\r\n159[.]65[.]84[.]42:11530), which was online at the time of writing this. How can we redirect all the packets sent to\r\nthe active server?\r\nFigure 4 ProxyCap configuration to redirect IP.\r\nIn our case, we use ProxyCap[vi]. ProxyCap enables you to redirect your computer’s network connections through\r\nproxy servers. You can tell ProxyCap which applications to connect to the internet through a proxy and under what\r\ncircumstances. This is done through a user-friendly interface without the need to reconfigure any of your internet\r\nclients.\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 3 of 13\n\nFigure 5 Successfully redirected packet and received packets!\r\nConfiguring ProxyCap is an easy game. You have to define two things: 1.) the proxy server – the destination IP\r\naddress where redirected packets should be sent; and 2.) the rule – the indicator needed to spot, according to their\r\ninitial destination IP addresses, which packets to redirect . After configuring ProxyCap [fig. 5], let’s try  to open the\r\nQealler file again and check the behavior on procmon.\r\nCongratulations! The redirection was a success and, in return, we received a packet triggering a new set of events\r\nfrom Qealler. Let’s dig into the huge procmon log for more good stuff.\r\nOne thing we like to check before everything else when using procmon is the process create event.\r\nFigure 6 Process created by Qealler.\r\nQealler created two processes [fig.6]:\r\n… executable, decompressing another file in the windows temporary folder referred as %TEMP%. The exact\r\ncommand executed by this executable is:\r\n%TEMP%\\7z_\u003cRANDOM_NB\u003e.exe x %TEMP%\\_\u003cRANDOM_NB\u003e.tmp -o %TEMP%\r\n-p \"\u003cPW\u003e\" -mmt -aoa -y\r\nexe executed with the following parameters:\r\n%TEMP%\\qealler\\python\\Python.exe %TEMP%\\qealler\\qazagne\\main.py all\r\nLooking at the first process created, it appears Qealler is decrypting a password-protected file using 7z after\r\nreceiving a packet from the server. Procmon logs give us more information: Qealler has created four files: three\r\nrelated to 7zip executable (two dlls and one executable) and the password-protected archive. So, finally, Qealler is\r\neither including those files (using a packer[vii]) or downloading them. The second option seems more logical if we\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 4 of 13\n\nlook at the size of the malware. First, let’s dive deeper into this archive and then reverse Qealler to understand the\r\nexact way it works.\r\nFigure 7 File tree of the downloaded archive using TreeSize.\r\nThe password-protected archive contains two folders [fig. 7]. One contains a python script called Qazagne and the\r\nother contains the python software with all of the  libraries required to run the script.\r\nThe script is not called Qazagne for nothing. Indeed, the script is a compact version of the famous credential\r\nrecovery tool Lazagne.[viii] The LaZagne project is an open source application used to retrieve lots of passwords\r\nstored on a local computer [fig. 8]. Each software stores its passwords using different techniques (plaintext,\r\nWindows APIs, custom algorithms, databases, etc.). This tool was developed for the purpose of finding these\r\npasswords for the most commonly used software. The output is a list of credentials in JSON format.\r\nWhy does Qealler steal all those credentials? Why is it bypassing AVs? Is it a dropper or a packed malware? Let’s\r\ndig deeper.\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 5 of 13\n\nFigure 8 Lazagne credentials target very similar to Qazagne target [ix]\r\n.\r\nReversing Qealler\r\nIn order to learn more about Qealler’s inner workings, we decided to reverse it. A JAR archive can be easily\r\ndecompressed using different tools (WinRAR, JarExplorer, Java Decompressor etc.). Once decompressed, you get\r\nall the compiled Java class files. The next step is to decompile them with tools like JD-Eclipse, Cavaj Java\r\nDecompiler or JBVD. Let’s apply this to our sample.\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 6 of 13\n\nFigure 9 Content inside the Jar archive decompressed with JavaDecompressor.\r\nAt a first look [fig. 9], the files obtained from JavaDecompressor seem weird. There’s only one class file\r\n(com.aglyphodonta.naiadaceous.Piezoelectric) and other files with unknown extensions. In other words, the files\r\nseem to be encrypted.\r\nLet’s focus on the Piezoelectric.class file and decompile it with JBVD[x] . The decompiled source code obtained\r\n[fig. 10] is quite simple. It uses the ScriptEngineManager object configured in Javascript mode in order to execute\r\nthe script defined in the abettors’ variable.\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 7 of 13\n\nFigure 10 Decompiled Piezoelectric file.\r\nThe serious part begins now. The JavaScript part [fig. 11] is our key to decrypt some of the encrypted files in the\r\narchive. As you can see in figure 11, it is obfuscated. Nonetheless, the main function calls (purple) and their\r\ndefinitions in the java documentation suggest that it’s a decryption process and you can identify the decryption key\r\nas well. The variable [fig. 11] in green contains everything:\r\nDecrypted class package name: enterprise.reaqtor.reaqtions.standartbootstrap\r\nDecrypted class name: Header\r\nFile to decrypt: com/agliphodonta/eparchies/Reticulatocoalescent.ski\r\nFile size in bytes: 6251\r\nDecryption key: xml1JzxHQcBFVSiJ\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 8 of 13\n\nFigure 11 JS script embedded in the main java class.\r\nSo, now we have everything. The script decrypted the file com/agliphodonta/eparchies/Reticulatocoalescent.ski\r\nusing AES-256 with the key xml1JzxHQcBFVSiJ.\r\nThe decrypted file (with a file size of 6256 bytes) is saved in a file called Header (also the name of the class) in the\r\npackage qua.enterprise.reaqtor.reaqtions.standartbootstrap. Finally, the class is instantiated and executes the\r\nconstructor and main function of the Header Class.\r\nNow that we understand the behavior, we can easily write a function that does the same thing and save the decrypted\r\nfile in order to be able to read it.\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 9 of 13\n\nFigure 12 Script to decrypt the Reticulatocoalescent.ski file.\r\nThe output of our script [fig.12] is a java class called Header. It contains a map. By changing the source code a little\r\nto look at the content stored in the map object, we discovered that it stores all the remaining encrypted files and their\r\noriginal file names. It was not clear at first because it uses the map to decrypt only three files (Head, Loader$1 and\r\nLoader$1$1) out of a lot of files.\r\nAnother important point is that there are not only AES encrypted files this time (using a different key than before),\r\nbut also a Gzip compressed file. Even with the high obfuscation, we can still identify the next decrypted class that\r\nwill be instantiated afterwards (aka Head class).\r\nNow that we know the map contains all of the remaining files, what happens if we can do it all over again, but this\r\ntime add in some code to save all the files in the decryption function? We tried and obtained something astonishing.\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 10 of 13\n\nFigure 13 Files obtained decrypting all the content of the map.\r\nThe result is, as you can see [fig. 12], very obfuscated. Moreover, a lot of obfuscation mechanisms are used: useless\r\nfunctions with long and closed names; functions that return the object itself; filenames above 256 characters, which\r\ncause problems with a lot of software (including Windows Explorer); etc.\r\nWe could have spent a lot of time refactoring and simplifying the code to have something that can at least be\r\ncompiled (though still obfuscated), but instead we chose to analyze the malware’s behavior based on the static\r\nanalysis (i.e., looking for static analysis’ indicators in the reverse source code).\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 11 of 13\n\nFigure 14 Encrypted URL found in the source code.\r\nLet’s quickly look  at those files to see if something can help us. In this type of malware, you’ll usually look for the\r\nnext stage it will download from a URL or unpack from within. Indeed, figure 13 contains the variables found in one\r\nof the obfuscated files. Clearly, we can detect two important variables: LIB_7Z_URL and LIB_QEALLER_URL,\r\nwhich prove that Qealler is a dropper.\r\nThanks to our knowledge of the behavior so far, in the Head file, which is the real main class, we easily spotted the\r\npart of the code responsible for downloading 7z and the Qealler archive from the server [fig. 13], decompressing it\r\nand executing the python Qazagne script. Moreover, after the execution of the script, Qealler is looking for #ff# and\r\n#fs# strings in the output of the python script.\r\nInterestingly, that is exactly what we got: a JSON format output with those strings at the start and the end of the\r\noutput. These are clearly not correct JSON syntax and so there must be a difference between the original Lazagne\r\nscript and this compressed and fake one. All the important information is between those tags.\r\nThe next step is to send them to the server. From there, we got everything from the script : the JSON is encrypted\r\nusing AES 256 bytes again with another key and the packet data will contain “output=XXX” with XXX being the\r\nencrypted message. We found it on Wireshark and using decryption on it with the key found by reversing Qealler\r\ngives you the exact content of the JSON.\r\nMitigation\r\nSo how do we protect against similar threats? A multi-layer protection strategy is best.\r\nAn updated and well-configured antivirus solution should be your first wall of defense. While an antivirus will\r\ndetect and block some threats, dynamic, rapidly evolving and highly obfuscated threats like Qealler will likely go\r\nundetected.\r\nCase in point: In June, only 5 out of 61 well known and widely deployed AV engines detected it as a threat [fig.2].\r\nAs Qealler’s old samples signatures are being added to AV databases, Qealler can still improve and reinforce its\r\nobfuscation mechanism so that it can continue to bypass AV signatures.\r\nMoreover, AVs and a lot of protection tools have been built to block known attacks and attacks using the same\r\ntechniques, but cannot block new attacks. As a consequence, AVs are clearly not enough.\r\nQealler executes a python script targeting sensitive resources. Having defense in depth on the endpoint is a good\r\nway to prevent this kind of new attack. For example, solutions like CyberArk’s Endpoint Privilege Manager (EPM)\r\ncan protect endpoint credential stores that reside in memory, registry or files. EPM also has the ability to block\r\nlateral movement like Pass-the-hash, Pass-the-ticket and more. With this product, it does not matter if the malware\r\nbypasses traditional security protections: you can rest assured that critical resources are protected.\r\n[i] https://twitter.com/James_inthe_box/status/1035190253697396737\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 12 of 13\n\n[ii] https://urlhaus.abuse.ch/browse/tag/Qealler/\r\n[iii] https://en.wikipedia.org/wiki/Remittance_advice\r\n[iv] https://www.javaworld.com/article/3272244/core-java/what-is-the-jvm-introducing-the-java-virtual-machine.html\r\n[v]\r\nhttps://www.virustotal.com/#/file/61a8b7f9260d163d0f20059bf21d6c55954ee77b0588610bfab4907dd964cf6a/detection\r\n[vi] http://www.proxycap.com/\r\n[vii] https://en.wikipedia.org/wiki/Executable_compression\r\n[viii] https://github.com/AlessandroZ/LaZagne\r\n[ix] https://github.com/AlessandroZ/LaZagne\r\n[x] https://github.com/Konloch/bytecode-viewer\r\nSource: https://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nhttps://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.cyberark.com/threat-research-blog/qealler-the-silent-java-credential-thief/"
	],
	"report_names": [
		"qealler-the-silent-java-credential-thief"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434636,
	"ts_updated_at": 1775826773,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6a8ca8b97aa689ad42f5995f953ce8eff19621ad.pdf",
		"text": "https://archive.orkl.eu/6a8ca8b97aa689ad42f5995f953ce8eff19621ad.txt",
		"img": "https://archive.orkl.eu/6a8ca8b97aa689ad42f5995f953ce8eff19621ad.jpg"
	}
}