Authors: Jacques Portal, Renée Burton

 
Hazy Hawk

Hazy Hawk is a DNS-savvy threat actor that hijacks abandoned cloud resources of high-profile organizations. By “cloud resources” we mean things like S3 buckets and Azure endpoints. You might have read about domain hijacking; we and other security vendors have written about different techniques for grabbing control of forgotten domain names several times over the past year. While domain names can be hijacked through stolen accounts, we think the most interesting hijacks leverage DNS misconfigurations. Because DNS is not widely understood as a threat vector, these kinds of attacks can run undetected for long periods of time. At the same time, these attacks require a technical sophistication that isn’t commonplace in the cybercriminal world. Hazy Hawk finds gaps in DNS records that are quite challenging to identify, and we believe they must have access to commercial passive DNS services to do so.

The hijacked domains are used to host large numbers of URLs that send users to scams and malware by way of different traffic distribution systems (TDSs). This actor came to our attention after successfully gaining control of subdomains of the U.S. Center for Disease Control (CDC) in February 2025. Hundreds of URLs hosted on the CDC subdomain appeared suddenly and surfaced in search engine results, their result rankings buoyed by the credibility of the CDC. We soon realized that other government agencies across the globe, large universities, and international companies had been victimized by the same threat actor since at least December 2023. Figure 1 shows a simple view of Hazy Hawk operations.

Figure 1. A high-level overview of how hijacked cloud resource domains are used for malicious activities by Hazy Hawk

Figure 1. A high-level overview of how hijacked cloud resource domains are used for malicious activities by Hazy Hawk

The discovery of vulnerable DNS records is a complex problem and indicates that Hazy Hawk has access to a large passive DNS service. These types of hijacks rely on misconfigured DNS records and can involve multiple DNS records in a chain that is not visible through normal internet probing. In addition, the integration of malicious push notifications in the attack chain acts as a force multiplier.

Perhaps the most remarkable thing about Hazy Hawk is that these hard-to-discover, vulnerable domains with ties to esteemed organizations are not being used for espionage or “highbrow” cybercrime. Instead, they feed into the seedy underworld of adtech, whisking victims to a wide range of scams and fake applications, and using browser notifications to trigger processes that will have a lingering impact. Hazy Hawk is indicative of the lengths scam artists will go to get a portion of the multi-billion-dollar fraud market. In the senior population within the United States alone, citizens lose billions of dollars a year to the type of content Hazy Hawk delivers.1

Hazy Hawk uses layered defenses to protect their operations from discovery. By hijacking very reputable domains, they evade and hinder security analysis. Furthermore, Hazy Hawk uses code from legitimate websites to disguise their own content. The URLs typically redirect visitors through a second set of domains before entering a TDS for further routing. We found that a subdomain of the well-established js[.]org was used to deliver fake videos and games, for example, while in other cases Hazy Hawk appears to have set up the redirection site themselves.

Backstory

Our discovery of Hazy Hawk starts with Brian Krebs. He alerted us that the CDC domain, cdc[.]gov, was suddenly hosting dozens of URLs that referenced porn videos. These could be seen in search engine results and carried the credentials of the CDC in the search metadata. In addition to pornography, there were also advertisements for a British football match (see Figure 2). Krebs initially thought that the CDC website had what is called an open relay, allowing traffic to freely redirect across their domain. But from our DNS perspective, it did not look that way.

Figure 2. An example of Hazy Hawk hijacked domains in Google search results on February 16, 2025

Figure 2. An example of Hazy Hawk hijacked domains in Google search results on February 16, 2025

Why did we suspect DNS hijacking? All the URLs were on a strange subdomain of the primary domain, ahbazuretestapp[.]cdc[.]gov. This isn’t the kind of subdomain a threat actor is likely to choose, so we checked for active CNAME records. It turned out that the subdomain was aliased to an Azure website. The Azure domain was the site of the hijack. Shown in Figure 3, DNS queries for ahbazuretestapp[.]cdc[.]gov will lead to ahbdotnetappwithsqldb[.]azurewebsites[.]net.

Figure 3. The IP resolution chain for ahbazuretestapp[.]cdc[.]gov on February 16, 2025

Figure 3. The IP resolution chain for ahbazuretestapp[.]cdc[.]gov on February 16, 2025

At this point, we were certain that the CDC had abandoned their Azure service, and that the hacker then found its corresponding, so-called dangling, DNS record. Hijacking was as easy as creating an Azure account and a site with the same name. But how does this all work?

