Inside the FortiBleed Operator’s Browser History

Introduction

Those of you who closely followed the developments may remember the SOCRadar Threat Research team’s in depth analysis of the FortiBleed operation in June and July 2026, which was found to be associated with the Lynx and INC ransomware groups.

In operations like these, critical operational security mistakes (OPSEC) made by threat actors can enable security researchers to uncover an attacker’s identity and operating methods by following the digital traces they leave behind. In this article, I decided to take a closer look at the FortiBleed operator’s Chrome profile files and show what can be learned from an attacker’s digital footprint.

For this analysis, I first identified which of the following key profile files, created in the Chrome/Default directory on April 3, 2026, were worth examining and what questions each could help answer.

Key Files

History File (SQLite)

1. Which websites did the operator access, and when?
2. What search queries did the operator perform?
3. Which technical topics did the operator research before and after the operation?
4. Which tools, services, and infrastructure did the operator investigate?
5. Which files did the operator download, from which websites, and when?
6. Which tools, software, or infrastructure were the downloaded files associated with?
7. Was there a temporal relationship between the downloads and the websites visited or searches performed?

Cache Files (Chrome Cache_Data)

1. Which web content or resources were cached by the browser?
2. Which websites, applications, or services were associated with the cache records?
3. Did the cache contain information such as file names, file paths, URLs, or content types?
4. Were there traces of websites, applications, or services in the cache that were not present in the browser history?

Cookies File (SQLite)

1. For which websites were cookies stored?
2. Were there indicators of services the operator may have logged into?
3. Were there clues indicating which services were used regularly?

Local Storage Files (LevelDB)

1. Which websites or applications left persistent data in the browser?
2. What did this data reveal about the web applications in use?
3. Did it contain information related to the user, session, or application settings?

IndexedDB Files (LevelDB)

1. Which web applications created persistent and more extensive data in the browser?
2. What did this data indicate about whether the web application was actually being used?
3. Did the application contain user, session, project, or transaction information?

Sessions Files (SNSS)

1. Which tabs were open during the last session?
2. Which websites were being used before Chrome was closed?
3. Which services or applications had been used most recently?

Web Data File (SQLite)

1. What information had been saved for autofill?
2. Was information such as a name, email address, phone number, or physical address stored?
3. Which email addresses or contact details may have been used?
4. Were there any records related to payment information?
5. Could this information help associate the Chrome profile with a specific user?

Bookmarks File (JSON)

1. Which websites had the actor specifically bookmarked?
2. Which services or tools had been saved for future use?
3. What did the bookmarked sites reveal about the threat actor’s areas of activity?

Extensions File (JSON)

1. Which Chrome extensions were installed?
2. What purposes might these extensions have served?
3. Did the installed extensions provide clues about the threat actor’s working habits or the tools they used?

The location of Chrome profile files varies by operating system.

Windows: %LOCALAPPDATA%\Google\Chrome\User Data\Default\
macOS: ~/Library/Application Support/Google/Chrome/Default/
Linux: ~/.config/google-chrome/Default/

Many of these files are SQLite databases and can be queried using the sqlite3 command. Depending on the file type, the remaining artifacts can be examined with tools such as strings and jq.

To avoid analyzing each file individually, I looked for a tool capable of performing a consolidated analysis and found Hindsight, a digital forensics tool designed to analyze web browser artifacts.

Hindsight is a tool designed to examine digital traces left by web browsers, including URLs, download history, cache records, bookmarks, autofill records, saved passwords, preferences, browser extensions, HTTP cookies, and Local Storage records.

Originally developed to analyze Google Chrome browsing history, it was later expanded to support other Chromium-based applications and can now also analyze Mozilla Firefox profiles.

Timeline Analysis

When I started going through the Hindsight timeline, I found 2,204 records associated with the operator and started reviewing them one by one, highlighting the entries that caught my attention in red.

Russian-Language Content

Among the numerous digital traces left by the operator, I also found evidence that translate.yandex.ru had been used for Russian-English translation. Together with the other indicators, this led me to assess that the operator was most likely Russian. The text submitted for translation also suggested that the operator was associated with a ransomware group.

AI-Assisted Tools

As I continued reviewing the visited addresses, I found that the operator used the Manus AI agent platform to develop tools and applications, and the OpenRouter platform, which provides access to multiple AI models through a single API, to prepare for lateral movement within the compromised environment.

When I reviewed the file download records specifically related to Manus from April and May, it became clear that the operator relied on Manus during a significant portion of the operation.

Although several months had passed, I wondered whether there might still be a way to retrieve these or related files. I concluded that examining the cache files would be a worthwhile approach and began discussing the possibility with ChatGPT. I then started scanning the Cache_Data records in the Chrome profile to identify the local file paths beginning with /home/ubuntu/ shown in the screenshot and extract the associated web addresses.

After identifying 45 addresses, I encountered a major surprise when I attempted to access one of them. Even after three months, the file was still accessible. I immediately downloaded all 45 files and began examining the artifacts left behind by the operator individually.

When I started examining the Python files, it became apparent that the operator was initially attempting to validate the remote access credentials in their possession and identify systems that could be accessed. For example, parse_remote_login.py parses IP addresses, ports, usernames, and passwords.

