The Click Is the Product

It all started with one line in a search result. Our daily CTI scan surfaced an article at opnameinvullen.com titled "CISA Alert: SharePoint Zero-Day Exploit CVE-2026-58644". A headline like that attracts any analyst: an alert from the US cyber agency, a critical SharePoint vulnerability and a CVE number. But the domain does not belong to CISA, and its name does not look like a security site. I set out to check whether this was reliable content, bait, or something else.

This article is the investigation diary, stop by stop. At every stop I answer the same five questions: what I checked, what it is, why I checked it, what I found and where it led me. Every technical term is explained the first time it appears, so you can follow along without reproducing the checks.

The short answer: I did not find a proven attack chain, and there is no need to invent one. I found a network of domains that redirect to a single content and advertising site, a domain that used to be a scout group's site and is now marketed as for sale, "publication" timestamps that renew on every request even though the article did not change, and different behavior toward crawler strings that was observed in one window and not reproduced later. The implication for CTI: accurate information about a threat can arrive in a wrapper that has no authority to lead us to act. And the most important thing to understand: the entire mechanism is built to make money from clicks. The click is the product. The full explanation appears after stop 10, in the section "So what's the problem?".

The journey map

Ten stops. Each one answers the question the previous one left open.

After stop 10 comes the section "So what's the problem?". It explains why the whole mechanism exists, and why security people should worry about it even when it contains no attack.

Ground rules

All checks were passive and used public material: ordinary GET requests for text (HTML, JS, JSON, ads.txt), DNS queries, public registration data, archives and scanner reports that already exist. I did not run JavaScript, did not scan actively, did not log in to anything, did not submit forms, did not download executables and did not contact the operators. All times are UTC. The main text collection was done on 12.10.2026 between 06:06 and 06:19 UTC; the screenshots and the recheck between 06:28 and 06:29. The results describe a defined sample, not the entire network.

Stop 1: The starting point, an article that looks like a CISA alert

The first check did not touch the site but the claim. CVE-2026-58644 is a Remote Code Execution vulnerability in Microsoft SharePoint (remote code execution, no authentication), with a CVSS 3.1 score of 9.8 out of 10; CVSS is the standard for rating vulnerability severity. MSRC, the Microsoft Security Response Center, published it in July 2026. CISA added it on July 16 to KEV, the catalog of vulnerabilities exploited in the wild, and an official CISA alert documents this. I re-verified the data against the official sources on 12.10.2026. [3-5]

The conclusion from this stop narrows the problem. The vulnerability is real, the alert is real, so the mere headline "CISA Alert" on a third-party site is not proof of impersonation. Covering a real alert is not impersonation. What remains open is what the site does around the content.

The question that opened: If the content is correct, why does the article appear on this domain? To answer, I requested the article and checked what the server returns.

Stop 2: The first jump, a 302 redirect to another site

The server did not return an article. It returned a 302 to hxxps://custommapposter[.]com/article/cisa-alert-sharepoint-zero-day-exploit-cve-2026-58644-security-patch-update/14641. From here on I will call custommapposter.com "the hub", because everything found afterwards leads to it.

The hub is a generic content site: a catalog of articles on a variety of topics, with ads on the page. This is what the destination page looks like (Figure 1). The archive (stop 6) shows that it predates the SharePoint article: RDAP shows the hub registered on 11.1.2024, and Wayback from 21.1.2024 shows a general catalog of health and questions. This is not a site that was born in October 2026.

The redirect itself is the surprise, not the content at its end: a domain with a Dutch name, registered a few months ago, that sends a security article to another content and advertising site. I did not measure how visitors reach the address, what the Google ranking is or how much traffic there is. What was actually documented is the redirect and the page.

The question that opened: Is opnameinvullen an isolated case? First, I checked what the article ties to: it contains links to related articles, and among them other hostnames.

Stop 3: From one domain to a hundred, expanding the links

I ran the check in three waves. First I checked the 101 hosts that appear in the article's links plus five "contact" pages from the previous report, 106 checks. From the links collected in the responses I then took a deterministic sample of 60 new domains (seed 20261012, so the selection can be reproduced). Finally I checked 12 hosts with rare suffixes, so as not to look only at com and org.