CNAME Hijacking

CNAME records are a type of DNS record that maps one domain name (the alias) to another (the CNAME). Very basically, it is a way for you to tell a resolver that, if someone wants to access something[.]on-your-domain[.]com, they can find it somewhere[.]on-another-domain[.]com. See Figures 4 and 5. These records are commonly used by content delivery networks (CDNs) to distribute large files you don’t want to handle yourself.2

Figure 4. Simplified view of DNS CNAME resolution

Figure 4. Simplified view of DNS CNAME resolution

Figure 5. An example CNAME chain for cloud resources

Figure 5. An example CNAME chain for cloud resources

When a DNS CNAME record exists, but the resource it points to does not, the record is considered dangling. An attacker registers the missing resource to hijack the domain. Traditional dangling CNAME attacks take advantage of cases where the DNS record points to a domain that is not registered. The email security firm Guardio wrote about a threat actor who used this technique to imitate major brands in spam distribution.3 In that case, for example, marthastewart[.]msn[.]com had a CNAME record pointing to msnmarthastewartsweeps[.]com. The latter domain had not been registered by MSN, but the DNS record had not been removed. By registering the abandoned domain, the spammer could send emails as MSN. For only a few dollars, the spammer gained a tremendous advantage.

Domain hijacking sounds so easy: find a misconfigured DNS record, register a domain, and you are off to the races! But to hijack these domains, attackers first must find the dangling CNAME record. Even with free publicly available tools, effort and access to DNS data is required. For traditional CNAME hijacks, potential records can be checked by querying the alias domain to see if it is registered. A DNS response of NXDOMAIN is a telltale sign that the domain is ripe for hijacking.

But Hazy Hawk is not a traditional hijacker, and hijacking cloud resources is not as easy as looking for an NXDOMAIN response. Identifying abandoned cloud resources is significantly more challenging than identifying unregistered domains. Every cloud provider handles missing resources differently. While a few providers will respond with an NXDOMAIN, most of them will respond with an IP address. Beyond that, there are even more challenges to isolating vulnerable DNS records. Some major cloud providers, like Azure, have implemented specific mechanisms to prevent hijacking even when a dangling record exists.

We are not going to share methods to isolate exploitable CNAME records. Let’s just say it requires extensive passive DNS access and ingenuity. Finding cloud resources susceptible to hijacking is significantly more labor intensive than finding lame name server delegations that are vulnerable to a Sitting Ducks attack.4 Hazy Hawk and other cloud resource hijacking actors are likely doing significant manual work to validate vulnerable domains due to the various ways each cloud provider handles dropped resources. In contrast, through random sampling, we identify thousands of domains every day that might be susceptible to a Sitting Ducks attack, and tens of thousands of domains have been hijacked since 2020.

Hazy Hawk

So, let’s talk Hazy Hawk. They are very good at finding abandoned cloud resources. We’ve seen attacks against dozens of major organizations since at least December 2023.5 They have commandeered domains (see the Indicators section for a full list) from:

  • Federal and regional government entities worldwide, such as alabama[.]gov and health[.]gov[.]au
  • Universities: berkeley[.]edu and ucl[.]ac[.]uk
  • Healthcare companies and organizations: cdc[.]gov and dignityhealth[.]org
  • Media and other large corporations: deloitte[.]com, ey[.]com, pwc[.]com and ted[.]com

Hazy Hawk has usurped resources on these services, and possibly others:

  • Akamai
  • Amazon EC2, S3 and Elastic Beanstalk
  • Azure (various cloud services)
  • Bunny CDN
  • Cloudflare CDN
  • GitHub
  • Netlify

We use the name Hazy Hawk for this actor because of how they find and hijack cloud resources that have dangling DNS CNAME records and then use them in malicious URL distribution. It’s possible that the domain hijacking component is provided as a service and is used by a group of actors.

Hazy Hawk creates large numbers of URLs on the reputable resource. These URLs lead to a variety of scams and malware through affiliations with other actors. The first image in Figure 1 shows a high-level view of their operation. The URLs are cloaked—meaning their true nature is hidden—through the integration of sketchy adtech services. For example, visiting one of the CDC links led to a TDS operated by Adsterra. Navigating to the link from a VPN led to a webpage containing the text “anonymous proxy detected,” while a residential IP address led through a maze of malicious content dependent on device and location. We captured examples of this rerouting behavior (see these screenshots), by clicking one of the URLs on an Android phone.

