Editor’s note: Sophos MDR’s Johua Rawles, Mark Parsons, Jordon Olness, and Colin Cowie contributed to this report.
One of the Internet’s most prolific cybercrime-as-a-service operations recently suffered a setback: In November, Sophos MDR noticed that detections for the Rockstar2FA “phishing-as-a-service”(PaaS) platform had suddenly gone quiet.
Based on telemetry gathered by Sophos MDR, it appears that the group running the service experienced at least a partial collapse of its infrastructure, with pages associated with the service no longer reachable. This does not appear to be because of a takedown action, but due to some technical failure on the backend of the service.
The disappearance of Rockstar2FA, an updated version of phishing services known as DadSec (previously associated with Microsoft’s Storm-1575 threat group) came two weeks before TrustWave published research detailing the phishing-as-a-service operation. Elements of the phishing service’s infrastructure are now no longer reachable, returning an HTTP 522 response— indicating that they were cut off from the Cloudflare content delivery network. Telegram channels associated with command and control of the service also appear to have gone offline.
In the weeks following the disruption of Rockstar2FA, we observed a surge in the use of a similar set of PaaS portals that have been tagged by some researchers as “FlowerStorm”—the name coming from the use of plant-related terms in the HTML page titles of many of the phishing pages themselves (“Flower,” “Sprout, “Blossom,” and “Leaf,” for example). FlowerStorm shares a number of features with Rockstar and with Tycoon, another Telegram bot-powered PaaS platform.
So, you want to be a rock star
Rockstar2FA is (or perhaps was) a PaaS kit that mimics legitimate credential-request behavior of commonly used cloud and software-as-a-service platforms. Would-be cybercriminals purchase and control phishing campaigns through Telegram and are given a unique phishing page and URL to use in their campaign. Visits via the link delivered to the target delivered the phish; visits to the domain of the site itself are routed to a “decoy” page. Rockstar’s decoy pages usually had an automotive theme.
Visitors to the URL would be routed to a counterfeit Microsoft login page. That page captured credentials and multifactor authentication tokens and sent them via an HTTP POST message to an adversary-controlled “backend server” page —a PHP page with a seemingly random number for its name (as shown in Figure 2). These back-end servers were largely on .ru, .de and .moscow registered domains. The decoy pages were frequently hosted on the same hosts as the back-end servers.
Most of the phishing pages were on domains registered in the .com, .de, .ru. and .moscow top-level domains. At any given time, the Rockstar2FA service used about 2,000 domains across these and other TLDs.
However, starting no later than June 2024, some of these pages used Cloudflare Pages serverless deployment (using the domain pages[.]dev), along with code deployed as Cloudflare workers (at the domain worker[.]dev), while still relying on backend servers for exfiltrating phishing data. These phishing pages used subdomain names that did not appear to be created with a domain generation algorithm (DGA)—instead, they appear to have been manually typed by the operator of the kit. Some were crafted to emulate specific target domains (as with 4344655-proofpoint-online-secure.pages[.]dev). But others were similar to keyboard spam:
- whenyoucreatanydominsamedominusedturnslite.pages[.]dev
- pppaaaaulhaaaammmlinnnnbuiiildddeeeerrsssssnzzzzzozzzz.pages[.]dev
These domains made up only a small number of the overall URLs related to Rockstar, and were generally associated with the phishing portals themselves.
Technical difficulties
On November 11, the infrastructure of Rockstar2FA suddenly was disrupted. Redirects to decoy pages failed, yielding a Cloudflare 522 error, indicating that the server providing the page was no longer in communication with Cloudflare.
Figure 5. A failed connection to a decoy page domain
Additionally, the portal pages began to fail. While clicking the Cloudflare “I’m human” test previously resulted in a counterfeit Microsoft login portal being loaded, now all that loaded was the animated Outlook logo. The remainder of the script for the portal pages fails because the connection to the back-end server (via a POST request) has been severed.
The same was true for pages[.]dev hosted portal pages, which also hung while trying to connect to the back-end URLs. Since November, we have continued to see new phishing portal pages set up on pages[.]dev subdomains, but they all fail to connect to their backend servers.
Figure 7: A failed POST request to a Rockstar2FA backend server
This suggests that the operators are continuing to struggle to get their infrastructure back online. This may be because of a web hosting problem or some other technical issue plaguing the Rockstar2FA operators. The fact that the Telegram bots used to run the service also appear to be down suggests there is some larger sort of disruption to the operation.
The rising rock star (?): FlowerStorm
Within about a week and a half of the interruption of Rockstar, we saw a surge in activity from FlowerStorm, though we also found many of these sites were being disrupted as well. The FlowerStorm PaaS platform has been active since at least June of 2024.
Looking at the behavior of FlowerStorm samples, we found that the portal used the same URL to send an authentication request for the target as used in communication requests to the “backend portal”—in this case, to a backend server utilizing the file “next.php”.
In this case, the same IP address utilized for the credential harvesting was also used for the authentication to the user account, based on EntraID sign-in logs.
The phishing pages’ communication to the backend servers PHP file utilized the expected fields and communication below:
Field Descriptions and Expected Values
| Field/Event | Description | Value/Example |
| Do | Specifies the action being requested. | “check” – For check operation “login” – For login event |
| CheckVerify | Periodic server check for authentication method status. | – do: “checkVerify”- token: <token>- user: <email>- service: “notif”- key: <base64_encoded_password> |
| User’s email address. | <email> | |
| pass | User’s password, required when do is “login”. | base64_encoded_password |
| token | JWT containing session information. | <JWT_Token> |
Expected Responses and Interpretations
| Action | Response | Description |
| check | { “status”: “success”, “banner”: null, “background”: null, “federationLogin”: “”, “type”: “office” } | Indicates a valid email and issues a token. |
| login | { “status”: “verify”, “message”: “Please verify your account”, “method”: “<base64 encoded method response>”, “token”: “<JWT_Token>”, “key”: “<base64_encoded_password>”, “user”: “<email>” } | Prompts for MFA using the same JWT for session tracking. |
| Method | { “status”: true, “data”: “<base64 encoded session data>”, “number”: 59 } | Posts session-specific data used for MFA. |
| Method (Data Decoded) | [ { “authMethodId”: “PhoneAppNotification”, “data”: “PhoneAppNotification”, “isDefault”: true }, { “authMethodId”: “PhoneAppOTP”, “data”: “PhoneAppOTP”, “phoneAppOtpTypes”: [“MicrosoftAuthenticatorBasedTOTP”] } ] | Details multi-factor authentication methods available to the user. |
| CheckVerify (Failure) | { “status”: false, “message”: “Verification failed”, “token”: “<JWT_Token>” } | Server begins checking for MFA acceptance. |
| CheckVerify (Success) | { “<string_with_session_cookies>” } | MFA was accepted, response contains session cookies for authentication. |
Not all the phishing pages utilize the same backend server structure. Some portals will utilize a next.php hosted on the same domain as the phishing landing page. The IP address in EntraID authentication logs will not be the same for these portals. For example, in the case below, the phishing page protectivewearsupplies[.]doclawfederal[.]com/wQBPg/ sends its post request to a different host with the same domain name:
![Figure 11: A developer browser view of the phishing page protectivewearsupplies[.]doclawfederal[.]com/wQBPg/](https://news.sophos.com/wp-content/uploads/2024/12/FlowerstormDeveloperViewPhishportal.png)
Rockstar2FA/ FlowerStorm similarities
FlowerStorm has a significant number of similarities to Rockstar2FA, both in the format of its phishing portal pages and the connection to its backend server .
Document object model
The HTML of FlowerStorm’s portal pages has changed over the past six months but still retains a similar Document Object Model (DOM) content to that of Rockstar pages. The HTML pages of older and newer FlowerStorm phishing pages, like those of Rockstar2FA, have strings of random, unrelated text in HTML comments, use Cloudflare “turnstile” keys to prompt a check of the incoming page request, and have other similar structures and content, as shown below:
| New FlowerStorm | Old Rockstar2FA | Old FlowerStorm | |
| Title | OreganoLeaf | Unalike | Elderberry |
| Turnstile Sitekey | 0x4AAAAAAA0_fAGSk-ZDbrja | 0x4AAAAAAAhiG1SBeMjCx4fG | 0x4AAAAAAAceMeRudDiJWXJJ |
| Form Submission Script | FennelBlossom | Nautili | Bravery |
| Comments Themes | Literary/academic | Cars, fitness, fruits | Cars, lifestyle, fruits |
| Visible Security Text | “Initializing browser security protocols” | “Running browser verification to protect your safety” | “Browser security verification ongoing for your safety” |
The elements in the chart above are called out in the screenshots below, showing the HTML code of each of the phishing portals. The HTML document title tags are highlighted with a red box, comments are highlighted with orange, turnstyle key with yellow, the script function name in green, and the visible “security” text in blue. All appear to follow the same sort of template for generating HTML, though the comment and title naming schemes reference different text arrays.
Figure12: The document object model of a Rockstar2FA phishing page
While abuse of the Cloudflare CDN’s security turnstyles has been present in other adversary-in-the-middle phishing kits, the structure of FlowerStorm and Rockstar phishing portals suggests at least a common ancestry.
Credential harvesting
The methods utilized by FlowerStorm for communication bear close resemblance to the previous Rockstar2FA portals, with some minor variation in the field names and responses:
Common Fields
| FlowerStorm | Rockstar2FA | Commonality | |
| PHP Communication | Next.php | <numbers>.php | Both communicate to a backend server hosting a PHP file. Used for exfiltration and data communication. |
| Email Validation | “do”:
“check” for email validation |
“do”: “check” for email validation | Both support email validation as a fundamental feature. |
| Login Event | “do”: “login” for authentication | “do”: “le” for authentication | Both facilitate login operations. |
| Password | “pass”: contains base64 encoded password | “px”: contains plaintext password | Both communicate passwords to backend server. |
| Session Tracking | “token” for session tracking. | “sec” for session tracking | Both provide session tracking tokens. |
Domain Registration and Discovery
The patterns of domain registration and the detection of new pages through URLScan submissions for both phishing kits’ infrastructure appear to follow a distinct pattern, especially when comparing the domain activity and identification of the two.
Figure 15: A chart plotting daily page detections for Rockstar2FA and FlowerStorm through the end of November 2024
From October 1 to November 11 the peaks and valleys of FlowerStorm and Rockstar Decoy page detections and domain registrations follow a remarkably similar trend, often rising and falling in tandem. This behavior could indicate a shared infrastructure, overlapping operational objectives, or coordinated timing between the two activities.
After November 11th, the two patterns diverge:
- FlowerStorm begins to show stronger independent peaks, especially around November 22–26
- Rockstar Decoy page activity dwindles significantly after November 11, which is in line with the ceasing of operations previously mentioned.
FlowerStorm targeting
The overall nature of FlowerStorm as a paid phishing service means that FlowerStorm’s operators don’t choose who gets targeted for phishing attacks. That’s the decision of their customers. But an analysis of what actors are doing once they have access to the system can be useful for defenders.
Based on our detection information for FlowerStorm, the vast majority of the targets chosen by FlowerStorm users (84%) are in the United States, Canada, United Kingdom, Australia, and Italy. Organizations in the United States were the most frequently targeted, with over 60% of cases associated with organizations primarily located within the US. Canada was the next most targeted country, at only 8.96%. Overall, 94% of the targets of FlowerStorm phishing attempts Sophos has detected were employees of North American and European organizations. Beyond those locations, Singapore, India, Israel, New Zealand, and the United Arab Emirates make up the remaining 5% of targets.
The most heavily targeted sector is the service industry, with particular focus on firms providing engineering, construction, real estate, and legal services and consulting.
Conclusions
We cannot with high confidence link Rockstar2FA and FlowerStorm, other than to note that the kits reflect a common ancestry at a minimum due to the similar contents of the kits deployed The similar patterns of domain registration could be a reflection of FlowerStorm and Rockstar working in coordination, though it is also possible that these matching patterns were driven by market forces more than the platforms themselves. The diverging activity post-November 11might reflect:
- A strategic pivot in one of the groups
- A change in personnel impacting operations
- A disruption in shared infrastructure
- A deliberate decoupling of operations to avoid detection
Furthermore, the rapid ramp-up of FlowerStorm has led to some mistakes and misconfigurations in their operations that have allowed them to also easily be disrupted. Those mistakes have also provided us with an opportunity to more closely examine their back-end operations—which we will continue to do.
A list of indicators of compromise related to FlowerStorm is available on Sophos X-Ops’ Github repository.
Leave a Reply