The result: 150 ingress domains in the sample actually redirected to the hub, in addition to the check of the hub itself. The statuses: 161 HTTP 200 responses, 11 404 responses, four errors with no status, one 520 response and one 403. A 200 response is not confirmation that the page is safe, and an error does not mean there is no content there.

This is what the links block looks like in the article's source code (Figure 3): a long list of articles, each leading to a different hostname. This is where I started to expand.

The whole graph is larger. The links collected yielded 3,289 hostnames and 14,803 link edges. This number is not the number of the operator's domains and not the number of malicious domains. It includes legitimate sources that the hub links to (NASA, IamExpat, news sites) and a gambling site that redirected to a different site. One counterexample: buildingtradesinstitute.org redirected to a different gambling site, without the shared analytics ID, and therefore was not counted as part of the network. There is no reason to turn thousands of links into thousands of IOCs. [E1-E2]

The question that opened: A shared redirect can still be a shared redirect service. What in the pages' code actually connects them?

Stop 4: What is shared, five markers in the code

These are the markers that recurred, and what each one is:

Google Analytics ID, G-54725HQVMF. The ID a site owner receives when they enable traffic measurement. The same ID on different pages means they report to the same measurement account, or copied the same template. It appeared in 156 results, including five "contact" pages that remained on the source domain.

Advertising site ID and advertising loader. The pages load a script from monu.delivery/site/0/e/f234e7-fc25-4181-9fdc-65d9171ace67.js. This is the Monumetric loader, a company that manages advertising for content sites, and the ID in the address is the site ID on its side. It appeared in 151 hub results in the sample. We return to it in stop 9.

The publisher's JS file, newsike.js. The site's local code file. I pulled it separately from six hosts (the hub, opnameinvullen, npsana, newsbee, pintotools, graafbernadotte). On all of them it was 21,951 bytes long and had the same SHA-256. A hash is a fingerprint of the file's content; an identical hash means the bytes are identical. [E3]

134f3ac4d5c9ef0738acd4a27716f0ea9a5f6ee75608d103552499a4abf7285f

Shared template. On 95 pages of the first wave the same page template recurred, including msvalidate.01 verification tags, tags a site owner adds to verify ownership with Bing Webmaster Tools.

Public contact string. One Gmail address appears on the same 95 pages. It is a string the site displays, not a verified identity, so I did not infer from it a person, nationality or country of an operator, and I omitted it from the article.

This is what two of the markers look like inside the source code of the hub page (Figure 4).

The redirects, the analytics ID, the advertising ID and the identical code on six hosts together support an operational link between the pages: they serve the same site, with the same advertising and measurement system. They do not identify the person who operates them. The fact that Cloudflare serves the domains and that they were registered with NameCheap is also not ownership attribution: both are services of millions of sites.

The question that opened: If so, what does this network do? I checked what a visitor gets who enters the main page of an ingress domain, and not the path of an article.

Stop 5: The main entrance, a banking article and a "for sale" panel

The root of opnameinvullen was redirected with a 302 to hxxps://custommapposter[.]com/article/best/926? sd=opnameinvullen.com. The root of graafbernadotte was redirected to the same article, with sd=graafbernadotte.org. [8]

The article itself deals with money transfers, and its headline mentions a card number and CVV. This is exactly what would raise suspicion of card-theft bait, so I read the forms on the page. All three forms found are search forms (a keyword field), not a form that collects card details or credentials. [E4]

The page also has a panel that displays the name of the source domain and offers it for sale. It includes the sentences "For sale securely on Namecheap" and "This domain is ready to be yours", and a link to a search on Namecheap. This is a claim of the page, which I presented as it is. I did not verify sale availability, price, ownership or an agreement with Namecheap, and I did not open a purchase process.

That is, the same template displays a customized sale window for every domain that redirects to it. The page markets a sale option; the research does not prove that such a sale takes place.

The question that opened: The name graafbernadotte looks like a real organization. What was on this domain before it became an entry door?