Hazy Hawk uses layered defenses to disguise their activities, including:

  • Hijacking subdomains of highly popular, reputable domains connected to cloud resources
  • Obfuscating URLs
  • Using content from other reputable websites as a basis for their initial page
  • Redirecting through at least one other URL using a well-known service
  • Redirecting into a TDS designed to cloak the final landing page

URL Obfuscation

In certain cases, the malicious URLs are obfuscated to make it less obvious which cloud resource was hijacked. One way the threat actor does this is with URL redirection. For example, in January 2025, we saw Hazy Hawk exploit an open relay on the University of Bristol’s website to redirect victims to the domain they hijacked: agri-offers[.]michelin[.]co[.]uk. See Figure 6. Abuse of open relays is not new; Brian Krebs documented their use by spam actors in 2016.

Figure 6. Hazy Hawk hijacked domains using URL redirection

Figure 6. Hazy Hawk hijacked domains using URL redirection

Another obfuscation trick they use is specific to AWS S3 buckets. Their malicious URLs are sometimes written in such a way that they do not directly refer to the hijacked resource name. For example, Hazy Hawk hijacked the S3 bucket oercommons in March 2025, but instead of using that domain name in the distributed scam URLs, like this:

Https[:]//oercommons[.]s3[.]amazonaws[.]com/<params>

they used an alternate format like this:
Https[:]//s3-ap-southeast-2[.]amazonaws[.]com/oercommons/<params>

This format hides the bucket name and thwarts blocking based on the fully qualified domain name of the bucket. Clever! Figure 7 shows another example and includes other domains that were contacted while loading the URL.6

Figure 7. AWS subdomain obfuscation; the hijacked bucket name is hidden in the URL path https://urlquery.net/report/64ae0264-9f2a-4234-b8b6-8b8a8030a2f4

Figure 7. AWS subdomain obfuscation; the hijacked bucket name is hidden in the URL path https://urlquery.net/report/64ae0264-9f2a-4234-b8b6-8b8a8030a2f4

Stealing Legitimate Website Content

Hazy Hawk uses legitimate, often high-profile websites as the basis of their initial site content. They then modify the site to redirect to a second location. To a content crawler, the majority of the site will appear legitimate.

In some cases, they used a clone (pure copy of the HTML) of the page, such as the New York Times,7 for their own main page. Although it might fool a content crawler (probably the goal) it won’t fool real humans any time soon. We have seen Hazy Hawk do this for quite a few of the domains they have taken over, up until mid-February. It is unclear if they only did this for domain names they didn’t think were valuable, or if they just did it to all of their domains up until that point, but this content cloning is not the best disguise.

More recently, we’ve seen them try a bit harder, and at least do a bit of research into the companies owning the domains they are hijacking. For example, when they hijacked a subdomain of honeywell[.]com, visiting it with a browser would land the user on a website that pretended to be Honeywell (the HTML was not a copy, but imitated the original Honeywell site). The admittedly simple website8 talks about thermostats, smart home devices, and other things you might expect to find on a Honeywell domain.

Moving on from cloaking home pages, most of the webpages hosted on the hijacked domains use the same template and the same HTML headers. Hazy Hawk lures their victims with the promise of an enticing video (often pornography or pirated content). But, instead of building a video streaming website from scratch, Hazy Hawk just copied PBS. The website template they use is literally just a copy of pbs[.]org. They load the same libraries, the same stylesheets, and the same fonts, sometimes from pbs[.]org directly (shown above in Figure 7: AWS subdomain obfuscation). The one thing they do not appear to steal is PBS’ video player, which might be surprising. But in reality, they don’t need a video player: the “videos” on their websites are just blurry pictures of videos with a play button in the middle.

Initial Redirection

The initial URL often redirects through a second domain. Sometimes the initial redirect itself is a hijack. That was the case when a French government website for the Olympic Games was commandeered in November 2024. Following the event, the site was taken down, but the DNS record was not removed. Hazy Hawk created URLs that redirected users to https[:]//share[.]js[.]org/watch/, which served fake CAPTCHAs, requested permission to deliver notifications, and finally redirected users to the scam domain. If a user visited the URL from a VPN, they were blocked via TDS domains operated by an actor we track as Venal Viper.9

