OmegaTech: Evidence of Persistent Malicious Infrastructure

Introduction

IP addresses are often one of the first places defenders look when suspicious activity appears. They can connect a detection to known infrastructure, reveal where a payload was hosted, or give security teams something concrete to block. Alongside domains, URLs, and file hashes, they form much of the basic evidence used to investigate and contain malicious activity. The problem is that individual indicators are easy to change. An attacker can move to a new IP, register another domain, or replace a payload once the original infrastructure starts getting detected. This is one of the ideas behind the Pyramid of Pain: lower-level indicators such as hashes and IP addresses are useful, but they are also relatively easy for an adversary to replace. That does not make IP-based indicators less valuable. It means defenders need a way to look beyond one address at a time. Instead of treating each IP as a separate finding, analysts can look at the larger network responsible for routing that address and ask whether the same environment keeps appearing across suspicious activity.

ASN context is particularly useful when the same network repeatedly appears across malware delivery, command-and-control, phishing, or other abuse-related activity. Some hosting providers become known for tolerating malicious customers or failing to respond effectively to abuse, while others may simply contain a mix of legitimate and suspicious infrastructure. For that reason, an ASN association is not evidence that every address in the network is malicious or that the operator knowingly supports abuse. It is a way to identify recurring concentrations of risk that may not be visible when indicators are reviewed one at a time.

Which brings us to AS202412. This particular ASN, operated by OmegaTech LTD, caught the team’s attention because it kept reappearing across different incidents, activity groupings, and related infrastructure. The repetition suggested that the network was worth examining as more than a collection of individual IP addresses. The goal was to determine whether the available evidence supported treating AS202412 as high-risk infrastructure and applying network-level controls where no legitimate business need existed. The sections that follow assess whether the recurrence, concentration, and repeated reuse of AS202412 infrastructure justify increased defensive scrutiny at the network level.

OmegaTech ASN profile

AS202412 is a relatively small and recently established autonomous system. Its RIPE organization record, ORG-OL329-RIPE, was created on January 5, 2026, followed by the autonomous system record on January 12. During the June/July 2026 review period, public routing sources identified 20 /24 prefixes associated with AS202412, representing a research corpus of 5,120 IPv4 addresses. No IPv6 prefixes were observed during the review period. RIPE RIS routing history showed that most of the reviewed address space began appearing under AS202412 shortly after its registration, with additional prefixes following over the next several months. One range, 45.74.59.0/24, had limited and inconsistent visibility across route collectors, while the remaining 19 prefixes were more consistently observed under AS202412. Because internet routing changes over time, these figures represent the finalized research snapshot rather than a permanent total. Internal activity was therefore evaluated against the observed transition date for each individual /24 rather than treating the address space as a single static block.

OmegaTech is registered in Seychelles, but that designation offers limited insight into where the infrastructure is physically located or who is operating activity from it. Public geolocation and provider metadata associated portions of the address space with several countries, including Germany, the Netherlands, and the United States. These differences may reflect the separation between registration, routing, hosting location, and customer infrastructure.

AS202412 (OmegaTech LTD) relies on a small number of upstream networks for connectivity. Observed BGP data identified AS30823 (aurologic GmbH) and AS51396 (Pfcloud UG) as upstream providers, while the RIPE aut-num record also listed an import/export policy involving AS203446 (SMARTNET LIMITED). The aurologic relationship is relevant because Recorded Future identified the provider as a common upstream for several abuse-heavy networks, including AS209800 and AS214943 (Railnet LLC), in November 2025. Both AS209800 and AS214943 (Railnet LLC) also appeared in the history of address space later announced by AS202412 (OmegaTech LTD). RIPE routing data showed that all 20 reviewed prefixes had previously originated from other ASNs, with AS209800 appearing in the history of 12. Recorded Future reported that AS209800 had been registered using the identity of the legitimate German company metaspinner net GmbH without its involvement and documented a substantial malicious footprint within the ASN. Much of the same address space later appeared under AS214943 (Railnet LLC) before moving through additional origin networks and eventually appearing under AS202412 (OmegaTech LTD). This routing history provides relevant context, but it does not by itself establish common ownership, control, or responsibility across the networks involved. It does, however, place AS202412 within a routing environment that had already drawn scrutiny before OmegaTech was established.

IPv4 space routinely moves between networks through transfers, leases, reassignments, or provider changes, so a change in origin ASN is not inherently suspicious. Routing history shows which network announced a prefix at a particular time, but it does not establish ownership, explain why the space moved, or prove a relationship between the operators involved. The history still matters because intelligence attached to an IP address does not reset when its routing changes. At the same time, activity that occurred before a prefix moved into AS202412 should not be attributed to OmegaTech. Earlier internal observations were therefore retained only as historical context. The primary findings below include only activity observed after the applicable prefix began originating through AS202412.