Stop 6: What was there before, a scout group's site

The Wayback snapshot from January 9, 2019 shows the site of a scout group in Heemstede, the Netherlands. The current RDAP shows a registration date of August 22, 2026. At the time of collection, an article path on the domain redirected to the hub, and the root led to the banking article with the sale panel from stop 5.

And these are the registration data themselves, as read from the public RDAP database of the org suffix (Figure 8).

This is a documented domain repurposing: the same domain name, a completely different use. The new registration is consistent with a domain that expired and was registered again, but it does not prove the acquisition mechanism. It was not shown that the scouts were hacked, that the domain was stolen or that it was bought at a particular auction. Inheritance of backlinks or a ranking improvement were also not measured. And in general, a nearby snapshot is not the earliest evidence, and a registration is not proof of a chain of ownership.

This is how the hub itself looks in the archive: Wayback from 31.12.2024 and from 1.1.2026 show a general catalog, and in January 2026 many dog-care topics. The publisher predates the SharePoint article, and the article is just more content that it recycles.

The question that opened: If the network recycles domains and topics, how far can we trust the date that appears in the article? I checked the timestamps.

Stop 7: One article, a date that renews on every request

In all three requests, the publication and update fields were identical to each other, and matched the response time exactly (in a +07:00 time zone):

To show that the article itself did not change I used a body hash: I extracted only the article text, normalized it (text only, a space as separator, no leading or trailing whitespace) and computed a SHA-256. I did not do this on the entire HTML, because a whole page changes on every request because of timestamps, tokens and rotating links even when the article is identical. In all three requests the same hash was obtained: [E5]

dc7cffb0dba2065f8684637c935dfceb88db73fecfe77d3031ce1837f51b1978

So this is not a substantive edit of the article. It is a stamp generated at serving time. The phenomenon recurred in the screenshot check at 06:28:08 and at 06:29:49 UTC. There is no need to know why the code was written this way to determine that the date on the site is not a reliable indicator of the publication time. [E5, V1]

To see this without relying on a single screenshot, I sent three requests for the same article five seconds apart and compared them (Figure 10).

In the same area of the page there is an author profile. I did not verify it, and there is no basis for calling the person shown "fabricated" or for concluding that the content was created by AI. The name, title, view count and reader rating on the page are not independent verification of identity or expertise.

The implication for CTI is practical: if a collection mechanism records "updated today" as a fact about the threat, it turns old content into a new indicator. Source quality must be preserved together with the fact extracted from it, and not disappear on the way to the summary.

The question that opened: If the page adapts itself to the request, does it also adapt itself to the identity of the requester? I checked what search engine crawlers get.

Stop 8: One version for the crawler, another for the reader, sometimes

In the original collection window, 06:06-06:19 UTC, requests with a Bingbot and Googlebot UA received robots: index, follow, without the Monumetric advertising loader. Control requests with a regular UA received noindex, follow and with an advertising loader. The normalized article body remained identical in all of them.

But at 06:29:49 UTC I repeated the check with a regular UA and with Bingbot, and the responses were identical: noindex, follow and an advertising loader in both. Therefore the finding is a conditional behavior that was observed in a particular window and was not reproduced in the later check. It can be described as intermittent; it cannot be presented as a fixed rule.

Two notes on limits. A request that declares Googlebot is not a verified Google visit; this is a comparison between responses to UA strings, and all the checks went out from the same network egress point, with no geographic variations. And I did not measure indexing, ranking improvement, entry into Discover or hiding of malware. The measured difference is in indexing metadata and in the loading of advertising, not in a malicious payload.

The question that opened: If advertising is so important that it is hidden from crawlers, who operates it and what is the connection to money? I checked the hub's advertising declarations.

Stop 9: Where the money comes from

The hub's ads.txt redirected (301) to a file at monu.delivery, which declares OWNERDOMAIN=custommapposter.com and MANAGERDOMAIN=monumetric.com, and a line in which monumetric.com is defined as DIRECT with the ID 0ef234e7-fc25-4181-9fdc-65d9171ace67. This ID is identical to the ID in the loader code I found in stop 4. The publisher's privacy policy and Monumetric's advertising policy declare the relationship, and cookies and data sharing for advertising purposes.

