Denial-of-Service Attacks on Investigative Media Traced to yet another Proxy Provider

11 June 2025

On May 25, 2025, and over the following 48 hours, the independent Venezuelan investigative journalism website Armando.info was targeted by a series of denial-of-service attacks affecting various parts of its hosting infrastructure in Norway and Sweden. The attacks consisted of multiple attack vectors making the attack more complex to fingerprint and mitigate.

The attack began on the evening of May 25—the same day Venezuela held parliamentary and regional elections marked by significant political tensions, low voter turnout, and widespread opposition boycotts.

Just a few days earlier, on May 21, the Peruvian investigative outlet IDL Reporteros was also targeted by a sustained DDoS attack. Both IDL Reporteros and Armando.info are thorns in the side of their respective governments, known for their hard-hitting reporting on corruption scandals and abuses of power.

The DDoS attacks of both Armando and IDL Reporteros were once again traced to infrastructure operated by a proxy provider who lack adequate control over how their services are used by paying clients. Once again, the attacker’s account was shut down without revealing their identity, allowing them to simply open a new account the next day and resume their malicious activities.

Investigating the attacks

The Denial of Service attacks consisted of a combination of attack vectors that included:

A mitigation strategy was developed for each attack vector, beginning with the separation of the main data streams and routing them to dedicated mitigation infrastructure

The various components of the attack sought to overwhelm the target either by flooding it with massive volumes of traffic (UDP volumetric floods) or by exhausting internal resources such as memory and CPU through application-layer attacks.

An initial analysis of the SYN floods revealed that the attacker was generating spoofed connection attempts. To evade mitigation techniques, the attacker varied SYN packet parameters—such as window scale (wscale), maximum segment size (MSS), and window size (win). Additionally, some SYN packets included the experimental TCP Fast Open (TFO) flag to further complicate filtering efforts.

After processing several packet captures obtained during the attack traffic, we could isolate three distinctive packet generators. Each of the packet generators operated spoofing a 1GE port at full line rate. Every generator was roughly able to generate 1.5 Million packets per second.

An analysis of traffic patterns from over 100 million recorded sessions provided valuable insight for designing our mitigation filters, as legitimate traffic does not match several distinctive signatures observed in the flood traffic.

As usual in Denial of Service the challenge is not just to detect bad patterns but to mitigate the spoofed traffic at high speed rates.

While several parts of the infrastructure were mitigating the different attack vectors, we focused on recording and analyzing what it is often the most interesting piece of forensic information, the real IP addresses conducting web application floods.

Not surprisingly, the first thing we identified was that the attackers were using the third-party service “check-host” to monitor the effectiveness of their attack. The hosting providers behind “check-host” deserve an article of their own. Among them are several well-known enablers of DDoS activity and disinformation, including Aeza, Stark Industries, Alexhost, and — unsurprisingly — the top name in bullet proof hosting solutions: Hetzner Online GmbH.

Fingerprinting the attack – KOK to the Rescue

When fingerprinting an attack, we look for something that stands out from the regular valid traffic. In this case we noticed the presence of a very rare ISO code for a browser language – KOK. Konkani – with ISO code KOK – is a minority language spoken by a couple of million people in India. This very specific language setting in the browser, lead us to a handful of ASN involved in the attack:

AS394432 PEG-SG | SG, Singapore
AS398993 PEG-TY | JP, Japan
AS399195 PEG-KR | US, United States
AS398823 PEG-LA | US, United States

More than 300 IP addresses come from the ASNs belonging to Peg Tech Inc, a California registered entity that operates Aquanx , RAKsmart and Petaexpress.

When looking into the IP addresses used in the attack coming from the different ASN run by “PEG” we found that all of them had the same port number open during the attack time. Port number 24785. This is common feature of proxy services that allocate a port number from a pool of proxies to a given customer.

Reaching out to PEG Tech Inc

