Operation Deceptive Prospect: RomCom Targeting UK Organisations through Customer Feedback Portals

Figure 1. STIX graph for “Operation Deceptive Prospect"

The "Deceptive Prospect" campaign targets customer feedback portals on company websites as a mechanism to deliver phishing emails containing malicious links directing customer service representatives to supporting evidence in the form of files, such as police statements.

Of the intrusion attempts delivered to Bridewell customers, we observed emails reporting stolen luggage at a hotel, recruitment enquiries, and unsatisfactory levels of facilities at a major UK airport.

The emails contained well-worded complaints with convincing personas generated to impersonate an English-speaking individual. In both cases, the threat actors utilised Yahoo email addresses to submit their portal complaints following the same format patterns:

• "[a-z]+\\.[a-z]+[0-9]{6}@yahoo.com"

• "[a-z]{6,}[0-9]{6}@yahoo.com"
  

Customer Feedback Portal Complaints

Figure 2. Email lure used by RomCom to target retail/hospitality sector

Figure 3. Email lure used by RomCom to target Aviation sector

The above emails were received through internet facing feedback channels where staff handle the customer complaints service mailbox. The handlers work the complaint case using the feedback. In this instance, RomCom were crafting social engineering tactics to get them to open links regarding a stolen laptop or substandard airport facilities.

We hypothesised that it is highly likely that the threat actor used Artificial Intelligence (AI) to generate email content therefore, we analysed various elements of the body structure to form an assessment. During our research into RomCom infrastructure, we later identified another intrusion attempt, during threat hunting, by the threat actor involving recruitment enquiries which was omitted from this part of the analysis.

Firstly, both emails follow a consistent formulaic structure such as "Context -> Issues -> Evidence -> Impact -> Recommendation -> Action Request." Additionally, the "Stolen Laptop" email has inconsistencies with email subject and content, such as referencing staff performance as the complaint title but the body of text refers to a lost laptop. Additionally, the Laptop email contained a "Sent from my OnePlus device" in a possible attempt to seem more convincing to the target. Both emails contained URLs attempting to impersonate Google Drive or Microsoft OneDrive, a technique we have observed RomCom utilise in historical campaigns.

Figure 4. Table showing structural comparisons between analysed lures

Pillars of Social Engineering

Bridewell CTI analysed the contents of the emails against the "Pillars of Social Engineering" to understand which techniques are employed by the threat actors to increase their chances of success.

Both emails contained some form of intimidation, claiming to escalate the issue within a fixed time window (7 days) or highlight possible reputational damage because of inaction. The main pillar leveraged in both cases is that of Trust. Both emails rely heavily on trust between the complainant and the recipient customer service employee.

In both cases, the threat actor relies on the recipient's presumed sense of duty and attempts to build credibility with document mentions and steps taken to assist the customer service representative in acting and responding. In the case of the airport complaint, the threat actor uses the persona of an experienced traveller to validate their observations based on travel to other airports globally to validate their claims.

Figure 5. Table showing analysis of lures against the Pillars of Social Engineering

Complaint Domains

Within each email is a link attempting to impersonate cloud storage services such as Google Drive and Microsoft OneDrive. We identified the following domains: gdrive-share[.]online within the Laptop Theft Complaint and 1dv365[.]drive within the Airport Infrastructure Complaint.

Each domain is appended with a URL path of "file/share" or "workgroup/docs" followed by a 5-character alphanumeric string. The threat actors have recently purchased these domains through Rebrandly as a distribution reseller for domain name registrations.

All RomCom domains we identified utilised Rebrandly, who host their services on Amazon S3 storage within the United States. This is likely a conscious effort by the threat actors to evade detection by utilising common and reputable services as the first stage of their infection chain, improving evasion success to redirect victim traffic to dedicated VPS infrastructure in latter stages of the infection. RomCom threat actors also utilise Tucows DNS infrastructure with systemdns.com nameservers pointing to Amazon S3 IPs for all complaint-related first stage domains.

Figure 6. First stage domain hosted on Rebrandly

We are tracking two clusters of first stage domains that we attribute to RomCom threat actors. The first cluster are active domains that we have observed in the involvement of the reported infection chain, leading to payload hosting infrastructure.

The second cluster are domains that match all the expected RomCom indicators, but we have not yet observed infection activity involvement. It is assessed with medium-high confidence that these will be in the short-near term.

Of the active domains identified within the "Deceptive Prospect" campaign, we identified "live", "pub" and "online" Top Level Domains (TLDs) in use with the following URL patterns: "/workgroup/files/", "/workgroup/docs/, "/folder/open/" and, "/data/", "/cloud/sync/" directing users to the intermediate infrastructure.

RomCom's first stage domain infrastructure revolves around: the dominance of cheap, unregulated gTLDs such as "live"; "pub" and "online" in our active cluster; “Drive”-centric naming to mimic OneDrive/Microsoft 365; numeric and punctuation obfuscation; and an emphasis on “Share” and “Storage” themes. In total, we have identified nearly 100 domains matching these characteristics. Below we have broken down the domain distribution by TLD of all identified domains.