This is what the file itself looks like (Figure 11).

The whole file contains more than 1,000 authorization lines for 123 different advertising domains. This is an infrastructure built to sell ad slots at scale.

The leading explanation for everything seen so far is money, and it is simple: the click is the product. Every visit to a page loads ads, every ad that is displayed is sold, and therefore a page that someone opened is worth money to the site's owner, regardless of whether the content is correct. The full detail comes in the section after stop 10. This is an assessment with a medium level of confidence, not measured revenue: contracts, payments, price per thousand impressions or invalid traffic were not examined, and an ad that appears in a screenshot is not proof that a particular impression was billed. Monumetric is not presented here as a partner in an attack, and no proof of ad fraud was found.

The question that opened: One could see this as a business model. Is there something more dangerous on top of it? I checked the code, the forms and the reputation.

Stop 10: Is there an attack there

The code. The publisher's bundle includes lazy-loading, adblock detection and bait resources meant to detect blocking. In the word list I searched in it I did not find eval, atob, clipboard, canvas or fingerprinting. The two Monumetric code layers (about 68 KB and about 594 KB) and a cookie helper were read as text only. Capabilities of ordinary advertising were observed: collection of browser, device and location data for auction purposes, sending auction metadata and dynamic loading of scripts and creatives. Advertising telemetry is not necessarily credential leakage, and no shell, clipboard access or credential-theft flow was found. This is not full reverse engineering, and I have no verdict based on a word search.

The forms. On the SharePoint and banking paths no form that collects card details or credentials was found (stop 5).

The reputation. On OTX, an open threat database, the hub has six pulses. One of them carries a SocGholish tag, but it is a broad list of 5,971 indicators with no payload chain attributed to this domain. Existing urlquery reports include warnings about shared ad hosts. These are directions for checking, not proof that Custommapposter distributes SocGholish; I found no basis for such an attribution. opnameinvullen and the other hosts checked have no pulses on OTX, and that is not proof of cleanliness. An existing urlscan scan from 11.10 remained unclassified, which is also not a verdict. [12-14, E6]

What came out of this. In the defined corpus, the SharePoint and banking paths, the publisher's code, the advertising layers that were read and the reputation material that could be interpreted, no proven attack chain was found. This is not equivalent to "the site is safe": not all creatives, sessions, countries and user profiles were checked. Nor is it equivalent to "tomorrow there will be an attack". Those are two jumps the evidence does not allow.

The question that opened: If there is no attack, and all of this exists for money, why is this a problem at all? This is the question the next section answers.

So what's the problem?

At this point all the evidence is on the table, and one question remains that I have not yet asked out loud: what is all this for? If there is no malware and no attack chain, what was actually built here, and why is this an article and not just an ugly site? The answer is assembled from stops 4, 5 and 9, and now they can be connected.

The goal is money, and the click is the product

The entire mechanism is built to make money from page visits. The visitor is not the site's customer. The visitor is what is being sold. The chain, step by step:

This is what I mean when I say the click is the product. There is no customer here paying for an article. There is a page that sells the attention of whoever arrived at it, and therefore anything that brings more visitors to the page is profit: a headline with hot search keywords, hundreds of doors instead of one door, a page that always looks fresh.

How each stop looks when you connect it to money

Until now each stop was a finding in its own right. The table shows what each one does inside the money model. The explanation column is my interpretation, not a finding.

What I don't have: numbers. I did not see a contract, a payment, a price per thousand impressions or an actual visit count, so I have no measured revenue. The money model is the leading explanation for the evidence, not a measured fact. I also did not check whether the advertising itself is in order: there is no claim here of ad fraud or of Monumetric being a partner.

Why this is a security problem even without an attack

If a money machine like this sat on recipes or sports news, I would write "another ugly site" and move on. Here it sits on real information about a SharePoint vulnerability, exactly where security people search. From this come three problems. None of them is "the site attacks".

1. Erosion of trust in real CVE data