So how did Hazy Hawk get access to share[.]js[.]org? It turns out, they stole that too. The domain js[.]org provides free webspace to JavaScript developers.10 The developers use a subdomain of js[.]org to point to their GitHub repo.11 An established Chinese developer, Jeff Tian, had claimed the “share” subdomain six years ago, linking share[.]js[.]org to his WeShare tool.12 Somehow Hazy Hawk gained control of the subdomain in November 2024 and began using it to redirect visitors from the French government website to scam content. When we asked Jeff about it, he said that he was alerted in January by the js[.]org maintainers that his page was serving “Sports-News powered by WordPress” and not the original content.13

In many cases, the hijacked cloud domain redirects to a likely threat actor-controlled domain in Blogspot.14 For example, the domain chesta-korci-bro[.]blogspot[.]com served as the first redirection for many of the CDC URLs and was first observed in passive DNS only a month earlier.15 As of mid-April this Blogspot domain was still active and visiting individual blog entries would lead users into similar scams.16

In some instances, we have seen an intermediate redirection through one of several link shorteners, including the (formerly Twitter) URL shortening service t[.]co, TinyURL, Bitly, and Cuttly, before sending the user to the actor-controlled redirection site.17

Traffic Distribution Systems

Regardless of the first redirection, potential victims will typically be directed into a TDS, which will determine where they are sent next. The landing page is often unrelated to the initial lure. For example, the offer to watch high-profile sports matches may lead to security or gift card scams. A TDS is designed to maximize profits for the parties involved, connecting victims with the “content” they are most likely to “buy,” while protecting the network from discovery by security vendors. This combination of profit and security motivations create dynamic circumstances where it can be hard to recreate a user’s experience—the first visit may lead to a scam and the second to an Amazon shopping page.

Many of the Hazy Hawk URLs leveraging the hijacked cdc[.]gov subdomain redirected through an actor-controlled Blogspot page and then to viralclipnow[.]xyz. By sampling URL navigation paths that include this domain, we can get a view of how the TDS domains relate to the hijacked domains, initial redirects, and landing pages. The graphic in Figure 8 shows referrals and redirections of various URLs that connect to viralclipnow[.]xyz.

Figure 8. A partial view of the TDS connections of viralclipnow[.]xyz; the graph shows referrals and redirections from visiting URLs hosted on a number of primary domains, including cdc[.]gov

Figure 8. A partial view of the TDS connections of viralclipnow[.]xyz; the graph shows referrals and redirections from visiting URLs hosted on a number of primary domains, including cdc[.]gov

Figure 9 below shows the portion of Figure 8 above that contains the cdc[.]gov domain. In it, we can see how Blogspot domains were used as intermediate redirects before landing at viralclipnow[.]xyz and other domains. The graph also shows some of the scam landing domains, including clean-out[.]xyz and turbo-vpn-app[.]com. Other domains shown there are part of the TDS. When the xyz Registry closed down viralclipnow[.]xyz in February, the threat actor moved to other domains.

Figure 9. (zoom in from Figure 8) Partial view of TDS containing viralclipnow[.]xyz and subdomains of cdc[.]gov

Figure 9. (zoom in from Figure 8) Partial view of TDS containing viralclipnow[.]xyz and subdomains of cdc[.]gov

Push Notifications

Hazy Hawk is one of the dozens of threat actors we track within the advertising affiliate world. As we previously reported, threat actors who belong to affiliate advertising programs drive users into tailored malicious content and are incentivized to include requests to allow push notifications from “websites” along the redirection path. The victim who accepts these notifications, often through a trick by the actor, will be inundated with browser push notifications, each of which leads to a different scam. Programs for so-called push monetization can pay a 70-90 percent revenue share to the affiliate who gained the victim’s approval. Push notifications essentially provide a persistence mechanism for the malicious adtech world to target a victim repeatedly.

Several examples of the push notifications seen from the CDC hijack are shown in Figure 10, with more examples here. The push notification services are run by different actors; we have seen residual push notifications from both RollerAds and the Russian underground operator, MoneyBadgers. While operators like Hazy Hawk are responsible for the initial lure, the user who clicks is led into a labyrinth of sketchy and outright malicious adtech. The fact that Hazy Hawk puts considerable effort into locating vulnerable domains and then using them for scam operations shows that these advertising affiliate programs are successful enough to pay well.