Peg Tech Inc was established in 2012 in San Jose, California, and offers access to several Chinese upstream providers including China Mobile International or China Telecom.

The origins of the company can be traced back to several to another companies registered in California Easy2Service Inc e2svs.com that was later on renamed to Dignitas Technology Inc. and to be recently converted to a Delware company PetaCloud AI Inc. petacloud{.}ai

The company runs under the brand names of RAKsmart, Aquanx and Packetexpress. There is little or no information about the company’s ownership in social media and the only visible public records point to: David Chaung and Wei Zhang. Other records point to Zhang Pengfeng, Haiyan Zhang or Serry Zhang.

We also found that the company runs a You Tube channel with thousands of videos generated by AI with only a handful number of views.

We reached out to Peg Tech Inc on the 28th of May via email to all abuse e-mail address of all the entities we could find, RAKsmart, Aquanx and Packetexpress. The mail to Aquanx bounced.

During several days we exchanged emails with RAKsmart. All responses were signed as “RAKsmart Team” and included standard phrases to bounce our claims of attack.

• Hello, through verification, the customers using these IPs have not experienced the above attack behaviors. If you receive abnormal behaviors again, please provide detailed logs and inform the corresponding port information.
• It was checked here that the traffic of the machine was stable during the attack period, and no historical records of connecting to the IP x.x.x.x were found on the server.
• No IP in this IP range has been found. You can observe again. If there is a latest log, resubmit the work order for feedback.
• Please check whether the attack is still going on.
• No measures have been taken here and the corresponding server is operating normally, so the attacker’s IP remains to be verified.
• It has been sealed.

Finally, on the 31st of May we received a message from RAKsmart stating:

“After reviewing your logs, we confirmed that many involved IP addresses belong to a single customer. We have suspended the related servers and issued a strict warning, making it clear that further violations will result in permanent service termination.”

What is hosted at Peg Tech Inc?

In examining signs of malicious activity associated with Peg Tech Inc., we found multiple reports linking the company to malware hosting. A 2017 report claimed that Peg Tech was unresponsive to abuse complaints related to malicious activity originating from its networks. Earlier, in 2012, the company was found to be providing hosting services to Dudrop (AS46230), a network known for operating spam campaigns. More recent research has highlighted Peg Tech’s reputation for supplying fraudulent geolocation data, further underscoring concerns about its role in enabling abusive practices.

Our research also revealed that Peg Tech was identified to route misappropriated IPv4 space from Afrinic.

Peg Tech Inc is highly likely providing services to more than one proxy provider including Yilu Proxies and Nexusnet. According to research from F5, Nexusnet is one of the brands of a proxy provider that also includes asocks[.]com, ake[.]net, blackproxy[.]io, sx[.]org, any-page[.]io and nexusnet[.]io.

The table below summarizes the IP addresses run by Peg Tech’s ASNs leased out from pools originated in Afrinic via Larus (Lu Heng).

Conclusion

Despite repeated efforts to obtain from Peg Tech Inc. the name of the proxy service believed to be operating tens of thousands of IP addresses under the “Packet Express” label, the hosting provider remained steadfast in its commitment to privacy. Peg Tech refused to disclose the identity of the customer allegedly responsible for abusive activity, asserting that such information would only be released in response to a lawful subpoena. Although the company acknowledged the reported issue and blackholed the offending IP address, it declined to disclose the client’s identity or specify who within the organization handles abuse complaints.

This policy allows proxy operators to control vast IP ranges via Peg Tech’s infrastructure with minimal external scrutiny, effectively shielding potentially malicious actors from accountability. While Peg Tech asserts that it takes abuse seriously, its refusal to share even basic identifying information, coupled with an opaque and impersonal abuse reporting process, raises significant concerns.

Despite these obstacles, we succeeded in uncovering a critical component of the infrastructure behind the attacks. However, Peg Tech’s unwillingness to fully cooperate leaves the broader issue unresolved and casts doubt on its commitment to mitigating abuse.