Figure 7. Table showing the breakdown of RomCom domains by TLD

Intermediate Infrastructure

Google Drive or Microsoft OneDrive impersonation links initiate a set of redirects through an intermediate service, which involves solely the domain "opn.to" as a URL shortener service, hosted on OVH SAS in France. In the event of unsuccessful redirects, the adversary appears to have leveraged the Unitag QR code service, only identifying "OOPS...404 The QR Code you are looking for does not seem to exist anymore" as a default redirected web page.

However, we did not identify any usage of a QR code in the infection and web traffic merely routed through the opn[.]to domain automatically on execution of the initial first stage domain in the web browser.

Figure 8. Intermediate 404 webpage

Payload Hosting

Ultimately, the victim lands on a payload hosting site operated on threat actor-controlled infrastructure, impersonating OneDrive with a fake .pdf file extension and associated download button to retrieve supplemental complaint evidence. We have identified payload domains: gcloud-drive[.]com, 1dvstorage[.]com, cloudedrive[.]com, datadrv1[.]com and onelivedrv[.]com used by RomCom to stage these pages.

Figure 9. RomCom payload hosting webpage

These domains are registered with the Tucows registrar and are hosted on ASNs such as SHOCK-1, HZ Hosting and AEZA Group Ltd. Historically, RomCom has used HZ Hosting and AEZA to host Snipbot C2 infrastructure and payload hosting, providers which are typically abused by other threat actors.

A notable difference between the payload infrastructure and lure domains is that these utilise Njalla Okta LLC for DNS services. Previously, RomCom actors have also used hosting providers such as LIMENET, a Bullet Proof Hosting Provider, who had presence in Bulgaria, much like the AEZA Group Ltd infrastructure in this campaign.

Final Payloads

Initiating the download will retrieve the executable of the same name from the Mediafire file sharing site and drop the fake pdf Windows executable on the victim's machine. In previous campaigns, the threat actors have been observed to use file sharing site "temp.sh" store payloads, making a change in tactic for payload staging.

Please note that the filename mentioned below is not the same as the one found during this campaign. However, we identified the same file hash with different file names reused in other intrusions which we have observed.

Figure 10. HTML Content showing payload retrieval from Mediafire hosting

File Analysis

We were able to retrieve the original file that would have been part of the infection chain had it continued further. This file was used to conduct static, dynamic, and code analysis of the file to identify potential similarities with RomCom malware, discover new network indicators which can aid in further infrastructure analysis, and externally hunt for other related malware samples.

Static Analysis

Figure 11. Detect It Easy file attributes of analysed sample

Language Locale Code: Polish (0415 in hexadecimal)

File Names:

• Drug Composition & Reaction Evidence april.exe
• Medical Report scan april.exe
• Medical Records 2025 april.exe
• Drug Composition & Reaction Evidence april (1).exe
• Attachment_Harassment evidence april.exe
• Evidence File april.exe
• aprToSign.exe

It was not known what specific file name was associated with our observed intrusions. Based on the email theme, we assess it was likely a file name such as "Evidence File april.exe" since the lure was non-medical/ legal related. Alternative file names also suggest that the targeting could have been more specific in nature outside of the observed intrusions. In addition to this, the telemetry from Virus Total suggests with low confidence that other countries may also include France, USA, Portugal, Croatia and Germany.

Figure 12. Geographical submissions of file sample from VirusTotal

AV Detections:

At the time of reporting this activity, this file is detected as malicious only by ESET using the Win32/TrojanDownloader.RomCom.A. The name of the signature further supports our hypothesis that there is technical overlap with RomCom from a tooling perspective as well. Only this file is linked to the AV signature, no other files were discovered.

Packer: The file under consideration does not appear to be packed. This is based on the entropy values, and raw and virtual sizes of the file sections.

Compilation Time Stamp: April 16 11:25:29 2025

Figure 13. Compilation Timestamp of sample

Code Sign Certificate: The file is signed by the organisation GMC CONSTRUCTION AND TRADING COMPANY LIMITED. This certificate is likely stolen or compromised. The date when the file was signed and compiled is the same. The signed organsiation also appears to be UK-based and was dissolved the day before the signing the certificate. Currently, only this file was identified to be signed using the code signing certificate. Below you will see that there is a difference between the signing time and validation period of the certificate.

Figure 14. Code Signing Certificate information 

Strings: Upon analysis on ASCII and Unicode strings embedded in the file, there were no indications of malicious strings. However, a particular unicode string "Created by: GRZANA" stands out as it hints towards the developer based on the alias. The origin of the name is unknown. This should be treated with caution due to the absence of this alias in external reporting till date. There were two other samples that also included this string.

Sample 1 SHA256 File Hash: 8183f4b75cbe318a34846b0d8bb9caf219b4b2686d14a531090b6550398cbbca

