Cybercriminals have been known to approach their targets under the guise of company recruiters, enticing them with fake employment offers. After all, what better time to strike than when the potential victim is distracted by the possibility of getting a job? Since early 2024, ESET researchers have observed a series of malicious North Korea-aligned activities, where the operators, posing as headhunters, try to serve their targets with software projects that conceal infostealing malware. We call this activity cluster DeceptiveDevelopment.

As part of a fake job interview process, the DeceptiveDevelopment operators ask their targets to do a coding test, such as adding a feature to an existing project, with the files necessary for the task usually hosted on private repositories on GitHub or other similar platforms. Unfortunately for the eager work candidate, these files are trojanized: once they download and execute the project, the victim’s computer gets compromised with the operation’s first-stage malware, BeaverTail.

DeceptiveDevelopment was first publicly described by Phylum and Unit 42 in 2023, and has already been partially documented under the names Contagious Interview and DEV#POPPER. We have conducted further analysis of this activity cluster and its operator’s initial access methods, network infrastructure, and toolset, including new versions of the two malware families used by DeceptiveDevelopment – InvisibleFerret, and the aforementioned BeaverTail.

Key points of this blogpost:

• DeceptiveDevelopment targets freelance software developers through spearphishing on job-hunting and freelancing sites, aiming to steal cryptocurrency wallets and login information from browsers and password managers.
• Active since at least November 2023, this operation primarily uses two malware families – BeaverTail (infostealer, downloader) and InvisibleFerret (infostealer, RAT).
• DeceptiveDevelopment’s tactics, techniques, and procedures (TTPs) are similar to several other known North Korea-aligned operations.

We first observed this DeceptiveDevelopment campaign in early 2024, when we discovered trojanized projects hosted on GitHub with malicious code hidden at the end of long comments, effectively moving the code off-screen. These projects delivered the BeaverTail and InvisibleFerret malware. In addition to analyzing the two malware families, we also started investigating the C&C infrastructure behind the campaign. Since then, we have been tracking this cluster and its advances in strategy and tooling used in these ongoing attacks. This blogpost describes the TTPs of this campaign, as well as the malware it uses.

DeceptiveDevelopment profile

DeceptiveDevelopment is a North Korea-aligned activity cluster that we currently do not attribute to any known threat actor. Operators behind DeceptiveDevelopment target software developers on Windows, Linux, and macOS. They primarily steal cryptocurrency for financial gain, with a possible secondary objective of cyberespionage.

To approach their targets, these operators use fake recruiter profiles on social media, not unlike the Lazarus group in Operation DreamJob (as described in this WeLiveSecurity blogpost). However, while Operation DreamJob targeted defense and aerospace engineers, DeceptiveDevelopment reaches out to freelance software developers, often those involved in cryptocurrency projects. To compromise its victims’ computers, DeceptiveDevelopment provides its targets with trojanized codebases that deploy backdoors as part of a faux job interview process.

Victimology

The primary targets of this DeceptiveDevelopment campaign are software developers, mainly those involved in cryptocurrency and decentralized finance projects. The attackers don’t distinguish based on geographical location and aim to compromise as many victims as possible to increase the likelihood of successfully extracting funds and information.

We have observed hundreds of different victims around the world, using all three major operating systems – Windows, Linux, and macOS. They ranged from junior developers just starting their freelance careers to highly experienced professionals in the field. We only observed attacker–victim conversations in English, but cannot say with certainty that the attackers will not use translation tools to communicate with victims who don’t speak that language. A map showing the global distribution of victims can be seen in Figure 1.

Attribution

We consider DeceptiveDevelopment to be a North Korea-aligned activity cluster with high confidence based on several elements:

• We observed connections between GitHub accounts controlled by the attackers and accounts containing fake CVs used by North Korean IT workers. These people apply for jobs in foreign companies under false identities in order to collect salaries to help fund the regime. The observed connections were mutual follows between GitHub profiles where one side was associated with DeceptiveDevelopment, and the other contained fake CVs and other material related to North Korean IT worker activity. Similar connections were also observed by Unit42. Unfortunately, the GitHub pages were taken down before we were able to record all the evidence.
• The TTPs (use of fake recruiters, trojanized job challenges, and software used during interviews) are similar to other North Korea-aligned activity (Moonstone Sleet, and Lazarus’s DreamJob and DangerousPassword campaigns).

In addition to the connections between the GitHub profiles, the malware used in DeceptiveDevelopment is rather simple. This tracks with the reporting done by Mandiant claiming that the IT workers’ work is usually of poor quality.

