Half a Million VK Accounts Quietly Taken Over
At first people logging into their profile did not see anything unusual. Gradually, however, minor things began to feel off; settings would default back to “default” approximately monthly; new groups would show up in their subscription list — groups they had never chosen to subscribe to. All of this was done through chrome extensions that were entirely innocuous-looking, i.e., simple theme changers, or other extensions that made using VK easier.
Upon closer examination, it became apparent that these extensions were not a single malicious plugin, but part of an organized effort to target VKontakte (a social media site with over 650 million registered users). In examining Yandex ad code as part of a routine check, a network of five malicious chrome extensions was discovered that together had been downloaded more than 500,000 times. Therefore, hundreds of thousands of user accounts could be compromised. These extensions did not crash browsers, did not create visible error messages, and did not attract attention to themselves.
In practice, the extension would:
-
automatically subscribe users to groups controlled by the attacker, doing so frequently — roughly three out of four sessions;
-
reset profile settings every 30 days, overriding changes even if users had manually corrected them;
-
bypass VK’s built-in protections by manipulating CSRF tokens;
-
check donation status to unlock additional features, effectively monetizing infected users;
-
maintain control through staged code loading, making detection more difficult.
The man behind this project was not a team, but rather one individual who used the username “2vk” on GitHub. This person was able to turn an average VK profile into a command center to distribute payload-based malware attacks and artificially inflate their audience by forcing unwanted followers onto users. Everything looked like regular social media activity.
A Yandex Investigation Begins
The investigation didn’t start at Yandex though; it started when an internal risk assessment program indicated suspicious behavior by a Chrome extension. That extension was identified as injecting Yandex display ad scripts into every webpage a user accessed.
This lead to additional review of all Chrome extensions utilizing the exact same rendering engine as the identified extension. Eventually attention would be directed towards VK Styles, a Chrome extension which had approximately 400,000 installations and offered itself as a way to customize the look of your VK experience. Upon further inspection there was nothing to indicate anything abnormal about the extension; however, upon closer examination of the code there was a Yandex Metrica identifier being created and assigned dynamically, as if to help evade detection from automated scanning systems.
‘R-A-’ + 843079 * 2 // Evaluates to: R-A-1686158
There are many reasons why the developer would have chosen to do this at runtime. Static analysis and security scanning tools typically use exact string matching to identify potential malicious content. Therefore, by generating the identifier at runtime, the developer is able to avoid simple pattern based detection of the malware.
This particular line of code that was analyzed generated enough red flags to warrant further investigation of the code base.
Upon closer inspection of the code base for the Yandex Metric extension, it became apparent that while the Yandex metric was simply a cover, the actual malicious functionality was multi-staged and utilized VK as part of its own infrastructure.
Stage 1:
The extensions themselves were harmless on the surface. “VK Styles” was presented as providing users with a better overall experience with VK through customization of themes, addition of new features, and cleaning up the user interface. “VK Styles” also had thousands of positive reviews and was being updated regularly, which indicated that there was no reason to suspect anything malicious about the Chrome Web Store listing.
However, once the codebase of VK Styles was run through an analysis agent, two lines buried within the different components of the project completely changed the perspective of the extensions’ intentions.

Which, in essence,

Using this method, any string sent into E could be run as code. Next, the agent found out what component of the application called E by tracing back all calls to E and discovered the code that pulls a URL from the metadata in a VK profile: vk.com/m0nda. The extension then retrieves code from that profile and executes that code locally on the user’s computer.

This was anything but an ordinary VK account. What looked like a regular personal profile was in fact a command hub — a control point the attacker used to issue instructions and manage infected systems.
Metadata as a Payload Carrier
The next stage was hidden inside the HTML metadata tags of the VK profile:
<meta name="description" content="4000 :: G2vk.github.io/-/ V1.0.250.69 Yan.yandex.ru/system/context.js Ayastatic.net/partner-code-bundles/ :">
At first glance? Just nonsense. But decode them, and the picture changes completely:
-
G (GitHub): https://2vk.github.io/-/
-
Y (Yandex): https://an.yandex.ru/system/context.js
-
A (Ad Bundles): https://yastatic.net/partner-code-bundles/
-
V (Version): 1.0.250.69
The attacker uses VK’s meta tags as a kind of blind spot to store payload URLs.
Why is this clever?
-
There are no hardcoded URLs inside the extension’s code, which makes it much harder to detect or block using standard scanning methods.
-
Updates happen dynamically. The attacker only needs to change the content of their VK profile, and the malicious payload is instantly updated without modifying the extension itself.
-
Communication with the C2 relies entirely on VK.com’s legitimate infrastructure. No shady third-party servers, no suspicious hosting providers.
-
There are no obviously malicious external domains in the traffic. Everything looks like normal VK activity, which significantly complicates detection.
In practice, the extension simply visits a specific VK profile, reads the page’s meta tags, extracts the hidden encoded links, and then uses those links to fetch the next stage from GitHub.
Stage 2: GitHub Payload
The malware is hosted on the GitHub account 2vk: https://github.com/2vk