The files sophos_ovpn_checker.py, probe_sophos.py, and test_sophos_paths.py were used to check authentication and VPN access to Sophos devices, while download_ovpn_configs.py attempted to obtain OpenVPN configuration files after successful access.

I also found that mssql_probe_banner.py, mssql_retry_failed.py, mssql_final_retry.py, and mssql_domain_check.py attempted to connect to MSSQL services and validate credentials as well as server and domain information.

The files study_forti.py and analyze_vpn_page.py were used to examine FortiGate/FortiOS and VPN infrastructure. Other files, including domain_checker.py, domain_checker2.py, find_api_paths.py, and find_api2.py, contained checks related to domain and API discovery.

In short, the Python files indicated that the operator was testing the access credentials in their possession in order to identify usable systems.

Preparing for System Access via Virtual Media

As I continued reviewing the timeline, I saw that the operator accessed the system at 192.168.151.98 via FortiGate SSL-VPN at 80.x.y.174:10443. The operator initially used the vMedia, virtual floppy, and virtual CD-ROM functions and shortly afterward opened an iKVM (integrated KVM) session.

I then observed a visit to the Hiren’s BootCD PE download page. A few minutes later, the netboot.xyz ISO file was downloaded, followed immediately by another vm_cdrom access.

Taken together, these records suggested that the operator was not merely using the remote management interface, but was preparing to boot the target system from an alternative environment and operate outside the installed operating system using iKVM and virtual media features. In particular, the sequential download of bootable ISOs such as Hiren’s BootCD PE and netboot.xyz, followed by vm_cdrom operations, suggested that this preparation was deliberate rather than incidental.

Another Target: Synology NAS Devices

As I moved further back through the timeline, the web address titled Synology Distributed Checker, http://213.177.179.56/, caught my attention. In particular, shortly after the goods.txt file was downloaded from this website, logins to Synology network attached storage (NAS) devices were observed. This raised the possibility that the operator had somehow obtained usernames and passwords from this file for use against the devices.

To learn more about the Synology Distributed Checker page, I began searching the cache files under Cache/Cache_Data in the Chrome profile directory for HTML content. I first identified relevant files by searching for characteristic HTML structures such as <!DOCTYPE html>, <html>, <head>, and <body>.

I then converted the cache files I identified into readable text using strings, saved the output to temporary text files, and created separate .html files after removing the HTML tags. Finally, I opened these files directly in Google Chrome to visually inspect which web interfaces had been preserved in the cache.

With this method, I was able to confirm that the Synology Distributed Checker interface was indeed a cached HTML page. The interface appeared to have been designed to perform high volume username/password attempts against Synology devices and collect the results through a centralized panel.

Accessing a Previously Compromised Device

As I moved further down the timeline, the filename README_FOR_DECRYPT.txtt immediately caught my attention. When I reviewed the downloaded files, it appeared that this file had also caught the operator’s attention.

When I searched for the filename README_FOR_DECRYPT.txtt using search engines, I found that it had been associated since 2021 with the ech0raix ransomware group, which has targeted QNAP and Synology network-attached storage (NAS) devices. This raised the possibility that the FortiBleed operator had accessed a device that had previously been compromised by this threat actor.

Registered Email Addresses

When I checked the email addresses used by the operator in the timeline, I found records associated with the following websites.

URL: https://console.wasabisys.com/ Email Address: ci**79[@]cosdas.com
URL: https://manus.im/ Email Address: xi**48[@]outlook.com
URL: https://app.cyberyozh.com/ Email Address: sh**ha[@]outlook.com
URL: https://ds.smartape.net/ Email Address: sh**ha[@]outlook.com
URL: https://accounts.x.ai/ Email Address: sh**ha[@]outlook.com
URL: https://forum.exploit.in/ Email Address: am**64[@]hotmail.com
URL: https://openrouter.ai/ Email Address: am**64[@]hotmail.com

Exploit.in Records

When I looked at the Exploit.in records in the timeline, one of the better known platforms in the cybercrime ecosystem, I found that the operator performed broad searches for terms such as RDP, brute, and bthoster, and subsequently viewed threads where various brute force tools were shared.

Conclusion

This analysis showed that the Chrome profile left behind by the FortiBleed operator contained far more than visited websites and search history. It preserved a broader set of traces that helped reconstruct how the operation was conducted. Evidence ranging from the use of AI platforms and files retained in the cache to Python tools for validating access credentials, activity across attack surfaces such as FortiGate, Sophos, RDWeb, and Synology, and research conducted on Exploit.in enabled me to piece together key elements of the operator’s working methods. In particular, recovering files that remained accessible through the Chrome cache months later demonstrated how browser artifacts can help recover operational traces that might otherwise appear to have been lost.

The findings suggest that the FortiBleed operator was not a highly specialized threat actor following a fixed target or attack chain. Instead, the operator appears to have been an opportunistic, financially motivated cybercriminal who tested the access credentials in their possession against different systems, relied heavily on username/password-based access methods, automation, and ready made tools, and searched for weak links across a broad attack surface.

More broadly, this analysis demonstrates the evidentiary value of a single Chrome profile in a digital forensics investigation. Browser artifacts can provide visibility into an attacker’s areas of interest, tools, working habits, operational approach, and OPSEC mistakes, making them a valuable source of intelligence when reconstructing the activities of a threat actor.

Hope to see you in the following articles.

Show this post in PDF formatPrint this page