The CVE is real, the CISA alert is real, and the article quotes them correctly (stop 1). The problem is the wrapper: a headline that opens with "CISA Alert" on a site that has no connection to CISA, and was built to catch searches. An analyst searching for the vulnerability also gets money pages in the results, and has to separate them each time anew. The more such pages there are, the more the real source drowns, and every secondary article becomes a little less credible even when it is correct. To be precise: the domain checked is not a typosquat of CISA, and a headline that covers CISA is not proof of impersonation.

2. The fake-freshness effect

In stop 7 we saw that a "published" and "updated" stamp equals the moment of the request (Figure 10). A CTI tool, a feed or an analyst that sorts by "what was updated today" will see the article as new every time they check it. Over time this teaches people and automation to treat freshness as a sign of credibility, exactly when it cannot be trusted. This is the sharpest finding for someone who does CTI: a true fact inside a timestamp that cannot be trusted.

3. The pipe itself

The network brings to the page security people, IT staff and system administrators who are looking for a server update. These are the people who install patches. Today this pipe is search, click, redirect, page, ad-bearing and nothing more, and there is no evidence that it carries more than that. But it does not need new infrastructure to carry something else: whoever controls the page, or an ad that loads in it, could tomorrow offer a fake "security update" there, a command to paste into a terminal (ClickFix) or another loader. This is a hypothetical future scenario, not a finding, and not a claim that the current operator has such an intent. The risk is that the pipe already exists and reaches exactly the people who act on what they read.

A note on wording: loading additional code is part of ordinary advertising and is not in itself an additional malware stage. An "additional stage" here is only the hypothetical scenario, not something that was found. And "no attack chain was found" is not "the site is safe", and also not "tomorrow there will be an attack": I did not cover every creative, session, country or user profile.

The finding in one sentence

A content and advertising network built on recycled domains redirects search traffic to a shared publisher, sometimes changes the page's indexability and ad loading toward crawler strings, and produces publication stamps that are generated at request time. All of this serves a model in which the click is the product. Every part of the thesis has a chain of evidence from the stops above. There is no chain of evidence for malware, for impersonation of CISA or for an intent to harm the reader.

What to do

The recommendations are divided by who is reading. Each one is small, and can be carried out today.

If you are CTI analysts, a SOC or intelligence consumers

1. Use a third-party article to discover a topic, not to choose a patch. Verify the CVE number, the affected product and the update itself against MSRC, CISA or a relevant official source such as NCSC.
2. After every redirect, check which domain you landed on. Do not download an "update", an extension or a repair tool from a page you found by chance.
3. Keep provenance separate from CVE severity. In the intelligence store, keep the source URL, the collection time and a reliability assessment. Do not raise confidence because of an official-looking headline or a fresh timestamp: an "updated today" stamp is not evidence that the content changed.

If you are responsible for an organization

1. Consider blocking browsing to the observed content domains, according to organizational policy. This is filtering an untrusted source, not blocking a proven C2. Use a narrow, verified list, document the reason and a review date, and do not block shared Cloudflare addresses, a registrar or an entire advertising infrastructure on the basis of this research.
2. Search for the ingress domains and the hub in DNS, proxy and SWG. A visit alone is not a compromise. Escalation to IR should rest on a follow-up: a file download, its execution, a browser change, a new process or endpoint behavior.
3. Keep browsers updated and restrict unapproved extensions. For examining suspicious material, prefer an isolated environment.

If you are a search engine, an advertising network or a domain registrar

1. Search engine: The findings are a basis for examining timestamps generated at request time, content consolidation and UA differences.
2. Advertising network: The findings are a basis for examining provenance, redirect chains and the publisher's identity. Invalid traffic was not measured, so this must not be presented as proof of ad fraud.
3. Domain registrar: Focused examples can be passed on if a violation of its policy is discovered. Not every reuse of a domain is a violation, and the sale claim in the panel was not verified. No such approach was made as part of the research.

The durable mitigation is not guessing who will attack tomorrow. It is preserving the boundary between a content source and a source of code and updates. Even if a secondary article is right about the CVE, it has no authority to deliver a binary, receive credentials or ask for a command in a terminal.