Figure 10
Figure 10. Push notifications following a visit to a Hazy Hawk URL claimed that the laptop had been hacked; clicking on the notification led to tech support and antivirus scams

Figure 10. Push notifications following a visit to a Hazy Hawk URL claimed that the laptop had been hacked; clicking on the notification led to tech support and antivirus scams

The U.S. Federal Bureau of Investigation’s (FBI) statistics on the wide range of scams enabled by Hazy Hawk show that such crimes are rapidly increasing, particularly among the elder community.18 In 2023, total losses reported for various fraud against people over 60 in the United States toppled $3.4 billion. Figure 11 shows those crimes by category. A remarkable number of them are the types we see Hazy Hawk conducting, along with other actors working in the affiliate advertising space.

Figure 11. Losses by category according to the 2023 Elder Fraud Report

Figure 11. Losses by category according to the 2023 Elder Fraud Report

Prevention and Protection

There are two types of victims with Hazy Hawk activities: those whose domains are hijacked and the users who visit the malicious URLs.

For domain owners, the best protection against Hazy Hawk and similar DNS hijacking threat actors is well-managed DNS. This can be difficult in complex, multi-national organizations where management of projects, domain registration, and DNS records may all be in separate organizations. These attacks are common after mergers and acquisitions. We recommend the establishment of processes that trigger a notification to remove a DNS CNAME record whenever a resource is shut down, as well as tracking active resources.

The best way to shield end users from Hazy Hawk is through protective DNS solutions. Threat actors who work in the affiliate marketing space utilize TDSs to maximize their profits, and DNS is the optimal solution to disrupt all activity through these systems. When the threat intelligence used in a protective DNS product is designed to track and detect TDS actors, as Infoblox Threat Intel does, Hazy Hawk and others can change their domain names and still be thwarted.

Education is a final component. Urge users to deny notification requests from websites they don’t know. If they start receiving messages, unwanted notifications can be turned off in the browser settings.

Indicators

Malicious indicators can be found in our GitHub repository.