What the internal data shows

An initial January–June 2026 scope check showed that OmegaTech represented a disproportionate share of activity within the reviewed incident dataset. The dataset was limited to incidents ingested through the team’s primary incident-analysis workflow and does not represent all detections across every security platform or activity type. However, within that scope, the 24 OmegaTech addresses accounted for only 0.55% of unique incident-linked IPs, yet appeared in 14.25% of reviewed incidents and 21.11% of reviewed incidents containing at least one IP address observation. ASN mappings were available for 99.19% of unique incident-linked IPs, reducing the likelihood that the concentration resulted primarily from missing ASN enrichment. After applying each prefix’s AS202412 first observed date, the qualifying incidents involved addresses from 11 of the 20 reviewed /24 ranges. Incidents containing multiple OmegaTech addresses were deduplicated at the incident level, while the underlying IP relationships were retained to evaluate recurrence across individual hosts and prefixes.

To better understand how that activity was distributed across the network, the reviewed incidents were broken down by prefix and recurring address. The results showed that activity was not evenly spread across the ASN, but concentrated within a small number of ranges. Addresses in 178.16.52.0/24 appeared in nearly 45% of the reviewed incidents, followed by 158.94.208.0/24 and 158.94.209.0/24, which appeared in approximately 31% and 27%, respectively. Figure 1 shows this distribution across the most frequently observed prefixes and also indicates how many unique IP addresses contributed to each prefix’s incident share. The concentration took different forms: some ranges contained several recurring addresses, while activity in others was dominated by a single host.

Figure 1: Distribution of OmegaTech-linked incidents by observed prefix

Share of incidents containing at least one address from each listed prefix. An incident may include more than one prefix, so the percentages are not mutually exclusive. The number of unique IP addresses observed within each prefix is shown above the corresponding bar.

The incident timeline showed that this activity was sustained across the six-month review period rather than confined to a single short-lived spike. Incidents involving qualifying AS202412 address space were observed in every month from January through June 2026, with continued activity through the end of the review period. Recurrence was concentrated among a relatively small set of addresses. Of the 24 IPs observed in the reviewed incidents, 17 appeared more than once, with several recurring across a substantial number of incidents. Eight IPs were active during more than one calendar month, while several high-frequency addresses were associated with multiple activity groupings. Figure 2 illustrates this recurrence over time, showing when the most frequently observed AS202412 addresses appeared across the six-month review period.

Figure 2: Monthly recurrence of frequently observed AS202412 IP addresses

Color intensity reflects the volume of internal incidents associated with each IP address by month. Exact counts are not shown. White cells indicate no observed incidents.

Recurrence took more than one form. Some addresses appeared in concentrated bursts, while others remained present across several consecutive months. One especially active address was concentrated in February and March, while other frequently observed hosts recurred from March through June. Several were associated with more than one delivery or staging pattern. This distribution indicates repeated reuse of a limited set of infrastructure rather than a corpus dominated by one-time observations.

Review of the underlying case activity showed that the recurring infrastructure supported several distinct delivery and post-compromise roles. The patterns were evaluated as broader behavioral families rather than by internal cluster labels, since several labels captured variations of the same underlying technique.

The largest recurring family used OmegaTech addresses directly as retrieval infrastructure. In these incidents, PowerShell commands were used to contact an OmegaTech IP and execute the returned content, most commonly through short Invoke-RestMethod (irm) or Invoke-WebRequest (iwr) sequences combined with Invoke-Expression (iex). Related cases wrapped the retrieval logic in try/catch blocks or constructed the destination IP through string concatenation before following the same broader sequence. In some process trees, the activity continued into additional PowerShell execution and .NET compilation. Despite differences in command construction and follow-on activity, the cases reflected one broader direct-IP loader pattern in which OmegaTech infrastructure was used directly to retrieve and execute additional content.

A second recurring family used verification-themed domains, hidden PowerShell, tokenized download paths, and randomized temporary staging. Earlier observations relied heavily on .beer domains, as well as a few .pro domains. Many of those domains resolved to 178.16.52.101, which served as a major concentration point for the activity. Some chains downloaded and launched a script or executable directly. Others retrieved an extraction utility and archive before executing the expanded payload. This placed OmegaTech infrastructure directly in the domain-hosting and payload-staging portions of the chain.