How to identify a network like this without guessing

My playbook starts with provenance and not with reputation. The goal is to build a chain of evidence: where we came in from, where we arrived, what is shared between the pages and what changes between requests. Every check requires a UTC time, a URL, the response and the errors, and not only a screenshot of a headline.

1. Keep the entire redirect chain

Document the entry URL, the 3xx codes, the Location headers and the final URL. Do not settle for the domain the browser displays at the end. Different domains returning to the same publisher is stronger than a similarity between names or the same CDN. Here the sd parameter was also a useful pivot.

2. Connect several markers, do not crown one marker

Compare the GA ID, the ad-site UUID, the MANAGERDOMAIN in ads.txt and the hash of the publisher code. A shared identifier can indicate shared infrastructure or a shared service; it is not a malware signature. The combination with the redirects is what makes the link well founded. Also record counterexamples.

3. Separate a content change from a metadata change

Save two or more responses and compare HTTP Date, published_time and modified_time. Compute a hash for a normalized article body, separately from a hash of the whole HTML. A whole page may change because of timestamps, tokens and rotating links even when the article did not change. Here the normalization was article.get_text with a space separator and stripping of edge whitespace. [E5]

4. Check history and run a control

Compare an archive snapshot to RDAP and to the current response. A new registration is not a full ownership history. In a UA check, use the same path, repeat a regular control and check again later. Reporting a failure to reproduce is part of the finding, not a detail to hide.

5. Expand the graph, then validate a sample

Related-articles links provide leads. They are not an asset list. Choose a documented sample, keep the seed if you use sampling, and then actually check the paths. Separate serving relationships from external sources and unrelated destinations. Do not turn thousands of hyperlinks into thousands of malicious IOCs.

You can start from the research's evidence package and read HTML and JS as text only. When collecting again, prefer narrow, permitted requests, without running untrusted code, creating new public scans or testing exploitability. Reproduction is not a promise that the dynamic site will behave as it did at the time of collection.

Why not rely on the SocGholish tag?

The hub appeared in an OTX pulse with a SocGholish tag, but the pulse was a broad ASN list of 5,971 indicators with no payload chain specific to the domain. Other reports included warnings about shared ad hosts. These are leads for checking, not proof that Custommapposter distributes SocGholish. I found no basis for such an attribution. [12-14, E6]

Limits of the findings

The conclusions here are limited to what was observed, when, and at what scale. They do not attribute intent, ownership or identity, and do not purport to describe the entire network.

What can be said

Facts can be phrased with a time window and scope: 150 ingress domains in the sample redirected to the same hub; the same markers and code recurred; a domain that served a scout group is used differently today; timestamps matched the request time; UA differences were observed in one window and not reproduced later. Next to each claim there is a source or an evidence ID. The screenshots are documentation of an observed state, not a verdict on the entire site.

What there is no basis to claim

There is no basis to call the network a criminal organization, a proven phishing campaign, an APT, a SocGholish distributor or a proven ad fraud. Ownership, a person or a country must not be attributed by a Gmail string, an author name, a timezone, a language, a registrar or a CDN. There is no basis to write that the scouts were hacked, that Namecheap confirmed a sale or that Monumetric is a partner in an attack.

Unverified contact details are not needed to show a connection between pages, and therefore were omitted from the article. The screenshot of the author profile was cropped without an address and phone number, and from the scout site screenshot only the site's title in the archive remained, without identifiable images of children. The crops are stated in the captions.

Disclosure and transparency

As part of the research no approach was made to CISA, Monumetric, Namecheap or the site operators, and this is not a report of a new SharePoint attack or of confirmed phishing. If an actual attack chain is found, that will be a new fact that requires reassessment.

My bottom line: not every problematic source is an attacker. But a true fact inside an untrustworthy wrapper does not make the wrapper trustworthy. Here the click is the product, and the value for us is to learn to recognize the infrastructure without inventing a crime for it, and without entrusting it with our next action.

Appendix: investigation markers, not a malware list