The file name of sample 1 "WindowsProject1.exe" combined with the compilation time stamp suggest that this was likely a test file used during the early stages of the development. This sample was signed using the organisation "Emma Weber" and shares the same PE import hash as the original file. There were no other debug artifacts associated with this sample.

Sample 2 SHA256 File Hash: 4055e3a45d63778dfc5775ae6e512fb3991df1dadf91630a26ed5747e350f75f

Sample 2 was signed using "Mark Linn" and has a different PE import hash from the original file and icon (music icon).

All three identified samples share similar file sizes, compilation timestamps, language locale code, developer alias string, code signing pattern (one file per signature) and common contained resources which together conclude that the files are very similar to one another. None of these file hashes were mentioned in external reporting.

Furthermore, some of the lesser used PE imports from the original file were leveraged to spot and cluster potentially related file samples in combination with other attributes such as the specific complier used. As a result, six new samples were discovered, these are assessed to be related to the original file based on low confidence. It is still early during the analysis process to determine or validate any attribution to known malware.

b7d48c6982fa1ce21ac9bf4a0a95e109ec2b92176a05556deb920600fb21d57b 3191542dc4c94d5b9f85e00aa60c6d0e48f42ad936e8dbba714962564141e2bd 58d5fffdf41da83b0eef0ea3dd208f371cef87e118cfde4976b83de9158083d1 c77c73fdb66fb0e8720979adcc36081bc6cf8defbfb0adb9c3ec19188a922320 99e6daaa559dc0f812dfd03aa68a8a862cfb5779fa734c6c9e7d7d6ad1286b03 e48bcdb4af6e2f8945adba74a1dc4c7657c75344afc2b487a0373440bb200748

Dynamic Analysis

The file was executed in a sandbox environment. As a result, very limited behaviour was exhibited by the executable with no signs of obvious suspicious/ malicious activity (network, child processes, files dropped) upon execution. The file appears to be some sort of audio/video playing software with a very basic user interface.

However, the presence of the PDF icon during file execution is suspicious since the file has nothing to do with rendering PDFs. The previously specified language locale can be verified based on the language selection option being Polish. The cause behind the expression of such limited file behaviour would require further examination of code.

Figure 15. ClickPlay application screenshot

Upon analysis of the in-memory strings found while running the file, the list of executed process during the run time of the binary and changes to the registry keys, one potential defense evasive technique identified was the checking for the RecentDocs registry key for the number of documents on the target system.

This anti-sandbox technique was mentioned by Unit42 in their Inside SnipBot: The Latest RomCom Malware Variant" article. This observation requires further investigation into the code to identify the relevant API functions used to lookup the registry structure and what value of the number of recent documents the file is comparing against.

0x745daeac (26): MaxRecentDocs

0x745daeac  (38): NoRecentDocsHistory

Figure 16. Registry value checks screenshot

External Correlations: Upon corelating the findings from the file analysis with recent infection chains uncovered by external reporting involving RomCom, the Palo Alto's Unit 42 article "Inside SnipBot: The Latest RomCom Malware Variant" shows overlap to a certain extent based on the recent reporting period, initial infection chain, checking of recent documents as form of defense evasion, similar file names and other factors.

File Assessment

After correlating the findings from the file analysis independently, there are no signs of suspicious or malicious activity emitted from the file. However, it is important to recognise that this requires further examination of the file which was determined to be out of scope at the time of writing this.

There is a confirmation bias in the analysis where we are searching for evidence to support our earlier infrastructure analysis pointing towards RomCom activity along with the subsequent detection of the file as RomCom according to ESET. 

Diamond Model

Figure 17. Diamond Model for “Operation Deceptive Prospect” campaign

Tactics, Techniques and Procedures (TTPs)

• T1036: Masquerading
• T1036.008: Masquerade File Type
• T1199: Trusted Relationship
• T1497: Virtualization/Sandbox Evasion
• T1553.002: Code Signing
• T1566: Phishing
• T1566.002: Spearphishing Link
• T1583: Acquire Infrastructure
• T1584: Compromise Infrastructure
• T1584.003: Virtual Private Server
• T1585.002: Email Accounts
• T1587.002: Code Signing Certificates
• T1588.007: Artificial Intelligence
• T1656: Impersonation

Threat Hunting and Detection Analytics

For KQL and YARA detection content, please visit the Bridewell CTI Github repository here: https://github.com/Bridewell-CTI/

Indicators of Compromise (IOCs)

For a full list of IOCs linked to this campaign, please visit the Bridewell CTI repository here:

https://github.com/Bridewell-CTI/IOCs/blob/main/2025/04/Operation_Deceptive_Prospect.txt

References

https://unit42.paloaltonetworks.com/snipbot-romcom-malware-variant/

https://www.welivesecurity.com/en/eset-research/romcom-exploits-firefox-and-windows-zero-days-in-the-wild/