{
	"id": "0c89648a-d2f8-4d38-881e-bfa1542d7a96",
	"created_at": "2026-04-06T00:15:21.009453Z",
	"updated_at": "2026-04-10T03:37:09.102798Z",
	"deleted_at": null,
	"sha1_hash": "09ca32266ae216a4203175e587ad92a9d9341a20",
	"title": "FickerStealer: A New Rust Player in the Market",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1908641,
	"plain_text": "FickerStealer: A New Rust Player in the Market\r\nBy Ben Cohen\r\nPublished: 2021-07-19 · Archived: 2026-04-05 13:06:17 UTC\r\nThis blog introduces a new information stealer, written in Rust and interestingly named FickerStealer. In this\r\nblog post, we provide an in-depth analysis of this new threat and its obfuscation techniques, including an\r\nIDAPython deobfuscator script.\r\nBackground\r\nFickerStealer is an exceptional information stealer, first seen in the wild in August 2020. This info-stealer was\r\nsold on underground forums as a MaaS (Malware-as-a-service) by a seller named @ficker (@ficker_sup on\r\nTelegram). The average price of an information stealer is $200, and it varies depending on their additional\r\ncapabilities and the subscription time for the service. The price for FickerStealer cost ranges between $90 up to\r\n$900, and it only depends on the subscription time to the service.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 1 of 20\n\nFigure 1: FickerStealer post on a known Russian forum\r\nOnce a buyer purchases the Ficker service, an “on-prem” package will be provided, including the C2 server setup\r\n(called Panel) and the stealer executable (called Build). After the purchase, the buyer is required to specify what\r\nthe C2 server’s address will be, so the malware author (the seller) will configure the malware (build) to\r\ncommunicate with the attacker’s C2 server.\r\nOne of the more surprising things about FickerStealer is that it’s written in Rust and Assembly. Rust language isn’t\r\na natural choice for malware developers. While it is very fast and memory-efficient and runs on embedded\r\ndevices, developers might take a longer time to learn Rust because of its complexities. The advantages of this\r\nprogramming language are not utilized to their fullest when building malware, except that it’s difficult to reverse\r\nengineer it. Because of that, there are few known malware families written in Rust, so it was a bit surprising to\r\nfind a new Rust infostealer.\r\nFickerStealer has quickly gained popularity among cybercriminals on underground forums because of its\r\nattractive price and interesting and different methodology as an information stealer (we will dive into that later).\r\nThe malware received many good reviews from customers. For example: “I use it for targeted attacks, in a\r\ncouple of months the product showed itself at its best, I recommend.” It even received an excellent review from\r\nsome known underground forum moderators — the dream of every malware author.\r\nFigure 2: Part of the forum moderator review (translated from Russian)\r\nThe malware is used to steal sensitive information, including login credentials, credit card information,\r\ncryptocurrency wallets and browser information from applications such as WinSCP, Discord, Google Chrome,\r\nElectrum, etc. It does all that by implementing a different approach than other stealers (we’ll cover it later).\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 2 of 20\n\nAdditionally, FickerStealer can function as a File Grabber and collect additional files from the compromised\r\nmachine, and it can act as a Downloader to download and execute several second-stage malware.\r\nDelivery Methods – Malware Distribution\r\nWe noticed that FickerStealer is primarily delivered by two different methods: Exploit kit – RigEK and\r\nMalspam – Hancitor.\r\nRigEK –The victims enter a malicious/compromised website. The malicious website acts as a gate that can\r\nperform some checks of the user characteristics, like host machine, GeoIP, user-agent, etc. In case this type\r\nof user is targeted, the user is redirected to the RigEK landing page.\r\nThe landing page scans and profiles the victim’s browser and checks if it is vulnerable to any of the exploit\r\nkit vulnerabilities (most of them are 1-day vulnerabilities). In case the browser is vulnerable, the landing\r\npage executes the exploit to load the malware payload.\r\nHancitor – Malicious spam campaigns have proven to be an efficient infection vector. The malware is\r\ndelivered via targeted phishing emails with malicious macro-based documents attached. The macro drops\r\nthe Hancitor loader, which then injects the final payload using process hollowing. It’s worth mentioning\r\nthat we found many samples of FickerStealer that Hancitor delivers. If you are interested in more\r\ninformation about Hancitor, you should check Binary Defense’s blog.\r\nFigure 3: Hancitor loading Ficker payload in a sandbox environment\r\nTechnical Overview\r\nAs we mentioned earlier, Ficker is written in Rust, making the analysis complex and challenging because it’s\r\ncompiled differently than C/C++ language. On top of that, the Ficker executable is also heavily obfuscated.\r\nFikcerStealer’s main objective, like all credential theft malware, is to gather as much sensitive information as\r\npossible. Before we  dive into analyzing FickerStealer‘s features, the following are the main diffrencess between\r\nFicker and other stealers:\r\nFicker doesn’t have dependencies. It doesn’t need to download/load other DLLs like dll, nss3.dll on\r\nruntime to fulfill its stealing capabilities.\r\nThe communication channel with the C2 server is encrypted/obfuscated from the client-side, unlike\r\nmost stealers that rely on HTTP protocol and send the data as plain text.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 3 of 20\n\nFicker sends the stolen data after each successful stealing operation and by doing that, it doesn’t write\r\nany logs/files to disk. Other stealers write the stolen data to some temp folder, compress it and send it as a\r\nzip file to the C2 server. In addition, Ficker sends the sensitive Mozilla browser data to the C2 server and\r\ndecrypts it on the server-side.\r\nThe Downloader feature can download and execute several PE files, including executing malicious\r\nexecutables and loading DLLs.\r\nFicker tries to make its malware more reliable and stealthier than other stealers.\r\nFigure 4: Malware flow\r\nIn-depth Analysis\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 4 of 20\n\nAs far as we know, the first Rust malware was spotted in the wild in 2016. So far, we haven’t heard about many\r\nRust malware families or any trend of writing malware in Rust among malware developers as we have seen lately\r\nwith Golang. Most of the Rust malware we stumbled upon, like Telebots backdoor, contains Rust debug\r\ninformation, which makes our life easier while analyzing those Rust samples. Unfortunataley, in our case, the\r\ndebug information of our FickerStealer sample is stripped out, making the analysis more difficult.\r\nAs you can probably guess, we began by opening it in IDA, and we noticed that there are no symbols for Rust\r\nfunctions (or any developer functions). In addition, we could easily tell that the sample was heavily obfuscated: all\r\nthe strings are encrypted; it uses many dynamic calls; and most of the functions are just wrappers on wrappers\r\nwith minor modifications.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 5 of 20\n\nFigure 5: Part of Ficker’s WinMain function\r\nLet’s see how we approached the task of dissecting the malware.\r\nOur mindset was to first “map” the malware by finding its strings, as that would reveal the malware’s functionality\r\nand allow us to make educated guesses about what a snippet of code or function does.\r\nStrings Obfuscation\r\nThe problem is that all Ficker’s strings are obfuscated, including API function names, C2 server address, mutex\r\nname, sensitive and targeted file names, etc. As mentioned, revealing those strings can shed some light on the\r\nmalware capabilities and IoCs.\r\nWhile analyzing Ficker’s string decryption process, we found that Ficker doesn’t decrypt all the strings at once\r\nlike Oski Stealer does. It decrypts each string at a different location on runtime just before it uses it. Therefore, we\r\nhad to find the string decryption function and find every call to it.\r\nAlso, while going over the malware, we noticed many dynamic calls, so we started debugging it. Ficker tries to\r\nhide its call to the string decryption function (string_decrypt) by obfuscating the function address. It calculates the\r\nfunction’s address by using different instructions and different offsets. In figure 6 (highlighted with red boxes),\r\nyou can see a simple dynamic call to string_decrypt using short and straightforward obfuscation (which is not the\r\ncase in most calls to string_decrypt).\r\nFigure 6: Obfuscated call to string_decrypt function\r\nIn our case, the string decryption function is at 0x42572C (0x431192 + 0xFFFF459A). Our next step is finding\r\nwhere the function is called; however, when we checked the xrefs for this function, we saw that it had no\r\nreferences.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 6 of 20\n\nFigure 7: string_dercypt function has no references\r\nWe believe there are two reasons for this:\r\n1. The malware calls this function dynamically in an obfuscated way, as we saw earlier, or\r\n2. It has other string decryption routines (which is not likely.)\r\nBefore digging into this issue, let’s focus on the string_decrypt function.\r\nString Decryption Function\r\nThe string decryption function receives three arguments: a destination pointer to write the decrypted string, the\r\nstring length and the pointer to the obfuscated string.\r\nThe obfuscated string has a pretty simple structure. The first four bytes are the key for the decryption algorithm,\r\nand the rest of the bytes (as the size of the string length argument) are the encrypted string.\r\nAfter delving deeper into the function, we noticed a few things:\r\n1. The pointer for the obfuscated string is also obfuscated; the pointer is not the one for the “real” structure\r\n(that we described before).\r\n2. The function first calculates the “real” address and retrieves the encrypted string and the decryption key.\r\n3. After getting the “real” structure, the function implements the decryption algorithm.\r\nThe function uses a hardcoded constant to calculate the address of the “real” string structure. As much as we know\r\n— and at the time of writing this blog post — this constant remains the same in all Ficker’s samples. It’s 0x25.\r\nThe address of the structure is calculated in this way:\r\nenc_struc = obf_addr + string_dec_const * str_len – 4.\r\nFor example, the function gets the address 0x436FF8 (obf_addr) and the length of the decrypted string which is\r\n0x06 (str_len). Eventually, we’ll get the address 0x437494 that holds the “real” string structure for Pidgin.\r\nAfter getting the “real” address, the function decrypts the string using a simple decryption algorithm.\r\nWe wrote an IDAPython script that simulates the string_decrypt  function, including the decryption algorithm.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 7 of 20\n\nFigure 8: IDAPython script for string_decrypt  function\r\nAfter writing a script that can decrypt any string, we just need to find where it’s called and what the parameters are\r\nfor each call (on every location).\r\nIt sounds like a great mission for an IDAPython script! If you remember, we noted that it is more likely that\r\nstring_decrypt will be called on runtime.\r\nLet’s break our mission into tasks:\r\n1. Find all dynamic calls in the binary — find all call instructions with some register (e.g., call eax).\r\n2. Calculate the address in the register (can be obfuscated) and compare the calculated address to\r\nstring_decrypt function’s address.\r\n3. Get the function arguments’ values (string length, pointer to obfuscated string structure), which can also be\r\nobfuscated.\r\n4. Use our IDAPython str_decrypt function to decrypt the string (figure 8).\r\nThe interesting part is how we can deal with Ficker’s obfuscation. Ficker mostly uses obfuscation techniques like\r\ncalculating the data, using useless instructions and pushing-popping data.\r\nTo deal with that, we wrote two IDAPython functions get_value, get_ref.\r\nThe primary function (get_value) is a recursive function, which gets the instruction’s address as an argument and\r\nreturns the value used on this instruction, e.g., the address of push ebx will return the value ebx holds.\r\nBut a question comes to mind: How can we find it? We use the get_ref function that gets this instruction’s address\r\nand the operand index as arguments and returns the first reference to the given operand.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 8 of 20\n\nThe get_value function first identifies the instruction (call, mov, lea, add instruction, etc.’). Therefore, we can tell\r\nthat it knows which operand may contain the data and checks this operand’s type if it is mem_addr or imm_value.\r\nThese types of operand indicate if it’s a piece of data that’s stored as part of the instruction itself instead of being\r\nin a memory location or a register. In case the operand holds any value (mem_addr/imm_value), the function will\r\nreturn this value. Otherwise, the function gets a reference to this operand by calling get_ref and then it calls\r\nrecursively to itself with the new instruction’s address. The recursive function breaks when it finds\r\nmem_addr/imm_value.\r\nLet’s see how it works with an example. The goal here is to find the address for the call on 0x415C6A:\r\n.text:00415C51 lea eax, loc_4342CA+2\r\n.text:00415C57 lea ecx, unk_437BEF\r\n.text:00415C5D mov [edi], eax\r\n.text:00415C5F mov eax, 0FFFF1460h\r\n.text:00415C64 add eax, [edi]\r\n.text:00415C66 push ecx\r\n.text:00415C67 push 21h ; '!'\r\n.text:00415C69 push esi\r\n.text:00415C6A call eax\r\nCode Snippet 1: Disassembly snippet from Ficker’s binary\r\nWe call our recursive function with the address 0x415C6A to find the address of eax. The function checks the type\r\nof the relevant operand (in this case, the first one because it’s a call instruction). The operand is a register, which is\r\nnot a mem_addr/imm_value. Therefore, the function searches for a reference to this operand (eax). The function\r\ncalls itself with the new address of the reference, 0x415C64.\r\nAnd again, it checks the type of both operands because it add instruction and searches a reference for both\r\noperands (eax and edi). After the function finds those registers’ values recursively, it finally will return the sum of\r\nthem.\r\nFicker Deobfuscator: An IDAPython script\r\nYou can find our IDAPython deobfuscator in our Malware Research repository — FickerStealer.\r\nWe gathered all those parts together and added more functionalities into one IDAPython script. The script defeats\r\nFicker’s obfuscation and decrypts all the strings along the binary that Ficker uses.\r\n1. The script finds the decryption function address by searching (using pattern-based) the string’s decryption\r\nalgorithm.\r\n2. It obtains the addresses of all dynamic calls in the binary, and for each one, deobfuscate the address on the\r\ncall instruction and compares it to the decryption function address.\r\n3. It gets the arguments (by stack) of the string decryption call; the string decryption function gets three\r\narguments (destination pointer, string length and a pointer to the obfuscated string.)\r\n4. It gets the data that the arguments should hold.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 9 of 20\n\n5. Deobfuscate the string using the function get_obf_string, which gets the pointer for the obfuscated string\r\nand the string length.\r\n6. This function returns the decrypted string.\r\nFigure 9: FickerStealer’s deobfuscator usage\r\nThe script also sets a reference to string_decrypt function, adds a comment with the decrypted string and dumps\r\nall the data to a JSON file.\r\nAnd now, having collected the fruits of our labor, our deobfuscator script was able to identify 191 calls to the\r\nstring decryption function (string_decrypt) and to decrypt 182 strings in this sample.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 10 of 20\n\nFigure 10: References for string_decrypt function\r\nFinally, after we got all Ficker’s strings, we have an idea about what most functions and code parts do, so we can\r\nnow move forward.\r\nC2 server communication\r\nEstablishing Connection\r\nFicker holds the address and port for the C2 server as an encrypted string, IP:PORT, which can be easily identified\r\nby running the IDAPython script. The string can be an IP address or domain name, and if the C2 address is a\r\ndomain name, the malware tries to resolve it until it succeeds.\r\nThe malware communicates with the C2 server over TCP. It creates a TCP socket to the C2 server by using the IP\r\naddress and the port. After the connection is established, Ficker calls to recv function twice. First, it receives two\r\nbytes that indicate the data size it needs to allocate. It then allocates this memory and receives the data from the\r\nC2 server.\r\nThe received data is the Grabber rules configuration of the C2 server and contains a list of Grabber rules\r\nconfigured by the attacker. We will focus on this section on the Grabber part.\r\nAfter getting the grabber rules sent as plaintext, Ficker sends some hardcoded value 0x0C000F0A0B0A0B0A (not\r\nencrypted) to the C2. We assume that this hardcoded value indicates that the connection was established\r\nsuccessfully and the configuration has been received.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 11 of 20\n\nFigure 11: Send the hardcoded value\r\nThe last part of this connection establishing method is sending the address of the C2 server encrypted/obfuscated\r\nusing a function we named send_enc_data.\r\nSending Data to C2\r\nFickerStealer has a singular method for sending the data to the C2 server, and it does it in an encrypted/obfuscated\r\nway. Using this method makes the network analysis of this malware a little bit more difficult and stealthier than\r\nsending the data as plaintext like most of the stealers.\r\nThe function send_enc_data gets two arguments: a pointer to the data and an index flag. The index flag indicates\r\nthe data type used by the C2 server. This function first “encrypts” the data using simple XOR rotation with one\r\nbyte XOR key:  0x0A. So far, we noticed the XOR byte is the same in all Ficker’s samples.\r\nAfter encrypting the data and before sending it, Ficker creates a packet for sending the data:\r\n4 bytes: the size of the encrypted data,\r\n1 byte: the index flag\r\nX bytes: the encrypted data\r\nFinally, Ficker sends this data to the C2 server in two separate requests.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 12 of 20\n\nFigure 12: The simple XOR rotation and sending the first packet\r\nAs we mentioned earlier, the index flag indicates the data type sent to the C2 server. We check the xrefs of this\r\nfunction, and we found out it is called from 13 different locations and gets 12 different values of the index flag\r\nargument, from 0x00 to 0x0B.\r\nBy setting a conditional breakpoint on the entry of this function, we could dump the plaintext data and the index\r\nflag on every call. By correlating these parameters, we figured out what each index flag value represents.\r\nIndex Flag value Data type\r\n0x00 Chromium-based browsers\r\n0x01 Mozilla-based browsers\r\n0x02 FTP clients\r\n0x03 Grabber files\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 13 of 20\n\nIndex Flag value Data type\r\n0x04 Screenshots\r\n0x05 System information\r\n0x06 Cryptocurrency wallets\r\n0x07 Hardware ID\r\n0x08 Others (Desktop clients)\r\n0x09 C2 address and port\r\n0x0A poppush – Downloader command\r\n0x0B Victim public IP\r\nTable 1: Mapped index flag values\r\nStealing Capabilities\r\nMost applications store confidential information in various files/registry keys, and most of the information stealers\r\nhave a hardcoded list of known/default locations where the sensitive file is located for each targeted application.\r\nFicker’s methodology of stealing sensitive information from files is quite different from other stealers.\r\nFicker doesn’t have this typical path list for each application. It recursively searches a unique file that belongs to\r\nthe targeted application from a starting location (path). This recursive search is implemented by a function we\r\nnamed find_file. The function gets a path (starting location) and the sensitive file’s name to search, which can also\r\nbe a regex expression. The function returns a list of all the locations where the file was found under the starting\r\nlocation. This method allows Ficker to find the application folder containing the sensitive files without knowing\r\nexactly where they are stored (the application may be installed on a different location) — and without having all\r\nthose suspicious strings.\r\nMozilla-based applications\r\nFirst, Ficker calls to find_file with the full path of %appdata% and the file name cookies.sqlite — a file used by\r\nMozilla-based application that stores web cookies. By doing that, it gets a list of all profile folders for every\r\ninstalled Mozilla-based application. After it finds every sensitive folder, it moves to the next step: stealing the\r\ndata. Ficker steals the user’s saved login credentials, cookies, and autocomplete history. All those sensitive\r\nfiles are under the locations Ficker found at the first step.\r\nThe main difference for stealing Mozilla-based applications’ information is the way in which Ficker steals the\r\nuser’s saved credentials. Most of the stealers parse the login.json file and decrypt the confidential information by\r\ngetting the decryption key from other known database files (key4.db, cert9.db, or key3.db, cert8.db for older\r\nversions). Instead of parsing the credentials file and dealing with the decryption part, Ficker sends those files to\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 14 of 20\n\nthe C2 server, and the server does all the parsing and decrypting work of these credentials. Our guess here is that\r\nFicker does this to run without having any dependencies like nss3.dll and to appear less suspicious.\r\nIn the case of data that doesn’t require decryption operations, such as the autocomplete and cookies data, Ficker\r\nparses it on the victim’s side and then sends the data to the C2 server.\r\nChromium-based browsers\r\nFicker employs a similar methodology to steal Chromium-based data like it used to steal from Mozilla-based\r\napplications.\r\nTo begin with, Ficker decrypts five strings that will be starting locations:  %appdata%, %localappdata%,\r\n%userprofile%\\Desktop, %userprofile%\\Documents, %USERPROFILE%\\Local Settings\\Application Data. It also\r\ndecrypts the string Login Data, the DB file name used by Chromium-based browsers that stores saved credentials.\r\nBy searching this file under those starting locations, Ficker gets all Chromium-based browsers users’ profile\r\nfolders.\r\nFigure 13: The folder found by find_file\r\nFor each user’s profile folder, it extracts the user’s master key from the Local State file by parsing this JSON file\r\nand getting the value of encrypted_key. This value is Base64 encoded and encrypted using DPAPI; hence, Ficker\r\ndecodes this value and decrypts it using CryptUnprotectData. This key is used to decrypt confidential information\r\nthat Chromium-based browsers save in their SQLite database files.\r\nFor each existing profile in the browser, Ficker targets the Login Data, Cookies, and Web Data SQLite DB files in\r\norder to steal the user’s saved login credentials, cookies, and autocomplete history.\r\nOne of the exciting things about SQLite database files is that Ficker parses those files and extracts the sensitive\r\ndata independently. As we mentioned earlier, Ficker doesn’t have any dependencies like most of the stealers,\r\nwhich download or drop some dlls like sqlite3.dll that make their job easier. It is common to see information\r\nstealers using sqlite3.dll’s exported functions to extract sensitive data using SQL queries. For instance, getting the\r\nuser’s saved credentials from Login Data using this query: SELECT origin_url, username_value, password_value\r\nFROM logins.\r\nHowever, Ficker doesn’t use any SQL query to extract the sensitive data from the DB files. It goes over the\r\nSQLite3 database file format and extracts the sensitive file by parsing the DB file.\r\nCryptocurrency wallets\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 15 of 20\n\nLike most information stealers, Ficker also steals crypto wallets. It doesn’t target every crypto wallet application,\r\nbut it does target the more popular ones. For every wallet application, Ficker decrypts the application folder\r\nlocation and the sensitive file name (e.g., *.wallet). After getting the location of those files using find_file, Ficker\r\nreads those files into memory and sends all the data to the C2 server.\r\nThe targeted applications are Bitcoin, Jaxx, Exodus, Atomic, Electrum, Zcash, Bytecoin, Ethreum, Monero,\r\nLitecoin, and Dash.\r\nSystem information\r\nFicker gathers information and takes a screenshot of the compromised machine. When it finishes collecting this\r\ninformation, it gathers all the data together and sends it to the C2 server.\r\nMoreover, Ficker collects basic information about the machine like the location of the running executable, OS\r\nversion, hardware and graphic information, system time zone and language. In addition, it lists all the running\r\nprocess and their PIDs, as well as the installed applications on the victim’s machine.\r\nFigure 14: Collected system information\r\nGrabber\r\nFickerStealer has a grabber feature that allows the attacker to collect any files from the victim’s machine and send\r\nthose to the C2 server. This feature is configurable, and the attacker can enable or disable it from the C2 panel.\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 16 of 20\n\nWhen the malware establishes its connection to the C2 server (as we covered earlier), it gets the Grabber’s\r\nconfiguration from the C2 server.\r\nThe received data contains a list of Grabber rules. Each rule has the start location and its mask; the mask can be a\r\nregex or file name, so the malware searches for files by the mask under the start location recursively.\r\nFigure 15: The received Grabber’s configuration\r\nThe structure of the Grabber configuration looks like Code Snippet 2:\r\nstruct rule{\r\nint path_len;\r\nchar* startFolder; #size of path_len\r\nint mask_len;\r\nchar* mask; #size of mask_len\r\nchar end_flag;\r\n};\r\nstruct grabberRules{\r\nint rules_num;\r\nrule* rule_list; #size of rules_num\r\n};\r\nCode Snippet 2: Grabber configuration structure\r\nWe wrote a simple python script that parses this data by this structure. We noticed that attackers mainly focus on\r\nsearching other cryptocurrency wallets in different locations, password manager confidential information and\r\npassword files. For instance, path:%userprofile%\\Documents, mask:*.kdbx targets KDBX files, which are used by\r\nKeePass and usually refer to the KeePass Password Database. You can check our IoCs page in our Malware\r\nResearch Repository to find more examples of Grabber’s rules.\r\nDownloader\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 17 of 20\n\nAfter Ficker steals as much data as possible, it moves for its last feature, which is the Loader. Ficker can download\r\nand execute several second-stage malware that can be done by running executables or loading DLLs.\r\nThe attacker can enable/disable the downloader feature from the C2 panel. The panel of the malware also allows\r\nsetting checks prior to downloading the second stage malware — checking some of the victim’s characteristics\r\nlike GeoIP, stolen credentials type, etc.\r\nBefore receiving the second stage malware from the C2 server, Ficker sends a command to the C2 server-poppush.\r\nThe malware first decrypts the string poppush and then sends it to the C2 server by using send_enc_data function.\r\nWe assume that this string/magic commands the C2 server to return the second-stage malware data.\r\nFigure 16: Downloader communication\r\nAs we can see in figure 16, the malware sends the XORred poppush string, and it receives a data structure from\r\nthe C2 server.\r\nThe first four bytes are the data size, so Ficker first receives only four bytes and then allocates a new memory\r\nbuffer for the Downloader data. The next four bytes indicate the number of binaries that received from the C2\r\nserver. In the communication with the C2 server above, we can see it’s configured to download two binaries. The\r\nnext four bytes indicate the first binary size, which is right after these four bytes.\r\nAfter receiving the second-stage malware, Ficker generates a random name for each binary and gets the Temp\r\nfolder of the current user. Ficker decrypts the binary’s extension string, which can be .exe or .dll depending on the\r\nbinary type. Then it concatenates all those three strings into a valid file path –\r\n%temp%+random+decrypted_exetension, e.g., C:\\Users\\win10\\AppData\\Local\\Temp\\1606398000688.exe. After\r\nthat, Ficker writes the binary data to this path.\r\nThe last part of this feature is executing the second stage malware. Ficker uses CreateProcess to run an executable,\r\nand it uses LoadLibraryA to load a DLL.\r\nConclusion\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 18 of 20\n\nWe foresee an expanding number of opportunities for FickerStealer among cybercriminals because of its\r\nefficiency and differentiation from other stealers, such as its stealing methodology and being written in Rust.\r\nFicker has all the capabilities that cybercriminals look for in information stealers. Moreover, Ficker uses different\r\nobfuscation techniques and because it’s written in Rust, it makes the analysis of the malware more difficult —\r\nleading us to one of our main conclusions. Our first strategy to “map” the malware by finding its strings paid off\r\nbecause it saved us time analyzing the sample. By doing that, we could eventually understand any part of the\r\nmalware quite quickly and focus only on the features that interest us without digging into the malware.\r\nCredential-theft malware will always be a popular resource used by adversaries. Even though information stealers\r\nmight not be the most sophisticated malware, they are still effective enough to cause significant damage to\r\norganizations and individuals.\r\nTo defend against these threats, organizations can use an endpoint protection solution like CyberArk Endpoint\r\nPrivilege Manager, combine it with fundamental security awareness, deploy MFA and use of strong and unique\r\npasswords to further mitigate risk.\r\nAppendix A: Targeted Applications\r\nTargeted Applications\r\nAll Mozilla-based browsers and Thunderbird\r\nAll Chromium-based browsers\r\nCryptocurrency wallets application: Bitcoin, Jaxx, Exodus, Atomic, Electrum, Zcash, Bytecoin, Ethreum,\r\nMonero, Litecoin, and Dash.\r\nWindows Vault\r\nFTP clients: WinSCP, FileZilla\r\nDicscord, Pidgin\r\nSteam\r\nAppendix B: IoCs \u0026 YARA Rule\r\nHashes\r\na4113ccb55e06e783b6cb213647614f039aa7dbb454baa338459ccf37897ebd6\r\n25fe7dd7a49dac5706ac0772f8baf415e7b554e68d904bc2e026ac2cb4848527\r\n6029558794981d135cf41756c3e2de0cb4b08f1533a7dcd945b2ac9ff02535bf\r\ned635f60d1cc542377ea9f0b0723f19fe998a8eb6319373a1a3177066d5d4816\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 19 of 20\n\n382055f0fca8a6172846236a2a9031ce9103359673b4b13e1c4c04bc1861d941\r\n94e60de577c84625da69f785ffe7e24c889bfa6923dc7b017c21e8a313e4e8e1\r\n25fe7dd7a49dac5706ac0772f8baf415e7b554e68d904bc2e026ac2cb4848527\r\n5a904972e7ce7ef0b9484daa3eee9860ece27845692ca5750d2b80b24acd6a8f\r\n6029558794981d135cf41756c3e2de0cb4b08f1533a7dcd945b2ac9ff02535bf\r\nb00121c90392716403386a4d407015430e121eced0603af7dc0c8a996a61cb5f\r\ne5ac51cbaab11a34c180417118933758ceae64d5fbbc00ebf210e6664963082c\r\n4abf05cd0f538e42237328617711752687faddfe314afe5adf07a24155305df5\r\nC2 servers\r\n45.141.84[.]139:80\r\n195.154.168[.]132:81\r\nsweyblidian[.]com:80\r\nmamkindomen[.]info:80\r\n93.115.22[.]72:80\r\n95.217.5[.]249:80\r\n139.59.66[.]32:81\r\nYara Rule\r\nFickerStealer Yara Rule\r\nSource: https://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nhttps://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.cyberark.com/resources/threat-research-blog/fickerstealer-a-new-rust-player-in-the-market"
	],
	"report_names": [
		"fickerstealer-a-new-rust-player-in-the-market"
	],
	"threat_actors": [
		{
			"id": "67bf0462-41a3-4da5-b876-187e9ef7c375",
			"created_at": "2022-10-25T16:07:23.44832Z",
			"updated_at": "2026-04-10T02:00:04.607111Z",
			"deleted_at": null,
			"main_name": "Careto",
			"aliases": [
				"Careto",
				"The Mask",
				"Ugly Face"
			],
			"source_name": "ETDA:Careto",
			"tools": [
				"Careto"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "9f101d9c-05ea-48b9-b6f1-168cd6d06d12",
			"created_at": "2023-01-06T13:46:39.396409Z",
			"updated_at": "2026-04-10T02:00:03.312816Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"CHROMIUM",
				"ControlX",
				"TAG-22",
				"BRONZE UNIVERSITY",
				"AQUATIC PANDA",
				"RedHotel",
				"Charcoal Typhoon",
				"Red Scylla",
				"Red Dev 10",
				"BountyGlad"
			],
			"source_name": "MISPGALAXY:Earth Lusca",
			"tools": [
				"RouterGod",
				"SprySOCKS",
				"ShadowPad",
				"POISONPLUG",
				"Barlaiy",
				"Spyder",
				"FunnySwitch"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "39842197-944a-49fd-9bec-eafa1807e0ea",
			"created_at": "2022-10-25T16:07:24.310589Z",
			"updated_at": "2026-04-10T02:00:04.931264Z",
			"deleted_at": null,
			"main_name": "TeleBots",
			"aliases": [],
			"source_name": "ETDA:TeleBots",
			"tools": [
				"BadRabbit",
				"Black Energy",
				"BlackEnergy",
				"CredRaptor",
				"Diskcoder.C",
				"EternalPetya",
				"ExPetr",
				"Exaramel",
				"FakeTC",
				"Felixroot",
				"GreyEnergy",
				"GreyEnergy mini",
				"KillDisk",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"NonPetya",
				"NotPetya",
				"Nyetya",
				"Petna",
				"Petrwrap",
				"Pnyetya",
				"TeleBot",
				"TeleDoor",
				"Win32/KillDisk.NBB",
				"Win32/KillDisk.NBC",
				"Win32/KillDisk.NBD",
				"Win32/KillDisk.NBH",
				"Win32/KillDisk.NBI",
				"nPetya"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "8941e146-3e7f-4b4e-9b66-c2da052ee6df",
			"created_at": "2023-01-06T13:46:38.402513Z",
			"updated_at": "2026-04-10T02:00:02.959797Z",
			"deleted_at": null,
			"main_name": "Sandworm",
			"aliases": [
				"IRIDIUM",
				"Blue Echidna",
				"VOODOO BEAR",
				"FROZENBARENTS",
				"UAC-0113",
				"Seashell Blizzard",
				"UAC-0082",
				"APT44",
				"Quedagh",
				"TEMP.Noble",
				"IRON VIKING",
				"G0034",
				"ELECTRUM",
				"TeleBots"
			],
			"source_name": "MISPGALAXY:Sandworm",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "f5bf6853-3f6e-452c-a7b7-8f81c9a27476",
			"created_at": "2023-01-06T13:46:38.677391Z",
			"updated_at": "2026-04-10T02:00:03.064818Z",
			"deleted_at": null,
			"main_name": "Careto",
			"aliases": [
				"The Mask",
				"Ugly Face"
			],
			"source_name": "MISPGALAXY:Careto",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3a0be4ff-9074-4efd-98e4-47c6a62b14ad",
			"created_at": "2022-10-25T16:07:23.590051Z",
			"updated_at": "2026-04-10T02:00:04.679488Z",
			"deleted_at": null,
			"main_name": "Energetic Bear",
			"aliases": [
				"ATK 6",
				"Blue Kraken",
				"Crouching Yeti",
				"Dragonfly",
				"Electrum",
				"Energetic Bear",
				"G0035",
				"Ghost Blizzard",
				"Group 24",
				"ITG15",
				"Iron Liberty",
				"Koala Team",
				"TG-4192"
			],
			"source_name": "ETDA:Energetic Bear",
			"tools": [
				"Backdoor.Oldrea",
				"CRASHOVERRIDE",
				"Commix",
				"CrackMapExec",
				"CrashOverride",
				"Dirsearch",
				"Dorshel",
				"Fertger",
				"Fuerboos",
				"Goodor",
				"Havex",
				"Havex RAT",
				"Hello EK",
				"Heriplor",
				"Impacket",
				"Industroyer",
				"Karagany",
				"Karagny",
				"LightsOut 2.0",
				"LightsOut EK",
				"Listrix",
				"Oldrea",
				"PEACEPIPE",
				"PHPMailer",
				"PsExec",
				"SMBTrap",
				"Subbrute",
				"Sublist3r",
				"Sysmain",
				"Trojan.Karagany",
				"WSO",
				"Webshell by Orb",
				"Win32/Industroyer",
				"Wpscan",
				"nmap",
				"sqlmap",
				"xFrost"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "a66438a8-ebf6-4397-9ad5-ed07f93330aa",
			"created_at": "2022-10-25T16:47:55.919702Z",
			"updated_at": "2026-04-10T02:00:03.618194Z",
			"deleted_at": null,
			"main_name": "IRON VIKING",
			"aliases": [
				"APT44 ",
				"ATK14 ",
				"BlackEnergy Group",
				"Blue Echidna ",
				"CTG-7263 ",
				"ELECTRUM ",
				"FROZENBARENTS ",
				"Hades/OlympicDestroyer ",
				"IRIDIUM ",
				"Qudedagh ",
				"Sandworm Team ",
				"Seashell Blizzard ",
				"TEMP.Noble ",
				"Telebots ",
				"Voodoo Bear "
			],
			"source_name": "Secureworks:IRON VIKING",
			"tools": [
				"BadRabbit",
				"BlackEnergy",
				"GCat",
				"NotPetya",
				"PSCrypt",
				"TeleBot",
				"TeleDoor",
				"xData"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "18a7b52d-a1cd-43a3-8982-7324e3e676b7",
			"created_at": "2025-08-07T02:03:24.688416Z",
			"updated_at": "2026-04-10T02:00:03.734754Z",
			"deleted_at": null,
			"main_name": "BRONZE UNIVERSITY",
			"aliases": [
				"Aquatic Panda",
				"Aquatic Panda ",
				"CHROMIUM",
				"CHROMIUM ",
				"Charcoal Typhoon",
				"Charcoal Typhoon ",
				"Earth Lusca",
				"Earth Lusca ",
				"FISHMONGER ",
				"Red Dev 10",
				"Red Dev 10 ",
				"Red Scylla",
				"Red Scylla ",
				"RedHotel",
				"RedHotel ",
				"Tag-22",
				"Tag-22 "
			],
			"source_name": "Secureworks:BRONZE UNIVERSITY",
			"tools": [
				"Cobalt Strike",
				"Fishmaster",
				"FunnySwitch",
				"Spyder",
				"njRAT"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "6abcc917-035c-4e9b-a53f-eaee636749c3",
			"created_at": "2022-10-25T16:07:23.565337Z",
			"updated_at": "2026-04-10T02:00:04.668393Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Bronze University",
				"Charcoal Typhoon",
				"Chromium",
				"G1006",
				"Red Dev 10",
				"Red Scylla"
			],
			"source_name": "ETDA:Earth Lusca",
			"tools": [
				"Agentemis",
				"AntSword",
				"BIOPASS",
				"BIOPASS RAT",
				"BadPotato",
				"Behinder",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"Doraemon",
				"FRP",
				"Fast Reverse Proxy",
				"FunnySwitch",
				"HUC Port Banner Scanner",
				"KTLVdoor",
				"Mimikatz",
				"NBTscan",
				"POISONPLUG.SHADOW",
				"PipeMon",
				"RbDoor",
				"RibDoor",
				"RouterGod",
				"SAMRID",
				"ShadowPad Winnti",
				"SprySOCKS",
				"WinRAR",
				"Winnti",
				"XShellGhost",
				"cobeacon",
				"fscan",
				"lcx",
				"nbtscan"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "d53593c3-2819-4af3-bf16-0c39edc64920",
			"created_at": "2022-10-27T08:27:13.212301Z",
			"updated_at": "2026-04-10T02:00:05.272802Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Earth Lusca",
				"TAG-22",
				"Charcoal Typhoon",
				"CHROMIUM",
				"ControlX"
			],
			"source_name": "MITRE:Earth Lusca",
			"tools": [
				"Mimikatz",
				"PowerSploit",
				"Tasklist",
				"certutil",
				"Cobalt Strike",
				"Winnti for Linux",
				"Nltest",
				"NBTscan",
				"ShadowPad"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "b3e954e8-8bbb-46f3-84de-d6f12dc7e1a6",
			"created_at": "2022-10-25T15:50:23.339976Z",
			"updated_at": "2026-04-10T02:00:05.27483Z",
			"deleted_at": null,
			"main_name": "Sandworm Team",
			"aliases": [
				"Sandworm Team",
				"ELECTRUM",
				"Telebots",
				"IRON VIKING",
				"BlackEnergy (Group)",
				"Quedagh",
				"Voodoo Bear",
				"IRIDIUM",
				"Seashell Blizzard",
				"FROZENBARENTS",
				"APT44"
			],
			"source_name": "MITRE:Sandworm Team",
			"tools": [
				"Bad Rabbit",
				"Mimikatz",
				"Exaramel for Linux",
				"Exaramel for Windows",
				"GreyEnergy",
				"PsExec",
				"Prestige",
				"P.A.S. Webshell",
				"AcidPour",
				"VPNFilter",
				"Neo-reGeorg",
				"Cyclops Blink",
				"SDelete",
				"Kapeka",
				"AcidRain",
				"Industroyer",
				"Industroyer2",
				"BlackEnergy",
				"Cobalt Strike",
				"NotPetya",
				"KillDisk",
				"PoshC2",
				"Impacket",
				"Invoke-PSImage",
				"Olympic Destroyer"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434521,
	"ts_updated_at": 1775792229,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/09ca32266ae216a4203175e587ad92a9d9341a20.pdf",
		"text": "https://archive.orkl.eu/09ca32266ae216a4203175e587ad92a9d9341a20.txt",
		"img": "https://archive.orkl.eu/09ca32266ae216a4203175e587ad92a9d9341a20.jpg"
	}
}