Analyzing a Facebook Profile Stealer Written in Node.js
After the stealing process is completed, the client sends another status message to the server stating that the stealing process has been completed. In the case of a server pushing a message during the stealing process, the client responds with a “wait for the completion” message.
The reason for the implementation of handling such messages is the activation of the stealing process. The threat actor maintains an IP address list of infected clients that are just waiting for activation (by receiving a message). After the threat actor pushes a message to the clients, the stealing process restarts.
The stealer focuses on the following web browsers:
- Microsoft Edge
- Google Chrome
- Opera / OperaGX
- Brave
For each browser, the stealer searches for available profiles in the User Data folder. It then collects the user home path, the profile path, the User Data path, and version information from the \User Data\Last Version file. Next, it extracts the encrypted key (used to decrypt Chrome cookies and passwords) from \User Data\Local State and decrypts it. Finally, it will kill the browser process.
For each available profile, the stealer gets all saved cookies database from <profile>\Network\Cookies. It then checks if a Facebook cookie named xs is present. This cookie is a session ID that indicates whether a user is logged in to Facebook for that profile. If this cookie is not found, it skips the profile.
It extracts all cookies belonging to Facebook, Google, and Outlook (live.com) and decrypts all of them with a key previously obtained from \User Data\Local State. It also retrieves the database of all saved login credentials from <profile path>\Login Data.
Furthermore, the stealer decrypts all Facebook, Google, and Outlook logins (usernames, emails and passwords) also using a key obtained from \User Data\Local State.
It then checks if the MetaMask extension exists in <profile path>\Local Extension Settings\, after which it packs the whole MetaMask extension directory into a zip archive and exfiltrates it to the Telegram bot.
It gets Facebook’s c_user cookie and additional browser information such as operating system, version, and architecture. The stealer will also attempt to steal Facebook’s access token. If this is unsuccessful, it will exfiltrate Facebook cookies, browser names, executable paths, saved logins, IP addresses, and country codes. The targeted profile is then skipped, with the stealer proceeding to another profile.
It then exfiltrates the following in order via GET requests to C&C server:
- Facebook identity numbers, full usernames, email addresses, birthdays, access tokens, Facebook cookies, browser names, executable paths, saved logins, IP addresses, and country codes
- Gmail credentials and cookies
- Outlook credentials and cookies
- Additional Facebook information, such as email addresses and location information
- Business account information, such as usernames and identifiers. For each business account, it will steal the name, ad account limit, creation time, business ID, permitted roles, verification status, and number of business users associated with the business.
- Page information, including usernames and page access tokens
- Ad account information, which includes usernames. For each ad accounts, the stealer extracts ad account IDs, ad account agencies, spending limits, extended credits (invoice and how often it is billed), currency ratio to USD, time zones, next billing dates, the creation time, billing thresholds, balances, payment cards, payment card expiration dates, payment card verification status, ad account insights, and account status
Most likely for backup purposes, previously extracted information is also saved into a text file and sent to the Telegram bot.
Exfiltration to the C&C server
The exfiltration of stolen data to the C&C server is done via GET request to a randomly generated path (<server>/image/<random 26-character ID>.png). The exfiltrated content is passed inside the authorization header.
Read More HERE