The table is meant for correlation and exposure investigation. Domains are written in defanged form. The appearance of a marker is not proof of compromise; a publisher's hash is not a malware hash.

Full identifiers and hashes

Shared ad-site identifier:

0ef234e7-fc25-4181-9fdc-65d9171ace67

SHA-256 of the publisher bundle, identical on six hosts, 21,951 bytes:

134f3ac4d5c9ef0738acd4a27716f0ea9a5f6ee75608d103552499a4abf7285f

SHA-256 of the normalized SharePoint article body:

dc7cffb0dba2065f8684637c935dfceb88db73fecfe77d3031ce1837f51b1978

SHA-256 of the research's full evidence ZIP:

ac155b9d225f922e350bd4b0aa7d72fc855d37d3cf1668011397403d5146aba0

Evidence package and reproduction limits

A full evidence package exists with 673 files, including SHA256SUMS, source-index.csv, request and response records, domain-checks.csv, link-edges.csv, serving-comparison.json and reproduce.md. The integrity check confirmed the 672 items in the manifest. The hashes prove file integrity after collection, not source identity or a collection time approved by a third party.

The main text collection was done on 12.10.2026, around 06:06-06:19 UTC; the screenshots and the recheck at 06:28-06:29 UTC. The source documentation separates a static reading of code from a browser display. No exploit attempts, fuzzing, account logins, executable downloads or approaches to operators were made. Reproduction must remain a safe reading of untrusted material, not opening HTML/JS as a live page.

Figures 3, 4, 8, 10 and 11 were added in this version. They were collected on 12.10.2026 between 07:32 and 07:35 UTC with passive reading only: view-source of the page and a text load of the ads.txt and RDAP files. Figure 10 was assembled from the output of three requests. The public contact string that appears in the source code was not included in the screenshots.

Sources and evidence map

These are the research sources, not a recommendation to visit the network's sites in a regular browser. The unofficial paths are untrusted material. The source addresses are clickable. Official sources 3-5 were rechecked on 12.10.2026; the other sources are supported by the documented collection in the package.

1. The entry path checked
   hxxps://opnameinvullen[.]com/article/cisa-alert-sharepoint-zero-day-exploit-cve-2026-58644-security-patch-update
2. The SharePoint article on the hub
   hxxps://custommapposter[.]com/article/cisa-alert-sharepoint-zero-day-exploit-cve-2026-58644-security-patch-update/14641
3. The official CISA alert
   https://www.cisa.gov/news-events/alerts/2026/07/14/cisa-urges-sharepoint-hardening-after-new-exploitations
4. MSRC: vulnerability and CVSS score
   https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-58644
5. CVE/CNA record
   https://cveawg.mitre.org/api/cve/CVE-2026-58644
6. The scout site archive
   https://web.archive.org/web/20190109175930/http://www.graafbernadotte.org/
7. RDAP of graafbernadotte.org
   https://rdap.publicinterestregistry.org/rdap/domain/graafbernadotte.org
8. Landing page and sale panel
   hxxps://custommapposter[.]com/article/best/926?sd=opnameinvullen.com
9. ads.txt: the documented target file
   hxxps://monu[.]delivery/adstxt/0/e/f234e7-fc25-4181-9fdc-65d9171ace67.txt
10. The publisher's privacy policy
    hxxps://custommapposter[.]com/page/privacy-policy
11. Monumetric's advertising policy
    https://www.monumetric.com/publisher-advertising-privacy
12. OTX: reputation record of the hub
    https://otx.alienvault.com/api/v1/indicators/domain/custommapposter.com/general
13. OTX: the pulse with the SocGholish tag
    https://otx.alienvault.com/api/v1/pulses/66cd2662131c0ca94577e105
14. An existing urlquery report, not a new scan
    https://urlquery.net/report/1c48c7a9-36fb-4831-a358-aa865c170faa

Claim-to-evidence-file map

The collection window and the hashes in the package refer to the saved responses, not to the state of the site forever. A later reproduction that is not identical should be kept alongside the original results. The screenshots were extracted from the research's visual documentation, with no change to the content other than the crops described in the captions.