Other incidents showed AS202412 serving different roles at different points in the intrusion chain. In a smaller cluster, the intrusion began with finger.exe retrieving commands from a remote server, while OmegaTech-hosted command-and-control infrastructure appeared later in the chain. In another pattern, OmegaTech-hosted domains delivered both a remote HTA file and a follow-on MSI file, placing the network directly in the initial and secondary delivery stages. These examples show that AS202412 was used not only for direct retrieval and domain-based staging, but also for later command-and-control and multi-stage payload delivery.

The case-level examples above describe how OmegaTech infrastructure appeared in internally observed incidents, but they cover only the addresses captured in those investigations. To examine risk signals beyond the addresses present in the incident dataset, the review separately assessed threat-intelligence relationships attached to other IP observables directly associated with AS202412 within the platform. Command-and-control infrastructure and general RAT activity were the most common associations, followed by several named malware families and delivery classifications. Figure 3 summarizes those associations and shows that the threat-intelligence context attached to AS202412 extended beyond the limited set of IPs observed in internal incidents.

Figure 3: Threat intelligence labels for OmegaTech ASN IPs outside the incident dataset

Counts represent unique IPs within each normalized label bucket. Categories overlap, so one IP may appear in multiple rows. Source-specific and duplicate labels were consolidated into broader categories. For example, “botnet_c2” and “c2” were grouped under “command-and-control,” while “remcos” and “remcosrat” were grouped under “Remcos.” Source and feed-related labels were excluded.

To explore the network from another angle, the analysis reviewed IP observables already present in the platform that fell within the current AS202412 address space but were not directly linked to the OmegaTech ASN entity. It then examined which ASN relationships those observables did retain and whether any patterns emerged. That comparison identified approximately 400 IPs that remained associated only with earlier origin networks, primarily AS214943 (Railnet LLC) and AS209800. Figure 4 shows how those retained ASN relationships were distributed.

Figure 4: ASNs previously associated with current OmegaTech address space

Distribution of previous ASN relationships attached to IP observables now located within the AS202412 address space. One isolated relationship was omitted.

The historical relationships were not necessarily incorrect. In most cases, they were valid for the time they were created, but they did not reflect the current routing state. This exposed an enrichment gap: an ASN-only query for AS202412 omitted hundreds of observables whose addresses now fall within the OmegaTech-announced space. Historical ASN context should therefore be retained alongside current prefix-based mapping. One shows where the infrastructure was previously routed, while the other shows where it’s routed now.

Mapping the broader OmegaTech footprint

The internal incidents represented only a portion of the address space associated with OmegaTech. To better understand the surrounding infrastructure, the review also considered historical and current DNS data, active-service observations, IP enrichment, and third-party threat intelligence across the 5,120-address research set (including the range with inconsistent route-collector visibility). These sources provided uneven and incomplete visibility. Some addresses appeared in multiple datasets, while others had little or no available context. The results were therefore used to assess the breadth of observable infrastructure around AS202412, not to classify every address in the network as malicious.

The broader domain review reinforced the tokenized delivery pattern described above. Across the reviewed address space, approximately 13,000 domains resolved to addresses within the OmegaTech ranges at some point in the available historical DNS data, and over 12,000 still resolved within those ranges at the time of collection. Those domains were not evenly distributed across the network. Many converged on a relatively small number of hosts. The concentration was especially pronounced among .beer domains, with 109 historical domain-to-IP relationships distributed across only 12 addresses. This pattern aligned with the internally observed activity, where OmegaTech-hosted domains supported tokenized requests, script and archive staging, and follow-on payload delivery. In April 2026, LevelBlue independently reported ErrTraffic-related .beer domains and similar verification- and CDN-themed delivery infrastructure within AS202412, closely aligning with the tokenized delivery activity observed internally.

Third-party intelligence provided additional context beyond the addresses observed internally, including reporting related to command-and-control infrastructure, RATs, credential stealers, botnets, and malware delivery. ThreatFox’s ASN-level reporting offered a complementary network-wide view. As of July 2026, its AS202412 report aggregated nearly 1,500 observables and associated the ASN with several malware families, including ClearFake, Lumma, AsyncRAT, Remcos, DCRat, Vidar, Stealc, and Tofsee. The breadth of those associations suggests that activity tied to the network was not limited to a single malware family or infrastructure role.

The broader datasets did not show uniform risk across all 5,120 addresses, but they did identify abuse-related signals beyond the 24 IPs present in internal incidents. Domain relationships and external intelligence extended the observed risk context into additional parts of the announced space. That wider distribution supports evaluating AS202412 as a network-level risk while preserving uncertainty around legitimate or otherwise uncharacterized addresses.

What this means for MSPs