The repository name has been kept very generic. In fact, the name “–” is simply a normal hyphen (therefore it has no meaning). As a result of the repository name being so generic it is nearly impossible to locate or identify through standard means of searching.
Inside the repository there is an ordinary looking file named “C”. This file appears to be unremarkable and therefore probably intentionally made that way. However the file does contain hidden JavaScript code; once the code has been placed into the required location, the code will continue executing the logic.

The VKontakte page visited by the victim.

Summary of the stream:

Over the course of seven months this file was edited 17 times. If you go through each commit one by one you can see it growing and developing. At first it looks like a basic technical draft nothing to get excited about, nothing that would immediately cause suspicion.
The changes then become more noticeable. New chunks of logic are added; certain parts are rethought; others become more complex. Clearly the code was not just being patched but was instead gradually expanded and enhanced.
When you step back and view the larger picture this is no longer a random collection of edits. It is a slow progression from a simple foundation to a more structured and deliberate system — one that grew more capable and assertive with each update compared to where it started.
How the code gradually evolved
June 22, 2025 (commit 9c04efc) — The first Step
At the beginning it appeared as a simple framework. The author set up the fundamentals: handle the csrf cookie; add a wrapper for the vk api; deploy minimal infrastructure. Nothing excessive — just enough to make the system functional. At this point it reminded me of a technical scaffold and not something overtly malicious.
December 23, 2025 (commit ba0125b) — when Things turned serious
This is where the project obviously shifted. An automatic subscription function was introduced and triggered most sessions. A 30-day settings reset mechanism was also added along with forced configuration changes made without user consent. What had previously been a structural base now started acting on its own — much more aggressively than before.
January 13, 2026 (commit 8f94054) — The Money Phase
At this point it was apparent this was not an experiment. The author switched away from HTML scraping and directly made api calls — a more stable and less conspicuous approach. Donation tracking through the VK Donut API was added along with logic that allowed features to be enabled or disabled based on payment status. The system effectively implemented a “pay to unlock” model.
January 2026 (commit c9d1e96) — covering Tracks
After that cleanup occurred. Over a hundred lines of code related to intersection observer were eliminated. The structure was simplified and packaged into a smaller space. The less excess code that remained the harder it was to raise suspicion when reviewing the code.
What This Malware Actually Does
Once fully deployed, the malware carries out five distinct categories of malicious activity. Let’s break them down.
Automatic Subscriptions: Building an Army
Code:

Translation: There is a 75% chance (3 out of 4 random outcomes) that every time you visit VKontakte, malware automatically subscribes you to the VKontakte group -168874636.
What is the VKontakte group 168874636?
This is the attacker’s own group.: https://vk.com/club168874636 .
This redirects to VK Styles (https://vk.com/2style) – an “official community” for malware disguised as a user support group. It has 1.4 million followers, such as the popular guy VK Styles 🙂
Why Is This So Clever?
-
Viral growth — every infected user automatically becomes a subscriber, boosting the group’s perceived legitimacy.
-
Social proof — “1.4 million members can’t be wrong.” Large numbers create trust.
-
Free promotion — friends see the new subscriptions in their feeds, which makes the activity look organic and credible.
-
Monetization leverage — more followers mean more influence, which leads to more potential victims.
-
Persistence — even if a user manually unsubscribes, there’s roughly a 75% chance they’ll be re-subscribed during a future VK session.
The attacker essentially turned malware distribution into a self-reinforcing loop. Victims unknowingly help attract new victims.
30-Day Reset: Ongoing Account Control
Code:

Translation: Every 30 days (2,592e6 milliseconds = 30 days), the malware:
-
resets the VK feed sorting to “recent” instead of algorithmic;
-
changes the message bubble theme back to theme 0;
-
overrides any custom settings you have configured;
-
tracks the timestamp of the last reset to ensure it runs monthly.
CSRF Token Manipulation: Breaking VK’s Security
Code:

Translation: The malware is able to read and manipulate VK’s CSRF protection cookie, remixsec_redir.
What is a CSRF token?
A CSRF token is essentially a security marker that confirms an action in your account was initiated by you. When you change settings, publish a post, or perform another sensitive action on VK, the system checks this token automatically. If the token matches, the request is accepted. If it doesn’t, the action is blocked. In simple terms, it prevents someone from triggering actions on your behalf through a malicious or third-party site.
By manipulating this cookie, the malware can potentially:
-
bypass CSRF protection when making API calls;
-
execute actions that would normally be blocked;
-
make malicious requests appear legitimate to VK’s security systems.
This is a direct attack on VK’s security infrastructure.
The Network: Five Extensions, One Threat Actor
A search for the Yandex Metrica identifier RA-1686158 uncovered a network of extensions — all controlled by the same operator and relying on the same underlying infrastructure:

-
Total number of confirmed victims: 502,000
-
One extension was already removed by Google in 2024 for violating the online store’s policies – this indicates that this campaign was detected earlier, but the attacker simply switched to new extension IDs and continued the operation.
-
The most popular extension, VK Styles – Themes for vk.com, was removed from the marketplace on February 6.
Total impact: more than 502,000 confirmed victims.
VK group growth: The attacker’s VK Styles group expanded “organically” through forced subscriptions, effectively turning infected users into a self-sustaining distribution channel.
Geographic distribution: The majority of victims appear to be Russian-speaking users — VK’s core demographic — along with users in Eastern Europe, Central Asia, and Russian-speaking communities abroad.
Timeline: The campaign has been active since at least June 2025, with continuous updates through January 2026 — more than seven months of sustained activity.
What’s Happening Right Now
Every day, thousands of VK users are:
-
unknowingly subscribed to the attacker’s group;
-
having their account settings reset;
-
exposed to CSRF token manipulation;
-
monetized through donation-tracking logic;
-
functioning as distribution nodes for the malware itself.
Because browser extensions update automatically, the attacker can instantly push new malicious code to more than 500,000 infected users — without any action required from them.
Overall Implications
The Koi Team conducted this study as a continuation of its efforts to identify threats within the software supply chain. What we see in the VK Styles case clearly illustrates that there is more at stake than ever before with browser extensions and their associated risks.
As we look at the way this malware functions, there are several disturbing trends in how it is operating today:
-
Social Media Profiles as Command & Control Infrastructure. VK profiles, meta tags, etc. are being used as command & control interfaces for attackers. Social media profiles are often seen as nothing more than a user’s online identity. But what they are actually being used for here is the transmission of commands to victim machines.
-
Self-Propagation via Automatic User Actions. Victim users are automatically added to attacker controlled groups on social media platforms. When an attacker adds a new follower to the group, it increases the overall visibility of the group and therefore the number of potential victims. Essentially, this system causes itself to grow and increase in size.
-
Monetized Model Based on Subscription. Rather than having a single event (infection) the operator created a subscription-based model. Once infected, the malware will remain on the victim machine and unlock additional functionality based on user payment. It has evolved into a legitimate business operation.
-
Periodic Resets to Malware Settings. All of the user’s settings reset every 30 days back to the malware defaults. A user could potentially manually fix the problem once, but the next time the malware runs, it will reset the user’s settings back to where they were when initially infected. In most cases, to completely escape the cycle of the malware, the user would have to remove the extension from their browser altogether.
-
Dynamic Multi-Stage Payloads. The main extension could appear relatively safe, while all malicious code is pulled dynamically from external sources such as GitHub or VK profiles. The malicious code can then be modified without updating the original extension. This also creates a significant challenge for anti-malware tools to detect.
Browser extensions have quietly become one of the most dangerous attack vectors in modern security:
-
They operate with high privileges.
-
They update automatically without explicit user approval.
-
They are difficult to audit or monitor.
-
Marketplace security reviews are limited.
-
Users tend to trust them by default.