acciona[.]com[.]au
ademe[.]fr
aha[.]org
alabama[.]gov
alaskaair[.]com
angloamerican[.]com
animalhumanesociety[.]org
anker[.]com
ariba[.]com
arsenal[.]com
auburn[.]edu
bain[.]com
barcelo[.]com
barnardos[.]org[.]uk
benesse[.]ne[.]jp
berkeley[.]edu
bluepoint[.]uk[.]com
boomi[.]com
bose[.]com
bv[.]com
byu[.]edu
ca[.]gov
campuslabs[.]com
capgemini[.]com
carrefour[.]fr
carto[.]com
cbre[.]com
ccsu[.]edu
cdc[.]gov
chicagotribune[.]com
christianpost[.]com
civilservice[.]gov[.]uk
claytargetsports[.]com
cmsg[.]uk[.]com
colorado[.]edu
commscope[.]com
communitycare[.]co[.]uk
deloitte[.]com
dignityhealth[.]org
discoverhongkong[.]com
dosomething[.]org
education[.]vic[.]gov[.]au
emerson[.]com
eset[.]com
ey[.]com
fcagroup[.]com
fnsb[.]gov
foxtel[.]com[.]au
fuller[.]edu
fwc[.]gov[.]au
gavi[.]org
ge[.]com
go[.]com
gouv[.]qc[.]ca
gov[.]on[.]ca
grapecity[.]com
gsk[.]com
health[.]gov[.]au
hktdc[.]com
honeywell[.]com
humana[.]com
iaea[.]org
illinois[.]edu
ine[.]mx
intel[.]com
investmentsandwealth[.]org
jameshardie[.]eu
jameshardie[.]it
jointcommission[.]org
kcl[.]ac[.]uk
kingcounty[.]gov
logitechg[.]com
mgmresorts[.]com
michelin[.]co[.]uk
motoman[.]com
mylio[.]com
nhk[.]or[.]jp
northwestern[.]edu
ntv[.]co[.]jp
nyu[.]edu
nzta[.]govt[.]nz
ombudsman-services[.]org
optum[.]com
ottogroup[.]com
oxinst[.]com
panasonic[.]com
panasonic[.]jp
pass-jeux[.]gouv[.]fr
pattan[.]net
pearson[.]com
phrma[.]org
ping[.]com
ppg[.]com
pwc[.]com
rakuten[.]com
ranzcp[.]org
rockwellautomation[.]com
sahealth[.]sa[.]gov[.]au
sartorius[.]com
savingplaces[.]org
scfederal[.]org
scholastic[.]com
sena[.]edu[.]co
sjsu[.]edu
skoda-auto[.]cz
slb[.]com
stanford[.]edu
stonybrook[.]edu
tamu[.]edu
ted[.]com
thapar[.]edu
trxtraining[.]com
trygghansa[.]se
turnitin[.]com
ucdavis[.]edu
ucl[.]ac[.]uk
uconn[.]edu
uhc[.]com
uib[.]no
umass[.]edu
uncc[.]edu
unicef[.]org
unilever[.]com
upmc[.]com
usc[.]edu
usopen[.]com
utexas[.]edu
valley[.]com
virginia[.]edu
wholetale[.]org
wiley[.]com
wsu[.]edu
zf[.]com
Table 1. Second-level domains (SLDs) that have had a Hazy Hawk subdomain hijack since December 2023
chesta-korci-bro[.]blogspot[.]com
pokam-pok[.]blogspot[.]com
kopde-tuk-kpre[.]blogspot[.]com
share[.]js[.]org
Table 2. Examples of first redirection URLs
accomodateyours[.]com
viralclipnow[.]xyz
acceleratetomb[.]xyz
impliednauseous[.]xyz
Whilsttypewriter[.]com
Trusthubmedia[.]com
Tvddt[.]online
Propertyportocolom[.]com
wearychallengeraise[.]com
Mstores[.]top
Cambertech[.]xyz
Extuilowelevid[.]com
Uxaya[.]sbs
Lijit[.]com
viralnow[.]xyz
cccodes[.]cloud
Leak[.]eneu[.]io
Table 3. Examples of TDS domains
Dankdigs[.]com
Hotnewrumor[.]com
Encryptalert[.]com
ferma[.]co[.]in
Rssnews[.]media
Gtrewe[.]co[.]in
Sualiteregents[.]co[.]in
Risotoska[.]co[.]in
Opukoj[.]com
Table 4. Examples of push notification request domains
Ferigs[.]xyz
Apperetive[.]xyz
Edygik[.]org
Digitdsk[.]org
Extuilowelevid[.]com
Table 5. Examples of domains from push notifications
Thankstoyou[.]space
Encryptalert[.]com
Ok-wwow[.]com
Fabiansec[.]com
Cleanupharm[.]com
Jidoscn[.]sbs
Spicymaturelovers[.]site
Nitehushpro24[.]com
movie[.]rssnews[.]media
impliednauseous[.]com
Table 6. Examples of malicious landing page domains

Footnotes

  1. https://www.ic3.gov/AnnualReport/Reports/2023_IC3ElderFraudReport.pdf
  2. https://blogs.infoblox.com/threat-intelligence/how-scammers-hijack-major-brands/
  3. https://labs.guard.io/subdomailing-thousands-of-hijacked-major-brand-subdomains-found-bombarding-users-with-millions-a5e5fb892935
  4. https://blogs.infoblox.com/threat-intelligence/who-knew-domain-hijacking-is-so-easy/
  5. https://urlscan.io/result/ea226950-2de8-4a39-8ad1-5282c1d394fb
  6. https://urlquery.net/report/64ae0264-9f2a-4234-b8b6-8b8a8030a2f4
  7. https://urlscan.io/result/3f9ac7ce-4a27-44c1-be46-983306fc362d
  8. https://urlscan.io/result/0195d776-08e9-7aaa-a2bd-0ab7c495e4af/
  9. https://urlscan.io/result/b1ce81c9-a187-454e-817d-07f27d360d34/
  10. https://js.org/
  11. https://github.com/js-org/js.org/wiki
  12. https://github.com/Jeff-Tian/weshare
  13. https://github.com/js-org/js.org/issues/9512
  14. https://urlscan.io/result/7d69ac72-0bef-43d7-a215-9de321cf7d39/
  15. https://urlscan.io/result/d2fbd8b3-8599-4ea9-bbb8-d1b2a7881b83/
  16. https://urlscan.io/result/01962c74-19c8-749e-89a6-f3090c6893a9
  17. https://urlscan.io/result/b425cad3-2d0f-41ca-ba18-e61ad349956f
  18. https://www.ic3.gov/AnnualReport/Reports/2023_IC3ElderFraudReport.pdf

Infoblox Original

About Author

WordPress Appliance - Powered by TurnKey Linux