While monitoring DeceptiveDevelopment activity, we saw numerous cases showing a lack of attention to detail on the part of the threat actors. In some of them, the authors failed to remove development notes or commented-out local IP addresses used for development and testing. We also saw samples where they seem to have forgotten to obfuscate the C&C address after changing it; this can be seen in Figure 2. Furthermore, the malware uses freely available obfuscation tools with links to them sometimes left in code comments.

Technical analysis

Initial access

In order to pose as recruiters, the attackers copy profiles of existing people or even construct new personas. They then either directly approach their potential victims on job-hunting and freelancing platforms or post fake job listings there. At first, the threat actors used brand new profiles and would simply send links to malicious GitHub projects via LinkedIn to their intended targets. Later, they started using profiles that appear established, with many followers and connections, to look more trustworthy, and branched out to more job-hunting and code-hosting websites. While some of these profiles are set up by the attackers themselves, others are potentially compromised profiles of real people on the platform, modified by the attackers.

Some of the platforms where these interactions occur are generic job-hunting ones, while others focus primarily on cryptocurrency and blockchain projects and are thus more in line with the attackers’ goals. The platforms include:

• LinkedIn,
• Upwork,
• Freelancer.com,
• We Work Remotely,
• Moonlight, and
• Crypto Jobs List.

The most commonly observed compromise vector consists of the fake recruiter providing the victim with a trojanized project under the guise of a hiring challenge or helping the “recruiter” fix a bug for a financial reward.

Victims receive the project files either directly via file transfer on the site or through a link to a repository like GitHub, GitLab, or Bitbucket. They are asked to download the files, add features or fix bugs, and report back to the recruiter. Additionally, they are instructed to build and execute the project in order to test it, which is where the initial compromise happens. The repositories used are usually private, so the victim is first asked to provide their account ID or email address to be granted access to them, most likely to conceal the malicious activity from researchers.

Despite that, we observed many cases where these repositories were publicly available, but realized that these belong mostly to victims who, after completing their tasks, uploaded them to their own repositories. Figure 3 shows an example of a trojanized project hosted on GitHub. We have reported all observed malicious code to the affected services.

The trojanized projects fall into one of four categories:

• hiring challenges,
• cryptocurrency projects,
• games (usually with blockchain functionality), and
• gambling with blockchain/cryptocurrency features.

These repositories are often duplicates of existing open-source projects or demos, with little to no change aside from adding the malicious code and changing the README file. Some of the malicious project names and names of attacker-controlled accounts operating them (where we could assess them) are listed in Table 1.

Table 1. Observed project names and repository/commit authors

We also observed the attackers impersonating existing projects and companies by using similar names or appending LLC, Ag, or Inc (abbreviations of legal company types) to the names, as seen in Table 2.

Table 2. Observed project names and repository/commit authors impersonating legitimate projects

The attackers often use a clever trick to hide their malicious code: they place it in an otherwise benign component of the project, usually within backend code unrelated to the task given to the developer, where they append it as a single line behind a long comment. This way, it is moved off-screen and stays hidden unless the victim scrolls to it or has the word wrap feature of their code editor enabled. Interestingly, GitHub’s own code editor does not enable word wrap, so the malicious code is easy to miss even when looking at code in the repository, as shown in Figure 4.

Another compromise vector we observed consisted of the fake recruiter inviting the victim to a job interview using an online conferencing platform and providing a link to a website from which the necessary conferencing software can be downloaded. The website is usually a clone of an existing conferencing platform’s website, as seen in Figure 5, and the downloaded software contains the first stage of the malware.

Toolset

DeceptiveDevelopment primarily uses two malware families as part of its activities, delivered in two stages. The first stage, BeaverTail, has both a JavaScript and a native variant (written in C++ using the Qt platform), and is delivered to the victim, disguised as a part of a project the victim is asked to work on, a hiring challenge, or inside trojanized remote conferencing software such as MiroTalk or FreeConference.

BeaverTail acts as a simple login stealer, extracting browser databases containing saved logins, and as a downloader for the second stage, InvisibleFerret. This is modular Python-based malware that includes spyware and backdoor components, and is also capable of downloading the legitimate AnyDesk remote management and monitoring software for post-compromise activities. Figure 6 shows the full compromise chain from initial compromise, through data exfiltration, to the deployment of AnyDesk.

Both BeaverTail and InvisibleFerret have been previously documented by Unit 42, Group-IB, and Objective-See. A parallel investigation was also published by Zscaler, whose findings we can independently confirm. Our analysis contains details that have not been publicly reported before and presents a comprehensive overview of the malicious activity.

BeaverTail