For MSPs, the primary concern is not whether every address announced by AS202412 can be individually confirmed as malicious. The operational question is whether the network presents enough concentrated and recurring risk to justify treating it differently from ordinary hosting infrastructure.

The available evidence supports treating AS202412 as a high-risk network for defensive purposes. Internal activity was observed across 11 of the network’s 20 identified /24 ranges, with several prefixes containing recurring addresses associated with multiple incidents and activity patterns. External intelligence added associations with command-and-control infrastructure, botnets, RATs, credential stealers, malware delivery, redirectors, and impersonation activity across other portions of the network. Domain data and ASN-level reporting further showed that the broader context was not limited to the addresses observed directly in internal incidents, although the strength and type of evidence varied across the network.

Because the evidence spans recurring hosts, multiple prefixes, and related domain infrastructure, controls limited to the individual IPs and domains already observed would address only the known portion of the risk. Individual indicators remain useful for investigation and enforcement, but ASN and prefix context can expose relationships between addresses that would otherwise be reviewed separately. This network-level context can support earlier alerting, broader threat hunting, and more consistent controls. Organizations with no identified business need for the network may reasonably consider blocking prefixes currently observed as announced by AS202412. The decision should reflect the customer’s risk tolerance and should be tested against historical traffic where possible.

Any broader control must also account for changes in the network’s routing footprint. Enforcement lists should be generated from current routing data rather than from a permanent list of every prefix historically associated with AS202412. Routing visibility can vary across collectors and change over time, as demonstrated by the inconsistent visibility of 45.74.59.0/24. Organizations should therefore validate the routes visible from their own environment or selected routing source before applying or refreshing network-level controls. A full block may not be appropriate in every environment. MSPs should maintain a documented exception process for customers with a confirmed business need. Any permitted connection to OmegaTech space should still be reviewed in context, including the destination domain, protocol, initiating process, user activity, and surrounding telemetry. Exceptions should be limited to the required destination and business purpose rather than applied to the ASN as a whole.

Organizations unable to block the network outright can still apply high-risk treatment:

• Alert on inbound and outbound connections involving currently announced AS202412 prefixes.
• Enrich related addresses with both current and historical routing context, when available.
• Hunt retrospectively for customer connections to the OmegaTech ASN space.
• Review associated domains and URLs for suspicious delivery patterns, including tokenized requests and secondary payload distribution.
• Escalate activity involving script interpreters, payload retrieval, credential access, or remote-administration tooling.
• Refresh prefix mappings regularly and adjust enforcement as route visibility changes.

Historical ASN context should also remain available during investigation. Searches limited to the current AS202412 relationship may omit observables still associated with prior origin networks, while historical enrichment alone may fail to reflect current routing. Both views are needed.

ASN-level controls are broader than blocking a single indicator, but that broader scope is also their operational value. In this case, repeated internal exposure, abuse-related findings across multiple prefixes, and independent domain and threat-intelligence associations support treating AS202412 as high-risk infrastructure. For MSPs managing many customer environments, network-level blocking is a defensible option where no business requirement exists, provided that current routing data is used and any exceptions are limited to specific, verified needs.

References

Bianco, David J. “The Pyramid of Pain.” Enterprise Detection & Response, March 1, 2013. https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html

RIPE NCC. “OmegaTech LTD — ORG-OL329-RIPE.” RIPE Database. https://apps.db.ripe.net/db-web-ui/lookup?key=ORG-OL329-RIPE&source=RIPE&type=organisation

RIPE NCC. “AS202412 — OMEGATECH-AS.” RIPE Database. https://apps.db.ripe.net/db-web-ui/lookup?key=AS202412&source=RIPE&type=aut-num

RIPE NCC. “Routing History.” RIPEstat Data API Documentation. https://stat.ripe.net/docs/data-api/api-endpoints/routing-history.html

BGP.Tools. “AS202412 — Omegatech LTD.” https://bgp.tools/as/202412

Recorded Future, Insikt Group. “Malicious Infrastructure Finds Stability with aurologic GmbH.” November 2025. https://www.recordedfuture.com/research/malicious-infrastructure-finds-stability-with-aurologic-gmbh

LevelBlue SpiderLabs. “Err-Hiding and Seek: How ErrTraffic v3 Leverages EtherHiding in ClickFix Campaign.” April 2026. https://www.levelblue.com/blogs/spiderlabs-blog/err-hiding-and-seek/how-errtraffic-v3-leverages-etherhiding-in-clickfix-campaign

ThreatFox. “ThreatFox ASN Report: AS202412.” abuse.ch. https://threatfox.abuse.ch/asn/202412/