BeaverTail is the name for the infostealer and downloader malware used by DeceptiveDevelopment. There are two different versions – one written in JavaScript and placed directly into the trojanized projects with simple obfuscation, and native versions, built using the Qt platform, that are disguised as conferencing software and were initially described by Objective-See. Both versions have strong similarities in their functionalities.

This malware targets Windows, Linux, and macOS systems, with the aim of collecting saved login information and cryptocurrency wallet data.

It starts by getting the C&C IP address and port. While the IP addresses vary, the ports used are usually either 1224 or 1244, making the malicious network activity easily identifiable. In the JavaScript version, the IP address and port are obfuscated using base64 encoding, split into three parts, and swapped around to prevent automatic decoding. Other strings are also encoded with base64, often with one dummy character prepended to the resulting string to thwart simple decoding attempts. The native version has the IP, port, and other strings all stored in plaintext. The obfuscated JavaScript code can be seen in Figure 7, and the deobfuscated code in Figure 8.

BeaverTail then looks for browser extensions installed in the Google Chrome, Microsoft Edge, Opera, and Brave browsers and checks whether any of them match extension names from a hardcoded list from Chrome Web Store or Microsoft Edge Add-ons, shown below. The browser listed in parentheses is the source of the extension; note that both Opera and Brave also use extensions from Chrome Web Store, as they are Chromium-based.

• nkbihfbeogaeaoehlefnkodbefgpgknn – MetaMask (Chrome)
• ejbalbakoplchlghecdalmeeeajnimhm – MetaMask (Edge)
• fhbohimaelbohpjbbldcngcnapndodjp – BNB Chain Wallet (Chrome)
• hnfanknocfeofbddgcijnmhnfnkdnaad – Coinbase Wallet (Chrome)
• ibnejdfjmmkpcnlpebklmnkoeoihofec – TronLink (Chrome)
• bfnaelmomeimhlpmgjnjophhpkkoljpa – Phantom (Chrome)
• fnjhmkhhmkbjkkabndcnnogagogbneec – Ronin Wallet (Chrome)
• aeachknmefphepccionboohckonoeemg – Coin98 Wallet (Chrome)
• hifafgmccdpekplomjjkcfgodnhcellj – Crypto.com Wallet (Chrome)

If they are found, any .ldb and .log files from the extensions’ directories are collected and exfiltrated.

Apart from these files, the malware also targets a file containing the Solana keys stored in the user’s home directory in .config/solana/id.json. BeaverTail then looks for saved login information in /Library/Keychains/‌login.keychain (for macOS) or /.local/share/keyrings/ (for Linux). If they exist, the Firefox login databases key3.db, key4.db, and logins.json from /.mozilla/firefox/ are also exfiltrated during this time.

Each BeaverTail sample contains a victim ID used for identification. These IDs are used throughout the whole compromise chain as identifiers in all downloads and uploads. We suspect that these IDs are unique to each victim and are used to connect the stolen information to the victim’s public profile.

The collected data along with the computer hostname and current timestamp is uploaded to the /uploads API endpoint on the C&C server. Then, a standalone Python environment is downloaded in an archive called p2.zip, hosted on the C&C server, to enable execution of the next stage. Finally, the next stage is downloaded from the C&C server (API endpoint /client/) into the user’s home directory under the name .npl and executed using the downloaded Python environment.

In August 2024, we observed a new version of the JavaScript BeaverTail, where the code placed in the trojanized project acted only as a loader and downloaded and executed the actual payload code from a remote server. This version also used a different obfuscation technique and added four new cryptocurrency wallet extensions to the list of targets:

• jblndlipeogpafnldhgmapagcccfchpi – Kaia Wallet (Chrome)
• acmacodkjbdgmoleebolmdjonilkdbch – Rabby Wallet (Chrome)
• dlcobpjiigpikoobohmabehhmhfoodbb – Argent X – Starknet Wallet (Chrome)
• aholpfdialjgjfhomihkjbmgjidlcdno – Exodus Web3 Wallet (Chrome)

When investigating the ipcheck[.]cloud website, we noticed that the homepage is a mirror of the malicious mirotalk[.]net website, serving native BeaverTail malware disguised as remote conferencing software, indicating a direct connection between the new JavaScript and the native versions of BeaverTail.

InvisibleFerret

InvisibleFerret is modular Python malware with capabilities for information theft and remote attacker control. It consists of four modules – main (the .npl file), payload (pay), browser (bow), and AnyDesk (adc). The malware has no persistence mechanism in place aside from the AnyDesk client deployed at the end of the compromise chain. After gaining persistence via AnyDesk, the attackers can execute InvisibleFerret at will.

Interestingly, most of its backdoor functionality requires an operator (or scripted behavior) at the other side sending commands, deciding what data to exfiltrate and how to propagate the attack. In all versions of InvisibleFerret that we observed, the backdoor components are activated upon operator command. The only functionality not executed by the operator is the initial fingerprinting, which is done automatically.

Main module

The main module, originally named main, is the .npl file that BeaverTail downloaded from the C&C server and saved into the home directory. It is responsible for downloading and executing individual payload modules. All modules contain an XOR-encrypted and base64-encoded payload, preceded by four bytes representing the XOR key, followed by code to decrypt and execute it via exec, as seen in Figure 9. Each module also contains the sType variable, containing the current victim ID. This ID is a copy of the ID specified in the download request. When a request is made to download the script file, the given ID is placed as the sType value into the final script file by the C&C server’s API.

This module contains a hardcoded C&C address encoded with base64 and split into two halves that have been swapped to make decoding harder. In most cases that we observed, this address was identical to the one used in the preceding BeaverTail sample. The main module downloads the payload module from /payload/ to .n2/pay in the user’s home directory and executes it. Afterwards, if running on macOS (determined by checking whether a call to the platform.system function returns Darwin), it exits. On other operating systems it also downloads the browser module from /brow/ to .n2/bow in the user’s home directory and executes that in a separate Python instance.

Payload module

The pay module consists of two parts – one collects information and the other serves as a backdoor. The first part contains a hardcoded C&C URL, usually similar to the previously used ones, and collects the following:

• the user’s UUID,
• OS type,
• PC name,
• username,
• system version (release),
• local IP address, and
• public IP address and geolocation information (region name, country, city, ZIP code, ISP, latitude and longitude) parsed from http://ip-api.com/json.

This information, illustrated in Figure 10, is then uploaded to the /keys API endpoint using HTTP POST.

The second part acts as a TCP backdoor, and a TCP reverse shell, accepting remote commands from the C&C server and communicating via a socket connection. It usually uses port 1245, but we also observed ports 80, 2245, 3001, and 5000. Notably, the C&C IP address hardcoded in this part was different from the previous ones sometimes, probably to separate the more suspicious final network activity from the initial deployment.

The second payload checks whether it is executing under Windows – if it is, it enables a keylogger implemented using pyWinHook and a clipboard stealer using pyperclip, shown in Figure 11. These collect and store any keypresses and clipboard changes in a global buffer and run in a dedicated thread for as long as the script itself is running.

Afterwards, it executes the backdoor functionality, which consists of eight commands, described in Table 3.

Table 3. Commands implemented in InvisibleFerret

Each command is named with the prefix ssh_ and assigned a numerical value to be used when communicating with the server. For each command received, a new thread is spawned to execute it and the client immediately starts listening for the next command. Replies to commands are sent asynchronously as the commands finish executing. The two-way communication is done over sockets, in JSON format, with two fields:

• command – denoting the numerical command ID.
• args – containing any additional data sent between the server and client.

The script also contains lists of excluded file and directory names (such as cache and temporary directories for software projects and repositories) to be skipped when exfiltrating data, and a list of interesting name patterns to exfiltrate (environment and configuration files; documents, spreadsheets, and other files containing the words secret, wallet, private, password, etc.)

Browser module

The bow module is responsible for stealing login data, autofill data, and payment information saved by web browsers. The targeted browsers are Chrome, Brave, Opera, Yandex, and Edge, all Chromium-based, with multiple versions listed for each of the three major operating systems (Windows, Linux, macOS) as shown in Figure 13.

It searches through the browser’s local storage folders (an example is shown in Figure 14) and copies the databases containing login and payment information to the %Temp% folder on Windows or the /tmp folder on other systems, into two files:

• LoginData.db containing user login information, and
• webdata.db containing saved payment information (credit cards).

Because the saved passwords and credit card numbers are stored in an encrypted format using AES, they need to be decrypted before exfiltration. The encryption keys used for this are obtained based on the operating system in use. On Windows, they are extracted from the browser’s Local State file, on Linux they are obtained through the secretstorage package, and on macOS they are obtained through the security utility, as illustrated in Figure 15.

The collected information (see Figure 16) is then sent to the C&C server via an HTTP POST request to the /keys API endpoint.

AnyDesk module

The adc module is the only persistence mechanism found in this compromise chain, setting up AnyDesk access to the victim’s computer using a configuration file containing hardcoded login credentials.

On Windows, it checks whether the C:/Program Files (x86)/AnyDesk/AnyDesk.exe exists. If not, it downloads anydesk.exe from the C&C server (http://:/anydesk.exe) into the user’s home directory.

Then it attempts to set up AnyDesk for access by the attacker by entering hardcoded password hash, password salt, and token salt values into the configuration files. If the configuration files don’t exist or don’t contain a given attacker-specified password salt value, the module attempts to modify them to add the hardcoded login information. If that fails, it creates a PowerShell script in the user’s home directory named conf.ps1, containing code to modify the configuration files (shown in Figure 17) and attempts to launch it.

After these actions complete, the AnyDesk process is killed and then started again to load the new configuration. Lastly, the adc module attempts to delete itself by calling the os.remove function on itself.

InvisibleFerret update

We later discovered an updated version of InvisibleFerret with major changes, used since at least August 2024. It is no longer separated into individual modules, but rather exists as a single large script file (but still retaining the backdoor commands to selectively install the browser and AnyDesk modules). There are also slight code modifications for increased support of macOS, for example collecting the username along with the hostname of the computer.

Another modification we observed is the addition of an identifier named gType, in addition to sType. It acts as a secondary victim/campaign identifier in addition to sType when downloading modules from the C&C server (e.g., :///). We haven’t seen it used to label the exfiltrated data.

This new version of InvisibleFerret has also implemented an additional backdoor command, ssh_zcp, capable of exfiltrating data from browser extensions and password managers via Telegram and FTP.

With the new command, InvisibleFerret first looks for and, if present, collects data from 88 browser extensions for the Chrome, Brave, and Edge browsers and then places it into a staging folder in the system’s temporary directory. The complete list of extensions can be found in the Appendix and the code for collecting the data is shown in Figure 18.

Apart from the extension data, the command can also exfiltrate information from the Atomic and Exodus cryptocurrency wallets on all systems, in addition to 1Password, Electrum, WinAuth, Proxifier4, and Dashlane on Windows. This is illustrated in Figure 19.

The data is then archived and uploaded to a Telegram chat using the Telegram API with a bot token, as well as to an FTP server. Once the upload is done, InvisibleFerret removes both the staging folder and the archive.

Clipboard stealer module

In December 2024 we discovered yet another version of InvisibleFerret, containing an additional module named mlip, downloaded from the C&C endpoint /mclip/ to .n2/mlip. This module contains the keylogging and clipboard-stealing functionality that was separated from the rest of the payload module.

Showing an advancement in technical capabilities of the operators, the keylogging and clipboard stealing functionality of this module has been limited to two processes only, chrome.exe and brave.exe, while the earlier versions of InvisibleFerret logged any and all keystrokes. The collected data is uploaded to a new API endpoint, /api/clip.

Network infrastructure

DeceptiveDevelopment’s network infrastructure is composed of dedicated servers hosted by commercial hosting providers, with the three most commonly used providers being RouterHosting (now known as Cloudzy), Stark Industries Solutions, and Pier7ASN. The server API is written in Node.js and consists of nine endpoints, listed in Table 4.

Table 4. DeceptiveDevelopment C&C API endpoints

Most C&C communication we observed was done over ports 1224 or 1244 (occasionally 80 or 3000) for C&C communication over HTTP, and 1245 (occasionally 80, 2245, 3001, 5000, or 5001) for backdoor C&C communication over TCP sockets. All communication from the client to the C&C server, except downloading the Python environment, contains the campaign ID. For InvisibleFerret downloads, the ID is added to the end of the URL in the GET request. For data exfiltration, the ID is sent as part of the POST request in the type field. This is useful for identifying network traffic and determining what specific sample and campaign it belongs to.

The campaign IDs (sType and gType values) we observed are alphanumeric and don’t seem to bear any direct relation to the campaign. Before the introduction of gType, some of the sType values were base64 strings containing variants of the word team and numbers, such as 5Team9 and 7tEaM;. After gType was introduced, most observed values for both values were purely numeric, without the use of base64.

Conclusion

The DeceptiveDevelopment cluster is an addition to an already large collection of money-making schemes employed by North Korea-aligned actors and conforms to an ongoing trend of shifting focus from traditional money to cryptocurrencies. During our research, we observed it go from primitive tools and techniques to more advanced and capable malware, as well as more polished techniques to lure in victims and deploy the malware. Any online job-hunting and freelancing platform can be at risk of being abused for malware distribution by fake recruiters. We continue to observe significant activity related to this campaign and expect DeceptiveDevelopment to continue innovating and searching for more ways to target cryptocurrency users.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

A comprehensive list of indicators of compromise (IoCs) and samples can be found in our GitHub repository.

Files

Network

MITRE ATT&CK techniques

This table was built using version 16 of the MITRE ATT&CK framework.

Appendix

Following is a list of browser extensions targeted by the new InvisibleFerret: